Файл: Методичка по БД.docx

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

Отношение ВКЛЮЧАЕТ между объектами ТОВАР и НАКЛАДНАЯ имеет показатель кардинальности много-ко-многим, так как накладная может содержать несколько товаров, а товар может встречаться в нескольких накладных, при этом одной накладной должен соответствовать хотя бы один товар (т.е. со стороны товара класс принадлежности обязательный, со стороны накладной - необязательный). Если необходимо контролировать оплату поставленного по накладным товара, то необходимо добавить сущность ОПЛАТА с атрибутами НОМЕР ДОКУМЕНТА, ВИД ОПЛАТЫ и ДАТА. Показатель кардинальности отношения ОПЛАЧЕНА между объектами НАКЛАДНАЯ и ОПЛАТА равна один-к-одному и класс принадлежности является обязательной (подразумевается, что при выписке накладной должны также оформляться документы об оплате). Модель данных приведена на рис. 4.

Рисунок 4. Модель «сущность – связь» торговой фирмы на основе накладной

1.5 Выбор СУБД и других программных средств

Выбор СУБД осуществляется на основании таких критериев, как тип модели данных и её адекватность потребностям рассматриваемой предметной области; характеристики производительности; набор функциональных возможностей; удобство и надежность СУБД в эксплуатации; стоимость СУБД и дополнительного программного обеспечения [1].

1.6 Логическое проектирование БД

1.6.1 Разработка логической структуры БД

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

Основные 6 правил генерации таблиц:

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

Правило 2. Если показатель кардинальности бинарной связи равен 1 : 1 и класс принадлежности одной сущности является обязательным, а другой ‑ необязательным, то необходимо построение двух таблиц. Под каждую сущность нужно выделить по одной таблице, при этом ключ сущности должен служить первичным ключом для соответствующей таблицы. Кроме того, ключ сущности, для которой класс принадлежности является необязательным, добавляется в качестве атрибута в таблицу, выделенную для сущности с обязательным классом принадлежности.

---

Правило 3.Если показатель кардинальности бинарной связи равен 1 : 1 и класс принадлежности ни одной сущности не является обязательным, то необходимо использовать три таблицы: по одной для каждой сущности, ключи которых служат в качестве первичных в соответствующих таблицах, и одна таблица для связи. Среди своих атрибутов таблица связи будет иметь по одному ключу каждой сущности.

Правило 4. Если показатель кардинальности бинарной связи равен 1 : М и класс принадлежности n-связной сущности является обязательным, то достаточным является использование двух таблиц, по одной на каждую сущность, при условии, что ключ каждой сущности служит в качестве первичного ключа для соответствующей таблицы. Дополнительно ключ 1-связной сущности должен быть добавлен как атрибут в таблицу, отводимую для n-связной сущности.

Правило 5. Если показатель кардинальности бинарной связи равен 1 : М и класс принадлежности n-связной сущности является необязательным, то необходимо формирование трех таблиц: по одной для каждой сущности, причем ключ каждой сущности служит первичным ключом соответствующей таблицы, и одной таблицы для связи. Таблица связи должна иметь среди своих атрибутов ключ каждой сущности.

Правило 6. Если показатель кардинальности бинарной связи равен М : М, то для хранения данных необходимо три таблицы: по одной для каждой сущности, причем ключ каждой сущности используется в качестве первичного ключа соответствующей таблицы, и одной таблицы для связи. Таблица связи должна иметь в числе своих атрибутов ключ каждой сущности.

Рассмотрим преобразование ранее созданной модели «сущность-связь» торговой фирмы (рис. 4).

Связь ОФОРМЛЕНА между сущностями ПОЛУЧАТЕЛЬ и НАКЛАДНАЯ имеет показатель кардинальности один-ко-многим и класс принадлежности обеих сущностей обязательный. Поэтому для преобразования этой связи воспользуемся правилом 4. В соответствии с этим правилом надо построить только две таблицы: по одной на каждую сущность. Причём ключ односвязной сущности добавляется как неключевой атрибут в таблицу, отводимую n-связной сущности (Код). В результате получим следующие таблицы:

