Читать онлайн «Базы данных: конспект лекций». Страница 27

Язык 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. Полная атрибутивная диаграмма.

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

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

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

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