Нормализация таблиц в реляционной модели базы данных

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ

Государственное образовательное учреждение

Высшего профессионального образования

РОССИЙСКИЙ ГОСУДАРСТВЕННЫЙ ТОРГОВО-ЭКОНОМИЧЕСКИЙ УНИВЕРСИТЕТ

КЕМЕРОВСКИЙ ИНСТИТУТ (ФИЛИАЛ)

ФАКУЛЬТЕТ ЗАОЧНОГО ОБУЧЕНИЯ

Кафедра вычислительной техники и информационных технологий

Контрольная работа

по дисциплине

“Базы данных”

по теме: “Нормализация таблиц в реляционной модели базы данных”

Выполнил:

студент группы ПИс-061

(сокращенная форма обучения)

Жилкова Ольга Анатольевна

г. Кемерово 2007 г.

Содержание

1 Нормализация таблиц в реляционной модели БД

1.1 Понятие “Нормализация"

1.2 Первая нормальная форма

1.3 Вторая нормальная форма

1.4 Третья нормальная форма

1.5 Четвертая нормальная форма

1.6 Пятая нормальная форма.

2. Реляционная алгебра над учебной базой

3. База данных для предметной области “Учебные пособия"

Литература

1 Нормализация таблиц в реляционной модели БД

1.1 Понятие “Нормализация"

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

Исключить дублирование информации в таблицах.

Обеспечить возможность изменений в структуре таблиц.

Уменьшить влияние структурных изменений базы данных на работу приложений, обеспечивающих пользователям доступ к данным.

Процесс нормализации состоит из нескольких этапов. Первые три из них, выполняемых чаще всего, были описаны в 1972 году доктором Коддом.

1.2 Первая нормальная форма

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

Примером ненормализованных данных могут выступать данные, представленные в таблице 1.1 Таким способом обычно составляется расписание движения транспорта.

Таблица 1.1 - Ненормализованные данные

Поскольку суда останавливаются во многих портах, столбцы Прибытие, Порт и Отправление повторяются для каждой остановки. Такая структура записи данных не подходит для реляционной базы данных. запись приведенной информации не соответствует требованиям первой нормальной формы, поскольку содержит повторяющуюся группу столбцов. Эту таблицу необходимо разделить на две: Порты и рейсы судов, не содержащие повторяющихся групп, как показано в таблицах 1.2 и 1.3

Таблица 1.2 - Таблица “Рейсы судов”

Таблица 1.3 - Таблица “Порты”

Теперь необходимо установить связь между таблицами Порты и Рейсы судов. В столбце рейс указывается текущий год, номер рейса за этот год, а также направление рейса (например, 9204W- это четвертый рейс за 1992 год в западном направлении). Таким образом, для связи между таблицами следует применять поля Судно и Рейс. Использовать какой-либо один из этих способов недостаточно, поскольку одно судно может делать несколько рейсов в течение года, а в одном направлении могут отправляться сразу несколько судов. Поскольку для удовлетворения требований первой нормальной формы придется создать новую таблицу Порты, необходимо отсортировать ее столбцы в порядке значимости. Первыми, как правило, размещаются столбцы, используемые для установки связи. При этом они располагаются в той последовательности, в какой они входят в составной первичный ключ. Данные показаны в таблице 1.4

Таблица 1.4 - Таблица “Порты”

Теперь необходимо определить ключевые поля таблицы Порты, что дает возможность точно идентифицировать ее записи. Обязательно необходимо создать первичный ключ, поскольку от этой таблицы могут зависеть многие другие. Необходимо добавить столбцы Судно и рейс, так как они обеспечивают связь с данными таблицы Рейсы судов, также добавить поле Порт для создания совершенного уникального ключа (столбы Судно и Рейс могут содержать повторяющиеся значения). Комбинации Судно+Рейс+Порт представляет собой составной первичный ключ, значение которого однозначно идентифицирует запись. Значения этого ключа не повторяются, поскольку учтена возможность дважды делать остановку в одном порту (придвижении туда и обратно). Так, если судно возвращается с востока, рейс помечается суффиксом “Е".

