Информатика и выч. техника \ Базы данных

Разработка базы данных "Заказы товаров", страница 2

Заказы (Код_заказа, Код_товара, Код_менеджера, Код_поставщика, Дата_заказа, Предп_дата_поставки, Факт_дата_поставки, Заказ_количество, Получ_количество, Тип_доставки).

Шаг 3. «Когда две сущности участвуют в связи один – ко - многим ( 1 : N ), то отношение, представляющее дочернюю сущность с кардинальностью N, должно иметь поле внешнего ключа от родительской сущности, представляющее эту связь». Выполняется.

Шаг 4. «Если две сущности участвуют в связи многие – ко многим (M : N), то необходимо создать отношение из первичных ключей обоих отношений… При необходимости в это отношение можно добавить кроме внешних ключей другие атрибуты». Получаем дополнительное отношение:

Заказано/Поставлено (Код_заказа, Код_товара, Заказ_количество, Получ_количество);

И преобразуется одно из ранее рассмотренных отношений:

Заказы (Код_заказа, Код_менеджера, Код_поставщика, Дата_заказа, Тип_доставки, Предп_дата_поставки, Факт_дата_поставки).

Шаг 5. «Если сущность имеет многозначный атрибут, то на его основе следует создать отдельное отношение. Один столбец такого отношения будет внешним ключом, и будет совпадать с ключом исходного отношения, а второй атрибут будет содержать значения многозначного атрибута. Первичный ключ такого отношения – комбинация этих столбцов». В нашем случае многозначных атрибутов нет, но сущность «Поставщики» имеет составной атрибут «Адрес». Будем считать этот атрибут атомарным, так как не требуется производительных действий с индексом, городом, улицей и домом фирмы – поставщика.

Итоги: В результате преобразование ER – модели в реляционную БД получилось 5 отношений:

Менеджеры (Код_менеджера, Фамилия_И_О, Контакт_тел, Фотография, Доп_сведения);

Поставщики (Код_поставщика, Название_фирмы, Контакт_лицо, Телефон, Факс, Адрес);

Товары (Код_товара, Тип_товара, Название_товара, Описание_товара, Цена);

Заказы (Код_заказа, Код_менеджера, Код_поставщика, Дата_заказа, Тип_доставки, Предп_дата_поставки, Факт_дата_поставки);

Заказано/Поставлено (Код_заказа, Код_товара, Заказ_количество, Получ_количество);

Четыре отношения соответствуют сущностям модели, одно отношение – связи между сущностями вида «многие – ко - многим».

Логическое проектирование. Нормализация отношений.

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

Первая нормальная форма (1НФ)

«Отношение находится в первой нормальной форме (1НФ), если все его атрибуты простые, и оно не имеет повторяющихся записей (строк – дубликатов)».

Повторяющихся записей в наших отношениях нет, атрибут «Адрес» в таблице «Поставщики» будем считать атомарным, следовательно, все таблицы нашей БД находятся в 1НФ.

Вторая нормальная форма (2НФ)

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

Отношения «Менеджеры», «Поставщики», «Товары», «Заказы» Имеют простой ключ, а следовательно автоматически находятся во 2НФ. Отношение «Заказано/Поставлено» имеет составной ключ. Функциональные зависимости:

1) Код_заказа, Код_товара à Заказ_количество, Получ_количество;

Неключевые поля полностью зависят от полного ключа, а не от его частей, следовательно, все таблицы нашей БД находятся во 2НФ.

Третья нормальная форма (3НФ)

«Отношение находится в третьей нормальной форме (3НФ), если оно удовлетворяет требованиям 2НФ, и в нем отсутствуют транзитивные зависимости».

«Определение: если для атрибутов А, В и С некоторого отношения существуют зависимости AàBи BàC, то считается, что атрибут С транзитивно зависит от А через атрибут В».

Необходимо выявить функциональные зависимости всех отношений.

