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

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

Логическое проектирование базы данных дляреляционной модели:

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

Особенности проектирования реляционных баз данных

• · Каждое отношение соответствует одной сущности предметной области и в него вносятся все атрибуты объекта, связанные с ним отношением 1:1.
• · Связь типа 1: n реализуется с помощью внешнего ключа.
• · Для реализации связи типа n: m между сущностями вводится дополнительное отношение, содержащее комбинации первичных ключей связанных отношений и атрибуты (свойства) этой связи.

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

Выбор ключей.

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

Иногда бывает, что предполагаемый первичный ключ таблицы оказывается не достаточно уникальным, когда мы начинаем учитывать реализацию его в реляционной базе данных. Возьмем, к примеру, событие. Дата и время наступления события будут гарантированно уникальными, если определить их с достаточной степенью точности. Однако в базе данных Oracleвремя хранится с точностью до секунды, а наличие двух событий в секунду — явление весьма распространенное.

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

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

Типы данных

Любые данные, используемые в программировании, имеют свои типы данных.

Реляционная модель требует, чтобы типы используемых данных былипростыми.

Простые, или атомарные, типы данныхне обладают внутренней структурой. Данные такого типа называютскалярами. К простым типам данных относятся следующие типы:

Логический.

Строковый.

Численный.

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

Целый.

Вещественный.

Дата.

Время.

Денежный.

Перечислимый.

Интервальный.

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

Нормализация отношений. В рамках реляционной модели данных Э. Ф. Коддом был разработан аппарат нормализации отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей нормальной форме. Нормализация схемы отношения выполняется путём декомпозиции схемы.

Первая нормальная форма (1НФ). Отношение находится в 1НФ, тогда и только тогда, когда не одно из полей не содержит более одного значения.

Вторая нормальная форма (2НФ). Отношение находится во 2НФ, если оно приведено к 1НФ и каждый неключевой атрибут функционально полно зависит от составного ключа.

Для того чтобы привести отношение ко 2НФ, нужно:

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

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

Третья нормальная форма (3НФ). Отношение находится в 3НФ, если она удовлетворяет определению 2-ой НФ и не одно из её неключевых полей не зависит функционально от любого другого неключевого поля.