Дисциплина: Базы данных (продвинутый уровень).

Лабораторные работы.
Гр. ЭУ-373604, ЭУ-373605, ЭУ-373631.
Преподаватель – Шаманов А.П.
Занятие 5. 06.05.2020

Лабораторная работа №4. Анализ логической схемы.

Задание.
1.Анализ целостности и устранение выявленных нарушений.
2. Нормализация данных.
3. Пробное заполнение таблиц (3-4 строки в каждую таблицу.
3.В качестве отчета выслать файл family.accdb (файл с той базой, в
которой были устранены нарушения целостности и выполнена нормализация).

Указания к выполнению лабораторной работы.

1.Анализ целостности и устранение выявленных нарушений.
1.1. Целостность реляционных данных.
В любой реляционной базе данных должны выполняться два ограничения,
обеспечивающих ее целостность. Это:
 Целостность сущностей.
 Целостность внешних ключей.
Целостность сущностей: Атрибуты, входящие в состав некоторого
потенциального ключа не могут принимать null-значений. Это означает, что для
каждого отношения (таблицы), должен быть задан первичный ключ и его
значение должно быть задано для каждого кортежа таблицы.
Целостность внешних ключей. Внешние ключи не должны быть
несогласованными, т.е. для каждого значения внешнего ключа должно
существовать соответствующее значение первичного ключа в родительском
отношении.
 Внешний ключ всегда ссылается на какой-то первичный ключ.
Необходимо, чтобы такой первичный ключ в базе был. Необходимо, чтобы тип
данных внешнего и первичного ключа совпадал. Необходимо также, чтобы
среди имеющихся значений первичного ключа, имелось значение, равное
значению внешнего ключа
В данной работе для решения этой задачи необходимо было для каждого
отношения создать суррогатный первичный ключ.

1.2.Суррогатный первичный ключ.

В том случае, если базовое отношение не имеет атрибута, подходящего

для того, чтобы стать первичным ключом, вводится суррогатный первичный
ключ, который служит только для идентификации кортежей (строк таблицы).
Фактически, в таблице создается дополнительный столбец. В Accessе суррогатный
первичный ключ имеет тип данных «счетчик». Этот тип эквивалентен числовому
типу, с той разницей, что значения полей устанавливаются автоматически в
возрастающем порядке. Суррогатный первичный ключ также может вводиться и в
тех случаях, когда особой необходимости в нем нет. Для простоты.
Пример. В данной работе сущность Товары имеет следующие атрибуты:
 Код –идентификатор группы товаров (например, «чай цейлонский
листовой»), тип данных- строка длиной 30 .
 Наименование - название товара на витрине(например, «чай
цейлонский листовой, сорт высший, вес 100г»), тип данных- строка
длиной 50.
 Единица измерения – единица измерения продукта (пачка, кг и т.п),
тип данных- строка длиной 10 .
 Цена покупки - стоимость единицы товара при поставке, тип
данных - денежный.
 Цена продажи - стоимость единицы товара при продаже, тип
данных - денежный.
Здесь, под кодом я подразумевал то, как этот товар будет обозначаться в
договорах с поставщиком. Там может быть своя классификация товаров,
которой поставщик должен придерживаться. Я не товаровед, не знаю какая там
принята классификация и принял, что это – штрих-код. Отсюда имя атрибута –
код. Под наименованием я подразумевал то название, под которым товар будет
предлагаться покупателю. Суть в том, что поставщик и покупатель один и тот
же товар могут называть по-разному (хотя никто не мешает им называть
одинаково). Это, кстати, иллюстрирует причину того, что в концептуальной
модели сущности и атрибуты следует прописывать обстоятельно.
 В принципе, хоть код хоть наименование могут быть выбраны в качестве
первичного ключа. Но и название, и какой-либо классификатор могут содержать
в себе много символов, что не очень-то удобно для внутреннего устройства
базы, гораздо проще пронумеровать товары по порядку -1,2, и т.д. Другими
словами ввести суррогатный первичный ключ.
Кроме того, со временем цена товара может меняться. Скажем чай
«Серый граф» стоил 100 руб. за пачку, а стал стоить 200. Для базы данных это
уже другой товар, хотя название и код останутся прежними.
Поэтому в задании на эту работу было задано использование суррогатного
первичного ключа для всех таблиц.

1.3.Целостность внешних ключей.

Поясню на примере. В таблице «поставки» есть атрибут «товар». Это, в
данном случае, внешний ключ – ссылка на таблицу «товары». Тип данных этого
атрибута должен быть точно таким, как тип данных первичного ключа таблицы
«товары». У суррогатного первичного ключа тип данных «счетчик». На самом
деле это числовой тип данных, значения которого устанавливаются
автоматически в установленном порядке. Поэтому у внешнего ключа в данном
случае надо задавать числовой тип данных. Что касается имени внешнего
ключа, то его можно заменить, например, на «id_товары», можно выбрать
другое имя, а можно не менять.
Для проверки целостности ссылок в Access предусмотрен следующий
механизм.
Щелкнуть правой кнопкой мыши по интересующей связи. Появится окно,
показанное на рисунке. Нужно выбрать «изменить связь».

Появится окно, в котором нужно отметить квадрат «обеспечение

целостности данных» и нажать «ОК».
 Если что-то не так, появится соответствующее сообщение.

2. Нормализация данных.
Нормализация данных — процесс проверки и реорганизации сущностей и
атрибутов с целью удовлетворения требований к реляционной модели данных.
Нормализация позволяет быть уверенным, что каждый атрибут определен для
своей сущности, а также значительно сократить объем памяти для хранения
информации и устранить аномалии в организации хранения данных. В
результате проведения нормализации должна быть создана структура данных,
при которой информация о каждом факте хранится только в одном месте.
Процесс нормализации сводится к последовательному приведению структуры
данных к нормальным формам — формализованным требованиям к
организации данных. Известны шесть нормальных форм. На практике обычно
ограничиваются приведением данных к третьей нормальной форме.
Здесь в дебри залазить пока не надо. Просто проверьте соответствие
модели «сущность-связь» и схемы базы данных:
- Должно быть совпадение таблиц и сущностей (каждой сущности должна
соответствовать одна таблица). Лишних таблиц быть не должно (это в данной
работе).
- Перечень атрибутов каждой сущности, без учета суррогатных ключей,
должен совпадать с перечнем атрибутов отношений (последние могут иметь
другие названия). При выполнении этой части учесть, что я в ER-диаграмме
допустил две ошибки. Опустил атрибут «сотрудник» в «кассовом чеке» и
вставил ненужный атрибут «код» в «поставках».