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

Нотация – это правило, в соответствии с которым отображается диаграмма сущность-связь.

Нотация Чена

Многозначный атрибут - наличие нескольких значений. Не может быть на конечных этапах проектирования.

Сущности

Независимая сущность

Зависимая сущность

Связь

Атрибут

Внешний ключ атрибут

Первичный ключ атрибут

Многозначный атрибут

Связи

Степень связи, координальность

Нотация Мартина

Сущности

Имя сущности

Атр1

Атр2

Атр3

….

Обозначение степени и типа связи

1-1

1-ко многим

1/0

Нотация Баркера

Использует обозначения сущностей, как в предыдущем варианте. Вместо подчеркивания у атрибутов – спецсимволы (#, @, …). Связи, как и в предыдущем случаи, одной или множественной линиями. Кардинальность по-другому: Сплошная линия – обязательная, пунктирная – необязательная.

Итог: вся группа разработчиков одинаково и правильно понимает всю структуру БД. Есть некоторая общность представления Предметной области, понимание семантики (то есть, как функционирует предметная области). Приступим к проектированию.

Проектирование структуры бд

В настоящее время существует два основных подхода к проектированию БД (реляционные):

1. Предметно-ориентированный подход основан на использовании реальной структуры объектов конкретной предметной области.

Положительные характеристики:

• весьма невысокие затраты на проектирование и реализацию.

• БД не является очень большой, достаточно компактные небольшие БД.

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

Недостаток: практически невозможно адаптировать на другие предметные области.

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

   1. Оцениваются наиболее возможные пути доступа к данным

   2. Способы выборки данных

   3. Реализуются общие механизмы для представления данных на логическом уровне

   4. Делается попытка реализовать все предвидимые задачи, которые может решать данная система. В нужный момент она должна представить нужные инструменты для решения

Получается универсальная система, в которой предусмотрены все типовые ситуации.

Положительные моменты:

• Прикладной подход позволяет создавать БД, которая подходят практически для любой предметной области

Недостатки:

• Громоздкая и требует много вычислительных средств

• На разработку требуется достаточно большое количество средств разработчиков

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

Типичный пример: 1С Предприятие

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

Основная цель проектирования – получение «чистого» проекта БД. Он предполагает, что каждая порция информации встречается только один раз и только в одном месте.

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

Основные недостатки (или аномалии), возникающие в проектах. Способы их исключения.

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

1. Более правильный: первичные отношения представляются единственной таблицей. Количество атрибутов составляет 3-4 десятка.

2. Когда в качестве первичных отношений берутся аналоговые варианты сущностей, полученные на этапе проектирования сущность-связь.

Предметная область: Необходимо создать ИБ для некоторого предприятия. Оно занимается производственной деятельностью и осуществляет выпуск некоторых изделий.

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

Детали характеризуются стоимостью, некоторыми физическими характеристиками, место приобретения.

В системе должна быть информация о дате закупки деталей.

Изделие	Вид	Цена	Детали	ЦенаДетали	ФизХарактер	Поставщик	АдресПоставщика	Дата закупки
Изд1	Вид1	#	Деталь2	#	-	-	-	-
Изд1	Вид1	#	Деталь3	#	-	-	-	-
Изд1	Вид1	#	…			-	-	-
Изд1	Вид1	#	Деталь15	#	-	-	-	-
Изд3	Вид3

Есть многозначные атрибуты, следовательно, это не таблица. Все атрибуты должны быть атомарными. Это список.

Если продублировать кое-какую информацию, то получится первичная таблица.

Такая таблица обладает недостатками:

1. Аномалия избыточности

2. Потенциальная противоречивость – Аномалия обновления

3. Аномалия включения информации (невозможно занести информацию о потенциальных поставщиках, например)

4. Аномалия удаления (потеря полезной информации при необходимости удалить какую-то строчку).

При проектировании РБД единственный способ – декомпозиция или разбиение на две и более таблиц.

Таблица 1 Изделия

Наименование	Вид	Цена
Изд.1	-	-
Изд.2	-	-

Таблица 2 Состав изделия

НаименованиеИзделя	КомплектующаяДеталь	СтоимостьДетали	ФизХарактер
Изд1	Деталь1

Таблица 3 Поставщики

НаименованиеПоставщика	Адрес
Пост1	-
Пост2	-

Таблица 4 Поставки

Поставщик	Деталь	Дата
Пост1	Деталь1	-
Пост1	Деталь3	-

Проведем анализ:

Избыточность уменьшена. Сократилось в той же мере, как и избыточность. Аномалия удаления и Аномалия включения исчезли как таковые в таблице Поставщики. Аномалия удаления и добавления остались в таблице Состав Изделия.

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

Таблица 1 Изделия

Код

Наименование

Вид

Цена

Код или шифр должен быть небольшого размера, чтобы не вносить избыточность. При добавлении информации код должен генерироваться автоматически. Код может быть числом или же строковым.

Таблица 2 Состав

Код Изделия

Детали

Стоимость Детали

ФизХар

Таблица 3 Поставщики

Код Поставщика

Наименование

Адрес

Таблица 4 Поставки

Код Поставщика

Деталь

Дата

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

Дальше нужно снова использовать декомпозицию.

Таблица 5 Детали

Код Детали

Наименование

Стоимость

Физ Характер

В таблице 2 Столбик Детали заменяется на Код детали. Избыточность уменьшилась. Кроме того, характеристики Стоимость и Физ Характеристики будут удалены из таблицы 2.

Анализ: Аномалии уменьшены на сколько возможно.

Можно еще выделить вид в отдельную таблицу.

Корректнее стоимость детали привязать к поставке, а из деталей удалить.

Таблица 6 Возможные виды изделий

Код вида

Наименование

Таблица 7 История цен

Код изделия

Дата

Цена

Но еще лучше следующее: Можно ориентироваться по дате продажи.

То, что мы сейчас проделали – интуитивная нормализация

02112011

Реляционная модель данных

Является наиболее распространенной. Почему?

1. Представление данных в виде таблиц является наиболее удобным форматом для пользователя.

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

В теории множеств существует понятие отношений:

Если заданное множество Д1, Д2,..,Дn, то отношением R является декартовым произведением исходных множеств (оно состоит из кортежей, при чем каждый элемент является элементом соответствующего множества). При этом исходные множества называются доменами. n – степень соответствующего отношения.

Строки таблицы – кортежи. Столбцы – атрибуты Ai. Количество атрибутом равно количеству исходных множеств. Атрибуты – подмножество Д.

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

С другой стороны каждый атрибут Ai можно рассматривать как проекцию на соответствующую i-ую координату.

Записывается так R1(A1, A2)

Можно дать новое определение:

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

В РМД предполагается, что все отношения являются нормализованными (все атрибуты являются атомарными). Операции над отношениями осуществляются в РМД двумя способами: методы реляционного исчисления и методы реляционной алгебры.

МРИ базируются на теоретических основах исчисления предикатов. Использование РИ имеет следующее преимущество:

1. Появляется возможность манипулирования данных на уровне выходного документа.

2. РИ позволяет создавать языки манипулирования данными не процедурного типа (типа SQL).

3. Пользователю дается возможность создавать и описывать данные независимо от процедур поиска и доступа к данным.

p(x1, x2,…,xn)=0|1

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

В РИ принято связывать с каждым отношением вида R(A1, A2,…,An) некоторый предикат p(x1, x2,…,xn). При этом значение атрибутов и значение аргументов предиката имеют одну и ту же область определения. Тогда, если такая связь создана, если предикат p с конкретными значениями атрибутов (a1, a2, …, an) принимает истинное значение, то соответствующий кортеж <a1,an> входит в состав отношения R. Если значение ложь, кортеж не принадлежит исходному отношению.

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

R1={(12,1),(10,4),(8,6),(7,3)}

Соответствующий предикат p1(x1,x2). Область определения первого 12, 10,8,7. Второго 1,4,6,3.

Можно на основе существующего предиката задать новое выражение. p2(x1)=

Создаем новое отношение R2(A1)={10,8,7}

Недостаток: отсутствие процедурности, то есть пользователь никаким образом не может влиять на реализацию процедур поиска и доступа к данным.

МРА

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

1. Операция объединения отношений. Если заданы два отношения А = {1,2,=,//} В= {8,10,+,-}. Результирующее отношение С состоит из элементов или отношения А, или отношения В. С= {1,2,=,//,8,10,+,-}.

2. Операция пересечения. Результат операции – это отношение С, состоящее из кортежей, который принадлежат и А, и В. В нашем примере отношение С пустое.

3. Операция вычитания. Результат вычитания В из А – это отношение С, состоящее из кортежей принадлежащих А, но не принадлежащих В.

4. Операция декартово произведения отношений. Результат – создание отношение С, полученное соединением каждого кортежа из отношения А с каждым кортежем из отношения В. Студенты*дисциплины = студент и какие дисциплины он изучает.

5. Операция проекция. Два операнда, но первый операнд – это отношение, а второй – это список атрибутов. A = {1,2,4,=,//,+} B={a1,a3}. С = {1,4,=,+}. Скрытие данных от отдельных видов пользователей.

6. Операция ограничения. Имеет два операнда: отношение и логическое выражение, задающее какое-то условие. Результирующее отношение – только те кортежи, которые соответствуют заданному логическому выражению. На этом основан Фильтр.

7. Операция соединения позволяет создать новое отношение из исходных А и В путем соединения однопорядковых строк из каждого отношения.

16112011

НОРМАЛИЗАЦИЯ.

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

Структура БД определяется множеством таблиц(отношений) и множеством связей.

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

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

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

Функциональная зависимость соответствует отношению 1 к 1 или 1 ко многим внутри таблицы.

Избыточная функциональная зависимость. Эта такая функц. зависимость, которая может быть получена на основе других зависимостей, находящихся в таблице. Схема БД - множество таблиц, связ. между собой. Корректной считается такая схема БД, в которой полностью отсутствует изб. функц. зависимость.(иначе декомпозиция таблиц - одна или неск. таблиц разбиваются на доп. отношений. новое мн-во таблиц является проекцией исходных отношений).

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

Условия обратимости:

1. в новых таблицах не должны появляться ранее отсутствовашие кортежи.

2. на схеме(на таблицах) новой схемы должно выполняться исходное множество функциональных зависимостей.

Если была функц. связь, то в результате декомпозиции она превратится в связь между таблицами.

Предполагается, что существует несколько состояний исходного проекта, которые называются нормальными формами. Каждая н.ф. определяется определенными требованиями, которые должны выполняться на каждом этапе проектирования.(1, 2, 3 нф. фбк. 4...нф).

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

Нормальные формы:

1 нормальная форма. Простой атрибут - только одно значение в каждый момент времени. Составной - несколько. Отношение находится в 1 н.ф. если все его атрибуты являются простыми(атомарными).

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

сотр(фио, адрес, дети, ист. работы)

дети(имя, дата)

ист. раб.(дата приема на должность, должность, история зп)

ист. зп.(дата начисления, сумма)

В конечных отношениях все атрибуты - атомарные.

Кодд - алгоритм приведения к 1 нормальной форме. Строится иерархия(дерево) отношений, узлами которого являются исходные отношения и все неатомарные атрибуты. Начиная с отношения, которое находится в вершине, выбирается первичный ключ родительского отношения и добавляется первичный ключ подчиненного отношения. Созданный таким образом ключ является первичным ключем для подчиненного отношения. На след. шаге из родительского отношения удаляются один или несколько составных доменов, которые отражены в подчиненном отношении. Далее эти шаги повторяются рекурсивно для все подчиненных вершин в составе дерева. При этом ключ, соответствующий доменам, добавленным из родительского отношения, называется связывающим ключем таблиц.(вторичный, внешний)

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

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

поставки(поставщик, товар, цена товара)

поставщик, товар -> цена

товар -> цена

тогда:

(поставщик, товар)

(товар, цена)

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

23112011

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

Для определения ТНФ вводится понятие транзитивной функциональной зависимости.

Допустим, атрибуты А, Б, С принадлежат одной и той же таблице и отношению. При этом в таблице есть отношение АкБ и БкС, обратной нет. В этом случае С транзитивно зависит от атрибута А. А, как правило, первичный ключ.

Пример:

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

1. каждая организация использует только одно складское помещение;

2. одно и то же складское помещение может разделяться между несколькими организациями.

Таблица Хранение_товаров (Организация, Склад, Объем склада)

Организация – первичный ключ. Недостатки или аномалии: Дублирование информации о складе и об объеме складского помещения.

Зависимости: Организация -> склад; склад->объем. Следовательно, орг->объем

Разбиваем на две таблицы: Хранение_товаров (Организация, склад) и Характеристики_склада (Склад, объем).

Недостатки исчезают.

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

Нормальная форма Бойс и Кодда

Является уточнением или дополнительным ограничением, накладываемым на третью нормальную форму.

Отношение находится в НФБиК, если выполняются требования ТНФ и отсутствуют зависимости первичного ключа от неключевых атрибутов.

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

Четвертая нормальная форма

Основана на многозначных зависимостях.

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

Пример:

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

Ограничения: разные преподаватели могут вести одни и те же дисциплины. Один и тот же преподаватель может вести разные дисциплины. Набор методических пособий для изучения дисциплин определяется преподавателем.

Преподаватель	Дисциплина	Методички
1	математика	Уч1
1	математика	Уч2
2	математика	Уч1
2	математика	Уч3

Недостатки: все аномалии, какие возможны

Функциональные зависимости: препод->>дисциплина, препод->>методичка

(->> множественная зависимость)

Первичный ключ – все три поля

Разбиваем на две таблицы Преподаватель-Дисциплина и Преподаватель-Учебник.

Обязательно вводить Код!

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

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

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

Отношение соответствует ПНФ, если выполняются требования всех предыдущих форм и любая зависимость по соединению определяется только возможными ключами.