Нотация UML. 
Базы данных: проектирование

Множество современных информационных систем строится на основе объектно-ориентированной технологии, и используемые в них базы данных зачастую реализуются гоже по этим принципам. Современные технологии разработки и программирования дают достаточно большой набор инструментов для реализации объектно-ориентированных баз данных, а также реляционных баз данных, используя нотацию и язык описания им К. В целях разработки баз данных в 1ШЬ применяется диаграмма классов, которая, при необходимом расширении, показывает не только структуру базы данных с ограничениями ссылочной целостности, но и описания механизмов обработки соответствующих данных. Для описания структуры базы данных в иМБ применяются обозначения, показанные в табл. 2.17.

Описание объектов предметной области, представляемых в логической модели базы данных в виде сущностей, в нотации иМБ выполняется с помощью классов (рис. 2.63), где наименование класса представляется в верхней (первой) части обозначения, а атрибутивный состав размещается во втором блоке обозначения класса.

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

Рис. 2.63. Пример представления класса в нотации UML.

В нотации UML нет специального обозначения для представления связи многие — ко — многим, но суть данного типа связи фактически представляет связывание равноправных элементов, что в UML может быть представлено ассоциативной связью между равноправными классами (рис. 2.64). Особенность этого обозначения заключается в том, что на концах линии отсутствуют какие-либо концевые элементы, а кардинальность, указываемая на ассоциативных связях, обладает верхней границей значения — «*», что обозначает возможность представления множества экземпляров соответствующего класса.

Рис. 2.64. Ассоциативная связь между равноправными классами.

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

Другим вариантом ассоциативной связи является связь, показывающая взаимодействие экземпляров классов в рамках указания направленности навигации или агрегации (рис. 2.65). Направленность навигации в ассоциативной связи показывает необходимость использования экземпляра первого класса в составе экземпляра второго класса. При этом, как правило, экземпляр первого класса во втором классе представляется в единственном варианте, а использоваться может во множестве экземпляров второго класса. Тем самым, ассоциативная связь с направлением навигации дает возможность представить простую связь один — ко — многим.

Рис. 2.65. Пример ассоциативной связи с направлением навигации.

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

Поскольку для классов данных важно понимание отношения друг к другу и определение его в виде «Целое/часть», то в модели классов нужно показывать это отношение, что иллюстрируется наличием концевого элемента «Ромб» в закрашенном или не закрашенном виде (рис. 2.66).

Рис. 2.66. Пример агрегатной ассоциации «Целое/часть» .

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

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

Рис. 2.67. Пример использования связи зависимости.

Например, в рассматриваемом примере объект «Товары заказа» является связкой между товаром и заказом, формируя на сцепке элемент предметной области, обозначающий количество заказываемых единиц конкретного товара в рамках одного заказа. Здесь для работы используется три класса, два из которых — «Товар» и «Заказ» , — являются равноправными, и разработчик показывает между ними простую ассоциативную связь (сплошная линия). Но класс «Товары заказа», являясь зависимым от этих классов, должен быть связан с ними связью зависимости (пунктирная линия). Для обозначения зависимости от обоих классов в нотации предусматривают возможность иллюстрации связи зависимости не от каждого родительского класса, а от ассоциативной связи, обозначая мощность (кардинальность) связи зависимости относительно каждого родительского класса.

Так же, как и в других нотациях, учитывая необходимость иллюстрации возможности разделения объектов на категории с собственным набором атрибутов, в нотации 1ШЬ используют такую связь, которая называется «Связь обобщения» (рис. 2.68).

В модели классов рассматривается не разделение элементов, а их обобщение, что показывается соответствующим изображением связи — линия с концевой стрелкой в направлении класса-общности. Для рассматриваемого примера объект «Клиент» является общностью для объектов «Физическое лицо» и «Юридическое лицо», поэтому, обозначая связь, разработчик будет ее показывать в виде стрелки, направленной к классу «Клиент». В результате моделирования диаграммы классов в нотации UML разработчиком будет представлена модель, которая показана на рис. 2.69.

Рис. 2.68. Пример использования связи обобщения.

Рис. 2.69. Модель классов в нотации ЬТМЬ.

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