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

Рассмотрим способы построения модели данных реляционного типа. Реляционная модель данных – это множество взаимосвязанных отношений. Простейший вариант реляционной модели – одно отношение. В базе данных – одна таблица.

Построим модель данных для инфологической модели школы:

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

Отношение, включающее в себя все перечисленные данные будет следующим:

В этом отношении первичный ключ состоит из трех полей: ФАМИЛИЯ, ИМЯ, ПРЕДМЕТ. Такой ключ называется составным.

Очевидным недостатком хранения данных в таком виде является их избыточность. Под избыточностью понимается многократное повторение одних и тех же данных.

Значение полей ФАМИЛИЯ, ИМЯ, ПОЛ, АДРЕС каждого ученика будут повторяться в записях, относящихся к разным предметам. Это ведет к лишнему расходу памяти компьютера (избыточности данных). Кроме того, существует вероятность того, что при вводе значений повторяющихся полей в каких-то строках могут быть допущены ошибки. Например, по-разному записан один и тот же адрес. Такая ситуация называется противоречивостью данных.

Решением этих проблем является разбиение данного отношения на два, т.е. переход от однотабличной модели к двухтабличной. Первую таблицу назовем УЧЕНИКИ. В ней будут храниться фамилия, имя, пол и адрес ученика. Каждому ученику в этом списке ставится в соответствие свой номер (номер в классном журнале). Он и будет выполнять функцию ключа.

Вторую таблицу назовем УСПЕВАЕМОСТЬ. В ней учеников можно будет идентифицировать по номерам, определенным в первой таблице. Замена имени и фамилии ученика на номер существенно сократит расход памяти. В таблицу УСПЕВАЕМОСТЬ включается поле ПРЕДМЕТ и сведения о полученных оценках. Поля НОМЕР УЧЕНИКА и ПРЕДМЕТ образуют составной ключ. В итоге модель данных представляется двумя следующими отношениями:

Связь между этими отношениями имеет тип «один – ко - многим». Она осуществляется через общее поле НОМЕР_УЧЕНИКА. В таблице УЧЕНИКИ это поле является первичным ключом. В таблице УСПЕВАЕМОСТЬ оно входит в составной ключ. Следовательно, конкретное значение этого поля в первой таблице может присутствовать только в одной записи, а во второй – во множестве записей.

Выполненная нами работа называется нормализацией данных. Полученная двухтабличная структура данных является нормализованной структурой. Основная цель нормализации – избавление от избыточных данных. В идеале не избыточная база данных должна хранить «каждый факт в одном экземпляре». В нашем случае, для каждого ученика его атрибуты ФАМИЛИ, ИМЯ, ПОЛ, АДРЕС будут заноситься в базу однократно. Если значения каких-то атрибутов изменится, то их легко исправить. Например, если изменится адрес ученика, то в первом варианте структуры данных его придется переписывать многократно. В окончательном же варианте это нужно будет сделать всего один раз.

Сущность нормализации заключается в том, что при построении модели данных, относящейся к определенной предметной области, нужно суметь выделить типы объектов (или сущностей), которые должны быть представлены в этой модели. В нашем примере такими объектами являются УЧЕНИКИ с их анкетными данными и УСПЕВАЕМОСТЬ (итоги обучения) со сведениями о полученных учениками оценках по разным предметам. Информация об учениках собрана в таблице УЧЕНИКИ, информация об итогах обучения – в таблице УСПЕВАЕМОСТЬ.

В теории реляционных баз данных используется понятие «нормальная форма» отношения. Отношение находится в первой нормальной форме, если все его поля являются атомарными. Атомарное поле дальше не делится. Например, объединение в одно поле «ФИО» фамилии, имени и отчества человека нарушает принцип атомарности. Понятие атомарности относительно. Например, если в приложениях не потребуется отдельной обработки названия улицы, номера дома и квартиры, то адрес можно не разбивать на составляющие и считать его атомарным.

Отношение находится во второй нормальной форме, если оно находится в первой нормальной форме, и все его неключевые поля полностью функционально зависят от первичного ключа. Иначе говоря, значение неключевого поля в каждой однозначно связано со значением ключа этой записи. Отношения УЧЕНИКИ и УСПЕВАЕМОСТЬ обладают таким свойством. У данного ученика (ключ НОМЕР_УЧЕНИКА) определенный адрес, фамилия, дата рождения и пр. У данного ученика по данному предмету (ключ НОМЕР_УЧЕНИКА + ПРЕДМЕТ) определенные оценки за четверти и за год.

Пример отсутствия функциональной зависимости: значение поля 1_ЧЕТВ не зависит от поля АДРЕС. У данного ученика может измениться АДРЕС, но это не ведет к изменению оценки за 1 четверть по математике. Именно поэтому мы поместили информацию об адресе и об оценках в разные таблицы.

