Построение концептуальной схемы

Главная задача при создании модели данных состоит в том, чтобы построить концептуальную схему. Однако пользователи не будут го­ворить с разработчиками на языке этой схемы. Пользователи говорят о данных с точки зре­ния своей работы, то есть своего собственного представления (внешней схемы) данных. Целью разработчика будет, взяв за отправную точку все эти внешние схемы, построить единую концептуальную схему, которая бы поддерживала каждое из заданных на входе пользовательских представлений.

Не менее важно при создании концептуальной схемы четко отличать ее от внутренней схемы. Не следует смешивать физическое представление данных с их логическим представлением. В противном случае ха­рактеристики СУБД будут ограничивать и искажать видение концептуаль­ной модели. Из-за этого СУБД просто ограничит свободу действий пользователей. Такого рода ограничения подобны хвосту, который ви­ляет собакой. (Не хотелось бы, чтобы характеристики индексов СУБД определя­ли то, как торговые агенты должны осуществлять продажи!)

Разумеется, разработав концептуальную схему, можно обнару­жить, что придется так или иначе от нее отступить, дабы обеспечить ее эффективную реализацию во внутренней схеме. Но прежде чем приступить к модификации схемы, требования пользователей, по крайней мере, будут зафиксированы в доку­ментальной форме. Может статься, что потом, в результате более тщательного обдумы­вания или из накопленного опыта, все-таки удастся найти способ реализо­вать ту концептуальную схему, которая нужна пользователям. А может быть, это станет возможным благодаря новому продукту или новым возможностям уже существующего продукта.

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

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

Модель «сущность—связь» и ее вapианты

Модель «сущность—связь» (entity-relationship model, E-R model) представляет собой совокупность понятий и графических символов для построения концептуальных схем. Модель «сущность—связь» была предложена Питером Ченом и опубликована им в 1976 году. В своей статье Чен описал основные элементы модели. Позже к этой модели были добавлены подтипы, результатом чего стала расширенная модель «сущность—связь» (еxtended E-R: model). На сегодняшний день, как правило, когда говорят о модели «сущность-связь», имеют в виду именно расширенный ее вариант.

Версии модели «сущность—связь»

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

- информационная инженерия (разработана в1990 году, меньше всего распространена в современной промышленности);

- IDEF1X («Integrated Definition I, Еstended» — «Единый стандарт, версия 1, расширенная»); в 1993 году эту версию модели «сущность—связь» в качестве национального стандарта США анонсировал Национальный институт стандартов и технологии. Этот стандарт включает в себя основные идеи модели «сущность—связь», но использует для их представления другие графические символы. В стандарте IDEF1X предусмотрены средства для разработки как концептуальных, так и внутренних схем, а также методы образования первых во вторые.

На этом, однако, путаница не кончается. Новая объектно-ориентированная модель разработки под названием UML (Universal Modeling Language — универсальный язык моделирования) также взяла за основу модель «сущность—связь», при этом ввела свои собственные символы и привнесла объектно-ориентированную специфику.

В конечном счете мы имеем исходную модель «сущность—связь», расширенную модель «сущность—связь», информационную инженерию, национальный стандарт IDEF1X и UML.

Расширенная модель «сущность—связь»

Ключевыми элементами модели «сущность—связь» являются сущности, атрибуты, идентификаторы и связи.

Сущности

Сущность (entity) — это некоторый объект, про который информация собирается и сберегается. Или за которым пользователь хотел бы наблюдать: СОТРУДНИК , КЛИЕНТ , ЗАКАЗ , ПРОДАВЕЦ , ПРОДУКТ . Сущности одного и того же типа группируются в классы сущностей (entity classes). Так, класс сущностей СОТРУДНИК является совокупностью всех сущностей СОТРУДНИК.

