Методика разработки модели на примере информационной системы по заказу некоторой оптовой торговой фирмы



При разработке ER-моделей мы должны получить следующую информацию о предметной области:

1. Список сущностей предметной области.

2. Список атрибутов сущностей.

3. Описание взаимосвязей между сущностями.

ER-диаграммы удобны тем, что процесс выделения сущностей, атрибутов и связей является итерационным. Разработав первый приближенный вариант диаграмм, мы уточняем их, опрашивая экспертов предметной области. При этом документацией, в которой фиксируются результаты бесед, являются сами ER-диаграммы.

Предположим, что перед нами стоит задача разработать информационную систему по заказу некоторой оптовой торговой фирмы. В первую очередь мы должны изучить предметную область и процессы, происходящие в ней. Для этого мы опрашиваем сотрудников фирмы, читаем документацию, изучаем формы заказов, накладных и т.п.

Например, в ходе беседы с менеджером по продажам, выяснилось, что он (менеджер) считает, что проектируемая система должна выполнять следующие действия:

· Хранить информацию о покупателях.

· Печатать накладные на отпущенные товары.

· Следить за наличием товаров на складе.

 

Выделим все существительные в этих предложениях - это будут потенциальные кандидаты на сущности и атрибуты, и проанализируем их (непонятные термины будем выделять знаком вопроса):

· Покупатель - явный кандидат на сущность.

· Накладная - явный кандидат на сущность.

· Товар - явный кандидат на сущность

· (?)Склад - а вообще, сколько складов имеет фирма? Если несколько, то это будет кандидатом на новую сущность.

· (?)Наличие товара - это, скорее всего, атрибут, но атрибут какой сущности?

Сразу возникает очевидная связь между сущностями - "покупатели могут покупать много товаров" и "товары могут продаваться многим покупателям". Первый вариант диаграммы выглядит так:

Рисунок. Первый вариант диаграммы

Задав дополнительные вопросы менеджеру, мы выяснили, что фирма имеет несколько складов. Причем, каждый товар может храниться на нескольких складах и быть проданным с любого склада.

Куда поместить сущности "Накладная" и "Склад" и с чем их связать? Спросим себя, как связаны эти сущности между собой и с сущностями "Покупатель" и "Товар"? Покупатели покупают товары, получая при этом накладные, в которые внесены данные о количестве и цене купленного товара. Каждый покупатель может получить несколько накладных. Каждая накладная обязана выписываться на одного покупателя. Каждая накладная обязана содержать несколько товаров (не бывает пустых накладных). Каждый товар, в свою очередь, может быть продан нескольким покупателям через несколько накладных. Кроме того, каждая накладная должна быть выписана с определенного склада, и с любого склада может быть выписано много накладных. Таким образом, после уточнения, диаграмма будет выглядеть следующим образом:

 

Рисунок. Уточненная диаграмма

Пора подумать об атрибутах сущностей. Беседуя с сотрудниками фирмы, мы выяснили следующее:

· Каждый покупатель является юридическим лицом и имеет наименование, адрес, банковские реквизиты.

· Каждый товар имеет наименование, цену, а также характеризуется единицами измерения.

· Каждая накладная имеет уникальный номер, дату выписки, список товаров с количествами и ценами, а также общую сумму накладной. Накладная выписывается с определенного склада и на определенного покупателя.

· Каждый склад имеет свое наименование.

· Снова выпишем все существительные, которые будут потенциальными атрибутами, и проанализируем их:

· Юридическое лицо - термин риторический, мы не работаем с физическими лицами. Не обращаем внимания.

· Наименование покупателя - явная характеристика покупателя.

· Адрес - явная характеристика покупателя.

· Банковские реквизиты - явная характеристика покупателя.

· Наименование товара - явная характеристика товара.

· (?)Цена товара - похоже, что это характеристика товара. Отличается ли эта характеристика от цены в накладной?

· Единица измерения - явная характеристика товара.

· Номер накладной - явная уникальная характеристика накладной.

· Дата накладной - явная характеристика накладной.

· (?)Список товаров в накладной - список не может быть атрибутом. Вероятно, нужно выделить этот список в отдельную сущность.

· (?)Количество товара в накладной - это явная характеристика, но характеристика чего? Это характеристика не просто "товара", а "товара в накладной".

· (?)Цена товара в накладной - опять же это должна быть не просто характеристика товара, а характеристика товара в накладной. Но цена товара уже встречалась выше - это одно и то же?

· Сумма накладной - явная характеристика накладной. Эта характеристика не является независимой. Сумма накладной равна сумме стоимостей всех товаров, входящих в накладную.

· Наименование склада - явная характеристика склада.

