На данной диаграмме каждая сущность представляет собой таблицу базы данных, каждый атрибут становится колонкой соответствующей таблицы. Обращаем внимание на то, что во многих таблицах, например, "CUST_DETAIL" и "PROD_IN_SKLAD", соответствующих сущностям "Запись списка накладной" и "Товар на складе", появились новые атрибуты, которых не было в концептуальной модели - это ключевые атрибуты родительских таблиц, мигрировавших в дочерние таблицы для того, чтобы обеспечить связь между таблицами посредством внешних ключей.
Реальным средством моделирования данных является не формальный метод нормализации отношений, а так называемое семантическое моделирование.
В качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER - Entity-Relationship).
Диаграммы сущность-связь позволяют использовать наглядные графические обозначения для моделирования сущностей и их взаимосвязей.
Различают концептуальные и физические ER-диаграммы. Концептуальные диаграммы не учитывают особенностей конкретных СУБД. Физические диаграммы строятся по концептуальным и представляют собой прообраз конкретной базы данных. Сущности, определенные в концептуальной диаграмме становятся таблицами, атрибуты становятся колонками таблиц (при этом учитываются допустимые для данной СУБД типы данных и наименования столбцов), связи реализуются путем миграции ключевых атрибутов родительских сущностей и создания внешних ключей.
При правильном определении сущностей, полученные таблицы будут сразу находиться в 3НФ. Основное достоинство метода состоит в том, модель строится методом последовательных уточнений первоначальных диаграмм.
В данной главе, являющейся иллюстрацией к методам ER-моделирования, не рассмотрены более сложные аспекты построения диаграмм, такие как подтипы, роли, исключающие связи, непереносимые связи, идентифицирующие связи и т.п.
В соответствии с основными этапами проектирования базы данных после построения концептуальной модели выбирается система управления базой данных, с помощью которой будет организована база данных и работа с ней. Каждая СУБД поддерживает определенные виды и типы данных, а также средства представления связей между данными, составляющими модель данных СУБД. Вторая стадия проектирования базы данных состоит в представлении построенной на предыдущей стадии концептуальной модели средствами модели данных СУБД или в отображении концептуальной модели в модель данных СУБД. Этот этап часто называют логическим проектированием базы данных. Полученная при этом модель часто также называется концептуальной моделью или схемой (но специфицированной к понятиям модели данных СУБД). В некоторых источниках полученную модель называют логической структурой данных или моделью данных базы данных. Можно по-разному характеризовать понятие модели данных СУБД. С одной стороны, модель данных СУБД – это способ структурирования данных, которые рассматриваются как некоторая абстракция в отрыве от предметной области. С другой стороны, модель данных СУБД– это инструмент представления концептуальной модели предметной области и динамики ее изменения в виде базы данных.
Учитывая обе вышеуказанные стороны, определим основные структуры моделей данных СУБД, используемые для представления концептуальной модели предметной области (сущностей, атрибутов, связей).
Элемент данных (поле) – наименьшая поименованная единица данных. Используется для представления значения атрибута.
С элементом данных неразрывно связано понятие «тип данных», который может принимать соответствующее поле. В разных СУБД могут использоваться разные типы данных, наиболее распространенными из которых (используемые во многих СУБД) являются следующие: числовой (numeric), символьный (char), дата (date) и т.д.
Запись – поименованная совокупность полей. Используется для представления совокупности атрибутов сущности (записи о сущности).
Экземпляр записи – запись с конкретными значениями полей.
Первичный ключ – минимальный набор полей записи, однозначно идентифицирующих экземпляр записи файла.
Файл – поименованная совокупность экземпляров записей одного типа. Используется для представления однородного набора сущностей.
Набор файлов – поименованная совокупность файлов, обрабатываемых в системе. Используется для представления нескольких наборов сущностей.
Введем понятие «группа», обобщающее понятия «файл» и «запись».
Группа – это поименованная совокупность элементов данных или элементов данных и других групп.
Важнейшим понятием концептуальной модели является понятие связи между сущностями (наборами сущностей). В моделях данных СУБД соответствующее понятие отражается понятием «групповое отношение».
Групповое отношение – поименованное бинарное отношение, заданное на двух множествах экземпляров рассматриваемых групп. По характеру бинарных связей различают групповые отношения вида 1:1, 1:M, M:1, M:N. Пары чисел называют коэффициентами группового отношения. В групповом отношении один член группы назначается владельцем отношения, другой – членом.
База данных – поименованная совокупность экземпляров групп и групповых отношений.
Для представления группового отношения используется две формы:
а) Графовая. Группы изображаются вершинами графа, связи между группами – дугами, направленными от группы-владельца к группе-члену с указанием имени отношения и коэффициента.
По типу графов различают:
• иерархическую модель (граф без циклов – дерево);
• сетевую модель (ориентированный граф общего вида).
б) Табличная. Связь между группами изображается таблицей, столбцы которой представляют ключи соответствующих групп. Для формального описания таблицы используется математическое (теоретико-множественное) понятие отношения. Соответствующая модель данных называется реляционной моделью.
Модель данных СУБД описывается следующим образом:
• определены возможные типы и характеристики логических структур данных (полей, записей, файлов);
• заданы правила составления структур более общего типа из структур более простых типов (например, записей из полей, файлов из записей и т.д.);
• определен способ представления связей (отношений) между файлами и записями) с помощью дополнительных полей ;
• определены возможные действия над структурами и правила их выполнения, включающие:
- основные элементарные операции над данными;
- обобщенные операции (процедуры);
- средства контроля относительно простых условий корректности операций добавления, обновления или удаления данных (ограничения), реализуемые автоматически запускаемыми при выполнении вышеуказанных операций специальными процедурами (триггерами);
- средства контроля сколь угодно сложных условий корректности выполнения определенных действий (правила);
- специальный класс процедур (триггеры).
В качестве основных элементарных операций обычно рассматриваются следующие: поиск записи с заданным значением ключа, чтение нужной записи, добавление записи, корректировка, удаление. В моделях данных СУБД также предусматриваются специальные операции для установления групповых отношений.
Обобщенные операции или процедуры – последовательность операций, реализующая определенный алгоритм обработки данных. Процедуры могут инициироваться СУБД автоматически, а также могут запускаться пользователем. Примерами процедур являются процедуры копирования БД, восстановления БД, процедуры, вычисляющие значения определенных атрибутов в БД по значениям других атрибутов, и т.п.
Средства контроля используются для реализации ограничений целостности концептуальной модели. Простейшие средства контроля – ограничения – используются для реализации как внешних ограничений концептуальной модели, так и внутренних ограничений модели данных. В качестве последних ограничений, в частности, реализованы ограничения на ввод данных несоответствующего типа, несоответствующей характеристики (по числу битов, по числу полей, по количеству записей и т.п.). Более сложные средства контроля (правила) позволяют вызывать выполнение определенной последовательности операций (сколь угодно сложной) при изменении или добавлении данных в БД и тем самым реализовывать ограничения целостности, описанные с помощью специальных конструкций.
Построение модели данных базы данных (отображение концептуальной модели в модель данных СУБД) После первой стадии концептуального проектирования у нас сформировано обобщенное представление пользователей о данных, как правило, представленное в виде ER- диаграммы. На следующей стадии (после того, как выбрана определенная СУБД с конкретной моделью данных) необходимо записать концептуальную схему в терминах и понятиях выбранной СУБД. На этой стадии каждая сущность концептуальной модели описывается как запись, состоящая из полей. Каждый атрибут описывается как поле с типом и характеристиками, возможными в выбранной СУБД. Описываются связи концептуальной модели в понятиях, соответствующих выбранной СУБД, определяется порядок реализации запросов пользователей к базе данных с помощью типовых операций СУБД и т. д.
Результатом этой стадии проектирования будет концептуальная модель, специфицированная к конкретной СУБД.