Код_менеджера àФамилия_И_О, Контакт_тел, Фотография, Доп_сведения;

Код_поставщика àНазвание_фирмы, Контакт_лицо, Телефон, Факс, Адрес;

Код_товара àТип_товара, Название_товара, Описание_товара, Цена;

Код_заказа àКод_менеджера, Код_поставщика, Дата_заказа, Тип_доставки, Предп_дата_поставки, Факт_дата_поставки;

Код_заказа, Код_товара à Заказ_количество, Получ_количество;

Все таблицы нашей БД соответствуют 3НФ, так как отношения в таблицах между собой не связаны, транзитивные зависимости отсутствуют.

Усиленная 3НФ - нормальная форма Бойса - Кодда (НФБК)

«Отношение находится в НФБК, если оно не содержит неключевых функциональных зависимостей, т.е. в таком отношении все атрибуты зависят только от ключа и других функциональных зависимостей в отношении нет».

Нарушения НФБК происходят, когда

· в отношении имеется два или больше потенциальных составных ключа,

· эти ключи имеют, по крайней мере, один общий атрибут.

Рассмотрим наши отношения:

Менеджеры (Код_менеджера, Фамилия_И_О, Контакт_тел, Фотография, Доп_сведения);

Поставщики (Код_поставщика, Название_фирмы, Контакт_лицо, Телефон, Факс, Адрес);

Товары (Код_товара, Тип_товара, Название_товара, Описание_товара, Цена);

Заказано/Поставлено (Код_заказа, Код_товара, Заказ_количество, Получ_количество);

Т.к. ключ в каждой таблице вводился нами как атрибут, изначально независимы от других, то все таблицы нашей БД соответствую 3НФБК.

Физическое проектирование.

Для физического проектирования используется реляционная СУБД MS Access.

Основная цель этого этапа – создание таблиц (+ определение типов данных и их размера), индексов, разработка схемы и целостности данных.

1) Таблица «Менеджеры»:

Код_менеджера: счетчик, длинное целое;

Фамилия_И_О: текстовый, 30 символов;

Контакт_телефон: текстовый, 15 символов, маска ввода 0\-000\-000\-00\-00;

Фотография: поле объекта OLE;

Доп_сведения: поле MEMO;

Ключевое поле таблицы – «Код_менеджера». Индексирование по полям «Код_менеджера», «Фамилия_И_О», «Контакт_телефон».

2) Таблица «Поставщики»:

Код_поставщика: счетчик, длинное целое;

Название_фирмы: текстовый, 30 символов;

Контакт_лицо: текстовый, 30 символов;

Телефон: текстовый, 15 символов, маска ввода 0\-000\-000\-00\-00;

Факс: текстовый, 15 символов, маска ввода \(000") "000\-0000;

Адрес: тестовый, 100 символов;

Ключевое поле таблицы – «Код_поставщика». Индексирование по полям «Код_поставщика», «Название».

3) Таблица «Товары»:

Код_товара: счетчик, длинное целое;

Тип_товара: текстовый, 30 символов;

Название_товара: текстовый, 50 символов;

Описание_товара: текстовый, 100 символов;

Цена: денежный;

Ключевое поле таблицы – «Код_товара». Индексирование по полям «Код_товара», «Название_товара», «Тип_товара», «Цена».

4) Таблица «Заказы»:

Код_заказа: счетчик, длинное целое;

Код_менеджера: числовой, длинное целое;

Код_поставщика: числовой, длинное целое;

Дата_заказа: дата/время, краткий формат даты;

Тип_доставки: текстовый, 40 символов;

Предп_дата_поставки: дата/время, краткий формат даты;

Факт_дата_поставки: дата/время, краткий формат даты;

Ключевое поле таблицы – «Код_заказа». Индексирование по полям «Код_заказа», «Код_менеджера», «Код_поставщика», «Дата_заказа», «Предп_дата_поставки», «Факт_дата_поставки».