Требование третьей нормальной формы: удовлетворение второй нормальной форме и отсутствие в отношении полей, транзитивно зависимых от ключа. Транзитивной зависимостью между полями А и В называется зависимость через третье поле С: А-> C-> B. Например, если бы в отношении УЧЕНИКИ присутствовало поле РАЙОН, обозначающее административный район города, где живет ученик, то имела бы место транзитивная зависимость. Район однозначно связан с адресом, поэтому транзитивность следующая:

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

Пример построения концептуальной модели для базы данных «Магазины»

В базе данных «Магазины города» сущностями будут:

· магазин (номер магазина, название, адрес, время работы, фамилия директора);

· товар (код товара, название товара, единица измерения цена);

· поставщик (код фирмы, название, адрес, телефон).

В скобках указаны атрибуты для каждой сущности.

Первичными ключами соответственно будут номер магазина, код товара, код фирмы, так как именно эти атрибуты однозначно идентифицируют уникальное значение сущности.

Учитывая, что один поставщик может поставлять разные товары и один и тот же товар может поставляться разными поставщиками, а также один товар может быть в разных магазинах и в одном магазине могут быть разные товары, концептуальная модель базы данных будет иметь вид:

 

Рис. 1. Концептуальная модель базы данных

 

Между сущностями существует связь «многое ко многим».

В соответствии с концептуальной моделью база данных должна содержать три таблицы: МАГАЗИН, ТОВАР, ПОСТАВЩИК. Для замены связи «многое ко многим» на две связи «один ко многим» вводится дополнительная таблица (таблица пересечения). В конкретном случае вводятся две таблицы пересечения: ПОСТАВКА (код товара, код фирмы, количество), НАЛИЧИЕ (код товара, номер магазина, количество). Схема базы данных будет иметь вид:

Рис. 2. Концептуальная модель базы данных

Разработка таблиц

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

Выбор размера поля и формат зависит от данных, которые будут внесены в это поле.

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

Связанные поля во всех таблицах должны быть одного типа, размера и формата. Желательно, чтобы связанные поля имели одинаковые наименования. В таблице 1 приведены свойства полей для база данных «Магазины города».

Таблица 1

Таблица	Поле	Тип поля	Размер	Формат
МАГАЗИН	Номер магазина (первичный ключ)	Числовой
Название магазина	Текстовый
Адрес	Текстовый
Начало работы	Дата-время		Краткий формат времени
Окончание работы	Дата-время		Краткий формат времени
ФИО директора	Текстовый
ТОВАР	Код товара (первичный ключ)	Счетчик
Наименование	Текстовый
Единицы измерения	Текстовый
Цена	Денежный
Поставщик	Код фирмы (первичный ключ)	Счетчик
Наименование	Текстовый
Адрес	Текстовый
Телефон	Текстовый
Наличие	Код товара (внешний ключ)	Числовой
Номер магазина (внешний ключ)	Числовой
Наличие в магазине	Числовой		Одинарное с плавающей запятой
Поставка	Код товара (внешний ключ)	Числовой
Код фирмы (внешний ключ)	Числовой
Количество	Числовой		Одинарное с плавающей запятой

 

⇐ Предыдущая12345Следующая ⇒

Поделиться:

Популярное:

1. CASE-средства проектирования баз данных
2. I. Краткое изложение данных истории болезни
3. II. Алгоритм процесса кибернетического моделирования.
4. SWIFT как система передачи данных.
5. Абстрактные модели защиты информации
6. Аддиктивное поведение: концепции и модели
7. Альтернативные модели поведения фирмы
8. АППРОКСИМАЦИЯ ДАННЫХ С ИСПОЛЬЗОВАНИЕМ МЕТОДА НАИМЕНЬШИХ КВАДРАТОВ
9. Архитектура производственной базы данных реального времени
10. Базы данных в Visual Basic и VBA. Самоучитель
11. Билет 27. МОДЕЛИРОВАНИЕ ПРОЦЕССА ПЕРЕВОДА. МОДЕЛИ ПРОЦЕССА ПЕРЕВОДА: ДЕНОТАТИВНО-СИТУАТИВНАЯ, ТРАНСФОРМАЦИОННАЯ МОДЕЛЬ, СЕМАНТИЧЕСКАЯ МОДЕЛЬ, ТРЕХФАЗНАЯ МОДЕЛЬ О.КАДЕ, ИНТЕГРАТИВНАЯ МОДЕЛЬ И ДР.
12. Блоки модуля методологических оснований концептуальной модели педагогической системы вузовского формирования функциональных компетентностей будущих учителей физической культуры