1.3 Вторая нормальная форма

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

Для создания в таблице Рейсы судов однозначного ключа придется использовать составной ключ (Судно+Рейс). Поскольку номер и название судна могут повторяться. Поля Судно и Название не зависят от первичного ключа, так как полем Рейс ничего не определяется. Название судна указывается в каждом рейсе. Так, например, название JapanBear появляется дважды. Все эти недостатки нарушают правила второй нормальной формы. Возникает необходимость разбиения таблицы Рейсы судов еще на две: Рейсы и Суда. Каждый корабль описывается одной строкой в таблице суда, а одна строка таблицы Рейсы описывает рейс одного судна (с целью упрощения построения базы данных восточные и западные направления рассматриваются как отдельные рейсы). Как и в таблице Порты, для установления соответствия между рейсами и судами необходимо создать ключ, поэтому необходимо добавить поле номеров судов в таблицу Рейсы. Таблицы Суда и Рейсы показаны в таблицах 1.5 и 1.6

Таблица 1.5 - Таблица “Суда”

Таблица 1.6 - Таблица “Рейсы”

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

1.4 Третья нормальная форма

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

Таблицы суда и Рейсы уже представлены в третьей нормальной форме, поскольку они содержат повторяющихся групп столбцов и существует зависимость неключевых столбцов этих таблиц от ключевых. В таблице Порты нет повторяющихся групп полей, а неключевые поля Прибытие и Отправление зависят от составного ключа (Судно + Рейс + Порт) и не зависят друг от друга. (Дата прибытия никак не влияет на дату отправления, поскольку интервал между ними определяется временем погрузки товаров на судно, доступностью стоянок, погрузочных кранов, а также погодными условиями) Таким образом, таблица Порты удовлетворяет требованиям первой, второй и третьей нормальных форм.

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

Таблица 1.7 - Таблица с транзитивным отношением между судами и служащими команды.

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

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

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

Таблица 1.8 - Таблица “Команды”

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

1.5 Четвертая нормальная форма

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

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

1.6 Пятая нормальная форма

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

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

Таблица 1.9 - Таблица “Порты”

Невозможно восстановить исходную таблицу из объединенных таблиц Рейсы и Порты, поскольку не сможете отличить строку отправления от других строк по значениям ее полей в таблице. Чтобы отличить строки отправлений, можно было бы использовать значения Null в поле Прибытие, однако значение Null должно быть зарезервированным для условия “данные недоступны". Необходимо устранить любые двусмысленности, которые могут привести к появлению значений Null, и преобразовать таблицу в пятую нормальную форму, добавив односимвольное поле Тип, определяющее прибытие или отправление. В показанной таблице 1.10 Порты коды Е и S представляют соответственно погрузку (Embarkation) и ожидаемое прибытие (Scheduled). Могут также использоваться коды M для заправки (Maintenance) и R- для обратного рейса (Returnvoyage).

Таблица 1.10 - Таблица “Порты”

2. Реляционная алгебра над учебной базой

R1 - список абитуриентов, сдававших репетиционные вступительные экзамены;

R2 - список абитуриентов, сдававших вступительные экзамены на общих основаниях;

R3 - список абитуриентов, принятых в институт.

Необходимо написать ответ на запрос в виде формулы реляционной алгебры. Запрос: “Список абитуриентов, которые поступали два раза и поступили в вуз".

Таблица 2.1 - Отношение R1

Таблица 2.2 - Отношение R2

Таблица 2.3 - Отношение R3

Операция реляционной алгебры - “пересечение".

R1 (a,b,c,d,e,f,g,h,l) R2 (a,b,d,h,m,n,o,p) =R3 (a,b,d,h)

3. База данных для предметной области “Учебные пособия"

Приведение к третьей нормальной форме.

первая нормальная форма - каждое поле таблицы представляет уникальный тип информации;

Таблица “Дисциплины" - номер дисциплины, наименование дисциплины, количество часов;

Таблица “Пособия” - номер пособия, ФИО автора, Номер дисциплины;