Важно уяснить разницу между классом сущностей и экземпляром сущности. Класс сущностей — это совокупность однотипных сущностей, и описывается он структурой или форматом сущностей, его составляющих. Экземпляр сущности (entity instance) представляет конкретную сущность, такую как КЛИЕНТ 12345. Он описывается значениями атрибутов данной сущности. Класс сущности обычно содержит множество экземпляров: класс КЛИЕНТ - по одному на каждого клиента.

Атрибуты

У сущностей есть атрибуты (attributes), или, как их иногда называют, свойства (properties), которые описывают характеристики сущности. Примерами атрибутов могут служить ИмяСотрудника, ДатаНайма и КодКвалификации. В модели «сущность—связь» предполагается, что все экземпляры данного класса сущностей имеют одинаковые атрибуты.

Исходное определение модели «сущность—связь» включает в себя композитные атрибуты (composite attributes) и многозначные атрибуты (multi-valued butes). В качестве примера композитного атрибута можно привести атрибут Адрес, состоящий из группы атрибутов {Улица, Город, Штат, Индекс}. Примером многозначного атрибута может служить атрибут ДоверенноеЛицо сущности КЛИЕНТ, который может содержать имена нескольких доверенных лиц данного клиента. Атрибут может быть одновременно и композитным, и многозначным — например, композитный атрибут Телефон, состоящий из группы атрибутов {КодРегиона, МестныйНомер}. Будучи многозначным, позволяет иметь в базе данных несколько телефонных номеров одного и того же лица.. В большинстве версий модели однозначные композитные атрибуты игнорируются, и требуется, чтобы многозначные атрибуты преобразовывались в сущности.

Идентификаторы

Экземпляры сущностей имеют идентификаторы (identifiers) — атрибуты, с мощью которых эти экземпляры именуются, или идентифицируются. Например, экземпляры сущностей класса СОТРУДНИК могут идентифицироваться по атрибутам НомерСоциальнойСтраховки, ТабельныйНомерСотрудника или ИмяСотрудника. Такие атрибуты, как Зарплата или Дата Найма, вряд ли могут служить идентификаторами экземпляров сущностей класса СОТРУДНИК, поскольку обычно эти атрибуты не способны однозначно указать на конкретного сотрудника. Точно так сущности класса КЛИЕНТ могут идентифицироваться по атрибутам НомерКлиента или ИмяКлиента, а сущности класса ЗАКАЗ могут идентифицироваться по атрибутам НомерЗаказа.

Идентификатор экземпляра сущности состоит из одного или более атрибутов сущности. Идентификатор может быть уникальным (unique) либо неуникальным (nonunique). Если идентификатор является уникальным, его значение будет указывать на один и только один экземпляр сущности. Если идентификатор являет неуникальным, его значение будет указывать на некоторое множество экземпляров. ТабельныйНомер является, скорее всего, уникальным идентификатором, а ИмяСотрудника неуникальным.

Идентификаторы, состоящие из нескольких атрибутов, называются композитными идентификаторами (composite identifiers). Примерами могут служить идентификаторы вида {КодРегиона, МестныйНомер}, {НазваниеПроекта, НазваниеЗадачи} и {Имя, Фамилия, ДобавочныйНомерТелефона}.

Связи

Взаимоотношения сущностей выражаются связями (relationships). Модель «cyщность—связь» включает в себя классы связей и экземпляры связей. Классы связей (relationship classes) выражают взаимоотношения между классами сущностей, а экземпляры связи (relationship instances) — взаимоотношения между экземплярами сущностей. У связей могут быть атрибуты.

Класс связей может соединять несколько классов сущностей. Число классов сущностей, участвующих в связи, называется степенью связи (relationship degree). Изображенная на рис. а связь ПРОДАВЕЦ—ЗАКАЗ имеет степень 2, поскольку в ней участвуют два класса сущностей — ПРОДАВЕЦ и ЗАКАЗ. Связь РОДИТЕЛЬ рис. б имеет степень 3, так как в ней участвуют три класса сущностей — МАТЬ, ОТЕЦ и РЕБЕНОК. Связи степени 2 весьма распространены, их часто называют бинарными связями (binary relationships).

