Контрольные вопросы 1.1

1. Кратко опишите этапы жизненного цикла программного проектирования.

2. Кто является основными действующими лицами жизненного цикла программного проектирования?

Модели данных

Для удобства, данные должны храниться в файле в определенном виде. В области баз данных последние 20 лет или около того, существует три основных типа «логических» моделей баз данных – иерархические, сетевые и реляционные – три пути логического восприятия расположения данных в файловой структуре. Данный раздел предусматривает ознакомление с каждой из этих трех основных моделей и краткое введение в реляционную модель.

Иерархическая Модель

Смысл иерархических моделей состоит в том, что все данные размещаются иерархическим способом (связь «родитель-ребенок»). Если, например, у нас была бы база данных компании, и был служащий, который имел зависимости, тогда можно было бы говорить об этом служащем, как о «родителе» зависимости. (Примечание: Важно понимать, что отношение «родитель-ребенок» не означает человеческие отношения. Термин «родитель-ребенок» является просто удобным определением общего семейного отношения. «Ребенок» здесь может быть зависимым супругом или любым другим человеческим отношением.) Мы можем иметь зависимость каждого служащего с одним родителем, и каждый служащий может иметь многочисленных зависимых детей. В базе данных, информация сформирована в файлы, записи, и области. Представьте себе картотеку, назовем ее файл «служащие»: он содержит всю информацию о служащих компании. Каждый служащий имеет запись о самом себе, так что файл «служащие» состоит из индивидуальных записей о каждом служащем. Каждая последующая запись в файле должна быть организована аналогичным образом. Например, Вы должны сделать так, что имя человека будет находиться всегда на одном и том же месте в каждой записи. Аналогично, адрес, номер телефона, и т.п. должны находиться на одних и тех же соответствующих местах во всех записях. Мы называем имя «полем» записи. Аналогично, адрес, номер телефона, жалованье, дата проката, и т.п. - также являются полями записи служащего. Вы можете представить себе, что родительская запись (о служащем) может содержать все типы полей - различные компании имеют разные потребности и не существует двух абсолютно одинаковых компаний.

В этом примере мы будем считать, что компания также имеет присоединенный к записи служащего зависимый файл с содержащейся в нем зависимой информацией – возможно, имя зависимости, дата рождения, место рождения, обучение в школе, страховой информации, и т.п.. Теперь представьте себе, что у вас есть две картотеки: о служащих и о зависимостях. Связь между записями в различных картотеках называется «отношение». Каждая зависимость должна быть связана с некоторым служащим, и каждый служащий может иметь или не иметь зависимости в картотеке зависимостей.

Связи во всех моделях базы данных имеют, что называется, «структурные ограничения». Структурное ограничение включает в себя два понятия: мощность (количество элементов) и опциональность. Мощность это описание всех возможных вариантов зависимости записи одного типа от другой, и наоборот. В нашей компании, если служащий может иметь множество зависимостей, а зависимость может иметь только одного служащего-родителя, следует говорить, что эта связь – один ко многим, то есть один служащий имеет много зависимостей. Если служащие компании могут иметь многочисленные зависимости, и зависимости имеют более одного родителя, тогда связь называется многие ко многим - много служащих, много зависимостей. Опциональность (факультативность) показывает, необходимо или возможно для некоторой записи иметь соответствующую запись в другом файле. Если служащий может иметь зависимости, а может и не иметь, тогда связь его с зависимостями – «опциональная» или «частичная». Если зависимости должны быть обязательно связаны со служащим(и), тогда связь его с зависимостями – «обязательная» или «полная».

Кроме того, связи всегда устанавливаются в обоих направлениях в описаниях баз данных. Мы можем сказать, что:

Служащие могут иметь несколько зависимостей или не иметь ни одной

и

Зависимости должны ассоциироваться с одним и только одним служащим.

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

Все связи между записями в иерархической модели являются связями один-ко-многим или один-к-одному, но ни в коем случае ни многие-к-одному или многие-ко-многим. Поэтому, для иерархической модели «служащий-зависимость», мы можем иметь только отношение служащий-зависимость с типом связи один-ко-многим или один-к-одному; служащий может иметь несколько зависимостей или не иметь ни одной, или (иногда) служащий может иметь одну и только одну зависимость. В иерархической модели не может быть зависимостей с несколькими родителями.

Проектирование иерархических баз данных начинается с выбора некоторого пути физического «соединения» родительской и дочерней записей. Представьте себе, что Вы ищете служащего в картотеке «служащие» и хотите найти связанные с ним записи в зависимой картотеке. Одним из вариантов установления связи служащий-зависимость является следующий: для некоторой записи служащего имеется указатель на зависимую запись, а для нее в свою очередь имеется указатель на следующую зависимость (например, список детей служащего).

Например, Вы находите служащего Jones. В записи Jones, есть пометка, что первая зависимость для Jones обнаружена в зависимой картотеке, файловая картотека 2, запись 17. «Файловая картотека 2, запись 17» это указатель – «связь» или «отношение» между служащим и зависимостью. Теперь рассматривая этот пример дальше, будем считать зависимость, находящуюся в файловой картотеке 2, запись 17, указателем на следующую зависимость, находящуюся в файловой картотеке 3, запись 38; эта запись указывает на следующую зависимость в файловой картотеке 1, запись 82.

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

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

Иерархическая модель имеет три основных недостатка:

1. Не все ситуации можно представить в виде «родитель-ребенок» со связью «один ко многим».

2. Выбор способа связи файлов влияет на производительность системы, причем как положительно, так и отрицательно.

3. Связь родительских и дочерних записей происходит физически. Если зависимый файл был изменен, необходимо восстанавливать все указатели.