поскольку разные варианты ER-моделей разрабатывались именно для поддержки проектирования реляционных баз данных, и ER-модели почти не содержат возможностей, выходящих за пределы реальных потребностей проектировщика реляционной базы данных.
Язык UML принадлежит объектному миру. Этот мир гораздо сложнее (если угодно, непонятнее, запутаннее) реляционного мира. Поскольку UML может использоваться для унифицированного объектно- ориентированного моделирования всего чего угодно, в этом языке содержится масса различных понятий, терминов и вариантов использования, избыточных с точки зрения проектирования реляционных баз данных. Если вычленить из общего механизма диаграмм классов то, что действительно требуется для проектирования реляционных баз данных, то мы получим в точности ER-диаграммы с другой нотацией и терминологией.
Любопытно, что при формировании имен классов в UML допускается использование произвольной комбинации букв, цифр и даже знаков препинания. Однако на практике рекомендуется использовать в качестве имен классов короткие и осмысленные прилагательные и существительные, каждое из которых начинается с заглавной буквы.
(Подробнее понятие диаграммы мы рассмотрим в следующем параграфе нашей лекции.)
1. Различные типы и кратности связей
Связь между отношениями при проектировании схем баз данных изображается в виде линий, соединяющих классы сущностей.
При этом каждый из концов связи может (и вообще должен) характеризоваться наименованием (т. е. типом связи) и кратностью роли класса в связи. Рассмотрим подробнее понятия кратности и типы связей.
Кратностью (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 – это связь, в свою очередь, аналогичная связи типа «многие к одному», она называется «многие к не более одному».
Как можно заметить, три последние связи получились из связей, которые в нашей лекции перечислены под номерами один, два и три путем замены кратности «один» на кратность «не более одного».
2. Диаграммы. Виды диаграмм
И теперь перейдем, наконец, непосредственно к рассмотрению диаграмм и их видов.
Вообще выделяют три уровня логической модели. Эти уровни различаются по глубине представления информации о структуре данных. Этим уровням соответствуют следующие диаграммы:
1) презентационная диаграмма;
2) ключевая диаграмма;
3) полная атрибутивная диаграмма.
Разберем каждый из названных видов диаграмм и подробно поясним смысл их различия по глубине представления информации о структуре данных.
1. Презентационная диаграмма.
Такие диаграммы описывают только самые основные классы сущностей и их связи. Ключи в таких диаграммах могут не описываться совсем, и соответственно, связи – никак не индивидуализироваться. Поэтому допустимыми являются связи типа «многие ко многим», хотя обычно их стараются избегать или, если они все же присутствуют, – детализировать. Также вполне допустимыми являются составные и многозначные атрибуты, хотя мы и писали раньше, что базовые отношения с такими атрибутами не являются приведенными к какой бы то ни было нормальной форме. Интересно, что из рассмотренных нами трех видов диаграмм только последний вид (полная атрибутивная диаграмма) предполагает, что данные, представленные с е помощью, находятся в некой нормальной форме. Тогда как уже рассмотренная презентационная диаграмма и следующая на очереди ключевая диаграмма ничего подобного не предполагают.
Такие диаграммы, как правило, используются для презентаций (отсюда и их название – презентационные, т. е. использующиеся для презентаций, демонстраций, где чрезмерная детализация и не нужна).
Иногда при проектировании баз данных необходимо проконсультироваться с экспертами той предметной области, информацией которой эта конкретная база данных и занимается. Тогда также используются презентационные диаграммы, ведь для получения нужных сведений у специалистов профессии, далекой от программирования, чрезмерное уточнение специфических деталей совсем не требуется.
2. Ключевая диаграмма.
В отличие от презентационных диаграмм ключевые диаграммы описывают обязательно все классы сущностей и их связи, правда, в терминах только первичных ключей. Здесь связи «многие ко многим» уже непременно детализируются (т. е. связей такого типа в чистом виде здесь просто не может быть задано). Многозначные атрибуты все еще допускаются так же, как и в презентационной диаграмме, но если они присутствуют в диаграмме ключевой, то, как правило, они преобразуются в самостоятельные классы сущностей. Но, что любопытно, однозначные атрибуты все еще могут быть представлены не полностью или описаны как составные. Эти «вольности», еще допустимые в таких диаграммах, как презентационная и ключевая, не допустимы уже в следующем виде диаграммы, ведь они определяют, что базовое отношение не является нормализованным.
Таким образом, можно сделать вывод, что ключевые диаграммы предполагают в дальнейшем лишь
