Цель работы:изучить структуру построения информационной модели.
Ход работы:
Лабораторная работа направлена на ознакомление с методологией информационного моделирования IDEF1X, получение навыков по применению данной методологии для построения информационных моделей на основании требований к информационной системе.
Предметная область: Отгрузка товара со склада.
В моей предметной области есть склад с товаром, этот товар я продаю покупателям, мои покупатели это юридические и физические лица. Когда я отгружаю товар, то я сопровождаю отгрузку документом ТТН (товарно-транспортная накладная). В этом документе фиксируется какой товар, в каком количестве, какого числа, к кому поедет.
Создавать я буду модель Logical/Physical, так как это выгоднее (в одном файле у нас находится и логический и физический уровень). В конечном счете, я хочу придти к генерации скрипта для создания БД, поэтому я указываю для какой СУБД будет составлен мой физический уровень (то есть для СУБД на языке SQL).
Выбираю сущности моей модели, это будут Товар, Покупатель и ТТН.
При проектировании пока что выбран Логический уровень и по рекомендациям методологии IDEF1X на логическом уровне в самом начале идет построение Концептуальной модели. Поэтому переключаемся на кнопку Entity Level (Уровень сущностей), где я буду создавать конкретно сущности, не раскрывая их атрибуты.
Я изображаю три сущности, которые сразу бросаются в глаза при проектировании. Это: Товар, Покупатель и ТТН.
Теперь мне нужно написать взаимодействие между этими сущностями с точки зрения одной и другой.
Берем сущность Покупатель и ТТН. У одного покупателя может быть много отгрузок по многим ТТН. А если мы берем одну ТТН, то у неё может быть только один конкретный покупатель. Таким образом связь между покупателем и ТТН будет иметь тип один Покупатель ко многим ТТН. Создаем между ними не идентифицированное отношение Один ко многим.
Подписываем отношение. Наша родительская сущность (Parent) Покупатель, так как у одного покупателя МНОГО ТТН. Поэтому первичный ключ из покупателя пойдет в ТТН потом. Подписываем связь (Parent-to-Child) глаголом «Получат товар» с точки зрения родительской сущности. С точки зрения ТТН (дочерней сущности) одна накладная «Принадлежит» покупателю (Child-to-Parent).
Берем следующие сущности Товар и ТТН. С одной стороны один вид Товара может продаваться по многим ТТН, с другой стороны по одной ТТН может продаваться много разных видов товаров. Поэтому связь между ними будет Многие ко Многим. Тут уже не так важно где Родительская, а где Дочерняя сущность. С точки зрения Товара один товар «Продается» по многим накладным, а с точки зрения ТТН одна накладная содержит много товара.
Таким образом, концептуальная схема готова. Между Товаром и Покупателем нет прямой связи, так как они связаны через ТТН.
При переходе на следующий уровень любая связь Многие ко Многим должна быть разрешена. То есть от неё нужно избавиться – свести её к двум отношениям типа Один ко Многим. По этому, использую опцию Create Association Entity (Создать ассоциирующую сущность), то есть ту сущность, которая будет реализовывать связь Многие ко Многим.
Назовем эту сущность «Строка ТЧ ТТН»
Получаем данную сущность, в которой будут Идентифицирующие связи:
Перехожу на следующий уровень, переключаюсь на Attribute level.
Как только я переключилась, у меня появились не только имена сущностей, но и место, куда можно писать атрибуты сущностей.
Самые важные атрибуты сущности – первичные ключи, поэтому нужно построить модель, основанную на ключах.
Создаю ключ для товара «КодТовара» Primary Key.
Так как я уже построила связь, то ключ автоматически мигрировал в связанную дочернюю таблицу. Так как связь идентифицированная, то этот ключ войдет в Первичный ключ новой сущности (Строка ТЧ ТТН), станет его частью.
Создаю ключ «КодПокупателя» Primary Key.
Происходит тоже - самое, что и в первом случае (ключ автоматически мигрировал в связанную дочернюю таблицу). То есть он также стал Внешним ключом. Но по сравнению с прошлой ситуацией данная связь не идентифицирующая, поэтому он стал Рядовым Внешним ключом и он не войдет в первичный ключ, не будет являться его частью.
Добавляем в ТТН ключ «НомерТТН» Primary Key.
Так же происходит миграция в сущность «Строка ТЧ ТТН», таким образом, её первичный ключ построился сам, на основе идентифицирующей связи.
Таким образом, модель, основанная на ключах готова.
Теперь можно переходить на Физический уровень и добавлять в модель атрибуты. Но можно дополнить нашу схему. Так как покупатели и физические и юридические лица, а у них разные атрибуты, то создаем отношение категоризации. Для этого создаю две дополнительные сущности «Физические лица»
и «Юридические лица».
И создаем теперь отношение категоризации. Данная связь между Физическими и Юридическими лицами будет «Один к Одному».
И теперь переходим к Физическому уровню.
На этом уровне уже добавляю атрибуты моих сущностей с их типами.
Готовая Информационная модель имеет такой вид. По ней в дальнейшем можно генерировать скрипт для создания БД.
Контрольные вопросы
1. Информационная модель — модель объекта, представленная в виде информации, описывающей существенные для данного рассмотрения параметры и переменные величины объекта, связи между ними, входы и выходы объекта и позволяющая путём подачи на модель информации об изменениях входных величин моделировать возможные состояния объекта[1].
Информационная модель (в широком, общенаучном смысле) — совокупность информации, характеризующая существенные свойства и состояния объекта, процесса, явления, а также взаимосвязь с внешним миром.
Информационная модель данных предназначена для представления семантики предметной области в терминах субъективных средств описания - сущностей, атрибутов, идентификаторов сущностей, супертипов, подтипов и т.д.
2. Информационная модель предметной области базы данных содержит следующие основные конструкции:
· диаграммы "сущность-связь" (Entity - Relationship Diagrams);
· определения сущностей;
· уникальные идентификаторы сущностей;
· определения атрибутов сущностей;
· отношения между сущностями;
· супертипы и подтипы.
3. Сущность (entity) представляет тип объектов, которые должны храниться в базе данных. Каждая таблица в базе данных должна представлять одну сущность. Как правило, сущности соответствуют объектам из реального мира.
Атрибут – это свойство сущности в предметной области. Его наименование должно быть уникальным для конкретного типа сущности. Например, для сущности студент могут быть использованы следующие атрибуты: фамилия, имя, отчество, дата и место рождения, паспортные данные и т.д. В реляционной БД атрибуты хранятся в полях таблиц.
Связь (relationship) – это графически изображаемая ассоциация, устанавливаемая между двумя сущностями. Связь может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь). Возможны связи на основе отношений:
- один-к-одному;
- один-ко-многим;
- многие-ко-многим.
4. Для экспорта модели данных из ERwin в BPwin необходимо в ERwin открыть модель и выбрать пункт меню File/Export/BPwin. В появившемся диалоге необходимо выбрать имя файла *.еах и нажать ОК. Затем в BPwin нужно открыть модель процесса, выбрать в меню пункт File/Import/ERwin (ЕАХ), выбрать имя файла и нажать ОК. Появится диалог Import Differences Preview, в котором показывается протокол импорта. Для внесения данных в модель процесса следует щелкнуть по кнопке Accept. Кнопка Cancel отменяет импорт.
Вывод: изучить структуру построения информационной модели и самостоятельно построила информационную модель определенной области.