DataAtlas Modeler - концепции
DataAtlas Modeler представляет собой комбинированное средство для построения как концептуальной, так и логической модели данных. Modeler позволяет создать структуру данных так, чтобы она могла быть понятна и разработчику баз данных, так и конечному пользователю. Modeler поддерживает подход "сущность-взаимоотношение" (ER) для концептуального моделирования данных. Такой подход использует ER-модели для визуального представления структуры данных. ER-модель отображает данные как сущности, атрибуты и взаимоотношения между сущностями, а также ограничения, накладываемые на использования данных.
Концептуальная модель обеспечивает инфраструктуру для логической модели данных. DataAtlas Modeler отображает ER-модель в структуру данных, которая определяется для каждой конкретной системы управления базами данных. Получающийся в результате этого реляционный дизайн состоит из определения таблиц и их экземпляров.
Соответствие концептуальной и логической моделей данных представляется следующим образом:
| Сущность | Таблица |
| Отношение | Внешний ключ или таблица |
| Атрибуты | Столбцы |
| Разделяемые элементы данных | Разделяемые элементы данных |
| Первичные ключи | Первичные ключи |
| Обязательно/Дополнительно | Правила целостности ссылок |
Сущность представляет собой некий объект реального мира, такой как персона, место, событие и тому подобное. DataAtlas Modeler поддерживает следующие типы сущностей, отображаемые на диаграмме разными видами прямоугольников:
 |
1. Фундаментальные - как класс объектов реального мира. |
 |
2. Ассоциативные - для представления отношений с локальными. |
 |
3. Атрибутивные - для отображения составных атрибутов объекта (например, адреса). |
Отношение представляет собой связь между одной или несколькими сущностями. DataAtlas Modeler поддерживает как унарные, так и бинарные отношения.
Пример унарного отношения : "Сотрудник управляет, по меньшей мере, нисколькими и, по большей мере, сколько угодно многими сотрудниками, и, в то же время, сотрудник управляем, по меньшей мере, одним и, по большей мере, одним сотрудником".
Пример бинарного отношения : " Сотрудник имеет, по меньшей мере, нисколько и, по большей мере, сколько угодно много персональных компьютеров, и, в то же время, персональный компьютер принадлежит, по меньшей мере, одному и, по большей мере, одному сотруднику".
Кардинальностью
отношения называется количество встречаемых проявлений сущности, которое может или должно соответствовать каждому проявлению другой сущности. Каждое отношение имеет минимальную и максимальную кардинальность в обоих направлениях. Минимальная кардинальность определяет правила существования для сущности в отношении:
0
- отношение с необязательной сущностью;
I
- отношение с обязательной сущностью.
Максимальная кардинальность
определяет максимальное число экземпляров сущности, которая может иметь место в отношении:
I
- максимально один экземпляр сущности может иметь место в отношении;
X
- число максимальных экземпляров сущности в отношении не ограничено.
Максимальная кардинальность отношения представляется на диаграмме ближе, а минимальная - дальше от фигуры сущности. Кроме того, в DataAtlas Modeler около значков сущности отображаются глаголы действий отношения.
Приведем список всех возможных кардинальностей, так, как они представлены на диаграмме ER-модели в DataAtlas Modeler.
Необязательно один-к-одному.
Обязательно один-к-одному
(с одной обязательной сущностью)
(c обеими обязательными сущностями)
Необязательно один-ко-многим
Обязательно один-ко-многим
(с одной обязательной сущностью)
(с обеими обязательными сущностями)
Необязательно многие-ко-многим
Обязательно многие-ко-многим
(с одной обязательной сущностью)
(с обеими обязательными сущностями)
При описании кардинальности отношения, обычно ссылаются только на максимальную кардинальность. Например, отношения, определенные как многие-ко-многим, означают, что обе максимальные кардинальности устанавливаются в значение "много".
Например, представим себе, что мы хотим смоделировать следующее предложение: "Отдел не имеет сотрудников или имеет много сотрудников, при этом каждый сотрудник обязан работать только в одном отделе". Отношение будет выглядеть следующим образом, где слова "принадлежит" (belongs to) и "имеет" (has) являются глаголами.
Группы сущностей представляют собой именованные множества сущностей. Использование групп сущностей служит для консолидации сущностей, которые принадлежат друг другу, и для иерархической организации ER-модели, что делает данную модель более читаемой и удобной в работе. Например, при разработке модели данных предприятия, можно сгруппировать те сущности, которые соответствуют объектам закупок в группу под названием "закупки". Одна группа сущностей может содержать в себе другие группы сущностей. На диаграмме ER-модели группа сущностей, содержащая другую группу сущностей отображается в виде эллипса.
 |
