Нотация Мартина (Crow's Foot)
Данная нотация является одной из наиболее известных в разработке баз данных, отражающей уровень логического представления базы данных с обозначением некоторых компонентов модели базы данных в графическом виде, облегчая, тем самым, отображение диаграммы в рабочем пространстве. Модели такого типа менее громоздки по сравнению с моделями в нотации Питера Чена. Тем не менее, сложность предметных областей нередко мешает представлению всей модели в рамках единого рабочего пространства, что во многих средствах моделирования баз данных исправляется возможностью формирования и представления моделей базы данных в разрезе отдельных рабочих пространств, которые могут соответствовать функциональному делению предметной области или какому-либо другому фактору, уменьшающему количество рассматриваемых элементов модели базы данных.
Для построения логической модели базы данных в этой нотации разработчик оперирует терминами логического представления базы данных, где элементами хранения данных являются сущности, а не объекты, как в концептуальном представлении. По сути, при последовательном движении в процессе разработки базы данных сущности логической модели базы данных будут иметь соответствие с объектами предметной области, но в процессе моделирования и нормализации моделей возможно появление вспомогательных сущностей, которые не имеют непосредственных представителей в предметной области, но объективно необходимы для эффективного представления и обработки данных. В нотации для представления модели базы данных используются следующие обозначения (табл. 2.15).
Основу всей модели базы данных в нотации Мартина составляют элементы "Сущность", представляемые прямоугольником с указанием существительного в качестве названия сущности. В некоторых случаях допускается использовать словосочетания, обозначающие особенности данных, которые представляются описываемой сущностью. Например, стандарт-
ными наименованиями сущностей могут быть: "Товар", "Заказ", "Клиент" и т.д. При необходимости указания дополнительных характеристик возможны другие наименования сущностей, например "Товар заказа", "Юридическое лицо", "Адреса доставки", "Адреса пунктов выдачи" и т.д. Как очевидно из примеров наименований сущностей, ключевым элементом, тем не менее, остается ключевое существительное, определяющее основу данных, а остальные слова являются дополнительными характеристиками. Однако, в целях удобства последующего использования на физическом уровне разработчики стараются использовать максимально короткие по количеству слов и символов наименования сущностей, но достаточно понятные, чтобы их можно было однозначно интерпретировать и понимать без использования дополнительных материалов.
Таблица 2.15
|
Обозначения в модели базы данных но нотации Мартина
|
При описании сущностей в нотации Мартина (рис. 2.49) и многих других нотациях, в отличие от нотации Питера Чена, атрибуты указываются не рядом с сущностью в виде отдельных элементов модели, а в ней самой, и являются составной частью сущностей. При этом указание на ключевые атрибуты обозначается с помощью соответствующего подчеркивания наименования ключевого атрибута.
|
|
Рис. 2.49. Пример описания сущности в нотации Мартина
Устанавливая связи между сущностями, в нотации Мартина (рис. 2.50) ее смысловое наполнение можно обозначать единственной глагольной формой, имеющей смысл связи от "левой" сущности к "правой" сущности, представляя в качестве "левой" сущности ту, у которой кардинальность связи в верхней се границе равна "1". В случае установления связи многие — ко — многим (№М) "левой" сущностью является та, которая по логике модели является более значимой.
|
Рис. 2.50. Пример установления связи в нотации Мартина |
Тем не менее, поскольку не всегда можно однозначно разделить сущности на "левую" и "правую", разработчиками указывается смысловое наполнение связи двумя глагольными формами, аналогично тому, как это делалось при рассмотрении модели в нотации Чена. Когда определяется смысловое наполнение (рис. 2.51) двумя глагольными формами, то они могут размещаться двумя способами:
• на связи в максимальной близости от сущности, смысл действия которой описывается;
• сверху связи для обозначения смысла связи от "левой" сущности к "правой" и снизу связи для обратной направленности.
|
Рис. 2.51. Пример смыслового наполнения связи в нотации Мартина |
Для представленного примера, как и в нотации Чена, разработчик вынужден выделить вспомогательную функциональную сущность "Товар заказа" с целью указания атрибута "Количество", который не может быть отнесен к сущностям "Товар" и "Заказ". Это в нотации Мартина будет представлено, как показано на рис. 2.52.
|
Рис. 2.52. Представление функциональной сущности-связки в нотации Мартина |
Поскольку при моделировании базы данных на начальном этапе использование внешних ключей не рассматривается, то они не указаны в соответствующих сущностях. Однако, процесс моделирования базы данных, учитывая необходимость последующего формирования физической модели и физической базы данных, требует их указания. Этот процесс, при использовании специализированных инструментальных средств, автоматически, в случае использования связей 1:1 и 1 :N, указывает соответствующие внешние ключи, именуемые точно теми же фразами, как они представлены в первичных ключах базовых сущностей.
При описании связей, в отличие от нотации Чена, кардинальность устанавливается не в виде текстовых обозначений, а соответствующими графическими представлениями на связи. Так, когда нужно указать, что в связи у соответствующей сущности могут отсутствовать связанные экземпляры, то на соответствующем конце будет обозначаться кружок, как, например, между сущностями "Клиент" и "Заказ", где экземпляр клиента может быть представлен в базе данных, не имея ни одного заказа. При этом, когда указывается кардинальность для связи в направлении сущности "Клиент", то указывается две вертикальные черты, обозначающие, что экземпляр клиента, который формирует заказ, обязательно должен существовать. Множественность кардинальности в нотации Мартина обозначается "вороньей лапкой" (Crow's Foot) в виде концевого элемента.
Аналогично другим моделям представления базы данных и предметной области в нотации Мартина используются категоризационные элементы, представляемые сущностью-общностью и сущностями-категориями. Это представление, как и сама суть соответствующей связи, определяет тип связи 1:1с учетом полного описания кардинальности связей (рис. 2.53).
|
Рис. 2.53. Пример указания связи категоризации в нотации Мартина |
Рассматривая связи многие — ко — многим (ММ) и учитывая, что нотация Мартина ориентирована на представление логической модели базы данных, некоторые такие связи никак не преобразовывают до момента выполнения нормализации модели базы данных, и они сохраняются в таком виде, пока не наступит момент перехода от логической модели базы данных к физической.
В рассматриваемом примере такой связью является связь между сущностями "Юридическое лицо" и "Банк", при этом подразумевается, что одно юридическое лицо может иметь несколько счетов в разных банках, а в одном байке могут быть счета множества юридических лиц (рис. 2.54).
|
Рис. 2.54. Пример связи между сущностями "Юридическое лицо" и "Банк" |
Обычно, при установлении подобных связей между сущностями кардинальность с обеих сторон имеет значение "О, Лг". Это вполне логично, поскольку при использовании связи многие — ко — многим между сущностями, когда нет атрибутов, имеющих отношение к связке сущностей, каждая сущность является функционально самостоятельной и экземпляры этих сущностей могут существовать независимо от наличия или отсутствия экземпляров в другой сущности. В результате, общая модель в нотации Мартина по рассмотренным примерам может быть представлена, как показано на рис. 2.55.
|
Рис. 2.55. Пример модели базы данных в нотации Мартина |
В данной модели не использовали внешние ключи и указания на связь с соответствующими объектами предметной области или сущностями базы данных, подразумевая, что указанные связи уже определяют необходимые связи, а их тип позволяет при переходе к физической модели базы данных или в процессе нормализации указать необходимые атрибуты.
В рамках построения логической модели зачастую стоит вопрос представить мифологическую модель, которая является промежуточной между моделью предметной области и логической моделью базы данных, где указание ключевых элементов или ссылок на соответствующие объекты не является необходимым условием.