Таблица “Специальности” - номер специальности, наименование специальности;

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

Таблица “Дисциплины" - номер дисциплины;

Таблица “Пособия” - номер пособия;

Таблица “Специальности” - номер специальности.

третья нормальная форма - столбцы, не являющиеся ключевыми, зависят от первичного ключа таблицы и не зависят от всех остальных столбцов. Для связывания таблиц “Дисциплины" и “Специальности” необходимо создать дополнительную таблицу “Дисциплины-Специальности".

Таблица “Дисциплины-Специальности" - номер дисциплины, номер специальности.

Данные таблиц.

Таблица 3.1 - Таблица “Дисциплины”

Таблица 3.2 - Таблица “Пособия”

Таблица 3.3 - Таблица “Специальности”

Таблица 3.4 - Таблица “Дисциплины - Специальности"

Создание таблиц. Для создания запросов выбрана СУБД ACCESS.

CREATE дисциплины (number integer,

name_disz varchar (100),

hour integer);

CREATE пособия (number integer,

author varchar (100),

diszipl integer);

CREATE специальности (number varchar (10),

name_spez varchar (100));

CREATE дисциплины_специальности (number_spez varchar (100),

number_diszinteger).

Заполнение таблиц данными. Для примера показаны вставки по одной записи.

INSERT INTO дисциплины (number, name_disz, hour) VALUES (1, “Информатика”, 132);

INSERTINTO специальности (number, name_spez) VALUES (“101170", “Прикладная информатика в экономике”);

INSERT INTO пособия (number, autor, diszipl) VALUES (1, “Джон Вейкас”, 3);

INSERT INTO дисциплины_специальности (number_spez, number_disz) VALUES (“101170”, 1)

Запрос1 - Для номера специальности “220135" вывести наименование этой специальности, наименования дисциплин для этой специальности, у которых количество часов больше 90 и меньше 140, а также авторов пособий для этих дисциплин.

SELECT специальности. number AS "Номер специальности",

специальности. name_spezAS "Специальность",

дисциплины. name_diszAS "Дисциплина",

дисциплины. hourAS "Количество часов",

пособия. authorAS "Автор пособия"

FROM специальности, дисциплины, пособия,

дисциплины_специальности

WHERE дисциплины_специальности. number_disz=дисциплины. number And

дисциплины_специальности. number_spez=специальности. number And

пособия. diszipl=дисциплины. number And

специальности. number="220135" And

дисциплины. hour Between 90 And 140

ORDER BY дисциплины. name_disz, пособия. author;

Запрос 2 - Вывести для каждой специальности номер специальности, наименование специальности, количество дисциплин для каждой специальности, у которых количество часов больше 90 и меньше 150.

SELECT специальности. number AS "Номер специальности",

специальности. name_spez AS "Специальность",

COUNT (дисциплины_специальности. number_disz) AS "Количество

дисциплин"

FROM специальности, дисциплины_специальности, дисциплины

WHERE дисциплины_специальности. number_spez=специальности. number

And дисциплины_специальности. number_disz=дисциплины. number

And дисциплины. hour Between 90 And 150

GROUP BY специальности. number, специальности. name_spez

ORDER BY специальности. name_spez;

Литература

1. Базы данных: теория и практика: Учебник для вузов/ Б.Я. Советов., В.В. Цехановский, В.Д. Черотовской. - М.: Высш. шк., 2005. - 463 с. ил.

2. Вейскас Д. эффективная работа с MicrosoftAccess 97 - СПб: ЗАО “Издательство “Питер””, 1999. - 976 с.: ил.

3. В.В. Корнеев, А.Ф. Гареев, С.В. Васютин, В.В. Райх. Базы данных. Интеллектуальная обработка информации. - М.: Издатель Момачева С.В., Издательство Нолидж, 2001. - 496 с., ил.

4. Дженнингс, Роджер. Использование MicrosoftAccess 2000. Специальное издание.: Пер. с англ.: Уч. пос. - М.: Издательский дом “Вильямс", 2000. - 1152 с.: ил. - Парал. тит. англ.