СУБД / УМК СУБД

атрибут. Ключ этого отношения будет составным, включающим оба эти атрибута. Для многозначных атрибутов МА4 и МА5 будут созданы отношения: R2 (И1 , МА4 ) и R3 (И1 ,МА5 ).

4.Если сущность имеет необязательный атрибут, возможны два варианта:

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

если свойством обладает малое число экземпляров, то можно выделить отношение,

включающее идентификатор и соответствующий атрибут: R4 (И1 , НА6 ). Отношение

будет содержать столько строк, сколько объектов имеет свойство.

5.Если сущность имеет составной атрибут, то возможны два варианта:

составному свойству ставится в соответствие отдельное поле;

каждому из составляющих элементов составного свойства ставится в соответствие отдельное поле.

Выбор варианта зависит от характера обработки данных. При реализации запросов проще объединить поля, чем выделить часть поля. Если предполагается использование компонентов атрибута, лучше вариант 2, иначе – вариант 1.

6.Бинарные связи один-к-одному и один-ко-многим становятся внешними ключами.

Создается копия уникального идентификатора с конца связи «один», и соответствующие столбцы составляют внешний ключ.

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

R3 (И1 , И2 , А1 , А2 ).

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

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

Причем это можно сделать в любом из отношений:

R1 (И1 , А1 , И2 )

R2 (И2 , А2 )

или

R1 (И1 , А1 )

R2 (И2 , А2 , И1 ).

65

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

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

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

R1 (И1 , А1 )

R2 (И2 , А2 )

R3 (И1 , И2 ).

7. Преобразование бинарной связи один-ко-многим (1:N) зависит только от класса принадлежности N-связной сущности. Если он является обязательным, то можно использовать два отношения (по одному для каждой сущности). В отношение для N-

связной сущности добавляется идентификатор 1-связной сущности:

R1 (И1 , А1 )

R2 (И2 , А2 , И1 ).

Если класс принадлежности N-связной сущности является необязательным, то для отображения связи создается третье отношение, которое будет содержать ключи каждой из связанных сущностей:

R1 (И1 , А1 )

R2 (И2 , А2 )

R3 (И1 , И2 ).

8. Для бинарной связи многие-ко-многим (М:N) потребуются три отношения: по одному для каждой сущности и одно дополнительное – для отображения связи между ними. Последнее отношение будет содержать идентификаторы связанных объектов. Ключ этого отношения будет составным:

R1 (И1 , А1 )

R2 (И2 , А2 )

R3 (И1 , И2 ).

9. В случае N-арной связи необходимо использовать (n+1) отношение – по одному для каждой сущности, и одно для связи. Идентификатор каждой сущности станет первичным ключом соответствующего отношения. Отношение, порождаемое связью, будет иметь среди своих атрибутов ключи каждой сущности. Если связь имеет атрибуты, то они становятся атрибутами отношения связи. Например:

R1 (И1 , А1 )

R2 (И2 , А2 )

66

R3 (И3 , А3 )

R4 (И1 , И2 , И3 , АС4 ).

10. Обобщающей сущности соответствует одно отношение, причем ключ сущности становится ключом отношения. Этому отношению приписываются общие для всех ролевых сущностей атрибуты.

Ролевые элементы и связи, их соединяющие, порождают такое число отношений,

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

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

7.2. Физические модели

Физическая модель БД определяет способ размещения данных на носителях

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

К вопросам организации данных относятся:

·выбор типа записи – единицы обмена в операциях ввода-вывода;

·выбор способа размещения записей в файле и, возможно, метода оптимизации размещения;

·выбор способа адресации и метода доступа к записям.

Стадия физического проектирования БД в общем случае включает:

·выбор способа организации БД;

·разработку спецификации внутренней схемы;

·описание отображения концептуальной схемы во внутреннюю.

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

·выбор схемы размещения данных (разделение по файлам или тип RAID-массива);

·определение числа и типа индексов (например, кластеризованный или некластеризованный в случае MS SQL Server).

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

67

таких системах не используется. Внешние схемы БД обычно конструируются на стадии

разработки приложений.

Тема 8. Case-средства разработки баз данных

ER-модели широко используются в практике создания БД. Они применяются при ручном и автоматизированном проектировании с использованием CASE-средств,

поддерживающих весь цикл разработки СБД или отдельные его стадии. К таким средствам относятся: ProKit*WORKBENCH, Design / IDEF, CASE Oracle (Designer / 2000), Power Designer (S-Designor), ERWin, SILVERRUN, ERStudio и другие. CASE-средства являются сравнительно новым направлением в информационных технологиях. Первая версия инструментария Oracle появилась в 1989 г.

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

При сравнении CASE-систем кроме используемой методологии ER-моделирования,

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

число и перечень поддерживаемых целевых СУБД;

поддержку распределенных БД;

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

построение концептуальной ER-модели по описанию структуры существующей БД – реверс-инжиниринг;

автоматизируемые функции проектирования и степень их автоматизации;

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

надежность работы;

документирование проекта;

открытость системы (возможность стыковки с другими средствами);

удобство графического редактора;

количественные ограничения (общее число сущностей, число уровней вложенности для обобщенной сущности и др.);

возможность автоматической оценки объема памяти для проектируемой БД;

68

возможность автоматической генерации процедур;

наличие средств моделирования хранилищ данных;

требования к ресурсам компьютера;

операционную среду;

стоимость системы.

CASE-средства показывают модель с разной степенью детализации:

