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

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

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

Для реализации процесса трансформации, используя IBM InfoSphere Data Architect, в контекстном меню логической модели базы данных предусмотрен пункт «Transform to Physical Data Model» (Трансформация в физическую модель данных). Аналогичное действие может быть выполнено при выборе пункта меню «Data/Transform/Physical Data Model» (Данные/Трансформация/Физическая модель данных).

Выбор пункта меню трансформации модели па первом шаге диалогового окна определения параметров требует от разработчика указать вариант создания физической модели базы данных (рис. 4.87):

• • Create new model (Создать новую модель) — выбор этого варианта приведет к созданию новой модели базы данных с описанием таблиц, относящихся только к создаваемой модели;
• • Update existing model (Обновление существующей модели) — выбор этого варианта приводит к изменению существующей и указанной в поле «Target model» (Модель назначения) модели базы данных, заменяя существующие в ней сущности, связи, ключи и прочие элементы.

Рис. 4.87. Определение варианта создания физической модели базы данных.

На втором этапе определения параметров трансформации разработчик указывает СУБД (рис. 4.88), правила которой необходимо использовать при описании таблиц и программных модулей. Для этого в поле «Database» (База данных) необходимо выбрать необходимую СУБД из указанного перечня, который от версии к версии инструментального средства регулярно пополняется и содержит достаточно большое количество применяемых на рынке средств управления базами данных. В ноле «Version» (Версия) важно указать, для какой версии СУБД будет проектироваться физическая модель базы данных, поскольку зачастую в разных версиях бывают отличными синтаксис и набор стандартных функциональных программных модулей. В рассматриваемом примере, в целях соблюдения преемственности производителя используемых программных средств, выбираем СУБД «IBM DB2 for Linux, UNIX and Windows» и последнюю имеющуюся в списке версию «V 10.1» .

Puc. 4.88. Указание используемой для модели СУБД Третий шаг определения параметров трансформации указывает на правила именования атрибутов, сущностей и использования типов данных. Здесь стоит сделать некоторое отступление от процесса настройки трансформации (рис. 4.89). Важным является принятие в разработке правил именования элементов базы данных, аналогично тому, как это делается в программировании, где обязательно существует соглашение имен, применяемых в программных кодах. Соглашение имен для базы данных учитывает принципы и правила, применяемые для правильного использования имен таблиц, полей (колонок), процедур, функций, ограничений, умолчаний и т. д. Это соглашение будет применяться не только в рамках трансформации, но и после первичного формирования физической модели данных для приведения к виду, удобному для написания программного кода обработки данных и обращения к объектам базы данных. Чтобы модель была корректно представлена, разработчиком определяются следующие параметры соглашения имен:

правило слияния слов в наименовании таблицы, поскольку, по умолчанию, предполагается, что СУБД не должна обрабатывать любые наименования, содержащие специальные символы и пробелы;

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

На третьем шаге, учитывая соглашении имен, разработчик определяет свойства преобразования названий таблиц, атрибутов и прочих элементов базы данных:

• • Name Case (Представление имен) — свойство дает возможность указать, что все наименования атрибутов и таблиц должны представляться строчными (маленькими), заглавными (большими) символами или в существующем в логической модели базы данных варианте;
• • Data Type Defaults (тип данных no умолчанию) — свойство определяет тип данных с базовыми параметрами размерности, который должен быть установлен для атрибута, если в СУБД не представлен указанный в логической модели базы данных тип;
• • Physical Options/Surrogate key (суррогатный ключ) — свойство определяет правило представления суррогатного ключа в базе данных одним из двух вариантов: идентифицирующая колонка (поле) или счетчик (sequence);
• • Physical Options/Index (индекс) — это свойство определяет необходимость создания описания индексов для первичных ключей и атрибутов с ограничением уникальности значения;
• • Join table separator (разделитель слов имени таблицы) — это свойство определяет комбинацию символов, которая должна применяться для пробелов и специальных символов при трансформации имен сущностей в имена таблиц.

Рис. 4.89. Настройки преобразования объектов модели.

В итоге выполнения операции получается модель базы данных (рис. 4.90), где, в соответствии с требованиями СУБД, описаны объекты базы данных: таблицы, ноля (колонки), индексы, ограничения, умолчания и т. д.

Рис. 4.90. Результат трансформации модели.

При использовании СЛ ERWin Data Modeler, чтобы создать физическую модель из логической, достаточно выполнить экспорт созданной физической модели, указав в качестве модели назначения физическую модель. В результате будет создан файл с физической моделью или, если выбрана комбинированная модель, логико-физическая модель с преобразованием имен объектов модели в соответствующие элементы физической модели.