Определение сущности
Полное определение сущности подразумевает указание параметров, перечисленных в стандартных формах C6 и C7 и требуемых для работы в среде CASE. Если подразделения организации разбросаны географически, требования распределенной обработки должны быть зафиксированы в форме C8 (дополняющей форму C6).
В форме "Определение сущности" для каждого атрибута вы можете указать наименование, обязательность, домен, формат, замечания и принадлежность к уникальному идентификатору. Для большинства атрибутов этого достаточно. Для более детального описания атрибутов используется форма C9 (где приводятся те же сведения, но с дополнительными подробностями).
Параметры сущности
| Этап стратегии | Этап анализа | Правила | |||||
| Имя | О |
| О | Уникально в контексте. Имеет вид существительного ед.числа. Согласовывается с пользователями. Не допускает иного толкования. | |||
| Множественная форма | О | О | Уникально в контексте. Согласованный формат для предложений,использующих множеств. форму. | ||||
| Синоним(ы) | Н | Н | Альтернативные названия для одной и той же вещи | ||||
| Пример(ы) | Н | Н | Даются в замечаниях, облегчают понимание предмета. | ||||
| Описание | Н | О | Сжатое,точное,согласованное с пользователем определение сущности, начинающееся с фразы "Имеет значение..." | ||||
| Замечания | Н | Н | Дополнительная информация о сущности, адресованная к другим аналитикам и проектировщикам | ||||
| Код | Н | Н | Уникальный код, необходимость в котором определяется инсталляцией. | ||||
| Супертип | О | О | Допускается только одно значение. |
| Обозначения: | О - обязательный параметр
Н - необязательный параметр |
Взаимоотношения сущности с другими элементами
| Этап стратегии | Этап анализа | Правила | |||||
| Атрибут | Н | О | На этапе стратегии - один или два. К концу этапа анализа по меньшей мере два на сущность. | ||||
| Функция | Н | О | На этапе стратегии требуется двойная проверка. К концу этапа анализа на каждую сущность должна быть минимум одна функция по ее созданию, коррекции, удалению и пр. Обычно отражается в форме определения функций. | ||||
| Связь | О | О | Подробности о связях со всеми прочими сущностями. Каждая сущность должна иметь связь с минимум еще одной сущностью. (См. описание связей ниже.) | ||||
| Функциональный блок (распределенная обработка) | Н | Н | Для распределенных организаций могут оказаться важными объемные характеристики использования каждой сущности в функциональном блоке/ отделе. См. стандартную форму C8. |
С помощью словаря ( энциклопедического или терминологического) эту информацию можно быстро проверить и сформировать по ней отчет для согласования с пользователем.
Обеспечение целостности
|
Правила |
Н |
Н |
В некоторых случаях имеют решающее значение, если отражают существенные (а не случайные) для предмета правила. Указываются в форме C7 или C8. |
|
Обозначения: |
О - обязательный параметр Н - необязательный параметр |
|
Этап стратегии |
Этап анализа |
Правила |
|
|
Объемы |
Н |
О |
Может быть просто одно значение (например, 200 самолетов), тогда укажите начальный, средний и максимальный объемы и темп роста, используя форму C6. Если нужно указать диапазоны, темпы роста по периодам и распределение внутри организации, используйте форму C7. Объемы подтипов должны примерно совпадать с объемами супертипов. |
|
Архивирование |
Н |
Н |
Страхует от краха системы. Указывается в формах C7 или C8 для всех объемных сущностей |
|
Обозначения: |
О - обязательный параметр Н - необязательный параметр |
Определение связи
Полное определение связи подразумевает указание для каждого из ее концов следующих параметров (см. форму C6):
Параметры связи
| Этап стратегии | Этап анализа | Правила | |||||
| Степень | О | О | Уточнение типа связи. | ||||
| Описание связи на ее конце | О | О | Связующая фраза, следующая за фразой "должно/ может". | ||||
| Обязательность | О | О | Обязательная или необязательная связь. | ||||
| Замечания | Н | Н | Для особых случаев. | ||||
| Минимальная степень | Н | Н | Может указываться в замечаниях. | ||||
| Средняя степень | Н | Н | Может указываться в замечаниях. | ||||
| Максимальная степень | Н | Н | Может указываться в замечаниях. |
Признак каскадного удаления
| Признак каскадного удаления | Н | Н | X = Каскадное удаление в случае удаления родителя.
C = Родитель не удаляется, пока существует хоть один потомок. N = Родитель и потомок могут удаляться отдельно друг от друга. |
| Обозначения: | О - обязательный параметр
Н - необязательный параметр |
Взаимоотношения с другими элементами
| Этап стратегии | Этап анализа | Правила | |||||
| Сущность | О | О | Каждый конец связи должен иметь отношение к сущности. | ||||
| Функция | Н | Н | Иногда функция имеет явную ссылку на связь (через установление или разрыв последней). | ||||
| Дуга | Н | Н | Каждый конец связи может покрываться одной и только одной дугой, имя или номер которой указывается в столбце "Дуга". |
Уникальный идентификатор
В форме "Определение сущности" два столбца отведены для записи альтернативных уникальных идентификаторов. Каждый идентификатор представляет собой комбинацию атрибутов и/или концов связей, помечаемых "галочкой" в соответствующем столбце. К концу этапа анализа уникальный идентификатор должен быть у каждой сущности.
| Этап стратегии | Этап анализа | Правила | |||||
| Уникальный идентификатор | Н | Н | Каждый конец связи может быть компонентой одного или нескольких уникальных идентификаторов. |
Обозначения: |
О - обязательный параметр Н - необязательный параметр |
До тех пор, пока вы не наберетесь собственного опыта, вы можете сэкономить время, используя предлагаемые ниже примеры описания связей:
Пары описаний связи
о (about) |
предмет (subject of) |
в отношении к (applicable to) |
контекст для (context for *) |
в (at) |
место для (location of) |
основано на (based on) |
основа для (basis for) |
получено от (bought in from) |
поставщик (supplier of) |
основание для классификации (classification for) |
имеет (of) |
покрывается (covered by) |
для (for) |
определяется (defined by) |
частично определяет (part definition of) |
описание (description of) |
характеризуется (for) |
для (for) |
отражается на (shown on) |
для работы под (for work under) |
основание для (authority for) |
инициализируется (initiated by) |
инициатор (initiator of) |
кандидат на (nominee for) |
объект притязаний (subject of) |
упоминается на (notified on) |
место упоминания (notification point for) |
управляется (operated by) |
приводит в действие (operator for) |
принадлежит (owned by) |
владелец (owner of *) |
составная часть (part of) |
состоит из (composed of) |
часть (part of) |
детализируется на (detailed by) |
участвует в (party to) |
для (for) |
представляется (represented by) |
представление для (representation of) |
несет ответственность за (responsible for) |
объект ответственности (responsibility of) |
обслуживается (run by) |
курирует (carrier for) |
источник для (source of) |
строится на (based on) |
вызывает (trigger for) |
приводится в действие (triggered by) |
при (under) |
контекст для (context for) |
в пределах ответственности (within) |
отвечает за (responsible for) |
Пары, помеченные звездочкой (*), используются только в крайних случаях. Так, например, отношение владения (принадлежит - владелец) должно отражать узаконенное право собственности.
Некоторые из примеров отражают ту или иную роль личности или организации.
ОПРЕДЕЛЕНИЕ ДОМЕНА (ПРИКЛАДНОЙ УРОВЕНЬ)
Код 173 ORACLE (R)
Система управления реляционной базой данных
|
||||||||||||||||||||||||||||||||||||||||||||
|
Описания/замечания Определяет допустимые значения классификации воздушных перелетов, имеющие отношение к КУПОНАМ и МЕСТАМ
|
|
Форма |
Группа |
Проект |
Аналитик |
Дата |
Лист 1 |
|
C3 |
Пользователь |
Действие |
Проверил |
Дата |
Всего 1 |
Перечень материалов
Во многих организациях, занимающихся выпуском изделий, структура, подобная перечню материалов, позволяет идентифицировать:
какие компоненты (детали, составные части) используются в различных продуктах (изделиях) и
какие продукты выпускаются и их состав
В этих случаях говорят о типах компонент и продуктов. Компонента одного и того же типа (например, мотор) может входить в состав множества других компонент или продуктов. Изобразим это утверждение в виде схемы.
Рисунок 8-14.
Возможностей этой модели нам окажется недостаточно, если нас будет интересовать количественный аспект и порядок сборки. Для этого нам понадобится создать граничную сущность с подобными атрибутами (как мы это делаем, когда сталкиваемся со связью типа "многие ко многим").
Рисунок 8-15. Создание граничной сущности, разрывающей связь "многие ко многим"
Разложение на части
Каждая КОМПОНЕНТА или ПРОДУКТ может состоять из одной и более СТАНДАРТНЫХ СОСТАВЛЯЮЩИХ соответствующего количества и порядка сборки, каждая из которых должна отражать назначение той или иной КОМПОНЕНТЫ или ПРОДУКТА.
И наоборот, каждая КОМПОНЕНТА или ПРОДУКТ может использоваться в качестве одной и более СТАНДАРТНЫХ СОСТАВЛЯЮЩИХ, каждая из которых должна входить в список компонент для другой КОМПОНЕНТЫ или ПРОДУКТА.
С терминологией могут возникнуть трудности. Вы должны прежде всего признать то, что форма правильна, а терминологию вы можете использовать ту, которая предполагается соглашениями, принятыми в исследуемой организации. От организации к организации слова, обозначающие одно и то же, меняют свое написание:
часть
компонента
составляющая
продукт
список ингредиентов
оборудование
установка
и многие другие.
Пользовательское одобрение
Регулярно представляйте вашу модель или ее отдельные фрагменты, относительно которых у вас возникают сомнения, на одобрение пользователей. Поддерживайте в них желание работать с вами бок о бок над поиском и исправлением ваших ошибок и упущений. Особое внимание уделяйте исключениям из правил и ограничениям. Разобравшись в проблеме на 100%, разработчики смогут создать такой проект БД, который будет учитывать до 82% запросов, действительно нуждающихся в компьютерной поддержке (обычно действует правило 80:20; дополнительные 2% позволяют существенно снизить издержки по сопровождению).
Поток и хранилище данных
Многие аналитики и проектировщики пользуются понятием "схема потоков данных", подразумевающим отражение взаимосвязей между управленческими функциями, принимающими или передающими данные. Пример см. на следующей странице.
Рисунок 9-1. Схема потоков данных для функции "Поставка и сопровождение"
Каждая из стрелок представляет поименованный поток данных.
Каждый из блоков соответствует временному или постоянному хранилищу логических данных/атрибутов, используемому отдельной функцией.
Описание каждого потока и хранилища данных дается в терминах набора атрибутов сущностей, представленных на модели взаимосвязей между сущностями. В некоторых случаях они содержат также производные данные, такие как "доход", которые должны обычно выводиться исходя из значений известных атрибутов. Это важный элемент контроля полноты.
Содержимое хранилища должно отражать результат объединения связанных с ним потоков данных.
Правила
Все правила и руководящие указания содержатся в ранее рассмотренных соглашениях. Здесь же мы сведем их вместе для удобства.
Правила для атрибутов
Следующие несложные правила позволяют создавать точные, полные и гибкие модели. См. также Приложение A.
Атрибут служит для описания одной сущности
Атрибут должен определять именно ту сущность, под которой он подписан.
Это может показаться очевидным, однако наиболее часто возникающие ошибки связаны с атрибутами. Так, например, "номер места" является атрибутом купона, билета, посадочного талона, самолета или места в самолете? Очевидно, это атрибут МЕСТА, однако в реальной жизни этот номер зачастую многократно дублируется, появляясь, например, в том числе и на посадочном талоне, включенном в схему в качестве сущности (Рисунок 3-12).
Почему так? В реальном мире номер места очень удобно использовать для представления связи. Если вам известны подобные случаи, добавьте в схему линии таких связей (при необходимости, создавая недостающие сущности).
Рисунок 3-12. Передача атрибута "истинному владельцу"
Как правило, для описания большинства сущностей используется от двух до восьми атрибутов. Превышение этого числа может быть следствием слишком большого количества связей и/или отсутствия некоторых необходимых сущностей.
Чтение названий атрибутов
В названии атрибута не следует использовать имя сущности. Это будет излишним, ибо атрибут описывает только одну сущность. В вышеприведенном примере "номер места" в действительности идентифицировал отсутствующую сущность МЕСТО, которая кроме атрибута "номер" может иметь и другие атрибуты, например "тип".
Чтобы прочитать атрибуты, названные таким образом, вы можете воспользоваться одной из следующих двух форм:
Имя сущности Название атрибута или Название атрибута Имя сущности , например: номер места.
В классическом примере со служащими и отделами "номер отдела" не является атрибутом сущности СЛУЖАЩИЙ. Он выступает атрибутом сущности ОТДЕЛ.
Убирайте повторяющиеся атрибуты
В одно и то же время сущность не может иметь более одного значения каждого из ее атрибутов. Если значений атрибута оказывается много, вам нужно создать новую сущность с передачей ей этого атрибута и с установлением связи типа "многие к одному" с первой сущностью.
Воспользуемся старым примером:
Рисунок 3-13. Повторяющийся атрибут указывает на отсутствие сущности
Следуя указанному правилу, мы получим:
Рисунок 3-14. Добавление недостающей сущности
Это правило часто называют "Первой формой нормализации" (см. Приложение A).
Использование единственного числа в наименованиях
Название атрибута должно быть дано в единственном числе. Множественное число часто является отражением проблемы повторяющихся атрибутов. Для сущности САМОЛЕТ такими атрибутами могут стать - места, экипаж, двери и двигатели. Еще раз обратите внимание на отсутствие на схеме тех сущностей, которым могут принадлежать эти атрибуты.
Может это сущность?
Атрибут становится сущностью, если он представляет самостоятельный объект или явление со своими собственными связями и атрибутами.
В предыдущем примере мы использовали "регистрационный номер" в качестве атрибута самолета. И это будет иметь смысл до той поры, пока у авиалинии не появится подсистема регистрации, которая потребует также учета "даты регистрации", "места регистрации", "цели регистрации", "признака перерегистрации" и т.п. Наша схема может превратиться в нечто подобное следующему:
Рисунок 3-15. Атрибут может стать сущностью
Будьте осторожны ! Таким путем можно дойти до подробностей, не относящихся к делу. В нашем случае такая подсистема нас не интересует и мы возвращаемся к предыдущей модели, расширив наше представление путем добавления к регистрационному номеру прилагательного "текущий".
Рисунок 3-16
Правила для сущностей
Любое явление или объект может быть представлено в виде только одной сущности. Другими словами, во всех случаях сущности строятся по принципу взаимного исключения.
Каждая сущность должна быть уникально определена.
То есть каждый экземпляр (вхождение) сущности должен иметь ясное и недвусмысленное определение, позволяющее отличать его от других экземпляров (вхождений) той же сущности.
(См. раздел "Уникальный идентификатор".)
Другие соглашения и правила, касающиеся сущностей, приводятся в главе 7. (См. также Приложение C.)
Правила размещения объектов на схемах
Элементарные правила построения схем направлены на облегчение чтения схем, их восприятия пользователями, а также повышение их качества и точности.
Подсхемы
При обсуждении с пользователем или проектировщиками конкретного функционального фрагмента проблемы удобнее пользоваться подсхемами, как наиболее эффективным средством представления, подходящим для этого случая. В процессе обсуждения вы будете обнаруживать упущения и ошибки, которые на подсхеме исправляются проще и быстрее (смена точек зрения - мощное аналитическое средство).
Точность и аккуратность
Старайтесь, чтобы на ваших схемах блоки выстраивались в ряд, а линии связей были по возможности прямые, горизонтальные или вертикальные. Пересечения линий сведите к минимуму. Если же пересечения не удается избежать, старайтесь, чтобы линии пересекались под углом 30-60 градусов, облегчая тем самым зрительное восприятие.
Следите за тем, чтобы у вас не получались схемы, состоящие из большого количества элементов с близко расположенными параллельными линиями: за такими связями трудно следить. Старайтесь оставлять побольше места между блоками, чтобы у пользователя не возникало ощущение тесноты; для придания схеме изящного вида можно изредка использовать и диагональные линии.
Пометки на схеме
Каждая схема должна иметь заголовок и дату; не забудьте указать автора схемы.
Узнавание по форме
Большинство людей способно мгновенно узнавать что-либо по форме или очертаниям и благодаря этому легко запоминать сам предмет. Построители схем могут воспользоваться этой особенностью, придавая каждой схеме свою неповторимую форму (размер при этом не имеет существенного значения). Ранее утвержденная модель в дальнейшем может снова стать предметом обсуждения с максимальной продуктивностью.
Если же вы создадите несколько схем одной формы, способность быстро запоминать детали и подробности будет потеряна.
Текст
Следите за тем, чтобы в используемом тексте не допускалась двусмысленность. Избегайте сокращений и элементов жаргона. Ориентируйтесь на соглашения, рассмотренные нами ранее, и прочитывайте схему, дабы убедиться в ее полноте и точности.
Хорошая схема взаимосвязей между сущностями должна отличаться семантической полнотой. Чтобы облегчить понимание и добиться повышения точности, прибегайте к примерам и более развернутым характеристикам.
Старайтесь располагать текст по горизонтали, чтобы его было легче читать. Наименование может располагаться на нескольких строках. В случае необходимости описания связей могут располагаться вдоль всей линии.
Рисунок 3-22
Степень связи
Старайтесь, чтобы разветвляющийся конец (воронья лапка) связи находился слева или в верхней части линии связи. Как оказалось, это повышает точность модели, ибо модель при этом читается от более часто встречающихся сущностей к более редким.
(Большинство людей просматривает схемы слева направо и сверху вниз, так что такое расположение информации совпадает с естественным путем ее восприятия. Этому способствует также тот факт, что наиболее редко встречающиеся сущности, находящиеся в правом нижнем углу схемы, представляют особенную важность, ибо используются для описания других объектов; примеры: компания, продукт, аэропорт. Чтение схемы в направлении таких сущностей помогает определять остальные сущности через связи, существующие между ними.)
Размер и форма блоков
Размеры и форма блоков не имеют особого значения. Блоки могут быть вытянутыми, увеличенными или сжатыми, если это необходимо в целях обеспечения большей наглядности представления.
Рисунок 3-23. Стандартный вид схемы
Обратите внимание на использование двух диагональных линий и точное следование правилу "разветвление сверху и слева".
Качество
Данные соглашения допускают появление на схеме сходных по смыслу сущностей по соседству др. с др. На практике такое может случаться, ибо часто один объект появляется под разными наименованиями - проверьте атрибуты, связи и функции, в которых они используются.
Дополнительные соглашения
В настоящей главе приведены только основные соглашения и определения, используемые в МВМС. В следующей главе рассматривается еще один пример и вводятся дополнительные понятия.Уточненные определения, новые правила и способы проверки качества, которые будут введены позднее, позволят моделировать более сложные ситуации.
Информация должна рассматриваться не только
Информация должна рассматриваться не только как некая принадлежащая предприятию ценность, но и как исходная точка для построения информационной системы, обслуживающей предприятие. На практике во многих организациях пришли к убеждению, что правильное понимание информационного аспекта служит необходимой предпосылкой для построения высококачественных и целостных информационных систем. По этой причине ведущим направлением в разработке программных средств АСУ является переход от процедурно-ориентированных методов разработки к информационно-ориентированным. Информационное проектирование становится самой популярной методологией, пронизывающей все стадии жизненного цикла системы.
Информационное проектирование зачастую характеризуется как подход к созданию систем, сконцентрированный на информации. Это также всеобъемлющая стратегия, основанная на информационном планировании и уяснении целей системы. Главная посылка, на которой строится данная стратегия, состоит в том, что целостность информационных систем определяется степенью охвата информационных элементов объекта соответствующей логической моделью.
Информационное проектирование предполагает прежде всего глубокое исследование всех информационных систем, преследующее своей целью поиск ответа на вопрос: каким образом информация используется и разделяется системами. Программные структуры выступают по отношению к информационной модели уже "надстройкой", определяющей общую информационную инфраструктуру для создания соответствующих систем на предприятии. Таким образом, процедуры логически вытекают из данных, а качество информационных систем определяется качеством построения информационной модели.
Информационное обследование организации - трудоемкая и продолжительная работа. Только опытным аналитикам, вооруженным мощным инструментарием и технологией, под силу обеспечить точность и целостность описания информации.
Моделирование взаимосвязей между сущностями (объектами) представляет собой метод информационного проектирования, предназначенный для построения высококачественной информационной модели.
Информационное моделирование служит стандартным средством определения данных и взаимосвязей между ними, применяемым во всех информационных системах. Оно существенно повышает качество системы и продуктивность программного обеспечения.
Моделирование взаимосвязей становится универсальным методом информационного моделирования. По существу, каждому системному аналитику следует изучать и использовать основы моделирования взаимосвязей между объектами. Существует несколько курсов и пособий, помогающих освоить указанный метод моделирования. Настоящая книга написана Ричардом Баркером, опытным аналитиком, внесшим свой вклад в его развитие и испытание за двадцать лет работы над различными проектами. Изложение основ моделирования в книге сопровождается разъяснением соответствующей терминологии и некоторыми руководящими указаниями. Автор использует примеры из реальной жизни - простые и более сложные - дабы с их помощью облегчить освоение нового метода. Объясняется механизм поддержки метода с помощью CASE-инструментария. В дальнейшем, после освоения метода, пользователь может обращаться к книге как к справочнику, содержащему определение основных понятий и терминов.
Карма Макклар
Сентябрь 1989
Предостережение
Довольно легко перейти грань, отделяющую реальную модель от чересчур обобщенной; в качестве примера последней можно привести модель, называемую "жизнь, вселенная и все, что можно представить":
Рисунок 8-35. Последняя стадия обобщения
Старайтесь всегда привлекать к обсуждению модели своих коллег и пользователей.
Такие модели являются средством, облегчающим общение, и если вы почувствовали в ходе обсуждения, что в чем-то перестарались, вы можете вернуться к предыдущему уровню обобщения и т.п. до тех пор, пока не достигнете всеобщего понимания.
Претензии пользователей
От систем сегодня и в ближайшем будущем ждут в любой организации выполнения разнообразных запросов, возникающих в повседневной работе, на административном уровне, в рамках локальной, централизованной и децентрализованной обработки. В этих системах должны находить воплощение различные методы реализации, от использования простейших файлов, обрабатываемых вручную, и канцелярских комплексов до гетерогенных распределенных БД. Создание подобных систем без использования средств моделирования вряд ли возможно.
Прикладные функции
Из вышеизложенного следует, что определения функциям следует давать в терминах проблемных представлений. Простые функции реализуются на одном проблемном представлении, часто это представление граничной сущности; например: КУПОН к билету на рейс. Другие функции используют два и более проблемных представлений, связанные между собой ссылками на идентичные производные атрибуты.
Все атрибуты проблемного представления могут использоваться в определении прикладной функции через условия, фразы "where" (где) или другие средства идентификации интересующих нас вхождений.
Вообще говоря, только атрибут текущей сущности может быть объектом корректирующих действий.
Единственное исключение имеет место, когда эти действия производятся в отношении значений атрибутов, корреспондирующих с уникальным идентификатором сущности, непосредственно связанной с текущей. В этом случае можно говорить о попытке изменить связь.
Так, например, если обратиться к проблемному представлению для сущности КУПОН, то можно сказать, что попытка изменения номера рейса и даты отправления будет попыткой изменить связь КУПОНА с РЕЙСОМ (переоформление на другой рейс).
Если функция имеет отношение к РЕГУЛЯРНОМУ РЕЙСУ, атрибуты соответствующего проблемного представления будут использоваться следующим образом:
Рисунок G-5. Проблемное представление РЕГУЛЯРНЫЙ РЕЙС
B. ДОПУСТИМЫЕ ВИДЫ СВЯЗЕЙ
Информация об общепринятых способах описания степени мощности и обязательности связей может оказаться вам полезной.
C. ДЕТАЛИЗИРОВАННЫЕ ОПИСАНИЯ СУЩНОСТИ, СВЯЗИ, ДОМЕНА И АТРИБУТА
В данном приложении рассматриваются формы детализированного описания сущности, связи, домена и атрибута. Эти формы могут заполняться вручную, на бумаге, но для записи информации рекомендуется использовать систему CASE.
Формы именуются:
|
C6 |
Определение сущности |
(с перечислением атрибутов, связей, уникальных идентификаторов и основных объемов) | |||
|
C7 |
Объемные характеристики сущностей |
(общие объемы) | |||
|
C8 |
Объемные характеристики сущностей |
(распределенные требования) | |||
|
C3 |
Определение домена | ||||
|
C9 |
Полное определение атрибута. |
Все эти формы взяты из книги "CASE*Method Tasks and Deliverables" (Приложение C) и могут быть размножены для использования при работе с CASE-методом.
Код 52 ORACLE (R) --------------------- ОПРЕДЕЛЕНИЕ СУЩНОСТИ ----------¬ ¦ Система управления реляционной ¦ ¦ базой данных ¦ ¦ ¦ ¦ Имя ¦ ¦ (множественная форма) КУПОН(ы)......... Супертип............ ¦ ¦ Синонимы ................. Начальный объем ...... ¦ ¦ ................. Средний объем....... Вероятный ¦ ¦ ................. максимум ..... ¦ ¦ ................. Темп роста ......... % в год ¦ +----------------------------------------------------------------+ ¦ Описание: имеет значение составной части билета, оформляемой на¦ ¦ конкретный рейс через процедуру выписки посадочного талона. ¦ ¦ ¦ +----------------------------------------------------------------+ ¦ Атрибуты ¦ ¦ Наименование Не- Домен Формат Макс. Заме- См. Уни-¦ ¦ обяза- длина чания пол- каль¦ ¦ тель- ное ный ¦ ¦ ность опи- ид.
¦ ¦ сание ¦ +-----------------T---T--------T-------T-------T------T-----T-T--+ ¦ класс ¦ N ¦ класс ¦ ¦ ¦ ¦ ¦ ¦ ¦ статус ¦ ¦ ¦ ¦ ¦ ¦ v ¦ ¦ ¦ ¦ индикатор под- ¦ ¦ ¦ ¦ ¦Булево¦ ¦ ¦ ¦ тверждения ¦ N ¦ ¦ char ¦ 1 ¦знач-е¦ ¦ ¦ ¦ ¦ комментарии ¦ Y ¦ ¦ char ¦ 40 ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ +-----------------+---+--------+-------+-------+------+-----+-+--+ ¦ Связи: Каждое вхождение данной сущности ¦ ¦ должно/¦связующая¦одну и только одну/¦имя ¦кас- ¦дуга¦ ¦ ¦ может ¦фраза ¦одну и более ¦сущности¦кад- ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ное ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦уда- ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ление¦ ¦ ¦ +--------+---------+-------------------+--------+-----+----+--T--+ ¦ должно ¦входить в¦один и только один ¦билет ¦ x ¦ ¦v v ¦ ¦ должно ¦оформ- ¦один и только один ¦рейс ¦ ¦ 1 ¦v ¦ ¦ ¦ ¦ляться на¦ ¦ ¦ ¦ ¦ ¦ ¦ должно ¦быть от- ¦один и только один ¦авиа- ¦ ¦ 1 ¦ ¦v ¦ ¦ ¦крытым на¦ ¦маршрут ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ +--------+---------+-------------------+--------+-----+----+--+--+ ¦ Замечания: ¦ ¦ ¦ ¦ Полное описание атрибута должно быть введено для всех допусти- ¦ ¦ мых значений атрибута, имеющего "галочку" в столбце "См.
полное¦ ¦ описание". ¦ ¦ ¦ ¦ ¦ ¦ Подробности на следующем листе ¦ L-----------------------------------------------------------------
ОПРЕДЕЛЕНИЕ СУЩНОСТИ
Код 52 ORACLE (R)
Система управления реляционной базой данных |
|||||||||
Имя (множественная форма) КУПОН(ы) .......... |
Супертип .......... |
||||||||
Синонимы ......... ......... ......... ......... |
Начальный объем .......... Средний объем .......... Темп роста .......... |
Вероятный максимум % в год .......... |
|||||||
Описание: имеет значение составной части билета, оформляемой на конкретный рейс через процедуру выписки посадочного талона. |
|||||||||
Атрибуты Наименование |
Необя- затель- ность |
Домен |
Формат |
Макс. длина |
Замечания |
См. полное описание |
Уникальный ид. |
||
класс |
N |
класс |
|||||||
статус |
v |
||||||||
индикатор подтверждения |
N |
char |
1 |
Булево значение |
|||||
комментарии |
Y |
char |
40 |
||||||
Связи: Каждое вхождение данной сущности |
|||||||||
должно/может |
связующая фраза |
одну и только одну/одну и более |
имя сущности |
каскадное удаление |
дуга |
||||
должно |
входит в |
один и только один |
билет |
х |
v |
v |
|||
должно |
оформляться на |
один и только один |
рейс |
1 |
v |
||||
должно |
быть открытым на |
один и только один |
авиамаршрут |
1 |
v |
||||
Замечания: Полное описание атрибута должно быть введено для всех допустимых значений атрибута, имеющего "галочку" в столбце "См. полное описание". Подробности на следующем листе |
|||||||||
|
Форма |
Группа |
Проект |
Аналитик |
Дата |
Лист 1 |
|
C6 |
Пользователь |
Действие |
Проверил |
Дата |
Всего 3 |
Код 52 ORACLE (R)
|
Система управления реляционной базой данных (общие объемы) Имя сущности КУПОН.......................... (См. распределенные требования) Детализированные объемные характеристики (некоторых сущностей)
Обеспечение целостности
|
|
Форма |
Группа |
Проект |
Аналитик |
Дата |
Лист 2 |
|
C7 |
Пользователь |
Действие |
Проверил |
Дата |
Всего 3 |
Код 52 ORACLE (R)
|
Система управления реляционной базой данных (распределенные требования) Имя сущности КУПОН.......................... |
||||||||||||||||||||||||||||||||||||||||||||||||||||||
Архивирование
Обеспечение целостности
|
|
Форма |
Группа |
Проект |
Аналитик |
Дата |
Лист 3 |
|
C8 |
Пользователь |
Действие |
Проверил |
Дата |
Всего 3 |
D. ИСПОЛЬЗОВАНИЕ CASE-ИНСТРУМЕНТАРИЯ
Поставкой средств автоматизированного проектирования систем или программного обеспечения (CASE) занимаются многие фирмы. Большинство этих средств включают в себя возможность МВМС или др. информационного моделирования. Содержащиеся в данном приложении обзорные схемы дают представление о функциях, выполняемых этими средствами на различных этапах проектирования систем. Этапы выработки стратегии и анализа иллюстрируются более подробно, так как они отражают очередность применения средств, поддерживающих МВМС.
Из схем однако не видны задачи, стоящие на каждом из этапов; они рассматриваются в книге "CASE*Method - Tasks and Deliverables", принадлежащей перу того же автора.
Этап выработки стратегии
F. ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ
Настоящая книга не является руководством по проектированию БД, тем не менее представляется полезным проиллюстрировать основы логического проектирования реляционной БД в контексте и на базе модели взаимосвязей между сущностями. Для ознакомления с этим разделом необходимо иметь представление о языке структурированных запросов (SQL) по описанию, составленному Американским национальным институтом стандартов (ANSI).
I. ПОЛНАЯ МОДЕЛЬ ДЛЯ АВИАЛИНИИ "ATLANTIS ISLAND FLIGHTS"
Данное приложение содержит модель взаимосвязей между сущностями для авиалинии "Atlantis Island Flights", построенную средствами CASE*Designer в среде Oracle. Поскольку авиалиния - всего лишь гипотетическая, модель нельзя считать не только окончательной, но и даже свободной от упущений и достаточно близкой к реальности. Стоит потратить время на то, чтобы проверить детали, не освещенные в комментариях и замечаниях, и открыть для себя что-то новое в результате таких исследований.
В данном приложении также приведены отчеты CASE*Dictionary для следующих сущностей: БИЛЕТ,КУПОН,АВИАМАРШРУТ,НАЗНАЧЕНИЕ В ЭКИПАЖ.
Также показан пример экрана программы-построителя схем взаимосвязей между сущностями, входящей в состав CASE*Designer'а.
Пример экрана построителя схем взаимосвязей между сущностями
Построители схем взаимосвязей между сущностями включаются в большинство пакетов CASE. Рассматриваемый здесь взят из CASE*Designer'а - многооконного и многопользовательского продукта корпорации Oracle.
В процессе работы с этим средством вы можете выбирать сущности, задавать размеры их блоков, перемещать их и включать в другие сущности (т.е. создавать подтипы), а также выбирать оптимальную форму размещения объектов на схеме. Опции меню позволяют добавлять атрибуты, формировать проект БД по умолчанию, а также многое другое, что может потребоваться на этапах выработки стратегии, анализа и проектирования БД. Похожими возможностями обладают построители матриц, схем информационных потоков, функциональной иерархии и т.п.
------------------------------------------------------------¬ -+----------------------------------------------------------¬¦ -+----------------------------------------------------------¬¦¦ -+----------------------------------------------------------¬¦¦¦ -+----------------------------------------------------------¬¦¦¦¦ ¦ Date: 01-AUG-89 ORACLE: CASE*Dictionary Page: 1 ¦¦¦¦¦ ¦ ¦¦¦¦¦ ¦ DETAILED ENTITY DEFINITION ¦¦¦¦¦ ¦ ¦¦¦¦¦ ¦ Entity Name: TICKET Application: ATBS ¦¦¦¦¦ ¦ Version : 1 ¦¦¦¦¦ ¦ ¦¦¦¦¦ ¦ Sub-type of: Reference : TICKET ¦¦¦¦¦ ¦ ¦¦¦¦¦ ¦ Synonyms : GROUP TICKET Initial Volume: ¦¦¦¦¦ ¦ Average Volume: 60000 ¦¦¦¦¦ ¦ Maximum Volume: ¦¦¦¦¦ ¦ Annual Growth%: 15 ¦¦¦¦¦ ¦ ¦¦¦¦¦ ¦ --- DESCRIPTION - HAS SIGNIFICANCE AS ------------------- ¦¦¦¦¦ ¦ ¦¦¦¦¦ ¦ A means of acquiring the right to fly with an airline as ¦¦¦¦¦ ¦ a passenger. ¦¦¦¦¦ ¦ # ¦¦¦¦¦ ¦ A contractual document between an airline and a person, ¦¦¦¦¦ ¦ which may be exchanged, cashed in, or its constituent cou-¦¦¦¦¦ ¦ pons exchanged for a journey with this or another airline.¦¦¦¦¦ ¦ ¦¦¦¦¦ ¦ --- ATTRIBUTES ------------------------------------------ ¦¦¦¦¦ ¦ ¦¦¦¦¦ ¦ Name : CURRENCY Domain : CHAR CODE ¦¦¦¦¦ ¦ Opt : N Format : CHAR Length : 3 ¦¦¦¦¦ ¦ Name : DATE OF ISSUE Domain : ¦¦¦¦¦ ¦ Opt : N Format : DATE Length : ¦¦¦¦¦ ¦ Name : DISCOUNT GIVEN Domain : ¦¦¦¦¦ ¦ Opt : N Format : MONEY Length : 6.2 ¦¦¦¦¦ ¦ Name : FULL FARE Domain : ¦¦¦¦¦ ¦ Opt : N Format : MONEY Length : 6.2 ¦¦¦¦¦ ¦ Name : NUMBER Domain : ¦¦¦¦¦ ¦ Opt : N Format : INTEGER Length : 9 * ¦¦¦¦¦ ¦ Name : STAFF INDICATOR Domain : ¦¦¦¦¦ ¦ Opt : N Format : CHAR Length : 1 ¦¦¦¦¦ ¦ Name : TIME OF ISSUE Domain : ¦¦¦¦¦ ¦ Opt : N Format : TIME Length : ¦¦¦¦¦ ¦ * - Attributes in primary unique identifier ¦¦¦¦¦ ¦ ¦¦¦¦¦ ¦ --- RELATIONSHIPS --------------------------------------- ¦¦¦¦¦ ¦ ¦¦¦¦¦ ¦ EACH OCCURRENCE OF THIS ENTITY : ¦¦¦¦¦ ¦ ¦¦¦¦¦ ¦ MUST BE made up of ONE OR MORE COUPONS ¦¦¦¦¦ ¦ MUST BE issued by ONE AND ONLY ONE ORGANIZATION UNIT ¦¦¦¦¦ ¦ MUST BE for ONE AND ONLY ONE PERSON ¦¦¦+- ¦ * - Relationships in primary unique identifier ¦¦+- ¦ ¦+- ¦ --- NOTES AND REMARKS ----------------------------------- +- L------------------------------------------------------------ ------------------------------------------------------------¬ -+----------------------------------------------------------¬¦ -+----------------------------------------------------------¬¦¦ -+----------------------------------------------------------¬¦¦¦ -+----------------------------------------------------------¬¦¦¦¦ ¦ Дата: 01-AUG-89 ORACLE: CASE*Dictionary Стр.: 1 ¦¦¦¦¦ ¦ ¦¦¦¦¦ ¦ ДЕТАЛИЗИРОВАННОЕ ОПРЕДЕЛЕНИЕ СУЩНОСТИ ¦¦¦¦¦ ¦ ¦¦¦¦¦ ¦ Имя сущности: БИЛЕТ Прикладная система: ATBS ¦¦¦¦¦ ¦ Версия : 1 ¦¦¦¦¦ ¦ ¦¦¦¦¦ ¦ Супертип : Ссылка : БИЛЕТ ¦¦¦¦¦ ¦ ¦¦¦¦¦ ¦ Синонимы : ГРУППОВОЙ БИЛЕТ Начальный объем : ¦¦¦¦¦ ¦ Средний объем : 60000 ¦¦¦¦¦ ¦ Максимальн.объем: ¦¦¦¦¦ ¦ Годовой прирост%: 15 ¦¦¦¦¦ ¦ ¦¦¦¦¦ ¦ --- ОПИСАНИЕ - ИМЕЕТ ЗНАЧЕНИЕ --------------------------- ¦¦¦¦¦ ¦ ¦¦¦¦¦ ¦ Средства приобретения права на полет, курируемый авиалини-¦¦¦¦¦ ¦ ей, в качестве пассажира. ¦¦¦¦¦ ¦ # ¦¦¦¦¦ ¦ Договора между авиалинией и личностью, допускающего изме- ¦¦¦¦¦ ¦ нения и перепродажу, о путешествии по маршруту, курируемо-¦¦¦¦¦ ¦ му этой или другой авиалинией. ¦¦¦¦¦ ¦ ¦¦¦¦¦ ¦ --- АТРИБУТЫ -------------------------------------------- ¦¦¦¦¦ ¦ ¦¦¦¦¦ ¦ Имя : ВИД ВАЛЮТЫ Домен : CHAR CODE ¦¦¦¦¦ ¦ Необязательн.: N Формат : CHAR Длина : 3 ¦¦¦¦¦ ¦ Имя : ДАТА ВЫПИСКИ Домен : ¦¦¦¦¦ ¦ Необязательн.: N Формат : DATE Длина : ¦¦¦¦¦ ¦ Имя : СКИДКА Домен : ¦¦¦¦¦ ¦ Необязательн.: N Формат : MONEY Длина : 6.2 ¦¦¦¦¦ ¦ Имя : ПОЛНАЯ СТОИМОСТЬ Домен : ¦¦¦¦¦ ¦ Необязательн.: N Формат : MONEY Длина : 6.2 ¦¦¦¦¦ ¦ Имя : НОМЕР Домен : ¦¦¦¦¦ ¦ Необязательн.: N Формат : INTEGER Длина : 9 * ¦¦¦¦¦ ¦ Имя : ИНДИКАТОР ПОДТВЕРЖДЕНИЯ Домен : ¦¦¦¦¦ ¦ Необязательн.: N Формат : CHAR Длина : 1 ¦¦¦¦¦ ¦ Имя : ВРЕМЯ ВЫПИСКИ Домен : ¦¦¦¦¦ ¦ Необязательн.: N Формат : TIME Длина : ¦¦¦¦¦ ¦ * - Атрибуты в первичном уникальном идентификаторе ¦¦¦¦¦ ¦ ¦¦¦¦¦ ¦ --- СВЯЗИ ----------------------------------------------- ¦¦¦¦¦ ¦ ¦¦¦¦¦ ¦ КАЖДОЕ ВХОЖДЕНИЕ ЭТОЙ СУЩНОСТИ : ¦¦¦¦¦ ¦ ¦¦¦¦¦ ¦ ДОЛЖНО состоять из ОДНОГО И БОЛЕЕ КУПОНОВ ¦¦¦¦¦ ¦ ДОЛЖНО выписываться ОДНОЙ И ТОЛЬКО ОДНОЙ ¦¦¦¦¦ ¦ ОРГАНИЗАЦИОННОЙ ЕДИНИЦЕЙ ¦¦¦+- ¦ ДОЛЖНО быть для ОДНОЙ И ТОЛЬКО ОДНОЙ ЛИЧНОСТИ ¦¦+- ¦ * - Связи в первичном уникальном идентификаторе ¦+- ¦ --- ЗАМЕЧАНИЯ ------------------------------------------- +- L------------------------------------------------------------ ------------------------------------------------------------¬ -+----------------------------------------------------------¬¦ -+----------------------------------------------------------¬¦¦ -+----------------------------------------------------------¬¦¦¦ ¦ Date: 01-AUG-89 ORACLE: CASE*Dictionary Page: 2 ¦¦¦¦ ¦ ¦¦¦¦ ¦ DETAILED ENTITY DEFINITION ¦¦¦¦ ¦ ¦¦¦¦ ¦ Entity Name: COUPON Application: ATBS ¦¦¦¦ ¦ Version : 1 ¦¦¦¦ ¦ ¦¦¦¦ ¦ Sub-type of: Reference : COUPON ¦¦¦¦ ¦ ¦¦¦¦ ¦ Synonyms : Initial Volume: ¦¦¦¦ ¦ Average Volume: 90000 ¦¦¦¦ ¦ Maximum Volume: ¦¦¦¦ ¦ Annual Growth%: ¦¦¦¦ ¦ ¦¦¦¦ ¦ --- DESCRIPTION - HAS SIGNIFICANCE AS ------------------- ¦¦¦¦ ¦ ¦¦¦¦ ¦ The part of a ticket which entitles the named passenger to¦¦¦¦ ¦ travel on a specified flight of an aircraft, assuming ¦¦¦¦ ¦ there is an available seat. ¦¦¦¦ ¦ The passenger would normally have an (implicitly) associ- ¦¦¦¦ ¦ ated booking and subsequent boarding pass for the same ¦¦¦¦ ¦ flight. ¦¦¦¦ ¦ ¦¦¦¦ ¦ --- ATTRIBUTES ------------------------------------------ ¦¦¦¦ ¦ ¦¦¦¦ ¦ Name : CHECK-IN TIME Domain : ¦¦¦¦ ¦ Opt : Y Format : TIME Length : 4 ¦¦¦¦ ¦ Name : COMMENT Domain : ¦¦¦¦ ¦ Opt : Y Format : CHAR Length : 20 ¦¦¦¦ ¦ Name : CONFIRMED INDICATOR Domain : INDICATOR ¦¦¦¦ ¦ Opt : Y Format : CHAR Length : 1 ¦¦¦¦ ¦ Name : FINAL CHECK-IN TIME Domain : ¦¦¦¦ ¦ Opt : Y Format : TIME Length : 4 ¦¦¦¦ ¦ Name : STATUS Domain : ¦¦¦¦ ¦ Opt : Y Format : CHAR Length : 1 ¦¦¦¦ ¦ ¦¦¦¦ ¦ * - Attributes in primary unique identifier ¦¦¦¦ ¦ ¦¦¦¦ ¦ --- RELATIONSHIPS --------------------------------------- ¦¦¦¦ ¦ ¦¦¦¦ ¦ EACH OCCURRENCE OF THIS ENTITY : ¦¦¦¦ ¦ ¦¦¦¦ ¦ MUST BE for ONE AND ONLY ONE SEAT CLASS ¦¦¦¦ ¦ MUST BE on ONE AND ONLY ONE TICKET * ¦¦¦¦ ¦ MUST BE open for ONE AND ONLY ONE AIRLINE ROUTE * ¦¦¦¦ ¦ OR ¦¦¦¦ ¦ MUST BE for ONE AND ONLY ONE FLIGHT * ¦¦¦¦ ¦ ¦¦¦¦ ¦ * - Relationships in primary unique identifier ¦¦+- ¦ ¦+- ¦ --- NOTES AND REMARKS ----------------------------------- +- L------------------------------------------------------------ ------------------------------------------------------------¬ -+----------------------------------------------------------¬¦ -+----------------------------------------------------------¬¦¦ -+----------------------------------------------------------¬¦¦¦ ¦ Дата: 01-AUG-89 ORACLE: CASE*Dictionary Стр.: 2 ¦¦¦¦ ¦ ¦¦¦¦ ¦ ДЕТАЛИЗИРОВАННОЕ ОПРЕДЕЛЕНИЕ СУЩНОСТИ ¦¦¦¦ ¦ ¦¦¦¦ ¦ Имя сущности: КУПОН Прикладная система: ATBS ¦¦¦¦ ¦ Версия : 1 ¦¦¦¦ ¦ ¦¦¦¦ ¦ Супертип : Ссылка : КУПОН ¦¦¦¦ ¦ ¦¦¦¦ ¦ Синонимы : Начальный объем : ¦¦¦¦ ¦ Средний объем : 90000 ¦¦¦¦ ¦ Максимальн.объем: ¦¦¦¦ ¦ Годовой прирост%: ¦¦¦¦ ¦ ¦¦¦¦ ¦ --- ОПИСАНИЕ - ИМЕЕТ ЗНАЧЕНИЕ --------------------------- ¦¦¦¦ ¦ ¦¦¦¦ ¦ Составной части билета для указанного пассажира, связываю-¦¦¦¦ ¦ щей билет с рейсом, самолетом и классом имеющихся мест. ¦¦¦¦ ¦ Пассажир проходит оформление и получает посадочный талон ¦¦¦¦ ¦ на указанный рейс. ¦¦¦¦ ¦ ¦¦¦¦ ¦ --- АТРИБУТЫ -------------------------------------------- ¦¦¦¦ ¦ ¦¦¦¦ ¦ Имя : КОНТРОЛЬНОЕ ВРЕМЯ Домен : ¦¦¦¦ ¦ Необязательн.: Y Формат : TIME Длина : 4 ¦¦¦¦ ¦ Имя : КОММЕНТАРИИ Домен : ¦¦¦¦ ¦ Необязательн.: Y Формат : CHAR Длина : 20 ¦¦¦¦ ¦ Имя : ИНДИКАТОР ПОДТВЕРЖДЕНИЯ Домен : INDICATOR ¦¦¦¦ ¦ Необязательн.: Y Формат : CHAR Длина : 1 ¦¦¦¦ ¦ Имя : ОКОНЧАТЕЛЬНОЕ КОНТРОЛЬН.
ВРЕМЯ Домен : ¦¦¦¦ ¦ Необязательн.: Y Формат : TIME Длина : 4 ¦¦¦¦ ¦ Имя : СТАТУС Домен : ¦¦¦¦ ¦ Необязательн.: Y Формат : CHAR Длина : 1 ¦¦¦¦ ¦ ¦¦¦¦ ¦ * - Атрибуты в первичном уникальном идентификаторе ¦¦¦¦ ¦ ¦¦¦¦ ¦ --- СВЯЗИ ----------------------------------------------- ¦¦¦¦ ¦ ¦¦¦¦ ¦ КАЖДОЕ ВХОЖДЕНИЕ ЭТОЙ СУЩНОСТИ : ¦¦¦¦ ¦ ¦¦¦¦ ¦ ДОЛЖНО быть для ОДНОГО И ТОЛЬКО ОДНОГО КЛАССА МЕСТ ¦¦¦¦ ¦ ДОЛЖНО входить в ОДИН И ТОЛЬКО ОДИН БИЛЕТ * ¦¦¦¦ ¦ ДОЛЖНО быть открыто ОДНОГО И ТОЛЬКО ОДНОГО ¦¦¦¦ ¦ для АВИАМАРШРУТА * ¦¦¦¦ ¦ ИЛИ ¦¦¦¦ ¦ ДОЛЖНО быть для ОДНОГО И ТОЛЬКО ОДНОГО РЕЙСА * ¦¦¦¦ ¦ ¦¦¦¦ ¦ * - Связи в первичном уникальном идентификаторе ¦¦+- ¦ ¦+- ¦ --- ЗАМЕЧАНИЯ ------------------------------------------- +- L------------------------------------------------------------ ------------------------------------------------------------¬ -+----------------------------------------------------------¬¦ -+----------------------------------------------------------¬¦¦ ¦ Date: 29-SEP-89 ORACLE: CASE*Dictionary Page: 3 ¦¦¦ ¦ ¦¦¦ ¦ DETAILED ENTITY DEFINITION ¦¦¦ ¦ ¦¦¦ ¦ Entity Name: AIRLINE ROUTE Application: ATBS ¦¦¦ ¦ Version : 1 ¦¦¦ ¦ ¦¦¦ ¦ Sub-type of: Reference : ROUTE ¦¦¦ ¦ ¦¦¦ ¦ Synonyms : Initial Volume: ¦¦¦ ¦ Average Volume: 50 ¦¦¦ ¦ Maximum Volume: ¦¦¦ ¦ Annual Growth%: 5 ¦¦¦ ¦ ¦¦¦ ¦ --- DESCRIPTION - HAS SIGNIFICANCE AS ------------------- ¦¦¦ ¦ ¦¦¦ ¦ A standard route flown by an airline on an approved ¦¦¦ ¦ schedule. ¦¦¦ ¦ ¦¦¦ ¦ --- ATTRIBUTES ------------------------------------------ ¦¦¦ ¦ ¦¦¦ ¦ Name : BOOKABLE SEATS INDICATOR Domain : INDICATOR ¦¦¦ ¦ Opt : N Format : CHAR Length : 1 ¦¦¦ ¦ Name : FLIGHT NUMBER Domain : ¦¦¦ ¦ Opt : N Format : CHAR Length : 6 ¦¦¦ ¦ Name : STANDARD FARE Domain : ¦¦¦ ¦ Opt : N Format : MONEY Length : 6.2 ¦¦¦ ¦ Name : STANDARD FARE CURRENCY Domain : CHAR CODE ¦¦¦ ¦ Opt : N Format : CHAR Length : 3 ¦¦¦ ¦ Name : DEPARTURE DAY Domain : ¦¦¦ ¦ Opt : Y Format : CHAR Length : 12 ¦¦¦ ¦ Name : REFRESHMENT TYPE Domain : CHAR CODE ¦¦¦ ¦ Opt : Y Format : CHAR Length : 3 ¦¦¦ ¦ Name : SCHEDULED ARRIVAL TIME Domain : ¦¦¦ ¦ Opt : Y Format : TIME Length : 4 ¦¦¦ ¦ Name : SCHEDULED DEPARTURE TIME Domain : ¦¦¦ ¦ Opt : Y Format : TIME Length : 4 ¦¦¦ ¦ ¦¦¦ ¦ * - Attributes in primary unique identifier ¦¦¦ ¦ ¦¦¦ ¦ --- RELATIONSHIPS --------------------------------------- ¦¦¦ ¦ ¦¦¦ ¦ EACH OCCURRENCE OF THIS ENTITY : ¦¦¦ ¦ ¦¦¦ ¦ MUST BE operated by ONE AND ONLY ONE AIRLINE * ¦¦¦ ¦ MUST BE to ONE AND ONLY ONE AIRPORT ¦¦¦ ¦ MUST BE from ONE AND ONLY ONE AIRPORT ¦¦¦ ¦ MUST BE specific to ONE AND ONLY ONE PERIOD ¦¦¦ ¦ MAY BE normally ONE AND ONLY ONE AIRCRAFT TYPE ¦¦¦ ¦ serviced by ¦¦¦ ¦ MAY BE referenced on ONE OR MORE COUPONS ¦+- ¦ +- L------------------------------------------------------------ ------------------------------------------------------------¬ -+----------------------------------------------------------¬¦ -+----------------------------------------------------------¬¦¦ ¦ Дата: 28-SEP-89 ORACLE: CASE*Dictionary Стр.: 3 ¦¦¦ ¦ ¦¦¦ ¦ ДЕТАЛИЗИРОВАННОЕ ОПРЕДЕЛЕНИЕ СУЩНОСТИ ¦¦¦ ¦ ¦¦¦ ¦ Имя сущности: АВИАМАРШРУТ Прикладная система: ATBS ¦¦¦ ¦ Версия : 1 ¦¦¦ ¦ ¦¦¦ ¦ Супертип : Ссылка : МАРШРУТ ¦¦¦ ¦ ¦¦¦ ¦ Синонимы : Начальный объем : ¦¦¦ ¦ Средний объем : 50 ¦¦¦ ¦ Максимальн.объем: ¦¦¦ ¦ Годовой прирост%: 5 ¦¦¦ ¦ ¦¦¦ ¦ --- ОПИСАНИЕ - ИМЕЕТ ЗНАЧЕНИЕ --------------------------- ¦¦¦ ¦ ¦¦¦ ¦ Стандартного маршрута, выполняемого авиалинией по утверж- ¦¦¦ ¦ денному расписанию. ¦¦¦ ¦ ¦¦¦ ¦ --- АТРИБУТЫ -------------------------------------------- ¦¦¦ ¦ ¦¦¦ ¦ Имя : ИНДИКАТОР НАЛИЧИЯ МЕСТ Домен : INDICATOR ¦¦¦ ¦ Необязательн.: N Формат : CHAR Длина : 1 ¦¦¦ ¦ Имя : НОМЕР РЕЙСА Домен : ¦¦¦ ¦ Необязательн.: N Формат : CHAR Длина : 6 ¦¦¦ ¦ Имя : СТАНДАРТНАЯ СТОИМОСТЬ Домен : ¦¦¦ ¦ Необязательн.: N Формат : MONEY Длина : 6.2 ¦¦¦ ¦ Имя : ВИД ВАЛЮТЫ Домен : CHAR CODE ¦¦¦ ¦ Необязательн.: N Формат : CHAR Длина : 3 ¦¦¦ ¦ Имя : ДЕНЬ ОТПРАВЛЕНИЯ Домен : ¦¦¦ ¦ Необязательн.: Y Формат : CHAR Длина : 12 ¦¦¦ ¦ Имя : ТИП ОБСЛУЖИВАНИЯ Домен : CHAR CODE ¦¦¦ ¦ Необязательн.: Y Формат : CHAR Длина : 3 ¦¦¦ ¦ Имя : ВРЕМЯ ПРИБЫТИЯ ПО РАСПИСАНИЮ Домен : ¦¦¦ ¦ Необязательн.: Y Формат : TIME Длина : 4 ¦¦¦ ¦ Имя : ВРЕМЯ ОТПРАВЛЕНИЯ ПО РАСПИСАН.
Домен : ¦¦¦ ¦ Необязательн.: Y Формат : TIME Длина : 4 ¦¦¦ ¦ ¦¦¦ ¦ * - Атрибуты в первичном уникальном идентификаторе ¦¦¦ ¦ ¦¦¦ ¦ --- СВЯЗИ ----------------------------------------------- ¦¦¦ ¦ ¦¦¦ ¦ КАЖДОЕ ВХОЖДЕНИЕ ЭТОЙ СУЩНОСТИ : ¦¦¦ ¦ ¦¦¦ ¦ ДОЛЖНО обслуживаться ОДНОЙ И ТОЛЬКО ОДНОЙ АВИАЛИНИЕЙ * ¦¦¦ ¦ ДОЛЖНО быть в ОДИН И ТОЛЬКО ОДИН АЭРОПОРТ ¦¦¦ ¦ ДОЛЖНО быть из ОДНОГО И ТОЛЬКО ОДНОГО АЭРОПОРТА ¦¦¦ ¦ ДОЛЖНО быть связано с ОДНИМ И ТОЛЬКО ОДНИМ ПЕРИОДОМ ¦¦¦ ¦ МОЖЕТ обычно ОДНИМ И ТОЛЬКО ОДНИМ ТИПОМ САМОЛЕТА ¦¦¦ ¦ обслуживаться ¦¦¦ ¦ МОЖЕТ указываться на ОДНОМ И БОЛЕЕ КУПОНАХ ¦+- ¦ +- L------------------------------------------------------------ ------------------------------------------------------------¬ -+----------------------------------------------------------¬¦ ¦ Date: 29-SEP-89 ORACLE: CASE*Dictionary Page: 4 ¦¦ ¦ ¦¦ ¦ DETAILED ENTITY DEFINITION ¦¦ ¦ (CONTINUATION) ¦¦ ¦ Entity Name: AIRLINE ROUTE Application: ATBS ¦¦ ¦ Version : 1 ¦¦ ¦ ¦¦ ¦ Sub-type of: Reference : ROUTE ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ --- RELATIONSHIPS --------------------------------------- ¦¦ ¦ ¦¦ ¦ EACH OCCURRENCE OF THIS ENTITY : ¦¦ ¦ ¦¦ ¦ MAY BE covered by ONE OR MORE NORMAL CREW ¦¦ ¦ MEMBERSHIPS ¦¦ ¦ MAY BE scheduled as ONE OR MORE SCHEDULED FLIGHTS ¦¦ ¦ MAY BE additionally ONE OR MORE STANDARD CREW ¦¦ ¦ serviced by MEMBERSHIPS ¦¦ ¦ MAY BE normally serviced by ONE AND ONLY ONE ¦¦ ¦ ¦¦ ¦ * - Relationships in primary unique identifier ¦¦ ¦ ¦¦ ¦ --- NOTES AND REMARKS ----------------------------------- ¦¦ ¦ ¦¦ ¦ --------------------------------------------------------- ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ +- L------------------------------------------------------------ ------------------------------------------------------------¬ -+----------------------------------------------------------¬¦ ¦ Дата: 28-SEP-89 ORACLE: CASE*Dictionary Стр.: 4 ¦¦ ¦ ¦¦ ¦ ДЕТАЛИЗИРОВАННОЕ ОПРЕДЕЛЕНИЕ СУЩНОСТИ ¦¦ ¦ (ПРОДОЛЖЕНИЕ) ¦¦ ¦ Имя сущности: АВИАМАРШРУТ Прикладная система: ATBS ¦¦ ¦ Версия : 1 ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ --- СВЯЗИ ----------------------------------------------- ¦¦ ¦ ¦¦ ¦ КАЖДОЕ ВХОЖДЕНИЕ ЭТОЙ СУЩНОСТИ : ¦¦ ¦ ¦¦ ¦ МОЖЕТ обслуживаться ОДНОЙ И БОЛЕЕ ДОЛЖНОСТЯМИ В ¦¦ ¦ ОБЫЧНОМ ЭКИПАЖЕ ¦¦ ¦ МОЖЕТ планироваться ОДИН И БОЛЕЕ РЕЙСОВ ¦¦ ¦ как ¦¦ ¦ МОЖЕТ дополнительно ОДНУ И БОЛЕЕ ДОЛЖНОСТЕЙ В ¦¦ ¦ определять СТАНДАРТНОМ ЭКИПАЖЕ¦¦ ¦ ¦¦ ¦ * - Связи в первичном уникальном идентификаторе ¦¦ ¦ ¦¦ ¦ --- ЗАМЕЧАНИЯ ------------------------------------------- ¦¦ ¦ ¦¦ ¦ --------------------------------------------------------- ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ ¦¦ ¦ +- L------------------------------------------------------------ ------------------------------------------------------------¬ ¦ Date: 29-SEP-89 ORACLE: CASE*Dictionary Page: 5 ¦ ¦ ¦ ¦ DETAILED ENTITY DEFINITION ¦ ¦ ¦ ¦ Entity Name: CREW ASSIGNMENT Application: ATBS ¦ ¦ Version : 1 ¦ ¦ ¦ ¦ Sub-type of: Reference : CREW ASS¦ ¦ ¦ ¦ Synonyms : Initial Volume: ¦ ¦ Average Volume: 85000 ¦ ¦ Maximum Volume: ¦ ¦ Annual Growth%: ¦ ¦ ¦ ¦ ¦ ¦ --- DESCRIPTION - HAS SIGNIFICANCE AS ------------------- ¦ ¦ ¦ ¦ An allocation of a person, who must be an existing member ¦ ¦ of a crew, to either a complete flight or a component of ¦ ¦ a flight.
Each assignment is within the context of a ¦ ¦ specific crew role, which may differ from their normal ¦ ¦ crew role. Eg A captain acting as a second pilot. ¦ ¦ ¦ ¦ --- ATTRIBUTES ------------------------------------------ ¦ ¦ ¦ ¦ Name : DATE CANCELLED Domain : ¦ ¦ Opt : Y Format : DATE Length : ¦ ¦ Name : DATE MADE Domain : ¦ ¦ Opt : Y Format : DATE Length : ¦ ¦ Name : SPECIAL DUTY Domain : ¦ ¦ Opt : Y Format : CHAR Length : 80 ¦ ¦ ¦ ¦ * - Attributes in primary unique identifier ¦ ¦ ¦ ¦ --- RELATIONSHIPS --------------------------------------- ¦ ¦ ¦ ¦ EACH OCCURRENCE OF THIS ENTITY : ¦ ¦ ¦ ¦ MUST BE in ONE AND ONLY ONE CREW ROLE ¦ ¦ MUST BE of ONE AND ONLY ONE PERSON * ¦ ¦ ¦ ¦ MUST BE to ONE AND ONLY ONE FLIGHT * ¦ ¦ OR ¦ ¦ MUST BE to ONE AND ONLY ONE FLIGHT COMPONENT * ¦ ¦ ¦ ¦ * - Relationships in primary unique identifier ¦ ¦ ¦ ¦ --- NOTES AND REMARKS ----------------------------------- ¦ ¦ ¦ ¦ --------------------------------------------------------- ¦ ¦ ¦ L------------------------------------------------------------ ------------------------------------------------------------¬ ¦ Дата: 01-AUG-89 ORACLE: CASE*Dictionary Стр.: 5 ¦ ¦ ¦ ¦ ДЕТАЛИЗИРОВАННОЕ ОПРЕДЕЛЕНИЕ СУЩНОСТИ ¦ ¦ ¦ ¦ Имя сущности: НАЗНАЧЕНИЕ В Прикладная система: ATBS ¦ ¦ ЭКИПАЖ Версия : 1 ¦ ¦ ¦ ¦ Супертип : Ссылка : ЭКИПАЖ ¦ ¦ ¦ ¦ Синонимы : Начальный объем : ¦ ¦ Средний объем : 85000 ¦ ¦ Максимальн.объем: ¦ ¦ Годовой прирост%: ¦ ¦ ¦ ¦ ¦ ¦ --- ОПИСАНИЕ - ИМЕЕТ ЗНАЧЕНИЕ --------------------------- ¦ ¦ ¦ ¦ Назначения личности, являющейся членом экипажа, либо на ¦ ¦ весь рейс, либо на его часть.
Каждое назначение произво- ¦ ¦ дится в контексте конкретной роли, выполняемой в экипаже, ¦ ¦ которая может отличаться от обычной роли члена экипажа. ¦ ¦ Так, например, командир может действовать в качестве вто- ¦ ¦ рого пилота. ¦ ¦ ¦ ¦ --- АТРИБУТЫ -------------------------------------------- ¦ ¦ ¦ ¦ Имя : ДАТА ОТМЕНЫ Домен : ¦ ¦ Необязательн.: Y Формат : DATE Длина : ¦ ¦ Имя : ДАТА ПРОИЗВОДСТВА Домен : ¦ ¦ Необязательн.: Y Формат : DATE Длина : ¦ ¦ Имя : ОСОБАЯ ОБЯЗАННОСТЬ Домен : ¦ ¦ Необязательн.: Y Формат : CHAR Длина : 80 ¦ ¦ ¦ ¦ * - Атрибуты в первичном уникальном идентификаторе ¦ ¦ ¦ ¦ --- СВЯЗИ ----------------------------------------------- ¦ ¦ ¦ ¦ КАЖДОЕ ВХОЖДЕНИЕ ЭТОЙ СУЩНОСТИ : ¦ ¦ ¦ ¦ ДОЛЖНО быть на ОДНУ И ТОЛЬКО ОДНУ РОЛЬ В ЭКИПАЖЕ ¦ ¦ ДОЛЖНО быть для ОДНОЙ И ТОЛЬКО ОДНОЙ ЛИЧНОСТИ * ¦ ¦ ¦ ¦ ДОЛЖНО производиться ОДНОГО И ТОЛЬКО ОДНОГО РЕЙСА * ¦ ¦ для ¦ ¦ ИЛИ ¦ ¦ ДОЛЖНО производиться ОДНОЙ И ТОЛЬКО ОДНОЙ ЧАСТИ РЕЙСА * ¦ ¦ для ¦ ¦ ¦ ¦ * - Связи в первичном уникальном идентификаторе ¦ ¦ ¦ ¦ --- ЗАМЕЧАНИЯ ------------------------------------------- ¦ ¦ ¦ ¦ --------------------------------------------------------- ¦ ¦ ¦ L------------------------------------------------------------
J. МОДЕЛИ ДРУГИХ ТИПОВ
МВМС является средством, которое используется многими методологиями проектирования; однако, понятия, которыми оно манипулирует, изображаются на схемах часто по-разному. Все альтернативные способы представления мы не в состоянии охватить, но некоторые мы приведем в качестве иллюстрации выдвинутого положения.
Сначала повторим одну из схем, уже встречавшуюся в книге, а затем представим ее альтернативными способами.
Рисунок J-1. Модель заказа и его строк, построенная с учетом принятых в CASE*Method'е соглашений
Рисунок J-2. Модель SSADM (методология проектирования систем на базе структурного анализа)
Легко заметить, что связи типа "один ко многим", как и исключающие дуги, выглядят так же. В то же время подтипы, уникальные идентификаторы и непереносимые связи не представлены вообще. На мысль о подтипах наводит исключающая дуга, покрывающая связи сущности ЗАКАЗ.
Используемые "ролевые" атрибуты указывают на способ осуществления связи; например, номер заказа, повторенный у сущности СТРОКА, ОПИСЫВАЮЩАЯ ПРОДУКТ, отражает связь последней с сущностью ЗАКАЗ.
Рисунок J-3. Модель IEM (методология информационного проектирования)
Здесь указатель необязательности связи --o-- присутствует на противоположном конце (в отличие от CASE*Method'а). Символом --+-- обозначается конец связи со степенью "один".
CASE*Method по существу является методологией информационного проектирования, охватывающей большинство понятий МВМС и использующей различные соглашения.
Chen Model (Модель Чена) ---------------¬ n 1 ---------------¬ ¦СТРОКА, ОПИСЫ-+----------< описывает >-------+ ПРОДУКТ ¦ ¦ВАЮЩАЯ ПРОДУКТ+---¬ LT-------T------ L------T-------- ¦ ¦ ¦ ¦ ¦ ====¦ ---+---- ¦ 1 ¦ n << код >>< описание > ¦ ¦ ===== -------- ¦ ¦ 1 ---------------¬ < является > L------< описывает >-------+ УСЛУГА ¦ ¦ LT-------T------ ¦ ¦ ¦ ¦ 0 ====¦ ---+---- ¦ << код >>< описание > ¦ ===== -------- -------+-------¬ 0 1 ---------------¬ ¦СТРОКА ЗАКАЗА +----------< является >--------+ПРОЧАЯ СТРОКА ¦ LT----TT-------- ¦ ЗАКАЗА ¦ ¦ ¦¦ L--------------- ====¦== ¦¦ ^ << номер >>¦¦ n ¦ ======= ¦¦ ¦ ----¦ Сущность ------+- ¦ < описание >¦ -------- ¦ ¦ < содержит > <-------------------------------T- Связь ¦ 1 0 ¦ -------+-------T--------¬ ¦ ¦ ЗАКАЗ ¦ +-< включает > <------- L----T--------T+--------- ¦ ¦ n --+- =¦===== < дата > << номер >> ---- =======
В данной модели, хотя это и не видно на схеме, предполагаются не только бинарные связи (т.е. связи, имеющие строго два конца). Здесь, как и в методе Мерайза (Merise), одна связь может соединять две, три и более сущностей, кроме того она может иметь свои собственные атрибуты.
В противоположность сущностям и связям, атрибуты изображаются в виде эллипсов, а уникальные идентификаторы, кроме того, обводятся двойной линией. Дабы не усложнять схему, часть атрибутов на ней пришлось опустить. Подтипы обозначаются бинарными связями типа "один к одному", исключительность и непереносимость связей не показывается вообще.
Кредитная компания открывает счета либо
Кредитная компания открывает счета либо для частных лиц, либо для организаций, которые в свою очередь выдают карточки своим служащим. Компания выпускает в обращение карточки трех различных типов, с различными лимитами (предельными суммами), условиями платежа и др. условиями.
С каждым счетом, будь то счет частного лица или организации, может быть связано множество карточек. Необходимо знать, кто является владельцем каждой из них. Физически это решается путем указания на карточке имени ее владельца (держателя) в сочетании с номером счета и датой истечения срока действия.
Допустим, что у вас есть счет, с карточками - для вас и вашей супруги. У вас может также быть карточка со счетом вашей организации (постарайтесь не вводить ее в смущение своими расходами на развлечения!).
У вашей супруги может быть даже и третий счет с карточками как для вас, так и для ваших детей - с очень низкой предельной суммой. Мудрая предосторожность, не так ли?
Кредитной компании нужно знать, кому принадлежат счета, на кого оформлялись карточки и сколько карточек различных типов закреплено за счетами частных лиц и организаций.
В целях создания модели приступим к анализу понятий и поиску сущностей, атрибутов и связей.
Первый параграф примера
Кредитная компания открывает счета либо для частных лиц, либо для организаций, которые в свою очередь выдают карточки своим служащим. Компания выпускает в обращение карточки трех различных типов, с различными лимитами (предельными суммами), условиями платежа и др. условиями.
В этом параграфе можно обнаружить несколько важных понятий. Представим их в виде существительных единственного числа:
компания (организация)
счет
частное лицо
карточка (или лучше сказать, кредитная карточка)
служащий.
Все эти понятия можно считать сущностями.
В параграфе нам встретились и некоторые другие понятия и выражения:
тип карточки
лимит
условие платежа
прочее условие.
Возможно, что часть из них является атрибутами, поскольку позволяет описывать другие объекты.
Попытаемся связать их с сущностями.
Является ли " тип карточки" атрибутом карточки или самостоятельной сущностью? Если это сущность, то она должна представлять собой важный объект, информация о котором подлежит выяснению или запоминанию. В этом случае это так, поскольку "лимит" и "условие платежа" являются атрибутами "типа карточки". Экземпляром ТИПА КАРТОЧКИ будет такой тип, у которого лимит равен двумстам долларов, а условие платежа требует полного расчета по окончании месяца - идеальный тип для моих детей, каждому из которых пригодилась бы подобная карточка.
Какие при этом возможны связи? Они обнаруживаются в нескольких парах сущностей по следующим фразам:
КОМПАНИЯ открывает СЧЕТА
СЧЕТ либо для ЧАСТНОГО ЛИЦА, либо для КОМПАНИИ
КОМПАНИЯ... своим СЛУЖАЩИМ.
КОМПАНИЯ появляется дважды - один раз как кредитная, а второй раз как организация-клиент кредитной компании. Предположим, что кредитная компания - просто контекст для данного примера и ею можно пренебречь.
Обратите внимание на фразу "либо..., либо...", появляющуюся в ситуации со СЧЕТАМИ. Для того, чтобы перенести ее на модель, нам потребуется новое соглашение - т.н. "исключающая связь", которая на схеме изображается в виде двух перечеркнутых одной дугой линий связи:
Рисунок 4-1. Исключающая дуга
Читается это так:
Каждый СЧЕТ должен быть либо для одного и только одного ЧАСТНОГО ЛИЦА, либо для одной и только одной КОМПАНИИ.
Эта небольшая подмодель, конечно, неполна, но на данном этапе полезна. На ней видна связь типа "многие к одному", существующая между СЧЕТАМИ (множеством) и КОМПАНИЕЙ (одной). Описание связи на другом конце пока отсутствует и будет получено при дальнейшей отладке.
Второй параграф
С каждым счетом, будь то счет частного лица или организации, может быть связано множество карточек. Необходимо знать, кто является владельцем каждой из них. Физически это решается путем указания на карточке имени ее владельца (держателя) в сочетании с номером счета и датой истечения срока действия.
Рассмотрим следующие понятия:
счет частного лица (персональный счет)
счет организации (компании)
владелец карточки.
Перечень возможных атрибутов:
имя владельца карточки
номер счета
дата истечения срока действия (короче: срок действия).
Перечень возможных связей:
КАРТОЧКИ... связаны с ПЕРСОНАЛЬНЫМ СЧЕТОМ
КАРТОЧКИ... связаны со СЧЕТОМ КОМПАНИИ
Эти связи имеют тип "многие к одному".
Остальные параграфы
Возможные сущности:
счет
карточка
супруга
компания-клиент (организация)
ребенок
кредитная компания
тип карточки.
Возможный атрибут:
·
очень низкая предельная сумма (лимит).
Возможные связи:
СЧЕТ с КАРТОЧКОЙ
КОМПАНИЯ имеет СЧЕТ
КАРТОЧКА для ВАС
СЧЕТ у СУПРУГИ
КАРТОЧКИ для ДЕТЕЙ
КАРТОЧКИ различных ТИПОВ.
Синтез
У нас теперь есть масса полезной информации. Чтобы обработать ее, обратимся к логике.
Сколько лиц может быть указано на карточке? Только одно - во всех случаях.
Может ли кто-то иметь больше одного счета? Не вижу причины, почему бы и нет.
Посмотрим еще раз на имена сущностей. Некоторые из них на самом деле представляют собой один и тот же класс объектов:
частное лицо
служащий
владелец карточки
супруга
ребенок.
Исключают ли они друг друга во всех ситуациях или же это все один и тот же объект? Если да, то нам придется ввести новое обобщающее понятие - в данном случае ЛИЧНОСТЬ. Остальные понятия представляют собой примеры или роли личности. Некоторые из этих понятий могут появиться позже в описаниях связей.
Потратим десять минут на построение модели взаимосвязей между сущностями.
Построив модель, проверьте ее вместе с вашими коллегами, используя известные соглашения, и добавьте дополнительные атрибуты. Если у вас есть кредитная карточка, то вам нетрудно будет составить их список:
дата начала действия
срок действия
дата выпуска
подпись.
Все остальное на карточке относится к связи или к типу карточки.
Как можно уникально идентифицировать карточку?
Сравните вашу черновую модель с представленной на следующей странице.
Пример, связанный с билетами на самолет
Главным овеществленным понятием, которое нас будет интересовать в путешествиях по воздуху, выступает в данном примере авиабилет, подтверждающий перелет из, ну скажем, Атлантии - столицы архипелага Атлантис - в Париж. Если посмотреть внимательно, можно заметить, что авиабилет состоит из купонов (отрывных талонов), каждый из которых соответствует перелету между двумя аэропортами. Выглядеть такой билет будет следующим образом:
Рисунок 2-1. Авиабилет
Билет состоит из двух купонов - один для перелета из Атлантии в Лондон, другой для перелета из Лондона в Париж. Третий лист содержит описание всего маршрута путешествия.
Рисунок 2-2. Купон к авиабилету
Начнем рассмотрение информационной области с выполняющего полет самолета.
Каждый самолет, как правило, за день выполняет несколько рейсов, однозначно определяемых датой и временем вылета, номером рейса и аэропортом отправления. Из номера рейса можно почерпнуть два указания: на авиакомпанию, обслуживающую полет (так "AIF" соответствует авиакомпании "Atlantis Island Flights"), и на маршрут, по которому выполняется полет. Отсюда нас будет интересовать, какими самолетами выполняются полеты, сколько продано билетов, какие рейсы получили подтверждение и какие места выделены для пассажиров.
Рисунок 2-3. Модель взаимосвязей для сущности "Билет"
Ядром такой системы выступает купон. Он означает примерно то же, что и наименьший общий делитель в математике, и ему присущи такие информационные характеристики, как класс и статус. Купон может существовать только при наличии (в контексте) авиабилета, от которого он наследует дату выписки и стоимость.
Каждый из блоков на Рисунке 2-3 заключает в себе сущность, а линия, соединяющая между собой блоки, соответствует связи между сущностями. Разветвляющееся окончание такой линии у левого блока и одинарное окончание у правого говорят о том, что у одного билета может быть много купонов; мы имеем дело со связью типа "многие к одному". Непрерывная линия говорит о том, что связь обязательная.
Связь может читаться слева направо:
Каждый КУПОН должен входить в один и только один БИЛЕТ и справа налево:
Каждый БИЛЕТ должен состоять из одного или более КУПОНОВ. Следует отметить, что выражение "должен" свидетельствует об обязательном характере связи.
А что можно сказать о рейсе ?
Рисунок 2-4. Связь между сущностями БИЛЕТ и РЕЙС
Теперь мы можем взглянуть на тот же купон, но уже по отношению к рейсу. Прочитаем связь между ними слева направо:
Каждый КУПОН должен оформляться для одного и только одного РЕЙСА и в обратном направлении:
Каждый РЕЙС может быть основанием для оформления одного и более КУПОНОВ.
Заметьте, что рейс может и не быть основанием для оформления купонов вообще! (Это видно из прерывистого характера соединяющей эти сущности линии, свидетельствующего о необязательности существующей между ними связи.) Причиной такого положения может быть, например, то, что рейс только что включен в расписание, или то, что купоны просто не поступали в продажу. В любом случае, связь между этими сущностями дает нам некоторую полезную информацию.
Теперь мы получили строгую связь между билетом и рейсом - через купон. Связь эта относится к типу "многие ко многим", что видно из следующего:
Каждый БИЛЕТ должен состоять из одного или более КУПОНОВ, каждый из которых оформляется на свой РЕЙС, и наоборот, каждый РЕЙС может быть основанием для оформления одного и более КУПОНОВ, каждый из которых должен входить в свой БИЛЕТ.
Другая полезная информация приводится внутри самих блоков, в виде т.н. атрибутов. Эти атрибуты как бы дополняют описание сущностей и интерпретируются следующим образом:
Каждый БИЛЕТ имеет дату выписки и стоимость.
Краткое резюме
Прежде чем продолжать, попробуем обобщить все, что мы уже узнали к этому моменту об изучаемом методе. Сущность изображается в виде блока, внутри которого заглавными буквами записывается имя сущности, а строчными - ее атрибуты. Две сущности могут быть связаны между собой, и мы наблюдали две подобные связи, имеющие тип "многие к одному" и графическое изображение:
Перейдем к расширению нашей модели.
Рисунок 2-5.
Модель, изображенная на рисунке 2-5, содержит уже достаточно информации для того, чтобы стать моделью авиабилета. Обратите внимание на то, что мы уже изобразили в виде блоков все объекты, упомянутые на билете. Нами добавлены блоки, соответствующие сущностям ПАССАЖИР, АЭРОПОРТ, АВИАЛИНИЯ и, пожалуй, наиболее сложной для понимания сущности АВИАМАРШРУТ.
Авиамаршрут однозначно идентифицируется номером рейса и курирующей его авиалинией. На билете ему соответствует составной код AIF213 или AIF217.
У нас появилась возможность прочитать всю схему относительно сущности АВИАЛИНИЯ:
Каждая АВИАЛИНИЯ может курировать один и более АВИАМАРШРУТОВ, каждый из которых может планироваться как один и более РЕЙСОВ, описываемых датой и временем вылета. В соответствии со схемой, каждый рейс должен выполняться по АВИАМАРШРУТУ (заранее определенному) и должен следовать из одного АЭРОПОРТА в другой.
Это общеупотребимый и обязательный набор правил. На приведенное утверждение можно посмотреть с двух разных углов.
Угол 1: Какие рейсы выполняются из аэропорта Атлантии любой из авиалиний? Эта информация обычно в первую очередь интересует вылетающих пассажиров.
Рисунок 2-6 . Отправление рейсов по аэропортам
|
Отправление Аэропорт: Атлантия |
||||
|
Авиалиния |
Номер рейса |
Отправление |
Место назначения |
|
|
дата |
время |
|||
|
BA AIF AIF BA TW |
962 213 004 964 51 |
3 Янв 89 3 Янв 89 3 Янв 89 3 Янв 89 3 Янв 89 |
07:30 08:00 08:15 09:00 09:15 |
Лондон Лондон Нью-Йорк Манчестер Чикаго |
Угол 2: Какие рейсы, отправляющиеся из Атлантии, выполняются авиалинией "Atlantis Island Flights"?
Эта информация используется компанией AIF для слежения за своими рейсами.
Рисунок 2-7. Отправление рейсов по авиалиниям
|
Отправление Авиалиния: Atlantia Island Flights (AIF) Аэропорт: Атлантия |
|||
|
Номер рейса |
Место назначения |
Отправление |
|
|
дата |
время |
||
|
213 004 009 |
Лондон LHR Нью-Йорк JFK Южный Остров AASI |
3 Янв 89 3 Янв 89 3 Янв 89 |
08:00 08:15 09:20 |
Другими словами, современные авиалинии должны иметь систему (автоматическую или неавтоматическую) для регистрации, выдачи и контроля информации, представленной на схеме.
Механизм создания схемы
В каждом случае, когда информация на билете или купоне ссылается на нечто из реального мира, мы создаем сущность, соответствующую этому нечто, оформляем ее в виде блока, записываем в нем заглавными буквами название, а строчными - атрибуты. Так, например, сущность АВИАЛИНИЯ имеет атрибут "код". При обнаружении связи между двумя сущностями мы соединяем их линией и делаем надписи, характеризующие степень участия сущности в этой связи.
В реальном мире для обозначения связей часто используются коды и названия. Так, например, на изображении купона к билету (Рисунок 2-2) код AIF указан в столбце, озаглавленном "Трансагентство", для обозначения связи с авиалинией "Atlantis Island Flights". На нашей схеме, однако, эта косвенная связь показана линиями, соединяющими сущности КУПОН, РЕЙС, АВИАМАРШРУТ и АВИАЛИНИЯ, а "AIF" - только значение атрибута "код" сущности АВИАЛИНИЯ.
Однако, на схеме еще пока отсутствует информация о самолете, подтверждении полета и выделении мест. Схема с этой информацией представлена на Рисунке 2-8.
Рассмотрим же информацию под тем углом, как она соотносится с сущностью САМОЛЕТ.
Каждый САМОЛЕТ может назначаться на один и более РЕЙСОВ с датой и временем вылета и
Каждый РЕЙС должен выполняться по стандартному АВИАМАРШРУТУ из одного АЭРОПОРТА в другой.
(В модели допускаются даже авиамаршруты, где аэропорт отправления совпадает с аэропортом назначения ! Это может пригодиться для тех пассажиров, кто получает удовольствие просто от двухчасового пребывания на борту Конкорда.)
При выделении мест каждый пассажир должен быть обеспечен местом на борту самолета. Эта задача решается с помощью посадочного талона, выписываемого на основании купона и могущего рассматриваться в качестве его синонима или второго наименования.
Каждый САМОЛЕТ может иметь одно и более МЕСТ, каждое из которых может выделяться на основании одного и более КУПОНОВ (или ПОСАДОЧНЫХ ТАЛОНОВ) на РЕЙС с определенной датой и временем вылета.
Обратите внимание на то, что мы связали билет с пассажиром и разрешили пассажиру иметь более одного билета одновременно.
Каждый билет должен предназначаться для одного и только одного ПАССАЖИРА, который, в свою очередь, может быть указан на одном и более БИЛЕТАХ.
Сущность ПАССАЖИР может пригодиться нам в дальнейшем, если мы захотим помочь авиалинии индивидуализировать свои услуги, т.е. учитывать предпочтения пассажира на занятие тех или иных мест.
В надежной системе необходимо обеспечить уникальность выписываемых посадочных талонов для каждого рейса, хотя до закрепления мест за пассажирами некоторое превышение количества продаваемых билетов считается нормой.
На основании посадочных талонов мы можем получить список пассажиров, принятых на борт самолета, что может пригодиться в каких -нибудь чрезвычайных обстоятельствах, а также в том случае, если за несколько минут до вылета пассажир еще не попал на борт. Можно представить в графическом виде, как эта информация будет отображаться в реальной системе.
Рисунок 2-8. Расширенная модель
Рисунок 2-9. Схема выделения мест
На рисунке представлен вариант экранной формы для настольной системы распределения мест на самолет. Она представляет собой как бы внутренний план самолета в графической форме - иллюстрацию взаимосвязи между местом и самолетом типа "многие к одному". Для отнесения места к типу "для курящих" или "для некурящих" используется штриховка; на нашей модели взаимосвязей между сущностями ей соответствует атрибут "признак разрешения курения" сущности МЕСТО.В нашем случае место D4 выбрано с помощью манипулятора "мышь"; в появившемся окне разрешен ввод или подтверждение сведений о пассажире. После заполнения полей окна можно нажатием клавиши "OK" закончить работу с ним.
и услуги являются вхождениями одной
Заказы
Рисунок 8-23. Классическая структура для заказов
Замечания:
На этой схеме продукты и услуги являются вхождениями одной и той же сущности.
Подтип ПРОЧАЯ СТРОКА ЗАКАЗА адресует нас к налогам, условиям поставки, комментариям и т.п. по данному заказу.
Модель позволяет отслеживать многоуровневую иерархию подзаказов, входящих в данный заказ (что имеет решающее значение для контроля).
Поставщик и покупатель выделены в отдельные сущности, что характерно для малого бизнеса. В более общем случае их следовало бы объединить, чтобы иметь возможность охватить и внутренние заказы.
Если учесть внутренние заказы, можно составить довольно интересный список возможных синонимов и примеров:
|
ЗАКАЗ |
Контракт Соглашение Лицензия Tребование Внутренний заказ |
|
ОСНОВНОЙ ЗАКАЗ |
Основной контракт Первоочередной контракт |
|
ПОДЧИНЕННЫЙ ЗАКАЗ |
Подконтракт Подзаказ |
|
Примеры |
Контракт на ремонт и обслуживание Соглашение об оказании услуг Контракт с фиксированной ценой Материальный контракт |
Другие документы
Попробуйте заменить на схеме слово ЗАКАЗ на слово ПОСТАВКА (или ЗАЯВКА). Возникнет необходимость в некоторых изменениях, но сама форма останется неизменной, поскольку воплощает основные принципы, заложенные в различных контролируемых документах.
Роли и занятия
Начнем с перечня примеров:
Роли - выполняющий заказы, покупатель, продавец, оказывающий первую помощь, руководитель проекта, лектор, поденщик.
Занятия - менеджер, клерк, торговый агент, монтер, сиделка, учитель, программист.
Замечания:
На схеме, которую мы разберем, типы ролей и занятий показаны отдельно друг от друга.
Тип занятия можно расширить таким образом, что он будет включать ранг и соответствующую оплату, полное описание обязанностей и т.п. Здесь мы только отделили ЦЕЛИ от ролей. На более детализированной модели можно произвести дифференциацию и внутри целей.
Мы предположили, что ДОГОВОР О НАЙМЕ имеет отношение только к ВНУТРЕННИМ ОРГАНИЗАЦИОННЫМ ЕДИНИЦАМ.
Заменив эту связь на связь с супертипом (ОРГАНИЗАЦИОННОЙ ЕДИНИЦЕЙ), мы сможем отслеживать занятия, выполняемые людьми одновременно, ныне, в прошлом и планирующиеся к выполнению в будущем.
Во многих странах вместо слов ДОГОВОР О НАЙМЕ используется НАЗНАЧЕНИЕ НА ДОЛЖНОСТЬ; то есть люди назначаются на должность (тип занятия) через официальное оформление договора о найме или без оного.
Рисунок 8-24. Классическая структура для ролей и занятий.
Продукты
Если мы объединим некоторые из предыдущих примеров, мы получим следующую схему для контроля за продуктами.
Рисунок 8-25. Классическая структура для продуктов и занятий
Модель подходит и для торгующей организации, рекламирующей узлы, состоящие из других продуктов (которые в свою очередь сами могут быть узлами).
Продукты имеют тенденцию со временем изменять свои цены, которые отражаются в строках прейскуранта. Прейскурант может быть составлен для какой-то одной компании, и если компания имеет иерархическую структуру, то тот же самый прейскурант распространяет свое действие на все организационные единицы, входящие в компанию.
Управленческая информация
Следующий пример иллюстрирует обработку информации, характеризующей некоторый крупный проект с точки зрения объемов и источников затрат. Концепция, о которой пойдет речь, применима во многих областях, в частности при составлении:
прогнозов
бюджетов
отчетов и сводок.
Схема, составленная нами, войдет в обобщенную модель.
Шаг 1
Рассмотрим проект, содержащий ряд прогнозов, которые в принципе могут пересматриваться.
Рисунок 8-26. Базовая структура
Шаг 2
Проект может включать в себя много разнотипных ограничений по использованию кадровых, финансовых и материальных ресурсов; например, данные различных прогнозов, бюджетов, прямых подсчетов и т.п. Некоторые из них могут иметь отношение к финансовым периодам, другие, возможно, нет.
Мы можем, таким образом, использовать подтипы (как это сделано ниже), но следует учесть, что предсказать все возможные подтипы, которые нам когда-нибудь пригодятся, довольно трудно.
Рисунок 8-27. Добавление подтипов и фактора времени
Шаг 3
Поэтому попробуем создать некоторую обобщающую сущность с именем ЭЛЕМЕНТ ПРОЕКТНОГО ПЛАНИРОВАНИЯ, выделив ТИП ПЛАНА, который может содержать столько вхождений, сколько нам будет нужно.
Рисунок 8-28. Использование новых сущностей для создания более универсальной структуры (структуры с более высоким уровнем обобщения)
Шаг 4
Чтобы продолжить классификацию прогнозов, бюджетов, планов и т.п., часто обращаются к типу используемого ресурса. Иногда даже доходят до конкретного вхождения; например, использование конкретного здания или компьютера. Все это можно увидеть на следующей схеме, где слово "редко" дополнительно характеризует новую связь.
Рисунок 8-29. Переход к ресурсам
Шаг 5
От планов перейдем к оценке фактического использования ресурсов. Для оценки можно воспользоваться такими материалами, как табели для персонала, документы по финансовым сделкам и различным механизмам распределения материальных ресурсов и имущества (например, наем помещений). При этом чаще идет речь о типах ресурсов, нежели о конкретных ресурсах.
Рисунок 8-30. Использование ресурсов
Шаг 6
Если нас интересует сведение фактических данных за конкретный период, модель станет еще более сложной.
Рисунок 8-31. Расширенная структура
Шаг 7
Единственный способ упростить модель (т.е. перейти на более высокий уровень обобщения) заключается в поиске сходства между связями и атрибутами, принадлежащими сущностям:
Элемент планирования
Использование и
Сводка по проекту
Таким образом, мы можем перейти к схеме, позволяющей вести обработку управленческой информации с учетом всевозможных обстоятельств. Сущность ПРОЕКТ можно заменить на сущность КУРС ОБУЧЕНИЯ, СЧЕТ или РАЗРАБОТКА ПРОДУКТА.
Рисунок 8-32. Обобщенная модель
Проблемное представление
Представляет собой концепцию, используемую для проверки модели, ее соотнесения с существующими системами и для упрощения процесса описания функций. Она также облегчает видение взаимной зависимости данных при поэтапной реализации системы.
Определение
Проблемное представление сущности охватывает атрибуты сущности и атрибуты всех других сущностей, имеющих к ней непосредственное отношение.
Или если говорить более точно, проблемное представление вхождения сущности включает в себя:
атрибуты данной сущности плюс
атрибуты сущностей, одно и только одно вхождение которых связано с данной, плюс
атрибуты других сущностей в цепочке (связанных той же связью, но опосредованно).
Если используется необязательная связь или дуга, все атрибуты, вытекающие из соответствующего пересечения (и последующие), тоже считаются необязательными. Если в одну и ту же сущность втекают несколько связей, имя (описание) связи используется в качестве уточняющего префикса.
Рисунок G-1. Модель, состоящая из простых компонент
Проблемное представление сущности КУПОН включает в себя:
|
КУПОН (текущая сущность) |
класс статус индикатор подтверждения комментарии | ||
|
РЕЙС |
дата вылета время вылета | ||
|
АВИАМАРШРУТ |
номер рейса время отправления по расписанию | ||
|
АВИАЛИНИЯ |
код название | ||
|
АЭРОПОРТ (из) |
код название | ||
|
АЭРОПОРТ (в) |
код название | ||
|
БИЛЕТ |
дата выписки стоимость вид валюты (денежная единица) | ||
|
ЛИЧНОСТЬ |
фамилия титул первая буква имени |
Обратите внимание на то, что поскольку между АВИАМАРШРУТОМ и АЭРОПОРТОМ существуют две связи, описания связей используются в качестве уточнения.
Вы еще убедитесь в том, что такое простое на первый взгляд представление оказывается полезным, когда встает задача двойной проверки бумажной документации, формата файлов и т.п.
Проблемное представление сущности РЕЙС:
|
РЕЙС |
дата вылета время вылета | ||
|
АВИАМАРШРУТ |
номер рейса время отправления по расписанию | ||
|
АВИАЛИНИЯ |
код название | ||
|
АЭРОПОРТ (из) |
код название | ||
|
АЭРОПОРТ (в) |
код название |
Расширение представления
Представление несколько усложняется, когда появляются подтипы, рекурсивные связи и исключающие дуги.
Рекурсивная связь, подразумевающая возможность пересчета атрибутов, обозначается многоточием (...). Если связь адресуется к подтипу, перейдите на уровень выше и продолжите формирование представления с супертипа. Если используются исключающие дуги, пройдите вдоль каждой из них по очереди.
Реальный пример построить сложно, поэтому воспользуемся следующей иллюстрацией:
Рисунок G-2. Модель, состоящая из более сложных компонент
Проблемное представление для каждого вхождения сущности A может быть либо таким:
|
A |
a1, a2, a3 |
(текущая сущность) |
|
C |
c1, c2, c3 |
|
|
D |
d1, d2, d3 |
(все необязательные) |
|
F |
f1, f2, f3 |
|
A |
a1,a2,a3 |
|
|
C |
c1,c2,c3 |
|
|
D |
d1,d2,d3 |
(все необязательные) |
|
E |
e1,e2,e3 |
|
|
E (компонента) |
e1,e2,e3... |
(все необязательные) |
Поименованные проблемные представления
Одна и та же сущность может быть объектом нескольких проблемных представлений, каждое из которых имеет свое подмножество атрибутов. Эти представления могут содержать информацию, группируемую по организационному или функциональному принципу. Тем не менее, часто наименования атрибутов и представление о них отличаются от их компромиссных определений, согласованных с пользователями. Для создания полной картины может возникнуть необходимость в дополнительных "производных атрибутах".
Обратимся вновь к примеру, который мы разобрали вначале, и выделим два поименованных проблемных представления.
Рисунок G-3.
Напомним еще раз проблемное представление сущности РЕЙС:
|
РЕЙС |
дата вылета время вылета |
|
АВИАМАРШРУТ |
номер рейса время отправления по расписанию |
|
АВИАЛИНИЯ |
код название |
|
АЭРОПОРТ (из) |
код название |
|
АЭРОПОРТ (в) |
код название |
Поскольку между АВИАМАРШРУТОМ и АЭРОПОРТОМ существуют две альтернативные связи, описания связей используются в качестве уточнения.
Теперь мы можем создать проблемное представление с именем РЕГУЛЯРНЫЙ РЕЙС и со следующей структурой:
Рисунок G-4.
В данном примере мы опустили четыре атрибута, принадлежавшие полному проблемному представлению, и изменили наименования некоторых других атрибутов.
Легко заметить, что вместо "Названия авиалинии" используется просто "Авиалиния" - такое использование имени сущности или синонима в качестве наименования атрибута является общим и привычным.
Термины "Место назначения" и "Исходный пункт" отражают назначение (роль) сущности АЭРОПОРТ, вытекающее из ее связей с сущностью АВИАМАРШРУТ.
Теперь мы можем составить определения функций, работающих с сущностью РЕГУЛЯРНЫЙ РЕЙС.
Пример 1
Установить номер рейса и дату вылета по расписанию для всех регулярных рейсов, отправляющихся из аэропорта "Хитроу" в мае 1989 года в одно место назначения более одного раза в день.
Пример 2
Второй пример иллюстрирует использование проблемного представления. Модель позволяет непосредственно получить следующее определение функции:
Создать по требованию вхождение сущности РЕЙС на определенную дату для конкретного АВИАМАРШРУТА, идентифицируемого номером рейса из АЭРОПОРТА отправления с определенным названием в АЭРОПОРТ назначения с определенным названием и обслуживаемого АВИАЛИНИЕЙ с соответствующим кодом, где: название АЭРОПОРТА отправления не совпадает с названием АЭРОПОРТА назначения.
С помощью проблемного представления РЕГУЛЯРНЫЙ РЕЙС это определение можно упростить:
Создать по требованию вхождение сущности РЕГУЛЯРНЫЙ РЕЙС, используя известные значения даты отправления по расписанию, номера рейса, времени вылета, авиалинии, места назначения и исходного пункта, где место назначения не совпадает с исходным пунктом.
С точки зрения пользователя последнее определение более понятно, хотя оно полностью охватывает связи, описанные в первом определении.Проблемное представление (и с этой точки зрения любое определение сущности) также учитывает все обеспечивающие целостность и согласованность ограничения, накладываемые на значения и обязательность атрибутов. Так, например, если атрибут является обязательным и имеет тип "дата", это означает, что его значение должно существовать и это значение должно иметь вид допустимой даты.
Таким образом, определение функции может стать еще короче: Создать по требованию вхождение сущности РЕГУЛЯРНЫЙ РЕЙС, в котором место назначения не совпадает с исходным пунктом.
Если используются производные атрибуты, например, количество купонов или прибыль от реализации билета, логика определения прикладной функции страдает от этого несильно.
Продолжение рассказа о компании "Atlantis Island Flights"
В целях обеспечения гибкости в обслуживании клиентов компания "Atlantis Island Flights" предоставляет своим клиентам возможность приобретения билетов с т.н. открытыми купонами. Это удобно для тех, кто регулярно летает по одному маршруту и желает иметь оплаченный вперед билет, которым можно было бы воспользоваться в любой день. Это также удобно в случае предварительного оформления билетов на обратную дорогу, если продолжительность поездки заранее неизвестна.
Рисунок 6-1. Билет с открытой датой вылета
Рейсы, таким образом, можно разбить на две категории - регулярные (по расписанию) и вне расписания.
Персоналу авиакомпании выделяются специальные билеты. Они выглядят как обычные билеты с открытой датой вылета, но имеют на купоне цветную полосу. По заведенному в компании порядку не более 10 ее сотрудников, включая 5 членов экипажей, могут путешествовать на любом рейсе в качестве пассажиров. Представляют интерес имена и должности этих сотрудников (на крайний случай). Специальные билеты не имеют стоимости, поскольку предоставляются от лица компании. Если те же сотрудники путешествуют как частные лица, для них сохраняются общие правила - их билеты содержат данные о полной стоимости, включая предусмотренную для персонала скидку. (Прочие виды скидок также время от времени имеют место в разных обстоятельствах.)
Члены экипажа строго проверяются - по уровню мастерства и составу выполняемых работ. На каждый пассажирский рейс составляется список членов экипажа, учитывающий только тип самолета.
Рисунок 6-2. Состав экипажа
На некоторые маршруты, например, с продолжительными перелетами, состав экипажа может быть расширен по сравнению с обычным рейсом.
В заключение отметим, что модель должна отражать рабочую нагрузку членов экипажа и включать в себя рейсы, на которых они выступают в качестве экипажа и в качестве пассажиров, помогая тем самым компании "Atlantis Island Flights" предупреждать опасность перенагрузки отдельных экипажей.
Производные атрибуты
Прежде чем завершить обзор принципов проектирования БД, имеет смысл вернуться к понятию "производный атрибут", введенному нами в Главе 7.
Основное правило, которого придерживаются проектировщики БД, состоит в том, что значение пересчитывается только тогда, когда в нем возникает необходимость. При этом нарушается другое правило - что атрибуты всегда становятся столбцами.
Но что делать в том случае, если к значению атрибута программы обращаются часто, а изменения происходят достаточно редко ? Необходимости в постоянном пересчете значения не будет, если мы создадим для производного атрибута столбец и будем корректировать его значение только тогда, когда оно изменится в действительности. Решающими условиями при выборе способа реализации, таким образом, станут:
редкая смена производного значения
существенность затрат по пересчету. Обычно это имеет место, когда пересчет затрагивает более одной строки БД.
Проверка полноты
Просмотрите всю документацию по существующей системе, все канцелярские формы, отчеты и т.п. Не удастся ли вам обнаружить такой элемент данных, который не является атрибутом и не может быть выведен из атрибутов, включенных в вашу модель, но должен быть охвачен? Добавьте в модель все обнаруженные сейчас, но пропущенные ранее атрибуты.
Распечатайте отчеты по CASE-проектированию и проверьте их вместе с вашими пользователями на предмет полноты.
Подготовьте проблемные представления для всех граничных сущностей. Соотносятся ли они с форматами существующих файлов? (См. Приложение G.)
Проверьте каждую элементарную функцию. Являются ли упоминаемые в ней сущности (явно или неявно - с помощью синонимов) известными вам? Не пропущены ли среди их атрибутов какие-нибудь логически связанные элементы данных? Нет ли каких-нибудь пропущенных связей?
Проверьте, не используются ли в функциональных блоках (иногда называемых "коммерческими единицами") какие-либо понятия, применимые только в определенных местах. Имеются ли данные об объемах информации, перерабатываемых функциональным блоком?
Реализация в базе данных
Рассмотрим в двух словах, как модель для сущностей КУПОН, МЕСТО и САМОЛЕТ может быть организована с помощью различных баз данных.
Реляционная база данных
В реляционной БД каждая сущность становится таблицей, а ее атрибуты - столбцами в таблице.
Рисунок 2-10. Реляционный проект
Столбцы с отметкой "**" используются для реализации связей между таблицами. Так, например, регистрационный номер самолета, включенный в таблицу SEAT, реализует связь между сущностями МЕСТО и САМОЛЕТ. Такой столбец именуют внешним ключом.
Выражение "not null" соответствует либо обязательной связи (которая на модели обозначается сплошной линией), либо обязательному атрибуту. Выражение "null" используется для обозначения либо необязательной связи (пунктирная линия), либо необязательного атрибута - "null" означает "значение может отсутствовать".
Сетевая база данных
В сетевой БД каждой сущности обычно соответствует запись. Каждой связи присваивается набор указателей NPO (Следующий, Предыдущий и Владелец). Записи, требующие доступа по ключу, располагаются с использованием алгоритма хэширования (CALC). Записи, которые на диске должны быть сгруппированы, требуют для своего размещения использования еще одной записи (VIA).
Символами "MA" на схеме обозначается обязательная автоматическая связь (Mandatory Automatic) - скажем, между записью "БИЛЕТ" и владельцем "САМОЛЕТ". Символы "OM" служат для обозначения необязательной связи.
Рисунок 2-11. Сетевой проект
Иерархическая база данных
В иерархической БД каждая сущность обычно изображается в виде записи с отражением иерархии всех ее взаимоотношений, существующих в модели. Записи располагаются в очередности "родитель-потомок", которой на модели соответствуют связи типа "один ко многим". Связи реализуются в виде некоторой комбинации логических (ключевых) или физических указателей. В случае обнаружения сетевого взаимодействия (пример: КУПОН появляется на самом нижнем уровне сразу трех иерархий) вводится понятие "виртуального логического потомка", связи которого указывают на реальную запись, находящуюся в другой иерархии:
Рисунок 2-12. Иерархический проект
Файл на языке КОБОЛ
Если используется алгоритмический язык КОБОЛ, запись САМОЛЕТ (AIRCRAFT) будет содержать повторяющуюся группу для сущности МЕСТО (SEAT):
Рисунок 2-13. Расположение полей в записи на КОБОЛе
Файл с ручной обработкой
Для того, чтобы картина была более полной, не стоит забывать, что большое количество информации в мире хранится в неавтоматических файловых (учетных) системах. На схеме представлена возможная реализация файла с данными о пассажирах в виде картотеки, хранящейся в бюро путешествий.
Рисунок 2-14. Регистрационный шкаф
Регистрация изменений (в прошлом и будущем)
Природа атрибута может со временем меняться; например, состояние контракта. Если принять во внимание время, можно найти такие значения атрибутов, которые характеризуют вхождение сущности на протяжении перекрывающихся интервалов времени; например, имена или псевдонимы личности. Связь также в то или иное время может относиться к разным вхождениям сущности; например, место жительства личности.
Все подобные проблемы решаются одинаково, а именно путем создания новой сущности, значениям которой соответствует интервал времени, когда они имеют место.
Изменение значений атрибутов
Рисунок 8-11. Атрибут "статус" становится сущностью
Если рассматривать СТАТУС в качестве уникального идентификатора, возникает несколько вопросов; например:
"Может ли контракт в течение одного дня находиться более чем в одном состоянии?"
Рисунок 8-12. Атрибут "фамилия" становится сущностью
Модель дает возможность сохранять информацию о всех возможных фамилиях (именах) личности, даже позволяя последней иметь несколько разных имен одновременно. Ничто не может помешать вам запомнить ту или иную фамилию на случай ее смены в результате женитьбы.
Однако модель не позволяет использовать одну и ту же фамилию в разные периоды жизни.
Изменение связей
Рисунок 8-13. Добавление новой сущности, учитывающей изменение связей
Модель позволяет каждой личности иметь имущественные договора одновременно на несколько жилищ. В свою очередь, место жительства хозяина (владельца) может быть установлено через договор. Обратите внимание на то, что в модели предусмотрено для каждого жилища не более одного хозяина - вы можете изменить это условие.
Рекурсивные связи
Многие к одному
Рисунок B-11. Обязательность на одном конце с необязательностью на другом
В принципе невозможна. Бесконечный цикл, не имеющий вершины.
Рисунок B-12. Обязательность на обоих концах
В принципе невозможна.
Рисунок B-13. Необязательность на одном конце с обязательностью на другом
В принципе невозможна.
Рисунок B-14. Необязательность на обоих концах
Довольно часто (см. ниже). Иногда называется "необязательное свиное ухо". Отражает наличие простой иерархии с любым числом уровней (организационная иерархия, классификация продуктов, структура рынка и т.п.).
Один к одному
Рисунок B-15. Обязательность на одном конце с необязательностью на другом
В принципе невозможна.
Рисунок B-16. Обязательность на обоих концах
В принципе невозможна.
Рисунок B-17. Необязательность на обоих концах
Редко, но имеет место. Отражает связи альтернативного типа.
Многие ко многим
Рисунок B-18. Необязательность на обоих концах
Имеет место на ранних этапах. Часто отражает структуру "перечня материалов" (взаимная вложенность компонент).
Пример:
Каждая КОМПОНЕНТА может состоять из одной и более (других) КОМПОНЕНТ и каждая КОМПОНЕНТА может использоваться в одной и более (других) КОМПОНЕНТАХ.
Рисунок B-19. Обязательность на одном конце с необязательностью на другом
В принципе невозможна.
Рисунок B-20. Обязательность на обоих концах
В принципе невозможна.
Сети
Сетевая структура очень часто имеет место на схемах взаимосвязей между сущностями.
Рисунок 8-9. Сетевая структура
В нашей структуре просматривается множество иерархий:
E/D/B/A
E/D/C/A
E/D/C/B/A
E/A
Каждая из иерархий связывает сущности E и A в сложную сеть, и можно пройти по всем путям, соединяющим экземпляры (вхождения) этих сущностей. Начиная с E, прямо перейдем ко всем вхождениям сущности A, для каждого из них найдем соответствующее C, а затем D и E.
| Шаг 1 | начать с E | ||
| Шаг 2 | выбрать все непосредственно связанные A | ||
| Шаг 3 | для каждого A выбрать соответствующее C и соответствующее тому D и соответствующее тому E (с этой точки вы можете перезапустить шаг 1) | ||
| Шаг 4 | также для каждого A выбрать соответствующее B, для которого либо выбрать соответствующее ему D и соответствующее тому E (еще одна точка рестарта) | ||
| Шаг 5 | либо выбрать соответствующее ему C и соответствующее тому D и соответствующее тому E (последняя точка рестарта) |
Рисунок 8-10. Элементарный пример сетевой структуры
Рассматривая этот пример, можно начать со служащего и найти ту организационную единицу, в которой этот служащий работает ныне, а затем отыскать того служащего, который этой организационной единицей в настоящее время руководит.
Если организационной единицей является отдел, можно найти ту организационную единицу, куда этот отдел ныне входит, и ее руководителя (и т.д. вверх по организационной иерархии). Ясно отсюда, что такую сеть можно использовать для всех случаев, когда нам нужно узнать, кто где работает.
Замечание: модель не учитывает многих обстоятельств, ибо не позволяет служащему работать более, чем в одном отделе, не запоминает перестановок (невосприимчива к изменениям), не допускает совмещения постов руководителей нескольких компаний или отделов и т.д.
Еще один интересный логический момент заключается в том, что вхождение сущности "организационная единица" не может существовать без служащего, руководящего его работой. И наоборот, вхождение сущности "служащий" не может существовать, если нет такой организационной единицы, которая была бы местом его работы. Ситуация, похожая на "курицу и яйцо" - что раньше?
Чтобы усовершенствовать эту модель, нам потребуются знания.
Схемная архитектура
Часто говорят о трехсхемной архитектуре. CASE-метод предполагает использование схемы взаимосвязей между сущностями в качестве информационной модели концептуального и прикладного уровня. Она может преобразовываться в логическую модель (как показано в Приложении F). Логическая модель обычно представляет собой нормализованную модель БД реляционного типа, не затрагивающую вопросы, связанные с доступом или использованием памяти.
Схема третьей формы появляется в результате проецирования логической модели на условия физической реализации, включающие в себя такие вопросы, как индексы, кластеризация данных, использование дискового пространства.
Следующие шаги
Значительная часть вышеописанных действий выполняется автоматически, по вашему желанию и под управлением CASE.
Но это только самое начало, поскольку проект БД требует тщательной проработки в направлении повышения эффективности использования ресурсов, создания возможностей для обработки нерегламентированных запросов, рационализации архивирования и т.п. Все это может потребовать проведения аккуратной денормализации, распределения ресурсов в сети, детализированного проектирования индексов и планирования дискового пространства.
Со всеми этими аспектами проектирования вам следует ознакомиться прежде, чем приступать к разработке моделей повышенной сложности.
Сущность
Определение сущности
Сущностью называется имеющее особый смысл, существующее в действительности или воображаемое явление или объект, информация о котором подлежит запоминанию или выяснению.
Рисунок 3-1. Сущность
Изображение сущности
На схемах сущность изображается в виде блока (прямоугольника с закругленными углами) с именем в середине. Именем может быть существительное единственного числа, записываемое заглавными буквами.
Блок может иметь любой размер и форму, так чтобы в нем могло уместиться точно выраженное имя сущности (старайтесь избегать сокращений), а также чтобы повысить читабельность схемы. Иногда, например, имеет смысл придавать блокам вытянутую форму, чтобы избегать пересечения линий связи на схеме.
Имена сущностей
Имя сущности может представлять тип или класс объекта, но не конкретное значение. В нашем примере именем сущности не могут стать ни "Хитроу", ни "Джон Ф. Кеннеди" - конкретные значения сущности АЭРОПОРТ.
В тех случаях, когда для именования сущности подходят разные слова, имеющие идентичный смысл в контексте данной проблемы, допускается использование синонимов. Одно имя назначается в качестве первого; синонимы могут записываться заглавными буквами с символом "наклонная черта" (/) перед каждым. Для облегчения понимания понятия и его отличий от других подобных понятий могут использоваться примеры.
Рисунок 3-2. Пример сущности
Фэйроукс - небольшой аэродром на юге Англии, на котором, однако, есть контрольно-диспетчерский пункт, таможенный досмотр, иммиграционная служба и т.п.
...ВЕРТОЛЕТ, который является разновидностью САМОЛЕТА, ...
Если сущность является и супертипом, и подтипом одновременно, используйте обе фразы:
...АЭРОПЛАН, который является разновидностью САМОЛЕТА и должен быть либо ПЛАНЕРОМ, либо УПРАВЛЯЕМЫМ АЭРОПЛАНОМ, ...
Проверка правильности задания подтипа
Если у подтипа нет своих отдельных атрибутов, связей или функций, в которых он используется, то спрашивается, какой же это подтип? Наверное, это просто синоним для чего-то еще.
Инвертированный синтаксис
Запишем утверждение наоборот, например:
...это означает, что аэроплан является разновидностью самолета во всех случаях и никогда не может быть классифицирован иначе, как планер или управляемый аэроплан. Так ли это?
Установление различий между подтипами
Для успешной работы с подтипами нужно располагать каким-нибудь методом, позволяющим отличать один подтип от другого. Существуют три стандартных метода:
На уровне реализации добавляется новый элемент данных, которому присваиваются значения, допустимые для каждого из возможных подтипов. Этот элемент данных можно назвать, например, ПОДТИП СУЩНОСТИ (в нашем случае ПОДТИП САМОЛЕТА).
На прикладном уровне вы можете завести атрибут, использующийся для той же цели. Так, например, атрибут "пол" со значениями "мужской" и "женский" дает нам два подтипа сущности ЛИЧНОСТЬ.
Так же на прикладном уровне вы можете составить комбинацию из атрибутов/связей и условий, накладываемых на их значения, которая будет определять подтипы.
Так, например, сущность ЗАКАЗ может иметь следующие три подтипа:
|
Подтип |
Описание условий и/или значений |
|
ОЖИДАЕМЫЙ ЗАКАЗ |
где индикатор подтверждения = no |
|
ПОДТВЕРЖДЕННЫЙ ЗАКАЗ |
где индикатор подтверждения = yes И дата выполнения неизвестна или находится в будущем |
|
ВЫПОЛНЕННЫЙ ЗАКАЗ |
где дата выполнения известна И = текущей или находится в прошлом |
Иногда бывает удобно иметь пересекающиеся или т.н. ортогональные подтипы; то есть, если имеется несколько способов разбиения сущностей на подмножества.
Это имеет смысл тогда, когда сущность может играть несколько ролей; например, такие сущности, как ЛИЧНОСТЬ или ОРГАНИЗАЦИОННАЯ ЕДИНИЦА.
Правила те же самые; за исключением того, что каждая совокупность подтипов должна иметь наименование и внутри каждой совокупности действует правило взаимного исключения.
Так, например, две совокупности подтипов для сущности ЛИЧНОСТЬ именуются ВИД ЗАНЯТОСТИ и ПОЛ.
Вхождение сущности ЛИЧНОСТЬ, идентифицируемое как СОСТОЯЩАЯ НА СЛУЖБЕ, имеет даты начала и окончания службы. ЛИЧНОСТЬ, идентифицируемая как ИСПОЛНЯЮЩАЯ ЗАКАЗЫ, имеет связь с ЗАКАЗЫВАЮЩЕЙ ОРГАНИЗАЦИОННОЙ ЕДИНИЦЕЙ, которая нанимает ее. Поскольку у нас возникают пересекающиеся подтипы, было бы удобнее каждой из совокупностей присвоить наименование. В нашем примере мы выбрали наименование ВИД ЗАНЯТОСТИ.
Рисунок 7-2. Совокупность подтипов ВИД ЗАНЯТОСТИ
В зависимости от значения атрибута "пол" вхождение сущности ЛИЧНОСТЬ относится к подтипу МУЖЧИНА или ЖЕНЩИНА. Для удобства этой совокупности подтипов присвоено наименование ПОЛ.
Рисунок 7-3. Совокупность подтипов ПОЛ
Поскольку подтипы пересекаются, имеет смысл для наглядности использовать, скажем, черный цвет для обозначения чаще других применяемой классификации и другие цвета для изображения других классификаций.
Следует заметить, что дополнительные правила, относящиеся к подтипам, накладывают ограничения на функции, создающие или корректирующие эти сущности, - ссылка делается уже на определение функции для подтипа вместо супертипа.
Функция "Создать вхождение с именем ИСПОЛНЯЮЩАЯ ЗАКАЗЫ" подразумевает инициализацию всех атрибутов, описанных для данного подтипа, а также всех атрибутов, унаследованных им от сущности ЛИЧНОСТЬ. Мы должны также предусмотреть связь с ЗАКАЗЫВАЮЩЕЙ ОРГАНИЗАЦИОННОЙ ЕДИНИЦЕЙ, которая нанимает ИСПОЛНЯЮЩУЮ ЗАКАЗЫ. Кроме того, у этого подтипа отсутствует атрибут "дата начала службы": этот атрибут присущ только подтипу СОСТОЯЩАЯ НА СЛУЖБЕ.
Справочная сущность
Термин "справочная сущность" используется для обозначения такой сущности, в которую не входит ни одна из обязательных линий связи. (Обычно на одной схеме таких сущностей набирается немного.) Эта сущность используется для дополнения описания других сущностей.
Сущности, описывающие тип объекта (например, ТИП САМОЛЕТА), зачастую выступают в качестве справочных сущностей, так же как и сущности, подобные ОРГАНИЗАЦИОННОЙ ЕДИНИЦЕ и ЛИЧНОСТИ. Вхождения справочной сущности могут существовать самостоятельно, безотносительно к другим объектам.
Граничная сущность
Граничной называется сущность, реализующая связь типа "многие ко многим" между двумя другими сущностями. Вхождения граничной сущности могут существовать только в контексте двух справочных сущностей.
Рисунок 7-4. Справочные и граничная сущности
Определение сущности
Для того, чтобы считать анализ информационного содержимого сущности завершенным, мы должны иметь следующее:
имя
множественное число
синонимы
объемы и, если возможно, темпы роста
описание
примечания/замечания,
а также все, что связано с этой сущностью:
атрибуты (по меньшей мере два)
связи (как минимум одну)
уникальный идентификатор (как минимум один)
функции, с которыми она связана (как минимум одна).
Полностью определение сущности описано в Приложении C.
Требования к распределенной обработке
В организации с децентрализованной структурой одна и та же сущность может использоваться по-разному. На этот случай определение должно включать в себя объемные характеристики каждой сущности по месту ее использования.
Детализация определения
Полное и детализированное определение вместе со всеми правилами показано в Приложении C, где приводятся стандартные формы, которые вам нужно заполнять.
Связь между сущностями
Определение связи
Связью мы назовем поименованное отношение, имеющее место между двумя сущностями.
Такая связь является бинарной, в том смысле что она имеет место между ровно двумя поименованными сущностями или же имеет вид отношения сущности к самой себе.
Каждая связь имеет два конца, каждый из которых обладает:
именем
степенью / мощностью
признаком обязательности.
Эти свойства используются для характеристики связи по отношению к каждой из участвующей в ней сторон.
Изображение связи
Связь изображается в виде линии между двумя блоками, каждый из которых соответствует определенной сущности, или, в случае рекурсивной связи, в виде линии, которая начинается и заканчивается на одном и том же блоке. Чаще всего связь имеет тип (степень) "многие к одному", является обязательной на конце "многие" и необязательной на конце "один".
Рисунок 3-3. Связь
На конце "многие" линия связи разветвляется и принимает вид "вороньей лапки", соприкасающейся с блоком сразу в трех точках. На конце "один" линия соприкасается с блоком ровно в одной точке.
Если на одном из концов связь обязательная, та часть линии, которая примыкает к этому концу, является сплошной. Если же связь необязательная, соответствующий фрагмент рисуется пунктиром.
Зачастую полезно бывает представить связь типа "один ко многим" как связь между родителем и потомком, при этом потомок в какой-то мере зависит от своих родителей.
Рекурсивная связь
Рекурсивная связь с идентичными свойствами изображается следующим образом:
Рисунок 3-4. Рекурсивная связь
Идентификация связей
Имя (а скорее, описание) для каждого конца связи подписывается возле него строчными буквами.
Рисунок 3-5. Идентификация связи
Если на одном из концов связь является обязательной, перед соответствующим описанием появляется выражение "должен"; для необязательных связей используется выражение "может".
Таким образом изображенная выше схема читается слева направо следующим образом:
Каждая СУЩНОСТЬ-A должна "описание-связи-1" одну и только одну СУЩНОСТЬ-B
а справа налево:
Каждая СУЩНОСТЬ-B может "описание-связи-2" одну и более СУЩНОСТЕЙ-A.
Все это может выглядеть несколько непонятно до тех пор, пока вы не обратитесь к реальному примеру:
Рисунок 3-6. Пример связи
Каждый БИЛЕТ должен предназначаться для одного и только одного ПАССАЖИРА и:
Каждый ПАССАЖИР может быть указан на одном и более БИЛЕТАХ.
Упоминание имени сущности во множественном числе имеет место в том случае, если степень связи имеет значение "многие". Такая связь читается как "одну и более", а связь, имеющая степень "один", читается как "одну и только одну".
При построении схем взаимосвязей между сущностями правильнее располагать блоки таким образом, чтобы "воронья лапка" в каждом конкретном случае примыкала к левому окончанию линии связи (при ее горизонтальном расположении) или к верхнему окончанию (при вертикальном расположении линии).
Дисциплина идентификации
Присвоение связям имен (описаний) на каждом конце помогает сократить избыточность связей, облегчает их понимание и способствует более быстрому обнаружению необходимости включения в схему дополнительных связей и сущностей.
Описание связи содержит тип отношения, имеющего место между двумя сущностями; под этот тип должны подходить все экземпляры (вхождения) данной связи. Все понятия в МВМС адресуются к типам, а не к экземплярам и вхождениям.
Формальный синтаксис
Для чтения любой связи используется следующий синтаксис:
Фразы "и любая" и "всегда" добавляются для придания утверждению большей строгости. Фраза "не так ли?" добавляется для проверки утверждения.
Если мы прочитаем связь БИЛЕТ/ПАССАЖИР снова, она станет яснее.
Каждый и любой БИЛЕТ должен предназначаться для одного и только одного ПАССАЖИРА всегда, не так ли ?
Это хороший вопрос, поскольку в данном утверждении предполагается, что компания не продает ни семейных, ни групповых билетов, а также билетов, в которых не упоминается личность пассажира.
Такое прочтение связей способствует возбуждению у аналитика сомнений и возражений, в частности по поводу того, всегда ли в прошлом рассматриваемое утверждение было истинно. При такой постановке модель может отражать все возникающие вопросы и способствовать их решению путем выбора оптимального проекта системы. Как оказалось, это может помочь и при возникновении многих проблем, являющихся следствием отсутствия сомнений, и снизить расходы по переделке.
Инвертированный синтаксис
Вышеприведенный синтаксис в большинстве случаев очень удобен, но в действительности может оказаться полезным и знание следующего синтаксиса:
Рисунок 3-7.
При использовании нормального синтаксиса связь читается так:
Каждый КУПОН должен оформляться на один и только один РЕЙС.
При использовании инвертированного синтаксиса:
Это означает, что вы не можете иметь КУПОН, которому бы не соответствовал уникально определенный РЕЙС, не так ли?
Слово "любой" мы заменили вопросительной фразой, а выражение "один и только один" свели к "уникально определенному".
Вопрос и здесь получился корректным, ибо в модели не допускается использование КУПОНА, которому бы не соответствовал определенный рейс на определенную дату. Однако в реальной жизни существуют билеты с открытой датой, у которых купоны не содержат точную дату вылета, поэтому характеристику связи необходимо изменить на "необязательную".
Разрешенные связи
Не все связи, которые пользователь пожелал бы изобразить, являются разрешенными (допустимыми) или имеют место достаточно часто. Рассмотрим наиболее общие разрешенные формы связей.
Рисунок 3-8. Разрешенные формы связей
Теперь рассмотрим примеры неразрешенных связей, отражающих состояния, которые невозможны в действительности.
Рисунок 3-9.Неразрешенные формы связей
Дополнительные соглашения и правила, касающиеся связей, рассматриваются в главе 7. Исчерпывающий перечень разрешенных и неразрешенных форм связей приводится в Приложении B.
Связи
Разделение отношения "многие ко многим"
Связи типа "многие ко многим" широко используются на этапе выработки стратегии и даже в самом начале этапа анализа. Но к концу этого этапа все они должны быть разделены, если только они не представляют двунаправленного списка данных. Такое разделение реализуется посредством вставки новой граничной сущности между двумя сущностями, связанными отношением "многие ко многим".
Рисунок 7-5. Разделение связи типа "многие ко многим" через добавление граничной сущности
Вновь созданная сущность должна иметь имя; зачастую при выборе имени используются описания подлежащей разделению связи. Как вы поняли, построенная модель позволяет следить за обслуживанием самолетов. Атрибуты новой сущности и ее связи с другими сущностями добавляются по известной схеме.
Понятие исключительности
Две и более связей, в которых принимает участие одна и та же сущность, могут быть взаимно исключающими.
Представление
На схеме исключительность обозначается дугой, пересекающей каждую из взаимно исключающих связей данной сущности, с выделением места пересечения.
Рисунок 7-6. Исключающая дуга
Место пересечения может быть жирно обведено, и тогда простое пересечение дугой одной из линий связи будет говорить о том, что эта связь не вступает с другими связями, пересеченными той же дугой, в отношение взаимного исключения. Другой способ представления показан на Рисунке 7-8.
Рисунок 7-8
Если с одной и той же сущностью связано несколько исключающих дуг, для наглядности представления изображайте их на расстоянии друг от друга (Рисунок 7-9).
Правила
Дуги могут связывать только однотипные концы связей, т.е. такие, которые либо все обозначают обязательную связь, либо все обозначают необязательную связь.
Конец связи может участвовать только в одной исключающей дуге.
Дуга должна покрывать как минимум две линии связей; в отношении взаимного исключения обычно принимают участие не более трех-четырех таких линий.
Дуги почти всегда покрывают концы связей, имеющие степень "многие".
Дуги не могут покрывать линии связей, относящиеся к разным сущностям, к разным подтипам одной сущности и к разным супертипам одного подтипа.
Если конец связи, являющийся частью уникального идентификатора, покрывается дугой, то каждый из концов, покрытых той же дугой, должен входить в альтернативный уникальный идентификатор для данной сущности.
Проиллюстрируем некоторые из правил с помощью рисунка:
Рисунок 7-9.
Синтаксис
В синтаксические правила чтения связей для данного случая необходимо внести изменения, а именно добавить слова "либо-либо", дабы в явном виде отразить взаимную исключительность связей.
Рисунок 7-10. Реальный пример с исключающей дугой
Каждый КУПОН должен оформляться на один и только один РЕЙС (на конкретную дату) или быть открытым для одного и только одного АВИАМАРШРУТА (идентифицируемого номером рейса, но не датой, т.е. имеет место открытый купон/билет).
Обратный синтаксис
Используя обратный синтаксис, получаем:
Это означает, что у нас никогда не может быть КУПОНА, не оформленного на конкретный РЕЙС (с конкретной датой) и в то же время не открытого для СТАНДАРТНОГО РЕЙСА (с номером). Так ли это?
Обратите внимание на то, что мы воспользовались именами атрибутов (дабы придать информации большую определенность).
Недопустимые комбинации
Рисунок 7-11. Дуги, изображенные с нарушением правил
Каждая из изображенных дуг не проходит логическую проверку.
Необычные дуги
Рисунок 7-12. Дуга на конце связи со степенью "один"
Такая схема означает, что сущность A часто бывает связана с набором вхождений сущности B или с набором вхождений сущности C, но никогда с их комбинацией.
(Будьте внимательны: такие ситуации зачастую связаны с политическими соображениями, которые подвержены постоянным изменениям. Лучше было бы эти соображения учитывать в функции, ссылающейся на фрагмент модели.)
Непереносимые связи
Отношение между вхождениями разных сущностей обычно реализуется через связь, и такая связь уже после установления может быть разорвана и передана другому вхождению той же сущности.
Если это не допускается, значит связь является непереносимой.
Представление
Непереносимая связь обозначается значком <>, изображаемым на соответствующем конце.
Рисунок 7-13. Пример
Не имеет никакого смысла переносить купон из одного билета в другой, но тот же самый купон можно было бы переоформить на другой рейс, если на этот рейс мест уже нет. Рейс, на который переоформляется купон, может выполняться той же авиалинией, но в более позднее время, или же другой авиалинией, что тоже бывает.
Синтаксис
При чтении связи можно добавить фразу типа "и никогда не может быть перенесена".
Каждый КУПОН должен входить в один и только один БИЛЕТ и никогда не может быть перенесен в другой БИЛЕТ.
Обратный синтаксис позволяет дать утвердительный ответ во всех случаях.
Оценка степени мощности связи
Иногда бывает важно определить границы степени мощности, ее нормальное значение, максимальное, среднее и значение в 95% случаев. Эта информация может иметь решающее значение для проектировщиков.
Представление
При указании степени мощности используйте символы =, >, >=, <, <=.
Рисунок 7-14. Пример 1
Каждый ГОД может включать в себя от одного до двенадцати МЕСЯЦЕВ.
Рисунок 7-15. Пример 2
Каждый СЧЕТ должен принадлежать одной или двум ЛИЧНОСТЯМ. (Т.е. разрешаются общие счета.)
Иногда, чтобы оценить степень мощности связи, бывает нужно построить диаграмму распределения, как это сделано в следующем примере.
Рисунок 7-16. Пример 3
Рисунок 7-17. Диаграмма распределения
Вершины на диаграмме соответствуют:
обычным счетам
счетам с отсроченными платежами
просроченным счетам (т.е. счетам, по которым подозревается обман и объявлен розыск)
Такая информация по нескольким миллионам счетов имеет решающее значение как при проектировании БД, так и при выборе способа хранения данных в неавтоматической системе.
Определение связи
Для того, чтобы считать анализ информационного содержимого связи завершенным, мы должны иметь следующее:
степень (мощность)
описание
обязательность (по возможности с оценкой)
замечания
а также все, что сопутствующее этой связи:
сущности (ровно две)
дуги (не более одной)
уникальные идентификаторы
функции, в которых она используется.
Полностью определение связи описано в Приложениях B и C. Там же приведен набор примеров описания связей, который может помочь вам в случае каких-либо возникающих у вас затруднений.
Избыточная связь
Схема взаимосвязей между сущностями не должна содержать связей, которые в любых обстоятельствах могут быть получены или выведены каким-нибудь способом из других связей.
Замечание: в БД, в файловой или неавтоматической реализации избыточность используется в интересах обеспечения надежности. Однако, на это должны быть направлены усилия проектировщиков, но не действия (возможно, некорректные) аналитика.
Рисунок 7-18. Пример
На первый взгляд схема представляется правдоподобной и действительно отражает структуру некоторых купонов; тем не менее, связь между КУПОНОМ и РЕЙСОМ уже недвусмысленно идентифицирует как АВИАМАРШРУТ, так и АВИАЛИНИЮ, делая тем самым две другие связи сущности КУПОН избыточными.
Каскадное удаление
В реальной жизни, если мы напрочь забываем о чем-то, то мы забываем тем самым и о всех связанных с этим вещах.
Так, например, если вы удаляете все связанное с БИЛЕТОМ, вы удалите тем самым и все связанное с КУПОНОМ. КУПОНЫ (потомки) существуют только в контексте БИЛЕТА (родительской сущности).
Такое действие называется "каскадным удалением" и имеет отношение к сущностям, имеющим потомков и связи типа "многие".
В обычной ситуации (не связанной с каскадным удалением) должно выполняться правило, в соответствии с которым удаление приостанавливается в случае наличия сущностей, зависящих от удаляемой (т.е. ее потомков).
Так, например, нельзя удалить сущность ЭКИПАЖ до тех пор, пока в нем есть какие-то ЧЛЕНЫ.
Признак каскадного удаления
Статус каскадного удаления отражается с помощью специального признака:
X = Удалить всех потомков, если удаляется родитель
C = Помешать удалению родителя в случае существования хотя бы одного потомка
N = Родитель и потомок удаляются отдельно друг от друга.
Признак имеет значение C обычно тогда, когда потомок связан с родителем обязательной связью (must be).
Значение N свидетельствует о том, что связь является необязательной с обеих сторон.
Каскадная коррекция
Относится только к уровню реализации проекта и используется только при наличии системы управления реляционной БД (СУРБД). При изменении значения уникального идентификатора/первичного ключа родителя, новое значение автоматически заносится во все внешние ключи.
Каскадное удаление и коррекция успешно реализуются с помощью СУРБД и генераторов прикладных программ.
Терминология
Также интересно отметить, что в окончательном виде номер рейса следует переименовать в "номер маршрута". Проблема терминологии является обычной для большинства сфер деятельности - в воздушных перевозках слово "рейс" используется для обозначения и "маршрута", зачастую в одном и том же предложении. Такова жизнь!
Тип и вхождение
Важно уяснить себе, что определения, данные нами для сущности, связи, атрибута и уникального идентификатора, относятся к определениям, представляющим тип или класс понятия - но не конкретные вхождения. Для того, чтобы пояснить, что имеется ввиду, обратимся к фрагменту схемы.
Рисунок 3-19
Эту схему можно представить в трехмерном пространстве и рассмотреть конкретные вхождения сущностей.
Рисунок 3-20
Все места связаны с самолетом, однако только на некоторые из них имеются купоны. Таким образом, рисунок отражает реальную картину, которая допускает наличие в самолете незанятых мест.
Если мы посмотрим на все купоны - старые, нынешние и выданные предварительно на будущие рейсы - мы столкнемся со следующей ситуацией.
Рисунок 3-21. Временной разрез схемы: прошлое, настоящее и будущее
Теперь мы имеем на сотни тысяч больше купонов, из которых мы выбрали те, которые когда-либо (в прошлом, настоящем или будущем) оформлялись на место A1 на самолете с регистрационным номером G-ORCE.
Под ваши определения в каждом конкретном случае должен точно подходить каждый экземпляр (вхождение) определяемого объекта. В нашем примере эскадрилья может включать в себя пару очень старых самолетов, относительно которых нас может чрезвычайно интересовать, когда в последний раз проверялось наличие запчастей для них. Для таких исключительных случаев, при необходимости, определение может включать в себя информацию, присутствующую как "возможность" и не требующуюся в обычных случаях.
Все прочие понятия и определения в МВМС также адресуются к типу или классу объекта.
Типология сущностей
Существует несколько способов задания типов сущностей, которые частично повторяют путь, проходимый при классификации.
Рисунок 8-19. Подтипы
Сущность A имеет три взаимно исключающих друг друга подтипа: A1, A2 и A3. Это довольно укрупненное разделение, поскольку в нем допускается не более трех подтипов, однако оно позволяет задавать атрибуты и связи, присущие отдельным подтипам.
Рисунок 8-20. Атрибут "тип"
Подход, идентичный классификации и допустимый во многих простых ситуациях.
Рисунок 8-21. Сущность "тип"
Более общая конструкция.
Рисунок 8-22. Множественность типов
Схема аналогична классификации. Отличается наибольшей гибкостью и может использоваться в очень сложных моделях.
Участие руководства
Правильно понимаемое МВМС концентрируется на информации, жизненно важной для данной организации. Это либо массовая информация (как купоны), либо имеющая критическое значение (связанная с формированием экипажей и контролем безопасности). Руководство сильно интересуют детальные сведения по таким направлениям, которые оказывают наибольшее влияние на управление. И вам поэтому следует получить "добро" на всестороннюю проверку модели с привлечением ответственных должностных лиц, действительно разбирающихся в деловых вопросах. Им должна быть дана возможность направлять ваши усилия в нужное русло.
Но не следует показывать им всю схему целиком.
Возводите модель осторожно, используя элементы, иллюстрирующие их понимание дела. Прибегайте к тематическим примерам, понятным для них, обращайте внимание на текущие вопросы, которые они решают, демонстрируя при этом, каким образом новая модель может оказать им помощь в их проблемах. Так, только для компании "Atlantis Airline Flights" может потребоваться от тридцати до сорока подсхем, иллюстрирующих ее деятельность до подробностей.
Построенная и согласованная модель взаимосвязей между сущностями имеет сразу несколько назначений. Во-первых, она образует архитектурный каркас, необходимый для разработки новых и совершенствования существующих систем. Во-вторых, она дает представление о проекте БД "в первом разрезе". Но и это еще не все. В передовых компаниях она используется и на уровне высшего руководства в качестве катализатора, дающего толчок к рождению новых идей.
Уникальный идентификатор
Каждая сущность должна иметь уникальное определение, которое обеспечивается с помощью комбинации атрибутов и/или связей. Поэтому всегда следует искать дополнительные атрибуты, помогающие идентифицировать сущность.
Для самолета в таком случае могут иметь значение и номера шасси, и номера двигателей и т.п.
Значение атрибута должно зависеть от всего уникального идентификатора.
Уберите те из атрибутов, значения которых зависят только от одной составляющей уникального идентификатора. Эти действия называют "Второй формой нормализации" (см. Приложение A). Подобные атрибуты обычно указывают на отсутствие какой-либо сущности.
Атрибуты должны зависеть от значения уникального идентификатора
Уберите те из атрибутов, которые не зависят от значения уникального идентификатора сущности (т.н. "Третья форма нормализации"). Так, например, на посадочном талоне может быть записано имя пассажира. Но:
"Зависит ли имя пассажира как-нибудь от значения уникального идентификатора посадочного талона?"
Очевидно, нет. (Не должен же я менять свое имя при выписке посадочного талона!) Если атрибут не зависит от значения уникального идентификатора, значит, возможно, нами не учтена какая-либо сущность и/или связь.
Необязательные атрибуты
Значения некоторых атрибутов могут в какие-то моменты просто отсутствовать или же быть недоступны. В таких случаях перед именем атрибута на схеме ставится буква "o", что говорит о том, что атрибут - необязательный (optional).
Обязательные атрибуты
Те атрибуты, значения которых должны быть известны всегда, имеют перед своим именем значок "*". Но будьте внимательны - добавленное вами условие будет означать, что вам не известен случай появления такого экземпляра сущности, который не имел бы значений своих обязательных атрибутов. Вот то, что я называю настоящей строгостью! На практике же уровень строгости соглашений обычно слегка смягчается.
Рисунок 3-17. Изображение необязательности атрибутов
Определение уникального идентификатора
Каждая сущность должна быть уникально определена, то есть каждый экземпляр (вхождение) сущности должен иметь ясное и недвусмысленное определение, позволяющее отличать его от других экземпляров (вхождений) той же сущности. Уникальным идентификатором может быть атрибут, комбинация атрибутов, комбинация связей или атрибутов и связей.
Сущность может иметь несколько альтернативных способов уникальной идентификации: первый метод состоит в обозначении тех атрибутов, которые составляют уникальный идентификатор, символом "#" и в перечеркивании входящих в уникальный идентификатор связей.
Рисунок 3-18. Изображение уникальных идентификаторов
Таким образом, для того, чтобы уникально определить посадочный талон, необходимо иметь:
связь с местом и, благодаря этому, с его номером;
связь с рейсом и, таким образом, с датой и временем вылета;
дату и время выписки на случай переоформления посадочных талонов; например, члены одной семьи могут пожелать пересесть поближе друг к другу в случае неявки одного из них;
для уникального определения рейса необходима также связь с авиамаршрутом и номер рейса.
Управленческая функция/процесс
Любая управленческая функция, в особенности элементарная, должна описывать действие, направленное на достижение цели управления, вне зависимости от способа его выполнения. Она должна иметь вид предложения, которое начинается с глагола, ссылается на сущности или синонимы сущностей и описывает происходящие в данных изменения и прочие обстоятельства в терминах атрибутов.
Управленческое событие
Выполнение большого числа управленческих функций вызывается некоторыми событиями, имеющими различную форму. К ним относятся события реального времени (например, через тридцать дней от даты обращения), события изменения (изменение некоторых деталей или появление новых данных) и системные события (когда завершение выполнения одной или нескольких функций служит сигналом к выполнению другой функции).
Каждое событие подлежит описанию; для него можно определить условия, при которых оно имеет место. Эти условия задаются в терминах известных атрибутов.
Управление
С ростом масштабов задача становится все более трудной. В большинстве случаев вас может выручить надстройка к БД - совместно используемый словарь, описывающий все данные и перекрестные ссылки. Контроль качества, полноты и проведение контактного анализа облегчается благодаря ведению отчетности средствами CASE.
При моделировании крупных систем у вас может получиться многофункциональный набор моделей, который впоследствии разбивается на различные прикладные системы. Эти прикладные системы неизменно пересекаются, над ними работают разные группы, повторяющие все изменения при переходе с одной версии на другую. Одновременно могут существовать системы, работающие в производстве, находящиеся в стадии разработки и только планируемые, причем любая из них может пересекаться с другими системами.
В распоряжении администратора данных должны быть средства, помогающие управлять:
доступом к определениям
полномочиями на внесение изменений
описанием системы
внесением изменений и формированием новых версий.
Обычно администратор данных тесно взаимодействует с конечными пользователями, аналитиками, возглавляющими различные проекты, и проектировщиками БД.
Упрощенный подход к проектированию
Шаг 1
Каждая элементарная сущность преобразуется (транслируется) в таблицу. Элементарной называется сущность, не являющаяся подтипом. Таблице обычно дается имя, представляющее собой множественную форму имени сущности.
Шаг 2
Каждый атрибут превращается в одноименный столбец, при этом формат его подвергается уточнению.
Необязательные атрибуты становятся столбцами с разрешением пустого (null) значения. Обязательные атрибуты становятся столбцами типа not-null (ненулевыми).
Шаг 3
Компоненты уникального идентификатора сущности становятся первичным ключом таблицы. Заметим, что сущность может иметь несколько уникальных идентификаторов, тогда из них выбирается тот, который используется наиболее часто.
Напомним также, что сущность уникально идентифицируется комбинацией атрибутов и/или связей. Связи преобразуются следующим образом: в качестве первичного ключа используются компоненты уникального идентификатора сущности на дальнем конце связи (процедура их поиска продолжается рекурсивно, пока наконец не будут найдены атрибуты).
При этом описания связей и/или имена сущностей добавляются к наименованиям атрибутов в целях обеспечения уникальности имени столбца, который предполагается использовать в качестве компоненты внешнего ключа.
Шаг 4
Связи типа "многие к одному" (и "один к одному") становятся внешними ключами. При этом в качестве столбцов используются уникальные идентификаторы сущностей на конце "один".
Необязательные связи создают столбцы с разрешением пустого (null) значения. Обязательные связи создают столбцы типа not-null (ненулевые).
Рисунок F-1. Пример
Шаги 1-4 годятся для большинства несложных проектов. Прежде чем мы переходить к более сложным случаям, предполагающим использование исключающих дуг и подтипов, рассмотрим кратко, как создаются индексы.
Шаг 5. Проектирование индексов
Индексы создаются для:
первичного ключа (уникальный индекс)
внешних ключей и
индексы, предусмотренные матрицей функция/атрибут.
Напомним о том, что первичный и внешние ключи могут состоять из нескольких столбцов.
Столбец, который идет первым в индексе, состоящем из нескольких столбцов, сам по себе уже может не упорядочиваться.
В результате детализации функций может появиться потребность в использовании значений атрибутов в качестве условий выборки данных. В этом случае может быть создана матрица функция/атрибут, которая позволяет обнаружить наиболее часто используемые атрибуты; отображение этих атрибутов на столбцы таблиц дает возможные индексы.
Последующее слежение за работой СУРБД позволит определить, какие индексы и при каких обстоятельствах используются.
Пример
Для трех вышеназванных таблиц можно выбрать следующие индексы:
|
Код в AIRPORTS |
(Уникальный индекс) |
|
Код в AIRLINES |
(Уникальный индекс) |
|
Код родительской авиалинии в AIRLINES |
(Неуникальный индекс) |
|
Номер рейса и Код авиалинии в AIRLINE ROUTES |
(Составной уникальный индекс) |
|
Код аэропорта вылета в AIRLINE ROUTES |
(Неуникальный индекс) |
|
Код аэропорта назначения в AIRLINE ROUTES |
(Неуникальный индекс) |
Подтип сущности - это обычная сущность со своими атрибутами или связями, но помимо того наследующая атрибуты и/или связи от своего родителя (сущности-супертипа) и вышестоящих родителей (вверх по иерархии супертипов).
Если вы уже имели дело с объектно-ориентированными структурами данных, включающими свойства наследования, это понятие вам будет знакомо.
Существует два основных варианта представления подтипов (каждая из которых имеет свои преимущества и недостатки):
все подтипы в одной таблице
таблица для каждого подтипа.
Все подтипы в одной таблице
Таблица создается для внешнего супертипа, в то время как для каждого из подтипов могут создаваться обзоры. Как и раньше, основаниями для создания столбцов и внешних ключей служат атрибуты и связи типа "многие к одному".
Обзор представляет собой средство доступа к подмножеству (фрагменту) таблицы. Обзор может быть сведен к подмножеству столбцов или к отдельным строкам таблицы и может менять наименования столбцов.
В первую очередь обзоры используются для корректировки и выборки данных. (Более сложные обзоры включают в себя данные из нескольких таблиц, при этом могут использоваться и производные данные, но как правило только для чтения.)
Все это имеет отношение к каждому подтипу, к каждому подтипу данного подтипа и т.п. Разница в том, что все столбцы, создаваемые для подтипов, имеют тип null (необязательность). Обязательный атрибут (или связь) для одного подтипа не должен использоваться для другого - таким образом, все они должны быть необязательными, целостность же обеспечивается либо прикладными программными средствами, либо через обзор с опцией контроля (check option).
В таблицу должен быть добавлен по меньшей мере еще один ненулевой столбец, обозначающий тип (TYPE) и включаемый в первичный ключ.
Например:
TYPE |
char |
4 |
not null |
с предписанным значением для каждого подтипа |
Замечание: рекомендуется, тем не менее, контроль целостности включать в текст программы, дабы пользователи могли получать сообщения, объясняющие причину нарушения целостности.
Рисунок F-2. Пример
Обратите внимание на то, что два столбца именуются "Номер...", при этом имя столбца содержит имя сущности, уточняющее его смысл. Кроме того, столбцы "Количество" и "Код_продукта" сделаны необязательными, поскольку ни один из них не связан с ПРОЧЕЙ СТРОКОЙ ЗАКАЗА.
Столбец "Тип" добавлен, чтобы иметь возможность различать подтипы сущности СТРОКА ЗАКАЗА.
При этом код "СОП" означает СТРОКУ, ОПИСЫВАЮЩУЮ ПРОДУКТ, а "ПС" - ПРОЧУЮ СТРОКУ.
Описание реляционных обзоров на языке SQL:
CREATE VIEW OTHER_ORDER_LINES AS /* обзор ПРОЧИЕ_СТРОКИ_ ЗАКАЗА */ SELECT LINE_NUMBER, /* номер строки */ ORDER_NUMBER, /* номер заказа */ DESCRIPTION, /* описание */ TAX_COMMENT, /* комментарии */ TYPE /* тип */ FROM ORDER_LINES /* таблица СТРОКИ_ЗАКАЗА */ WHERE TYPE='OOL' /* ТИП='ПС' */ WITH CHECK OPTION CREATE VIEW PRODUCT_ORDER_LINE AS /* обзор СТРОКА_ ОПИСЫВАЮЩАЯ_ПРОДУКТ */ SELECT LINE_NUMBER, /* номер строки */ ORDER_NUMBER, /* номер заказа */ DESCRIPTION, /* описание */ QUANTITY, /* количество */ PRODUCT_CODE, /* код продукта */ TYPE /* тип */ FROM ORDER_LINES /* таблица СТРОКИ_ЗАКАЗА */ WHERE TYPE='OOL' /* ТИП='СОП' */ AND QUANTITY NOT NULL AND EXISTS (SELECT NULL FROM PRODUCTS WHERE /* таблица ПРОДУКТЫ */ PRODUCTS.CODE=ORDER_LINES.PRODUCT_CODE) WITH CHECK OPTION
Обратите внимание на то, что в обоих обзорах производится проверка столбца Type, кроме того во втором обзоре появляются дополнительные условия: ненулевое количество и существование соответствующего кода продукта в таблице PRODUCTS.
Таблица для одного подтипа
Таблицы, создаваемые для отдельных подтипов, должны учитывать все возможные вхождения.
Если мы имеем дело с иерархией подтипов, состоящей из нескольких уровней, таблицы создаются для подтипов верхнего уровня. (Для подтипов всех последующих уровней создаются обзоры.)
Создаваемая для подтипа таблица включает в себя столбцы для каждого атрибута и каждой связи типа "многие к одному". Кроме них создаются столбцы для супертипа (и для его супертипов, стоящих выше по иерархии), при этом каждый из наследуемых столбцов наследует и обязательность.
Если подтип сам является супертипом, в таблице могут появиться и необязательные столбцы для каждого из его подтипов (и для подтипов всех последующих уровней).
При работе с супертипом вам может также пригодиться обзор типа UNION.
Рисунок F-3. Пример
Предположим, что таблица создается для подтипа В. Это сложный пример, заслуживающий внимательного изучения.
Рассмотрим обзор для подтипа E:
CREATE VIEW E AS SELECT e, b1, b2, a1, G_g, type, a2, parent_a1, parent_G_g, parent_type FROM B WHERE type='E' AND e not null AND EXISTS (SELECT NULL FROM B WHERE B.a1 = E.Parent_a1 AND B.G_g = E.Parent_G_g AND B.Type = E.Parent_Type) WITH CHECK OPTION И для полноты впечатления рассмотрим обзор типа UNION для A: CREATE VIEW A AS SELECT * FROM B UNION SELECT * FROM C Символ * в операторе SELECT означает выборку всех столбцов.
Преимущества и недостатки
|
Все подтипы в одной таблице |
Таблица для одного подтипа |
|
Преимущества |
Преимущества |
|
Все в одном месте |
Совокупность условий более наглядно распределяется по подтипам |
|
Простота доступа к супертипу и подтипам |
Программы имеют дело только с теми таблицами, которые связаны с интересующими нас подтипами |
|
Требуется меньше таблиц |
|
|
Недостатки |
Недостатки |
|
Чересчур высокий уровень обобщения |
Много дополнительных таблиц |
|
Трудность объединения различных наборов столбцов с различной целостностью |
Беспорядочное объединение столбцов в обзоре типа UNION |
|
Возможны "узкие места", в частности при использовании механизмов блокировки |
Проблемы с быстродействием при обработке обзора типа UNION |
|
Столбцы для подтипов должны стать необязательными |
Коррекция супертипа невозможна, что мешает выполнению функций |
|
В некоторых СУРБД возникает опасность превышения допустимого количества столбцов или выхода за пределы отведенного пространства (за счет хранения пустых значений) |
Шаг 7. Исключающая связь
Существует два основных средства обработки исключающих связей:
общий домен
заданные явно внешние ключи.
Общий домен
Если оставшиеся внешние ключи можно включить в один домен (идентичный формат), создайте два столбца:
Идентификатор связи
Идентификатор сущности.
Столбец "Идентификатор связи" позволяет различать связи, покрываемые исключающей дугой.
Столбец "Идентификатор сущности" содержит значения уникального идентификатора сущности, расположенной на противоположном конце соответствующей связи.
Рисунок F-4. Пример
В таблице TIMESHEET_ENTRIES (СТРОКИ_ТАБЕЛЯ) связи "по ЭТАПУ ПРОЕКТИРОВАНИЯ" и "о ДЕЯТЕЛЬНОСТИ ВНЕ ПРОЕКТА" реализуются с помощью столбцов:
|
Строка_табеля_по (Timesheet_for) |
char |
3 |
not null |
(значение 'ЭП' и 'ДВП') |
|
Код_деятельности (Activity_code) |
char |
7 |
not null |
Явное задание внешних ключей
Если полученные внешние ключи не объединяются в домен, создайте соответствующие внешним ключам столбцы для каждой связи, покрытой исключающей дугой, и сделайте эти столбцы необязательными (null). В прикладной программе следует учесть, что только одно значение может быть введено (или должно быть введено, если связи обязательные).
Вернемся к нашему примеру, но на этот раз предположим, что код этапа проектирования является целым числом (integer).
Рисунок F-5. Снова предыдущий пример
В результате добавятся столбцы:
|
Код_этапа_проектирования (Project_units_code) |
integer |
5 |
null |
|
Код_деятельности_вне_проекта Non-project_activities_code) |
char |
7 |
null |
|
Общий домен |
Явное задание внешних ключей |
|
Преимущества |
Преимущества |
|
Используются только два столбца Необязательность поддерживается средствами СУРБД |
Видны условия соединения |
|
Недостатки |
Недостатки |
|
Оба столбца должны использоваться во всех операциях соединения |
Дополнительные столбцы Необязательность столбцов и их использование реализуются прикладными средствами |
В чем заключается значимость МВМС?
За последние двадцать лет компьютерные системы усложнились чрезвычайно. Они претерпели ряд эволюций:
опытные разработки (экспериментирование);
отдельные функциональные системы;
ведомственные системы (в рамках отдела);
интегрированные операционные системы;
системы автоматизации делопроизводства;
административные информационные системы.
При всем том только на словах признавалась необходимость сведения к минимуму дублирования и обеспечения интеграции данных, их целостности и доступности. Частично это объяснялось тем, что возможности систем почти всегда были ограниченны, а идея о понимании различных и зачастую противоречащих друг другу потребностей пользователей не могла быть принята во внимание вследствие недостатка умения и опыта, а также возможностей имеющегося инструментария.
МВМС в сочетании с CASE-инструментарием составляют эффективные современные средства описания информационных запросов. Однако пользоваться ими следует корректно, как впрочем и любыми другими действующими средствами.
Данная книга содержит руководящие указания по созданию, отладке и использованию моделей взаимосвязей между сущностями. Эти модели, облегчающие построение эффективных компьютерных и/или неавтоматических систем, использовались на протяжении почти двадцати лет в разных обстоятельствах при реализации проектных решений в рамках реляционных, сетевых, иерархических и традиционных компьютерных систем, при разработке форм документов, процедур записи в файл и контроля.
Работу с книгой рекомендуется сочетать с изучением предмета, а в идеале с работой бок о бок с опытным построителем моделей.
Опыту трудно найти замену.
Связь с циклом проектирования системы
В применении к циклу проектирования управленческой системы можно сказать, что вопросы, рассматриваемые в данной книге, имеют отношение к этапам выработки стратегии и анализа. Принципы, изложенные здесь, имеют более широкое значение - они применимы на этапе проектирования БД и на этапе запуска в эксплуатацию. Более подробно о цикле проектирования см. в документе "CASE*Method - Tasks and Deliverables".
Внешняя схема
Внешняя схема отражает точку зрения на информацию пользователя, играющего определенную роль. В CASE-методе предусмотрено подмножество обзоров, учитывающих функциональные запросы данной роли. (См. Приложение G.)
К обсуждению вопросов проектирования высшее
К обсуждению вопросов проектирования высшее руководство нужно привлекать, но учитывая при этом, что дело нужно представлять просто и понятно, тогда его легче будет контролировать.
Даже имея всего только несколько сущностей и немного информации, можно построить очень сложную и строгую модель. Особую ценность представляют исключающие связи, изображаемые с помощью дуг.
Наконец, мы обнаружили несколько функций, в которых участвуют сущности. Функциональное моделирование выходит за пределы настоящей публикации, но это не мешает нам перечислить их:
Открытие счета для частного лица или организации
Выдача карточки, связанной с конкретным счетом, частному лицу Установка лимитов, условий платежа и создание условий, определяющих тип карточек
Идентификация кредитной карточки по ее держателю, счету и сроку действия
Анализ кредитных карточек по типам
Поиск карточек с истечением срока действия в следующем месяце и повторная выдача карточек под тем же счетом.
Мы рассмотрели некоторые важные дополнительные соглашения и определения, в частности:
подтипы и супертипы
исключающие связи
непереносимые связи.
Эти понятия дают нам не только более богатый набор средств моделирования (за счет повышения точности представления объектов предметной области), но и правила, которые необходимо включать в любую реализацию системы (канцелярскую или компьютерную).
При использовании CASE-инструментария эти правила автоматически реализуются с помощью средств СУРБД и генераторов прикладных программ.
На выполнение этой задачи вы не потратите много времени, но ее значение скажется в будущем, ибо оно выливается в сокращение последующих переделок и повышение продуктивности работы проектировщиков.
Многопользовательский, ориентированный на групповое использование CASE-инструментарий, сочетающий интерактивные построители схем и диаграмм с соответствующими утилитами и возможностью формирования отчетов, повысит качество вашей модели и продуктивность работы аналитиков и стратегов.
Администраторы БД и руководители проекта могут воспользоваться средствами регулирования доступа, хранения версий и управления проектированием.
Этап анализа
Зависимость данных
На любом из этапов, следующих за этапом выработки стратегии, может возникнуть вопрос, что еще из данных и функций должно быть реализовано в системе, дабы проект некоторого действительно ключевого элемента данных стал полным.
Рисунок G-6. Расширенная модель из второй главы
Вернувшись к нашим авиалиниям, предположим, что исходная (традиционная) система составления расписания рейсов не в состоянии дальше справляться с увеличением траффика и требует скорейшей автоматизации. После проведения последней мы добавим в систему элементы отслеживания билетов и купонов.
Правила
Из приведенной схемы видно, что реализация сущности РЕЙС требует учета соответствующих деталей сущностей САМОЛЕТ, АВИАМАРШРУТ, АВИАЛИНИЯ и АЭРОПОРТ. Подобную зависимость легко установить, если пройтись по обязательным связям (типа "должен"); например: РЕЙС должен выполняться по АВИАМАРШРУТУ.
Мы также добавим сюда сущности, связанные с текущей сущностью отношением типа "многие (или один) к одному"; так, например, на РЕЙС может назначаться САМОЛЕТ. В этом случае принимаются во внимание как обязательные, так и необязательные связи.
Те же правила касаются и сущностей, выполняющих в цепочке роль последующих звеньев.
Переходя впоследствии к реализации сущности БИЛЕТ, мы должны будем учесть детали не только сущности ПАССАЖИР, но и сущности КУПОН, поскольку БИЛЕТ должен состоять из одного и более КУПОНОВ. Следуя тем же правилам, мы должны также учесть все связи, предполагаемые сущностью КУПОН, а именно: с РЕЙСОМ, САМОЛЕТОМ (необязательная), АВИАМАРШРУТОМ, АЭРОПОРТОМ(из), АЭРОПОРТОМ(в), АВИАЛИНИЕЙ, МЕСТОМ (необязательная) и вновь с САМОЛЕТОМ (но уже через место, необязательная). Такую зависимость легко обнаружить, имея полное проблемное представление сущности КУПОН.
Дальнейшие действия
Затем мы можем принять во внимание все прикладные функции, имеющие отношение к отобранным сущностям, или их проблемные представления, и отобрать те из них, что могут составить основу поэтапного совершенствования модели в направлении более полного удовлетворения пользовательских запросов, целей и приоритетов.
Обращение к важнейшим проблемным представлениям уточняет зависимость, обнаруженную между данными.