только обозначения сущностей и связей между ними;

сущности + ключи;

сущности + ключи + внешние ключи;

сущности + все атрибуты.

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

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

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

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

Многие CASE-средства этим позволяют задавать в модели ограничения целостности и генерируют программы (триггеры, хранимые процедуры), проверяющие эти ограничения при эксплуатации БД. Кроме того, CASE-средства могут генерировать программы ведения БД.

Многие CASE-средства позволяют экспортировать модели в другие системы и,

наоборот, импортировать их из других систем.

69

8.1. Пример нотации er-модели – метод idef1x

Методики представления ER-моделей, используемые в разных литературных источниках, а также в разных CASE-системах, несколько отличаются друг от друга. В

ряде CASE-средств (ERwin, ERStudio) реализован метод IDEF1X, входящий в семейство стандартов IDEF. Метод разработан для армии США и широко используется в государственных учреждениях, финансовых и промышленных корпорациях. Он прост в изучении и обеспечивает возможность автоматизации. Позволяет построить модель данных, эквивалентную РМД, приведенной к 3НФ.

Каждой сущности присваиваются уникальное имя и номер, разделяемые косой чертой и помещаемые над блоком (рис. 27). Первичный ключ (Primary Key) – это атрибут

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

Рисунок 27. Графическое обозначение сущности в IDEF1X

В одной сущности может быть несколько потенциальных ключей (Candidate Key) –

атрибутов, претендующих на роль первичного ключа. Альтернативный ключ (Alternate

Key) – потенциальный ключ, не ставший первичным. На диаграмме обозначается AK n.m,

где n – номер ключа, m – номер атрибута в ключе. Инверсионный вход (Inversion Entries) –

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

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

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

70

Рисунок 28. Зависимая и независимая сущности Каждая сущность может обладать любым количеством связей с другими сущностями

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

другая – дочерней или сущностью-потомком.

Связиименуются глаголами или глагольными фразами, которые выражают некоторые бизнес-правила и облегчают чтение диаграмм. Связь сотрудника с заказом может быть определена следующим образом (рис. 29):

·Сотрудник выполняет один или более Заказов;

· Заказ должен выполняться ровно одним Сотрудником.

Рисунок 29. Связи на диаграмме На логическом уровне можно установить:

1)идентифицирующую связь один-ко-многим (обозначается ѕ·);

2)неидентифицирующую связь один-ко-многим (обозначается ----·);

3)связь многие-ко-многим (обозначается ·ѕ·).

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

внешние ключи (Foreign Key) (рис. 30).

Рисунок 30. Идентифицирующая связь При установлении неидентифицирующей связи дочерняя сущность не превращается в

зависимую, а ключевые атрибуты родительской сущности мигрируют в область неключевых атрибутов дочерней сущности (рис. 31).

71

Рисунок 31. Неидентифицирующая связь В случае обязательной связи при генерации схемы БД атрибут внешнего ключа

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

Мощность связи обозначает отношение числа экземпляров родительской сущности к числу экземпляров дочерней сущности. Различают случаи (рис. 32):

1)когда одному экземпляру родительской сущности соответствует 0, 1 или много

экземпляров дочерней сущности (общий случай);

2)когда одному экземпляру родительской сущности соответствует 0 или 1 экземпляр дочерней сущности (исключены множественные значения);

3)когда одному экземпляру родительской сущности соответствует один или много

экземпляров дочерней сущности (исключено нулевое значение);

4)когда одному экземпляру родительской сущности соответствует заданное число

экземпляров дочерней сущности (например, 5).

Рисунок 32. Мощность связи

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

ПОСТОЯННЫЙ СОТРУДНИК и СОВМЕСТИТЕЛЬ (рис. 33).

72

Рисунок 33. Иерархия наследования

Дискриминатор – атрибут родового предка, который показывает, как отличить одну категориальную сущность от другой. В нашем примере – это тип.

Категория является неполной, если в родовом предке могут существовать экземпляры,

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

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

Рисунок 34. Комбинация полной и неполной категорий

Отношения многие-ко-многимявляются неспецифическими для РБД. Они могут быть установлены в концептуальной (в CASE – логической) модели. На этапе создания даталогической (в CASE – физической) модели такие отношения потребуют разрешения.

CASE-средства автоматически преобразуют отношения в специфические с введением новых (ассоциативных) сущностей.

73

Неспецифическое отношение на рис. 35 указывает, что Студент может изучать много

Предметов, а Предмет может изучаться многими Студентами. Мы не можем определить, какой студент изучает какой предмет, пока не введем третью

(ассоциативную) сущность Изучение предмета. Каждый экземпляр введенной сущности связан с одним студентом и с одним предметом (рис. 36).

Рисунок 35. Отношение многие-ко-многим

Рисунок 36. Разрешение отношения многие-ко-многим

Тема 9. Требования к распределенным базам данных

Распределенная база данных (DDB – Distributed DataBase) – это совокупность множества взаимосвязанных БД, распределенных в компьютерной сети. БД распределена физически, но логически едина (имеет общую схему данных).

В системах с распределенными БД используются разные технологии распределения данных по узлам сети – фрагментация и тиражирование.

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

При использовании тиражирования в нескольких узлах сети создаются и поддерживаются в согласованном состоянии (синхронизируются) копии всей БД или ее фрагментов. Копия БД называется репликой.

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

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

– теряется при использовании тиражирования. При этом сохраняются возможности контроля целостности данных для всей системы.

74