Даталогическое проектирование

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

Проектирование логической структуры РБД предполагает:

· разбиение всей информации по отношениям (таблицам);

· определение состава полей (атрибутов) каждого отношения;

· определение ключа каждого отношения;

· определение связей и обеспечение целостности по связям.

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

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

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

2) существенное влияние оказывает характер обработки. Частые обращения к совместно обрабатываемым данным предполагают их совместное хранение, а данные, к которым обращаются редко, целесообразно хранить отдельно.

Рассмотрим по шагам общий подход к построению РБД на основе инфологической модели, представленной ER-диаграммой.

1. Каждая простая сущность превращается в таблицу (отношение). Имясущности становится именем таблицы. Каждый простой атрибут становится столбцом таблицы с тем же именем: R1 (И1 , А1 , А2 , А3 ).

2. Компоненты уникального идентификатора сущности превращаются в первичный ключ. Если имеется несколько возможных уникальных идентификаторов, выбирается наиболее используемый. Учитываются также следующие факторы:

· длина ключа – в качестве первичного ключа выбирается, как правило, самый короткий из вероятных ключей;

· стабильность – желательно выбирать в качестве первичного ключа атрибуты, которые не изменяются;

· мнемоничность– при прочих равных условиях следует отдавать предпочтение тем из вероятных ключей, которые легче запомнить.

Некоторые СУБД (Access, Paradox и др.) позволяют автоматически генерировать в качестве ключа таблицы поле типа «счетчик». Этот искусственный код можно использовать для простых объектов, если в предметной области не предполагается применение другой системы кодирования (ОКПО, ОКОНХ, ИНН).

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

3. Каждому из многозначных атрибутов ставится в соответствие отношение, полями которого будут идентификатор, выбранный в качестве первичного ключа, и многозначный атрибут. Ключ этого отношения будет составным, включающим оба эти атрибута. Для многозначных атрибутов МА4 и МА5 будут созданы отношения: R2 (И1 , МА4 ) и R3 (И1 ,МА5 ).

4. Если сущность имеет необязательный атрибут, возможны два варианта:

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

Б) если свойством обладает малое число экземпляров, то можно выделить отношение, включающее идентификатор и соответствующий атрибут: R4 (И1 , НА6 ). Отношение будет содержать столько строк, сколько объектов имеет свойство.

5. Если сущность имеет составной атрибут, то возможны два варианта:

составному свойству ставится в соответствие отдельное поле;

каждому из составляющих элементов составного свойства ставится в соответствие отдельное поле.

Выбор варианта зависит от характера обработки данных. При реализации запросов проще объединить поля, чем выделить часть поля. Если предполагается использование компонентов атрибута, лучше вариант 2, иначе – вариант 1.

6. Бинарные связи один-к-одному и один-ко-многим становятся внешними ключами. Создается копия уникального идентификатора с конца связи «один», и соответствующие столбцы составляют внешний ключ.

Связь один-к-одному между сущностями встречается редко. Если класс принадлежности обеих сущностей является обязательным, то для отображения обеих связанных сущностей можно использовать одну таблицу:

R3 (И1 , И2 , А1 , А2 ).

Однако таким решением злоупотреблять не следует. Если для каждого объекта потребуются свои связи или в запросах потребуется информация по каждой сущности, то выбранное решение усложнит или замедлит работу с БД.

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

R1 (И1 , А1 , И2 )

R2 (И2 , А2 )

или

R1 (И1 , А1 )

R2 (И2 , А2 , И1 ).

Если класс принадлежности одной из сущностей является необязательным, то идентификатор сущности с необязательным классом добавляется в отношение, соответствующее сущности с обязательным классом принадлежности.

Если класс принадлежности обеих сущностей является необязательным, то, чтобы избежать наличия пустых полей, следует использовать три отношения: по одному для каждой сущности и одно – для отображения связи между ними:

R1 (И1 , А1 )

R2 (И2 , А2 )

R3 (И1 , И2 ).

7. Преобразование бинарной связи один-ко-многим (1:N)зависит только от класса принадлежности N-связной сущности. Если он является обязательным, то можно использовать два отношения (по одному для каждой сущности). В отношение для N-связной сущности добавляется идентификатор 1-связной сущности:

