3. Даталогическое проектирование базы данных

   1. Создание даталогической модели Общие сведения

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

Таким образом, исходными данными для разработки даталогической модели являются:

• инфологическая модель, представляющая собой отображение предметной области;

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

Даталогическая модель включает в себя следующие основные компоненты:

• набор базовых структурных элементов для представления данных и схем данных (атрибуты, домены, схемы отношений);

• правила порождения ограничений на допустимые состояния данных (ограничения целостности);

• описание правил манипулирования данными.

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

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

В результате даталогического моделирования в соответствии с реляционной моделью данных создается внутренняя схема. Для описания внутренней схемы базы данных используются операторы языка описания данных соответствующей СУБД. В современных реляционных СУБД наиболее распространенным ЯОД являются подмножества языка SQL (Structured Query Language). Для описания ограничений целостности используются соответствующие средства ЯОД и языка разработки приложений (SAL – SQL Application Language), поддерживаемые конкретной СУБД.

Этап создания внутренней схемы сводится к следующим преобразованиям:

• Получение спецификаций внутренней схемы: перевод структурных спецификаций схемы базы данных с полноатрибутного IDEF1X-представления в описание на языке конкретной СУБД.

• Получение спецификаций ограничений целостности: перевод спецификаций ограничений целостности данных с языков IDEF1X, предикатов и естественного в описание на языке описания данных и программы на языке разработки приложений.

Получение спецификаций внутренней схемы базы данных

Реляционная база данных состоит из множества именованных отношений (их схем и расширений). Основной структурой данных для представления отношения служит таблица, поэтому в реляционных базах данных отношения представляются таблицами. Каждому отношению соответствует одна таблица. Каждое отношение состоит из одного или нескольких атрибутов. В общем случае процесс перехода от инфологической модели, разработанной в стандарте IDEF1X, к даталогической не представляет затруднений и заключается в следующем. Базовым структурным компонентом представления данных в полноатрибутной схеме базы данных в IDEF1X является сущность. Базовым структурным компонентом представления данных в реляционной модели данных является отношение. Сущность, представленная в полноатрибутной схеме, эквивалентна отношению реляционной модели данных. Каждой сущности ставится в соответствие одно отношение. Этому отношению присваивается имя соответствующей сущности. Каждое отношения наследует от сущности все ее атрибуты с их именами и типами данных. В связи с тем, что в инфологической модели все связи между сущностями, допустимые в моделях реляционного типа, уже реализованы посредством внешних ключей, в общем случае в результате этого преобразования получается система связанных отношений, соответствующая предметной области.

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

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

• правила построения имен отношений в используемой СУБД;

• правила построения имен атрибутов в используемой СУБД;

• типы данных, поддерживаемые используемой СУБД.

В связи с этим, если описание атрибутов, составленное на этапе инфологического проектирования, в каком-либо из этих аспектов не удовлетворяет требованиям используемой СУБД, необходимо скорректировать имена отношений и (или) описание атрибутов, и (или) имена доменов.