книги / Структурный подход к организации баз данных

4.2.4. Взаимосвязь «один к одному» (между двумя атрибутами)

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

Рис. 4.2. а) Взаимосвязь «один к одному» между двумя атрибутами; б) взаимосвязь «Один ко многим» между двумя атрибутами.

Имена пациентов могут совпадать, но их номера должны быть уникальными; в) взаимосвязь «многие ко многим» между двумя атрибутами

4.2.5. Взаимосвязь «один ко многим» (между двумя атрибутами)

Имя пациента и его номер существуют совместно. Пациентов с одина­ ковыми именами может быть много, но все они имеют различные номера. Каждому пациенту присваивается уникальный номер. Это означает, что данному номеру пациента соответствует только одно имя. Взаимосвязь «один ко многим» обозначается одинарной стрелкой в направлении к «одному» и двойной стрелкой в направлении ко «многим» (рис. 4.2).

4.2.6. Взаимосвязь «многие ко многим»

(между двумя атрибутами)

Несколько пациентов с одинаковыми именами могли быть проопериро­ ваны несколькими хирургами. Несколько хирургов с одинаковыми именами уогли прооперировать нескольких пациентов. Между атрибутами «имя пациента» и «имя хирурга» существует~взаимосвязь «многие ко многим». Мы обозначаем эту взаимосвязь двойными стрелками (рис. 4.2).

4.2.7. Обзор моделей данных

Иерархическая и сетевая модели данных стали применяться в системах управления базами данных в начале 60-х годов. В начале 70-х годов была предложена реляционная модель данных. Эти три модели различают­ ся в основном способами представления взаимосвязей между объектами.

Вреляционной модели данных, как показано на рис. 4.3а, объекты

