Добавлен: 22.11.2023
Просмотров: 46
Скачиваний: 3
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Существует тернарная связь между сущностями Товары, Склад и Секция торгового зала. Много товаров поставляется из нескольких складов в единственную секцию торгового зала (так как каждый товар продается только в одной секции торгового зала).
2.3. Преобразование ER- модели в реляционную модель
Концептуальные модели позволяют более точно представить предметную область, чем, например, реляционные, но в настоящее время существует немного СУБД, поддерживающих эти модели. На практике наиболее распространены системы, реализующие реляционную модель, поэтому необходим метод перевода концептуальной модели в реляционную.
Такой метод основывается на формировании набора предварительных таблиц из ER-диаграмм. Для каждой сущности создается таблица, причем каждому атрибуту сущности соответствует столбец таблицы[5].
Для преобразования связей используют правила.
В соответствии с типами отношений, представленных на ER диаграмме, будут использованы:
ПРАВИЛО 5. Если степень связи 1:n и класс принадлежности n-связной сущности необязательный, то необходимы три отношения: по одному для каждой сущности и одно для связи. В отношении для связи среди атрибутов должны быть ключи каждой сущности. Ключами первых двух отношений будут ключи сущностей, а ключом третьего – ключ n-связной сущности.
ПРАВИЛО 6. Если степень связи m:n, то необходимы три отношения: по одному для каждой сущности и одно для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей.
ПРАВИЛО 7. Для n-арной связи (n>2) требуется n+1 отношение: по одному для каждой сущности и одно для связи. Ключи каждой сущности превращаются в ключи соответствующих отношений. Кроме того, все ключи входят как атрибуты в отношение для связи.
Перечислим отношения и укажем их первичные ключи:
Продавцы (ФИО продавца, Должность);
Склад (Наименование склада, Адрес, Профиль);
Секция торгового зала (Название секции, ФИО заведующего);
Товары (Наименование товара, Тип, Процент наценки);
Товары на складе (Наименование склада, Наименование товара, Цена, Количество) (отношение добавлено по правилу 6);
Поставки (Наименование склада, Название секции, Наименование товара, Количество, Дата поставки) (отношение добавлено по правилу 7);
Товары в зале (Наименование товара, Название секции, Количество) (отношение добавлено по правилу 5);
Продажи (Номер чека, Наименование товара, Дата продажи, Количество, ФИО продавца) (отношение добавлено по правилу 6).
На следующем шаге необходимо проверить полученные отношения на соответствие правилам нормализации.
2.4. Нормализация отношений предметной области
Нормализация — это процесс организации данных в базе данных, включающий создание таблиц и установление отношений между ними в соответствии с правилами, которые обеспечивают защиту данных и делают базу данных более гибкой, устраняя избыточность и несогласованные зависимости.
Понятие нормальной формы было введено Эдгаром Коддом при создании реляционной модели базы данных[6]. Основное назначение нормальных форм – приведение структуры базы данных к виду, обеспечивающему минимальную избыточность. Устранение избыточности производится за счёт декомпозиции отношений таким образом, чтобы в каждом отношении хранились только первичные факты (факты, не выводимые из других хранимых фактов). Нормализация не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение объёма базы данных. Конечной целью нормализации является уменьшение противоречивости хранимой в базе информации[7].
Существует несколько правил нормализации баз данных. Каждое правило называется нормальной формой.
Существует пять нормальных форм[8], однако для большинства баз данных достаточно нормализовать базы данных до третьей нормальной формы.
Таблица находится в первой нормальной форме (1NF), если каждый её атрибут атомарен. Под выражением «атрибут атомарен» понимается, что атрибут может содержать только одно значение.
Вторая нормальная форма (2NF) требует, чтобы все поля таблицы зависели от первичного ключа, то есть, чтобы первичный ключ однозначно определял запись и не был избыточен. Если же в какой-либо таблице имеется зависимость каких-либо не ключевых полей от части первичного ключа, следует выделить их в отдельную таблицу, сделав первичным ключом новой таблицы ту часть первичного ключа, от которой зависят данные поля, и установить связь «один ко многим» от новой таблицы к старой.
Третья нормальная форма (3NF) требует, чтобы в таблицах не имелось транзитивных зависимостей между не ключевыми полями, то есть чтобы значение любого поля, не входящего в первичный ключ, не зависело от значения другого поля, также не входящего в первичный ключ.
Результатом нормализации является модель данных, которую легко поддерживать, не содержащая неопределенностей в данных и повторений данных.
Все исходные таблицы находятся в 1NF и 2 NF, так же все таблицы, кроме таблицы Товары, находятся так же в 3 NF.
Таблица Товары не находится в 3 NF, так как размер наценки на товар зависит от Типа товара. Таким образом, таблица Товары должна быть разделена на две: Товары (Наименование товара, Код типа); Типы товаров (Наименование типа товара, Процент наценки).
Поля длинными текстовыми значениями использовать в качестве первичных ключей нецелесообразно. Добавим в каждую из основных таблиц поля целочисленного типа, которые будем использовать в качестве первичных ключей. Связанные отношения так же изменим.
Перечислим итоговые отношения:
Продавцы (Код продавца, ФИО продавца, Должность);
Товары (Код товара, Наименование товара, Тип);
Склад (Код склада, Наименование склада, Адрес, Профиль);
Секция торгового зала (Номер секции, Название секции, ФИО заведующего);
Типы товаров (Код типа, Наименование типа, Процент наценки);
Товары на складе (Код склада, Код товара, Цена, Количество);
Поставки (Номер поставки, Код склада, Код секции, Код товара, Количество, Дата поставки);
Товары в зале (Код товара, Номер секции, Количество);
Продажи (Номер чека, Код товара, Дата продажи, Количество, Код продавца).
2.5. Физическая модель предметной области
Физическая модель, то есть таблицы, которые необходимо реализовывать в базе данных Товары торгового зала, представлены в таблицах 1-9.
Таблица 1
Структура таблицы Продавцы
| № | Обозначение | Название | Тип | Длина | Примечание |
| 1 | КодПр | Код продавца | Длинное целое | 4 | Ключ |
| 2 | ФИОпр | Фамилия имя отчество продавца | Текстовый | 25 | |
| 3 | Должность | Должность | Текстовый | 25 | |
Таблица 2
Структура таблицы Типы товаров
| № | Обозначение | Название | Тип | Длина | Примечание |
| 1 | КодТ | Код типа | Длинное целое | 4 | Ключ |
| 2 | НаименТ | Наименование типа | Текстовый | 50 | |
| 3 | ПроцНац | Процент наценки | Одинарное с плавающей точкой | 4 | |
Таблица 3
Структура таблицы Товары
| № | Обозначение | Название | Тип | Длина | Примечание |
| 1 | КодТв | Код товара | Длинное целое  | 4 | Ключ |
| 2 | НаимТв | Наименование товара | Текстовый | 100 | |
| 3 | КодТ | Код типа товара | Длинное целое | 4 | |
Таблица 4
Структура таблицы Секции торгового зала
| № | Обозначение | Название | Тип | Длина | Примечание |
| 1 | НомС | Номер секции | Длинное целое | 4 | Ключ |
| 2 | НазванС | Название секции | Текстовый | 25 | |
| 3 | ФИОЗав | ФИО заведующего | Текстовый | 25 | |
Таблица 5
Структура таблицы Продажи
| № | Обозначение | Название | Тип | Длина | Примечание |
| 1 | НомЧ | Номер чека | Длинное целое | 4 | Ключ |
| 2 | КодТв | Код товара | Длинное целое | 4 | |
| 3 | Дата | Дата продажи | Дата/время | 8 | |
| 4 | Кол | Количество | Целое | 2 | |
| 5 | КодПр | Код продавца | Длинное целое | 4 | |
Таблица 6
Структура таблицы Склад
| № | Обозначение | Название | Тип | Длина | Примечание |
| 1 | КодС | Код склада | Длинное целое | 4 | Ключ |
| 2 | НазвС | Название склада | Текстовый | 50 | |
| 3 | Адрес | Адрес | Текстовый | 100 | |
| 4 | Профиль | Профиль | Текстовый | 20 | |