Малков О.Б., Гегечкори Е.Т. Базы данных
Подождите немного. Документ загружается.
Уникальным идентификатором называется набор атрибутов, значения
которых в совокупности являются уникальными для каждого экземпляра
сущности. Удаление любого атрибута из идентификатора нарушает его
уникальность. Уникальные идентификаторы изображаются на диаграмме
подчеркиванием (рис. 20).
Рис. 19. Сущность с атрибутами Рис. 20. Сущность с уникальным
идентификатором
Каждая сущность может обладать любым количеством связей с другими
сущностями. Связь (Relationship) – поименованная ассоциация между
сущностями, значимая для рассматриваемой предметной области. Степенью
связи называется количество сущностей, участвующих в связи. Связь степени
2 называется бинарной, степени N – N-арной. Связь, в которой одна
сущность участвует в разных ролях, называется рекурсивной (унарной).
Один из вариантов графического изображения связи показан на рис. 21.
Рис. 21. Обозначение сущностей и связи
Пары чисел на диаграмме отражают две важные характеристики связи –
класс принадлежности (первое число) и мощность связи (второе число).
Класс принадлежности характеризует обязательность участия
экземпляра сущности в связи. Может принимать значение 0 (необязательное
участие – экземпляр сущности может быть связан с одним, несколькими или
ни с одним экземпляром другой сущности) или 1 (обязательное участие –
экземпляр сущности должен быть связан не менее чем с одним экземпляром
другой сущности). Классы принадлежности на рис. 21 означают: в каждом
отделе работает хотя бы один сотрудник, некоторые сотрудники могут не
работать в отделах (работают в цехах).
41
Мощность связи – число экземпляров сущности, участвующих в связи.
Мощность связи может быть равна 1, N или конкретному числу. Мощности
связи на рис. 21 означают: каждый сотрудник может работать не более чем в
одном отделе, а в каждом отделе может работать любое число сотрудников.
В зависимости от значения мощности связь может иметь один из трех
типов:
один-к-одному (обозначается 1:1), показана на рис. 22.
один-ко-многим (обозначается 1:N), показана на рис. 21.
многие-ко-многим (обозначается M:N), показана на рис. 23.
Рис. 22. Связь типа 1:1
Связи также могут иметь атрибуты. Чтобы узнать ставку сотрудника,
нужно знать не только его табельный номер, но и номер отдела (рис. 23).
Ставка является атрибутом обеих сущностей СОТРУДНИК и ОТДЕЛ. Это –
атрибут связи.
Рис. 23. Связь типа M:N
В связи «супертип-подтип» общие атрибуты типа определяются в
сущности-супертипе, сущность-подтип (подкласс) наследует атрибуты
супертипа. Экземпляр подтипа существует только при условии
существования экземпляра супертипа. Подтип не может иметь
идентификатора (он импортирует его из супертипа). Например, супертип
УЧРЕДИТЕЛЬ образуют подтипы ЮРИДИЧЕСКОЕ ЛИЦО и
ФИЗИЧЕСКОЕ ЛИЦО (рис. 24). Свойство, по которому проводится
разбиение, называется дискриминатором.
Существуют следующие виды идентификаторов:
первичный / альтернативный – сущность может иметь несколько
идентификаторов (рис. 25). Один должен быть основным (первичным),
другие – альтернативными. Первичный идентификатор на диаграмме
42
подчеркивается. Альтернативные идентификаторы предваряются символами
<1> для первого, <2> для второго и т. д.;
простой / составной – идентификатор, состоящий из одного
атрибута, является простым, из нескольких атрибутов – составным;
абсолютный / относительный – если атрибуты, составляющие
идентификатор, принадлежат сущности, то идентификатор является
абсолютным. Если один или более атрибутов идентификатора принадлежат
другой сущности, то идентификатор является относительным, а сущность
определяется как зависимая.
Рис. 24. Связь «супертип-подтип»
Рис. 25. Составной альтернативный идентификатор
На рис. 26 идентификатор сущности СТРОКА_ЗАКАЗА является
относительным. Он включает идентификатор сущности ЗАКАЗ, что
показывается подчеркиванием 1,1.
43
Рис. 26. Относительный идентификатор
При построении ER-модели необходимо ответить на вопросы:
что следует считать сущностью, а что – атрибутом?
когда следует делить класс на подклассы?
В качестве самостоятельного объекта следует изображать сущности:
имеющие более одного идентификатора;
для которых фиксируются какие-либо свойства;
которые участвуют более чем в одной связи.
В случае сомнений лучше принять решение о создании самостоятельного
объекта, так как это в дальнейшем потребует меньших переделок модели.
Количественные характеристики всегда являются атрибутами и никогда
– сущностями. Они никогда не являются идентификаторами и не входят в
состав идентификаторов. Следует стремиться отобразить информацию как
можно более детально. Так, например, если Адрес, ФИО являются
составными характеристиками, то желательно отразить это в модели.
Сущность-супертип следует вводить, чтобы подчеркнуть общность и
различие сущностей, входящих в один класс, или если объекты разных
подклассов участвуют в разных связях. Если для сотрудников мужского и
женского пола фиксируются одни свойства, эти объекты участвуют в одних
связях, то соответствующие подклассы выделять не следует. Если же для
мужчин фиксируются сведения о воинской обязанности, а для женщин – нет,
подклассы следует выделить.
Каждый подкласс может быть изображен в модели как самостоятельный
объект, а не как подкласс какого-то родового класса. Чтобы иметь больше
информации о предметной области и сократить число элементов (свойств,
связей) в модели, в большинстве случаев лучше объединять подклассы в
класс.
Связи устанавливаются на уровне сущностей. Нельзя устанавливать
связь между атрибутом одной сущности и другой сущностью или ее
атрибутом. Нельзя также непосредственно связывать сами связи. Подклассы
могут участвовать в связях, так же как и классы.
44
3.3. Даталогическое проектирование
Следующим шагом является выбор конкретной СУБД и отображение в
ее среду спецификаций инфологической модели предметной области. Эту
стадию называют логическим (даталогическим) проектированием БД. Ее
результатом является концептуальная схема БД, включающая определение
всех информационных единиц и связей, в том числе задание типов,
характеристик и имен.
Проектирование логической структуры РБД предполагает:
разбиение всей информации по отношениям (таблицам);
определение состава полей (атрибутов) каждого отношения;
определение ключа каждого отношения;
определение связей и обеспечение целостности по связям.
Часто при описании логической структуры РБД указывают, по каким
полям надо индексировать отношение, а для ключевых полей индексация
предусматривается автоматически. Индексация занимает промежуточное
положение между логической и физической структурой данных. Она
определяет способ логического упорядочения данных и доступ к ним, но при
этом создаются вспомогательные индексные файлы, что меняет общую
структуру БД.
Возможно несколько альтернативных вариантов отображения
инфологической модели в даталогическую. Следует учитывать влияние
следующих факторов:
1) связи предметной области могут отображаться как декларативным
путем – в логической схеме, так и процедурным – через программные
модули, обрабатывающие (связывающие) соответствующие данные.
2) существенное влияние оказывает характер обработки. Частые
обращения к совместно обрабатываемым данным предполагают их
совместное хранение, а данные, к которым обращаются редко, целесообразно
хранить отдельно.
Рассмотрим по шагам общий подход к построению РБД на основе
инфологической модели, представленной ER-диаграммой.
1. Каждая простая сущность превращается в таблицу (отношение). Имя
сущности становится именем таблицы. Каждый простой атрибут
становится столбцом таблицы с тем же именем: R
1
(И
1
, А
1
, А
2
, А
3
).
2. Компоненты уникального идентификатора сущности превращаются в
первичный ключ. Если имеется несколько возможных уникальных
идентификаторов, выбирается наиболее используемый. Учитываются также
следующие факторы:
45
длина ключа – в качестве первичного ключа выбирается, как
правило, самый короткий из вероятных ключей;
стабильность – желательно выбирать в качестве первичного ключа
атрибуты, которые не изменяются;
мнемоничность – при прочих равных условиях следует отдавать
предпочтение тем из вероятных ключей, которые легче запомнить.
Некоторые СУБД (Access, Paradox и др.) позволяют автоматически
генерировать в качестве ключа таблицы поле типа «счетчик». Этот
искусственный код можно использовать для простых объектов, если в
предметной области не предполагается применение другой системы
кодирования (ОКПО, ОКОНХ, ИНН).
Если в состав уникального идентификатора входят связи, то к числу
столбцов первичного ключа добавляется копия уникального идентификатора
сущности, находящейся на дальнем конце связи (процесс может
продолжаться рекурсивно).
3. Каждому из многозначных атрибутов ставится в соответствие
отношение, полями которого будут идентификатор, выбранный в качестве
первичного ключа, и многозначный атрибут. Ключ этого отношения будет
составным, включающим оба эти атрибута. Для многозначных атрибутов
МА
4
и МА
5
будут созданы отношения: R
2
(И
1
, МА
4
) и R
3
(И
1
, МА
5
).
4. Если сущность имеет необязательный атрибут, возможны два
варианта:
если таким свойством обладают многие экземпляры объекта, его
можно хранить как обычный атрибут в той же таблице (столбец может
содержать неопределенные значения);
если свойством обладает малое число экземпляров, то можно выделить
отношение, включающее идентификатор и соответствующий атрибут: R
4
(И
1
,
НА
6
). Отношение будет содержать столько строк, сколько объектов имеет
свойство.
5. Если сущность имеет составной атрибут, то возможны два варианта:
составному свойству ставится в соответствие отдельное поле;
каждому из составляющих элементов составного свойства ставится в
соответствие отдельное поле.
Выбор варианта зависит от характера обработки данных. При реализации
запросов проще объединить поля, чем выделить часть поля. Если
предполагается использование компонентов атрибута, лучше вариант 2,
иначе – вариант 1.
6. Бинарные связи один-к-одному и один-ко-многим становятся
внешними ключами. Создается копия уникального идентификатора с конца
связи «один», и соответствующие столбцы составляют внешний ключ.
46
Связь один-к-одному между сущностями встречается редко. Если класс
принадлежности обеих сущностей является обязательным, то для
отображения обеих связанных сущностей можно использовать одну таблицу:
R
3
(И
1
, И
2
, А
1
, А
2
).
Однако таким решением злоупотреблять не следует. Если для каждого
объекта потребуются свои связи или в запросах потребуется информация по
каждой сущности, то выбранное решение усложнит или замедлит работу с
БД.
Если для каждой сущности создаются отдельные отношения, то
информацию о связях можно отразить, включив в одно из отношений
идентификатор из другого отношения. Причем это можно сделать в любом из
отношений:
R
1
(И
1
, А
1
, И
2
)
R
2
(И
2
, А
2
)
или
R
1
(И
1
, А
1
)
R
2
(И
2
, А
2
, И
1
).
Если класс принадлежности одной из сущностей является
необязательным, то идентификатор сущности с необязательным классом
добавляется в отношение, соответствующее сущности с обязательным
классом принадлежности.
Если класс принадлежности обеих сущностей является необязательным,
то, чтобы избежать наличия пустых полей, следует использовать три
отношения: по одному для каждой сущности и одно – для отображения связи
между ними:
R
1
(И
1
, А
1
)
R
2
(И
2
, А
2
)
R
3
(И
1
, И
2
).
7. Преобразование бинарной связи один-ко-многим (1:N) зависит только
от класса принадлежности N-связной сущности. Если он является
обязательным, то можно использовать два отношения (по одному для каждой
сущности). В отношение для N-связной сущности добавляется
идентификатор 1-связной сущности:
R
1
(И
1
, А
1
)
R
2
(И
2
, А
2
, И
1
).
Если класс принадлежности N-связной сущности является
необязательным, то для отображения связи создается третье отношение,
которое будет содержать ключи каждой из связанных сущностей:
R
1
(И
1
, А
1
)
R
2
(И
2
, А
2
)
R
3
(И
1
, И
2
).
47
8. Для бинарной связи многие-ко-многим (М:N) потребуются три
отношения: по одному для каждой сущности и одно дополнительное – для
отображения связи между ними. Последнее отношение будет содержать
идентификаторы связанных объектов. Ключ этого отношения будет
составным:
R
1
(И
1
, А
1
)
R
2
(И
2
, А
2
)
R
3
(И
1
, И
2
).
9. В случае N-арной связи необходимо использовать (n+1) отношение –
по одному для каждой сущности, и одно для связи. Идентификатор каждой
сущности станет первичным ключом соответствующего отношения.
Отношение, порождаемое связью, будет иметь среди своих атрибутов ключи
каждой сущности. Если связь имеет атрибуты, то они становятся атрибутами
отношения связи. Например:
R
1
(И
1
, А
1
)
R
2
(И
2
, А
2
)
R
3
(И
3
, А
3
)
R
4
(И
1
, И
2
, И
3
, АС
4
).
10. Обобщающей сущности соответствует одно отношение, причем ключ
сущности становится ключом отношения. Этому отношению приписываются
общие для всех ролевых сущностей атрибуты.
Ролевые элементы и связи, их соединяющие, порождают такое число
отношений, которое определяется ранее описанными правилами, причем
каждая роль трактуется как обычная сущность. Связываются отношения с
помощью ключевого атрибута. Каждому значению ключевого атрибута
ролевой сущности соответствует одна запись в обобщающем отношении с
таким же значением ключа.
11. Индексы создаются для первичного ключа (уникальный индекс), а
также внешних ключей и тех атрибутов, которые будут часто использоваться
в запросах.
3.4. Физические модели
Физическая модель БД определяет способ размещения данных на
носителях (устройствах внешней памяти), а также способ и средства
организации эффективного доступа к ним. Поскольку СУБД функционирует
в составе и под управлением операционной системы, то организация
48
хранения данных и доступа к ним зависит от принципов и методов
управления данными операционной системы.
К вопросам организации данных относятся:
выбор типа записи – единицы обмена в операциях ввода-вывода;
выбор способа размещения записей в файле и, возможно, метода
оптимизации размещения;
выбор способа адресации и метода доступа к записям.
Стадия физического проектирования БД в общем случае включает:
выбор способа организации БД;
разработку спецификации внутренней схемы;
описание отображения концептуальной схемы во внутреннюю.
В отличие от ранних СУБД, многие современные системы не
предоставляют разработчику какого-либо выбора на этой стадии. Реально к
вопросам проектирования физической модели можно отнести:
выбор схемы размещения данных (разделение по файлам или тип
RAID-массива);
определение числа и типа индексов (например, кластеризованный
или некластеризованный в случае MS SQL Server).
Способ хранения БД определяется механизмами СУБД автоматически по
умолчанию на основе спецификаций концептуальной схемы БД, и
внутренняя схема в явном виде в таких системах не используется. Внешние
схемы БД обычно конструируются на стадии разработки приложений.
4. АВТОМАТИЗИРОВАННОЕ ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ
4.1. CASE-средства разработки баз данных
ER-модели широко используются в практике создания БД. Они
применяются при ручном и автоматизированном проектировании с
использованием CASE-средств, поддерживающих весь цикл разработки СБД
или отдельные его стадии. К таким средствам относятся:
ProKit*WORKBENCH, Design / IDEF, CASE Oracle (Designer / 2000), Power
Designer (S-Designor), ERWin, SILVERRUN, ERStudio и другие. CASE-
средства являются сравнительно новым направлением в информационных
технологиях. Первая версия инструментария Oracle появилась в 1989 г.
CASE-средства поддерживают концептуальное проектирование,
позволяют осуществить логическое и физическое проектирование путем
автоматической генерации БД для целевой СУБД. Но следует обратить
внимание на различия в терминологии. Во многих CASE-системах ER-
49
модель называется логической моделью, а представление логической
структуры целевой БД – физической моделью.
При сравнении CASE-систем кроме используемой методологии ER-
моделирования, необходимо учитывать специфические критерии, связанные
с реализацией функций автоматизированного проектирования:
число и перечень поддерживаемых целевых СУБД;
поддержку распределенных БД;
поддержку коллективной работы при проектировании (управление
правами пользователей, ведение репозитория и т. д.);
построение концептуальной ER-модели по описанию структуры
существующей БД – реверс-инжиниринг;
автоматизируемые функции проектирования и степень их авто-
матизации;
качество и жесткость проектных решений (возможность выбора из
нескольких альтернативных решений, возможность ручного вмешательства в
процесс);
надежность работы;
документирование проекта;
открытость системы (возможность стыковки с другими средствами);
удобство графического редактора;
количественные ограничения (общее число сущностей, число уров-
ней вложенности для обобщенной сущности и др.);
возможность автоматической оценки объема памяти для про-
ектируемой БД;
возможность автоматической генерации процедур;
наличие средств моделирования хранилищ данных;
требования к ресурсам компьютера;
операционную среду;
стоимость системы.
CASE-средства показывают модель с разной степенью детализации:
только обозначения сущностей и связей между ними;
сущности + ключи;
сущности + ключи + внешние ключи;
сущности + все атрибуты.
Наличие таких возможностей создает существенные удобства, особенно
при создании больших и сложных моделей.
Важной характеристикой CASE-средств является возможность получать
подмодели из общей модели и обеспечивать интеграцию фрагментов в
единую модель. Эти возможности могут быть полезны не только при
50