Переход к физической базе данных

Еще одним этапом трансформации моделей является создание программного кода на языке SQL для использования в СУБД, чтобы спроектировать физическую базу данных. В инструментальных средствах моделирования баз данных имеется два механизма:

- создание программного кода и сохранение его в файл на магнитном носителе;

— выполнение программного кода в физической базе данных.

Если модель базы данных разрабатывается на компьютере, где не установлена нужная СУБД, или требуется выполнить программный код на разных компьютерах, то выбирают первый вариант, который в данном разделе и будет рассмотрен.

Для создания программного кода (скрипта) объектов базы данных разработчику необходимо вызвать контекстное меню отдельно объекта в физической модели (таблица, индекс, ограничение и т.д.) или схемы (роли) базы данных, где размещены все объекты будущей базы данных, и указать пункт меню "Generate DDL..." (Создать DDL^[1]), вызывающий окно настроек по формированию SQL-программы.

В первой части настроек разработчику предстоит определить общие характеристики будущего программного кода, которые, в частности, включают (рис. 4.91):

• Check model (проверить модель) — свойство, обозначающее необходимость проверки корректности составленной модели базы данных, для возможности ее представления в физической базе данных;

• DROP statement (уничтожать элементы) — свойство обеспечивает создание в программном коде команд, которые до создания нужных объектов сначала их уничтожат, обеспечивая однозначность соответствия модели базы данных и ее физической реализации;

• CREATE statement (Создать элементы) — свойство, требующее создания указанных объектов базы данных.

Рис. 4.91. Базовые настройки программного кода

Указание этих и других свойств программного кода определяет возможный набор операций, команды по которым должны быть представлены в программном коде. Например, если указать свойство "DROP statement" и не указывать другие свойства, то будет создан программный код, реализующий очищение базы данных от объектов, указанных в других частях настроек.

Вторая часть настроек обеспечивает возможность указания конкретных типов объектов, по которым необходимо определить команды программного кода (рис. 4.92). В этой части настроек показаны все возможные, в соответствии с выбранной СУБД, типы объектов, среди которых табличные пространства (Tablespace), таблицы (Tables), проверочные ограничения (Check constraint), индексы (Index), счетчики (Sequence) и пр.

Разработчик, учитывая требуемый набор объектов, может сформировать программный код, который будет наиболее полезным для реализации в базе данных. Таких программных кодов можно сформировать любое количество, учитывая потребности и особенности создания базы данных. Например, когда указывается создание всех объектов, то средство моделирования базы данных самостоятельно определяет последовательность выполняемых команд. Выбор отдельных объектов и генерирование множества программных кодов дадут возможность сначала определить, например, создание таблиц, потом создать ограничения и индексы, далее представления и процедуры и т.д., тем самым структурировав по усмотрению разработчика процесс формирования базы данных.

Puc. 4.92. Выделение объектов для программного кода

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

• Run DDL on server (Выполнить DDL на сервере) — данное указание определяет необходимость не только сохранить па магнитном носителе программный код, но и выполнить его в СУБД, в соответствии с указываемыми свойства подключения к ней;

• Edit and run DDL in the SQL editor (редактировать и выполнить DDL в редакторе SQL) — данное указание предполагает, что разработчик желает провести корректировку программного кода и только после корректировки, используя специальный редактор, выполнить созданный программный код.

Таким образом, будет создай программный код, который можно выполнить на любом рабочем месте или сервере, где установлена необходимая СУБД. При необходимости создать программный код для другой СУБД разработчику нужно сменить СУБД для модели и повторить операции по генерированию DDL. Это позволяет, используя модель базы данных, без существенных затрат формировать физическую базу данных и программный код ее создания для любой СУБД, естественно, учитывая особенности программных элементов той СУБД, для которой этот программный код создастся.

Процедура создания программного кода с использованием СА ERWin Data Modeler немного отличается, давая несколько более развернутые возможности настройки программы и се реализации в СУБД. Если в продукте от 1ВМ большинство настроек заранее определено или создание программного кода ориентировано на настройки для конкретного объекта, то в средстве от С А разработчик сначала определяет все настройки и только в конце определяется с процедурой создания программного кода по отдельным объектам.

Рис. 4.93. Просмотр и определение последующих действий с программным кодом

Вызов мастера настройки синхронизации модели с базой данных и формирования программного кода создания объектов базы данных в инструментальном средстве СА ERWin Data Modeler выполняется через пункт меню "Actions/Complete Compare" (Действия/Полное сравнение), вызывающий диалоговое окно настроек правил сопоставления (синхронизации) моделей. Важно понимать, что процедура синхронизации предполагает указание двух моделей или баз данных, которые нужно сравнить. Поэтому данный инструмент целесообразно применять при необходимости создания базы данных или синхронизации (установление идентичности) двух моделей базы данных, в некоторых случаях разных уровней.

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

Puc. 4.94. Определение первой модели для синхронизации

На втором шаге разработчиком указывается вторая модель или база данных для синхронизации. Если необходимо сгенерировать программный код для выполнения в базе данных, то выбирается вариант "Database/ Script" (База данных/Программный код) и определяются параметры ее использования (рис. 4.95). В случае, когда ставится задачи генерирования программного кода, вторая модель может быть представлена пустой моделью, но важно модель указать, чтобы средство синхронизации понимало необходимость восстановления идентичности моделей.

Puc. 4.95. Выбор модели или базы данных для синхронизации

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

Следующие два шага настроек определяют объекты обеих моделей или баз данных, которые необходимо сравнить и, при указании разработчиком, синхронизировать, создав необходимые объекты в другой модели (рис. 4.97). Результатом указанных выборов является конструктор программного кода, вызываемый с помощью кнопки "Compare" (Сравнить), где указываются конкретные элементы модели базы данных или самой базы данных.

Рис. 4.96. Определение типов объектов, подлежащих синхронизации

Рис. 4.97. Выбор объектов для синхронизации

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

По итогам указания правил синхронизации, используя пиктограмму <®>. можно сохранить программный код в виде набора команд языка 5()Ь, доступный для последующего использования в СУБД, для которой синхронизация моделей и проводилась. Пиктограмм для создания программного кода имеется две, где одна формирует программный код но изменению "левой" модели, а вторая — соответственно для правой модели. При создании полного программного кода, когда вторая модель является пустой, формируется программный код правой модели, поскольку он будет содержать сведения о создании необходимых элементов исходной модели базы данных.

Рис. 4.98. Настройка программного кода или синхронизации