В ходе дополнительной беседы с менеджером удалось прояснить различные понятия цен. Оказалось, что каждый товар имеет некоторую текущую цену. Эта цена, по которой товар продается в данный момент. Естественно, что эта цена может меняться со временем. Цена одного и того же товара в разных накладных, выписанных в разное время, может быть различной. Таким образом, имеется две цены - цена товара в накладной и текущая цена товара.

С возникающим понятием "Список товаров в накладной" все довольно ясно. Сущности "Накладная" и "Товар" связаны друг с другом отношением типа много-ко-многим. Такая связь, как мы отмечали ранее, должна быть расщеплена на две связи типа один-ко-многим. Для этого требуется дополнительная сущность. Этой сущностью и будет сущность "Список товаров в накладной". Связь ее с сущностями "Накладная" и "Товар" характеризуется следующими фразами - "каждая накладная обязана иметь несколько записей из списка товаров в накладной", "каждая запись из списка товаров в накладной обязана включаться ровно в одну накладную", "каждый товар может включаться в несколько записей из списка товаров в накладной", " каждая запись из списка товаров в накладной обязана быть связана ровно с одним товаром". Атрибуты "Количество товара в накладной" и "Цена товара в накладной" являются атрибутами сущности " Список товаров в накладной".

Точно также поступим со связью, соединяющей сущности "Склад" и "Товар". Введем дополнительную сущность "Товар на складе". Атрибутом этой сущности будет "Количество товара на складе". Таким образом, товар будет числиться на любом складе и количество его на каждом складе будет свое.

Рисунок. Диаграмма со связями один ко многим

ЗАДАНИЯ.

2.1 Задание А. Перейдем к построению этой информационной модели сущность–связь в среде MS Office Visio 2007.

 1.Запустите MS Office Visio 2007.

2. На закладке выбора шаблона выберите категорию Программное обеспечение и базы данных и в ней элемент Схема модели базы данных. Нажмите кнопку Создать в правой части экрана.

3. Установите необходимые параметры страницы (масштаб, ориентация страницы).

5. MS Office Visio 2007 поддерживает различные нотации моделей баз данных. Для того чтобы задать нотацию IDEF1X, необходимо выбрать пункты меню База данных → Параметры → Документ. В открывшемся окне на вкладке Общие установить переключатель в меню Набор символов на IDEF1X. Меню Имена, видимые на схеме позволяет указать, какие имена атрибутов сущности будут отображены на диаграмме (концептуальные, физические или оба варианта одновременно). В данном случае для логического представления информационной модели необходимо выбрать пункт Концептуальные имена.

6.

 

В закладке Отношение окна Параметры документа базы данных в меню Показывать нужно отметить галочкой пункт Мощность, в меню Отображение вида выбрать пункт Показывать вербальную фразу и пункт Обратный текст. Данные настройки позволят отобразить имя и мощность связи в модели.

 

   

5. Для того чтобы создать сущность, необходимо перетащить элемент на рабочее поле. Переход в режим редактирования сущности осуществляется двойным щелчком по сущности или по нажатию правой кнопки мыши и выбора пункта меню Свойства базы данных. Добаьте нужные в модели сущности и укажите их имена.

 

 

 

 

6. Далее необходимо установить связи между сущностями.

Определим типы связей и построим модель. В дальнейшем можно будет подкорректировать связи между сущностями. Чтобы установить связи между сущностями, необходимо перетащить на рабочую область элемент, поднести один конец стрелки к родительской сущности, другой – к дочерней. Примечание. При правильном связывании каждая сущность будет подсвечена красным цветом.

В MS Office Visio 2007 по умолчанию используется не идентифицирующее отношение. Чтобы изменить тип связи, необходимо двойным щелчком по связи открыть окно Свойства базы данных и в категории в категории Прочее указать тип отношения (идентифицирующее, не идентифицирующее). В этой же категории указывается мощность связи.

Рисунок – Определение типа связи и мощности

 

Примечание. Кроме того, при не идентифицирующем отношении нужно указать, является ли наличие родительской сущности обязательным (т.е. может ли существовать экземпляр дочерней сущности, если не существует экземпляра родительской). Если наличие родительского объекта является необязательным, графически это отобразится в виде не закрашенного ромба со стороны родительской сущности.

Следующий шаг – в категории Имя в поле Вербальная фраза нужно указать имя отношения. Также можно указать имя связи в поле Обратная фраза для спецификации отношения потомок-родитель. Примечание. Все изменения при закрытии окна свойств сохраняются автоматически.

После определения имен, типов связей и задания мощностей получим информационную модель.

 Рисунок Информационная модель уровня «сущность-связь»

 

Практическое задание Б. Разработка логической модели данных, основанной на ключах

