Модели, богатые семантикой, используют на начальных стадиях разработки баз данных потому, что ни одна из поддерживаемых СУБД моделей данных не обеспечивает полного представления семантики предметной области и решаемых задач. Так, в реляционной модели данных, которую мы будем изучать в лекции 4, невозможно задание декларативных ограничений целостности кроме первичных, уникальных и внешних ключей. Описание процедурных ограничений вообще лежит вне этой модели.
Рассматриваемая ниже модель "сущность-связь" (ER-диаграммы, ER-модель) — это частный случай моделей данных богатых семантикой. Она позволяет описывать семантику, предназначенную для использования человеком. То есть можно вводить описания не реализуемые программно. С другой стороны, в ней фиксируются метаданные и ограничения целостности, используемые для создания скриптов, генерирующих схему базы.
Что хранят базы данных? Конечно же, данные. Однако, даже для организации хранения данных приходится учитывать связанные с ними смыслы. Так, в предыдущем разделе описывался первичный ключ, который не позволяет дублировать записи в наборе. Это свойство определяет частный смысл набора записей с первичным ключом. Типы данных, домены, метаданные определяют другие смыслы хранящихся данных.
Но если в базе хранятся только данные, то, как же хранятся смыслы? Прежде всего, смыслы —это тоже данные, связанные с теми данными, смысл которых они представляют.
Выделим следующие виды смыслов:
Как проявляется активность внутренних смыслов? Пусть имеется первичный ключ. Вы хотите записать запись в набор. Однако, СУБД сначала сделает то, что вы не просили — проверит допустимость вводимого значения ключа, — и только если это значение отсутствует, занесет запись.
Пример смысла третьего типа: Имеется таблица, содержащая оценки всех студентов по всем дисциплинам. Можно ли вычислить средний балл? Конечно. Однако, если вы знакомы со шкалами измерений, то вы знаете, что измерения успеваемости проводятся в шкале порядка. В ней средний балл смысла не имеет, или, говоря официальным языком, является неадекватной статистикой.
На начальной стадии создания приложения (анализ бизнеса) необходимо иметь модель предметной области, обеспечивающую неформальное описание всех значимых особенностей задачи известных постановщику. При этом отбрасывание деталей, которые "не ложатся" на модели данных, применяемые на стадии реализации проекта, может привести к существенному искажению постановки задачи. На этапе анализа полноту сведений следует предпочесть возможности их формального описания.
Семантическими принято называть модели, обеспечивающие представление семантики данных. Как и другие модели, они могут включать структурную, манипуляционную и целостную части. Однако, учитывая, что какая-то семантика имеется в любой модели, можно считать семантическими те модели, в которых семантики больше, чем в "несемантических" моделях, содержащих мало семантики. Данное псевдоопределение весьма расплывчато. Но пока нам этого достаточно.
В рамках семантической модели создается концептуальная схема базы данных, которая обычно вручную или автоматизировано (но не автоматически) преобразуется в схему базы, допустимую в рамках моделей данных, реализуемых на следующих стадиях жизненного цикла проекта — проектировании, разработки и сопровождения.
Детально семантика данных будет рассмотрена в лекции двенадцатой лекции учебника.
Самая известная семантическая модель "сущность-связь" ("entity-rela-tionship" — ER) была предложена Питером Пин Шен Ченом (Peter Chen) в 1976 году.
Семантические модели выполняются в виде диаграмм, предназначенных для человека, удобных для восприятия человеком. В современной науке вообще и в компьютерных науках в частности, большое и заслуженное внимание уделяется когнитивным аспектам. В рамках баз данных это означает выделение двух основных действующих лиц — человека и программы — и разработку естественных, удобных для человека моделей, языков, интерфейсов и алгоритмов работы пользователя. Естественно, необходимо учитывать предварительную профессиональную подготовку пользователя, определяющую, наряду с бытовыми знаниями, ментальный мир человека, набор образов (гештальтов), которыми он оперирует. Почему мы ожидаем головное меню в верхней части окна? Только потому, что нас к этому приучили разработчики некоторых успешных программных продуктов.
В соответствии с подходом Питера Чена, изложенным в основополагающей работе по диаграммам "сущность-связь", выделим четыре уровня представления моделей данных, несколько изменив их определения:
Забегая вперед, заметим, что реляционная модель относится к уровням 2 и 3. Сетевая и иерархическая модели, в том виде как они существовали 20 лет назад, работают в основном на уровне 3 и 4. UML —это уровни 1, 2 и 3, но UML далеко выходит за рамки описания данных. Модель "сущность-связь" работает на уровнях 1 и 2.
Сущность —это понятие, концепт, воображаемый объект, для которого у человека может быть создан четко отделяемый образ. Сущность задает некоторый набор объектов описываемого мира, в том числе процессов или атрибутов других объектов. Важно понимать, что сущность похожа на тип, но не на экземпляр. В дальнейшем мы будем говорить о типах сущностей, хотя употребление термина "тип" применительно к сущностям не совсем корректно. На ER-диаграммах сущность представляется прямоугольником, в котором обязательно указывается имя сущности. Дополнительно можно указывать примеры экземпляров сущности (рисунок 2.1). Примеры предназначены для человека, и позволяют с самого начала как-то ограничить множество экземпляров входящих в тип сущности.
(рис 2.1) Сущность
С каждым типом сущности можно связать предикат, проверяющий принадлежность экземпляра сущности набору сущностей. При определении типа сущности необходимо гарантировать, что экземпляры сущности различимы. Это требование аналогично требованию отсутствия записей-дубликатов или кортежей в реляционных отношениях, которые будут рассматриваться в лекции 4. Предикат, соответствующий сущности имеет вид: имя_сущности (список_атрибутов). Для моделей физического уровня задают еще типы атрибутов. Таким образом, сущности в ER-моделях определяются как минимум именем и списком атрибутов. В пределах одной сущности не может быть двух экземпляров с одинаковыми значениями атрибутов.
Связь —это типовое понятие, устанавливающее правила связывания сущностей. Каждый экземпляр типа связи устанавливается между экземплярами типов сущностей. Может существовать рекурсивная связь между типом сущности и им самим (как бы его дубликатом).
Пока рассматриваем только бинарные связи, устанавливаемые между двумя типами сущностей. В нотации Чена их обозначают сплошной линией. О связях с большей арностью поговорим позднее.
Концы бинарной связи в ER-модели характеризуются:
Обозначения и примеры связей в первоначальной нотации, предложенной П. Ченом, приведены на рисунке 2.2
(рис 2.2) Связи в нотации П. Чена
Для представления некоторых тонкостей наряду с нотацией П. Чена воспользуемся модифицированной нотацией Р. Баркера (рисунок 2.3). Будем изображать связь ненаправленной линией, соединяющей две разных сущности или сущность с собой. Обязательный конец связи будем представлять сплошной линией, а необязательный конец - штриховой линией. Неразветвленный конец линии обозначает степень 1. "Воронья лапка" означает степень "ко многим". Степень конца связи может быть уточнена. Так, указание 2..4 означает, что степень этого конца связи от 2 до 4 включительно.
Обязательность связи определяет, любой ли экземпляр сущности участвует в некотором экземпляре связи.
Примеры типов связей приведены на рисунке 2.3. Слева изображена связь, которую следует читать в двух направлениях так:
Справа пример рекурсивной связи, которую следует читать так:
Для правильного прочтения связей следует помнить, что обязательность, обозначенная типом линии (сплошная или прерывистая) связана только со "своим" именем роли. Тип линии другого конца связи значения не имеет.
(рис 2.3) Примеры типов связей
Обратите внимание на то, что чрезмерная краткость описания ролей в примере вызывает трудности в установлении смысла связи.
Задание уточнений степени конца связи определим на примерах:
n означает, что в каждом экземпляре связи участвует ровно п экземпляров сущности;Атрибут —это свойство сущности или связи, получаемое путем наблюдения или измерения. Информацию об экземпляре сущности выражают набором пар "атрибут — значение", как например на рисунке 2.4:
(рис 2.4) Пара "атрибут" — значение
Пример множественного значения. В анкете предлагается подчеркнуть один или несколько предусмотренных ответов в качестве значения атрибута. Заполненная строка выглядит так: "Как часто вы занимаетесь базами данных (нужное подчеркнуть): часто, редко, довольно часто, довольно редко, по настроению, в дождливую погоду".
Значения атрибутов обычно принадлежат одному типу, но возможны бестиповые атрибуты.
Связи также имеют атрибуты. Выделим две их разновидности:
Пример: Сущности "Работник" и "Проект" со связью "Проект — Работник", содержащей атрибуты связи "Номер_работника", "Номер_проекта" и атрибут свойства связи "Ресурс_времени". Последний атрибут эмерджентный. Его смысл: планируются затраты времени работника на работу в рамках указанного проекта.
На рисунке 2.5 приведено графическое обозначение атрибутов и пример несложной ER-диаграммы. Названия ключевых атрибутов подчеркнуты. Обратите внимание, даже простая диаграмма воспринимается плохо. Причина по-видимому в том, что в ней не создается образ, отражающий агрегирован-ность атрибутов в сущность. Сравните это изображение с хорошо выстроенной эквивалентной диаграммой ERwin на рисунке 2.14.
(рис 2.5) Пример ER-диаграммы с атрибутами
Ранее мы установили, что каждой сущности соответствует предикат вида: имя_сущности(список_атрибутов). Давайте выясним подробности. Могут ли атрибуты отсутствовать? И как в этом случае определять свойства сущности? Вспомните из философии пару концептов "материя — сознание" для которых весьма затруднительно назвать атрибуты. Их свойства выясняются через отношения, в которые они входят. Вряд ли в практике вы встретите подобные сущности, однако, полезно понимать, что связи могут существенно пополнить описание сущности и что возможны сущности без атрибутов, характеризуемые только своими связями.
Связям может быть поставлен в соответствие предикат вида: имя_связи (список_атрибутов_привязки, список_эмерджентных_атрибутов).
В свою очередь, атрибутам соответствует одноместный предикат: имя_атрибута(значение_атрибута).
Трудно поверить, но разделение на сущности, связи и атрибуты условно. Пример: то, что студент должен относиться к какой-нибудь учебной группе, можно выразить через связь (рисунок 2.6, а), введением пары атрибутов "Группа" и "Состав", обозначающих концы связи (рисунок 2.6, б), и заданием отдельной сущности "состав группы"(рисунок 2.6, в)
Вместе с тем, в практике всегда существуют предпочтительные варианты разделения на сущности, связи и атрибуты.
Еще одна проблема для начинающих — сущности, которые являются процессами, а не предметами, вещами. Вы должны были столкнуться с их аналогами при изучении классов в объектном программировании.
(рис 2.6) Условность разделения на сущности, связи и атрибуты
Уже говорилось, что связи вида "многие-ко-многим" (n:m) могут появляться в концептуальных моделях, но современные базы данных обычно не способны их реализовать. Поэтому необходимо перестроить связи n : m, выражая каждую через две связи вида "один-ко-многим". Рисунок 2.7 поясняет, как из связи "многие-ко-многим" получаются две связи "один-ко-многим".
(рис 2.7) Преобразование связи n : m в две связи n : 1 и 1 : m
Исходные сущности примера содержат множества экземпляров {1,2,3, 4,5} и {а, 6, с}. Линии показывают связи между экземплярами. Вводим ассоциированную сущность. Рисуем связи между исходными сущностями и вспомогательную вертикальную линию так, чтобы не было пересечений трех линий. Тогда точки пересечения связей с вертикальной линией соответствуют экземплярам фиктивной сущности и если, например, экземпляр "1" соединен с экземпляром "а", то получаем экземпляр фиктивной сущности "1а". Если для исходных двух сущностей имелась связь "многие-ко-многим" , то в итоге получили две связи "один-ко-многим" (от ассоциативной сущности к имевшимся). Ассоциативная сущность должна иметь имя. Его можно образовать просто соединяя имена исходных сущностей.
Содержательный пример преобразования связей n : m будет приведены ниже.
К сожалению, вам придется пользоваться пробной версией программного продукта, который менял свое имя и собственника раз пять. В свое время он назывался ERwin, а сейчас называется All Fusion Data Modeler. Опыт показывает, что при его использовании скорость разработки схемы базы увеличивается на порядок.
ERwin создает графическую документацию в стандарте IDEF1X , что очень удобно. По ER-диаграммам в процессе прямого инжиниринга генерируется скрипт, то есть текст, который позволяет создать базу данных для любой из двух десятков наиболее распространенных СУБД. По скрипту ERwin позволяет построить диаграмму. Этот процесс называется обратным инжинирингом.
Сведения по установке и запуску ERwin приведены на сайте книгиwww.database-model-lang-struct-semantic.ru.
Диаграммы могут быть созданы на двух уровнях —физическом и логическом. Поэтому после выбора в головном меню пути "File > New" лучше выбрать вариант "Logical/Physical". На рисунке 2.8 приведена панель ERwin, в которой создана логическая модель сущности.
(рис 2.8) Задание сущности
Установка кириллических шрифтов для обозначения имен сущностей, атрибутов и отношений показана на рисунке 2.9 Используется путь "Format > Default Fonts Colors". Выполните ее обязательно, чтобы установить кириллические шрифты. Не забывайте указывать, что установки предназначены для всех объектов базы (All Objects).
(рис 2.9) Установка шрифтов
На рисунке 2.10 приведена центральная часть верхней панели инструментов, на которой имеется текстовое окно для указания уровня модели, а правее и ниже его — основные объекты, переносимые в проект, — сущность, связь "категория", связь идентифицирующая, связь "многие-ко-многим" и связь неидентифицирующая.
(рис 2.10) Часть панели инструментов ERwin
В отличие от ER-диаграмм сущности в ERwin представляются прямоугольниками, внутри которых помещаются имена сущностей, записываемые именами существительных в единственном числе. Изображение каждой сущности разделяется горизонтальной линией на верхнюю часть (ключевую область), в которой расположены ключевые атрибуты (поля) (первичные ключи (РК) и, может быть, внешние ключи (Foreign Key — FK)), и нижнюю часть (область данных), где расположены неключевые атрибуты и, может быть, атрибуты внешних и альтернативных (АК) ключей.
Экземпляр идентифицируется значением первичного ключа. Других способов выделения записей в ER-диаграммах нет. Первичный ключ не должен изменяться со временем. При изменении ключа, меняется экземпляр сущности. Например, не желательно в состав ключа вводить фамилию, так как в определенных обстоятельствах женщины имеют склонность изменять фамилию. Желательно найти такие идентификаторы, которые со временем не изменятся.
Свойства первичного ключа:
Уникальные ключи (Unique Key —UK) отличаются от первичных тем, что в них могут использоваться неопределенные значения NULL.
Внешние ключи связывают сущности. Обнаружив связь, ERwin может передать ключ (набор ключевых атрибутов) в область ключей или область данных дочерней сущности. Переданные атрибуты будут внешними ключами. Атрибуты, перемещающиеся в другие сущности, называют мигрирующими.
Для установки вида изображения сущности используется меню "For-mat > Entity Display". Пример записи определений (Definition), примечаний (Note и Note2) и свойств, определенных пользователем (путь User Defined Properties > UDP) показан на рисунке 2.11.
(рис 2.11) Задание определения
UDP может использоваться для выполнения некоторых действий, например, содержать данные, необходимые для оценки. Заметки могут делаться по разным поводам. Они никак не участвуют в создании скрипта генерирующего базу.
Связи между сущностями обозначаются линиями, может быть, снабженными дополнительными символами на концах. Для создания связи необходимо подхватить ее в панели инструментов, а затем последовательно кликнуть левой кнопкой мыши на связываемых сущностях. Порядок обхода сущностей важен.
Существуют два типа связей — идентифицирующая и неидентифициру-ющая. Первая изображается сплошной линией (рисунок 2.12, сущности 3 и 4). Допустим, есть сущность, которая вне какой-то другой сущности не имеет смысла. Например, номер телефона без привязки к человеку практически бесполезен. В этом случае используют идентифицирующую связь. Обратите внимание на то, что изображение сущности 4 после связи с сущностью 3 изменилось. Появились скругленные углы. Это означает, что сущность 4 считается слабой. Чуть позже мы уточним смысл этого наименования.
(рис 2.12) Связи сущностей
Связь между сущностями 5 и 6 неидентифицирующая.
Связи именуются глаголами, которые показывают, как соотносятся сущности между собой. В простых схемах имена связей могут не назначаться и не проставляться.
В примере, изображенном на рисунке 2.13 на логическом уровне создаем две сущности "Работник" и "Отдел". Соединяем их идентифицирующей связью от отдела к работнику и обнаруживаем, что изображение сущности "Работник" поменялось.
(рис 2.13) Две сущности, соединенные идентифицирующей связью
Прямоугольником изображается сильная сущность. Предполагается, что отделы существуют сами по себе, а работники закреплены за отделами. Но в жизни могут быть и другие ситуации. Например, когда сотрудник закреплен за двумя отделами или директор не должен относиться ни к какому отделу.
В примере на рисунке 2.13 связь идентифицирующая. "Состоит из / работает в" — это роли сущностей в этой связи. Роль отдела — "состоит из", роль сотрудника — "работает в". Желательно именовать связи как можно проще и точнее, иначе легко запутаться.
Как вы знаете, связи вида "многие-ко-многим" в СУБД не реализуются. Поэтому необходимо их преобразовать в наборы связей "один-ко-многим". Достаточно создать ассоциированную сущность, у которой первичный ключ содержит только ключи соединяемых сущностей. Эти ключи будут еще и внешними ключами, обеспечивающими связи с сущностями, из которых они взяты.
Рассмотрим пример связи сущностей "Потребитель" и "Копия фильма" (рисунок 2.14). Один человек смотрит много фильмов и один фильм может просматриваться многими людьми.
(рис 2.14) Связь "многие-ко-многим"
На рисунке 2.15 показан первый шаг автоматического преобразования связи. В ERwin кликаем правой кнопкой мыши по связи. Появляется меню, в котором следует выбрать позицию "Create Association Entity" — создать ассоциированную сущность.
(рис 2.15) Преобразование связи "многие-ко-многим"
Появится сущность со странным названием составленным из кусков названий связываемых сущностей (рисунок 2.16). Получилось две связи один-ко-многим, которые реализуются в СУБД.
(рис 2.16) Преобразованная связь
Название ассоциированной сущности можно (и часто нужно) исправить.
Уточним понятия сильной и слабой сущности.
Может оказаться, что в первичный ключ сущности необходимо включить внешний ключ. Такая сущность называется слабой или зависимой.
Допустим, у нас есть никак не связанные команды и игроки. Пусть распределение игроков по командам несущественно. Это один подход. При втором подходе считается, что игрок — это всего лишь член некоторой команды. Если это так, то кроме его личного идентификатора, необходимо указать, к какой команде он относится. Сущность "Игрок" зависима от сущности "Команда". потому, что без указания команды игрока не выделишь однозначно.
Создадим две независимые сущности "Команда" и "Игрок" (рисунок 2.17):
(рис 2.17) Независимые сущности
Установление идентифицирующей связи определяет сущность "Игрок" как слабую, то есть зависимую (рисунок 2.18).
(рис 2.18) Идентифицирующая связь
При соединении идентифицирующей связью сущностей "Команда" и "Игрок", во-первых, изменяется изображение сущности "Игрок", появляется изображение этой связи, и, во-вторых, ключевой атрибут команды, мигрирует в сущность "Игрок".
Теперь рассмотрим случай, когда команды и игроки независимы. Выбираем неидентифицирующую связь (рисунок 2.19). Обратите внимание, что форма сущности "Игрок" осталась прежней (без скругления), а идентификатор из "Команды" мигрировал уже в неключевую область "Игрока".
(рис 2.19) Неидентифицирующая связь
Сейчас важно понимать, что, рассуждая о миграциях ключей, мы выходим за пределы базы данных, оперируем смыслами, извлеченными из модели бизнеса. Выясняем, как связаны команда и игрок.
В базах данных есть много вещей, с которыми разобраться невозможно, если не использовать сведения из бизнеса. Дело в том, что база данных что-то из модели бизнеса отображает, а что-то — нет. Если вы не умеете или не хотите разбираться с бизнесом, то база данных у вас получится не вполне адекватной модели бизнеса.
Потенциальные ключи, не использующиеся как первичные, могут быть определены как альтернативные ключи и записаны в секции данных модели с символом (AKn.m), где n.m — номер альтернативного ключа в формате "номер_сущности". "номер_ключа", AK означает — альтернативный ключ (alternate key).
Допустим, нас устраивает "Номер потребителя" в качестве первичного ключа. Если все потребители имеют ИНН, то он тоже может быть ключом. Мы не используем его как ключ, но помечаем как альтернативный (рисунок 2.20).
(рис 2.20) Альтернативный ключ
Зачем нужны альтернативные ключи? ИНН трудно запоминается, но не исключено, что когда-нибудь вам придется искать потребителя по ИНН.
Отметим, что в реализациях на первичный, альтернативный и уникальный ключи обычно создается индекс. Индексы иногда (далеко не всегда) ускоряют поиск, но из-за необходимости перестраивания индекса всегда замедляются вставка, обновление и удаление записей. Если обозначим ИНН как альтернативный ключ, то при создании базы данных на него система сама построит индекс. Если вы никогда не будете производить поиск по этому столбцу, то значит вы перетяжелили базу, дали ей лишнюю нагрузку.
Если вы хотите отрисовывать пиктограммы ключей, то:
Модели "сущность-связь" позволяют по модели бизнеса быстро построить схему базы данных. Все начинается с описания бизнес-процессов. Затем к ним привязывают обеспечивающие структуры данных или документов, описываемые ER-диаграммами.
Помните, что самые дорогие ошибки — это ошибки анализа бизнеса. Если что-то существенно не доделано, то не исключено, что работу по созданию базы придется просто выбросить и заново поставить задачу.
Можно, конечно, использовать гибкие методы разработки и на каждом следующем шаге уточнять задание, но этому еще нужно научиться. Во всяком случае, начинать освоение баз данных с использованием эволюционных методов разработки не следует.
Инструментальная поддержка модели "сущность-связь" дает хорошую графическую документацию для логической и физической схем базы. Более того, для самых распространенных баз, основанных на реляционной модели данных (лекция 4), по схеме можно сгенерировать скрипт на языке SQL, создающий схему базы. Эта операция называется прямым инжинирингом. Она выполняется только для диаграмм физического уровня. Обратный инжиниринг — это создание графического изображения модели по скрипту, создающему схему.
На рисунке 2.21 показан скрипт создания базы, сгенерированный по схеме рисунка 2.19 представленной на физическом уровне. В ERwin для выполнения прямого инжиниринга необходимо в головном меню выбрать позицию Tools, затем Forward Engeneer / Scheme Generation. Если в появившейся панели выбрать Preview, появится текст скрипта.
(рис 2.21) Прямой инжиниринг
После изучения языка SQL (лекция 8) текст будет легко читаться, но и сейчас понятно, что создаются две таблицы со столбцами, полученными из атрибутов исходных сущностей.
Смыслы (раздел 2.1.1)
(рис 2.22) Смыслы
Диаграмма сущность-связь (раздел 2.2.1)
(рис 2.23) Диаграмма сущность-связь
Связь (разделы 2.2.3 и 2.2.6)
(рис 2.24) Связь
Ключ (разделы 2.2.5 и 2.2.7)
(рис 2.25) Ключ
Сильные и слабые сущности (раздел 2.2.7)
(рис 2.26) Сильные и слабые сущности
Модели, богатые семантикой, используют на начальных стадиях разработки баз данных потому, что ни одна из поддерживаемых СУБД моделей данных не обеспечивает полного представления семантики предметной области и решаемых задач. Так, в реляционной модели данных, которую мы будем изучать в лекции 4, невозможно задание декларативных ограничений целостности кроме первичных, уникальных и внешних ключей. Описание процедурных ограничений вообще лежит вне этой модели.
Рассматриваемая ниже модель "сущность-связь" (ER-диаграммы, ER-модель) — это частный случай моделей данных богатых семантикой. Она позволяет описывать семантику, предназначенную для использования человеком. То есть можно вводить описания не реализуемые программно. С другой стороны, в ней фиксируются метаданные и ограничения целостности, используемые для создания скриптов, генерирующих схему базы.
Что хранят базы данных? Конечно же, данные. Однако, даже для организации хранения данных приходится учитывать связанные с ними смыслы. Так, в предыдущем разделе описывался первичный ключ, который не позволяет дублировать записи в наборе. Это свойство определяет частный смысл набора записей с первичным ключом. Типы данных, домены, метаданные определяют другие смыслы хранящихся данных.
Но если в базе хранятся только данные, то, как же хранятся смыслы? Прежде всего, смыслы —это тоже данные, связанные с теми данными, смысл которых они представляют.
Выделим следующие виды смыслов:
Как проявляется активность внутренних смыслов? Пусть имеется первичный ключ. Вы хотите записать запись в набор. Однако, СУБД сначала сделает то, что вы не просили — проверит допустимость вводимого значения ключа, — и только если это значение отсутствует, занесет запись.
Пример смысла третьего типа: Имеется таблица, содержащая оценки всех студентов по всем дисциплинам. Можно ли вычислить средний балл? Конечно. Однако, если вы знакомы со шкалами измерений, то вы знаете, что измерения успеваемости проводятся в шкале порядка. В ней средний балл смысла не имеет, или, говоря официальным языком, является неадекватной статистикой.
На начальной стадии создания приложения (анализ бизнеса) необходимо иметь модель предметной области, обеспечивающую неформальное описание всех значимых особенностей задачи известных постановщику. При этом отбрасывание деталей, которые "не ложатся" на модели данных, применяемые на стадии реализации проекта, может привести к существенному искажению постановки задачи. На этапе анализа полноту сведений следует предпочесть возможности их формального описания.
Семантическими принято называть модели, обеспечивающие представление семантики данных. Как и другие модели, они могут включать структурную, манипуляционную и целостную части. Однако, учитывая, что какая-то семантика имеется в любой модели, можно считать семантическими те модели, в которых семантики больше, чем в "несемантических" моделях, содержащих мало семантики. Данное псевдоопределение весьма расплывчато. Но пока нам этого достаточно.
В рамках семантической модели создается концептуальная схема базы данных, которая обычно вручную или автоматизировано (но не автоматически) преобразуется в схему базы, допустимую в рамках моделей данных, реализуемых на следующих стадиях жизненного цикла проекта — проектировании, разработки и сопровождения.
Детально семантика данных будет рассмотрена в лекции двенадцатой лекции учебника.
Самая известная семантическая модель "сущность-связь" ("entity-rela-tionship" — ER) была предложена Питером Пин Шен Ченом (Peter Chen) в 1976 году.
Семантические модели выполняются в виде диаграмм, предназначенных для человека, удобных для восприятия человеком. В современной науке вообще и в компьютерных науках в частности, большое и заслуженное внимание уделяется когнитивным аспектам. В рамках баз данных это означает выделение двух основных действующих лиц — человека и программы — и разработку естественных, удобных для человека моделей, языков, интерфейсов и алгоритмов работы пользователя. Естественно, необходимо учитывать предварительную профессиональную подготовку пользователя, определяющую, наряду с бытовыми знаниями, ментальный мир человека, набор образов (гештальтов), которыми он оперирует. Почему мы ожидаем головное меню в верхней части окна? Только потому, что нас к этому приучили разработчики некоторых успешных программных продуктов.
В соответствии с подходом Питера Чена, изложенным в основополагающей работе по диаграммам "сущность-связь", выделим четыре уровня представления моделей данных, несколько изменив их определения:
Забегая вперед, заметим, что реляционная модель относится к уровням 2 и 3. Сетевая и иерархическая модели, в том виде как они существовали 20 лет назад, работают в основном на уровне 3 и 4. UML —это уровни 1, 2 и 3, но UML далеко выходит за рамки описания данных. Модель "сущность-связь" работает на уровнях 1 и 2.
Сущность —это понятие, концепт, воображаемый объект, для которого у человека может быть создан четко отделяемый образ. Сущность задает некоторый набор объектов описываемого мира, в том числе процессов или атрибутов других объектов. Важно понимать, что сущность похожа на тип, но не на экземпляр. В дальнейшем мы будем говорить о типах сущностей, хотя употребление термина "тип" применительно к сущностям не совсем корректно. На ER-диаграммах сущность представляется прямоугольником, в котором обязательно указывается имя сущности. Дополнительно можно указывать примеры экземпляров сущности (рисунок 2.1). Примеры предназначены для человека, и позволяют с самого начала как-то ограничить множество экземпляров входящих в тип сущности.
(рис 2.1) Сущность
С каждым типом сущности можно связать предикат, проверяющий принадлежность экземпляра сущности набору сущностей. При определении типа сущности необходимо гарантировать, что экземпляры сущности различимы. Это требование аналогично требованию отсутствия записей-дубликатов или кортежей в реляционных отношениях, которые будут рассматриваться в лекции 4. Предикат, соответствующий сущности имеет вид: имя_сущности (список_атрибутов). Для моделей физического уровня задают еще типы атрибутов. Таким образом, сущности в ER-моделях определяются как минимум именем и списком атрибутов. В пределах одной сущности не может быть двух экземпляров с одинаковыми значениями атрибутов.
Связь —это типовое понятие, устанавливающее правила связывания сущностей. Каждый экземпляр типа связи устанавливается между экземплярами типов сущностей. Может существовать рекурсивная связь между типом сущности и им самим (как бы его дубликатом).
Пока рассматриваем только бинарные связи, устанавливаемые между двумя типами сущностей. В нотации Чена их обозначают сплошной линией. О связях с большей арностью поговорим позднее.
Концы бинарной связи в ER-модели характеризуются:
Обозначения и примеры связей в первоначальной нотации, предложенной П. Ченом, приведены на рисунке 2.2
(рис 2.2) Связи в нотации П. Чена
Для представления некоторых тонкостей наряду с нотацией П. Чена воспользуемся модифицированной нотацией Р. Баркера (рисунок 2.3). Будем изображать связь ненаправленной линией, соединяющей две разных сущности или сущность с собой. Обязательный конец связи будем представлять сплошной линией, а необязательный конец - штриховой линией. Неразветвленный конец линии обозначает степень 1. "Воронья лапка" означает степень "ко многим". Степень конца связи может быть уточнена. Так, указание 2..4 означает, что степень этого конца связи от 2 до 4 включительно.
Обязательность связи определяет, любой ли экземпляр сущности участвует в некотором экземпляре связи.
Примеры типов связей приведены на рисунке 2.3. Слева изображена связь, которую следует читать в двух направлениях так:
Справа пример рекурсивной связи, которую следует читать так:
Для правильного прочтения связей следует помнить, что обязательность, обозначенная типом линии (сплошная или прерывистая) связана только со "своим" именем роли. Тип линии другого конца связи значения не имеет.
(рис 2.3) Примеры типов связей
Обратите внимание на то, что чрезмерная краткость описания ролей в примере вызывает трудности в установлении смысла связи.
Задание уточнений степени конца связи определим на примерах:
n означает, что в каждом экземпляре связи участвует ровно п экземпляров сущности;Атрибут —это свойство сущности или связи, получаемое путем наблюдения или измерения. Информацию об экземпляре сущности выражают набором пар "атрибут — значение", как например на рисунке 2.4:
(рис 2.4) Пара "атрибут" — значение
Пример множественного значения. В анкете предлагается подчеркнуть один или несколько предусмотренных ответов в качестве значения атрибута. Заполненная строка выглядит так: "Как часто вы занимаетесь базами данных (нужное подчеркнуть): часто, редко, довольно часто, довольно редко, по настроению, в дождливую погоду".
Значения атрибутов обычно принадлежат одному типу, но возможны бестиповые атрибуты.
Связи также имеют атрибуты. Выделим две их разновидности:
Пример: Сущности "Работник" и "Проект" со связью "Проект — Работник", содержащей атрибуты связи "Номер_работника", "Номер_проекта" и атрибут свойства связи "Ресурс_времени". Последний атрибут эмерджентный. Его смысл: планируются затраты времени работника на работу в рамках указанного проекта.
На рисунке 2.5 приведено графическое обозначение атрибутов и пример несложной ER-диаграммы. Названия ключевых атрибутов подчеркнуты. Обратите внимание, даже простая диаграмма воспринимается плохо. Причина по-видимому в том, что в ней не создается образ, отражающий агрегирован-ность атрибутов в сущность. Сравните это изображение с хорошо выстроенной эквивалентной диаграммой ERwin на рисунке 2.14.
(рис 2.5) Пример ER-диаграммы с атрибутами
Ранее мы установили, что каждой сущности соответствует предикат вида: имя_сущности(список_атрибутов). Давайте выясним подробности. Могут ли атрибуты отсутствовать? И как в этом случае определять свойства сущности? Вспомните из философии пару концептов "материя — сознание" для которых весьма затруднительно назвать атрибуты. Их свойства выясняются через отношения, в которые они входят. Вряд ли в практике вы встретите подобные сущности, однако, полезно понимать, что связи могут существенно пополнить описание сущности и что возможны сущности без атрибутов, характеризуемые только своими связями.
Связям может быть поставлен в соответствие предикат вида: имя_связи (список_атрибутов_привязки, список_эмерджентных_атрибутов).
В свою очередь, атрибутам соответствует одноместный предикат: имя_атрибута(значение_атрибута).
Трудно поверить, но разделение на сущности, связи и атрибуты условно. Пример: то, что студент должен относиться к какой-нибудь учебной группе, можно выразить через связь (рисунок 2.6, а), введением пары атрибутов "Группа" и "Состав", обозначающих концы связи (рисунок 2.6, б), и заданием отдельной сущности "состав группы"(рисунок 2.6, в)
Вместе с тем, в практике всегда существуют предпочтительные варианты разделения на сущности, связи и атрибуты.
Еще одна проблема для начинающих — сущности, которые являются процессами, а не предметами, вещами. Вы должны были столкнуться с их аналогами при изучении классов в объектном программировании.
(рис 2.6) Условность разделения на сущности, связи и атрибуты
Уже говорилось, что связи вида "многие-ко-многим" (n:m) могут появляться в концептуальных моделях, но современные базы данных обычно не способны их реализовать. Поэтому необходимо перестроить связи n : m, выражая каждую через две связи вида "один-ко-многим". Рисунок 2.7 поясняет, как из связи "многие-ко-многим" получаются две связи "один-ко-многим".
(рис 2.7) Преобразование связи n : m в две связи n : 1 и 1 : m
Исходные сущности примера содержат множества экземпляров {1,2,3, 4,5} и {а, 6, с}. Линии показывают связи между экземплярами. Вводим ассоциированную сущность. Рисуем связи между исходными сущностями и вспомогательную вертикальную линию так, чтобы не было пересечений трех линий. Тогда точки пересечения связей с вертикальной линией соответствуют экземплярам фиктивной сущности и если, например, экземпляр "1" соединен с экземпляром "а", то получаем экземпляр фиктивной сущности "1а". Если для исходных двух сущностей имелась связь "многие-ко-многим" , то в итоге получили две связи "один-ко-многим" (от ассоциативной сущности к имевшимся). Ассоциативная сущность должна иметь имя. Его можно образовать просто соединяя имена исходных сущностей.
Содержательный пример преобразования связей n : m будет приведены ниже.
К сожалению, вам придется пользоваться пробной версией программного продукта, который менял свое имя и собственника раз пять. В свое время он назывался ERwin, а сейчас называется All Fusion Data Modeler. Опыт показывает, что при его использовании скорость разработки схемы базы увеличивается на порядок.
ERwin создает графическую документацию в стандарте IDEF1X , что очень удобно. По ER-диаграммам в процессе прямого инжиниринга генерируется скрипт, то есть текст, который позволяет создать базу данных для любой из двух десятков наиболее распространенных СУБД. По скрипту ERwin позволяет построить диаграмму. Этот процесс называется обратным инжинирингом.
Сведения по установке и запуску ERwin приведены на сайте книгиwww.database-model-lang-struct-semantic.ru.
Диаграммы могут быть созданы на двух уровнях —физическом и логическом. Поэтому после выбора в головном меню пути "File > New" лучше выбрать вариант "Logical/Physical". На рисунке 2.8 приведена панель ERwin, в которой создана логическая модель сущности.
(рис 2.8) Задание сущности
Установка кириллических шрифтов для обозначения имен сущностей, атрибутов и отношений показана на рисунке 2.9 Используется путь "Format > Default Fonts Colors". Выполните ее обязательно, чтобы установить кириллические шрифты. Не забывайте указывать, что установки предназначены для всех объектов базы (All Objects).
(рис 2.9) Установка шрифтов
На рисунке 2.10 приведена центральная часть верхней панели инструментов, на которой имеется текстовое окно для указания уровня модели, а правее и ниже его — основные объекты, переносимые в проект, — сущность, связь "категория", связь идентифицирующая, связь "многие-ко-многим" и связь неидентифицирующая.
(рис 2.10) Часть панели инструментов ERwin
В отличие от ER-диаграмм сущности в ERwin представляются прямоугольниками, внутри которых помещаются имена сущностей, записываемые именами существительных в единственном числе. Изображение каждой сущности разделяется горизонтальной линией на верхнюю часть (ключевую область), в которой расположены ключевые атрибуты (поля) (первичные ключи (РК) и, может быть, внешние ключи (Foreign Key — FK)), и нижнюю часть (область данных), где расположены неключевые атрибуты и, может быть, атрибуты внешних и альтернативных (АК) ключей.
Экземпляр идентифицируется значением первичного ключа. Других способов выделения записей в ER-диаграммах нет. Первичный ключ не должен изменяться со временем. При изменении ключа, меняется экземпляр сущности. Например, не желательно в состав ключа вводить фамилию, так как в определенных обстоятельствах женщины имеют склонность изменять фамилию. Желательно найти такие идентификаторы, которые со временем не изменятся.
Свойства первичного ключа:
Уникальные ключи (Unique Key —UK) отличаются от первичных тем, что в них могут использоваться неопределенные значения NULL.
Внешние ключи связывают сущности. Обнаружив связь, ERwin может передать ключ (набор ключевых атрибутов) в область ключей или область данных дочерней сущности. Переданные атрибуты будут внешними ключами. Атрибуты, перемещающиеся в другие сущности, называют мигрирующими.
Для установки вида изображения сущности используется меню "For-mat > Entity Display". Пример записи определений (Definition), примечаний (Note и Note2) и свойств, определенных пользователем (путь User Defined Properties > UDP) показан на рисунке 2.11.
(рис 2.11) Задание определения
UDP может использоваться для выполнения некоторых действий, например, содержать данные, необходимые для оценки. Заметки могут делаться по разным поводам. Они никак не участвуют в создании скрипта генерирующего базу.
Связи между сущностями обозначаются линиями, может быть, снабженными дополнительными символами на концах. Для создания связи необходимо подхватить ее в панели инструментов, а затем последовательно кликнуть левой кнопкой мыши на связываемых сущностях. Порядок обхода сущностей важен.
Существуют два типа связей — идентифицирующая и неидентифициру-ющая. Первая изображается сплошной линией (рисунок 2.12, сущности 3 и 4). Допустим, есть сущность, которая вне какой-то другой сущности не имеет смысла. Например, номер телефона без привязки к человеку практически бесполезен. В этом случае используют идентифицирующую связь. Обратите внимание на то, что изображение сущности 4 после связи с сущностью 3 изменилось. Появились скругленные углы. Это означает, что сущность 4 считается слабой. Чуть позже мы уточним смысл этого наименования.
(рис 2.12) Связи сущностей
Связь между сущностями 5 и 6 неидентифицирующая.
Связи именуются глаголами, которые показывают, как соотносятся сущности между собой. В простых схемах имена связей могут не назначаться и не проставляться.
В примере, изображенном на рисунке 2.13 на логическом уровне создаем две сущности "Работник" и "Отдел". Соединяем их идентифицирующей связью от отдела к работнику и обнаруживаем, что изображение сущности "Работник" поменялось.
(рис 2.13) Две сущности, соединенные идентифицирующей связью
Прямоугольником изображается сильная сущность. Предполагается, что отделы существуют сами по себе, а работники закреплены за отделами. Но в жизни могут быть и другие ситуации. Например, когда сотрудник закреплен за двумя отделами или директор не должен относиться ни к какому отделу.
В примере на рисунке 2.13 связь идентифицирующая. "Состоит из / работает в" — это роли сущностей в этой связи. Роль отдела — "состоит из", роль сотрудника — "работает в". Желательно именовать связи как можно проще и точнее, иначе легко запутаться.
Как вы знаете, связи вида "многие-ко-многим" в СУБД не реализуются. Поэтому необходимо их преобразовать в наборы связей "один-ко-многим". Достаточно создать ассоциированную сущность, у которой первичный ключ содержит только ключи соединяемых сущностей. Эти ключи будут еще и внешними ключами, обеспечивающими связи с сущностями, из которых они взяты.
Рассмотрим пример связи сущностей "Потребитель" и "Копия фильма" (рисунок 2.14). Один человек смотрит много фильмов и один фильм может просматриваться многими людьми.
(рис 2.14) Связь "многие-ко-многим"
На рисунке 2.15 показан первый шаг автоматического преобразования связи. В ERwin кликаем правой кнопкой мыши по связи. Появляется меню, в котором следует выбрать позицию "Create Association Entity" — создать ассоциированную сущность.
(рис 2.15) Преобразование связи "многие-ко-многим"
Появится сущность со странным названием составленным из кусков названий связываемых сущностей (рисунок 2.16). Получилось две связи один-ко-многим, которые реализуются в СУБД.
(рис 2.16) Преобразованная связь
Название ассоциированной сущности можно (и часто нужно) исправить.
Уточним понятия сильной и слабой сущности.
Может оказаться, что в первичный ключ сущности необходимо включить внешний ключ. Такая сущность называется слабой или зависимой.
Допустим, у нас есть никак не связанные команды и игроки. Пусть распределение игроков по командам несущественно. Это один подход. При втором подходе считается, что игрок — это всего лишь член некоторой команды. Если это так, то кроме его личного идентификатора, необходимо указать, к какой команде он относится. Сущность "Игрок" зависима от сущности "Команда". потому, что без указания команды игрока не выделишь однозначно.
Создадим две независимые сущности "Команда" и "Игрок" (рисунок 2.17):
(рис 2.17) Независимые сущности
Установление идентифицирующей связи определяет сущность "Игрок" как слабую, то есть зависимую (рисунок 2.18).
(рис 2.18) Идентифицирующая связь
При соединении идентифицирующей связью сущностей "Команда" и "Игрок", во-первых, изменяется изображение сущности "Игрок", появляется изображение этой связи, и, во-вторых, ключевой атрибут команды, мигрирует в сущность "Игрок".
Теперь рассмотрим случай, когда команды и игроки независимы. Выбираем неидентифицирующую связь (рисунок 2.19). Обратите внимание, что форма сущности "Игрок" осталась прежней (без скругления), а идентификатор из "Команды" мигрировал уже в неключевую область "Игрока".
(рис 2.19) Неидентифицирующая связь
Сейчас важно понимать, что, рассуждая о миграциях ключей, мы выходим за пределы базы данных, оперируем смыслами, извлеченными из модели бизнеса. Выясняем, как связаны команда и игрок.
В базах данных есть много вещей, с которыми разобраться невозможно, если не использовать сведения из бизнеса. Дело в том, что база данных что-то из модели бизнеса отображает, а что-то — нет. Если вы не умеете или не хотите разбираться с бизнесом, то база данных у вас получится не вполне адекватной модели бизнеса.
Потенциальные ключи, не использующиеся как первичные, могут быть определены как альтернативные ключи и записаны в секции данных модели с символом (AKn.m), где n.m — номер альтернативного ключа в формате "номер_сущности". "номер_ключа", AK означает — альтернативный ключ (alternate key).
Допустим, нас устраивает "Номер потребителя" в качестве первичного ключа. Если все потребители имеют ИНН, то он тоже может быть ключом. Мы не используем его как ключ, но помечаем как альтернативный (рисунок 2.20).
(рис 2.20) Альтернативный ключ
Зачем нужны альтернативные ключи? ИНН трудно запоминается, но не исключено, что когда-нибудь вам придется искать потребителя по ИНН.
Отметим, что в реализациях на первичный, альтернативный и уникальный ключи обычно создается индекс. Индексы иногда (далеко не всегда) ускоряют поиск, но из-за необходимости перестраивания индекса всегда замедляются вставка, обновление и удаление записей. Если обозначим ИНН как альтернативный ключ, то при создании базы данных на него система сама построит индекс. Если вы никогда не будете производить поиск по этому столбцу, то значит вы перетяжелили базу, дали ей лишнюю нагрузку.
Если вы хотите отрисовывать пиктограммы ключей, то:
Модели "сущность-связь" позволяют по модели бизнеса быстро построить схему базы данных. Все начинается с описания бизнес-процессов. Затем к ним привязывают обеспечивающие структуры данных или документов, описываемые ER-диаграммами.
Помните, что самые дорогие ошибки — это ошибки анализа бизнеса. Если что-то существенно не доделано, то не исключено, что работу по созданию базы придется просто выбросить и заново поставить задачу.
Можно, конечно, использовать гибкие методы разработки и на каждом следующем шаге уточнять задание, но этому еще нужно научиться. Во всяком случае, начинать освоение баз данных с использованием эволюционных методов разработки не следует.
Инструментальная поддержка модели "сущность-связь" дает хорошую графическую документацию для логической и физической схем базы. Более того, для самых распространенных баз, основанных на реляционной модели данных (лекция 4), по схеме можно сгенерировать скрипт на языке SQL, создающий схему базы. Эта операция называется прямым инжинирингом. Она выполняется только для диаграмм физического уровня. Обратный инжиниринг — это создание графического изображения модели по скрипту, создающему схему.
На рисунке 2.21 показан скрипт создания базы, сгенерированный по схеме рисунка 2.19 представленной на физическом уровне. В ERwin для выполнения прямого инжиниринга необходимо в головном меню выбрать позицию Tools, затем Forward Engeneer / Scheme Generation. Если в появившейся панели выбрать Preview, появится текст скрипта.
(рис 2.21) Прямой инжиниринг
После изучения языка SQL (лекция 8) текст будет легко читаться, но и сейчас понятно, что создаются две таблицы со столбцами, полученными из атрибутов исходных сущностей.
Смыслы (раздел 2.1.1)
(рис 2.22) Смыслы
Диаграмма сущность-связь (раздел 2.2.1)
(рис 2.23) Диаграмма сущность-связь
Связь (разделы 2.2.3 и 2.2.6)
(рис 2.24) Связь
Ключ (разделы 2.2.5 и 2.2.7)
(рис 2.25) Ключ
Сильные и слабые сущности (раздел 2.2.7)
(рис 2.26) Сильные и слабые сущности
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.