ПОЛУЧАТЕЛЬ (Код, Адрес, Название);

НАКЛАДНАЯ (Номер, Налог, Итого, Код).

Сущности ТОВАР и НАКЛАДНАЯ соединены связью типа М:М. Для преобразования модели «сущность-связь» потребуется правило 6, при этом класс принадлежности обеих сущностей не играет никакой роли. В этом случае требуется 3 таблицы: по 1 для каждой сущности и 1 таблица связи, которая будет иметь по одному ключу от каждой сущности, а первичным ключом таблицы связи будет составной ключ:

ТОВАР (Ном.номер, Наименование, Цена, Количество, Сумма);

НАКЛАДНАЯ (Номер, Налог, Итого, Код);

ВКЛЮЧАЕТ (Ном.номер, Номер).

Между сущностями НАКЛАДНАЯ и ОПЛАТА связь типа один-к одному и класс принадлежности обеих сущностей обязательный. Следовательно, для преобразования надо воспользоваться правилом 1, т.е. потребуется только одна таблица

---

НАКЛАДНАЯ (Номер, Налог, Итого, Код, Номер_документа, Дата, Вид).

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

ПОЛУЧАТЕЛЬ (Код, Адрес, Название);

НАКЛАДНАЯ (Номер, Налог, Итого, Код, Номер_документа, Дата, Вид);

ТОВАР (Ном.номер, Наименование, Цена, Количество, Сумма);

ВКЛЮЧАЕТ (Ном.номер, Номер).

1.6.2 Нормализация базы данных

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

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

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

Первая нормальная форма (1НФ)

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

Вторая нормальная форма (2НФ).

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

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

Таблица находится во 2НФ, если она приведена к 1НФ и каждый неключевой атрибут функционально полно зависит от составного первичного ключа.

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

Для того чтобы привести таблицу ко 2НФ, нужно:

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

2. Создать таблицу, атрибутами которой являются части составного ключа и атрибуты, зависящие от этих частей.

Третья нормальная форма (3НФ).

Третья нормальная форма основана на понятии транзитивной зависимости. Пусть X, Y, Z – атрибуты некоторой таблицы. При этом X→Y и Y→Z, но обратное соответствие отсутствует, т.е. Z не зависит от Y или Y не зависит от X. Тогда говорят, что Z транзитивно зависит от X (X→→Z).

---

Таблица находится в 3НФ, если она находится во 2НФ и каждый неключевой атрибут нетранзитивно зависит от первичного ключа.

Для того чтобы привести отношение к 3НФ, нужно:

1. В исходной таблице выявить транзитивно зависящие атрибуты (X→Y и Y→Z), и создать новую таблицу, исключив из исходной таблицы атрибуты, транзитивно зависящие от ключа (атрибут Z).

2. Построить новую таблицу, атрибутами которой являются части транзитивной зависимости (атрибуты Y и Z).

Четвертая нормальная форма (4НФ)

Четвертая нормальная форма основана на понятии многозначной зависимости.

Многозначная зависимость существует, если заданным значениям атрибута X соответствует множество значений атрибута Y (X–»Y).

Таблица находится в 4НФ в том и только в том слу­чае, если она находится в 3НФ и в случае существования многозначной зависимости А -» В все остальные атри­буты таблицы функционально зависят от А.

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

1.7 Программная реализация базы данных

Программная реализация базы данных заключается в описании ее схемы на языке определения данных (DDL, Data Definition Language) выбранной СУБД. Принятые на этом этапе решения оказывают огромное влияние на производительность системы.

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

Не менее важным вопросом разработки базы данных является защита БД от несанкционированного доступа.

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

2. ВЫПОЛНЕНИЕ КУРСОВОЙ РАБОТЫ

2.1. Задачи, решаемые в курсовой работе