Атрибут представляет собой объект, описывающий характеристики сущности или отношения. |
Атрибуты могут быть как ключевыми, так и неключевыми. Ключевые атрибуты делятся на первичные ключи и внешние ключи. Первичный ключ всегда является обязательным атрибутом, в то время как внешние ключи и неключевые атрибуты могут быть как обязательными, так и необязательными элементами.
Первичный ключ является атрибутом или группой атрибутов, уникально определяющим каждый экземпляр сущности или отношения. Значение первичного ключа всегда должно быть уникально и не равно пустому значению. Первичный ключ, состоящий из более чем одного атрибута, называется составным первичным ключом. Каждый атрибут, составляющий композитный первичный ключ, называется частичным первичным ключом. Для композитного первичного ключа, значение каждого составляющего его частичного первичного ключа не должно быть пустым.
Внешний ключ представляет собой первичный ключ, определяемый в результате установления отношения. Он определяет, какой экземпляр сущности связывается с экземпляром отношения. Внешний ключ, состоящий из более чем одного атрибута, называется составным внешним ключом. Каждый атрибут, составляющий композитный первичный ключ, называется частичным внешним ключом.
Внешние ключи не являются конструкциями концептуальной модели данных. Поскольку концептуальная модель в DataAtlas Modeler представляет собой основу для реляционной модели, то внешние ключи автоматически генерируются для модели данных. При разработке только концептуальной модели можно проигнорировать создание внешних ключей.
Внешние ключи автоматически создаются при помощи DataAtlas Modeler одним из следующих способов.
От одной сущности к другой через отношение. Например, один человек имеет нисколько или сколько угодно автомобилей, и один автомобиль принадлежит точно только одному человеку. Тогда каждый автомобиль будет иметь в качестве внешнего ключа первичный ключ каждого отдельного человека, и этот внешний ключ будет уникально определять владельца.
Внутри отношения, исходя от участвующих в нем сущностей. Например, если пассажир летает, по меньшей мере, ни одним, а, по большей мере, несколькими рейсами, и каждым рейсом летает от нискольких до нескольких пассажиров, то тогда внешний ключ принимает значение первичных ключей сущностей пассажиров и рейса. Взятые вместе, эти ключи определяют уникальным образом для каждого экземпляра отношения соответствующие экземпляры сущностей.
Ограничение в ER-модели представляет собой правило, которое управляет определением истинности операций работы с данными, такими как вставка, удаление, добавление, связанными с сущностью или отношением. В DataAtlas Modeler можно документировать ограничения. Эта информация в дальнейшем будет использована для определений программирования.
Например, если вы работаете с моделью данных для банка, то можно наложить ограничения на счет, так чтобы находящаяся на нем сумма денег была меньше или равна текущему банковскому балансу. Это предотвратит выдачу суммы денег большей, чем она есть в банке.
Элементы данных совместно используются благодаря средству TeamConnection. В DataAtlas Modeler элемент данных представляет собой объект, определяющий тип данных атрибута. Элемент данных определяет размер и другие характеристики атрибута. Тип данных указывает на внутреннее представление данных, например, real, integer, character или binary.
Каждый атрибут может иметь только один связанный с ним атрибут, однако один элемент данных может быть сопоставлен любому числу различных атрибутов. Так, например, если имеется несколько сущностей с атрибутом возраст, и если в текущей модели данных, возраст всегда представляется целым числом, то при создании одного элемента данных с именем "возраст" и целочисленным типом данных, то этот элемент данных можно сопоставить всем атрибутам "возраст" во всех сущностях.
Для сущностей может применяться техника классификации путем обобществления и спецификации - определения частных свойств. Обобществление группирует вместе общие атрибуты и сопоставляет с ними некую сущность-шаблон или сверхтип. Индивидуальные сущности тогда становятся подтипами сверхтипа. Например, если модель содержит сущности "легковой автомобиль", "грузовик" и "мотоцикл", то они могут разделять некие общие атрибуты и создать сверхтип "моторное средство передвижения". После этого можно размещать общие атрибуты в сверхтипе, а затем соединить сверхтип с его подтипами при помощи объединения. Атрибуты моторного средства передвижения будут приложены к легковому автомобилю, грузовику и мотоциклу. Спецификация означает расщепление посредством подтипов тех сущностей, который содержат только присущие им атрибуты.
Сверхтип
представляет собой сущность, которая описывает надмножество над другими, менее всеобщими сущностями (своими подтипами). Например, сверхтип "атлет" может иметь подтипы "легкоатлет" и "пловец". Все атрибуты и отношения для сверхтипа будут применимы и к его подтипам. Сверхтип соединяется с каждым из своих подтипов при помощи набора наследования.
Подтип
представляет собой сущность, описывающую подмножество другой, более всеобщей сущности (своего сверхтипа). Подтип получает первичный ключ своего сверхтипа как внешний ключ. Атрибуты и отношения сверхтипа. Как правило, подтип имеет дополнительные атрибуты и отношения, которые применимы только к нему, а не к его сверхтипу или другим подтипам его родительского сверхтипа.
Подтип связывается со своим сверхтипом при помощи отношений наследования. Отношением наследования называют отношение между родительским сверхтипом и его подтипами. Отношение наследования всегда имеет следующую кардинальность:
0,1 в направление от сверхтипа к своему подтипу (один экземпляр сверхтипа может не иметь совсем или иметь одно отношение к одному экземпляру сверхтипа). 1,1 в направление от подтипа к своему сверхтипу (один экземпляр подтипа обязан иметь одно и только одно отношение к одному экземпляру сверхтипа).
Эти кардинальности не показываются на диаграмме ER-модели.
В DataAtlas Modeler отношения наследования никогда не существуют независимо, каждое отношение наследования является членом набора наследования.
Набор наследования
представляет собой группу родственных отношений наследования, которая используется для обобществления и спецификации.
В DataAtlas Modeler существуют два правила, определяющие наличие набора наследования:
обязательность или необязательность;
исключительность или неисключительность.
Обязательность
. Каждый экземпляр данного сверхтипа обязан иметь по крайней мере одно отношение к экземпляру одного из своих подтипов. Обязательный набор наследования определяется посредством фразы "must be" (обязан быть), например, "Служащий должен быть только одним из (мужчина, женщина)."
Необязательность
(дополнительность). Каждый экземпляр данного сверхтипа должен не иметь отношения к экземпляру одного из своих подтипов. Необязательный набор наследования определяется посредством фразы "can be" (может быть), например, "Млекопитающее может быть только одним из (дельфин, собака, медведь, кабан)."
Исключительность
(единственность). Каждый экземпляр данного сверхтипа имеет по только одно отношение к экземпляру одного из своих подтипов. Например, служащий имеет подтип мужчина или женщина, но не два этих подтипа сразу. Исключительный набор наследования определяется посредством фразы "at most one of" (только один), например, "Животное должен быть одним из (пресмыкающееся, птица, млекопитающее, насекомое)."
Неисключительность
(множественность). Каждый экземпляр данного сверхтипа имеет одно или несколько отношений к экземпляру одного из своих подтипов. Например, атлет имеет подтипы пловец, легкоатлет, велосипедист, или два из них, или все три. Неисключительный набор наследования определяется посредством фразы "one or more" (один или несколько), например, "Спортсмен может заниматься одним или несколькими видами спорта (плавание, бег, велогонка)."
В DataAtlas Modeler эти конструкции будут отображены в виде диаграмм ER-моделей:
Дополнительная, множественная
Например, любитель музыки может быть как фанатом джаза, так и рока, или обеих стилей. Это необязательное, множественное отношение наследования от сущности "любитель_музыки" (сверхтип) к сущностям "фанат_джаза" и "фанат_рока" (подтипы).
Дополнительная, исключительная
Например, родитель может быть либо отцом, либо матерью, но не обоими сразу. Это необязательное, единственное отношение наследования от сущности "родитель" (сверхтип) к сущностям "отец" и "мать" (подтипы).
Обязательная, множественная
Например, атлет обязан быть либо пловцом, либо бегуном, либо заниматься сразу несколькими видами спорта. Это обязательное, множественное отношение наследования от сущности "атлет" (сверхтип) к сущностям "пловец" и "бегун" (подтипы).
Обязательная, единственное
Например, человек обязан быть либо мужчиной, либо женщиной, но не может быть обоими сразу. Это обязательное, единственное отношение наследования от сущности "человек" (сверхтип) к сущностям "мужчина" и "женщина" (подтипы).
Реляционный дизайн содержит в себе объекты, которые описывают реляционную базу данных, имена таблиц, а также один или несколько физических дизайнов. Каждый физический дизайн содержит в себе объекты, специфичные для целевой системы управления базами данных, например, таблицы и индексы. DataAtlas Modeler поддерживает как преобразование модели данных в реляционный дизайн, так и наоборот, из реляционного дизайна в модель данных.
При трансформации из модели данных в реляционный дизайн, для каждой сущности в модели данных, DataAtlas Modeler создаёт соответствующую таблицу. Он проводит аналогичные действия для каждого отношения, имеющего атрибут, независимо от того, указан ли явно внешний ключ или этот ключ строится при преобразовании. Каждый атрибут преобразовывается в столбец в соответствующей таблице. DataAtlas Designer использует реляционный дизайн для создания физического дизайна и DataAtlas Dictionary использует физический дизайн для создания программ на языке определения данных DDL.
[] []
IBM DataAtlas
Фирма IBM традиционно уделяет большое внимание средствам разработки программного обеспечения и системам управления базами данных. Спектр средств разработки семейства VisualAge лежит в пределах от индивидуального VisualAge для Basic и групповых VisualAge Smalltalk, C++ и Java до сложных CASE систем типа VisualAge PACBase, включая системы проектирования баз данных VisualAge DataAtlas.
Системы проектирования баз данных в настоящее время завоёвывают всё более широкую популярность среди постановщиков задач. Системы проектирования баз данных, с одной стороны, легче и дешевле, нежели полные CASE-системы, с другой стороны, они позволяют грамотно, в рамках концептуальной модели реальной задачи, определять данные и взаимоотношения между ними, что не могут делать средства быстрой разработки программ класса RAD.
Общие сведения.
IBM VisualAge DataAtlas
представляет собой средство для разработчика и администратора баз данных и состоит из двух модулей:
Modeler - для построения абстрактной модели данных; Dictionary & Designer - для работы с реальной базой данных и импорта/экспорта в неё абстрактной модели данных.
На сегодняшний день существуют две версии IBM VisualAge DataAtlas 1.01, ориентированная на работу с реляционными базами данных DB2 для OS/2 и MVS, а также иерархической СУБД IBM IMS (только в режиме Dictionary & Designer), и идущая ей на смену новая версия DataAtlas 2.0.
IBM DataAtlas 2.0 работает под управлением операционных систем IBM OS/2 Warp 3 и 4 (Modeler и Dictionary/Designer) и MS Windows NT 3.5x и 4 (Dictionary/Designer, осенью и Modeler). В качестве поддерживаемых баз данных могут быть:
DB2 Common Server V2 (OS/2, Windows NT, AIX, HP/UX, Sinix, Solaris, SCO UNIX, Irix); DB2 Common Universal Database (OS/2, Windows NT, AIX, HP/UX, Sinix, Solaris, SCO UNIX, Irix); DB2 в составе OS/400 для мини-ЭВМ серии AS/400; DB2 для MVS V3; DB2 для OS/390 версий 4 и 5; IBM IMS версий 4, 5 и 6; 7. Oracle.
Кроме того существует возможность создания файлов-заголовков на языке PL/I (существующего в реализации IBM для OS/2, Windows 95&NT, AIX, OS/400, OS/390), и планируется в качестве плановых обновлений поддержка языков COBOL и 4GL (системы VisualAge Generator).
IBM VisualAge DataAtlas работает как компонент универсальной среды разработчика IBM VisualAge TeamConnection, которая включается в комплект стандартной поставки DataAtlas.
IBM VisualAge TeamConnection.
IBM VisualAge TeamConnection представляет собой систему для многопользовательской работы группы программистов в среде Internet/intranet, базирующуюся на объектной (пост реляционной) базе данных ObjectStore, обеспечивая:
Контроль и администрирование версий программного продукта. Автоматическую генерацию и компиляцию программного кода на нескольких гетерогенных платформах. Обмен объектами между несколькими программистами. Защиту информации разработчиков от несанкционированного доступа. Возможность подключения разнообразных программных модулей (например, DataAtlas, VisualAge Generator, IBM FlowMark, IBM Visual Requirement Tool и других).
Преимущества от использования TeamConnection для ведения корпоративного проекта можно сравнить разве что с тем революционным нововведением, которым для мира аппаратного обеспечения стала концепция общей шины.
Работа с TeamConnection начинается с запуска сервера объектной пазы данных ObjectStore, которая реализована для платформ IBM OS/2 Warp и AIX, MS Windows NT и Hewlett Packard HP/UX. Проекты находятся в объектных базах данных, называемых семействами. Каждое такое семейство объектов автономно и активируется при помощи соответствующего процесса-демона с указание сервиса процесса в файле настроек TCP/IP /etc/services. Семейство представляет собой иерархию объектов, которой может управлять администратор данного семейства. Элементы такой иерархии называются компонентами. Компоненты могут иметь насколько версий-реализаций, которые также может определять пользователь данного объекта. "Мгновенный снимок" данного объекта, с соответствующими компонентами и их версиями называется рабочей областью, с помощью которой и ведется работа с самим текущим проектом. Сами компоненты представляют собой высокий уровень абстракции и могут реально соответствовать любому элементу, определенному программистом: типам данных, реляционным моделям, транслированным классам графического интерфейса, программному коду и так далее.
К серверу IBM VisualAge TeamConnection может подключаться несколько гетерогенных клиентов, при этом каждый клиент также может быть и сервером TeamConnection, содержащим несколько семейств. Администрация проекта ведется средствами протокола TCP/IP и может быть произведена как средствами командной строки (или языка C-shell в UNIX и REXX в OS/2), так и при помощи специальной графической утилиты. Примеры грамотного и удобного администрирования хорошо и подробно описаны в прилагаемых к пакету руководствах как для начинающих, так и для опытных пользователей.
Каждый пользователь может создавать свои собственные объекты и управлять ими при помощи графического интерфейса (рис.2) или командной строки и языка управления заданиями.
Рис.2. Графический экран клиентской части TeamConnection.
В случае последующего использования IBM VisualAge DataAtlas необходимо определить компонент, его версию-реализацию и рабочую область.
Николай Смирнов,
ответственный за маркетинг
Телефон: +7 (095)940-2000 4255
Факс: +7 (095) 940-2070
E-mail:
[] []
Поддержка пользователей.
IBM осуществляет как предпродажную (включая инсталляцию и показ основных навыков работы), так и послепродажную (гарантировано 60 дней с момента первого обращения) бесплатную поддержку IBM VisualAge DataAtlas. Кроме того, проводятся углублённые курсы по DataAtlas, DB2 и IBM VisualAge Generator. Каждый заинтересованный пользователь может также получить 60 дневную полнофункциональную версию IBM DataAtlas (с полной экранной документацией) для ознакомления и самообразования. Кроме того все плановые обновления (в пределах одной версии) доступны пользователю по Internet или из офиса IBM.
[] []
Практическая работа с DataAtlas Modeler
Основной экран DataAtlas Modeler выглядит следующим образом (рис.3). С его помощью можно создавать новые модели, шаблоны документации и работать с готовыми документами-описаниями.
Рис.3. Основной экран DataAtlas Modeler.
При создании новой модели на экране появляется древообразная структура, отображающая различные элементы ER-модели. Создание новых сущностей начнается с определением дизайнером базы данных новой групы сущностей (рис.4) или импортом уже существующего реляционного дизайна или CASE-модели стороннего производителя.
Рис.4. Структура ER-модели.
После определения сущностей можно при помощи манипулятора типа "мышь" связать их, определив отношения в концептуальной модели данных, назначив глаголы (verbs) отношений и аттрибуты отношений (рис.5).
Далее для каждой сущности (рис.6) строятся аттрибуты, тип данных которых предварительно определяются из общего репозитория IBM TeamConnection (рис.7).
После создания модели и её проверки на непротиворечивость (верификации) можно создать и распечатать документацию (рис.8). Заметим, что в шаблонах документов и комментариях к каждому объекту модели могут использоваться русские буквы, что значительно повышает потребительские свойства IBM VisualAge DataAtlas на российском рынке.
Рис.5. Взаимоотношения между сущностями.
Рис.6. Определение сущности.
Рис.7. Определение типов данных аттрибутов.
Рис.8. Документированная ER-модель.
В завершающей стадии работы с ER-моделью её можно перевести в реляционную модель для испоьзования с конкретной базой данных (рис.9) и далее работать с DataAtlas Dictionary and Designer.
Рис.9. Преобразование ER-модели в реляционную модель.
DataAtlas Dictionary & Designer.
Дизайн базы данных
- это связующее звено между хранимыми данными и производительностью всей базы данных в целом.
DataAtlas Designer
помогает разработчику или администратору базы данных в сложных и часто встречающихся процедурах оптимизации хранения данных. Основными задачами, решаемыми DataAtlas являются следующие действия:
оценка загрузки данных и рабочая нагрузка для разрабатываемого приложения;
определение и связывание дополнительных ресурсов (таких как индексы, области таблиц, пространства буферов);
- решение о физическом выравнивании данныx (таких как кластеризация индексов);
- решение о размещении данных;
DataAtlas Designer управляется при помощи интуитивно понятного интерфейса на основе "записных книжек", которые используются как для описания свойств объектов, так и для работы с настройками базы данных.
DataAtlas Designer позволяет также получать информацию от встроенной системы анализа дизайна и решения проблем. Имеются следующие типы советов и поддержки:
информация о потенциальных проблемах дизайна;
предложение об наиболее оптимальном дизайне базы данных;
проверка целостности и непротиворечивости текущего дизайна.
По запросу, представленные шаги определения дизайна обрабатываются автоматически.
Процесс дизайна баз данных может быть рассмотрен в двух основных перспективах:
"прямая" разработка - создание новой базы данных;
"обратная" разработка - улучшение дизайна уже существующей базы данных.
DataAtlas Designer поддерживает оба способа разработки.
DataAtlas Dictionary
дает разработчику базы данных методы для управления, разделения ресурсов и стандартизации определения данных, связанных с реляционными базами данных, иерархическими базами данных IBM IMS и приложений на языках разработки высокого уровня. DataAtlas Dictionary использует IBM VisualAge TeamConnection для хранения, обработки, и разделения объектов баз данных с модулями DataAtlas Designer и Modeler и другими средствами разработки (например, IBM VisualAge Generator).
После старта модуля DataAtlas Dictionary & Designer (рис.10) администратор системы управления базами данных может экспортировать данные из уже существующих реляционных и иерархических баз данных, либо создать свою собственную папку для работы с информацией, выбранной из общего репозитария TeamConnection или определенной самим администратором.
Рис.10. Основной экран DataAtlas Dictionary and Designer.
В папке хранится определение таких объектов, как реляцонный дизайн, база данных, таблицы базы данных, индексы и тому подобное (рис.11).
Рис.11. Рабочая папка с объектами, опеделяющими конкретую базу данных.
При работе с атрибутами и индексами таблиц баз данных, администратор может сам определять их структуру (рис.12). Таблицы, индексы и другие объекты, ответственные за структуру данных, имеют опцию контекстного меню "Generate to file" для создания командных файлов на языке описания данных Data Definition Language (DDL). Эти файлы можно исполнить как в интерпретаторе DB2, так и в пакетном или программном (С++, COBOL, Java) файле. Например получив файл my1.ddl, можно дополнить его предложениями:
create database MY1; connect to MY1;
(автоматически сгенерированный код)
и запустить на исполнение командой
db2 -f my.ddl -t
создав таким образом новую базу данных с именем MY1 из существующих в репозитории объектов.
Рис.12. Явное определение структуры таблицы.
Возможно обратное преобразование, когда из реальной физической базы данных можно получить определения объектов для дальнейшей работы в IBM VisualAge DataAtlas (рис.13).
Рис.13. Преобразование определений физической базы данных в реляционный дизайн.
Примеры трансформации объектов модели данных.
Отношение один-к-одному, где зависимая сущность имеет дополнительное отношения к родительской сущности
"Персональные компьютеры принадлежат инженерам, но не все инженеры имеют персональные компьютеры"
CREATE TABLE Engineer ( en_num INT NOT NULL, pc_num INT, PRIMARY KEY (en_num) ) CREATE TABLE PC ( pc_num INT NOT NULL, en_num INT, PRIMARY KEY (pc_num), FOREIGN KEY (en_num) REFERENCES Engineer ON DELETE SET NULL )
Отношение один-к-одному, где зависимая сущность имеет обязательное отношения к родительской сущности
"У каждого отдела должен быть начальник, но начальник должен быть начальником только одного отдела"
CREATE TABLE Manager ( mgr_num INT NOT NULL, PRIMARY KEY (mgr_num) ) CREATE TABLE Dept ( dep_num INT NOT NULL, mgr_num INT NOT NULL, PRIMARY KEY (dep_num), UNIQUE (mgr_num) FOREIGN KEY (mgr_num) REFERENCES Manager ON DELETE RESTRICT )
Отношение один-к-одному, где обе сущности обязательны.
"Государство имеет одного правителя и правитель правит только одним государством"
CREATE TABLE State ( st_name CHAR(20) NOT NULL, gv_name CHAR(20) NOT NULL, PRIMARY KEY (st_name)) CREATE TABLE Governor ( st_name CHAR(20) NOT NULL, gv_name CHAR(20) NOT NULL, PRIMARY KEY (dv_name), UNIQUE (st_name) FOREIGN KEY (st_name) REFERENCES State ON DELETE RESTRICT )
Отношение один-ко-многим, где зависимая сущность имеет необязательное отношение к родительской сущности.
"У инженера есть только одна секретарша, однако одна секретарша может работать на несколько инженеров"
CREATE TABLE Secretary ( sc_num INT NOT NULL, PRIMARY KEY (sc_num)) CREATE TABLE Engineer ( en_num INT NOT NULL, sc_num INT, PRIMARY KEY (en_num), FOREIGN KEY (sc_num) REFERENCES Secretary ON DELETE SET NULL )
Отношение один-ко-многим, где зависимая сущность имеет обязательное отношение к родительской сущности.
"У каждого инженера обязательно есть только одна секретарша, однако одна секретарша может работать на несколько инженеров"
sc_num INT NOT NULL, PRIMARY
CREATE TABLE Secretary ( sc_num INT NOT NULL, PRIMARY KEY (sc_num) ) CREATE TABLE Engineer ( en_num INT NOT NULL, sc_num INT, PRIMARY KEY (en_num), FOREIGN KEY (sc_num) REFERENCES Secretary ON DELETE RESTRICT )
Отношение многие-ко-многим.
"В профессиональное объединение входят как инженеры, так и не инженеры, в то же время, инженер может состоять в нескольких профессиональных ассоциациях."
CREATE TABLE PrfAsso ( ac_num INT NOT NULL, PRIMARY KEY (ac_num) ) CREATE TABLE Engineer ( en_num INT NOT NULL, PRIMARY KEY (en_num) ) CREATE TABLE Association_Engineer ( en_num INT NOT NULL, ac_num INT NOT NULL, PRIMARY KEY (en_num, ac_num), FOREIGN KEY is_mem_1 (en_num) REFERENCES Engineer ON DELETE CASCADE, FOREIGN KEY is_mem_2 (ac_num) REFERENCES PrfAsso ON DELETE CASCADE )
Отношение с атрибутами.
"Лекарства производятся по лицензии фирмы. Фирма лицензировала производство нескольких деталей. Дата выдачи лицензии является атрибутом отношения".
CREATE TABLE Drug ( dt_num INT NOT NULL, PRIMARY KEY (dt_num) ) CREATE TABLE DrManu ( fm_num INT NOT NULL, PRIMARY KEY (fm_num) ) CREATE TABLE Drug_Firm ( dt_num INT NOT NULL, fm_num INT NOT NULL, Date, PRIMARY KEY (dt_num, fm_num), FOREIGN KEY lic_1 (dt_num) REFERENCES Drug ON DELETE CASCADE, FOREIGN KEY lic_2 (fm_num) REFERENCES DrManu ON DELETE CASCADE )
Отношение наследования
"Компонент устройства может быть как стандартным компонентом, так и компонентом, выполненным на заказ".
CREATE TABLE Component ( comp_id INT NOT NULL, PRIMARY KEY (comp_id) ) CREATE TABLE Standard ( inv_num INT NOT NULL, comp_id INT NOT NULL, PRIMARY KEY (inv_num), UNIQUE (comp_id), FOREIGN KEY (comp_id) REFERENCES Component ON DELETE RESTRICT ) CREATE TABLE Make_To_Order ( ord_num INT NOT NULL, comp_id INT NOT NULL, PRIMARY KEY (ord_num), UNIQUE (comp_id), FOREIGN KEY (comp_id) REFERENCES Component ON DELETE RESTRICT )
При переносе из реляционного дизайна в модель данных можно не использовать средства моделирования данных. DataAtlas Dictionary обеспечивает способ, посредством которого информация из каталога баз данных переносится в объекты системы TeamConnection с таблицами и определениями таблиц. После этого можно преобразовать полученную таким путем модель данных в модель данных, работающую с DataAtlas Modeler.
[] [] []
