1626434812-e667f6b6e7e69d3a0798830a58e9075b (844135), страница 21
Текст из файла (страница 21)
Во втором подходе реализуется автоматизированная компиляция концептуальной модели ПО в схему БД (чаще всего реляционную). Известны два подхода: ! . Подход, основанный на явном представлении концептуальной модели ПО как исходной информации для компиляции. 2. Подход, ориентированный на построение интегрированных систем проектирования с автоматизированным созданием концептуальной модели ПО на основе интервью с экспертами предметной области.
И в том, и в другом случае в результате производится реляционная схема базы данных в третьей нормальной форме. Наконец, третий подход — это непосредственная работа с базой данных в семантической модели, т.е. применение СУБД, основанных на семантических моделях данных. При этом снова рассматриваются два варианта: 1.
Обеспечение пользовательского интерфейса на основе семантической модели данных с автоматическим отображением конструкций в реляционную модель данных (это задача примерно такого же уровня сложности, как автоматическая компиляция концептуальной модели ПО в схему БД). 2. Прямая реализация СУБД, основанная на какой-либо семантической модели данных. Наиболее близко ко второму варианту находятся современные объектноориентированные СУБД, модели данных которых по многим параметрам близки к семантическим моделям (хотя в некоторых аспектах они более мощны, а в некоторых — более слабы).
Хотя в целом можно сказать, что этот подход еще не вышел за пределы исследовательских и экспериментальных проектов. В настоящее время на рынке программного обеспечения появилось достаточно много универсальных (пе привязанных к какой-либо конкретной СУБД) пакс- Глава 5. Семантическое моделирование в оазах данных тов автоматизированного проектирования БД, позволяющих производить концептуальное моделирование ПО. В основе практически всех систем такого рода лежит та или иная интерпретация ЕК-модели. Такие системы являются реализацией второго из рассмотренных выше подходов.
Одним из наиболее популярных программных продуктов в этой области является ЕКмп компании Р!айцгп[241. 5.б. Средство автоматизированного проектирования баз данных Ейлип 5.6.1. Общие сведении ЕКччп — САЗЕ-средство проектирования баз данных фирмы Р!а!1пцгп. ЕКи1п сочетает графический интерфейс Мхова, инструменты для построения ЕК- диаграмм, редакторы для создания логического и физического описания модели данных и прозрачную поддержку ведущих реляционных СУБД, Для удобства изложения материала здесь и далее использована оригинальная терминология, принятая в Ейлчп.
ЕКъчп не привязан к технологии какой-либо конкретной фирмы, поставляющей СУБД или средства разработки. Он поддерживает различные серверы баз данных и настольные СУБД, а также может обращаться к базе данных через интерфейс ОРВС. Так, в текущей версии ЕЮип 3.5.2 встроена поддержка 23 СУБД, среди которых: Огас!е, М1сгозой Я;6. Зег~ег и т.п. ~см, рис. 5.6.25).
Заметим лишь, что речь идет только о реляционных СУБД. ЕКмчп 3.5,2 можно использовать совместно с некоторыми популярными средствами разработки клиентских частей приложений: РоюегВц1Ыег, У1зца! Ваз1с, Ре1р!й. Кроме того, ЕКмп 3.5.2 поддерживает работу в среде групповой разработки Моде!Маг!, являвшейся продуктом той же Р1а1!пшп. Процесс моделирования в ЕКччп базируется на методологии проектирования реляционных баз данных 1РЕГ1Х. Данная методология была разработана для ВВС США и теперь широко используется в правительственных учреждениях и частных компаниях как в самих США, так и далеко за их пределами.
Она определяет стандарты терминологии и графического изображения типовых элементов на ЕК-диаграммах. Заметим, что некоторые обозначения могут несколько расходиться с традиционными, принятыми в ЕК-модели, хотя в ЕКччп версии 3.5.2 уже сушествует возможность выбора традиционной нотации. ~При изложении матсриала использована нотация ЮЕГ1Х). Кроме того, существует ряд отличий, связанных с тем, что данная методология ориентирована на разработку реляционных БД. Но это не вносит заметных корректив в сам подход к разработке структуры БД, а жесткая стандартизация позволяет избежать такого недостатка ЕК-моделей, как возможность различной трактовки. Базы данных. Интеллектуальная обработка ияформации В данном параграфе рассмотрен процесс создания модели в Ейв1п, описаны основные элементы интерфейса, а также приведен пример разработки структуры БД. Для более детального изучения возможностей данного САБЕ- средства читатель может обратиться к книге ~~7'.
Определения некоторых понятий методологии 10ЕНХ, приведенные в данном параграфе, взяты из статьи 1261. 5.6.2. Структура процесса моделирования в ЕКмчп В ЕРлчп используются два уровня представления модели данных: логический и физический (что соответствует концептуальному и логическому уровшо, принятым в теории БД).
На логическом уровне не рассматривается использование конкретной СУБД, не определяются типы данных (например, целое или вещественное число) и не определяются индексы для таблиц. Целевая СУБД, имена объектов и типы данных, индексы составляют второй (физический) уровень модели ЕКчлп. Ейлип предоставляет возможности создавать и управлять этими двумя различными уровнями представления одной диаграммы (модели), равно как и иметь много вариантов отображения на каждом уровне.
Процесс построения информационной модели состоит из следующих этапов: 1. создание логической модели данных: ° определение сущностей; ° определение зависимостей между сущностями; ° задание первичных и альтернативных ключей; ° определение неключевых атрибутов сущностей; 2.
переход к физическому описанию модели: назначение соответствий имя сущности — имя таблицы, атрибут сущности — атрибут таблицы; ° задание триггеров, хранимых процедур и ограничений; 3. генерация базы данных. 5.6.3. Создание логической модели БД С точки зрения пользователя Еймчп, процесс создания логической модели данных заключается в визуальном редактировании ЕК-диаграммы. Диаграмма ЕВмчп строится из трех основных блоков: сущностей, атрибутов и связей.
5.6.3.1. Сущности и атрибуты На диаграмме сущность изображается прямоугольником. В зависимости от режима представления диаграммы прямоугольник может содержать имя сущности, ее описание, список ее атрибутов и другие сведения. Основная информация, описывающая сущность, включает: Глава 5. Семантическое моделирование в базах данных ° атрибуты, составляющие первичный ключ; ° неключевые атрибуты; ° тип сущности (независимая/зависимая).
Первичный ключ — это атрибут или набор атрибутов, уникально идентифицирующий экземпляр сущности. Если несколько наборов атрибутов могут уникально идентифицировать сущность, то выбор одного из них осуществляется разработчиком на основании анализа предметной области и учета следующих требований к первичному ключу: ° первичный ключ не должен принимать пустые (ХЖЕ) значения; ° первичный ключ не должен изменяться в течение времени; ° размер первичного ключа должен быть как можно меньшим. При этом если разработчик считает, что какой-либо из оставшихся наборов будет часто использоваться для доступа к сущности, то он может объявить его альтернативным ключом. В ЕКъчп можно также составлять группы атрибутов, которые не идентифицируют уникально экземпляры сущности, но часто используются для доступа к данным.
Они получили название инверсных входов. Одни и те же атрибуты сущности могут входить в несколько различных групп ключей. Рассмотрим вышесказанное на примере сущности СОТРУДНИК (рис. 5.6.1). СОТРУДНИК Рис. 5.6.1. Пример суи1ности Среди всех атрибутов данной сущности на роль первичного ключа могут претендовать "табельный номер" и группа атрибутов "фамилия", "имя", "отчество", "дата рождения" (последний необходим„т.к. на предприятии могут работать полные тезки). Очевидно, что по соображениям размера в качестве первичного ключа следует выбрать первый из вариантов.
Базы данных. Интеллектуальная обработка информации На диаграмме атрибуты, составляющие первичный ключ, располагаются в всрхней части прямоугольника и отделяются от прочих (не входящих в первичный ключ) горизонтальной линией. Группа атрибутов "фамилия", "имя", "отчество"„"дата рождения" может являться альтернативным ключом.
Однако вряд ли кто-либо, пытающийся найти информацию о сотруднике, будет знать дату его рождения. А вот группа атрибутов "фамилия", "имя", "отчество", вполне возможно„будет достаточно часто использоваться для этих целей. Поэтому на основе этих атрибутов было бы логично создать инверсный вход. Инверсный вход обозначается па диаграмме символами 1Еп, заключенными в скобки. Пример использования альтернативного ключа приведен на рис. 5.6.2. Альтернативный ключ обозначается на диаграмме символами АКп, заключенными в скобки.
ОТДЕЛ Рис. 5.6.2. Пример альтернативного ключа Если экземпляры сущности могут быть уникально идентифицированы без определения ее связей с другими сущностями, она называется независиыай. В противном случае сущность называют зависимой. Зависимая сущность отображается в ЕЮчп прямоугольником с закругленными углами. 5.6.3.2. Связи Связь в ЕКи1п трактуется как функциональная зависимость между двумя сущностями (в частности, возможна связь сущности с самой собой).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
