- •Лабораторная работа. Практикум по субд MicrosoftAccess
- •Нормализация реляционной модели данных
- •1.2.2. Пример построения концептуальной модели для базы данных «Магазины»
- •Разработка таблиц
- •1.2.3. Построение базы данных в access Создание таблиц
- •Создание первичного ключа
- •Сохранение таблицы
- •Заполнение таблиц
- •1.2.4. Экспорт данных в отчет Конструктор таблиц
- •Описание таблицы
- •Экспорт таблиц
- •Задание 2. Создание запросов
- •2.1. Выполнение задания
- •2.2. Методические указания по выполнению работы
- •2.2.1. Простой запрос Выбор полей одной таблицы
- •Выбор полей из нескольких таблиц
- •2.2.2. Запрос с итогами
- •2.2.3. Конструктор запросов
- •2.2.4. Запрос на выборку
- •Параметр – текстовое поле
- •3.2.1. Автоотчеты
- •Отчет с группировкой и итогами
- •3.2.3. Конструктор отчетов
- •Отчет с вычисляемыми полями
- •Отчет с группировкой и итогами
- •Приложение 2 Неоформленный макет отчета
Нормализация реляционной модели данных
Рассмотрим способы построения модели данных реляционного типа. Реляционная модель данных – это множество взаимосвязанных отношений. Простейший вариант реляционной модели – одно отношение. В базе данных – одна таблица.
Построим модель данных для инфологической модели школы:
На первом этапе построим базу данных, содержащую сведения об успеваемости учеников в некотором классе. Нас будут интересовать четвертные и годовые оценки по всем учебным дисциплинам. Иначе говоря, в базу данных необходимо занести табели успеваемости всех учеников класса за весь учебный год. Кроме того, в базе данных необходимо хранить домашние адреса учеников. Для того, чтобы отличать мальчиков от девочек, требуется указывать пол ученика.
Отношение, включающее в себя все перечисленные данные будет следующим:
В этом отношении первичный ключ состоит из трех полей: ФАМИЛИЯ, ИМЯ, ПРЕДМЕТ. Такой ключ называется составным.
Очевидным недостатком хранения данных в таком виде является их избыточность. Под избыточностью понимается многократное повторение одних и тех же данных.
Значение полей ФАМИЛИЯ, ИМЯ, ПОЛ, АДРЕС каждого ученика будут повторяться в записях, относящихся к разным предметам. Это ведет к лишнему расходу памяти компьютера (избыточности данных). Кроме того, существует вероятность того, что при вводе значений повторяющихся полей в каких-то строках могут быть допущены ошибки. Например, по-разному записан один и тот же адрес. Такая ситуация называется противоречивостью данных.
Решением этих проблем является разбиение данного отношения на два, т.е. переход от однотабличной модели к двухтабличной. Первую таблицу назовем УЧЕНИКИ. В ней будут храниться фамилия, имя, пол и адрес ученика. Каждому ученику в этом списке ставится в соответствие свой номер (номер в классном журнале). Он и будет выполнять функцию ключа.
Вторую таблицу назовем УСПЕВАЕМОСТЬ. В ней учеников можно будет идентифицировать по номерам, определенным в первой таблице. Замена имени и фамилии ученика на номер существенно сократит расход памяти. В таблицу УСПЕВАЕМОСТЬ включается поле ПРЕДМЕТ и сведения о полученных оценках. Поля НОМЕР УЧЕНИКА и ПРЕДМЕТ образуют составной ключ. В итоге модель данных представляется двумя следующими отношениями:
Связь между этими отношениями имеет тип «один – ко - многим». Она осуществляется через общее поле НОМЕР_УЧЕНИКА. В таблице УЧЕНИКИ это поле является первичным ключом. В таблице УСПЕВАЕМОСТЬ оно входит в составной ключ. Следовательно, конкретное значение этого поля в первой таблице может присутствовать только в одной записи, а во второй – во множестве записей.
Выполненная нами работа называется нормализацией данных. Полученная двухтабличная структура данных является нормализованной структурой. Основная цель нормализации – избавление от избыточных данных. В идеале не избыточная база данных должна хранить «каждый факт в одном экземпляре». В нашем случае, для каждого ученика его атрибуты ФАМИЛИ, ИМЯ, ПОЛ, АДРЕС будут заноситься в базу однократно. Если значения каких-то атрибутов изменится, то их легко исправить. Например, если изменится адрес ученика, то в первом варианте структуры данных его придется переписывать многократно. В окончательном же варианте это нужно будет сделать всего один раз.
Сущность нормализации заключается в том, что при построении модели данных, относящейся к определенной предметной области, нужно суметь выделить типы объектов (или сущностей), которые должны быть представлены в этой модели. В нашем примере такими объектами являются УЧЕНИКИ с их анкетными данными и УСПЕВАЕМОСТЬ (итоги обучения) со сведениями о полученных учениками оценках по разным предметам. Информация об учениках собрана в таблице УЧЕНИКИ, информация об итогах обучения – в таблице УСПЕВАЕМОСТЬ.
В теории реляционных баз данных используется понятие «нормальная форма» отношения. Отношение находится в первой нормальной форме, если все его поля являются атомарными. Атомарное поле дальше не делится. Например, объединение в одно поле «ФИО» фамилии, имени и отчества человека нарушает принцип атомарности. Понятие атомарности относительно. Например, если в приложениях не потребуется отдельной обработки названия улицы, номера дома и квартиры, то адрес можно не разбивать на составляющие и считать его атомарным.
Отношение находится во второй нормальной форме, если оно находится в первой нормальной форме, и все его неключевые поля полностью функционально зависят от первичного ключа. Иначе говоря, значение неключевого поля в каждой однозначно связано со значением ключа этой записи. Отношения УЧЕНИКИ и УСПЕВАЕМОСТЬ обладают таким свойством. У данного ученика (ключ НОМЕР_УЧЕНИКА) определенный адрес, фамилия, дата рождения и пр. У данного ученика по данному предмету (ключ НОМЕР_УЧЕНИКА + ПРЕДМЕТ) определенные оценки за четверти и за год.
Пример отсутствия функциональной зависимости: значение поля 1_ЧЕТВ не зависит от поля АДРЕС. У данного ученика может измениться АДРЕС, но это не ведет к изменению оценки за 1 четверть по математике. Именно поэтому мы поместили информацию об адресе и об оценках в разные таблицы.
Требование третьей нормальной формы: удовлетворение второй нормальной форме и отсутствие в отношении полей, транзитивно зависимых от ключа. Транзитивной зависимостью между полями А и В называется зависимость через третье поле С: А->C->B. Например, если бы в отношении УЧЕНИКИ присутствовало поле РАЙОН, обозначающее административный район города, где живет ученик, то имела бы место транзитивная зависимость. Район однозначно связан с адресом, поэтому транзитивность следующая:
В полученных нами отношениях транзитивных зависимостей нет. Таким образом, полученная нами двухтабличная модель данных удовлетворяет требованию третьей нормальной формы.