Курсовая работа включает в себя решение следующих задач:

1. Разработка модели «сущность – связь» (инфологическое проектирование).

2. Обоснование выбора СУБД и создание БД в выбранной СУБД.

3. Даталогическое проектирование реляционной БД на основе модели «сущность – связь», полученной на предыдущем этапе.

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

5. Определение характеристик атрибутов и правил декларативной поддержки ограничений целостности данных (обязательные данные, целостность сущностей, ссылочная целостность, требования конкретного предприятия (бизнес-правила)).

6. Разработка хранимых процедур и триггеров, обеспечивающих процедурную поддержку целостности данных (курсовая работа должна содержать не менее двух хранимых процедур и двух триггеров).

7. Реализация операций над данными (поиск, вставка, удаление, обновление) в соответствии с вариантом задания с помощью языка SQL.

---

Задание выполняется индивидуально каждым студентом в соответствии с вариантом, утвержденным преподавателем.

2.2. Организация процесса выполнения курсовой работы

Преподавателем индивидуально выдаются задания на курсовую работу. Вариант задания берется из списка вариантов заданий, приведенном в разделе 3. При этом номер варианта соответствует номеру студента в журнале группы. Студент имеет право предложить самостоятельное задание на курсовую работу. В этом случае задание на курсовую работу согласовывается с руководителем курсовой работы.

Задание подписывается студентом, преподавателем и заведующим кафедрой.

Примерный график выполнения курсовой работы:

• 1-я неделя. Получение задания.

• 2-я – 3-я недели. Инфологическое проектирование.

• 4-я неделя. Обоснование выбора СУБД и создание БД в выбранной СУБД.

• 5-я неделя. Описание реляционной модели данных.

• 6-я неделя. Нормализация полученной базы данных.

• 7-я неделя. Определение характеристик атрибутов и правил декларативной поддержки ограничений целостности данных.

• 8-я и 9-я недели. Определение характеристик атрибутов и правил декларативной поддержки ограничений целостности данных.

• 10-я и 11-я недели. Разработка хранимых процедур и триггеров, обеспечивающих процедурную поддержку целостности данных.

• 12-я и 15-я недели. Реализация операций над данными (поиск, вставка, удаление, обновление) в соответствии с вариантом задания с помощью языка SQL.

• 16-я неделя. Оформление пояснительной записки.

• 17-я и 18-я недели. Защита курсовой работы.

После предоставления пояснительной записки преподавателю и ее проверки, при отсутствии существенных замечаний к содержанию, назначается дата защиты. Защита курсовой работы проводится перед комиссией, состав которой утверждается кафедрой, и в присутствии студентов данной учебной группы. При защите курсовой работы студент должен привести сведения о поставленной задаче и ее особенностях, описать предлагаемую структуру данных, обосновать выбор СУБД и провести анализ проделанной работы.

2.3. Оформление пояснительной записки

Пояснительная записка выполняется на писчей бумаге формата А4 (297 210 мм). Отступы от границ листа: левое поле – 25 мм, правое, верхнее, нижнее – 20 мм. Разделы, подразделы, рисунки, таблицы и страницы нумеруются.

Содержание пояснительной записки:

1. Титульный лист (приложение 1).

2. Лист задания (приложение 2).

3. Аннотация, включающая в себя сведения об объеме курсовой работы, количестве рисунков, таблиц, краткое описание задачи, оценку результатов и т.д.

4. Содержание.

5. Основная часть.

   1. Концептуальное проектирование.

   2. Обоснование выбора СУБД

   3. Даталогическое проектирование.

      1. Преобразование концептуальной модели в реляционную модель.

      2. Нормализация базы данных.

      3. Определение характеристик атрибутов.

   4. Создание БД в выбранной СУБД.

   5. Поддержка целостности данных.

      1. Декларативная поддержка ограничений целостности.

      2. Процедурная поддержка ограничений целостности.

   6. Реализация операций над данными.

6. Список литературы.

---