Учебное пособие по базам данных. Учебное пособие. Пособие по базам данных Введение
 Скачать 169.5 Kb.
|
|
111(15,16,17) или 115,16,17(11) В данном случае элемент данных в левой части зависимости находится в обобщенном ключе, что необязательно для других прикладных областей. Отношение, соответствующее обобщенному ключу, декомпозируем на два отношения:
R9=Регистрация проданных билетов
После этой операции заметим, что первое отношение является частью отношения R3, а новое отношение R9 является не только интерпретируемым, но и технологичным (заполняется электронным кассовым аппаратом при продаже билетов на матч). Установим связи между сформированными отношениями. Обозначим связь типа 1:1 символом , а связь 1:М символом : R1R3 R2R1 -R2R3 -R2R4 R2R5 R4R3 R5R4 R6R1 -R6R3 R6R9 R7R6 R8R3 Анализируя связи на схеме, получаем, что связи R2R3 и R6R3 являются избыточными и подлежат удалению. Проблематичной для удаления является связь R2R4 из-за того, что одна из заменяющих ее связей: R2R5 и R5R4., а именно R2R5, имеет область определения "Для всех членов команды". Тогда как удаляемая связь имеет область определения только "Для игроков команды". Однако вторая связь: R5R4, также имеет область определения только "Для игроков команды". Следовательно, удаление связи R2R4 не нарушит ссылочной целостности на данные. Результирующая схема БД имеет следующее графическое представление:  Этап 4. В соответствии с заданием сформулируем и формализуем три запроса. А) Запрос с обобщенным ключом. Обобщенный ключ содержится в отношениях R3 и R9. Поскольку отношение R9 не имеет содержательных атрибутов (а таковым, например, мог быть атрибут "Цена билета"), то запрос будет носить формальный характер: «Получить перечень всех номеров зрительских мест на трибуне с номером "6" в матчах в городе "Омск", зрители на которых были свидетелями игрового события "Вне_игры" в период 20.07.2007 по 20.09.2007». Исходный запрос: <16>,<17>(<15>=6,<10>="Омск",<14>="Вне_игры",<19>20.07.2007,<19>20.09.2007(R3⋈ ⋈R6⋈R7⋈R8⋈R9)). Оптимизированный запрос: <16>,<17>(<18>(<14>="Вне_игры"(R8))⋈<8>(<10>="Омск"(R7))⋈ ⋈<1><8>(<19>20.07.2007,<19>20.09.2007(R6))⋈ ⋈<1><18>(R3)⋈<1><16><17>(<15>=6(R9))). Последовательность итерирования отношений R8, R7, R6, R3, R9 гарантирует, что в системном буфере будет присутствовать минимальное количество данных. Б) Запрос без обобщенного ключа. Получить список игроков команды «Иртыш», забивших голы. Исходный запрос: <13>(<4>="Иртыш",<14>="Гол"(R2⋈R3⋈R4⋈R5⋈R8)). Поскольку отношения в запросе не содержит обобщенного ключа, то проверяем выполнение свойства соединения без потери информации для заданной совокупности отношений. Замыкание множества атрибутов, соответствующих ключу отношения R3, на множестве сохраненных зависимостей в отношениях запроса содержит все атрибуты из этих отношений, поэтому искомое свойство для выбранной совокупности отношений будет выполнено. В общем случае, когда ключ не содержится в одном отношении, проверку свойства необходимо осуществлять по алгоритму. Заметим, что аналогичное свойство должно быть выполнено для отношений первого запроса. Однако, наличие в нем обобщенного ключа (суперключа) существенно упрощает проверку этого свойства. Достаточно построить замыкание этого ключа на множестве сохраненных в декомпозиции зависимостей. Оптимизированный запрос: <13>(<18>(<14>="Гол"(R8))⋈<2>(<4>="Иртыш"(R2))⋈ ⋈<2><6><13>(R5)⋈R4⋈<2><5><18>(R3)). В) Запрос на вычитание. Этот класс запросов предназначен для получения информации о событиях, которые могли произойти, но не произошли (не зафиксированы в базе данных). Получить ФИО члена команды и название команды для нападающих, которые ни разу не забили гол. Исходный запрос: <13><4>(<7>="Нападающий"(R2⋈R5)) / /<13><4>(<7>=" Нападающий ",<14>="Гол"(R2⋈R3⋈R4⋈R5⋈R8)). Оптимизированный запрос: <13><4>(<2><7><13>(<7>="Нападающий"(R5))⋈<2><4>(R2))/ /<13><4>(<2><7><13>(<7>="Нападающий"(R5))⋈<2><4>(R2)⋈ ⋈R4⋈<2><5><18>(R3)⋈<18>(<14>="Гол"(R8))). Этап 5. Выбор способа физического представления данных. Для ускорения поиска данных в нескольких таблицах одновременно довольно часто используется прием денормализации отношений. То есть, на логическом уровне (на схеме) объединяются отношения, сопоставимые по размерам и часто используемые совместно в запросах. Большинство СУБД не имеют возможности сформировать физическое представление данных, отличное от логического описания (схемы базы данных). Другими словами, состав полей физических записей должен соответствовать составу элементов данных логических записей. В этом случае денормализация отношений имеет довольно слабое оправдание. Однако, данную проблему нужно решать за счет использования СУБД, позволяющих реализовать совместное хранение отношений. Примером такой СУБД является ORACLE, которая позволяет организовать совместное хранение отношений в виде кластера. Ограничением на кластер является один набор элементов данных (ключей кластера), по которому организуется совместное хранение. В нашем случае потребуется другая возможность СУБД: раздельное хранение отношений на различных серверах (см. этап 6). Введем обозначения для типов данных: sN – символьная константа длины N; inN – целая константа длины N байтов; d – агрегат данных "дата" (день.месяц.год); t – агрегат данных "время" (час:минута:секунда); fn.m – финансовая константа, где n – количество разрядов для указания цены в рублях, m – добавочные разряды для копеек. Пусть k(tp) – элемент данных с номером k и типом tp. Физические записи, с учетом высказанных замечаний и введенных обозначений, могут иметь следующий вид: 1. Статус_команды (реализация R1): 1(in2), 2(in1), 3(s6); 2. Команды (реализация R2): 2(in1), 4(s15); 3. Игровые_события (реализация R3): 1(in2), 11(in2), 2(in1), 5(in1), 12(t), 18(in1); 4. Игровые_номера (реализация R4): 2(in1), 5(in1), 6(in1); 5. Составы_команд (реализация R5): 2(in1), 6(in1), 7(s12), 13(s20); 6. Расписание (реализация R6): 1(in1), 8(in1), 19(d), 20(t); 7. Стадионы (реализация R7): 8(in1), 9(s15), 10(s15); 8. Справочник_событий (реализация R8): 18(in1), 14(s15); 9. Продажа_билетов (реализация R9): 1(in2), 15(in1), 16(in1), 17(in1); В соответствии с установленными типами данных, частотой обновления данных в файлах, частотой поиска данных в файлах по соответствующим полям и т.д., выберем способы индексации основных файлов БД. R1 – инвертированный (по атрибутам 1 и 2), R2 – индексно-последовательный (по атрибуту 2), R3 – инвертированный (по атрибутам 1, 2, 5, 11 и 18), R4 – инвертированный (по атрибутам 2, 5 и 6), R5 – инвертированный (по атрибутам 2 и 6), R6 – инвертированный (по атрибутам 1 и 8), R7 – индексно-последовательный (по атрибуту 8), R8 – индексно-последовательный (по атрибуту 18), R9 – B-дерево (по атрибуту 1), Наиболее затратной по памяти является индексация файлов R3 и R4. Однако эти отношения чаще всего будут встречаться в запросах, требующих соединения по одноименным атрибутам. Причем, ограничения селекции будут задаваться на атрибуты других отношений, следовательно, эти отношения будут итерироваться раньше, и при выполнении естественного соединения с R3 и R4 их индексы будут активно использоваться. Альтернативой этих индексов могут быть два индекса соединения 1) для отношений R1 и R3 по атрибутам 1 и 2, и 2) для отношений R3 и R4 по атрибутам 2 и 5. Возможно будет полезен индекс соединения отношений R1, R2 и R5 по атрибуту 2. Этап 6. Анализ особенностей реализации информационной системы. Данные по всем матчам чемпионата должны храниться на центральном сервере комитета по организации чемпионата, кроме данных из отношения R9. Вместо него в отношение R6 дополняется атрибут «Количество проданных билетов». Отношения R1, R2, R5, R6, R7, и R8 заполняются на сервере перед началом проведения чемпионата. Отношение R4 пополняется перед матчем по заявке от команды, с возможными изменениями в отношении R5. Отношение R3 пополняется в течение проведения матча в оперативном режиме. Отношение R9 пополняется кассовыми аппаратами перед проведением матча. Перед проведением матча оператор из судейской бригады формирует на своей рабочей станции пустую базу данных, и закачивает в нее с сервера отношение R8 и сведения из отношений R1, R2, R5, R6, и R7, относящиеся к текущему матчу. В течение матча оператором в отношении R3 регистрируются игровые события. При дополнении записи, соответствующей событию «гол», должен быть запущен триггер, пересчитывающий результаты матча и выводящий эти результаты на табло стадиона. Комментаторы матча могут быть снабжены рабочими станциями с установленными на них сервисами для сбора статистики. Из сказанного следует, что на период проведения матча должна быть установлена непрерывная связь (выделенная линия) между рабочими станциями на стадионе и центральным сервером комитета по организации чемпионата. Перечень типовых заданий 1. Прикладная область: "Абитуриент". Документы: "Карточка абитуриента", "Расписание вступительных экзаменов", "Экзаменационная ведомость". Вариант 1.1. Абитуриент может поступать на одну специальность (фиксированное расписание экзаменов для потоков). Вариант 1.2. Абитуриент может поступать на несколько специальностей одновременно (индивидуальный график сдачи экзаменов для каждого абитуриента). 2. Прикладная область: "Факультет". Документы: "Расписание занятий", "Экзаменационная ведомость", "Приказы по деканату". 3. Прикладная область: "Продовольственный магазин". Документы: "Чек", "Электронная регистрация упаковки товаров", "Накладная на поставку товаров". 4. Прикладная область: "Мастерская по ремонту бытовой техники". Документы: "Заявка на ремонт оборудования", "Заявка от мастера на склад", "Накладная на поставку запчастей". Замечание: при поступлении запчастей на склад им присваиваются инвентарные номера. Для крупных изделий индивидуальные номера, для мелких – номера на коробки. Со склада мелкие детали выдаются коробками. 5. Прикладная область: "Домоуправление". Документы: "Реестр жильцов", "Заявка на проведение ремонта в квартире", "Табель сотрудников домоуправления". 6. Прикладная область: "Общественный транспорт". Документы: "Расписание движения транспорта", "Электронная регистрация транспорта на остановках", "Табель сотрудников предприятия". Замечание: обязательно присутствие двух атрибутов – "Плановое время прибытия на остановку" и "Фактическое время прибытия на остановку" 7. Прикладная область: "Библиотека". Документы: "Каталог непериодических изданий", "Регистрация выданных книг", "Табель сотрудников библиотеки". Замечания: 1) в библиотеке могут быть несколько экземпляров одной и той же книги, различающиеся только инвентарными номерами; 2) у одной книги может быть несколько авторов и у одного автора несколько книг. 8. Прикладная область: "Общественное питание". Документы: "Чек", "Меню", "Заявка от бригады поваров на склад", "Накладная на поставку товаров". Замечание: по заявке на склад отдельно фиксируется выдача одинаковых продуктов, поступивших по различным накладным. 9. Прикладная область: "Обслуживание пассажиров на ж./д. вокзале". Документы: "Билет пассажира", "Бирка на багаж", "Расписание движения поездов". Рекомендуется ввести понятие подмаршрута и установить отношения между подмаршрутами. 10. Прикладная область: "Школа". Документы: "Расписание занятий", "Классный журнал", "Сведения об опекунах". Замечание: у одного опекуна может быть несколько учеников и у одного ученика может быть несколько опекунов. Рекомендуется ввести атрибут "Отношение родства", принимающий значения: отец, мать, бабушка и т.д. 11. Прикладная область: "Автостоянка". Документы: "Договор с клиентом", "Квитанция об оплате услуги автостоянки", "Электронная регистрация на въезде по госномеру автомобиля". Замечание: договор составляется на определенный период и, возможно, на несколько автомобилей, оплата услуг по договору может осуществляться частями. 12. Прикладная область: "Служба занятости". Документы: "Журнал регистрации безработных", "Заявка от предприятия", "Договор на переобучение группы безработных", "Резюме начальника отдела кадров принимающего предприятия". 13. Прикладная область: "Овощная база". Документы: "Накладная на поставку овощей на базу", "Накладная на отгрузку овощей в магазин", "Путевой лист автотранспорта". Замечание: при поступлении овощи загружаются в специальные ящики, причем, овощи от разных поставщиков в один ящик не загружаются. 14. Прикладная область: "Дом отдыха". Документы: "Выделение путевок домом отдыха на сезон", "Путевка", "Регистрация отдыхающих при заезде", "График мероприятий в ДО". Замечание: рекомендуется использовать атрибут "Отметка об участии в мероприятии". 15. Прикладная область: "Товарная станция". Документы: "Квитанция об приеме товара на отправку", "Опись товаров в контейнере", "Путевой лист на доставку товаров автотранспортом предприятия", "Накладная на доставку товара". 16. Прикладная область: "Поликлиника". Документы: "Карточка пациента", "Расписание работы врачей", "Талон на посещение врача". Замечание: В карточке больного фиксируется диагноз, принимаемые препараты и результат лечения. 17. Прикладная область: "Кинотеатр". Документы: "Регистрация предварительной продажи билетов", "Билет", "Расписание сеансов", "Накладная на поставку партии фильмов". Библиографический список 1. Ульман Дж. Основы систем баз данных. М.: Финансы и статистика, 1983. 334 с. 2. Мейер Д. Теория реляционных баз данных. М.: Мир, 1987. 608 с. 3. Вейнеров О.М., Самохвалов Э.Н. Разработка САПР: В 10 кн. Кн. 4. Проектирование баз данных САПР. М.: Высш. шк., 1990. 144 с. 4. Дейт К. Введение в системы баз данных. М.: Диалектика, 1998. 782 с. 5. Тиори Т., Фрай Дж. Проектирование структур баз данных. М.: Мир, 1985. Т 2. 320 с. 6. Кузнецов С.Д. Основы баз данных. М.: Интуит.ру, 2005. 488 с. |