БД по локальной библиотеке

Полученная псевдотаблица может быть полезна при планировании или принятии управленческих решений, когда необходимо иметь все возможные варианты исполнения заказов по каждому изделию. Отметим, что таблица О3 не имеет ключей и в ней возможно повторение записей. Если таблицу Д3 сделать основной, а таблицу О3 -  дополнительной, получим связь вида 1:М. Поступив аналогично с таблицами О2 и Д2, можно получить связь вида М:1. Отсюда следует, что вид связи (1:М или М:1) зависит от того, какая таблица является главной, а какая дополнительной.

 

Связь вида М:М

Самый общий вид связи М:М возникает в случаях, когда нескольким записям основной таблицы соответствует несколько записей дополнительной таблицы.

 

Пример 5.

Пусть в основной таблице О4 содержится информация о том, на каких станках могут работать рабочие некоторой бригады. Таблица Д4 содержит сведения о том, кто из бригады ремонтников какие станки обслуживает.

 

Таблица О4

*   *  +  

Работает	На станке
Иванов А.В.	станок1
Иванов А.В.	станок2
Петров Н.Г.	станок1
Петров Н.Г.	станок3
Сидоров В.К.	станок2

 

Таблица Д4

*   *  +  

Обслуживает	Станок
Голубев Б.С.	станок1
Голубев Б.С.	станок3
Зыков А.Ф.	станок2
Зыков А.Ф.	станок3

 

Первой и третьей записям таблицы О4 соответствует первая запись таблицы Д4 (у всех этих записей значение второго поля – «станок1»). Четвертой записи таблицы О4 соответствуют вторая и четвертая записи таблицы Д4 (во втором поле этих записей содержится «станок3»).

Исходя из определения полей связи этих таблиц можно составить новую таблицу с именем «О4+Д4», записями которой будут псевдозаписи. Записям полученной таблицы можно придать смысл возможных смен, составляемых при планировании работы. Для удобства, поля новой таблицы переименованы (кстати, такую операцию предлагают многие из современных СУБД).

 

Таблица «О4+Д4»

Работа	Станок	Обслуживание
Иванов А.В.	станок1	Голубев Б.С.
Иванов А.В.	станок2	Зыков А.Ф.
Петров Н.Г.	станок1	Голубев Б.С.
Петров Н.Г.	станок3	Голубев Б.С.
Петров Н.Г.	Станок3	Зыков А.Ф.
Сидоров В.К.	Станок2	Зыков А.Ф.

 

Приведенную таблицу можно использовать, например, для получения ответа на вопрос: «Кто обслуживает станки, на  которых трудится Петров Н.Г.?».

Очевидно, аналогично связи 1:1, связь М:М, не устанавливает подчиненности таблиц. Для проверки этого можно основную и дополнительную таблицу поменять местами и выполнить объединение информации путем связывания. Результирующие таблицы «О4+Д4» и «Д4+О4» будут отличаться порядком следования первого и третьего полей, а также порядком расположения записей.

Замечание.

На практике в связь обычно вовлекаются сразу несколько таблиц. При этом одна из таблиц может иметь различного рода связи с несколькими таблицами. В случаях, когда связанные таблицы, в свою очередь, имеют связи с другими таблицами, образуется иерархия или дерево связей.

 

Контроль целостности связей.

Из перечисленных видов связи наиболее широко используется связь вида 1:М. Связь вида 1:1 можно считать частным случаем связи 1:М, когда одной записи главной таблицы соответствует одна запись вспомогательной таблицы. Связь М:1, по сути, является «зеркальным отображением» связи 1:М. Оставшийся вид связи М:М характеризуется как слабый вид связи или даже как отсутствие связи. Поэтому в дальнейшем рассматривается связь вида 1:М.

Напомним, что при образовании связи вида 1:М одна запись  главной таблицы (главная родительская запись) оказывается связанной с несколькими записями дополнительной (дополнительные, подчиненные записи) и имеет место схема, показанная на схеме 6.

 

 

 

				. . .
. . .
				. . .
. . .

Схема 6

 

Контроль целостности связей обычно означает анализ содержимого двух таблиц на соблюдение следующих правил:

• Каждой записи основной таблицы соответствует нуль или более записей дополнительной таблицы;
• В дополнительной таблице нет записей, которые не имеют родительских записей в основной таблице;
• Каждая запись дополнительной таблицы имеет только одну родительскую запись основной таблицы.

Опишем действие контроля целостности при манипулирования данными в таблицах. Рассмотрим три основные операции над данными двух таблиц:

• Ввод новых записей;
• Модификацию записей;
• Удаление записей.

При рассмотрении попытаемся охватить все возможные методы организации контроля целостности. В реальных СУБД могут применяться собственные методы, подобные описываемым.

При вводе записей возникает вопрос определения последовательности ввода записей в таблице, чтобы не допустить нарушение целостности. Исходя из приведенных правил, логичной является схема, при которой данные сначала вводятся в основную таблицу, а потом – в дополнительную. Очередность ввода может быть установлена на уровне целых таблиц или отдельных записей (случай одновременного ввода в несколько открытых таблиц).

В процессе заполнения основной таблицы контроль значений полей связи ведется как контроль обычного ключа (на совпадение  со значениями тех же полей других записей). Заполнение полей связи дополнительной таблицы контролируется на предмет совпадения со значениями полей связи основной таблицы. Если вновь вводимое значение в поле связи дополнительной таблицы не совпадает ни с одним соответствующим значением в записях основной таблицы, то ввод такого значения должен блокироваться.

Модификация записей. Изменение содержимого полей связанных записей, не относящихся к полям связи, очевидно, должно происходить обычным образом. Нас будет интересовать механизм изменения полей связи.

При редактировании полей связи дополнительной таблицы очевидным требованием является то, чтобы новое значение поля связи совпадало с соответствующим значением какой-либо записи основной таблицы. Т.е. дополнительная запись может заменить родителя, но остаться без него не должна.

Редактирование поля связи  основной таблицы разумно подчинить одному из следующих правил:

• Редактировать записи, у которых нет подчиненных записей. Если есть подчиненные записи, то блокировать модификацию полей связи;
• Изменения в полях связи основной записи мгновенно передавать во все поля связи всех записей дополнительной таблицы (каскадные обновления).

В операциях удаления записей связанных таблиц большую свободу, очевидно, имеют записи дополнительной таблицы. Удаление их должно происходить практически бесконтрольно.

Удаление записей основной таблицы логично подчинить одному из следующих правил:

• Удалять можно запись, которая не имеет подчиненных записей;
• Запретить (блокировать) удаление записи при наличии подчиненных записей, либо удалять ее вместе со всеми подчиненными запиясми (каскадное удаление).

 

 

    

 

3 ЭКОНОМИЧЕСКИЙ РАЗДЕЛ

 

3.1 Оценка затрат на  разработку ПО

Оценка затрат на разработку ПО является одним из наиболее важных видов деятельности в процессе создания ПО, хотя она и не выделена в стандарте ISO 12207 как отдельный процесс. При отсутствии адекватной и достоверной оценки невозможно обеспечить четкое планирование и управление проектом. В целом ситуация в данной области, сложившаяся в индустрии информационных технологий, выглядит далеко не блестящей.

Недооценка стоимости, времени и ресурсов, требуемых для создания ИС, влечет за собой недостаточную численность проектной команды, чрезмерно сжатые сроки разработки и, как результат, утрату доверия к разработчикам в случае нарушения графика. С другой стороны, перестраховка и переоценка могут оказаться ничуть не лучше. Если для проекта выделено больше ресурсов, чем реально необходимо, причем без должного контроля за их использованием, то ни о какой экономии ресурсов говорить не приходится. Такой проект окажется более дорогостоящим, чем должен был быть при грамотной оценке, и приведет к запаздыванию с началом следующего проекта.

Оценка затрат на разработку ПО предполагает выполнение следующих четырех шагов:

• оценка размера разрабатываемого продукта. Для ПО в прежнее время основной мерой оценки являлось количество строк кода (LOG — Lines Of Code), а в настоящее время является количество функциональных точек (FPs — Function Points). Определение функциональной точки приведено;
• оценка трудоемкости в человеко-месяцах или человеко-часах;
• оценка продолжительности проекта в календарных месяцах;
• оценка стоимости проекта.

