Средства представления инфологической модели данных

⇐ ПредыдущаяСтр 17 из 30Следующая ⇒

Популярной в настоящее время наглядной формой представления модели на информационно-логическом уровне являются ER- диаграммы (ER – от англ. Entity – Relationship, т.е. сущность-связь) В них сущности, атрибуты и связи изображаются условным образом. Условные обозначения элементов диаграммы представлены в таблице 6.3.

Связь соединяется с ассоциируемыми сущностями линиями (рис. 6.7). Возле каждой сущности на линии, соединяющей ее со связью, цифрами указывается класс кардинальности, включающий в себя модальность и мощность связи (таблица 6.4).

Таблица 6.3

Обозначения элементов ER-диаграммы в нотации Чена

Элемент диаграммы	Обозначает
	сущность
	связь
	атрибут
	первичный ключ

Модальность «может» означает, что экземпляр одной сущности может быть связан с одним или несколькими экземплярами другой сущности, а может быть и не связан ни с одним экземпляром.

Модальность «должен» означает, что экземпляр одной сущности обязан быть связан не менее чем с одним экземпляром другой сущности.

Таблица 6.4

Значения кардинальности связи

Кардинальность	Значение (модальность, мощность)	Обозначение в других нотациях
0, 1	Может / Один
1, 1	Должен / один
0, N	Может /много
1, N	Должен/Много

Описанный графический синтаксис позволяет однозначно читать диаграммы, пользуясь следующей схемой построения фраз:

< Каждый экземпляр СУЩНОСТИ 1> < МОДАЛЬНОСТЬ СВЯЗИ> < НАИМЕНОВАНИЕ СВЯЗИ> < ТИП СВЯЗИ> < экземпляр СУЩНОСТИ 2>.

Каждая связь может быть прочитана как слева направо, так и справа налево. Если Сущность 1 – Заказ, а Сущность 2 – Заказчик, а наименование связи «Заказывание», то связь на рисунке 6 читается так:

· справа направо: «Каждый Заказчик может заказать несколько Заказов».

· слева налево: «Каждый Заказ обязан быть заказан ровно одним Заказчиком».

Нормализация отношений

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

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

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

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

· Сведения о покупателях.

· Дату заказа и количество заказанного товара, данные о менеджере, обслуживающем заказ.

· Характеристику проданного товара (наименование, стоимость, и т.д.).

Таблицу, содержащую все необходимые реквизиты можно рассматривать как однотабличную БД (рисунок 6.7). Основная проблема заключается в том, что в ней содержится значительное количество повторяющейся информации. Такая структура данных является причиной следующих проблем, возникающих при работе с БД:

· Приходится тратить значительное время на ввод повторяющихся данных. Например, для всех заказов, сделанных одним заказчиком, придется каждый раз вводить одни и те же данные о заказчике.

· При изменении адреса или телефона заказчика необходимо корректировать все записи, содержащие сведения о заказах этого заказчика.

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

· Любые нештатные ситуации потребуют значительного времени для получения требуемой информации.

Первая нормальная форма

Таблица, структура которой приведена на рисунке 6.7, является ненормализованной. Таблица в первой нормальной форме (1НФ) должна удовлетворять следующим требованиям:

· Таблица не должна иметь повторяющихся записей.

· В таблице должны отсутствовать повторяющиеся группы полей.

· Строки должны быть не упорядочены

· Столбцы должны быть не упорядочены.

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

В таблицах большинства СУБД записи упорядочены, поэтому требование 3 не может быть удовлетворено.

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

· сведения о заказчиках

· номер и дату заказ клиента, данные о менеджере, обслуживающем заказ.

· код, наименование, количество заказанного товара.

Поэтому разобьем таблицу Заказы на три отдельные таблицы (Заказчик, Заказ и Заказано) и определим ИНН фирмы в качестве совпадающего поля для связывания таблицы Заказчик с таблицей Заказ и № заказа – для связывания таблиц Заказ и Заказано (рисунок 6.8)

Отметим, что отношение между связываемыми таблицами “один-ко-многим”

Таблица Заказ содержит данные о клиентах. Определим ключевое поле ИНН фирмы. Аналогично для таблицы Заказ – ключевое поле Номер Заказа. Таким образом, для таблиц Клиенты и Заказы решена проблема повторяющихся групп.

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

· Добавить в таблицу новое уникальное ключевое поле Счетчик, что позволит однозначно идентифицировать каждую запись. Это не лучший способ, т.е. в дальнейшем при построении схемы данных не позволит установить связь между таблицами.

· В качестве ключа использовать составной ключ, состоящий из 2 полей Номер Заказа и Код товара.

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

Вторая нормальная форма

О таблице говорят, что она находится во второй нормальной форме, если:

· Она удовлетворяет условиям первой нормальной формы.

· Любое неключевое поле однозначно идентифицируется полным набором ключевых полей.

Из приведенного определения видно, что понятие 2НФ применимо только к таблицам, имеющим составной ключ. В нашем примере такой таблицей является Заказано, в которой составной ключ образуют поля Номер Заказа и Код Товара. Данная таблица не является таблицей во 2НФ, т.к. поля Наименование, Единица измерения однозначно определяются только одним из ключевых полей – Наименование Товара.

Для приведения таблицы ко 2НФ выделим из таблицы Заказано таблицу Товар, которая будет содержать информацию о товарах (рисунок 6.9). Для связывания таблиц Заказано и Товары используется поле Код товара.

Третья нормальная форма

О таблице говорят, что она находится во второй нормальной форме, если:

· Она удовлетворяет условиям второй нормальной формы

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

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

В таблице Заказ поле Тел содержит номера телефонов менеджеров, которые однозначно определяются значением поля Контактная персона (при условии что нет однофамильцев) и не зависит от Номера Заказа. Следовательно, т.к. неключевое поле (Тел) однозначно определяется другим неключевым полем (Контактная персона), таблица Заказ не является таблицей в 3НФ. Для приведения этой таблицы к 3НФ создадим новую таблицу Сотрудник.

В результате получаем инфологическую модель (ИЛМ) базы данных «Заказы» (рисунок 6.10)

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

ИЛМ отражает иерархию подчинения объектов. В одно-многозначных связках каждый подчиненный объект необходимо разместить ниже главного. Все объекты должны быть распределены по уровням. На рисунке 6.11 представлен порядок заполнения таблиц.

Сначала вносятся данные в таблицы «Заказчик», «Сотрудник», «Товар». Таблица «Заказ» заполняется на основе данных из таблиц «Заказчик» и «Сотрудник». А данные в таблицу «Заказано» вносятся, когда все остальные таблицы уже заполнены.

⇐ Предыдущая 12 13 14 15 161718 19 20 21 Следующая ⇒