Основы проектирования реляционных баз данных

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

Как отмечалось в п. 1.3, инфологическая модель отображает реальный мир в некоторые понятные человеку концепции, полностью независимые от параметров среды хранения данных. Существует множество подходов к построению таких моделей: графовые модели, семантические сети, модель "сущность-связь" и т.д. [11]. Наиболее популярной из них оказалась модель "сущность-связь", которая будет рассмотрена в главе 2.

Инфологическая модель должна быть отображена в компьютеро-ориентированную  даталогическую модель, "понятную" СУБД. В процессе развития теории и практического использования баз данных, а также средств вычислительной техники создавались СУБД, поддерживающие различные даталогические модели [1, 2, 8, 11].

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

Сетевые модели также создавались  для мало ресурсных ЭВМ. Это достаточно сложные структуры, состоящие из "наборов" – поименованных двухуровневых деревьев. "Наборы" соединяются с помощью "записей-связок", образуя цепочки и т.д. При разработке сетевых моделей было выдумано множество "маленьких хитростей", позволяющих увеличить производительность СУБД, но существенно усложнивших последние. Прикладной программист должен знать массу терминов, изучить несколько внутренних языков СУБД, детально представлять логическую структуру базы данных для осуществления навигации среди различных экземпляров, наборов, записей и т.п. Один из разработчиков операционной системы UNIX сказал "Сетевая база – это самый верный способ потерять данные".

Сложность практического использования  иерархических и и сетевых  СУБД заставляла искать иные способы  представления данных. В конце 60-х годов появились СУБД на основе инвертированных файлов, отличающиеся простотой организации и наличием весьма удобных языков манипулирования данными. Однако такие СУБД обладают рядом ограничений на количество файлов для хранения данных, количество связей между ними, длину записи и количество ее полей.

Сегодня наиболее распространены реляционные  модели, которые будут подробно рассмотрены  в главе 3.

Физическая организация данных оказывает основное влияние на эксплуатационные характеристики БД. Разработчики СУБД пытаются создать наиболее производительные физические модели данных, предлагая пользователям тот или иной инструментарий для поднастройки модели под конкретную БД. Разнообразие способов корректировки физических моделей современных промышленных СУБД не позволяет рассмотреть их в этом разделе.

Глава 2. Инфологическая модель данных "Сущность-связь"

2.1. Основные понятия

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

Сущность – любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Москва, Киев и т.д.

Атрибут – поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д. Здесь также существует различие между типом и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений:  
 
Красный, Синий, Банановый, Белая ночь и т.д., 
 
однако каждому экземпляру сущности присваивается только одно значение атрибута.

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

Ключ – минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Для сущности Расписание (п. 1.2) ключом является атрибут Номер_рейса или набор: Пункт_отправления, Время_вылета и Пункт_назначения (при условии, что из пункта в пункт вылетает в каждый момент времени один самолет).

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

2.2. Характеристика связей и язык  моделирования

При построении инфологических моделей  можно использовать язык ER-диаграмм (от англ. Entity-Relationship, т.е. сущность-связь). В них сущности изображаются помеченными прямоугольниками, ассоциации – помеченными ромбами или шестиугольниками, атрибуты – помеченными овалами, а связи между ними – ненаправленными ребрами, над которыми может проставляться степень связи (1 или буква, заменяющая слово "много") и необходимое пояснение.

Между двумя сущностям, например, А и  В возможны четыре вида связей.

Первый тип – связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В:

Студент может не "заработать" стипендию, получить обычную или  одну из повышенных стипендий.

Второй тип – связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

Квартира может пустовать, в  ней может жить один или несколько  жильцов.

Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи МНОГИЕ-К-ОДНОМУ (М:1) и МНОГИЕ-КО-МНОГИМ (М:N).

Пример 2.1. Если связь между сущностями МУЖЧИНЫ и ЖЕНЩИНЫ называется БРАК, то существует четыре возможныхпредставления такой связи:

Характер связей между сущностями не ограничивается перечисленными. Существуют и более сложные связи:

• множество связей между одними и теми же сущностями

(пациент, имея одного лечащего  врача, может иметь также несколько  врачей-консультантов; врач может  быть лечащим врачом нескольких  пациентов и может одновременно консультировать несколько других пациентов);

• тренарные связи

(врач может назначить несколько  пациентов на несколько анализов, анализ может быть назначен  несколькими врачами нескольким пациентам и пациент может быть назначен на несколько анализов несколькими врачами);

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

В приведенных примерах для повышения  иллюстративности рассматриваемых связей не показаны атрибуты сущностей и ассоциаций во всех ER-диаграммах. Так, ввод лишь нескольких основных атрибутов в описание брачных связей значительно усложнит ER-диаграмму (рис. 2.1,а). В связи с этим язык ER-диаграмм используется для построении небольших моделей и иллюстрации отдельных фрагментов больших. Чаще же применяется менее наглядный, но более содержательный язык инфологического моделирования (ЯИМ), в котором сущности и ассоциации представляются предложениями вида:

СУЩНОСТЬ (атрибут 1, атрибут 2 , ..., атрибут n)

АССОЦИАЦИЯ [СУЩНОСТЬ S1, СУЩНОСТЬ S2, ...]

           (атрибут  1, атрибут 2, ..., атрибут n)

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

Так, рассмотренный выше пример множества связей между сущностями, может быть описан на ЯИМ следующим образом:

Врач (Номер_врача, Фамилия, Имя, Отчество, Специальность)

Пациент (Регистрационный_номер, Номер койки, Фамилия,

         Имя, Отчество, Адрес, Дата рождения, Пол)

Лечащий_врач [Врач 1, Пациент M]

             (Номер_врача, Регистрационный_номер)

Консультант [Врач M,Пациент N]

            (Номер_врача, Регистрационный_номер).

Рис. 2.1. Примеры ER-диаграмм

Для выявления связей между сущностями необходимо, как минимум, определить сами сущности. Но это не простая  задача, так как в разных предметных областях один и тот же объект может  быть сущностью, атрибутом или ассоциацией. Проиллюстрируем такое утверждение на примерах, связанных с описанием брачных связей (см. пример 2.1).

Пример 2.2. Отдел записей актов гражданского состояния (ЗАГС) имеет дело не со всеми людьми, а только с теми, кто обратился с просьбой о регистрации брака, рождения или смерти. Поэтому в странах, где допускаются лишь традиционные браки, отделы ЗАГС могут размещать сведения о регистрируемых браках в единственной сущности:

Брак (Номер_свидетельства, Фамилия_мужа, Имя_мужа,

      Отчество_мужа, Дата_рождения_мужа, Фамилия_жены,

      ... , Дата_регистрации, Место_регистрации, ...),

ER-диаграмма которой приведена  на рис. 2.1,б.

Пример 2.3. Теперь рассмотрим ситуацию, когда отдел ЗАГС расположен в стране, допускающей многоженство. Если для регистрации браков использовать сущность "Брак" примера 2.2, то будут дублироваться сведения о мужьях, имеющих несколько жен (см. табл. 2.1).

Таблица 2.1

Номер свидетельства	Фамилия мужа	...	Фамилия жены	...	Дата регистрации
1-ЮБ 154745	Петухов	...	Курочкина	...	06/03/1991
1-ЮБ 163489	Петухов	...	Пеструшкина	...	11/08/1991
1-ЮБ 169887	Петухов	...	Рябова	...	12/12/1992
1-ЮБ 169878	Селезнев	...	Уточкина	...	12/12/1992
1-ЮБ 154746	Парасюк	...	Свинюшкина	...	06/03/1991
1-ЮБ 169879	Парасюк	...	Хаврония	...	12/12/1992
...	...	...	...	...	...

Дублирование можно исключить созданием дополнительной сущности "Мужья"

Мужья (Код_М, Фамилия, Имя, Отчество, Дата рождения, Место рождения)

и заменой сущности "Брак" характеристикой (см. п. 2.3) со ссылкой на соответствующее  описание в сущности "Мужья".

 

Брак (Номер свидетельства, Код_М, Фамилия жены, ...,

      Дата регистрации, ...){Мужья}.

ER-диаграмма связи этих сущностей  показана на рис. 2.1,в, а пример  их экземпляров в табл. 2.2 и  2.3.

Таблица 2.2

Код_М	Фамилия	Имя	Отчество	Год/р.	Место рожд.
111	Петухов	Альфред	Остапович	1971	г. Цапелька
112	Селезнев	Вавила	Абрамович	1973	г. Гусев
113	Парасюк	Гораций	Федулович	1972	г. Свиньин
...	...	...	...	...	...

Таблица 2.3

Номер свидетельства	Код_М	Фамилия жены	Имя жены	Дата регистрации	...
1-ЮБ 154745	111	Курочкина	Августина	06/03/1991	...
1-ЮБ 163489	111	Пеструшкина	Мариана	11/08/1991	...
1-ЮБ 169877	111	Рябова	Милана	12/12/1992	...
1-ЮБ 169878	112	Уточкина	Вероника	12/12/1992	...
1-ЮБ 154746	113	Свинюшкина	Эльвира	06/03/1991	...
1_ЮБ 169879	113	Хаврония	Руфина	12/12/1992	...
...	...	...	...	...	...

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

Сотрудники (Табельный_номер, Фамилия, Имя, ...).

Использование, рассмотренной в  примере 2.2, сущности "Брак" нецелесообразно: в "Сотрудники" уже есть фамилии, имена, отчества супругов. Поэтому создадим ассоциацию

Брак [Сотрудник 1, Сотрудник 1]