Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Базы данных. Учебное пособие для обучающихся по направлению подготовки 09.03.03 «Прикладная информатика»
.pdf
только тогда, когда в любом допустимом значении этой таблицы каждая ее строка содержит только одно значение для каждого атрибута
(столбца).
Требование первой нормальной формы (1NF) очень простое и оно
заключается в том, чтобы таблицы соответствовали реляционной модели данных и соблюдали определённые реляционные принципы.
Таким образом, чтобы база данных находилась в 1 нормальной
форме, необходимо чтобы ее таблицы соблюдали следующие реляционные принципы:
- в таблице не должно быть дублирующих строк;
- в каждой ячейке таблицы хранится атомарное значение (одно не
составное значение);
- в столбце хранятся данные одного типа
- отсутствуют массивы и списки в любом виде.
Рассмотрим процесс нормализации на примере. Имеется таблица:
ФИО владельца Пациент
Иванов Иван Адреевич Мухтар, Мурка, Пепелла
Петров Петр Петрович Шарик
Андреев Иван Андреевич Дружок
Нарушение нормализации 1НФ происходит в столбце Пациенты, т.к. в одной ячейке содержится список из 3 элементов: Мухтар,
Мурка, Пепелла, т.е. он не является атомарным. Преобразуем таблицу к 1НФ:
ФИО владельца Пациент
Иванов Иван Адреевич Мухтар
Иванов Иван Адреевич Мурка
Иванов Иван Адреевич Пепелла
Петров Петр Петрович Шарик
Андреев Иван Андреевич Дружок
31
Таблица находится во второй нормальной форме (2НФ), если она
удовлетворяет определению 1НФ и все ее атрибуты (столбцы), не
входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом.
Чтобы база данных находилась во второй нормальной форме
(2NF), необходимо чтобы ее таблицы удовлетворяли следующим требованиям:
- таблица должна находиться в первой нормальной форме,
- таблица должна иметь ключ,
- все неключевые столбцы таблицы должны зависеть от полного
ключа (в случае, если он составной).
Рассмотрим на примере. Дана таблица с полями ФИО врача, Но-
мер кабинета, Телефон, Должность, Оклад. Ключом отношения является атрибут ФИО врача. Атрибут Должность находится в функциональной зависимости от атрибута ФИО врача.
ФИО врача Номер Кабинета Телефон Должность Оклад
Алексеев А.А. 20 55-25-25 офтальмолог 30000
Гатаулин В.А. 4 55-13-79 рентгенолог 27000
Дабаев Д.Д. 6 55-46-50 хирург 30000
Если не приводить ко второй нормальной форме таблицу, то могут
появиться такие проблемы, как:
- при изменении должности необходимо выполнить обновление
всех строк, которые содержат оклад. Такая проблема называется аномалией изменения данных.
- возникновение ситуации, когда будет отсутствовать врач по той
или иной должности, не будет строки, в которой хранится должность
и оклад. Такая проблема называется аномалией ввода данных.
- повторение должностей и окладов.
Чтобы привести таблицу ко второй нормальной форме, необходи-
мо:
- создание новой таблицы, которая состоит из атрибутов исходной
таблицы;
- исключение атрибутов, которые входят в новую таблицу;
- определить для новых таблиц ключевые поля.
32
Таким образом, получаем две таблицы: таблица Врачи с ключевым полем КодВрача и таблица Должность с ключевым полем КодДолжности. Все неключевые столбцы зависят от полного ключа.
КодВрача ФИО врача НомерКабинета Телефон
100 Алексеев А.А. 20 55-25-25
101 Гатаулин В.А. 4 55-13-79
107 Дабаев Д.Д. 6 55-46-50
КодДолжности Должность Оклад
3 офтальмолог 30000
4 рентгенолог 27000
6 хирург 30000
Таблица находится в третьей нормальной форме (3НФ), если она
удовлетворяет определению 2НФ и ни один из ее неключевых атрибутов не связан функциональной зависимостью с любым другим
ключевым атрибутом.
Если в первой нормальной форме главным являлось соблюдение
реляционных принципов, во второй нормальной форме ‒ первичный
ключ, то в третьей нормальной форме внимание уделяется столбцам,
которые не являются первичным ключом, т.е. неключевым столбцам.
Чтобы нормализовать базу данных до третьей нормальной формы,
необходимо сделать так, чтобы в таблицах отсутствовали неключевые столбцы, которые зависят от других неключевых столбцов.
Иными словами, неключевые столбцы не должны пытаться играть
роль ключа в таблице, т.е. они действительно должны быть неключевыми столбцами, такие столбцы не дают возможности получить данные из других столбцов, они дают возможность посмотреть на информацию, которая в них содержится, так как в этом их назначение.
Главное правило третьей нормальной формы (3NF) ‒ таблица
должна содержать правильные неключевые столбцы.
Чтобы определить, находится ли эта таблица в третьей нормальной форме, мы должны проверить все неключевые столбцы, каждый
33
из них должен зависеть только от первичного ключа, и никаким образом к другим неключевым столбцам он не должен относиться.
Рассмотрим на примере. Допустим, имеется таблица:
Код
Услу-
ги
1
2
3
Наименова-
ние услуги
Взятие
крови
(на анализ)
Контрастная
рентгеногра-
фия ЖКТ
Ортопе-
дическая
операция
Характе-
ристика
терапев-
тическая
рентген-
снимок
хирурги-
ческая
Стои-
Пациент
мость
154,00 Барсик
1907,00 Хлоя
3500,00 Тайсон
ФИО
владельца
Иванова
А.И.
Федоров
И.Н..
Комаров
А.Б.
Вид
Живот-
Порода
ного
кошка б/п
британ-
кошка
собака
ская
той-
терьер6 лет
Воз
Пол Телефон
раст
3
муж
года
13
жен
лет
муж
+7(914)
8495656
+7(964)
7453135
+7(924)
5137889
Если допустить, что пациент приходит на прием и получает услугу
в клинике, то мы получаем, что данная таблица учтет все необходимые параметры. Но в то же время необходимо понимать, что не все
неключевые столбцы будут зависеть от ключевого поля КодУслуги.
Проведя декомпозицию, получим отдельные таблицы: в одной будут храниться данные о пациентах, в другой – об услугах.
Код
Услуги
1 Взятие крови (на анализ) терапевтическая 154,00
2
Наименование услуги Характеристика Стоимость
Контрастная рентгенография
ЖКТ
рентген-снимок 1 907,00
3 Ортопедическая операция хирургическая 3 500,00
Номер
Карточки
Пациент
ФИО
владельца
Вид
Живот-
ного
Порода Возраст Пол Телефон
1202 Барсик Иванова А.И. кошка б/п 3 года муж +7(914)8495656
1213 Хлоя Федоров И.Н. кошка
британ-
ская
13 лет жен +7(964)7453135
1207 Тайсон Комаров А.Б. собака той-терьер 6 лет муж +7(924)5137889
34
После того как мы привели таблицы базы данных к третьей нормальной форме, можно переходить к приведению таблиц до следующей нормальной формы, в частности до нормальной формы
Бойса-Кодда (BCNF).
Таблица находится в нормальной форме Бойса-Кодда (НФБК),
тогда и только тогда, когда любая функциональная зависимость между ее атрибутами сводится к полной функциональной зависимости от
возможного первичного ключа.
Требования нормальной формы Бойса-Кодда следующие:
- Таблица должна находиться в третьей нормальной форме. Здесь
все как обычно, т.е. как и у всех остальных нормальных форм, первое требование заключается в том, чтобы таблица находилась в предыдущей нормальной форме, в данном случае в третьей нормальной
форме;
- Ключевые атрибуты составного ключа не должны зависеть от
неключевых атрибутов.
Отсюда следует, что требования нормальной формы Бойса-Кодда предъявляются только к таблицам, у которых первичный ключ
составной. Таблицы, у которых первичный ключ простой, и они находятся в третьей нормальной форме, автоматически находятся и в
нормальной форме Бойса-Кодда.
Главное правило нормальной формы Бойса-Кодда (BCNF) звучит
следующим образом: часть составного первичного ключа не должна
зависеть от неключевого столбца.
Для реляционных баз данных необходимо, чтобы все отношения
базы данных обязательно находились в 1НФ. Нормальные формы
более высокого порядка могут использоваться разработчиками по
своему усмотрению. Однако следует стремиться к тому, чтобы довести уровень нормализации базы данных хотя бы до ЗНФ, тем самым,
исключив из базы данных избыточность данных и аномалии обновления.
Важным преимуществом MS Access является анализатор таблиц
(Работа с базами данных – Анализ таблицы). Этот инструмент просматривает текущие записи базы данных и предлагает способы их
оптимизации. После запуска Мастер поможет определить, насколько
правильно построены таблицы.
В нашем случае, мастер «Анализ таблиц» предложил внести из-
35
менения по таблице Пациенты (рис. 8). Из рисунка видно, что мастер
Анализа таблиц предлагает разделить данную таблицу на 4 таблицы.
Но это только предложение, поэтому подумаем, насколько правильно мастер группирует данные. Из предложенных вариантов возможным является введение дополнительной таблицы по полу и породе.
Рис. 8. Мастер «Анализ таблиц»
Создание таблицы Пол является возможным и упростит ввод данных. На практике мы рассмотрим варианты заполнения этого поля в
упрощенном виде.
Таблицу по определению пород животных в рамках пособия рассматривать не будем. Поскольку породы животных зависят от вида
животного, это значит, что необходимо провести классификацию пород животных по их видам. Такой подход дает возможность выводить породы животных в зависимости от их вида.
Таким образом, после нормализации получаются следующие
таблицы:
Пациенты, Услуги, Штатное расписание, Врачи, Журнал, ВрачиУслуги (вспомогательная).
36
Название таблицы Поля таблицы
1. Пациенты НомерКарточки
ФИО владельца
Пациент
ВидЖивотного
Порода
Возраст
Пол
Телефон
Домашний адрес
2. Услуги КодУслуги
Наименование услуги
Характеристика услуги
Стоимость
3. Штатное расписание КодДолжности
Должность
Оклад
Надбавка
4. Врачи КодВрача
ФИО врача
ФотоВрача
НомерКабинета
Телефон
5. Журнал КодПриема
НомерКарточки
КодВрача
ДатаПриема
КодУслуги
37
Подводя итоги, отметим, что процесс нормализации заключается в следующем:
- исключение некоторых типов избыточности;
- устранение некоторых аномалий обновления;
- разработка проекта базы данных, который является достаточно
«качественным» представлением реального мира, интуитивно понятен и может служить хорошей основой для последующего расширения;
- упрощение процедуры применения необходимых ограничений
целостности.
Выполнение нормализации данных позволяет увереннее строить
физическую модель базы данных и работать над ее заполнением.
4. Физическая модель базы данных
Физическое проектирование базы данных подразумевает констру-
ирование таблиц в конкретной СУБД.
В физической модели содержится информация обо всех объектах
БД.
В процессе физического проектирования БД необходимо присвоить имена всем таблицам, а также присвоить имена полям таблиц.
Если в логической модели не имеет значения, какой конкретно тип
данных имеет атрибут, то в физической модели важно описать всю
информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т.д. Описания таблиц физической модели приведены в таблицах 3-7.
Таблица 3 ‒ Описание таблицы «Пациенты»
Имя поля Тип данных
НомерКарточки (FK) Числовой Длинное целое
ФИО владельца Короткий текст 20
Пациент Короткий текст 20
ВидЖивотного Короткий текст 20
Размер поля
(вкладка Общие)
38
Дополнительные
параметры
Индексированное
поле
Порода Короткий текст 20
Возраст Короткий текст 20
Пол Короткий текст 3
Телефон Короткий текст 20 Маска ввода
Домашний адрес Короткий текст 50
Таблица 4 ‒ Описание таблицы «Услуги»
Имя поля Тип данных
КодУслуги (FK) Числовой Длинное целое
Наименование
Услуги
Характеристика
Услуги
Стоимость Денежный Авто
Текстовый 50
Текстовый 20
Размер поля
(вкладка Общие)
Таблица 5 ‒ Описание таблицы «Штатное расписание»
Имя поля Тип данных
КодДолжности
(FK)
Должность Текстовый 20
Оклад Денежный Авто
Числовой Длинное целое
Размер поля
(вкладка Общие)
Дополнительные
параметры
Индексированное
поле
Дополнительные
параметры
Индексированное
поле
Надбавка Денежный Авто
39
Таблица 6 ‒ Описание таблицы «Врачи»
Имя поля Тип данных
КодВрача (FK) Числовой Длинное целое
ФИО врача Короткий текст 20
ФотоВрача
НомерКабинета Числовой Длинное целое
Телефон Короткий текст 255 Маска ввода
Поле объекта
OLE
Размер поля
(вкладка Общие)
Дополнительные
Индексированное
Таблица 7 ‒ Описание свойств полей таблицы «Журнал»
Имя поля Тип данных
КодПриема (FK) Счетчик Длинное целое
НомерКарточки Числовой Длинное целое
Размер поля
(вкладка Общие)
Дополнительные
параметры
поле
параметры
КодВрача Числовой Длинное целое
ДатаПриема Дата/время
КодУслуги Числовой Длинное целое
Краткий формат
даты
СОЗДАНИЕ БАЗЫ ДАННЫХ
Для приобретения умения работать с базами данных рассмотрим
процесс создания ее в среде MS Access.
Microsoft Access – это система управления базами данных, основанная на реляционной модели. Предназначена для хранения, ввода,
40
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]