Наиболее распространенным средством абстрактного представления схем баз данных при проектировании на логическом уровне является так называемая модель «сущность – связь». Ее еще иногда называют ER-модель, где ER – аббревиатура английского словосочетания Entity – Relationship, что буквально и переводится как «сущность – связь».

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

Дадим объяснения и определения каждого из этих элементов.

Класс сущностей – это как бы лишенный методов класс объектов в смысле объектно-ориентированного программирования. При переходе к физическому уровню классы сущностей преобразовываются в базовые отношения реляционных баз данных для конкретных систем управления базами данных. У них, как и у собственно базовых отношений, существуют собственные атрибуты.

Дадим более точное и строгое определение только что приведенных объектов.

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

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

Так называемые связи реализуются с помощью объявления внешних ключей (подобные явления нам уже встречались раньше), т. е. в отношении объявляются внешние ключи, ссылающиеся на первичные или кандидатные ключи каких-то других отношений. И посредством этого и происходит «связывание» нескольких различных самостоятельных базовых отношений в единую систему, называемую базой данных.

Далее диаграмма, составляющая графическую основу модели «сущность – связь», изображается при помощи унифицированного языка моделирования UML.

Языку объектно-ориентированного моделирования UML (или Unified Modeling Language) посвящено великое множество книг, многие из которых переведены на русский язык (а некоторые и написаны российскими авторами).

Вообще, UML позволяет моделировать разные виды систем: чисто программные, чисто аппаратные, программно-аппаратные, смешанные, явно включающие деятельность людей и т. д.

Но, помимо прочего, как мы уже упоминали, язык UML активно применяется для проектирования реляционных баз данных. Для этого используется небольшая часть языка (диаграммы классов), да и то не в полном объеме. С точки зрения проектирования реляционных баз данных, модельные возможности не слишком отличаются от возможностей ER-диаграмм.

Мы также хотели показать, что в контексте проектирования реляционных баз данных структурные методы проектирования, основанные на использовании ER-диаграмм, и объектно-ориентированные методы, основанные на использовании языка UML, различаются главным образом, лишь терминологией. ER-модель концептуально проще UML, в ней меньше понятий, терминов, вариантов применения. И это понятно, поскольку разные варианты ER-моделей разрабатывались именно для поддержки проектирования реляционных баз данных, и ER-модели почти не содержат возможностей, выходящих за пределы реальных потребностей проектировщика реляционной базы данных.

Язык UML принадлежит объектному миру. Этот мир гораздо сложнее (если угодно, непонятнее, запутаннее) реляционного мира. Поскольку UML может использоваться для унифицированного объектно-ориентированного моделирования всего чего угодно, в этом языке содержится масса различных понятий, терминов и вариантов использования, избыточных с точки зрения проектирования реляционных баз данных. Если вычленить из общего механизма диаграмм классов то, что действительно требуется для проектирования реляционных баз данных, то мы получим в точности ER-диаграммы с другой нотацией и терминологией.

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

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

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

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

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

Наиболее распространенным способом задания кратности роли связи является прямое указание конкретного числа или диапазона. Например, указание «1» говорит о том, что каждый класс с данной ролью должен участвовать в некотором экземпляре данной связи, причем в каждом экземпляре связи может участвовать ровно один объект класса с данной ролью. Указание диапазона «0..1» говорит о том, что не все объекты класса с данной ролью обязаны участвовать в каком-либо экземпляре данной связи, но в каждом экземпляре связи может участвовать только один объект. Поговорим о кратностях подробнее.

Типичными, самыми распространенными кратностями в системах проектирования баз данных являются следующие кратности:

1) 1 – кратность связи на соответствующем ее конце равна единице;

2) 0… 1 – такая форма записи означает, что кратность данной связи на соответствующем своем конце не может превышать единицы;

3) 0… ? – такая кратность расшифровывается просто «много». Любопытно, что, как правило, «много» означает «ничего»;

4) 1… ? – такое обозначение получила кратность «один или более».

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

Согласно этой диаграмме, можно легко понять, что каждая касса имеет много билетов, а, в свою очередь, каждый билет находится в какой-то одной (и не более того) кассе.

Теперь рассмотрим наиболее распространенные типы или наименования связей. Перечислим их:

1) 1 : 1 – такое обозначение получила связь «один к одному», т. е. это как бы взаимно-однозначное соответствие двух множеств;

2) 1 : 0… ? – это обозначение связи типа «один ко многим». Для краткости такую связь называют «1 : М». В рассмотренной ранее диаграмме, как можно заметить, присутствует связь именно с таким наименованием;

3) 0… ? : 1 – это обращение предыдущей связи или связь типа «многие к одному»;

4) 0… ? : 0… ? – это обозначение связи типа «многие ко многим», т. е. с каждого конца связи присутствует много атрибутов;

