
- •Т.Е.Ильиных л.И.Шустова проектирование реляционных баз данных в нотациях idef1x
- •Содержание
- •Этапы проектирования базы данных
- •Инфологическое проектирование базы данных
- •Общие сведения
- •Описание бизнес компонентов и бизнес процессов
- •Сущность
- •Атрибут
- •Другие компоненты инфологической модели
- •Уровни представления данных
- •Этапы инфологического проектирования Инициирование проекта (фаза 0)
- •Определение сущностей (фаза 1)
- •Построение модели уровня сущностей (фаза 2)
- •Построение модели уровня ключей (фаза 3)
- •Построение полноатрибутной модели (фаза 4)
- •Нормализация данных
- •Даталогическое проектирование базы данных
- •Создание даталогической модели Общие сведения
- •Получение спецификаций внутренней схемы базы данных
- •Ограничения целостности
- •Результаты этапа даталогического проектирования
- •Имя таблицы
- •Основы нормализации отношений Общие сведения
- •Первая нормальная форма
- •Вторая нормальная форма
- •Третья нормальная форма
- •Нормальная форма Бойса – Кодда
- •Четвертая нормальная форма
- •Пятая нормальная форма
- •Денормализация
- •Примеры проектирования баз данных различных бизнес приложений
- •Общие замечания
- •Проектирование базы данных "Школа" Постановка задачи
- •Инициирование проекта (фаза 0)
- •Определение множеств сущностей (фаза 1) Выделение множеств сущностей
- •Описание множеств сущностей
- •Пул сущностей
- •Построение модели уровня сущностей (фаза 2)
- •Концептуальная схема уровня сущностей
- •Построение модели уровня ключей (фаза 3) Разрешение неопределенных связей
- •Пул сущностей
- •Определение связей
- •Определение ключевых атрибутов и доменов
- •Изучаемый предмет/e5
- •Описание доменов
- •Описание атрибутов
- •Концептуальная схема
- •Построение полноатрибутной модели (фаза 4)
- •Описание доменов
- •Описание атрибутов
- •Явные ограничения целостности
- •Даталогическая модель
- •Проектирование базы данных "Обмен валюты" Постановка задачи
- •Инициирование проекта (фаза 0)
- •Определение множеств сущностей (фаза 1) Выделение множеств сущностей
- •Описание множеств сущностей
- •Пул сущностей
- •Фаза 2. Построение модели уровня сущностей Матрица связей
- •Матрица связей
- •Описание связей
- •Описание связей
- •Концептуальная схема уровня сущностей
- •Построение модели уровня ключей (фаза 3) Разрешение неопределенных связей
- •Пул сущностей
- •Определение связей
- •Определение ключевых атрибутов и доменов
- •Описание доменов
- •Описание атрибутов
- •Концептуальная схема
- •Построение полноатрибутной модели (фаза 4)
- •Описание доменов
- •Описание атрибутов
- •Явные ограничения целостности
- •Даталогическая модель
- •Проектирование базы данных "Торговля" Постановка задачи
- •Инициирование проекта (фаза 0)
- •Определение множеств сущностей (фаза 1) Выделение множеств сущностей
- •Описание множеств сущностей
- •Пул сущностей
- •Построение модели уровня сущностей (фаза 2)
- •Концептуальная схема уровня сущностей
- •Построение модели уровня ключей (фаза 3) Разрешение неопределенных связей
- •Пул сущностей
- •Описание связей
- •Определение ключевых атрибутов и доменов
- •Товар в списке цен/e5
- •Описание доменов
- •Описание атрибутов
- •Концептуальная схема
- •Построение полноатрибутной модели (фаза 4)
- •Описание доменов
- •Описание атрибутов
- •Явные ограничения целостности
- •Даталогическая модель
- •Список литературы
- •115409, Москва, Каширское ш., 31
Нормальная форма Бойса – Кодда
Отношение R находится нормальной форме Бойса – Кодда (НФБК) в том и только в том случае, если каждый его детерминант является возможным ключом.
Проблема нормальной формы Бойса – Кодда может возникнуть только тогда, когда в отношении имеется несколько возможных ключей, эти ключи являются составными и пересекающимися (т.е. имеют общие атрибуты). Если в отношении имеется только один возможный ключ (являющийся первичным ключом), то это определение становится эквивалентным определению третьей нормальной формы. Таким образом, нормальная форма Бойса – Кодда представляет собой усиленную третью нормальную форму.
Пример. Имеем отношение с именем СОТРУДНИК и атрибутами НОМЕР СОТРУДНИКА, ФАМИЛИЯ, НОМЕР ПРОЕКТА, ЗАДАНИЕ НА ПРОЕКТ.
Пусть предметная область такова, что личность сотрудника однозначно определяется и его номером (атрибут НОМЕР СОТРУДНИКА), и его фамилией (атрибут ФАМИЛИЯ). Каждый сотрудник работает только над одним проектом, а каждый проект закреплен только за одним конкретным сотрудником. Для каждого сотрудника для реализации проекта выдается конкретное задание. Исходя из приведенного описания предметной области, данное отношение имеет два возможных составных ключа:
Сотрудник.(Номер сотрудника + Номер проекта)
Сотрудник.(Фамилия + Номер проекта)
т.е. имеются следующие функциональные зависимости:
Сотрудник.Номер сотрудника Сотрудник.Фамилия
Сотрудник.Фамилия Сотрудник.Номер сотрудника
Сотрудник.Номер сотрудника Сотрудник.Номер проекта
Сотрудник.Фамилия Сотрудник.Номер проекта
Сотрудник.(Номер сотрудника + Номер проекта) Сотрудник.Задание на проект
Сотрудник.(Фамилия + Номер проекта) Сотрудник.Задание на проект
Независимо от того, какой из возможных ключей выбран в качестве первичного ключа, это отношение находится в 3НФ. Однако так как имеются функциональные зависимости атрибутов отношения от атрибута, являющегося частью первичного ключа, данное отношение не удовлетворяет условию нормальной формы Бойса – Кодда. Нормализация отношения СОТРУДНИК основывается на теореме Хеза и заключается в его декомпозиции на два отношения:
Сотрудник1 (Номер сотрудника, Фамилия)
Сотрудник2 (Номер сотрудника, Номер проекта, Задание на проект)
Для отношения СОТРУДНИК1 возможными ключами являются следующие атрибуты:
Сотрудник1.Номер сотрудника
Сотрудник1.Фамилия
Для отношения СОТРУДНИК2 возможный ключ один, и он является составным:
Сотрудник2.(Номер сотрудника + Номер проекта)
Для этих отношений имеются следующие функциональные зависимости между информационными единицами:
.Номер сотрудника Сотрудник1.Фамилия
Сотрудник1.Фамилия Сотрудник1.Номер сотрудника
Сотрудник2.(Номер сотрудника + Номер проекта) Сотрудник. Задание на проект
Полученные отношения находятся в НФБК.
Для данного примера возможна следующая альтернативная декомпозиция отношения СОТРУДНИК:
Сотрудник1 (Номер сотрудника, Фамилия)
Сотрудник2 (Фамилия, Номер проекта, Задание на проект)
В этом случае полученные отношения также удовлетворяют условию НФБК.