Нотация Питера Чена
Эта нотация была представлена Питером Ченом, являющимся одним из основоположников реляционных баз данных, и долгое время применялась для графической интерпретации предметной области в терминах сущностей и связей, иллюстрирующих ее абстрактное представление на логическом и концептуальном уровнях. При построении модели в данной нотации вводится ряд обозначений (табл. 2.14).
|
Обозначения для модели в нотации Чена Таблица 2.14
|
||||||||||||||||||||||||||||||||
Указанный набор обозначений не является полным, но достаточен для представления модели структуры данных. Универсальность нотации Чена позволяет применять се нс только для описания логической модели базы данных, но и для представления концептуальной модели предметной области в части используемых структур данных. В случае, когда описывается концептуальная модель, некоторые обозначения могут не использоваться (например, первичный и внешний ключи, идентифицирующая связь и т.д.), поскольку в предметной области они никаким образом не представлены и не обладают необходимой смысловой нагрузкой. Тем нс менее, ее использование на концептуальном уровне является оправданным, поскольку дает общее визуальное представление о структурах и связях между выделенными информационными объектами и позволяет, используя технические процедуры, перейти к логическому представлению модели базы данных, не потеряв при переходе необходимые составляющие описания структур данных.
Особой ценностью для разработчика модели в нотации Чена является возможность ее использования на концептуальном уровне, когда еще нет четкого представления о структуре будущей базы данных, но есть описание
объектов предметной области с их атрибутивным составом и пониманием связей между ними. Это позволяет на начальном этапе разработки базы данных представить структурную модель, используя терминологию предметной области, но при этом подготовленную для трансформации в модель базы данных.
При построении концептуальной модели в нотации Чена разработчику необходимо указать несколько основных составляющих: объекты, их атрибутивный состав, связи между ними, свойства связей но смысловому наполнению и мощности (кардинальности). Одной из важнейших составляющих модели является наличие атрибутов-ключей. Для концептуального представления модели нет необходимости в их использовании, но применение первичного ключа является предпочтительным.
Под первичным ключом в модели базы данных понимается атрибут, значения которого уникальны и однозначно идентифицируют каждый экземпляр сущности (объекта).
Например, для объекта "Физическое лицо" таким атрибутом в предметной области "Электронный магазин" может быть атрибут "Лицевой счет". Этот атрибут имеет уникальное значение на уровне всей совокупности данных, не может повторяться и однозначно закреплен за каждым конкретным клиентом-покупателем. Этот же атрибут может быть первичным ключом для объекта "Юридическое лицо". Также для этого объекта первичным ключом может выступать атрибут "Идентификационный номер налогоплательщика (ИНН)", который также уникален для каждой организации (юридического лица).
Таким образом, в концептуальной модели возможно и целесообразно указывать первичные ключи, которые реально существуют в предметной области и характеризуют соответствующие объекты. Пример представления взаимодействия двух объектов в концептуальной модели но нотации Чена может выглядеть, как показано на рис. 2.45.
|
Рис. 2.45. Пример связи объектов в нотации Чена |
Как очевидно из примера, объект "Клиент" обладает единственным атрибутом "Лицевой счет", который также является первичным ключом. Отсутствие остальных атрибутов вполне объяснимо. В результате анализа предметной области было определено, что в качестве клиентов могут участвовать физические и юридические лица. Оба варианта клиентов обладают собственным уникальным набором атрибутов. Единственным общим атрибутом, к тому же описывающим абстрактный объект "Клиент", является "Лицевой счет", назначаемый клиенту менеджером магазина и однозначно идентифицирущий каждого конкретного клиента.
Для объекта "Заказ" определено большее количество атрибутов, среди которых имеются первичный ключ "Номер", внешний ключ "Клиент" и простой атрибут "Дата". Рассматривая предметную область, разработчик выделял номер в качестве идентифицирующего атрибута для заказа, поскольку он должен иметь уникальный номер для каждого конкретного заказа и не должен повторяться во всей совокупности значений этого атрибута, иначе невозможно будет получить сведения об одном конкретном заказе. Атрибут "Дата" также был выделен при анализе предметной области в качестве характеристики, которая описывает временной фактор формирования заказа, что определило его появление в модели. Третий атрибут, "Клиент", для предметной области является вполне очевидным и описывает клиента, который делает соответствующий заказ. Однако в документ клиента заказ представляется указанием наименования организации или ФИО физического лица. Поскольку ранее было определено, что физическое и юридическое лицо являются объектами-категориями и для них определен объект-общность, то вполне логичным будет использовать именно этот объект для связи с заказом и характеризацией каждого конкретного заказа. Таким образом, получается, что для атрибутивного описания клиента в заказе можно использовать указание на экземпляр объекта "Клиент". Это реализуется с помощью внешнего ключа, который является всего лишь ссылкой.
Под внешним ключом в модели базы данных понимается атрибут, представляемый ссылкой на экземпляр другой сущности (объекта).
Поскольку связь категоризации (рис. 2.46) является частным случаем связи один — к — одному (1:1), то вполне естественным будет тот факт, что между объектами устанавливается идентифицирующая связь, которая определяет однозначное соответствие между экземплярами связываемых сущностей.
Под идентифицирующей связью понимают такое представление связи, когда экземпляр одной сущности (объекта) однозначно представляется экземпляром другой сущности (объекта) и первичный ключ первой сущности (объекта) является элементом первичного ключа второй сущности (объекта).
В представленном примере мы не отражаем одинаковые первичные ключи в первом объекте "Клиент" и втором объекте "Физическое лицо" и "Юридическое лицо". В этом нет необходимости, поскольку целью построения данной модели является иллюстрация взаимосвязей между объектами, а не организация правил храпения данных, что должно быть целью построения модели базы данных.
|
Рис. 2.46. Пример добавления в модель категоризационной связи |
Сами объекты "Физическое лицо" и "Юридическое лицо" характеризуются собственным набором атрибутов. Причем для объекта "Физическое лицо" в рассматриваемой предметной области не имеется первичного ключа. Это вполне обосновано, поскольку атрибут "Фамилия, имя, отчество" не может быть первичным ключом ввиду не уникальности значений в совокупности возможных значений, что может быть определено на основе знаний об этой совокупности в реальном мире.
Для объекта "Юридическое лицо" указаны два атрибута, один из которых, "ИНН", является первичным ключом. Его указание необходимо, поскольку взаимоотношения финансового характера между юридическими лицами, по правилам предметной области, должны осуществляться через документ "Счет", где этот атрибут является идентифицирующим для организации (юридического лица). Указание в качестве первичного ключа не является, в данном случае, обязательным условием для модели, поскольку организацию будет характеризовать атрибут "Лицевой счет", полученный из объекта "Клиент" на основании правил представления идентифицирующей связи. Тем не менее, указанный в качестве первичного ключа атрибут "ИНН" не нарушает требований представления модели.
В процессе построения концептуальной модели добавление объекта "Товар" (рис. 2.47) привело к появлению связи многие — ко — многим (Л!:М), что допустимо с точки зрения нотации Чена, но создает определенную проблему — поскольку в заказе, по условиям предметной области, для каждого указанного товара необходимо не только указать цену
и наименование этого товара, но и его количество, заказанное клиентом, то размещение атрибута "Количество" вызывает определенные проблемы, связанные с невозможностью его размещения на модели. Анализ предметной области показал, то для указания данной характеристики необходимо использование абстрактного объекта "Товар заказа".
|
Рис. 2.47. Пример добавления объекта "Товар" |
Ввод объекта "Товар заказа" (рис. 2.48) в модель и установление связей между этим объектом и связанными объектами "Заказ" и "Товар" позволили реализовать указанное выше требование о хранении сведений по количеству приобретенного товара в определенном заказе. Появление в модели идентифицирующей связи является обоснованным по той причине, что каждый экземпляр объекта "Товар заказа" должен характеризоваться данными из объектов "Заказ" и "Товар", что представлено соответствующими атрибутами в качестве внешних ключей, а их совокупность, отраженная идентифицирующей связью, позволяет говорить об однозначности выделения каждого отдельного экземпляра по совокупности сцепленных ключевых атрибутов.
|
Рис. 2.48. Представление в модели объекта "Товар закала" |
{1 Под сцепленным ключом понимается совокупность атрибутов, представляемых в качестве однотипного ключа.
В рассматриваемом примере сцепленный ключ "Заказ-Товар" является, учитывая идентифицирующую связь, сцепленным первичным ключом, который только в совокупности значений позволит выделить единственный экземпляр объекта "Товар заказа". Построение концептуальной
модели базы данных, во многих случаях, позволяет на начальных этапах моделирования получить необходимое представление модели базы данных, дальнейшие действия над которой связаны в большей степени с техническими процедурами нормализации.
Однако нужно понимать, что для достаточно сложных предметных областей, содержащих несколько десятков или сотен объектов, такие модели, как модели в других нотациях, будут слишком объемными, громоздкими и нечитаемыми. Поэтому целесообразно, в соответствии с анализом бизнес-процессов, выделенными функциями и задачами, строить отдельные небольшие модели, отражающие структурную организацию данных только для соответствующей функции или задачи, с учетом того факта, что они должны быть согласованными в части используемых объектов (сущностей) и их атрибутивного состава, чтобы впоследствии можно было представить единую модель базы данных и сформировать из нее физическую реализацию в СУБД.