5) 0… 1 : 0… 1 – это связь, аналогичная введенной ранее связи типа «один к одному», она, в свою очередь, называется «не более одного к не более одному»;

6) 0… 1 : 0… ? – это связь, аналогичная связи типа «один ко многим», она называется «не более одного ко многим»;

7) 0… ? : 0… 1 – это связь, в свою очередь, аналогичная связи типа «многие к одному», она называется «многие к не более одному».

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

И теперь перейдем, наконец, непосредственно к рассмотрению диаграмм и их видов.

Вообще выделяют три уровня логической модели. Эти уровни различаются по глубине представления информации о структуре данных. Этим уровням соответствуют следующие диаграммы:

1) презентационная диаграмма;

2) ключевая диаграмма;

3) полная атрибутивная диаграмма.

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

1. Презентационная диаграмма.

Такие диаграммы описывают только самые основные классы сущностей и их связи. Ключи в таких диаграммах могут не описываться совсем, и соответственно, связи – никак не индивидуализироваться. Поэтому допустимыми являются связи типа «многие ко многим», хотя обычно их стараются избегать или, если они все же присутствуют, – детализировать. Также вполне допустимыми являются составные и многозначные атрибуты, хотя мы и писали раньше, что базовые отношения с такими атрибутами не являются приведенными к какой бы то ни было нормальной форме. Интересно, что из рассмотренных нами трех видов диаграмм только последний вид (полная атрибутивная диаграмма) предполагает, что данные, представленные с е помощью, находятся в некой нормальной форме. Тогда как уже рассмотренная презентационная диаграмма и следующая на очереди ключевая диаграмма ничего подобного не предполагают.

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

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

2. Ключевая диаграмма.

В отличие от презентационных диаграмм ключевые диаграммы описывают обязательно все классы сущностей и их связи, правда, в терминах только первичных ключей. Здесь связи «многие ко многим» уже непременно детализируются (т. е. связей такого типа в чистом виде здесь просто не может быть задано). Многозначные атрибуты все еще допускаются так же, как и в презентационной диаграмме, но если они присутствуют в диаграмме ключевой, то, как правило, они преобразуются в самостоятельные классы сущностей. Но, что любопытно, однозначные атрибуты все еще могут быть представлены не полностью или описаны как составные. Эти «вольности», еще допустимые в таких диаграммах, как презентационная и ключевая, не допустимы уже в следующем виде диаграммы, ведь они определяют, что базовое отношение не является нормализованным.

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

3. Полная атрибутивная диаграмма.

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

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

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

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

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

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

1) PK – так мы будем обозначать любой атрибут первичного ключа (primary key);

2) FK – этим маркером мы будем обозначать атрибуты внешнего ключа (foreign key);

3) ^P_FK – таким маркером мы будем обозначать атрибут первичного/внешнего ключа, т. е. любой такой атрибут, который входит в состав единственного первичного ключа некоторого класса сущностей и одновременно в состав некоторого внешнего ключа этого же класса сущностей.

Таким образом, атрибуты класса сущностей с маркерами PK и FK образуют первичный ключ этого класса. А атрибуты с маркерами FK и ^P_FK входят в состав каких-то некоторых внешних ключей этого класса сущностей.

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

Всего различают две схемы миграции ключей.

1. Схема миграции ?PK (PK |>^P_FK);

В этой записи символ «|>» означает понятие «мигрирует», т. е. приведенная формула прочитается следующим образом: любой (каждый) атрибут первичного ключа PK родительского класса сущностей переносится (мигрирует) в состав первичного ключа ^P_FK дочернего класса сущностей, который, естественно, является одновременно и внешним ключом для этого класса.

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

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

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

1) полностью идентифицирующими.

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

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

2) не полностью идентифицирующими.

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

Таким образом, помимо ключа с маркером ^P_FK будет также присутствовать ключ с маркером PK. При этом внешний ключ PFK дочернего класса сущностей будет полностью определяться первичным ключом PK родительского класса сущностей, а просто первичный ключ PK этого дочернего отношения не будет определяться первичным ключом PK родительского класса сущностей, он будет сам по себе.

2. Схема миграции ?PK (PK |> FK);

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

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

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

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

1) обязательно неидентифицирующими.

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

2) необязательно неидентифицирующими.

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

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

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

Итак, мы видим, что во всех случаях, кроме последнего, ссылка не пустая (not null) > 1.

Заметим такую тенденцию, что на родительском конце связи во всех случаях, кроме последнего, устанавливается кратность «один». Это происходит потому, что значению внешнего ключа в случаях этих связей (а именно, полностью идентифицирующая, не полностью идентифицирующая и обязательно не идентифцирующая виды связей) обязательно должно соответствовать (и притом единственное) значение первичного ключа родительского класса сущностей. А в последнем случае из-за того, что значение внешнего ключа допускает равенство Null-значению (флажок допустимости FK: null), на родительском конце связи устанавливается кратность «не более одного».

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