проектирование БД. Методичка Пример проектирования модели и нормализации. Пример проектирования модели и проведения нормализации
 Скачать 483 Kb.
|
Изучение основных функций пакета ERwin.ERwin - средство концептуального моделирования БД, использующее методологию IDEF1X. ERwin реализует проектирование схемы БД, генерацию ее описания на языке целевой СУБД (ORACLE, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server, Progress, Interbase и др.) и реинжиниринг существующей БД. Построение моделей в ERwinВозможны две точки зрения на информационную модель и, соответственно, два уровня модели. Первый - логический уровень (точка зрения пользователя) означает прямое отображение фактов из реальной жизни. Например, люди, столы, отделы, собаки и компьютеры являются реальными объектами. Они именуются на естественном языке, с любыми разделителями слов (пробелы, запятые и т.д.). На физическом уровне модели рассматривается использование конкретной СУБД, определяются типы данных (например, целое или вещественное число), индексы для таблиц. ERwin предоставляет возможности создавать и управлять этими двумя различными уровнями представления одной диаграммы (модели), равно как и иметь много вариантов отображения на каждом уровне. Термин "логический уровень" в ERwin соответствует концептуальной модели. Этапы построения информационной модели:определение сущностей; определение зависимостей между сущностями; задание первичных и альтернативных ключей; определение атрибутов сущностей; приведение модели к требуемому уровню нормальной формы; переход к физическому описанию модели: назначение соответствий имя сущности - имя таблицы, атрибут сущности - атрибут таблицы; задание триггеров, процедур и ограничений; генерация базы данных. Erwin создает визуальное представление (модель данных) для решаемой задачи. Это представление может использоваться для детального анализа, уточнения и распространения документации, необходимой в цикле разработки. Однако ERwin далеко не только инструмент для рисования. ERwin автоматически создает базу данных (таблицы, индексы, хранимые процедуры, триггеры для обеспечения ссылочной целостности и другие объекты, необходимые для управления данными). Запуск программы и создание новой модели.После запуска программы ERwin в появившемся диалоге нужно выбрать пункт «Create model» (Создать модель). После этого появляется диалог, при помощи которого задаются свойства новой модели. Необходимо выбрать тип новой модели (New Model Type) – Logical/Physical, т.е. будет создаваться как логический уровень модели так и ее физическое описание. Также нужно задать вид базы данных (Target Database), для которой будет проведена генерация базы данных – необходимо выбрать InterBase.  Рисунок 10 Создание сущности.Для внесения сущности в модель необходимо щелкнуть по кнопке сущности на панели инструментов (Erwin Toolbox)  . Имя сущности по умолчанию будет «E/1», поменять его можно щелкнув на заголовке и введя новое имя с клавиатуры. Введем имя «Авиамаршрут». Таким же образом вставьте в диаграмму сущности «Рейс», «Член Экипажа», «Личность», «Авиакомпания», и других из модели рассмотренной в предыдущей главе. Создание атрибутов.Для описания атрибутов следует, щелкнув правой кнопкой по сущности, выбрать в появившемся меню пункт Attribute Editor. Появится диалог Attribute Editor. Если щелкнуть по кнопке New, то в появившемся диалоге New Attribute можно указать имя атрибута, имя соответствующей ему в физической модели колонки и домен. Домен атрибута будет использоваться при определении типа колонки на уровне физической модели. При проектировании необходимо представлять, какой тип должен выбираться для каждого атрибута сущности, если атрибут должен представлять текстовую информацию – выбираем «String», если цифровую, то - «Number», если информацию о времени или дате (или о том и другом сразу) то «Datetime», и наконец тип «Blob» используется если информация имеет неструктурированный характер (например текст произвольной длины или изображение). Для атрибутов первичного ключа в закладке General диалога Attribute Editor необходимо поставить флажок Primary Key. Очень важно дать атрибуту правильное имя, которое должно записываться в поле «Attribute Name» (Имя Атрибута). Атрибуты должны именоваться в единственном числе и иметь четкое смысловое значение. Согласно синтаксису IDEF1X, имя атрибута должно быть уникальным в рамках модели (а не только в рамках сущности!).  Рисунок 11 Создание атрибута InterBase не допускает символов кириллицы в именах объектов метаданных. Поэтому нам необходимо изменить имена для физического представления атрибутов, которые должны записываться в поле «Column Name» (имя колонки). Имя колонки может содержать только латинские буквы, цифры и символ подчеркивания, рекомендуется использовать только буквы в верхнем регистре, пробелы в имени не допустимы. Для систематизации имен колонок рекомендуется использовать единые правила их именования, например, сначала должен следовать префикс, показывающий какой таблице принадлежит эта колонка, затем символ подчеркивания, и, наконец, собственно смысловое имя. Так для атрибута «Код Города» имя колонки будет «CT_CODE», префикс CT от имени таблицы «CITY» (Город). При переносе атрибутов внутри и между сущностями можно воспользоваться техникой drag&drop, выбрав кнопку  в палитре инструментов.Создание связи.После того как определены все сущности, необходимо задать связи между ними. Связь в ERwin трактуется как функциональная зависимость между двумя сущностями. Если рассматривать диаграмму как графическое изображение предметной области, то сущности являются существительными, а связи - глаголами. Например, между сущностями «ГОРОД» и «АЭРОПОРТ» имеет место связь «находиться в». Для создания новой связи следует выбрать идентифицирующую или неидентифицирующую связь в палитре инструментов (ERwin Toolbox), щелкнуть сначала по родительской, а затем по дочерней сущности. В палитре инструментов кнопка  соответствует идентифицирующей связи, кнопка  связи многие-ко-многим (связь многие-ко-многим возможна только на уровне логической модели данных, поэтому при построении моделей отношений многие-ко-многим необходимо избегать) и кнопка соответствует неидентифицирующей связи. Для редактирования свойств связи следует щелкнуть правой кнопкой мыши по связи и выбрать на контекстном меню пункт Relationship Editor. Для редактирования свойств связи следует щелкнуть правой кнопкой мыши по связи и выбрать на контекстном меню пункт Relationship Editor. В закладке General появившегося диалога можно задать мощность, имя и тип связи. Мощность связи (Cardinality) - служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней. Различают четыре типа мощности: общий случай, когда одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности, не помечается каким-либо символом; символом P помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение). (В нашем случае такую мощность имеет смысл проставить для отношения АВИАКОМПАНИЯ – БОРТ, что означает, что у авиакомпании есть хотя бы один самолет); символом Z помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключены множественные значения); цифрой помечается случай, когда одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочерней сущности.          Рисунок 12 Панель задания мощности отношения По умолчанию символ, обозначающий мощность связи, не показывается на диаграмме. Для отображения имени следует в контекстном меню, которое появляется, если щелкнуть правой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Display Options/Relationship (Показать свойства отношений) и затем включить опцию Cardinality (Мощность). Тип связи (идентифицирующая/неидентифицирующая). В IDEF1X различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Когда рисуется идентифицирующая связь, ERwin автоматически преобразует дочернюю связь в зависимую. Зависимая сущность изображается прямоугольником со скругленными углами. Экземпляр зависимой сущности определяется только через отношение к родительской сущности. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности автоматически переносятся в состав первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешние ключи - (FK). При установлении неидентифицирующей связи дочерняя сущность остается независимой, а атрибуты первичного ключа родительской сущности мигрируют в состав неключевых компонентов дочерней. Неидентифицирующая связь служит для связи независимых сущностей. Идентифицирующая связь показывается на диаграмме сплошной линией с жирной точкой на дочернем конце связи, неидентифицирующая - пунктирной. Для неидентифицирующей связи можно указать обязательность (Nulls в закладке General диалога Relationship Editor). В случае обязательной связи (No Nulls) при генерации схемы БД атрибут внешнего ключа получит признак NOT NULL, несмотря на то, что внешний ключ не войдет в состав первичного ключа дочерней сущности. В случае необязательной связи (Nulls Allowed) внешний ключ может принимать значение NULL. Необязательная неидентифицирующая связь помечается прозрачным ромбом со стороны родительской сущности Имя связи (Verb Phrase) - фраза, характеризующая отношение между родительской и дочерней сущностями. Для связи один-ко-многим идентифицирующей или неидентифицирующей достаточно указать имя, характеризующей отношение от родительской к дочерней сущности (Parent-to-Child). (Например, для отношения АВИАКОМПАНИЯ – БОРТ имя, характеризующей отношение от родительской к дочерней сущности будет «Имеет», а для отношения Child-to-Parent (Потомок - Родитель) – «Принадлежит»).    Рисунок 13. Панель задания имени связи Для отображения имени следует в контекстном меню, которое появляется, если щелкнуть правой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Display Options/Relationship и затем включить опцию Verb Phrase. Имя роли или функциональное имя (Rolename) - это синоним атрибута внешнего ключа, который показывает, какую роль играет атрибут в дочерней сущности. Задать имя роли можно в закладке Rolename/RI Actions диалога Relationship Editor.  Рисунок 14 Панель задания имени роли    Рисунок 15 Случай обязательности имен ролей В примере, приведенном на рис.15, в сущности ТАРИФ внешний ключ «Код аэропорта» имеет имя роли «Аэропорт Откуда», которое показывает, какую роль играет этот атрибут в сущности. По умолчанию в списке атрибутов показывается только имя роли. Для отображения полного имени атрибута (как функционального имени, так и имени роли) следует в контекстном меню, которое появляется, если щелкнуть правой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Display Options/Entities и затем включить опцию Rolename/Attribute. Полное имя показывается как функциональное имя и базовое имя, разделенные точкой Обязательным является применение имен ролей в том случае, когда два или более атрибутов одной сущности определены по одной и той же области, т.е. они имеют одну и ту же область значений, но разный смысл. Сущности АЭРОПОРТ и ТАРИФ должны быть связаны дважды, и первичный ключ - «Код аэропорта» должен дважды мигрировать в сущность ТАРИФ в качестве внешнего ключа. Необходимо различать эти атрибуты, которые содержат информацию о аэропорте откуда (и куда) проложен маршрут, т.е. атрибуты имеют разный смысл, но ссылаются на одну и ту же сущность ТАРИФ. В примере на рис.15 атрибуты получили имена ролей «Аэропорт Откуда» и «Аэропорт Куда». Другим примером обязательного применения имен ролей являются рекурсивные связи, когда одна и та же сущность является и родительской и дочерней одновременно. Правила ссылочной целостности (Referential Integrity (RI)) - логические конструкции, которые выражают бизнес-правила использования данных и представляют собой правила вставки, замены и удаления. Задать можно в закладке Rolename/RI Actions диалога Relationship Editor.(Рис..) При генерации схемы БД на основе опций логической модели будут сгенерированы правила декларативной ссылочной целостности, которые должны быть предписаны для каждой связи. Установка ссылочной целостности - это логические конструкции, которые выражают ограничения использования данных. Они определяют, какие действия должна выполнять СУБД при удалении, вставке или изменении с троки таблицы (экземпляра сущности). Заданные таким образом действия могут использоваться впоследствии при автоматической генерации триггеров, поддерживающих целостность данных. Для каждой связи могут быть заданы требования по обработке операций INSERT/UPDATE/DELETE для родительской и дочерней сущности. ERwin предоставляет следующие варианты обработки этих событий: отсутствие проверки (NONE); проверка допустимости (SET NULL); запрет операции (RESTRICT); каскадное выполнение операции DELETE/UPDATE (CASCADE); установка пустого (NULL-значения) или заданного значения по умолчанию (SET DEFAULT)  Рисунок 16 Панель установления правил ссылочной целостности  Рисунок 17 Отношения и правила ссылочной целостности На рис.17. существуют связи между сущностями ЛИЧНОСТЬ и ЧЛЕН ЭКИПАЖА с одной стороны и РЕЙС и ЧЛЕН ЭКИПАЖА с другой (Это демонстрирует ситуацию, когда одна личность может многократно быть членом экипажа на разных рейсах). Что будет, если удалить рейс? Экземпляр сущности ЧЛЕН ЭКИПАЖА не может существовать без рейса, следовательно нужно либо запретить удаление рейса, пока в нем числится хотя бы один член экипажа, либо удалять вместе с рейсом и всех его членов экипажа. Такие правила удаления (Parent Delete) называются Parent Restrict (ограничение) и Parent Cascade (каскад). Сущности ЛИЧНОСТЬ и ЧЛЕН ЭКИПАЖА, в свою очередь, тоже связаны идентифицирующей связью и, если на удаление личности наложено правило каскадного удаления всех записей о его участии в рейсах (Parent Cascade), то при удалении личности будут удалены все записи об его участии в рейсе как члена экипажа. Аналогично можно установить правила целостности для отношения БОРТ-РЕЙС, если наложено правило каскадного удаления то при удалении борта, будут удалены все рейсы выполненные этим бортом, что в свою очередь вызовет удаление всех связанных членов экипажа. Первичный ключ (primary key) - это атрибут или группа атрибутов, однозначно идентифицирующие экземпляр сущности. Атрибуты первичного ключа на диаграмме не требуют специального обозначения - это те атрибуты, которые находятся в списке атрибутов выше горизонтальной линии. При внесении нового атрибута в диалоге Attribute Editor для того, чтобы сделать его атрибутом первичного ключа, нужно включить флажок Primary Key в нижней части закладки General. На диаграмме ключевой атрибут можно внести в состав первичного ключа, воспользовавшись режимом переноса атрибутов (кнопка в палитре инструментов).Ключи могут быть сложными, т.е. содержащими несколько атрибутов. Сложные первичные ключи не требуют специального обозначения - это список атрибутов выше горизонтальной линии. При выборе первичного ключа предпочтение должно отдаваться более простым ключам, т.е. ключам, содержащим меньшее количество атрибутов. Внешние ключи (Foreign Key) создаются автоматически, когда связь соединяет сущности: связи образуют ссылку на атрибуты первичного ключа в дочерней сущности и эти атрибуты образуют внешний ключ в дочерней сущности (миграция ключа). Атрибуты внешнего ключа обозначаются символом (FK) после своего имени. Зависимая сущность может иметь один и тот же ключ из нескольких родительских сущностей. Сущность может также получить один и тот же внешний ключ несколько раз от одного и того же родителя через несколько разных связей. Когда ERwin обнаруживает одно из этих событий, он распознает, что два атрибута одинаковы, и помещает атрибуты внешнего ключа в зависимой сущности только один раз. Это комбинирование или объединение идентичных атрибутов называется унификацией. Есть случаи, когда унификация нежелательна. Например, когда два атрибута имеют одинаковые имена, но на самом деле они отличаются по смыслу, и необходимо, что бы это отличие отражалось в диаграмме. В этом случае необходимо использовать имена ролей внешнего ключа Создание физической модели БДКонечный этап моделирования БД - переход к физическому уровню модели, на котором модель также представлена в виде диаграммы. Переключите диаграмму на физический уровень. Физический уровень представления модели зависит от выбранного сервера. Переименование названий таблицСервер InterBase не позволяет называть таблицы, используя буквы русского алфавита, поэтому необходимо переименовать все называния таблиц используя только латинские буквы, цифры и символ подчеркивания, при этом первый символ в имени может быть только буквой. Необходимо обратить внимание, что в названии таблицы не может быть пробелов – они должны быть заменены на символ подчеркивания. Для того чтобы изменить имя таблицы нужно щелкнуть по выбранному имени и отредактировать его. При переименовании необходимо учитывать, что название таблицы или поля не может совпадать с зарезервированным словом, поэтому вместо зарезервированного слова «ROLE» (роль) будем использовать «RANK» (должность).  Рисунок 18Физический уровень модели. Редактирование свойств полейДля редактирования свойств полей таблиц вызываем редактор колонок (Column Editor) В диалоге появляется новая страница с закладкой InterBase - на этой странице можно задать физические свойства колонки: тип данных, опцию NULL, правило валидации (проверки на допустимость) и значение по умолчанию. Необходимо убедиться, что название поля содержит только латинские буквы, цифры и символ подчеркивания. Особенно нужно следить, чтобы в названии поля отсутствовал символ номера (№), рекомендуется заменять его буквой N. Для переименования колонки (поля таблицы) вызываем диалог при помощи кнопки «Rename». Проконтролируем тип данных колонки. Сервер InterBase поддерживает типы данных, приведенные в табл.
Следует обратить внимание на соответствие типа данных колонки характеру информации, которая должна в них храниться. Проконтролируем допустимость присутствия пустого значения (опцию NULL). Очевидно что «Название Города», «Название аэропорта» и другие подобные поля не должны иметь пустых значений (городов или аэропортов без названий не бывает). Особенно внимательно нужно следить чтобы признак «NOT NULL» стоял у полей входящих в первичный ключ. Приведем соответствие имен таблиц и полей на логическом и физическом уровне.
Генерирование SQL-сценария создания БДОсновной целью процесса проектирования является генерация физической схемы БД. Для генерации схемы БД следует выбрать пункт меню «Tasks/ Forward Engineer/Schema Generation...».  Рисунок 19 Диалоговое окно генератора схем Физическая схема БД генерируется на основе логической схемы и набора установок, задаваемых в диалоговом окне генератора схем (рис. …). Эти установки определяют, какие элементы должны войти в схему БДе диалога содержатся и другие кнопки: Элементы генерируемой схемы организованы по разделам, список которых находится в левом окне страницы. В правом окне находится список элементов отмеченного раздела с флажками. Для выбора элемента, который должен использоваться при генерации схемы БД, следует проставить флажок рядом с этим элементом. А теперь можно сгенерировать схему нашей БД:. В диалоговом окне генератора схем на странице «Options» выделите в левом списке объект «Trigger» и уберите все флажки в правом списке; Выделите объект «Index» и уберите все флажки в правом списке; Нажмите «Preview». В окне просмотра появится SQL-скрипт создания БД: CREATE TABLE AIRCOMPANY ( AC_CODE INTEGER NOT NULL, AC_NAME VARCHAR(20) ); ALTER TABLE AIRCOMPANY ADD PRIMARY KEY (AC_CODE); CREATE TABLE AIRLINE ( AL_NUM VARCHAR(20) NOT NULL, AL_AC_CODE INTEGER NOT NULL, AL_PL_CODE VARCHAR(20) NOT NULL, AL_NAME VARCHAR(20) ); ALTER TABLE AIRLINE ADD PRIMARY KEY (AL_NUM); CREATE TABLE AIRPORT ( AP_CODE INTEGER NOT NULL, AP_NAME VARCHAR(20), AP_CT_CODE INTEGER NOT NULL ); ALTER TABLE AIRPORT ADD PRIMARY KEY (AP_CODE); CREATE TABLE BOARD ( BRD_NUM INTEGER NOT NULL, BRD_PL_CODE VARCHAR(20) NOT NULL, BRG_AC_CODE INTEGER NOT NULL ); ALTER TABLE BOARD ADD PRIMARY KEY (BRD_NUM); CREATE TABLE CITY ( CT_CODE INTEGER NOT NULL, CT_NAME VARCHAR(20) NOT NULL ); ALTER TABLE CITY ADD PRIMARY KEY (CT_CODE); CREATE TABLE EQUIPAGE ( EQ_CODE INTEGER NOT NULL, EQ_FL_DATE DATE NOT NULL, EQ_RNK_CODE INTEGER NOT NULL, EQ_PR_CODE INTEGER NOT NULL, EQ_FL_NUM VARCHAR(20) NOT NULL ); ALTER TABLE EQUIPAGE ADD PRIMARY KEY (EQ_CODE); CREATE TABLE FLIGHT ( FL_DATE DATE NOT NULL, FL_NUM VARCHAR(20) NOT NULL, FL_BRD_NUM INTEGER NOT NULL ); ALTER TABLE FLIGHT ADD PRIMARY KEY (FL_DATE, FL_NUM); CREATE TABLE PERSON ( PR_CODE INTEGER NOT NULL, PR_NAME VARCHAR(20) ); ALTER TABLE PERSON ADD PRIMARY KEY (PR_CODE); CREATE TABLE PLANE ( PL_CODE VARCHAR(20) NOT NULL ); ALTER TABLE PLANE ADD PRIMARY KEY (PL_CODE); CREATE TABLE RANK ( RNK_CODE INTEGER NOT NULL, RNK_NAME VARCHAR(20) ); ALTER TABLE RANK ADD PRIMARY KEY (RNK_CODE); CREATE TABLE SALON ( SL_TYPE INTEGER NOT NULL, SL_NAME VARCHAR(20) ); ALTER TABLE SALON ADD PRIMARY KEY (SL_TYPE); CREATE TABLE SALON_IN_PLANE ( SP_SL_TYPE INTEGER NOT NULL, SP_PL_CODE VARCHAR(20) NOT NULL, SP_COUNT INTEGER ); ALTER TABLE SALON_IN_PLANE ADD PRIMARY KEY (SP_SL_TYPE, SP_PL_CODE); CREATE TABLE TIMETABLE ( TBL_AP_CODE INTEGER NOT NULL, TBL_AL_NUM VARCHAR(20) NOT NULL, TBL_DOWN_TIME VARCHAR(20), TBL_START_TIME DATE, TBL_NUMBER INTEGER ); ALTER TABLE TIMETABLE ADD PRIMARY KEY (TBL_AP_CODE, TBL_AL_NUM); CREATE TABLE TARIFF ( TR_CODE INTEGER NOT NULL, TR_SL_TYPE INTEGER, TR_AL_NUM VARCHAR(20) NOT NULL, TR_COST INTEGER, TR_AP_FROM INTEGER NOT NULL, TR_AP_TO INTEGER NOT NULL ); ALTER TABLE TARIFF ADD PRIMARY KEY (TR_CODE); CREATE TABLE TICKET ( TC_NUM INTEGER NOT NULL, TC_PR_CODE INTEGER NOT NULL, TC_TR_CODE INTEGER NOT NULL, TC_FL_DATE DATE NOT NULL, TC_FL_NUM VARCHAR(20) NOT NULL ); ALTER TABLE TICKET ADD PRIMARY KEY (TC_NUM); ALTER TABLE AIRLINE ADD FOREIGN KEY (AL_AC_CODE) REFERENCES AIRCOMPANY; ALTER TABLE AIRLINE ADD FOREIGN KEY (AL_PL_CODE) REFERENCES PLANE; ALTER TABLE AIRPORT ADD FOREIGN KEY (AP_CT_CODE) REFERENCES CITY; ALTER TABLE BOARD ADD FOREIGN KEY (BRG_AC_CODE) REFERENCES AIRCOMPANY; ALTER TABLE BOARD ADD FOREIGN KEY (BRD_PL_CODE) REFERENCES PLANE; ALTER TABLE EQUIPAGE ADD FOREIGN KEY (EQ_RNK_CODE) REFERENCES RANK; ALTER TABLE EQUIPAGE ADD FOREIGN KEY (EQ_PR_CODE) REFERENCES PERSON; ALTER TABLE EQUIPAGE ADD FOREIGN KEY (EQ_FL_DATE, EQ_FL_NUM) REFERENCES FLIGHT; ALTER TABLE FLIGHT ADD FOREIGN KEY (FL_BRD_NUM) REFERENCES BOARD; ALTER TABLE FLIGHT ADD FOREIGN KEY (FL_NUM) REFERENCES AIRLINE; ALTER TABLE SALON_IN_PLANE ADD FOREIGN KEY (SP_PL_CODE) REFERENCES PLANE; ALTER TABLE SALON_IN_PLANE ADD FOREIGN KEY (SP_SL_TYPE) REFERENCES SALON; ALTER TABLE TIMETABLE ADD FOREIGN KEY (TBL_AL_NUM) REFERENCES AIRLINE; ALTER TABLE TIMETABLE ADD FOREIGN KEY (TBL_AP_CODE) REFERENCES AIRPORT; ALTER TABLE TARIFF ADD FOREIGN KEY (TR_AP_TO, TR_AL_NUM) REFERENCES TIMETABLE; ALTER TABLE TARIFF ADD FOREIGN KEY (TR_AP_FROM, TR_AL_NUM) REFERENCES TIMETABLE; ALTER TABLE TARIFF ADD FOREIGN KEY (TR_AL_NUM) REFERENCES AIRLINE; ALTER TABLE TARIFF ADD FOREIGN KEY (TR_SL_TYPE) REFERENCES SALON; ALTER TABLE TICKET ADD FOREIGN KEY (TC_FL_DATE, TC_FL_NUM) REFERENCES FLIGHT; ALTER TABLE TICKET ADD FOREIGN KEY (TC_TR_CODE) REFERENCES TARIFF; ALTER TABLE TICKET ADD FOREIGN KEY (TC_PR_CODE) REFERENCES PERSON; Для каждой таблицы, входящей в модель, генерируются запросы, заданные в опциях объекта Table. В данном случае это: CREATE TABLE - создание таблицы; ALTER TABLE... ADD PRIMARY KEY - добавление первичного ключа; ALTER TABLE... ADD FOREIGN KEY - добавление внешнего ключа. |