Основные понятия теории баз данных.

Автор: Пользователь скрыл имя, 18 Ноября 2012 в 14:40, лекция

Описание работы

Лекции с глоссарием по базам данным

Работа содержит 1 файл

Лекции_БД_ВМЕСТЕ С ГЛОССАРИЕМ.doc

— 1.52 Мб (Скачать)

 

 

A → B

A → K

B → D

K → C

Рис. 6.25  Диаграмма после удаление транзитивной зависимости A → D


 

 

После того как из диаграммы были удалены все избыточные зависимости, формируем следующие отношения:

R1 (B, D)

R2 (K, C)

R3 (A, B ,K)


 

    1. Общая схема проектирования баз данных методом декомпозиции

 

    1. Построение универсального отношения.
    2. Определение всех функциональных зависимостей, существующих между атрибутами универсального отношения.
    3. Удаление всех избыточных функциональных зависимостей.
    4. Определяем, находится ли отношение в НФБК, если да - проектирование закончить, если нет – отношение разбивается на два.
    5. Шаги 4 и 5 повторяются для всех отношений, полученных в результате декомпозиции, до тех пор пока все отношения не будут находиться в НФБК.

 

 

 

 

    1. Проектирование базы данных по предметной области “Начальник отдела”.

 

Возвратимся снова к примеру  базы данных “Начальник отдела”.

 

  Рис. 6.26 Универсально отношение  R (Сном, Сфам, Тном, Лном, Проект, Квартал, Вклад)


 

Детерминанты не являющиеся возможными ключами:

Сном

Лном

Тном


 

Возможным ключом является Сфам, Проект, Квартал.

Универсальное отношенияе R (Сном, Сфам, Тном, Лном, Проект, Квартал, Вклад)

и не находится в НФБК и нуждается  в декомпозиции.

Выявление функциональных зависимостей

 

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

 

Сном ® Лном ®Тном

Сном ® Тном ® Лном

Сном, Проект, Квартал®Вклад

Декомпозиция универсального отношения

 

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

 

Производим декомпозицию отношения R (Сном, Сфам, Тном, Лном, Проект, Квартал, Вклад) на

R 1 (Лном, Тном) и R2 (Сном, Сфам, Лном, Проект, Квартал, Вклад).

 

 

Возможные ключи: Лном, Тном

Детерминанты:        Лном, Тном

Отнонение находится в НФБК

Рис. 6.27 Отношение R 1 (Лном, Тном)


 

 

Возможные ключи: <Проект, Квартал, Вклад>

Детерминанты:        <Проект, Квартал, Вклад>

                                   Сном

Отношение не находится в НФБК.

Рис. 6.28 Отношение R2 (Сном, Сфам, Лном, Проект, Квартал, Вклад)


 

 

Произведем декомпозицию отношения R2 (Сном, Сфам, Лном, Проект, Квартал, Вклад) на

R3 (Сном, Сфам, Лном) и R4 (Сном, Проект, Квартал, Вклад).

 

В отношении R3 (Сном, Сфам, Лном) объединим зависимости Сном ® Сфам и Сном ® Лном в зависимость Сном ® Сфам, Лном.

 

Возможные ключи: Сном

Детерминанты:        Сном

Отнонение находится в НФБК

Рис. 6.29 Отношение R3 (Сном, Сфам, Лном).


 

 

Возможные ключи: <Проект, Квартал, Вклад>

Детерминанты:        <Проект, Квартал, Вклад>

Отнонение находится в НФБК

Рис. 6.30 Отношение R4 (Сном, Проект, Квартал, Вклад).


 

 

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

 

R2 (Лном, Тном)    – находится в НФБК

R3 (Сном, Сфам, Лном)   – находится в НФБК

R4 (Сном, Проект, Квартал, Вклад)  – находится в НФБК

 

Таблицы 6.21-6.23 демонстрируют отношения R2, R3, R4 полученные в результате декомпозиции универсального отношения R.

 

 

 

 

 

Таблица 6.21 R2.

Таблица 6.22 R3.

 

Таблица 6.23 R4.

Лном

Тном

 

Сном

Сфам

Лном

 

Сном

Проект

Квартал

Вклад

25АП

5-17

 

289

Иванов

25АП

 

289

РКТ14

1990,3

3

4КТ

8-29

 

315

Николаев

4КТ

 

289

Зенит

1990,3

5

14ММ

4-85

 

429

Андреев

25АМ

 

289

ВКТ14

1990,4

2

     

559

Зайцев

14ММ

 

289

ВТА2

1990,4

4

             

315

ВКТ14

1990,3

6

             

315

ВТА8

1990,4

7

             

315

ВКТ14

1990,4

8

             

429

Зенит

1990,3

2

             

429

ОТР6

1990,4

7

             

429