Оценка размера проекта базируется на знании требований к системе. Для такой оценки существуют два основных способа:

1. По аналогии. Если в прошлом приходилось иметь дело с подобным проектом и его оценки известны, то можно, отталкиваясь от них, приблизительно оценить свой проект.

2.  Путем подсчета размера  по определенным алгоритмам на основании исходных данных — требований к системе.

Оценка трудоемкости проекта выводится на основании его размера. Для такой оценки также существуют два основных способа:

1. Самый лучший вариант — это использование накопленных в вашей организации исторических данных, позволяющих сопоставить трудоемкость вашего проекта с трудоемкостью предыдущих проектов аналогичного размера. Однако это возможно только при следующих условиях:

в организации аккуратно документируются реальные результаты предыдущих проектов;

по крайней мере, один из предыдущих проектов (а лучше, если несколько) имеет аналогичный характер и размер;

жизненный цикл, используемые методы и средства разработки, квалификация и опыт проектной команды вашего нового проекта также подобны тем, которые имели место в предыдущих проектах.

2. Если предыдущий подход по разным причинам оказывается неприменимым, следует использовать один из известных алгоритмических методов оценки (например, модель СОСОМО (Constructive COst MOdel - конструктивная стоимостная модель) Барри Боэма).

Подобным же образом (как на основе исторических данных, так и с использованием формальных методов) оцениваются продолжительность и стоимость проекта.

Согласно Эдварду Йордану, все доступные средства оценки классифицируются следующим образом:

• Средства оценки, являющиеся коммерческими продуктами, такие, как SLIM (Quantitative Systems Management), ESTIMACS (Computer Associates), KnowledgePLAN и CHECKPOINT (Software 
Productivity Research (SPR)). Глава фирмы SPR Каперс Джонс, "гуру" в области метрик ПО, оценивает рынок средств оценки проектов примерно в 50 продуктов. Эти продукты нельзя назвать совершенными, и все они требуют от пользователя высокого уровня квалификации (здесь, как и в других областях деятельности, действует принцип "что заложишь, то и получишь"). В лучшем случае с помощью таких продуктов можно получить оценку с точностью +10%. Даже если точность будет +50%, это все равно лучше, чем брать данные "с потолка".

• Динамические модели систем — множество имитационных моделей, которые позволяют исследовать нелинейные зависимости между 
  различными факторами, влияющими на динамику проектных процессов. Например, если частью стратегии проекта является требование сверхурочной работы участников проекта со стороны менеджера, каков будет эффект через несколько недель или месяцев? Естественно предположить, что по сравнению с нормальным восьмичасовым рабочим днем отдача увеличится, однако наиболее опытный менеджер проекта также отметит, что производительность (измеряемая в количестве функциональных точек в день, строках кода в час и т.д.) по мере накопления усталости будет постепенно снижаться. Кроме того, возрастет количество ошибок, что, очевидно, повлияет на трудоемкость тестирования и отладки.
• Аналитические модели для оценки проектов, описанные в литературе. Лучшими являются работы Барри Боэма (модель СОСОМО, разработанная им в начале 80-х гг., была позднее модифицирована в модель СОСОМО-2). Другой классической работой является книга Фредерика Брукса "Мифический человеко-месяц", так же переизданная в 1995 г. с учетом современной технологии и практики разработки ПО.
• Различные руководства и отчеты организаций, подобных SoftwareEngineering Institute (SEI), которые могут помочь при выполнении уценки проектов.
• Такие распространенные методы, как прототипирование, также могут использоваться для оценки критичности тех или иных проектных ограничений для всей разрабатываемой системы в целом. Этот подход позволяет привнести немного здравого смысла в проектную команду и в окружающих ее менеджеров и заказчиков. Если руководство хочет, чтобы команда из трех разработчиков написала 1 млн строк кода за 12 мес., то следовало бы в течение первого месяца разработать небольшой прототип будущей системы, который, по крайней мере, позволит грубо оценить производительность проектной команды, а также реализуемость проекта в целом. 
  Остановимся более подробно на методе функциональных точек. Определение числа функциональных точек является методом количественной оценки ПО, применяемым для измерения функциональных характеристик процессов его разработки и сопровождения независимо от технологии, использованной для его реализации.