проектирование БД. Методичка Пример проектирования модели и нормализации. Пример проектирования модели и проведения нормализации
 Скачать 483 Kb.
|
Пример проектирования модели и проведения нормализацииВыявление существенных объектовПытаемся определить сущности и их атрибутный состав на интуитивном уровне, т.е. определяем, какими типами данных характеризуется наш объект исследований (предметная область). В качестве предметной области будем рассматривать сферу воздушных перевозок.  Итак, данные об авиарейсах будут сосредоточенны в сущности РЕЙС, на первом этапе эта сущность будет содержать все данные ассоциирующиеся с понятием рейс.Рисунок 1Сущность Рейс – ненормализованная модель (результат предварительного анализа) Предварительное действиеУбедимся в том, что все сущности имеют уникальные идентификаторы в виде комбинации атрибутов. В нашем случае рейс будет однозначно определяться номером рейса, датой и временем вылета.  Рисунок 2 Сущность Рейс с выделенным первичным ключом. Первая форма нормализацииПервая нормальная форма требует, чтобы на любом пересечении строки и столбца находилось единственное значение, которое должно быть атомарным, то есть оно не может быть разбито на составляющие. Кроме того, в таблице, удовлетворяющей первой нормальной форме, не должно быть повторяющихся групп, а также пустых первичных ключей. Проанализируем имеющееся атрибуты с точки зрения атомарности, отметим что поля Член экипажа N по своему смыслу могут быть заполнены примерно следующими данными
Таким образом, каждое из полей содержит информацию из двух составляющих ФИО члена экипажа и Роль члена экипажа (Командир, Штурман, Бортпроводник и т.д.) Следующим шагом отмечаем, что информация для каждого члена экипажа является повторяющейся группой, заметим, что предлагаемый способ представления рейса не позволяет представить информацию о рейсе более чем с тремя членами экипажа. Удаляем повторяющиеся атрибуты или группы атрибутов. Нам нужно убрать, например, группы атрибутов для членов экипажа с номерами 1,2,3. Это приведет к созданию новой сущности ЧЛЕН ЭКИПАЖА, имеющей атрибуты «ФИО» и «Роль» и связь типа «многие к одному» с исходной сущностью РЕЙС (иначе говоря, в одном рейсе много членов экипажа). Введем для члена экипажа уникальный идентификатор – суррогатный ключ «Код Члена экипажа».  Рисунок 3 Первая нормальная форма Вторая нормальная форма.Второе правило нормализации требует, чтобы любой неключевой столбец зависел от всего первичного ключа. Следовательно, представление таблицы во второй нормальной форме требует, чтобы все столбцы, не являющиеся первичными ключами (столбцы, описывающие объект, но однозначно не идентифицирующие его), зависели от всего первичного ключа, а не от его отдельных компонентов. Если сущность имеет уникальный идентификатор, состоящий из нескольких атрибутов и/или связей, и если значение какого-нибудь атрибута (не входящего в него) зависит только от какой-то части идентификатора (но не от всего идентификатора целиком), тогда этот атрибут и эта часть (от которой он зависит) должны составить основу новой сущности. Новая сущность идентифицируется перешедшим к ней фрагментом уникального идентификатора исходной сущности и имеет связь с ней типа «один ко многим». Так, например, значение атрибута Название авиалинии зависит от атрибута Номер рейса» и не зависит от даты и времени вылета. Мы получим сущность АВИАМАРШРУТ с фиксированным номером рейса, которому соответствуют один или несколько РЕЙСОВ, совершенных за период времени. Третья нормальная форма требует, чтобы ни один неключевой столбец не зависел от другого неключевого столбца. Любой неключевой столбец должен зависеть только от столбца первичного ключа. Другими словами, любой неключевой столбец зависит только от всего ключа и больше ни от чего, кроме ключа. Если значение принадлежащего сущности атрибута зависит от другого атрибута, не входящего в уникальный идентификатор, эти атрибуты должны составить основу для новой сущности, которая будет связана с исходной сущностью отношением типа «один ко многим». Уникальным идентификатором для новой сущности будет атрибут, определяющий значение другого атрибута. Так, например количество мест в самолете не зависит от номера рейса, выполняемого по АВИА-МАРШРУТУ, но зависит от типа самолета, т.е. необходимо выделить новую сущность ТИП САМОЛЕТА Если вы посмотрите на получившуюся модель внимательно, вы обнаружите то, что выделены сущности для действительно важных понятий РЕЙС, АВИА-МАРШРУТ, ТИП САМОЛЕТА. Продолжим выделение отдельных сущностей. Так глядя на сущность ЧЛЕН ЭКИПАЖА видим, что из атрибута ФИО должна появится новая сущность ЛИЧНОСТЬ. Этот позволит одному и тому же человеку быть назначенным на разные Рейсы. Кроме этого это нам в дальнейшем пригодится (с точки зрения гибкости), когда между ЛИЧНОСТЬЮ и РЕЙСОМ мы будем добавлять роль «пассажир», позволяющую членам экипажа быть пассажирами на других рейсах. Роль члена экипажа на самом деле является «типом роли» с небольшим набором заранее определенных значений (например, командир, штурман), она будет выделена в новую сущность с именем РОЛЬ ЧЛЕНА ЭКИПАЖА. Из атрибута «название аэропорта вылета» должна быть создана независимая сущность АЭРОПОРТ, т.к. аэропорты существуют сами по себе независимо от АВИА-МАРШРУТА. На диаграмме связи между АЭРОПОРТОМ и АВИАМАРШРУТОМ будет присвоена роль с именем «Аэропорт вылета». Также отметим, что в окончательном виде «номер рейса» следует переименовать в «номер маршрута». Проблема терминологии является обычной для большинства сфер деятельности – в воздушных перевозках слово «рейс» используется для обозначения и «маршрута», зачастую в одном и том же предложении  Рисунок 6 Окончательно нормализованная модель Уточнение моделиПроанализируем, каким образом мы можем отобразить то, какие аэропорты соединяет каждый из маршрутов. На данный момент в модели отображается только аэропорт вылета. Исходя из смысла АВИАМАРШРУТА, необходимо отображать все аэропорты, через которые этот маршрут проходит. Так как один АВИАМАРШРУТ может соединять несколько АЭРОПОРТОВ и через каждый АЭРОПОРТ может проходить несколько АВИАМАРШРУТОВ, необходимо создать промежуточную сущность, в этой сущности должны быть определены атрибуты: каким по счету будет аэропорт в авиамаршруте, время прилета и вылета. Среди всех аэропортов входящих в авиамаршрут первым будет тот, где время прилета будет пустым (кроме этого первый аэропорт в маршруте легко распознать т.к. «Номер в Маршруте» будет равен 1), а последним, соответственно, тот, где время вылета пусто. Созданную сущность можно рассматривать как РАСПИСАНИЕ (каждая запись будет соответствовать одной строке расписания). После появления Сущности РАСПИСАНИЕ атрибут «Время вылета» в сущности РЕЙС следует убрать, т.к. он полностью заменяется таким же атрибутом расписании. Заметим, что нам нужно знать не только аэропорт, но и город, которому этот аэропорт принадлежит, таким образом, вводим сущность ГОРОД.  Рисунок 7 Результат ввода сущности Расписание Обратим внимание на сущность ТИП САМОЛЕТА. Пассажиры приобретают билеты не просто на самолет, а в салон определенного типа (бизнес класс, эконом класс и т.д.), заметим, что нужно знать не общее количество мест во всем самолете, а количество мест в каждом из салонов. Таким образом, появляются сущность ТИП САЛОНА, и САЛОН В САМОЛЕТЕ, которая связывает ТИП САМОЛЕТА и ТИП САЛОНА.  Рисунок 8 Результат ввода сущности Тип Салона Проанализируем, какая информация кроме уже представленной в модели, является существенной для описания сферы воздушных перевозок. Во-первых, для описания АВИАМАРШРУТА нужно указать, какой авиакомпанией этот маршрут выполняется, так появляется сущность АВИАКОМПАНИЯ, которая связывается с АВИАМАРШРУТОМ как «один ко многим». Во-вторых, необходимо ввести сущность БОРТ, которая покажет, какие конкретные самолеты имеются в распоряжении каждой из АВИАКОМПАНИЙ, и какие из них выполняют тот или иной рейс. В-третьих, добавляем сущность ТАРИФ, которая показывает цену билета для АВИАМАРШРУТА при следовании из аэропорта вылета в аэропорт прилета, для моделирования этой ситуации необходимо соединить АЭРОПОРТ и ТАРИФ отношением «один ко многим» два раза. Для различия между этими двумя отношениями даем названия ролям «Аэропорт Откуда» и «Аэропорт Куда» соответственно. Теперь можно обратить внимание на то, что в тарифе для каждого авиамаршрута должны быть указаны только те аэропорты, через который проложен данный маршрут (которые присутствуют в расписании), это значит что более правильно будет установить отношения «Аэропорт Откуда» и «Аэропорт Куда» не между ТАРИФОМ и АЭРОПОРТОМ, а между ТАРИФОМ и РАСПИСАНИЕМ. Так как цена билета зависит также от типа салона, устанавливаем связь между сущностями ТАРИФ и ТИП САЛОНА. И наконец вводим сущность БИЛЕТ, которая даст возможность учитывать, кто когда, каким рейсом, откуда и куда летал по билету. У билета, очевидно, существует естественный первичный ключ «Номер билета». БИЛЕТ связывается отношением с РЕЙСОМ как «один ко многим». Информация о маршруте, аэропорте вылета и аэропорте прилета, а также типе салона будет извлекаться из сущности ТАРИФ с которой билет также связывается отношением «один ко многим».  Рисунок 9 Окончательный вариант модели |
