Пример описания предметной области
Рассмотрим пример базы данных «Видеопрокат».
Пункт видеопроката осуществляет прокат записей фильмов на различных типах носителей: видеокассеты 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)
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 содержит справочную информацию для клиента и не будет постоянно использоваться в запросах как критерий отбора записей.
Данный список не обязательно является полным. После некоторой практики проектировщик может сразу составить практически полный список атрибутов.
|
|
|
Определение множества функциональных зависимостей
Определим функциональные зависимости в прикладной области.
Рассмотрим атрибуты, характеризующие фильм.
Наименование фильма пока никаким атрибутом однозначно не определяется. Такую ситуацию мы будем условно обозначать следующим образом: 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 требует поддержки данного типа со стороны СУБД, а также, например, учета правил непривычной трехзначной логики при построении запросов.
Замечание1. Если предполагается, что неопределенные значения будут встречаться относительно редко (например, для документальных фильмов нельзя указать список актеров), то использование NULL-значений оправдано. В обратной ситуации, когда большинство записей будут содержать именно NULL-значение (именно дата порчи/потери носителя), целесообразно использовать понятие области определения функциональной зависимости.
Рассмотрим остальные зависимости.
«Идентификатор типа носителя» → «Тип носителя» (17→9)
Для этой зависимости и вводился атрибут «Идентификатор типа носителя».
«Идентификатор клиента» → «ФИО клиента» (19→14)
«Идентификатор клиента» → «Адрес электронной почты клиента» (19→15)
«Идентификатор клиента» → «Контактный телефон клиента» (19→16)
Объект выдача носителя клиенту характеризуется всеми своими атрибутами: носителем, клиентом, датой выдачи. По вышеописанным причинам необходимо ввести еще один атрибут для внутреннего пользования: №20 «ИДЕНТИФИКАТОР ВЫДАЧИ».
«Идентификатор выдачи» → «Идентификатор носителя» (20→6)
«Идентификатор выдачи» → «Идентификатор клиента» (20→19)
«Идентификатор выдачи» → «Дата выдачи носителя клиенту» (20→12)
«Идентификатор выдачи» → «Дата возврата носителя» (20→13)
Поскольку носитель каждый конкретный раз выдается только одному клиенту, это необходимо отразить в функциональных зависимостях:
«Идентификатор выдачи» → «ФИО Клиента», «Адрес электронной почты клиента», «Контактный телефон клиента»
Выше, при неформальном описании области отмечалась несколько нетривиальная связь фильма и носителя. Например, нельзя выделить зависимости «Идентификатор фильма» → «Идентификатор носителя» (18→6) и «Идентификатор носителя» → «Идентификатор фильма» (6→18): один фильм может располагаться на нескольких носителях, равно как и на одном носителе может быть несколько фильмов. Поэтому имеет место некоторое распределение фильмов по носителям.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
ПРИЛОЖЕНИЕ А
Темы курсовых работ
1. Реализация симплекс-метода в случае положительных свободных членов
2. Реализация симплекс-метода в случае отрицательных свободных членов
3. Реализация симплекс-метода в случае произвольных свободных членов
4. Реализация модифицированного симплекс-метода
5. Двойственные задачи
6. Методы решения транспортной задачи (метод потенциалов)
7. Методы и модели нелинейного программирования
8. Нахождение максимального потока в графе
9. Характеристики сетевого графика
10. Решение задачи о коммивояжере
11. Сетевое планирование
12. Задача о назначениях
13. Методы и модели динамического программирования
14. Многокритериальная оптимизация
15. Системы массового обслуживания
16. Методы прогнозирования
17. Применение корреляционного анализа
18. Реализация метода наименьших квадратов
19. Методы и модели управления запасами
20. Задачи в условиях определенности
21. Задачи в условиях неопределенности
22. Метод статистических испытаний (Метод Монте - Карло)
23. Решение матричных игр
24. Игры и стратегии
25. Примеры конечных игр. Принцип минимакса
26. Задачи в условиях вероятностной определенности
27. Решение игры в смешанных стратегиях
28. Модели прогнозирования временных рядов
ПРИЛОЖЕНИЕ Б
Дата добавления: 2018-05-13; просмотров: 581; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!