Необходимо определить атрибуты для каждой сущности, а затем установить ключевые атрибуты для каждой сущности, обращая внимание на то, что дочерние сущности наследуют ключевые атрибуты от родительских

.

Рисунок. Определение ключевого атрибута

Для этого двойным щелчком мыши по сущности откроем окно редактирования ее свойств, перейдем в категорию Столбцы, по нажатию кнопки Добавить введем имя поля Чтобы сделать атрибут ключевым, необходимо отметить галочкой пункт РК. Данное поле становится обязательным автоматически.

Аналогичным образом зададим ключевые атрибуты для всех сущностей информационной модели. Для того чтобы получить полную атрибутивную модель, необходимо дополнить сущности не ключевыми атрибутами. Примечание. Если атрибут не является обязательным, нужно убедиться, что в окне Свойства базы данных в категории Столбцы в пункте Обязательное не стоит галочка. Не обязательные к заполнению атрибуты справа от имени имеют пометку (О).

 

 Рисунок. Скорректированная информационная модель, основанная на ключах

Разработанный выше пример ER-диаграммы является примером концептуальной диаграммы. Это означает, что диаграмма не учитывает особенности конкретной СУБД. По данной концептуальной диаграмме можно построить физическую диаграмму, которая уже будут учитываться такие особенности СУБД, как допустимые типы и наименования полей и таблиц, ограничения целостности и т.п.

Практическое задание В. Расширьте созданную информационную модель, используя следующее текстовое описание.

На оптовом предприятии товары не только покупаются покупателями, но и поставляются поставщиками на склад. Как поставщик поставляет товары? Он делает поставку, которая подтверждается документом Товаротранспортная накладная. Таким образом, поставка рассматривается как самостоятельный объект. Один поставщик может осуществить несколько поставок, но каждая поставка осуществляется только одним поставщиком – это связь "один ко многим". Каждая поставка может содержать несколько товаров, а один и тот же товар может содержаться в нескольких поставках. Но связи "многие ко многим" недопустимы в реляционной модели, поэтому такую связь надо заменить на две связи "один ко многим". Делается это добавлением промежуточного объекта Журнал поставок, со связями "один ко многим" (один журнал поставок может включать несколько поставок, но каждая поставка может входить только в один журнал, аналогично и для остальных

Практическое задание Г. Постройте концептуальную информационную модель для предметной области «Прием коммунальных платежей в среде многофункциональной автоматизированной банковской системы»:

Концептуальная модель содержит следующие сильные сущности: «Пользователи», «Полу­чатели», «Группы получателей», «Плательщики», «Тарифы», «Кассовые документы», «Банковские атрибуты», «Проводки», «Отчеты», «Настройки». «Отделения» и слабую сущность «Квитан­ция».

Сущность «Получатели» предназначена для хранения информации об организациях-получателях, с которыми коммерческий банк заключил договор, а также о тех получателях, с ко­торыми договор не заключен. В этом случае информация представляется плательщиком. Сущ­ность включает следующие атрибуты:

табельный номер,

наименование получателя,

дата первоначальной инициализации получателя,

банковский идентификационный номер,

краткое наименование,

расчетный счет,

адрес.

Сущность «Получатели» соединена с сущностью «Тип платежа» связью с кардинально­стью «один-ко- многим», т.к. один получатель может иметь несколько типов платежей. В част­ности, для ОАО «Водоканал» существует два типа платежей – «За водоснабжение» и «Прочие платежи». Степень участия сущности «Получатели» в рассматриваемой связи является полной, а сущности «Тип платежа» – частичной.

Анализируемая сущность «Получатели» соединена с сущностью «Квитанции» связью с кардинальностью «один-ко-многим». Это определяется тем, что в адрес одной организации по­ступает произвольное количество квитанций.

Сущность «Группы получателей» предназначена для представления информации об осо­бенностях, присущих подмножеству получателей. К атрибутам этой сущности относятся:

номер группы,

наименование группы,

способ формирования платежных документов (по каждой квитанции, по каждому получателю, по всей группе),

момент взимания комиссии (по требованию кассового работника, непосредственно после регистрации квитанции),

документ, которым зачисляется комиссия на счет доходов банка,

момент формирования документов платежа (по требованию кассового работника, непо­средственно после регистрации квитанции),

момент печати документов.

Сущность «Группа получателей» соединена с сущностью «Получатели» связью с карди­нальностью «один-ко-многим», так как группа получателей объединяет нескольких получателей.

Степень участия сущности «Группа получателей» в рассматриваемой связи является полной, а сущности «Получатели» - частичная.

Аналогично представляется информация и об остальных сущностях и связях между ними.


Дата добавления: 2018-04-04; просмотров: 1920; Мы поможем в написании вашей работы!

Поделиться с друзьями:






Мы поможем в написании ваших работ!