ивзаимосвязи между ними представляются с помощью таблиц. Взаимосвя­ зи также рассматриваются в качестве объектов. Каждая таблица пред­ ставляет один объект и состоит из строк и столбцов. Реляционные системы управления базами данных используются в ряде университетов и исследо­ вательских лабораторий. Перечислим несколько систем-прототипов: 5У5- ТЕМ-К (1ВМ), ШОКЕ5 (Калифорнийский университет), МАСА1М5 (см.

Оо1с151ет К.С., 51гапс1 А. Ь. ТЬе М асатз Ва1а Мапа^етегй 5уз1ет.

— РгосеесПп^з о{ 1Ье 1970 АСМ-5ЮРЮЕТ, АА/огкзЬор оп Оа1;а ОезспрВоп апй Ассезз. Ыоу. 1970, р. 201) и АЭМ1Ы5 (см. Мс1п1озЬ 5., Оп11е1 Э. Эа1а Мапа^етеЫ: 1ог а Реппу а Ву1е.—Сотргйег Эещзюпз. Мау 1973). Известен также ряд коммерческих систем: (Эиегу-Ъу-Ехатр1е (1ВМ), МАСЖИМ (корп. ТутзЬаге), система МКОМ в среде МШЛЧСЗ (корп. Нопеу\уе11) и система 1ЧОМАО, разработанная компанией №1юпа1 С55. Кроме того, система АОАВАЗ (Зойшаге АО) представляет информацию аналогично реляционным системам.

Иерархическая модель данных строится по принципу иерархии типов объектов, т. е. один тип объекта является главным, а остальные, находя­ щиеся на низших уровнях иерархии,— подчиненными (см. рис. 4.5.). Меж­ ду главным и подчиненными типами объекта устанавливается взаимосвязь «один ко многим». Иными словами, для данного главного типа объекта существует несколько подчиненных типов объекта. В то же время для каж­ дого экземпляра главного объекта может быть несколько экземпляров подчиненных типов объектов. Таким образом, взаимосвязи между объекта­ ми напоминают взаимосвязи в генеалогическом древе за единственным исключением: для каждого порожденного (подчиненного) типа объекта может быть только один исходный (главный) тип объекта. Некоторые из старейших систем основаны на иерархической модели данных: система управления информацией (1М5) корпорации 1ВМ, система 5уз1еш 2000 корпорации 1п1е1 и система МАКК IV корпорации 1п1огтаИсз.

В сетевой модели данных понятия главного и подчиненных объектов несколько расширены. Любой объект может быть и главным, и подчинен­ ным (в сетевой модели главный объект обозначается термином «владелец набора», а подчиненный — термином «член набора»). Один и тот же объ­

в любом числе взаимосвязей. Можно назвать несколько распространенных

коммерческих систем управления базами данных, использующих сетевую модель данных. К ним, в частности, относятся системы: ШМ5 корпорации СиШпапе, ТОТАЬ корпорации Сшсош, ГО8/Н корпорации Нопеу\уе11, ОМ8 1100 корпорации 1Ж1УАС и система ОВМ5-10/20 корпорации

ЕцшртепГ В § 4.3, 4.4 и 4.5 подробно рассматриваются способы представления

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

4.3. РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ

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

Рассмотрим пример базы данных, показанной на рис. 4.3а. Данные в реляционной модели представляются в виде таблицы. В терминологии реляционной модели таблица, подобная представленной на рис. 4.3а, называется отношением. Чтобы не смешивать отношения с взаимосвязями между объектами, иногда мы будем называть отношение таблицей. Каж­ дый столбец в таблице является атрибутом. Значения в столбце выделяют­ ся из домена, т. е. домен суть множество значений, которые может прини­ мать некоторый атрибут. Так, домен для номера пациента составляют все четырехзначные целые положительные числа (0000, 0001, ...., 9999), однако в настоящий момент таблица ПАЦИЕНТЫ содержит только значе­ ния 1111, 1234, 2345, 4876, 5123 и 6845. Строки таблицы называются

кортежами.

Рис. 4.3а. Представление данных с помощью реляционной модели. Первичным ключом является номер пациента, т. е. номер пациента должен быть уникальным. Таблица имеет три атрибута и (в данный момент времени) шесть кортежей. Мы рассматриваем адрес пациента как единый атрибут, так как це предполагаем в дальнейшем рассматривать его компоненты (номер дома, улицу, город и штат) в отдельности

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

Таблица ХИРУРГИ (рис. 4.36) представляет объект ХИРУРГ. Табли­ ца ПАЦИЕНТ-И-ХИРУРГ на рис. 4.3в представляет взаимосвязь между

Т а б л и ц а Х И Р У Р Г И

Н о м е р

И м я

п а т е н т а

Рис. 4.36. Представление данных с помо­ щью реляционной модели. Первичным клю­ чом является номер патента хирурга

Таблица ПАЦИЕНТ-И-ХИРУРГ

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

пациентом, хирургом и датой проведения операции. Таблица на рис. 4.3г представляет объект ПРЕПАРАТ и побочный эффект от его применения.

Столбец или ряд столбцов называются возможным ключом (часто сокращенно — ключом) отношения, если его (их) значения однозначно идентифицируют строки таблицы. Основные термины реляционной модели приведены на рис. 4.3д. Вполне вероятно, что отношение имеет более одного ключа. В этом случае удобно рассматривать один из ключей в ка­ честве первичного. В отношении ПАЦИЕНТЫ, например, если задан номер пациента 1234, который является значением ключа, то и имя пациента — Мэри Джонс, и его адрес — 10, Мэйн стрит, Рай, Н.-Й. будут однозначно определены.

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

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

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

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

Для обеспечения связи между таблицами некоторые из них должны содержать общие атрибуты. Например, в таблицах ПАЦИЕНТЫ и ПАЦИЕНТ-И-ХИРУРГ имеется избыточный атрибут «номер пациента». В результате между некоторыми таблицами возникает избыточность по ключу. Однако это не обязательно приводит к физической избыточности, поскольку таблицы отражают логическое представление пользователя.

4.3.1. Достоинства модели

Простота. Пользователь работает с простой моделью данных. Он

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

Непроцедурные запросы. Поскольку в реляционной схеме понятие на­

вигации отсутствует, запросы не строятся на основе заранее определен­ ной структуры. Благодаря этому они могут быть сформулированы на непроцедурном языке.

Независимость данных. Это свойство является одним из важнейших

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

Теоретическое обоснование. Реляционная модель данных основана

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

4.3.2. Недостатки модели

Хотя в настоящее время уже существует ряд коммерческих СУБД, базирующихся на реляционной модели данных, их производительность подчас значительно ниже, чем у систем, основанных на иерархической или сетевой модели данных или использующих инвертирование файлов по нескольким ключам. Поэтому центральной проблемой, связанной с применением реляционных СУБД, остается производительность. Сможет ли СУБД, основанная на реляционной модели, обеспечить полный набор функциональных возможностей и приемлемые операционные характе­ ристики при обработке больших баз данных? Нам представляется, что повышение производительности и надежности технических средств по­ зволяют уже сегодня ответить на этот вопрос положительно.

4.4. И ЕР А Р Х И Ч ЕС К А Я М О Д ЕЛ Ь Д А Н Н Ы Х

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

Рассмотрим генеалогическое древо. Родители могут иметь одного или нескольких детей, либо вовсе их не иметь. Дети в свою очередь в бу­ дущем также могут иметь детей. Генеалогическое древо можно рас­ сматривать как иерархическую структуру, если считать, что из каждого узла удален один родитель. Терминология иерархической модели во мно­ гом использует рассмотренную аналогию.

Компоненты базы данных, основанной на иерархической модели, показаны на рис. 4.4.

4.4.1. Иерархическая древовидная структура

Иерархическая древовидная структура строится из узлов и ветвей. Узел представляет собой совокупность атрибутов данных, описываю­ щих некоторый объект. Наивысший узел в иерархической древовидной структуре называется корнем (например, руководитель предприятия). Зависимые узлы располагаются на более низких уровнях дерева. Уровень, на котором находится данный узел, определяется расстоянием от кор­ невого узла (рис. 4.5). (Иерархическое дерево представляет собой пере­ вернутое обычное дерево: корень находится наверху, а ветви растут вниз.)

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

Рис. 4.5. Узлы и ветви образуют иерархическую древовидную структуру. Узел является совокупностью атрибутов, описывающих объект. Наивысший в иерархии узел называется корневым (это главный тип объекта). Корневой узел находится на первом уровне. Зави­ симые узлы (подчиненные типы объектов) находятся на втором, третьем и т. д. уровнях

узлы, находящиеся на уровне 2, называются порожденными узла на уровне 1. Узел на уровне 1 называется исходным для узлов на уровне 2. Узлы, находящиеся на уровне 3, считаются порожденными узла уров­ ня 2, который для них является исходным, и т. д.

Иерархическая древовидная структура всегда удовлетворяет следую­ щим условиям:

1. Иерархия неизменно начинается с корн евого узл а .

2.Каждый узел состоит из одного или нескольких атрибутов, которые описывают объект в данном узле.

3.На низших уровнях могут находиться зависимые узлы. Узел, находящийся на предшествующем уровне, является исходны м для новых зави си м ы х у зл о в . Зависимые узлы могут добавляться как в вер­ тикальном, так и в горизонтальном направлении без всяких ограничений (см. рис. 4.4.). (И склю чение. На первом уровне может находиться только один узел, называемый корневым.)

4.Каждый узел, находящийся на уровне 2, соединен с одним и только одним узлом на уровне 1. Каждый узел, находящийся на уров­ не 3, соединен с одним и только одним узлом, находящимся на уровне 2,

ит. д. Поскольку между двумя узлами может существовать лишь одна дуга (соединение), дуги не нуждаются в метках.

5.Исходный узел может иметь в качестве зависимых один или несколько порожденных узлов. Если узел не имеет ни одного зависимого узла, он не является исходным.

МНОГИМ»).

6. Доступ к каждому узлу, за исключением корневого, происходит через исходный узел. Выборка каждого узла, представленного в иерар­ хии, осуществляется через его исходный узел, поскольку это в действи­ тельности отражает семантику данных. В связи с этим в иерархической модели данных пути доступа к каждому узлу являются уникальными (рис. 4.6). (Например, доступ к узлу I может осуществляться только по пути А-О-Н-1, а доступ к узлу О — только по пути А-В-О.) Поэтому иерархическая модель данных обеспечивает только линейные пути до­ ступа.

Рис. 4.6. В иерархической модели данных путь доступа к каждому узлу уникален. На­ пример, доступ к узлу I может осуществляться только по пути А-О-Н-1, а доступ к узлу О —

только по пути А-В-О. Таким образом, иерархическая модель обеспечивает лишь ли­ нейные пути доступа

7. Возможно существование любого числа экземпляров узлов каж­ дого уровня. Каждый экземпляр узла (за исключением корневого) соеди­ нен с экземпляром исходного узла, т. е. может существовать много экземпляров узла А. Каждый экземпляр узла А начинает логическую запись. Для каждого экземпляра узла А может существовать нуль, один или несколько экземпляров узла В и т. д.

Рассмотрим в качестве примера информацию, содержащуюся в от­ ношениях ПАЦИЕНТ, ХИРУРГ, ПАЦИЕНТ-И-ХИРУРГ и ПРЕПАРАТ, показанных на рис. 4.3а—г. Информация в иерархической модели дан­ ных может быть представлена различными способами. Один из вариантов показан на рис. 4.7. Корневой узел представляет объект ПАЦИЕНТ.

Рис. 4.7. Представление данных с помощью иерархической модели данных в базе данных ПАЦИЕНТ. Корневой узел представляет объект ПАЦИЕНТ. Объекты ХИРУРГ, ОПЕРА­ ЦИЯ и ПРЕПАРАТ объединены в порожденный узел

Для каждого пациента имеется экземпляр корневого сегмента. В рас­ сматриваемый момент в базе данных содержатся записи для пациентов Джона Уайта (1111), Мэри Джонс (1234), Чарльза Брауна (2345), Хола Кейна (4876), Пола Кошера (5123) и Энн Худ (6845). Экземпляр записи базы данных для Джона Уайта (1111) показан на рис. 4.8. Тип узла второго уровня, приведенный на рис. 4.7, на рис. 4.8 имеет два экземпляра. Иерархическая модель позволяет для каждого пациента представить сведения о нескольких операциях и нескольких хирургах (см. рисунок).