R1 (И1 , А1 )

R2 (И2 , А2 , И1 ).

Если класс принадлежности N-связной сущности является необязательным, то для отображения связи создается третье отношение, которое будет содержать ключи каждой из связанных сущностей:

R1 (И1 , А1 )

R2 (И2 , А2 )

R3 (И1 , И2 ).

8. Для бинарной связи многие-ко-многим (М:N) потребуются три отношения:

по одному для каждой сущности и

одно дополнительное – для отображения связи между ними. Последнее отношение будет содержать идентификаторы связанных объектов.

Ключ этого отношения будет составным:

R1 (И1 , А1 )

R2 (И2 , А2 )

R3 (И1 , И2 ).

9. В случае N-арной связи необходимо использовать (n+1) отношение – по одному для каждой сущности, и одно для связи. Идентификатор каждой сущности станет первичным ключом соответствующего отношения. Отношение, порождаемое связью, будет иметь среди своих атрибутов ключи каждой сущности. Если связь имеет атрибуты, то они становятся атрибутами отношения связи. Например:

R1 (И1 , А1 )

R2 (И2 , А2 )

R3 (И3 , А3 )

R4 (И1 , И2 , И3 , АС4 ).

10. Обобщающей сущности соответствует одно отношение, причем ключ сущности становится ключом отношения. Этому отношению приписываются общие для всех ролевых сущностей атрибуты.

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

11. Индексы создаются для первичного ключа (уникальный индекс), а также внешних ключей и тех атрибутов, которые будут часто использоваться в запросах.

Физические модели

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

К вопросам организации данных относятся:

· выбор типа записи – единицы обмена в операциях ввода-вывода;

· выбор способа размещения записей в файле и, возможно, метода оптимизации размещения;

· выбор способа адресации и метода доступа к записям.

Стадия физического проектирования БД в общем случае включает:

· выбор способа организации БД;

· разработку спецификации внутренней схемы;

· описание отображения концептуальной схемы во внутреннюю.

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

Реально к вопросам проектирования физической модели можно отнести:

· выбор схемы размещения данных (разделение по файлам или тип RAID-массива);

· определение числа и типа индексов (например, кластеризованный или некластеризованный в случае MS SQL Server).

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

ER-модели широко используются в практике создания БД. Они применяются при ручном и автоматизированном проектировании с использованием CASE-средств, поддерживающих весь цикл разработки СБД или отдельные его стадии. К таким средствам относятся: ProKit*WORKBENCH, Design / IDEF, CASE Oracle (Designer / 2000), Power Designer (S-Designor), ERWin, SILVERRUN, ERStudio и другие. CASE-средства являются сравнительно новым направлением в информационных технологиях. Первая версия инструментария Oracle появилась в 1989 г.

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

При сравнении CASE-систем кроме используемой методологии ER-моделирования, необходимо учитывать специфические критерии, связанные с реализацией функций автоматизированного проектирования:

· число и перечень поддерживаемых целевых СУБД;

· поддержку распределенных БД;

· поддержку коллективной работы при проектировании (управление правами пользователей, ведение репозитория

(от англ. repository – склад, хранилище; встречается также написание «репозитарий» Репозиторий, хранилище — место, где хранятся и поддерживаются какие-либо данные. Чаще всего данные в репозитории хранятся в виде файлов, доступных для дальнейшего распространения по сети. и т. д.);

· построение концептуальной ER-модели по описанию структуры существующей БД – реверс-инжиниринг

Обра́тная разрабо́тка (обратный инжиниринг, реверс-инжиниринг; англ. reverse engineering) — исследование некоторого готового устройства или программы, а также документации на него с целью понять принцип его работы; например, чтобы обнаружить недокументированные возможности (в том числе программные закладки), сделать изменение или воспроизвести устройство, программу или иной объект с аналогичными функциями, но без прямого копирования.;

· автоматизируемые функции проектирования и степень их автоматизации;

· качество и жесткость проектных решений (возможность выбора из нескольких альтернативных решений, возможность ручного вмешательства в процесс);

· надежность работы;

· документирование проекта;

· открытость системы (возможность стыковки с другими средствами);