Проектирование баз данных. Нормализация
Первая нормальная форма (1 НФ) Каждое поле таблицы БД должно быть неделимым и не содержать повторяющихся групп.
Приведение таблицы к 1 НФ. Неприведенная Приведенная к 1 НФ
Вторая нормальная форма (2 НФ) Необходимо чтобы все поля таблицы зависели от первичного ключа, то есть чтобы первичный ключ однозначно определял запись и не был избыточен. Те поля, которые зависят только от части первичного ключа должны быть выделены в отдельные таблицы.
Предположим у нас есть таблица для отпуска товара по накладным. Эту таблицу мы должны привести ко второй нормальной форме. Рассмотрим это схематично: Первичным ключом здесь являются поля Дата и Номер. Поля: Счет, Город и Телефон – зависят только от поля Покупатель, но не от первичного ключа, поэтому их можно выделить в отдельную таблицу под названием Клиенты. Таким образом, мы привели БД Накладные ко второй нормальной форме.
Третья нормальная форма (3 НФ) Необходимо, чтобы в таблице не имелось транзитивных зависимостей между не ключевыми полями, т. е. чтобы значение любого поля, не входящего в первичный ключ, не зависело от значения другого поля, также не входящего в первичный ключ Типичным примером может служить связка полей: Цена за единицу, Количество, К оплате. Дело в том, что значение поля К оплате зависит от полей Цена за единицу и Количество. Значение поля К оплате можно вычислять в процессе создания отчета или запроса, но хранить его в Базе данных вовсе не обязательно.
Техническое задание на создание базы данных. Вариант 0 1. База Данных (БД) должна быть приведена к третьей нормальной форме и содержать следующую информацию: Наименование клиента, Адрес клиента, Номер счета Клиента, ФИО обслуживающего агента, Номер офиса обслуживающего агента, Адрес офиса, Телефон офиса, Сумма всех контрактов агента, Номер договора, Дата заключения договора, Сумма по контракту. 2. Создать формы для ввода информации в каждую из созданных таблиц. 3. Создать три запроса: a) Номер контракта, Наименование клиента, ФИО обслуживающего агента, сумма контракта. Сортировка по номеру контракта в порядке возрастания. Вывести информацию для указанного пользователем агента. b) ФИО обслуживающего агента, Количество контрактов, Общая сумма всех контрактов. Вывести информацию только для указанного пользователем офиса. c) Номер офиса, Количество контрактов, Общая сумма всех контрактов, Средняя сумма всех контрактов. Вывести информацию только за прошедший месяц. 4. Создать отчеты на основании имеющихся запросов. 5. Создать основную кнопочную форму.
Приведем базу данных к первой нормальной форме. В базе данных есть несколько полей, которые можно разделить на несколько неделимых : -Адрес (считаем, что все клиенты и офисы находятся в России) Адрес клиента (Город Клиента, Индекс клиента, Улица клиента, Номер дома клиента, Номер комнаты). Адрес Офиса (Город офиса, Индекс офиса, Улица офиса, Номер дома офиса, Номер комнаты). -ФИО обслуживающего агента делим его на три поля: Фамилия агента, Имя агента, Отчество агента
Приведение к первой нормальной форме закончено и мы определились с набором полей нашей базы данных: Наименование клиента; Город Клиента; Индекс клиента; Улица клиента; Номер дома клиента; Номер комнаты клиента; Номер счета Клиента; Фамилия обсл. Агента; Имя обсл. Агента; Отчество обсл. Агента; Номер офиса обсл. Агента; Сумма всех контрактов агента; Город офиса; Индекс офиса; Улица офиса; Номер дома офиса; Номер комнаты офиса; Телефон офиса; Номер договора; Дата заключения договора; Сумма по договору
Приведем базу данных ко второй нормальной форме Для этого необходимо определить первичный ключ. Если внимательно посмотреть на приведенный список полей, то станет ясно, что это база данных, хранящая перечень договоров некой фирмы. Любое из приведенных полей может иметь повторяющиеся значения, поэтому первичный ключ будет состоять как минимум из двух полей. В качестве первичного ключа можно выбрать Дату и номер договора, поскольку в один и тот же день нельзя подписать договор с одинаковым номером. Поле Наименование клиента зависит от первичного ключа, а вся остальная информация о клиенте от первичного ключа не зависит, но зависит от поля Наименование клиента. В связи с этим выделяем эти поля в отдельную таблицу Клиенты. Далее Фамилия обслуживающего агента зависит от первичного ключа, а вся остальная информация об агенте от первичного ключа не зависит, поэтому выделяем эти поля в отдельную таблицу Агенты. В учебных целях можно считать, что в нашей фирме нет однофамильцев, поэтому в новой таблице в качестве первичного ключа выберем фамилию агента. Остальные поля таблицы Договора зависят от первичного ключа. В таблице Агенты от ключа (поля Фамилия) не зависят поля, хранящие адрес офиса и телефон офиса, поэтому выделяем их в отдельную таблицу Офисы.
структура базы данных примет вид: Связи между таблицами: Клиенты (Наименование клиента) – Договор (Наименование клиента); Агенты (Фамилия обсл. Агента) – Договор (Фамилия обсл. Агента); Офисы (Номер офиса) – Агенты (Номер офиса обсл. Агента).
Приведем базу данных к третьей нормальной форме В таблице Агенты есть поле Сумма всех контрактов Агента. Значение этого поля зависит от значений поля Сумма по договору и может быть вычислена на этапе создания отчета или запроса. Таким образом, это поле убираем из базы данных. Других таких полей нет. Окончательный вид структуры базы данных: Связи между таблицами: Клиенты (Наименование клиента) – Договор (Наименование клиента); Агенты (Фамилия обсл. Агента) – Договор (Фамилия обсл. Агента); Офисы (Номер офиса) – Агенты (Номер офиса обсл. Агента).
Скачать презентацию Проектирование баз данных Нормализация Первая нормальная форма
Проектирование баз данных.ppt