Три типа бинарных связей

На рис. показаны три типа бинарных связей. В связи 1:1 («один к одному») одиночный экземпляр сущности одного типа связан с одиночным экземпляром сущности другого типа. На рис. а связь СЛУЖЕБНЫЙ_АВТОМОБИЛЬ связывает конкретного сотрудника с конкретным автомобилем. Согласно этой диаграмме, за одним сотрудником не закреплено более одного автомобиля, и ни один автомобиль не закреплен более чем за одним сотрудником.

На рис.б изображен второй тип связи, 1:N («один к N» или «один ко многим).В этой связи, которая называется ОБЩЕЖИТИЕ—ЖИЛЕЦ, единичный экземпляр сущности класса ОБЩЕЖИТИЕ связан со множеством экземпляров сущности СТУДЕНТ. В соответствии с этим рисунком, в общежитии проживает много студентов, но каждый студент живет только в одном общежитии.

Важна позиция, в которой стоят 1 и N. Единица стоит на той стороне связи, где располагается ОБЩЕЖИТИЕ, а N стоит на той стороне связи, где располагается СТУДЕНT. Если бы мы поменяли местами 1 и N и записали бы эту связь как N:l, получилось бы, что в общежитии проживает всего один студент, причем студент может жить в нескольких общежитиях

На рис. в показан третий тип бинарной связи, N:M (читается «N к М» или «многие ко многим»). Эта связь называется СТУДЕНТ—КЛУБ, и она связывает экземпляры сущностей класса СТУДЕНТ с экземплярами сущностей класса КЛУБ. Один студент может быть членом нескольких клубов, а в одном клубе может состоять много студентов.

Числа внутри ромба, символизирующего связь, обозначают максимальное количество сущностей на каждой стороне связи. Эти ограничения называются максимальными кардинальными числами, а совокупность из двух таких ограничений для обеих сторон связи называется максимальной кардинальностью (maximi cardinality) связи. Например, о связи, изображенной на рис. б, говорят, что она обладает максимальной кардинальностью 1:N. Кардинальные числа могут иметь и другие значения, а не только 1 и N. Например, связь между сущностями БАСКЕТБОЛЬНАЯ_КОМАНДА и ИГРОК может иметь кардинальность 1:5, что говор нам о том, что в баскетбольной команде может быть не более пяти игроков.

Связи трех типов, представленных на рис. называются иногда связям типа «ИМЕЕТ», или связями принадлежности (HAS-A relationships). Например, сотрудник имеет автомобиль, студент имеет общежитие, клуб имеет студентов.

Диаграммы «сущность—связь»

Схемы, изображенные на рис., называются диаграммами «сущность—связь» (entity-relationship diagrams, ER-diagrams). Как в оригинальной, так и в расширенной модели классы сущностей обозначаются прямоугольниками, связи обозначаются ромбами, а максимальное кардинальное число каждой связи указывается внутри ромба. Имя сущности указывается внутри прямоугольника, а имя связи указывается рядом с ромбом. В других версиях модели используются другие символы.

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

Для указания минимальной кардинальности (minimum cardinality) существует несколько способов. Один из них, продемонстрированный на рис. заключает­ся в следующем: чтобы показать, что сущность обязана участвовать в связи, на линию связи помещают перпендикулярную черту, а чтобы показать, что сущность может (но не обязана) участвовать в связи, на линию связи помещают овал. Со­ответственно, рис. показывает, что сущность ОБЩЕЖИТИЕ должна быть связана как минимум с одной сущностью СТУДЕНТ, однако сущность СТУДЕНТ не обязана иметь связь с сущностью ОБЩЕЖИТИЕ. Полный набор накладываемых на связь ограничений состоит в том, что ОБЩЕЖИТИЕ имеет минимальное кардинальное число равное единице, и максимальное кардинальное число, равное «многим» сущностям СТУДЕНТ. СТУДЕНТ имеет минимальное кардинальное число, равное нулю, и максимальное кардинальное число, равное одному экземпляру сущности ОБЩЕЖИТИЕ.

