Методические рекомендации - Омский государственный
advertisement
П.С. Гладкий, Е.А. Костюшина, М.Е. Соколов
ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ
Методические указания
к выполнению лабораторных работ
Омск - 2006
ОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
Факультет компьютерных наук
Кафедра кибернетики
П.С. Гладкий, Е.А. Костюшина, М.Е. Соколов
ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ
Методические указания
к выполнению лабораторных работ
для студентов 3 курса, обучающихся по специальности
220100 – Вычислительные машины, комплексы, системы и сети
Омск - 2006
УДК
П.С. Гладкий, Е.А. Костюшина, М.Е. Соколов, Проектирование баз данных:
Методические указания к лабораторным работам. Омск: Издательство: Наследие. ДиалогСибирь, 2006. 32 с.
Методические указания являются руководством для выполнения лабораторных
работ по курсу «Базы данных». Рассматриваются вопросы проектирования баз
данных с помощью метода нормализации форм и ER-диаграмм.
Для студентов факультета компьютерных наук специальности 220100.
Работа подготовлена на кафедре кибернетики
Омский госуниверситет, 2006
Предисловие
Цель предлагаемых методических указаний
практические навыки проектирования баз данных.
дать
теоретические
и
Для проектирования баз данных используют следующие инструменты:
1. Реляционная модель данных – способ представления данных предметной
области
2. Структурированный язык запросов (SQL) – универсальный способ
манипулирования данными.
При разработке базы данных выделяют следующие уровни моделирования,
при помощи которых происходит переход от предметной области к конкретной
реализации базы данных (БД) средствами конкретной системы управления базами
данных (СУБД):
1. Модель предметной области
2. Логическая модель данных
3. Физическая модель данных
4. База данных и приложения
При разработке логической модели данных выделяют два подхода:
1. Сбор информации об объектах решаемой задачи в рамках одной таблицы
(одного отношения) и последующая декомпозиция ее на несколько
взаимосвязанных таблиц на основе процедуры нормализации отношений.
2. Формулирование знаний о системе (определение типов исходных данных и
их взаимосвязей) и требований к обработке данных, получение с помощью
CASE-системы (Computer Aided Software Engineering –система
автоматизации проектирования и разработки баз данных) готовой схемы БД
или даже готовой прикладной информационной системы.
Исходя из вышесказанного, предлагается следующая структура
практических занятий по проектированию баз данных:
1. Проектирование методом нормализации отношений (Лабораторная
работа №1)
2. Проектирование с помощью CASE средств (Лабораторная работа №2)
3. Основы структурированного языка запросов (SQL) (Лабораторная работа
№3)
Первая лабораторная работа выполняется в письменном виде, остальные с
использованием программных продуктов.
Первую лабораторную работу рекомендуется выполняться параллельно с
другими.
5
Лабораторная работа № 1. Проектирование схемы базы
данных
Цель работы: изучение общих принципов проектирования реляционных моделей
данных, знакомство с основами реляционного исчисления.
Задачи:
ознакомиться с предметной областью;
научиться основам проектирования и создания схем данных;
изучить основы реляционного исчисления;
самостоятельно разработать схему данных для предметной области
(формирование описания таблиц, определение первичных ключей).
Требования:
схема данных должна содержать не менее 5 базовых отношений (не
считая справочных);
2 запроса в терминах реляционного исчисления;
работа должна быть оформлена согласно приведенному образцу.
Лабораторная работа № 2. Проектирование схемы базы
данных с помощью CASE средств
Цель работы: научиться проектировать реляционные модели данных с
помощью CASE средств.
Задачи:
изучить предметную область по теме;
спроектировать ER-диаграмму по данной предметной области;
провести преобразование ER-модели в реляционную модель.
Требования:
в качестве CASE-средства при проектировании схемы базы данных
необходимо использовать Oracle Designer или CASE Studio, СУБД –
Oracle;
количество сущностей в ER-диаграмме не менее 7;
между сущностями в ER-диаграмме должны быть показаны все типы
связей.
Варианты задания по лабораторным работам №1, №2
1. «Абитуриент». а) администратор ВУЗа; б) член технической приёмной
комиссии; в) член экзаменационной комиссии.
2. «Факультет». а) ректор; б) декан; в) преподаватель; г) студент.
3. «Супермаркет». а) заведующий; б) продавец; в) покупатель; г) снабженец.
4. «Ателье по ремонту бытовой техники». а) директор; б) мастер; в) клиент;
г) поставщик деталей.
5. «Домоуправление». а) руководитель; б) паспортист; в) бригадир
ремонтников; г) работник районной администрации.
6. «Общественный транспорт». а) руководитель предприятия; б) диспетчер;
в) водитель; г) пассажир.
7. «Библиотека». а) библиотекарь; б) читатель; в) работник архива.
8. «Общественное питание». а) руководитель; б) снабженец; в) повар; г)
посетитель.
6
9. «Служба занятости». а) регистратор безработных; б) администратор
общественных работ; в) администратор по переобучению; г) безработный.
10. «Овощная база». а) руководитель базы; б) поставщик; в) заведующий
магазином; г) диспетчер автотранспорта.
11. «Обслуживание пассажиров на ж/д вокзале». а) администратор; б)кассир;
в) служба грузодоставки; г) пассажир.
12. «Дом отдыха». а) администратор дома отдыха; б) представитель
профкома предприятия; в) клиент; г) заведующий столовой при доме отдыха.
13. «Грузоперевозки». а) отправитель; б) получатель; в) диспетчер;
г)водитель автотранспорта.
14. «Школа». а) директор; б) учитель; в) родитель; г) ученик.
15. «Чемпионат по футболу». а) директор стадиона; б) судья;
в)администратор команды; г) болельщик.
16. «Туристическая фирма». а) руководитель фирмы; б) менеджер; в) клиент.
17. «Фотоателье». а) руководитель; б) клиент; в) фотограф.
18. «Музей». а) экскурсовод; б) билетер;
в) работник хранилища;
г)составитель экспозиций; д) посетитель музея.
19. «Рекламное агентство». а) руководитель агентства; б) рекламодатель;
в)менеджер агентства.
20. «Поликлиника». а) врач; б) больной; в) работник регистратуры.
21. «Студия звукозаписи». а) звукорежиссер; б) исполнитель; в) бухгалтер.
22. «Коллекционный винный погреб». а) владелец; б) соммилье(хранитель
винного погреба); в)покупатель.
23. «Оператор сотовой связи». а) абонент; б) менеджер; в) работник
технического отдела; г) работник справочной службы.
24. «Паспортный стол». а) начальник ПС; б) паспортист; в) гражданин;
г) работник справочной службы.
25. «Автосалон». а) заказчик; б) поставщик; в) менеджер; г) работник
технического сервиса.
26. «Выставочная галерея». а) посетитель выставки; б) экскурсовод;
в)куратор галереи г) составитель выставки.
27. «Политические деятели страны». а) избиратель; б) работник центральной
избирательной комиссии.
28. «Торговля недвижимостью» а) риэлтер; б) продавец; в) покупатель.
29. «Аптека» а) фармацевт; б) поставщик; в) покупатель.
Лабораторная работа № 3. Основы структурированного
языка запросов (SQL)
Цель работы: получить практический опыт написания SQL запросов.
Задачи:
изучить предложенную структуру БД;
написать 5 запросов, демонстрирующих знание SQL.
Требования:
СУБД – Oracle;
инструментарий PL/SQL Developer, SQL Plus;
из 5 запросов SQL: должны иметь подзапросы не менее 2 запросов, с
функциями агрегирования не менее 2 запросов.
7
Варианты задания по лабораторной работе № 3
Структура таблиц
ЛАБОРАТОРИИ
(Код лаборатории: Текстовый,
Наименование лаборатории: Текстовый,
Код руководителя: Текстовый,
Дата организации лаборатории: Дата,
Дата закрытия лаборатории: Дата)
СПЕЦИАЛЬНОСТИ
(Код специальности: Текстовый,
Наименование специальности: Текстовый
Дата открытия специальности: Дата,
Дата закрытия специальности: Дата)
СПИСОК СЛУЖАЩИХ
(Табельный номер: Текстовый,
Фамилия: Текстовый,
Имя: Текстовый,
Отчество: Текстовый,
Пол: Текстовый (возможные значения М, Ж),
Семейное положение: (возможные значения Ж, Х, Р, З),
Код лаборатории: Текстовый,
Телефон: Текстовый,
Код специальности: Текстовый,
Оклад: Числовой,
День рождения: Дата,
Адрес: Текстовый,
Характеристика: Текстовый)
ПРЕМИИ
(Табельный номер: Текстовый,
Размер премии: Числовой,
Номер приказа: Текстовый,
Дата приказа: Дата)
ДЕТИ СОТРУДНИКОВ
(Табельный номер: Текстовый,
Фамилия ребенка: Текстовый,
Имя ребенка: Текстовый,
Дата рождения: Дата)
Варианты возможных SQL-запросов
1. Список сотрудников, работающих в действующей лаборатории с
минимальным размером фонда заработной платы по лаборатории.
8
2. Список всех служащих с максимального для сотрудника размера премии,
если служащий не получал премий, то значение NULL.
3. Список руководителей действующих лабораторий с указанием числа
служащих в лабораториях
4. Список сотрудников, работающих в действующих лабораториях, где число
служащих превышает 10 человек.
5. Список сотрудников, работающих по специальностям, по которым число
служащих не превышает 5 человек.
6. Список сотрудников, имеющих максимальный общий объем премий.
7. Создать запрос, позволяющий получить следующую информацию о
сотруднике: ФИО, Дата рождения, Оклад, Надбавка (для родившихся до
1950 г. – 20% от оклада, после – 15% оклада). Данные упорядочить по полю
Фамилия.
8. Список всех служащих с указанием количества детей, если служащий не
имеет детей, то количество детей NULL.
9. Список сотрудников, работающих в действующей лаборатории, в которой
наибольший размер средней заработной платы по лаборатории в целом.
10. Список руководителей лабораторий с указанием количества детей для
каждого, если детей нет, то выводить NULL.
11. Список всех служащих с указанием размеров премий, получаемых ими, если
служащий не получал премию ни разу, то размер его премии указать как
NULL.
12. Список сотрудников, получающих оклад больше среднего по организации в
целом.
13. Список лаборатории с указанием количества служащих в каждой.
14. Список действующих лабораторий с указанием объема премии, полученной
каждой лабораторией.
15. Список руководителей лабораторий с указанием лаборатории.
16. Список лабораторий с указанием средней, максимальной и минимальной
заработной платы по каждой лаборатории.
17. Найти самого молодого руководителя действующей лаборатории.
18. Найти самого молодого сотрудника, имеющего детей.
19. Найти сотрудника с максимальным объемом премии.
20. Список детей, у которых родители получают заработную плату ниже
среднего по организации в целом.
21. Список сотрудников ни разу не получавших премии.
22. Список сотрудников имеющих более 3 детей и получающих заработную
плату ниже среднего по организации в целом.
23. Создать запрос, позволяющий получить следующую информацию по детям:
ФИО ребенка, Дата рождения, ФИО одного из родителей. Информацию
выводить по детям, родившимся с 1990 по 2006 года. Данные упорядочить
по полю Фамилии родителя.
24. Список разведенных служащих с указанием количества детей.
25. Список служащих с указанием суммарного размера премии сотрудника,
полученного им за весь период работы, и отклонения суммарного размера
премии сотрудника от максимального суммарного размера премии для
сотрудников по организации в целом.
9
Методические рекомендации
по выполнению лабораторной работы № 1
Описание предметной области
Рассмотрим пример базы данных «Видеопрокат».
Пункт видеопроката осуществляет прокат записей фильмов на различных
типах носителей: видеокассеты VHS, диски VCD и DVD; важно отметить, что как
на одном носителе может находиться несколько фильмов (например, сборник
мультфильмов на видеокассете), так и один фильм может быть записан на
несколько отдельных носителей (одного типа). Клиентами являются физические
лица.
В системе целесообразно выделить несколько ролей, которые могут
выполнять пользователи.
Клиент. Клиентов интересует, какие фильмы доступны в пункте
видеопроката вообще, какие можно взять в данный момент.
Сотрудник видеопроката. Сотрудник видеопроката работает с
клиентами: выдает и принимает носители, а также записывает
информацию о новых клиентов.
Выделение элементов данных по группам пользователей
Следующим шагом является выделение элементов данных. Оно
производится на основании анализа требований к информации, предъявляемых
пользователями различных ролей.
1. Клиент:
1.1. Наименование фильма (1)
1.2. Продолжительность фильма (2)
1.3. Режиссер фильма (3)
1.4. Актеры, занятые в фильме (4)
1.5. Год выхода фильма в прокат (5)
1.6. Рента за сутки (10)
1.7. Тип носителя (9)
1.8. Дата выдачи носителя клиенту (12)
1.9. Дата возврата носителя (13)
2. Работник проката:
2.1. Наименование фильма (1)
2.2. Продолжительность фильма (2)
2.3. Режиссер фильма (3)
2.4. Актеры, занятые в фильме (4)
2.5. Год выхода фильма в прокат (5)
2.6. Метка носителя (7)
2.7. Время добавления информации о носителе (8)
2.8. Тип носителя (9)
2.9. Рента за сутки (10)
2.10. Дата порчи/потери носителя (11)
2.11. Дата выдачи носителя клиенту (12)
10
2.12. Дата возврата носителя (13)
2.13. ФИО клиента (14)
2.14. Адрес электронной почты клиента (15)
2.15. Контактный телефон клиента (16)
Сведем все в общий список со сквозной нумерацией:
1. Наименование фильма
2. Продолжительность фильма
3. Режиссер фильма
4. Актеры, занятые в фильме
5. Год выхода фильма в прокат
6. Идентификатор носителя
7. Метка носителя
8. Время добавления информации о носителе
9. Тип носителя
10. Рента за сутки
11. Дата порчи-потери носителя
12. Дата выдачи носителя клиенту
13. Дата возврата носителя
14. ФИО клиента
15. Адрес электронной почты клиента
16. Контактный телефон клиента
Неплохим способом проверить атомарность атрибутов является определение
домена: множества значений, принимаемых атрибутом. Домен определяется типом
данных и ограничениями, накладываемыми на множество возможных значений
этого типа. В основном используются следующие типы данных: ЛОГИЧЕСКИЙ,
ЧИСЛО, СТРОКА, ДАТА, ВРЕМЯ (современные СУБД так или иначе
поддерживают все эти типы).
Атрибут №9 «Тип носителя» имеет строковый тип и содержит название типа
носителя: «кассета VHS», «диск DVD» — возможно, в ходе дальнейшего
технического прогресса он будет дополнен; фактически, домен этого атрибута
состоит только из этих двух строк. Вообще говоря, при работе с БД необходимо
иметь полный список точных значений этого атрибута в прикладной программе,
что может представлять собой проблему и нарушать принцип независимости
данных. Поэтому вводится новый атрибут №17 «Идентификатор типа носителя».
Атрибут №4 «Актеры, занятые в фильме», по всей видимости, нарушает
свойство атомарности: в этом атрибуте предполагается наличие нескольких
значений (имен актеров). Для решения проблемы достаточно удалить атрибут из
списка и добавить вместо него атрибут «Актер». Однако база данных
проектируется для предметной области «видеопрокат», а не, например,
«фильмография», где каждый актер представляет собой отдельную сущность. В
данном случае атрибут №4 содержит справочную информацию для клиента и не
будет постоянно использоваться в запросах как критерий отбора записей.
Данный список не обязательно является полным. После некоторой практики
проектировщик может сразу составить практически полный список атрибутов.
Определение множества функциональных зависимостей
Определим функциональные зависимости в прикладной области.
11
Рассмотрим атрибуты, характеризующие фильм.
Наименование фильма пока никаким атрибутом однозначно не определяется.
Такую ситуацию мы будем условно обозначать следующим образом: 0→1.
Рассмотрим зависимость 1 → 7 («Наименование фильма»→«Метка
носителя»). Мы вынуждены отбросить ее, т.к. возможна ситуация когда существует
два фильма с одинаковым названием, но записанные на разные носители (пункт
проката имеет два носителя идентичного содержания). Аналогичная ситуация
возникает с зависимостями, где определяющая часть это «Наименование фильма»,
а определяемая – остальные атрибуты характеризующие фильм.
Вообще говоря, тройка 1,3,5 («Наименование фильма», «Режиссер фильма»,
«Год выхода фильма в прокат») однозначно определяет фильм (одни и те же
режиссеры в один год редко снимают и картины, и их «ремейки»), и,
следовательно, все атрибуты, касающиеся его. В дальнейшем эта тройка будет
ключевыми атрибутами.
Значения атрибутов составных ключей многократно дублируются в записях
соответствующих таблиц: например, не все режиссеры сняли только по одному
достойному проката фильму. Поэтому в качестве ключевых атрибутов
рекомендуется использовать как можно более короткие: номера, коды, шифры.
Большинство существующих СУБД поддерживают такой тип, как ID
(счетчик) – он автоматически обслуживается СУБД. На физическом уровне
основой индексных файлов являются именно ключевые поля отношений, поэтому
крайне желательно использовать как можно короткие ключи фиксированной
длины. ФИО и наименования организаций для этого очевидно не подходят.
Поэтому мы введем новый элемент данных: №18 «ИДЕНТИФИКАТОР
ФИЛЬМА». По этим же соображениям введем атрибут №19 «ИДЕНТИФИКАТОР
КЛИЕНТА».
Теперь функциональные зависимости примут следующий вид:
«Идентификатор фильма» → «Наименование фильма» (18→1)
«Идентификатор фильма» → «Продолжительность фильма» (18→2)
«Идентификатор фильма» → «Режиссер фильма» (18→3)
«Идентификатор фильма» → «Актеры, занятые в фильме» (18→4)
«Идентификатор фильма» → «Год выхода фильма в прокат» (18→5)
Ранее уже был определен атрибут «Идентификатор носителя». Рассмотрим
теперь остальные атрибуты, касающиеся носителей.
«Идентификатор носителя» → «Метка носителя» (6→7)
«Идентификатор носителя» → «Рента за сутки» (6→10)
«Идентификатор носителя» → «Время добавления информации о носителе»
(6→8)
«Идентификатор носителя» → «Идентификатор типа носителя» (6→17)
«Идентификатор носителя» → «Дата порчи-потери носителя» (6→11)
Обратим внимание на зависимость «Идентификатор носителя» → «Дата
порчи-потери носителя» (6→11). Не все носители повреждены или украдены, а,
следовательно, эта зависимость будет выполняться не для всех носителей, и в этих
случаях атрибут из правой части будет принимать NULL значение. Использование
NULL требует поддержки данного типа со стороны СУБД, а также, например,
учета правил непривычной трехзначной логики при построении запросов.
12
Замечание1. Если предполагается, что неопределенные значения будут
встречаться относительно редко (например, для документальных фильмов нельзя
указать список актеров), то использование NULL-значений оправдано. В обратной
ситуации, когда большинство записей будут содержать именно NULL-значение
(именно дата порчи/потери носителя), целесообразно использовать понятие
области определения функциональной зависимости.
Рассмотрим остальные зависимости.
«Идентификатор типа носителя» → «Тип носителя» (17→9)
Для этой зависимости и вводился атрибут «Идентификатор типа носителя».
«Идентификатор клиента» → «ФИО клиента» (19→14)
«Идентификатор клиента» → «Адрес электронной почты клиента» (19→15)
«Идентификатор клиента» → «Контактный телефон клиента» (19→16)
Объект выдача носителя клиенту характеризуется всеми своими атрибутами:
носителем, клиентом, датой выдачи. По вышеописанным причинам необходимо
ввести еще один атрибут для внутреннего пользования: №20 «ИДЕНТИФИКАТОР
ВЫДАЧИ».
«Идентификатор выдачи» → «Идентификатор носителя» (20→6)
«Идентификатор выдачи» → «Идентификатор клиента» (20→19)
«Идентификатор выдачи» → «Дата выдачи носителя клиенту» (20→12)
«Идентификатор выдачи» → «Дата возврата носителя» (20→13)
Поскольку носитель каждый конкретный раз выдается только одному
клиенту, это необходимо отразить в функциональных зависимостях:
«Идентификатор выдачи» → «ФИО Клиента», «Адрес электронной почты
клиента», «Контактный телефон клиента»
Выше, при неформальном описании области отмечалась несколько
нетривиальная связь фильма и носителя. Например, нельзя выделить зависимости
«Идентификатор фильма»
→
«Идентификатор носителя» (18→6) и
«Идентификатор носителя» → «Идентификатор фильма» (6→18): один фильм
может располагаться на нескольких носителях, равно как и на одном носителе
может быть несколько фильмов. Поэтому имеет место некоторое распределение
фильмов по носителям.
Замечание 2. Распределение задается парой атрибутов «Идентификатор
носителя», «Идентификатор фильма» (6, 18). Поскольку на один носитель два
одинаковых фильма не пишут, эта пара также является составным ключом, и в
дополнительном идентификаторе необходимости не возникает. Для фильмов,
занимающих несколько носителей, необходимо хранить порядковый номер
разбиения (например, номер части). Однако столь длинные картины все же
редкость для кинопроката вообще, а, следовательно, для большинства пар
фильм-носитель значение атрибута «Номер тома» будет равно одному и тому
же, например, единице.
Целесообразно следующее решение: ввести
искусственный «Идентификатор распределения» (атрибут №21) и атрибут №22
«Номер тома».
Тогда получаем следующие зависимости:
13
«Идентификатор распределения» → «Идентификатор носителя» (21→6)
«Идентификатор распределения» → «Идентификатор фильма» (21→18)
«Идентификатор распределения» → «Номер тома» (21→22)
Построение минимального покрытия
Для построения минимального покрытия необходимо применить алгоритм
его построения.
Первым шагом является преобразование множества зависимостей ко
множеству зависимостей с определяемой частью из одного атрибута. На основании
правила декомпозиции, зависимость вида X → A1A2…Ak разбивается на множество
зависимостей X → A1, X → As, … X → Ak. В нашем случае подлежащей такому
преобразованию является зависимость
«Идентификатор выдачи» → «ФИО Клиента», «Адрес электронной почты
клиента», «Контактный телефон клиента».
По правилу декомпозиции получаем:
«Идентификатор выдачи» → «ФИО Клиента»;
«Идентификатор выдачи» → «Адрес электронной почты клиента»;
«Идентификатор выдачи» → «Контактный телефон клиента».
Второй шаг алгоритма заключается в удалении избыточных зависимостей.
Зависимость X→Y удаляется из множества зависимостей F, если множество F \
{X→Y} эквивалентно исходному множеству F.
Для проверки эквивалентности множеств функциональных зависимостей
используется понятие замыкания множества атрибутов. Замыканием X+ множества
атрибутов X зовется множество атрибутов {Ai} таких, что X→Ai F+, где F+ –
замыкание множества функциональных зависимостей.
Существует алгоритм проверки эквивалентности двух множеств
функциональных зависимостей F и G. Если для каждой зависимости X→Y F
выполнено Y X+G (X+G – замыкание X, построенное для множества зависимостей
G), то имеет место F G. Для проверки G F используется симметричное
утверждение. Если одновременно выполнены F G и G F, то множества
эквивалентны.
Возвращаясь ко второму шагу алгоритма, существует утверждение, что для
проверки эквивалентности указанных множеств (F \ {X→Y} и F) достаточно
построить X+G, где G = F \ {X→Y}, и проверить выполнение Y X+G. Если
утверждение истинно, то множества F и G эквивалентны, и зависимость может
быть удалена.
Второй шаг алгоритма заключается в описанной проверке всех имеющихся
зависимостей на избыточность. Здесь же в качестве иллюстрации будут
рассмотрены только две зависимости.
Рассмотрим зависимость: «Идентификатор выдачи» → «Идентификатор
клиента».
Для построения замыкания X+ множества атрибутов X применяется свой
алгоритм (X(i) – замыкание, построенное на очередном шаге):
Шаг 0. X(0) := X;
Шаг i. Пусть в результате последовательного просмотра множества
функциональных зависимостей для зависимости Y→Z выполнено Y X(i-1). Тогда
X(i) := X(i-1) {Z}.
14
Критерий остановки: алгоритм завершается, если за полный цикл просмотра
множества функциональных зависимостей не было произведено ни одной
модификации результирующего множества.
Построим замыкание атрибута «Идентификатор выдачи» для множества
зависимостей G:
«Идентификатор выдачи»+ = {
1. «Идентификатор выдачи»,
2. «Идентификатор носителя», «Дата выдачи носителя клиенту», «Дата
возврата носителя», «ФИО клиента», «Адрес электронной почты
клиента», «Контактный телефон клиента»,
3. «Метка носителя», «Время добавления информации о носителе»,
«Идентификатор типа носителя», «Дата порчи-потери носителя»,
«Рента за сутки»,
4. «Тип носителя» }
Атрибуты в замыкании разбиты на группы согласно причине их добавления.
Первая группа появляется в силу шага 0 алгоритма построения замыкания. Каждая
следующая группа содержит определяемые части функциональных зависимостей,
имеющих определяющие, состоящие из атрибутов предыдущих частей. Атрибуты
второй группы функционально зависят от «Идентификатора выдачи». Атрибуты
третьей части зависят от «Идентификатора носителя», четвертой — от
«Идентификатора типа носителя».
Как можно заметить, атрибут «Идентификатор клиента» в построенное
замыкание не входит. Зависимость остается.
Рассмотрим зависимость
«Идентификатор выдачи» → «ФИО Клиента»
Построим замыкание атрибута «Идентификатор выдачи» для множества
зависимостей без данной:
«Идентификатор выдачи»+ = {
1. «Идентификатор выдачи»,
2. «Идентификатор носителя», «Идентификатор клиента», «Дата выдачи
носителя клиенту», «Дата возврата носителя»,
3. «Метка носителя», «Время добавления информации о носителе»,
«Идентификатор типа носителя», «Дата порчи-потери носителя»,
«ФИО клиента», «Адрес электронной почты клиента», «Рента за
сутки», «Контактный телефон клиента»,
4. «Тип носителя» }
Здесь, несмотря на отсутствие в G зависимости «Идентификатор выдачи» →
«ФИО Клиента», атрибут «ФИО Клиента» появляется в построенном замыкании.
Данная зависимость избыточная и должна быть удалена.
Аналогичная проверка приводит к удалению следующих зависимостей:
«Идентификатор выдачи» → «Адрес электронной почты клиента»;
«Идентификатор выдачи» → «Контактный телефон клиента».
На третьем шаге алгоритма происходит удаление избыточных атрибутов из
определяющих частей. На этом шаге выполняется последовательный просмотр
множества зависимостей. Для каждой зависимости X→Y, где X = X1X2…Xk,
выполняется следующая проверка. Из X удаляется очередной атрибут Xi, после
чего проверяется эквивалентность F \ {X→Y} {X1X2…Xi-1Xi+1…Xn→Y} и F.
Если эквивалентность имеется, то атрибут не возвращается.
15
Как и на втором шаге, проверка эквивалентности сводится к построению
одного замыкания: (X1X2…Xi-1Xi+1…Xn)+F — и проверки Y на принадлежность ему
(в силу первого шага это один атрибут). Принадлежность означает эквивалентность
множеств, и в этом случае атрибут не возвращается.
Данное множество функциональных зависимостей не содержит таких, к
которым можно было бы применить третий шаг алгоритма. Минимальное
покрытие построено.
Построение канонической модели реляционного типа
В одно отношение будут входить (без повторов) атрибуты функциональных
зависимостей, чьи определяющие части совпадают и имеют одинаковую область
определения. Атрибуты из определяющих частей будут составлять первичный
ключ отношения.
Рассмотрим группу зависимостей, определяемых «Идентификатором
фильма»:
«Идентификатор фильма» → «Наименование фильма» (21→1)
«Идентификатор фильма» → «Продолжительность фильма» (21→2)
«Идентификатор фильма» → «Режиссер фильма» (21→3)
«Идентификатор фильма» → «Качество фильма» (21→4)
«Идентификатор фильма» → «Актеры, занятые в фильме» (21→5)
«Идентификатор фильма» → «Год выхода фильма в прокат» (21→6)
По ним строится следующее отношение:
Фильмы
(Идентификатор
фильма,
Наименование
фильма,
Продолжительность фильма, Режиссер фильма, Качество фильма; Актеры, занятые
в фильме; Год выхода фильма в прокат)
Аналогично формируются остальные отношения.
В итоге получаем следующую структуру записей:
R1 – Фильмы (Идентификатор фильма, Наименование фильма,
Продолжительность фильма, Режиссер фильма, Актеры, занятые в
фильме; Год выхода фильма в прокат)
R2
–
Многотомные
распределения
(Идентификатор
распределения, Номер тома)
R3 – Распределение фильмов (Идентификатор распределения,
Идентификатор фильма, Идентификатор носителя)
R4 – Носители (Идентификатор носителя, Метка носителя, Рента за
сутки, Время добавления информации о носителе, Идентификатор
типа носителя)
R5 – Испорченные носители (Идентификатор носителя, Дата
порчи-потери носителя)
R6 – Справочник типов носителей (Идентификатор типа
носителя, Тип носителя)
R7 – Клиенты (Идентификатор клиента, ФИО клиента, Адрес
электронной почты клиенты, Контактный телефон клиента)
R8 – Выдачи (Идентификатор выдачи, Идентификатор носителя,
Идентификатор клиента, Дата выдачи носителя клиенту)
R9 – Возвраты (Идентификатор выдачи, Дата возврата носителя)
16
Проверка выполнения свойства соединения без потерь
информации
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
R1 +(1) +(1) +(1) +(1) +(1)
18
19
20
21
22
+(1)
R2 +(11) +(11) +(11) +(11) +(11) +(9) +(12) +(12) +(14) +(12) +(13)
+(12) +(9)
+(1) +(1)
R3 +(2) +(2) +(2) +(2) +(2) +(1) +(3) +(3) +(5) +(3) +(4)
+(3) +(1)
+(1) +(10)
R4
+(1) +(1) +(1) +(5) +(1) +(4)
+(1)
R5
+(1) +(3) +(3) +(5) +(3) +(1)
+(3)
R6
+(1)
+(1)
R7
R8
R9
+(1) +(1) +(1)
+(1) +(3) +(3) +(5) +(3) +(4) +(1) +(8) +(6) +(6) +(6) +(3)
+(7) +(12) +(12) +(14) +(12) +(13) +(7) +(1) +(15) +(15) +(15) +(12)
+(1)
+(1) +(1)
+(7) +(1)
Шаг 1: Строится таблица, из 9 строк и 22 столбцов. На пересечении i-ой
строки и j-го столбца ставится «+(k)», где k – номер шага, если атрибут с
соответствующим номером принадлежит заданному отношению. Ключевые
атрибуты отношений выделены «фоном».
Шаг 2: Просматриваем список функциональных зависимостей.
Рассмотрим зависимость 18→1, а также и все остальные с определяющим
атрибутом 18 (18→2, 3, 4, 5). В строке, соответствующей R3, также присутствует
атрибут 18. Поэтому мы доставляем в этой строке «2» в те колонки, которые
соответствуют атрибутам из определяемой части зависимостей.
Шаг 3: Рассматриваем зависимости 6→7, 8, 10, 17
Шаг 4: Рассматриваем зависимости 6→11
Шаг 5: Рассматриваем зависимости 17→9
Шаг 6: Рассматриваем зависимости 19→14, 15, 16
Шаг 7: Рассматриваем зависимости 20→6, 12, 19
Шаг 8: Рассматриваем зависимости 20→13
Шаг 9: Рассматриваем зависимости 21→6,18
Шаг 10: Рассматриваем зависимости 21→22
Шаг 11: Рассматриваем зависимости 18→1, 2, 3, 4, 5
Шаг 12: Рассматриваем зависимости 6→7, 8, 10, 17
Шаг 13: Рассматриваем зависимости 6→11
Шаг 14: Рассматриваем зависимости 17→9
Шаг 15: Рассматриваем зависимости 19→14, 15, 16
Шаг 16: Рассматриваем зависимости 20→6, 12, 19
Шаг 17: Рассматриваем зависимости 20→13
Шаг 18: Рассматриваем зависимости 21→6,18
Шаг 19: Рассматриваем зависимости 21→22
Уже на 16-м шаге не происходит каких-либо изменений. В тоже время
строка, состоящая из ‘+’, не была получена, а это значит, что свойство соединения
без потерь информации не выполнено.
Составим обобщенный ключ: «Идентификатор фильма», «Идентификатор
распределения», «Идентификатор носителя», «Идентификатор типа носителя»,
«Идентификатор клиента», «Идентификатор выдачи» (18, 21, 6, 19, 20). Из
обобщенного ключа удалим те атрибуты, которые функционально выводятся из
17
остающихся, и получим следующее отношение: «Идентификатор распределения» и
«Идентификатор выдачи».
В этом отношении отметим неформальный признак многозначной
зависимости: добавление одной записи может потребовать добавления еще
нескольких записей (выдача клиенту носителя, на который записано несколько
фильмов, влечет за собой добавление в полученное отношение нескольких
записей, соответствующих данной выдаче и распределениям записанных на
выдаваемый носитель фильмов).
Чтобы решить проблему многозначной зависимости, вернем в обобщенный
ключ атрибут «Идентификатор носителя». Тогда в явном виде имеется
многозначная зависимость: «Идентификатор носителя» →→ «Идентификатор
выдачи» («Идентификатор распределения»).
Чтобы избавиться от многозначной зависимости, по правилу декомпозиции,
обобщенный ключ разбивается на отношения: («Идентификатор носителя»,
«Идентификатор выдачи») и
(«Идентификатор носителя», «Идентификатор
распределения»), естественное соединение, которых будет давать обобщенный
ключ. Оба этих отношения уже присутствуют в схеме базы данных в виде
отношений «Выдачи» и «Распределение фильмов»; то есть, добавления новых
отношений не требуется.
Полученная схема удовлетворяет свойству соединения без потерь
информации, при условии, что R3 ∞ R8 образует обобщенный ключ.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
R1
+(1) +(1) +(1) +(1) +(1)
R2
+(11) +(11) +(11) +(11) +(11) +(9) +(12) +(12) +(14) +(12) +(13)
+(12) +(9)
+(1) +(1)
R3
+(2) +(2) +(2) +(2) +(2) +(1) +(3) +(3) +(5) +(3) +(4)
+(3) +(1)
+(1) +(10)
R4
+(1) +(1) +(1) +(5) +(1) +(4)
+(1)
R5
+(1) +(3) +(3) +(5) +(3) +(1)
+(3)
R6
+(1)
+(1)
+(1)
R7
R8
R9
R3 ∞ R8
+(1) +(1) +(1)
+(2) +(2) +(2) +(2) +(2)
+(1)
+(1) +(3) +(3) +(5) +(3) +(4) +(1) +(8) +(6) +(6) +(6) +(3)
+(1) +(1)
+(7) +(12) +(12) +(14) +(12) +(13) +(7) +(1) +(15) +(15) +(15) +(12)
+(7) +(1)
+(1) +(3) +(3) +(5) +(3) +(4) +(1) +(8) +(6) +(6) +(6) +(3) +(1) +(1) +(1) +(1) +(10)
Как видно из таблицы, уже на 10-м шаге была получена строка, состоящая из
“+”. Таким образом, после добавления обобщенного ключа, наша схема обладает
свойством соединения без потерь информации.
Модификация структуры данных БД
Во время эксплуатации БД по каким-либо причинам может возникнуть
потребность в модификации существующей схемы данных базы.
При разработке БД “Видеопрокат” было сделано допущение, что фильм
имеет только одно название. Но уже при переводе с оригинального языка
зарубежный фильм получает русское название, под которым и происходит его
прокат. Клиент может искать нужный ему фильм именно по оригинальному
названию. И в данной реализации базы данных его поиск не увенчается успехом,
даже если кассета с фильмом будет стоять в хранилище на самом видном месте.
Лишение предприятия возможной прибыли от проката такой кассеты-невидимки
является достаточным стимулом для поиска решения.
Введем новые элементы данных «Другое название фильма» и
«Идентификатор другого названия фильма». Для них выпишем функциональные
зависимости
18
«Идентификатор другого названия фильма» → «Другое название фильма»;
«Идентификатор другого названия фильма» → «Идентификатор фильма».
После повторного выполнения шагов алгоритма построения канонической
модели получаем еще одно отношение в дополнение к уже известным:
R10 – Другие названия фильмов (Идентификатор другого
названия фильма, Другое название фильма, Идентификатор фильма)
Для новой схемы обобщенный ключ имеет вид: «Идентификатор другого
названия фильма», «Идентификатор распределения», «Идентификатор выдачи». В
нем, как и прежде, неявно присутствует многозначная зависимость, борьба с
которой рассмотрена выше. После некоторой практики не составляет труда
заметить еще одну, столь же неявную зависимость: «Идентификатор фильма» →→
«Идентификатор другого названия фильма» («Идентификатор распределения»).
Избавление от нее происходит теми же средствами. Получаем два отношения:
(«Идентификатор фильма», «Идентификатор другого названия фильма») и
(«Идентификатор фильма», «Идентификатор распределения», «Идентификатор
выдачи»). Первое отношение уже присутствует в схеме в виде отношения «Другие
названия фильмов». Второе отношение и его декомпозиция рассматривались выше.
Схема удовлетворяет свойству соединения без потерь информации.
Операции реляционной алгебры
Операндами реляционной алгебры являются отношения Ri, содержащие ki
столбцов и ni строк.
Базисный набор операций
1. Объединение. R = R1 R1. Ограничения: k1=k2 (формально) и заголовки
должны быть равны (содержательно). Результирующее отношение содержит
картежи обоих операндов, исключая дублирующие друг друга.
2. Вычитание. R = R1 \ R2. Ограничения: k1=k2 (формально) и заголовки
должны быть равны (содержательно). Из R1 удаляются картежи, встречающиеся в
R2.
3. Декартово произведение. R = R1 R2. Ограничений нет. Получаемое
отношение имеет все атрибуты своих операндов (при этом одноименные
заменяются на пары вида <Имя отношения>.<Имя атрибута>), и каждый картеж
первого отношения сопоставляется каждому картежу второго отношения.
Появление дублирующих картежей исключено – если их нет в исходных
отношениях.
4. Селекция. F(R), где F – логическое выражение, заданное на атрибутах из
R и имеет вид: <атрибут><значение>, где – операция из набора {<, ≤,=, ≠, ≥
,>}, связанных посредством операций (дизъюнкция), (конъюнкция),
(отрицание). Картеж из R попадает в результат, если при подстановке его
содержимого в F получается истинное выражение. Проекция – это вырезка из
таблицы по строкам, соответствующим логическому выражению F.
5. Проекция. X(R), где X – множество атрибутов, подмножество атрибутов
из R. Результатом является отношение, состоящее из атрибутов X, содержимым
которого будут соответствующие части картежей операнда с удаленными дублями.
Проекция – это вырезка из таблицы по столбцам.
19
Дополнительные операции
1. Пересечение. R1 R2 R1 \ R1 \ R2 .
2. Соединение. R1 F R2 F R1 R2 .
3. Эквисоединение. Соединение, только F содержит выражения со знаком
равенства.
4. Естественное соединение. Каждый картеж из R1 сопоставляется с каждым
картежом из R2, и если значения всех одноименных атрибутов совпадают, то
формируется новый картеж без дублирующихся атрибутов – он-то и помещается в
результат. Обозначается он R R1 R2 .
R1 R2 X Y R1 R2 ,
где X R1 R2 – объединенное множество атрибутов,
Y aZ R1.a R2 .a , Z R1 R2 – пересечение множества атрибутов.
Свойства операций
1. Коммутативность: R1 R2 R2 R1 , R1 R2 R2 R1 .
2. Ассоциативность:
R1 R2 R3 R1 R2 R3 , R1 R2 R3 R1 R2 R3 .
3. Операция проекции: X R1 R2 X R1 X R2 , где X i X Ri , i 1,2 ;
X R1 R2 X X R1 X R2 , где X i X Ri R1 R2 , i 1,2 .
4. Операция селекции:
F R1 R2 F R1 F R2 , F R1 R2 F R1 F R2 , где Fi содержит только
атрибуты из Ri и F F1 F2 .
1
1
1
2
2
2
1
2
Правила формальной оптимизации
1. Операция проекции должна выполняться раньше произведения или
соединения.
2. Операция селекции должна выполняться раньше произведения или
соединения.
3. Операции проекции и селекции должны выполняться совместно.
Проекция и селекция уменьшают объем результата, а произведения и
соединение – увеличивают.
Рекомендуемая литература
1. Гарсиа-Молина Гектор, Ульман Джеффри, Уидом Дженнифер. Системы баз
данных. Полный курс.: Пер с англ. – М.: Издательский дом «Вильямс», 2003. –
1088 с.
2. Дейт К. Дж. Введение в системы баз данных, 8-е издание: Пер. с англ. – СПб.:
Издательский дом «Вильямс», 2005. – 1328 с.
3. Коголовский М.Р. Энциклопедия технологий баз данных: Эволюция
технологий; Технологии и стандарты; Инфраструктура; Терминология – М.:
Финансы и статистика, 2002. – 800 с.
20
Методические рекомендации
по выполнению лабораторной работы № 2
В качестве CASE-средства при проектировании схемы базы данных
необходимо использовать Oracle Designer или CASE Studio.
При работе с Oracle Designer после запуска в диалоговом окне необходимо
ввести имя пользователя и пароль, далее выбрать свое приложение в списке.
Для выполнения задания необходимо знакомство со следующим набором
приложений из пакета Oracle Designer:
Entity Relationship Diagrammer – создание и редактирование ERдиаграммы;
Database Desing Transformer – трансформатор ER-диаграммы в
реляционную модель (Server Model)
Design Editor – просмотр и модификация реляционной модели (Server
Model)
Generate Database from Server Model – генерация файла с SQL инструкции
для создания физической модели данных
CASE Studio при работе с ER-диаграммами поддерживаtт стандарт IDEF1X.
При создании новой модели данных в CASE Studio следует задать, для какой СУБД
она проектируется, т.к. приложение имеет возможность построения полной
физической модели базы данных с использованием индивидуальных свойств
каждой БД: типы и свойства атрибутов (стандартные БД и пользователя),
возможности описания ключей (первичные и внешние), связей, условий
соблюдения ссылочной целостности, пользователей и их групп (ролей),
возможности написания хранимых процедур и пр. Для выполнения конверсии
физической модели для другой СУБД (опция Database Convertion) с сохранением в
виде копии. Для генерации файла со скриптом для создания физической модели
данных требуется воспользоваться опцией Generate script.
Таблица 1. Элементы ER-диаграммы в Oracle Designer
Сущности
Сущность
ЯЗЫК
# ИД
* Н АИ МЕН ОВАНИЕ
Сущность – супертип (Язык) с
подтипами (Русский, Иностранный)
ЯЗЫК
# ИД
* Н АИ МЕН ОВАНИЕ
РУССКИЙ
ИНОСТРАННЫЙ
Типы связей
связь (1,0):(N,1)
быть
быть
относиться к
яв ляться
яв ляться
связь (1,0):(N,0)
связь (1,1):(N,1)
состоять из
21
связь (1,1):(1,1)
относиться к
состоять из
связь (N,0):(N,0)
относиться к
состоять из
Обозначения для свойств атрибутов
#
*
O
Первичный ключ
Обязательный атрибут (NOT NULL)
Необязательный атрибут (NULL)
Таблица 2. Элементы ER-диаграммы в CASE Studio
Сущности
Сущность
Слабая сущность
Типы связей
Неидентифицирующая (0,N):(1,1)
Неидентифицирующая (1,N):(1,1)
Неидентифицирующая (1,1):(1,1)
Неидентифицирующая (0,1):(0,1)
Неспецифическая связь (N:N)
Идентифицирующая (1,1):(1,N)
Идентифицирующая (1,1):(0,N)
Обозначения для свойств атрибутов
(PK)
(FK)
Первичный ключ
Внешний ключ
Рекомендуемая литература
1. Коголовский М.Р. Энциклопедия технологий баз данных: Эволюция
технологий; Технологии и стандарты; Инфраструктура; Терминология – М.:
Финансы и статистика, 2002. – 800 с.
2. Кренке Д. Теория и практика построения баз данных, 9-е издание: Пер. с
англ. – СПб.: «Питер», 2005. – 864 с.
3. Питер Колетски, Д-р Поль Дорси. Oracle Desiner. Настольная книга
пользователя, 2-е издание – М.: Издательство «ЛОРИ», 1999. – 592 с.
22
4. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для
высших учебных заведений, 5-е издание – М.: Бином-Пресс; СПб.: КОРОНА
принт, 2006. – 736 с.
5. http://www.idefinfo.ru (описания стандартов проектирования)
6. http://www.intuit.ru/department/database/basedbw/3/3.html
(описание
CASEStudio).
7. http://www.interface.ru/oracle/des2000x.html (Описание Oracle Designer).
Методические рекомендации
по выполнению лабораторной работы № 3
Таблица 3. Инструкции языка SQL
Вид
Data Definition
Language (DDL)
Data Manipulation
Language (DML)
Инструкция
CREATE TABLE
DROP TABLE
ALTER TABLE
Назначение
Создание таблицы
Удаление таблицы
Изменение структуры
таблицы
Создание индекса
Удаление индекса
Создание представления
Удаление представления
Выборка записей
Изменение записей
Вставка записей
Удаление записей
CREATE INDEX
DROP INDEX
CREATE VIEW
DROP VIEW
SELECT
UPDATE
INSERT
DELETE
Таблица 4. Агрегирующие функции
Агрегирующая
функция
SUM([DISTINCT]
выражение)
Результат
Примечание
Сумма [различных]
значений
AVG([DISTINCT]
выражение)
Средняя величина
[различных] значений
COUNT([DISTINCT]
выражение)
COUNT(*)
MAX(выражение)
Количество [различных]
ненулевых значений
Количество выбранных
строк
Максимальное значение
только для числовых
выражений, NULL значения
игнорируются
только для числовых
выражений, NULL значения
игнорируются
для всех типов выражений,
NULL значения игнорируются
считают и NULL значения
MIN(выражение)
Минимальное значение
23
для всех типов выражений,
NULL значения игнорируются
для всех типов выражений,
NULL значения игнорируются
Рассмотрим на примерах использование основных SQL инструкций.
Пример 1.
Для добавления новой таблицы в базу данных, используется инструкция
CREATE TABLE.
CREATE TABLE films (
film_id INTEGER NOT NULL,
film_name VARCHAR(100) NOT NULL,
film_time time,
film_director VARCHAR(50) NOT NULL,
film_actors VARCHAR(255),
film_year INTEGER NOT NULL,
PRIMARY KEY (film_id))
Эта инструкция присваивает новой таблице имя FILMS и определяет для
каждого ее столбца имя и тип данных, хранимых в нем.
Пример 2.
Для изменения структуры уже определенных таблиц используется
инструкция ALTER TABLE.
ALTER TABLE film_distributions ADD FOREIGN KEY (film_id) REFERENCES
films(film_id) ON DELETE CASCADE
Пример 3.
Для удаления таблицы из базы данных используют инструкцию DROP
TABLE
DROP TABLE films
Пример 4.
Для выборки данных во всех SQL-запросах используется инструкция
SELECT.
SELECT * FROM films
WHERE films.film_year=1999
Результатом выборки будет список фильмов вышедших в 1999 году:
FILM_ID
5
FILM_NAME
Ghost Dog: The
Way of the
Samurai
FILM_TIME
116
FILM_DIRECTOR
Jim Jarmusch
13
Man on the moon
118
Milos Forman
FILM_ACTORS
Forest Whitaker,John
Tormey,Cliff Gorman,Henry
Silva,Isaach de
Bankole,Frank Minucci
Jim Carrey,Danny
DeVito,Courtney Love,Paul
Giamatti,Vincent Schiavelli
FILM_YEAR
1999
1999
Для построения выборки из нескольких таблиц используется два способа
соединения отношений:
1. Соединение по одноименным атрибутам с помощью условия WHERE;
2. Соединение двух таблиц с помощью внешнего соединения LEFT (RIGHT,
FULL) OUTER JOIN.
Рассмотрим и сравним следующие два запроса.
Пример 5.
SELECT clients.client_fio, rented_films.rent_start_date,
returned_rented_films.rent_end_date
24
FROM rented_films LEFT OUTER JOIN returned_rented_films ON
returned_rented_films.rent_id=rented_films.rent_id,
clients
WHERE clients.client_id=rented_films.client_id
CLIENT_FIO
RENT_START_DATE
RENT_END_DATE
Соколов Михаил Евгеньевич
28.06.2006
29.08.2006
Тимкина Наталья Дмитриевна
12.09.2006
13.09.2006
Колосов Антон Павлович
11.10.2005
13.10.2005
Соколов Михаил Евгеньевич
01.05.2006
02.05.2006
Гладкий Петр Сергеевич
05.06.2006
06.06.2006
Гладкий Петр Сергеевич
13.09.2006
NULL
SELECT clients.client_fio, rented_films.rent_start_date,
returned_rented_films.rent_end_date
FROM rented_films,
returned_rented_films,
clients
WHERE clients.client_id=rented_films.client_id AND
returned_rented_films.rent_id=rented_films.rent_id
CLIENT_FIO
RENT_START_DATE
RENT_END_DATE
Тимкина Наталья Дмитриевна
12.09.2006
13.09.2006
Соколов Михаил Евгеньевич
28.06.2006
29.08.2006
Соколов Михаил Евгеньевич
28.06.2006
29.08.2006
Соколов Михаил Евгеньевич
01.05.2006
02.05.2006
Гладкий Петр Сергеевич
05.06.2006
06.06.2006
Колосов Антон Павлович
11.10.2005
13.10.2005
Механизм работы этих двух способов соединения несколько различен. В
случае соединения через условие WHERE будет возвращено столько записей,
сколько имеют совпадения по одноименному связующему атрибуту. При
использовании OUTER JOIN количество записей в выборке будет равно
количеству записей в таблице слева от JOIN. Каждой записи таблицы слева будет
сопоставлена, согласно заданному условию, запись из таблицы справа, если же
соответствующей записи из правой таблицы нет, то будет сопоставлено NULLзначение.
Пример 6.
Нередко возникают ситуации, когда какой-либо запрос необходимо очень
часто выполнять. В этой случае можно создать представление данных, основанное
на данном запросе и в дальнейшем делать из него выборку как из обычной
таблицы. Создание представления данных осуществляется с помощью инструкции
CREATE VIEW.
Следующий пример создает представление данных client_list основанное на
предыдущем запросе.
CREATE VIEW client_list AS
SELECT clients.client_fio, rented_films.rent_start_date,
returned_rented_films.rent_end_date
FROM rented_films LEFT OUTER JOIN returned_rented_films ON
returned_rented_films.rent_id=rented_films.rent_id, clients
WHERE clients.client_id=rented_films.client_id
25
Пример 7.
Пример использования функций агрегирования (выборка с группировкой).
SELECT film_name,cnt_clients
FROM films,
(SELECT film_id, COUNT(DISTINCT client_id) AS cnt_clients
FROM rented_films GROUP BY film_id) cnt
WHERE films.film_id=cnt.film_id
ORDER BY film_name
В данном примере получим список фильмов с указанием их наименования и
количества клиентов, бравших каждый фильм. Если клиент брал один и тот же
фильм несколько раз, то при подсчете он будет считаться только 1 раз.
Пример 8.
Для добавления новой информации в базу данных в языке SQL используется
инструкция INSERT.
INSERT INTO medium_type_directory (medium_type) VALUES ('dvd')
В таблицу medium_type_directory добавлена новая запись.
Пример 9.
Инструкция DELETE удаляет какую-либо информацию из базы данных.
DELETE FROM clients WHERE client_id=15
В примере выполняется удаление записи о клиенте с client_id равным 15.
Пример 9.
Обновление уже существующей в базе данных информации выполняется,
используя инструкцию UPDATE.
UPDATE clients
SET client_phone_number=’795-55-78-48’
WHERE client_fio=’John N. Doe’
В данном примере у клиента John N. Doe будет изменен номер телефона.
Рекомендуемая литература
1. Боуман Джудит С., Дарновски Марси, Эмерсон Сандра Л. Практическое
руководство по SQL, 4-е издание: Пер. с англ. – М.: Издательский дом
«Вильямс», 2001. – 352 с.
2. Грофф Дж., Файнберг П. Энциклопедия SQL. 3-е издание: Пер. с англ. –
СПб.: Питер, 2003. — 896 с.
3. Кренке Д. Теория и практика построения баз данных, 9-е издание: Пер. с
англ. – СПб.: «Питер», 2005. – 864 с.
4. http://www.firststeps.ru/sql/oracle/oracle3.html (SQL, диалект Oracle)
5. http://www.sql-ex.ru (SQL, диалект Oracle)
6. http://megalib.com/items.php?idsubject=6 (Статьи по SQL)
26
Пример оформления лабораторной работы № 1
Вариант № ___. База данных ___________________
ФИО студента ______________________________, гр.__________
Описание предметной области
Пункт видеопроката осуществляет прокат записей фильмов на различных
типах носителей: видеокассеты VHS, диски VCD и DVD; важно отметить, что как
на одном носителе может находиться несколько фильмов (например, сборник
мультфильмов на видеокассете), так и один фильм может быть записан на
несколько отдельных носителей (одного типа). Клиентами являются физические
лица.
В системе целесообразно выделить несколько ролей, которые могут играть
пользователи.
Клиент. Клиентов интересует, какие фильмы доступны в пункте
видеопроката вообще, какие можно взять в данный момент.
Сотрудник видеопроката. Сотрудник видеопроката работает с
клиентами: выдает и принимает носители, а также записывает
информацию о новых клиентов.
Потребители информации
1) Работник проката.
2) Клиент проката.
Список атрибутов данных
Атрибуты:
1. Наименование фильма
2. Продолжительность фильма
3. Режиссер фильма
4. Актеры, занятые в фильме
5. Год выхода фильма в прокат
6. Идентификатор носителя
7. Метка носителя
8. Время добавления информации о носителе
9. Тип носителя
10. Рента за сутки
11. Дата порчи-потери носителя
12. Дата выдачи носителя клиенту
13. Дата возврата носителя
14. ФИО клиента
15. Адрес электронной почты клиента
16. Контактный телефон клиента
17. Идентификатор типа носителя
18. Идентификатор клиента
19. Идентификатор фильма
20. Идентификатор выдачи
27
21. Идентификатор распределения
22. Номер тома
Атрибуты, выделенные курсивом, добавлены в процессе проектирования.
Распределение атрибутов данных по группам пользователей
1) Работник проката: 1,2. 3, 4, 5, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16
2) Клиент проката: 1, 2, 3, 4, 5, 9, 10, 12, 13
Определение множества функциональных зависимостей
18→1;
18→2;
18→3;
18→4;
18→5;
20→6;
21→6;
6→7;
6→8;
17→9;
6→10;
6→11 (см. Замечание 1);
20→12;
20→13;
19→14;
19→15;
19→16;
6→17;
21→18;
20→19;
21→22 (см. Замечание 2).
Построение канонической модели данных
Исходное множество функциональных зависимостей не избыточно.
Переписываем множество функциональных зависимостей в
приемлемой для построения логических записей:
18→1, 2, 3, 4, 5;
6→7, 8, 10, 17;
6→11;
17→9;
19→14, 15, 16;
20→6, 12, 19;
20→ 13;
21→6,18;
21→ 22.
форме,
Сформируем логические записи (подчеркнуты ключевые элементы
данных):
28
1) R1 – Фильмы (Идентификатор фильма(18), Наименование фильма(1),
Продолжительность фильма(2), Режиссер фильма(3), Актеры, занятые в
фильме(4); Год выхода фильма в прокат(5))
2) R2 – Многотомные распределения (Идентификатор распределения(21),
Номер тома(22))
3) R3 – Распределение фильмов (Идентификатор распределения(21),
Идентификатор фильма(18), Идентификатор носителя(6))
4) R4 – Носители (Идентификатор носителя(6), Метка носителя(7), Рента за
сутки(10), Время добавления информации о носителе(8), Идентификатор типа
носителя(17))
5) R5 – Испорченные носители (Идентификатор носителя(6), Дата порчипотери носителя(11))
6) R6 – Справочник типов носителей (Идентификатор типа носителя(17), Тип
носителя(9))
7) R7 – Клиенты (Идентификатор клиента(19), ФИО клиента(14), Адрес
электронной почты клиенты(15), Контактный телефон клиента(16))
8) R8 – Выдачи (Идентификатор выдачи(20), Идентификатор носителя(6),
Идентификатор клиента(19), Дата выдачи носителя клиенту(12))
9) R9 – Возвраты (Идентификатор выдачи(20), Дата возврата носителя(13))
В результате проверки свойства соединения без потерь информации
получаем следующую итоговую таблицу.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
R1 +(1) +(1) +(1) +(1) +(1)
18
19
20
21
22
+(1)
R2 +(11) +(11) +(11) +(11) +(11) +(9) +(12) +(12) +(14) +(12) +(13)
+(12) +(9)
+(1) +(1)
R3 +(2) +(2) +(2) +(2) +(2) +(1) +(3) +(3) +(5) +(3) +(4)
+(3) +(1)
+(1) +(10)
R4
+(1) +(1) +(1) +(5) +(1) +(4)
+(1)
R5
+(1) +(3) +(3) +(5) +(3) +(1)
+(3)
R6
+(1)
+(1)
R7
+(1) +(1) +(1)
R8
R9
+(1)
+(1) +(3) +(3) +(5) +(3) +(4) +(1) +(8) +(6) +(6) +(6) +(3)
+(7) +(12) +(12) +(14) +(12) +(13) +(7) +(1) +(15) +(15) +(15) +(12)
+(1) +(1)
+(7) +(1)
Как мы видим строки, состоящей из всех “+” данная таблица не содержит, и
возможные итерации уже исчерпаны, это значит, что соединения без потерь
информации нет.
После добавления обобщенного ключа
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
R1
+(1) +(1) +(1) +(1) +(1)
R2
+(11) +(11) +(11) +(11) +(11) +(9) +(12) +(12) +(14) +(12) +(13)
+(12) +(9)
+(1) +(1)
R3
+(2) +(2) +(2) +(2) +(2) +(1) +(3) +(3) +(5) +(3) +(4)
+(3) +(1)
+(1) +(10)
R4
+(1) +(1) +(1) +(5) +(1) +(4)
+(1)
R5
+(1) +(3) +(3) +(5) +(3) +(1)
+(3)
R6
+(1)
+(1)
+(1)
R7
R8
R9
R3 ∞ R8
+(1) +(1) +(1)
+(2) +(2) +(2) +(2) +(2)
+(1)
+(1) +(3) +(3) +(5) +(3) +(4) +(1) +(8) +(6) +(6) +(6) +(3)
+(1) +(1)
+(7) +(12) +(12) +(14) +(12) +(13) +(7) +(1) +(15) +(15) +(15) +(12)
+(7) +(1)
+(1) +(3) +(3) +(5) +(3) +(4) +(1) +(8) +(6) +(6) +(6) +(3) +(1) +(1) +(1) +(1) +(10)
29
Запросы в терминах реляционной алгебры
1. Выдать список фильмов и носителей, ни разу не выдававшихся в прокат.
Оптимизированный запрос в терминах реляционной алгебры:
[1],[ 7 ]
[ 6]
R4 \ [6] R8 [6],[18] R3 [18],[1] R1 [6],[7] R4
2. Для заданного клиента (Z) выдать список фильмов и носителей, которые он
брал за период с X по Y. Оптимизированный запрос в терминах реляционной
алгебры:
[1],[ 7 ]
( [19] ( [14] Z ( R7)) [ 6],[19] ( [12] X [12]Y ( R8)) [ 6],[18] ( R3) [18],[1] ( R1) [ 6],[ 7 ] ( R4))
Литература
1. Боуман Джудит С., Дарновски Марси, Эмерсон Сандра Л. Практическое
руководство по SQL, 4-е издание: Пер. с англ. – М.: Издательский дом
«Вильямс», 2001. – 352 с.
2. Гарсиа-Молина Гектор, Ульман Джеффри, Уидом Дженнифер. Системы баз
данных. Полный курс.: Пер с англ. – М.: Издательский дом «Вильямс», 2003.
– 1088 с.
3. Грофф Дж., Файнберг П. Энциклопедия SQL. 3-е издание: Пер. с англ. –
СПб.: Питер, 2003. — 896 с.
4. Дейт К. Дж. Введение в системы баз данных, 8-е издание: Пер. с англ. –
СПб.: Издательский дом «Вильямс», 2005. – 1328 с.
5. Коголовский М.Р. Энциклопедия технологий баз данных: Эволюция
технологий; Технологии и стандарты; Инфраструктура; Терминология – М.:
Финансы и статистика, 2002. – 800 с.
6. Кренке Д. Теория и практика построения баз данных, 9-е издание: Пер. с
англ. – СПб.: «Питер», 2005. – 864 с.
7. Райордан Р. Основы реляционных баз данных: Пер. с англ. – М.:
Издательско-торговый дом "Русская редакция", 2001.
8. Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для
высших учебных заведений, 5-е издание – М.: Бином-Пресс; СПб.: КОРОНА
принт, 2006. – 736 с.
1.
2.
3.
4.
5.
6.
Электронные ресурсы
http://www.osp.ru
http://www.citforum.ru/database
http://intuit.ru
http://www.oracle.com
http://www.sql.ru
http://megalib.com, раздел «Базы данных»
30
П.С. Гладкий, Е.А. Костюшина, М.Е. Соколов
ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ
Методические указания
к выполнению лабораторных работ
Подписано в печать
.
Формат 60 х 84 1/16. Печ.л. 3,1. Уч.-изд.л.3,2.
Тираж 30 экз.
Полиграфический центр КАН
644050, г. Омск, пр. Мира 32, ком.11, тел. (381-2) 65-47-31
Лицензия ПЛД № 58-47 от 21.04.97 г.
31