ВКТ14

1990,4

4

             

559

ОВ77

1990,3

6


Проверка на наличие аномалий в  отношениях базы данных “Начальник отдела”

 

Присутствуют ли в этой базе данных аномалии вставки, удаления или обновления ?

Проверяем базу данных запросами взяв их из темы 6.3.

 

Вставка. На работу в лабораторию 25АР приняли Сорокина, его номер 687. Эта информация помещается в отношение R3 <687,Сорокин, 25АР>. Если теперь сделать запрос составить список сотрудников, вклад которых равен или меньше 2. Так как запрос будет обращен к отношению R4 будут выбранны сотрудники с табельными номерами 429, 289. После соединения таблиц мы получим ответ: Иванов и Андреев имели вклады в проекты меньше или равные трем.

Сорокина здесь нет, таким образом  аномалия вставки, присутствующая в  исходном отношении, устроена в результате декомпозиции.

 

Обновление. В исходном отношении возникла проблема при изменении телефона у Иванова на 9-17. Теперь при изменении телефона будут производится следующие действия: если мы сгенерируем запрос: из отношения R3 по табельному номеру Иванова будет определен номер лабратории в которой он работает, далее в отношения R2 изменим телефон лаборатории на 9-17. Теперь при запросе напечатать телефон лаборатории 25АР, мы получим ответ: 9-17.

Аномалия обновления, присутствующая в исходном отношении устранена  в результате декомпозиции.

Удаление. Финансирование проекта ОВ77 прекращено. Информация о проекте должна быть удалена из БД. В отношении R3 нужно удалить все записи со значением Проект=ОВ77

В исходном отношении это правило  к удалению из базы информации о  сотруднике 559 Зайцев.

В нашем случае информация о сотрудниках храниться в R2 и не будет потеряна при удалении кортежей со значением Проект=ОВ77 из отношения R3.

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

 

Цена за устранение аномалии –  увеличение количества отношений. Теперь запросы к базе данных будут реализовываться более сложно, т.к. возможно понадобится прохождение цепочки из двух или трех отношений при поиске требуемых данных.

 

  1. Семантическое моделирование или проектирования баз данных методом “Сущность-связь”

 

 

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

 

Предлагается модель данных, называемая моделью “сущность-связь” (entity-relationship model). Эта модель основывается на некоторой важной семантической информации о реальном мире. Вводится специальный диаграммный метод как средство проектирования баз данных.

 

    1. Сущности и связи

 

Рассмотрим простейший пример. Предположим, проектируется БД, предназначенная  для хранения информации о преподавателях и курсах, которые они читают. Двумя главными объектами, или сущностями, представляющими в данном случае интерес, являются “Преподаватель” и “курс”. Между этими сущностями существует связь ЧИТАЕТ.

 

           сущность

                связь

             сущность

  Рис. 7.1 Сущности и связи


 

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

 

 

Диаграмма ЕR–экземпляров:

 

    Рис. 7.2 Диаграмма ER-экземпляра


 

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

Диаграмма ER–типа:

 

     Рис. 7.3 Диаграмма  ER-типа


 

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

Терминология метода “Сущность-связь”

 

Термины, используемые в ER–методе, не могут быть определены строго, тем не менее, их необходимо определить.

 

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

 

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

 

Атрибут есть свойство сущности. Например атрибутами сущности преподавателя могут быть: номер преподавателя, фамилия, телефон, должность, адрес и т.п.

 

Ключ сущности – это атрибут или набор атрибутов, значения которых однозначно определяют экземпляр сущности.

 

Ключ связи – набор ключей сущностей, соединяемых данной связью.

 

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

 

    1. Степень связи

 

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

 

 

Пример 1: Каждый преподаватель читает не более одного курса, и каждый курс читается не более чем одним преподавателем (т.е. могут быть преподаватели которые ничего не читают и ни кем не читаемые курсы).

  не должны

            не должны

Рис. 7.4 Диаграмма ER-экземпляра для примера 1


 

 

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

должны

         не должны

Рис. 7.5 Диаграмма ER-экземпляра для примера 2


 

 

Пример 3: Каждый преподаватель читает не более одного курса, каждый курс читается только одним преподавателем.

не должны

      должны

Рис. 7.6 Диаграмма ER-экземпляра для примера 3


 

 

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

должны

        должны

Рис. 7.7 Диаграмма ER-экземпляра для примера 4


 

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

 

    1. Класс принадлежности сущности

 

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

 

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

 

Используется понятие класс принадлежности сущности. Класс принадлежности сущности связи является обязательным в случае обязательного участия. Класс принадлежности сущности связи является необязательным в случае необязательного участия. Класс принадлежности конкретной сущности в конкретной связи определяется из инфологической модели предметной области.

Информация о работе Основные понятия теории баз данных.