ПРОЖИВАНИЕ

Может существовать связь между сущностями одного и того же класса. Напримep, для сущностей класса СТУДЕНТ может быть определена связь СОСЕД_ПО_КОМНАТЕ. Такая связь показана на рис. а, а на рис. б изображены экземпляры сущностей, охваченных этой связью. Связи между сущностями одного и того же класса называются иногда рекурсивными связями (recursive relationships).

б

Изображение атрибутов на диаграммах «сущность—связь»

В некоторых версиях диаграмм «сущность—связь» атрибуты обозначаются эллипсами, соединенными с сущностью или связью, которой они принадлежат. На рис. показаны сущности ОБЩЕЖИТИЕ и СТУДЕНТ и связь ОБЩЕЖИТИЕ—ЖИЛЕЦ с принадлежащими им атрибутами. Как видно из рисунка, сущность ОБЩЕЖИТИЕ имеет атрибуты НазваниеОбщежития, Местоположение и КоличествоКомнат, а сущность СТУДЕНТ имеет атрибуты НомерСтудента, ИмяСтудента и Курс. Связь ОБЩЕЖИТИЕ—ЖИЛЕЦ имеет атрибут Плата, который показывает внесенную студентом плату за проживание в конкретном общежитии.

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

Слабые сущности

В модели «сущность—связь» определен особый тип сущности, называемы слабой сущностью (weak entity). К слабым сущностям относятся такие сущности, которые могут существовать в базе данных только в том случае, если в ней присутствует сущность некоторого другого типа. Сущность, не являющаяся слабой называется сильной сущностью (strong entity).

Чтобы разобраться в том, что такое слабые сущности, рассмотрим базу данных отдела кадров с классами сущностей СОТРУДНИК и ПОДЧИНЕННЫЙ. Предположим, существует правило, что экземпляр сущности СОТРУДНИК может существовать не будучи связанным ни с одной сущностью класса ПОДЧИНЕННЫЙ, но сущность ПОДЧИНЕННЫЙ не может существовать вне связи с какой-либо сущностью класса СОТРУДНИК. Тогда сущность ПОДЧИНЕННЫЙ является слабой. Это означает, что запись о сущности ПОДЧИНЕННЫЙ может появиться в базе данных только в том случае, если эта сущность имеет связь с какой-либо сущностью класса СОТРУДНИК.

Слабые сущности: а - идентификационно-независимая; б - зависимая

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

В модели «сущность—связь» имеется особый тип слабых сущностей, называемый идентификационно-зависимыми сущностями (ID-dependent entities). Это такие сущности, идентификаторы которых содержат идентификатор другой сущности. Рассмотрим сущности ДОМ и КВАРТИРА. Пусть идентификатором cyщности ДОМ является атрибут НазваниеДома, а идентификатором сущности КВАРТИРА является композитный идентификатор {НазваниеДома, НомерКвартиры}. Поскольку идентификатор сущности КВАРТИРА содержит в себе идентификатор сущности ДОМ НазваниеДома, то сущность КВАРТИРА является идентификационно-зави-симой от сущности ДОМ.. По-другому это так: как логически, так и физически квартира не может существовать, если не сущ. соответствующее здание.

Идентификационно-зависимые сущности встречаются часто. Еще одним примером может служить сущность ВЕРСИЯ в связи с сущностью ПРОДУКТ, где ПРОДУКТ — некоторый программный продукт, а ВЕРСИЯ — номер его версии. Идентификатором продукта является атрибут НазваниеПродукта, а идентификатором версия является совокупность {НазваниеПродукта, НомерВерсии}. Третий пример — связь между сущностями ИЗДАНИЕ и УЧЕБНИК. Идентификатором сущности УЧЕБНИК является атрибут Заглавие, а идентификатором издания является совокупность {Заглавие, ПорядковыйНомерИздания}.