ERwin имеет два уровня представления модели - логический и физический. Логический уровень - это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире. Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель данных может быть построена на основе другой логической модели, например на основе модели процессов. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД.
Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация о всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах - таблицах, колонках, индексах, процедурах и т. д. Разделение модели данных на логические и физические позволяет решить несколько важных задач:
1. Документирование модели. Многие СУБД имеют ограничение на именование объектов (например, ограничение на длину имени таблицы или запрет использования специальных символов - пробела и т. п.). Зачастую разработчики ИС имеют дело с нелокализованными версиями СУБД. Это означает, что объекты БД могут называться короткими словами, только латинскими символами и без использования специальных символов (т. е. нельзя назвать таблицу предложением - только одним словом). Кроме того, проектировщики БД нередко злоупотребляют "техническими" наименованиями, в результате таблица и колонки получают наименования типа RTD_324 или CUST_A12 и т. д. Полученную в результате структуру могут понять только специалисты (а чаще всего только авторы модели), ее невозможно обсуждать с экспертами предметной области. Разделение модели на логическую и физическую позволяет решить эту проблему. На физическом уровне объекты БД могут называться так, как того требуют ограничения СУБД. На логическом уровне можно этим объектам дать синонимы - имена более понятные неспециалистам, в том числе на кириллице и с использованием специальных символов. Например, таблице CUST_A12 может соответствовать сущность Постоянный клиент. Такое соответствие позволяет лучше задокументировать модель и дает возможность обсуждать структуру данных с экспертами предметной области.
2. Масштабирование. Создание модели данных, как правило, начинается с создания логической модели. После описания логической модели, проектировщик может выбрать необходимую СУБД и ERwin автоматически создаст соответствующую физическую модель. На основе физической модели ERwin может сгенерировать системный каталог СУБД или соответствующий SQL-скрипт. Этот процесс называется прямым проектированием (Forward Engineering). Тем самым достигается масштабируемость - создав одну логическую модель данных, можно сгенерировать физические модели под любую поддерживаемую ERwin СУБД. С другой стороны, ERwin способен по содержимому системного каталога или SQL-скрипту воссоздать физическую и логическую модель данных (Reverse Engineering). На основе полученной логической модели данных можно сгенерировать физическую модель для другой СУБД и затем сгенерировать ее системный каталог. Следовательно, ERwin позволяет решить задачу по переносу структуры данных с одного сервера на другой. Например, можно перенести структуру данных с Oracle на Informix (или наоборот) или перенести структуру dbf-файлов в реляционную СУБД, тем самым облегчив решение по переходу от файл-серверной к клиент-серверной ИС. Заметим, однако, что формальный перенос структуры "плоских" таблиц на реляционную СУБД обычно неэффективен. Для того чтобы извлечь выгоды от перехода на клиент-серверную технологию, структуру данных следует модифицировать.
Создание логической и физической модели поэтапно:
1. Запустите ERwin (кнопка «Пуск» на рабочем столе/ Программы/ Computer Associates/ AllFusion/ ERwin Data Modeler/ ERwin).
2. В открывшемся окне «ModelMart Connection Manager» нажать на кнопку «Cancel». Далее в открывшемся окне «Computer Associates ERwin» так же нажимаем на кнопку «Cancel».
3. Появляется диалоговое окно «Computer Associates ERwin» (см. рисунок 3.4). В этом окне вберите опцию «Create a new model» (Создание новой модели) и щелкните по кнопке OK (Создать).
Рисунок 3.4 – Выбор типа модели
Обратите внимание на то, что диалоговое окно «Computer Associates ERwin» (рисунок 3.4) позволяет открыть уже существующую модель данных с помощью выбора опции «Open an existing file» (Открытие существующего файла).
4. Откроется диалоговое окно «Create Model – Select Template» (Создание модели – Выбор шаблона) (см. рисунок 3.5).
Рисунок 3.5 – Выбор шаблона модели
Во фрейме «New Model Type» установите опцию «Logical/Physical», а во фрейме «Target Database» (Целевой сервер базы данных) установите в раскрывающемся окне списка систему управления базой данных (СУБД).
5. Автоматически создается незаполненная модель данных ERwin (см. рисунок 3.6). Таким образом, вы получили доступ к интерфейсу среды ERwin.
Рисунок 3.6 – незаполненная модель данных ERwin
Рабочее пространство ERwin включает окно диаграммы (поле для построения модели) и проводник модели.
6. В поле для построения модели, строим логическую и физическую модель базы данных.
Для переключения между логической и физической моделью данных служит список выбора в левой части панели инструментов Erwin (рисунок 3.7).
Рисунок 3.7 - Переключение между логической и физической моделью
При переключении, если физической модели еще не существует, она будет создана автоматически.
Для создания сущностей и связей между ними предназначена панель «Toolbox» (см. рисунок 3.8, таблицу 3.4).
Рисунок 3.8 – Панель «Toolbox»
Таблица 3.4 – Назначение кнопок
| Вид кнопки | Назначение кнопки |
| Кнопка указателя (режим мыши) – в этом режиме можно устанавливать фокус на каком-либо объекте модели. Всегда переходите в режим указателя мыши после редактирования объекта. |
| Кнопка внесения сущности – для внесения сущности нужно щелкнуть левой кнопкой мыши по кнопке внесения сущностей и по свободному пространству на модели. Повторный щелчок приведет к внесению в модель новой сущности. Для редактирования сущностей или других объектов модели необходимо перейти в режим указателя. |
| Кнопка категории. Категория, или категориальная связь, - специальный тип связи между сущностями, которая будет рассмотрена ниже. Для установления категориальной связи нужно щелкнуть левой кнопкой мыши по кнопке категории, затем один раз щелкнуть по сущности - родовому предку, затем - по сущности - потомку |
| Создание идентифицирующей связи. Для связывания двух сущностей нужно щелкнуть по кнопке, далее - по сущности-родителю, затем - по сущности-потомку. |
| Создание связи "многие ко многим". |
| Создание не идентифицирующей связи. |
Для внесения сущности в модель необходимо (убедившись предварительно, что вы находитесь на уровне логической модели) щелкнуть левой кнопкой мыши по кнопке внесения сущностей 
и по свободному пространству на модели. Затем кликнув правой кнопкой мыши по сущности, выбираем из всплывающего меню пункт «Entity Editor...». В открывшемся диалоге «Entities» (см. рисунок 3.9) определяются имя (Name), описание и комментарии сущности.
Рисунок 3.9 - Диалог «Entities»
Каждая сущность должна быть полностью определена с помощью текстового описания в закладке «Definition». Закладки «Note», «Note2», «Note3», «UDP» (User Defined Properties – Свойства определенные пользователем) служат для внесения дополнительных комментариев и определений сущности:
Definition - используется для ввода определения сущности.
Note - можно ввести полезное замечание, описывающее какое-либо бизнес-правило или соглашение по организации диаграммы.
Note 2 - можно задокументировать некоторые возможные запросы, которые, как ожидается, будут использоваться по отношению к сущности в БД.
Note 3 - позволяет вводить примеры данных для сущности (в произвольной форме).
Icon - каждой сущности можно поставить в соответствие изображение (файл bmp), которое будет отображаться в режиме просмотра модели на уровне иконок.
Для внесения атрибутов в сущность необходимо щелкнуть левой кнопкой мыши по сущности, выбрать из всплывающего меню пункт «Attributes…». Откроется диалоговое окно «Attributes» (см. рисунок 3.10).
Каждый атрибут хранит информацию об определенном свойстве сущности. Каждый экземпляр сущности должен быть уникальным. Атрибут или группа атрибутов, которые идентифицируют сущность, называется первичным ключом.
Рисунок 3.10 – Диалог «Attributes»
Для создания атрибута кликнуть по кнопке «New...», в появившемся диалоге «New Attribute» (см. рисунок 3.11) следует указать имя атрибута, имя соответствующей ему колонки и домен. Домен атрибута будет использоваться при определении типа колонки на уровне физической модели.
Рисунок 3.11 – Диалог «New Attribute»
После создания атрибута, во вкладке «Datatype» диалога «Attributes» следует указать тип данных для этого атрибута (зависти от типа выбранной СУБД, будет отображаться на физическом уровне). Для атрибутов первичного ключа в закладке «Key Group» диалога «Attributes» необходимо сделать пометку в окне выбора «Primary Key» (см. рисунок 3.10). При определении первичного ключа может быть рассмотрено несколько наборов атрибутов. Такие наборы называются потенциальными ключами. К первичным ключам предъявляются определенные требования:
- первичный ключ должен однозначно идентифицировать экземпляр сущности;
- первичный ключ должен быть компактен, то есть удаление любого атрибута из состава первичного ключа должно приводить к потере уникальности экземпляра сущности;
- каждый атрибут из состава первичного ключа не должен принимать null – значений;
- каждый атрибут первичного ключа не должен менять свое значение в течение всего времени существования экземпляра сущности.
Для установки связи между сущностями нужно воспользоваться кнопками 
в палитре инструментов.
На логическом уровне можно установить идентифицирующую связь один ко многим, связь многие ко многим и не идентифицирующую связь один ко многим (соответственно кнопки - слева направо в палитре инструментов).
Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. Зависимая сущность изображается прямоугольником со скругленными углами. Экземпляр зависимой сущности определяется только через отношение к родительской сущности, то есть в структуре. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности переносятся в состав первичного ключа дочерней сущности (миграция атрибутов). В дочерней сущности они помечаются как внешний ключ - (FK). При установлении не идентифицирующей связи дочерняя сущность остается независимой, а атрибуты первичного ключа родительской сущности мигрируют в состав не ключевых компонентов родительской сущности.
Для редактирования свойств связи следует кликнуть правой кнопкой мыши по связи и выбрать на контекстном меню пункт «Relationship Properties». В появившемся диалоге «Relationships» можно задать (см. рисунок 3.12):
Cardinality (Мощность связи) - служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней.
Verb Phrase - фраза, характеризующая отношение между родительской и дочерней сущностями.
Relationship (Тип связи) - идентифицирующая / не идентифицирующая.
Описание связи.
Правила ссылочной целостности (будут сгенерированы при генерации схемы БД).
Имя роли. Имя роли - это синоним атрибута внешнего ключа, которое необходимо, например, при циклической связи. В этом случае нельзя иметь два атрибута с одинаковым именем внутри одной сущности. При задании имени роли атрибут мигрирует в качестве внешнего ключа в состав не ключевых атрибутов с именем роли.
Рисунок 3.12 – Диалог «Relationships»
Связь многие ко многим возможна только на уровне логической модели данных. При переходе к физическому уровню ERwin автоматически преобразует связь многие ко многим, добавляя новую, ассоциативную сущность и устанавливая две новые связи один ко многим от старых к новой сущности.
Различают четыре типа мощности:
- общий случай, когда одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности, не помечается каким-либо символом;
- символом P помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение);
- символом Z помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключены множественные значения);
- цифрой помечается случай точного соответствия, когда одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочерней сущности.
7. Созданная физическая модель может быть перенесена в среду целевой СУБД-сервера.
3.5. Графический интерфейс информационной системы. Сделать скриншоты и краткое описание интерфейса информационной системы.
Пример:
Дважды щелкнув на ярлык системы в браузере появиться окно авторизации вида, рисунок 3.1.
Рисунок 3.1 – Вход в информационную систему
Далее в первом раскрывающемся полнее, нужно выбрать режим, под которым мы хотим войти (Администратор или Кассир), во втором поле мы вводим пароль.
Переключение между полями производится кнопкой « Tab » или курсором мыши.
Войдя в систему под режимом администратора, открывается окно администратора, рисунок 3.2.
Рисунок 3.2 – Окно «Администратор»
В режиме администратора нам доступны следующие функции меню:
- продажа товара по штрих коду, печать товарного чека, рисунок 3.3;
Рисунок 3.3 – Товарный чек
- добавление, изменение и перемещение категории;
- добавление, изменение и перемещение нового товара, рисунок 3.3;
Рисунок 3.3 – Добавление товара
- операции с имеющимся товаром, рисунок 3.4;
Рисунок 3.4 – Меню товаров
- меню отчетов, рисунок 3.4;
Рисунок 3.4 – Меню отчетов
- меню операций, рисунок 3.5;
Рисунок 3.5 – Меню операций
Рисунок 3.6 – Журнал накладных
Рисунок 3.7 – Журнал операций
Рисунок 3.8 – Учет прихода товара
Рисунок 3.7 – Журнал накладных
- меню свойства, входит 1 подпункт – Настройки, рисунок 3.8;
Рисунок 3.8 – Настройки
- меню маркетинг, рисунок 3.9;
Рисунок 3.9 – Меню маркетинг
- меню конфигурации, рисунок 3.10;
Рисунок 3.10 – Меню конфигурации
- меню пользователя, в ней описаны данные пользователей и их права.
Войдя в систему под режимом кассир, открывается окно кассира, рисунок 3.11.
Рисунок 3.11 – Меню кассира
Главное отличие меню кассира, от меню администратора, это отсутствие клавиш добавления, удаление, редактирования, перемещения категорий и товаров. Остальные функции ограниченны согласно настройкам администратора.
Выходные данные информационной системы приведены в приложении А.
Результаты анализа информационной системы приведены в приложении Б.
Экономическая часть проекта
В экономической части проекта следует сделать:
4.1. Расчет трудоемкости проекта.
Пример:
Разработка информационной системы торгового предприятия включает в себя:
- анализ предметной области;
- проектирование информационной системы;
- реализация информационной системы;
- подготовка к эксплуатации информационной системы;
- внедрение информационной системы.
Расчет трудоемкости проекта представлен в таблице 4.1.
Таблица 4.1 – Перечень работ и их трудоемкость
| Этапа | № Работы | Содержимое работы | Трудоемкость | |
| чел.- час | чел.- дней | |||
| 1 | 2 | 3 | 4 | 5 |
| 1. Анализ предметной области | 1 | Краткий обзор существующих систем | 40 | 5 |
| 2 | Описание информационных систем в торговых предприятиях | 24 | 3 | |
| 2. Проектирование информационной системы | 3 | Предварительное обследование торгового предприятия | 48 | 6 |
| 4 | Разработка Диаграммы взаимодействия | 32 | 4 | |
| 5 | Описание основных бизнес-процессов предприятия | 88 | 11 | |
| 6 | Создание функциональной модели информационной системы | 56 | 7 | |
| 7 | Моделирование вариантов использования | 48 | 6 | |
| 3. Реализация информационной системы | 8 | Разработка требований к ИС | 24 | 3 |
| 9 | Выбор архитектуры | 16 | 2 | |
| 10 | Выбор СУБД | 16 | 2 | |
| 11 | Разработка структуры базы данных | 56 | 7 | |
| 12 | Реализация базы данных | 48 | 6 | |
| 13 | Разработка программных модулей | 176 | 22 | |
| 14 | Разработка графического интерфейса программы | 72 | 9 | |
| 4. Подготовка и эксплуатация информационной системы | 15 | Тестирование системы | 96 | 12 |
| 16 | Отладка и исправление недочетов | 64 | 8 | |
| 5. Внедрение информационной системы | 17 | Установка и настройка БД | 16 | 2 |
| 18 | Установка и настройка ПО | 16 | 2 | |
| 19 | Подготовка пользователей | 24 | 3 | |
| Итог: | 960 | 120 | ||
Количество исполнителей проекта – 1 инженер-програмист.
4.2. Определение расходов на оплату труда.
Пример:
Расчет расходов на оплату труда исполнителей 
, руб., определяется по формуле
(4.1)
где 
– основная заработная плата, руб.;
– дополнительная заработная плата, руб.;
– страховые отчисления, руб.
Расчет расходов на выплату основной заработной платы 
, руб., производится на основе количества исполнителей, занятых в разработке, трудоемкости работ и средней заработной плате разработчика.
(4.2)
где 
– количество разработчиков;
– средняя заработная плата разработчика, руб./час;
– трудоемкость проекта, час.
В разработке информационной системы занят один программист. Средняя часовая заработная плата программиста 
, руб./час, будет рассчитана на основе месячного оклада и месячного фонда рабочего времени.
(4.3)
где 
– месячный оклад разработчика, руб.;
– фонд времени в текущем месяце, час., рассчитывается из учета общего числа дней в году, числа выходных и праздничных дней.
, (4.4)
где 
– продолжительность рабочего дня, час;
– общее число дней в году;
– число выходных дней в 2012 году (без учета праздничных);
– число праздничных дней в 2012 году (согласно производственному календарю).
На основе формул (4.3 – 4.4) получено соотношение для расчета средней часовой заработной платы разработчика.
(4.5)
В данном дипломном проекте установлен месячный оклад работника соответствующей должности, занимаемой в проектно-конструкторском отделе Красноярского ИВЦ: инженер-программист – 30000 рублей.
При месячном окладе разработчика 
рублей и продолжительности рабочего дня 
часов средняя часовая заработная плата 
составляет 
рублей.
Для среднечасовой зарплаты программиста 
рублей общие расходы на выплату основной заработной платы исполнителям в процессе реализации информационной системы торгового предприятия составят 
рубля. Расчет основной заработной платы приведен в таблице 4.2.
Таблица 4.2 – Затраты на оплату труда в процессе реализации проекта
| Должность | Количество человек | Трудоемкость работ (час) | Средняя з/п разработчиков (руб./час) | З/п исполнитель (руб.) |
| Инженер-программист | 1 | 960 | 181,5 | 174240 |
| Итого: | 174240 | |||
Расходы на дополнительную заработанную плату , руб., включают доплаты, надбавки, гарантийные и компенсационные выплаты, предусмотренные законодательством, премии за выполнение производственных заданий и функций. Величина этих выплат составляет 20% от размера основной заработной платы.
(4.6)
Для разработки информационной системы торгового предприятия расходы на выплату дополнительной заработной платы составляет 
рублей.
Страховые отчисления в 2012 году установлены в размере 34% от заработной платы 
рубль.
Согласно формуле (4.1), общие расходы на оплату труда разработчика составят 
рублей.
4.3. Определение накладных расходов.
Пример:
Накладные расходы 
, руб., определяются в процентном отношении к основной заработной плате разработчика . Коэффициент, определяющий величину накладных расходов, может отличаться на различных предприятиях. Примем его равным 25% от
, (4.7)
Для разработки программного комплекса мониторинга судовых систем накладные расходы составят 
рублей.
4.4. Определение эксплуатационных расходов.
Пример:
Расходы на персональный компьютер определяются материальными расходами в течение срока разработки программного продукта и стоимостью компьютера.
Расходы на электроэнергию ( 
)
(4.8)
где 
– мощность компьютера (0,3 Квт/ч);
– стоимость 1 Квт/ч. (0,91 руб.);
– время разработки (960 часов);
рублей.
Стоимость расходных материалов ( 
).
Затраты на расходные материалы в течение всего срока эксплуатации составляют примерно 10% от стоимости компьютера. Срок эксплуатации персонального компьютера – 3 года. Следовательно, можно определить подобные расходы за период создания программного обеспечения.
(4.9)
где 
– количество дней в году (365 дней); 
– стоимость компьютера = 25000 рублей («ДНС» от 17.04.2012);
– срок разработки в рабочих днях (120 дней);
рублей.
По статистике, расходы на комплектующие изделия 
для ремонта ПК составляют 10% от стоимости ПК за срок его эксплуатации. Следовательно, можно определить подобные расходы за период создания программного обеспечения.
(4.10)
рублей.
Амортизационный период ПК в настоящее время равен сроку морального старения вычислительной техники и составляет 3 года. Следовательно, за 3 года 
равны стоимости компьютера.
(4.11)
где 
– срок службы ПК (3 года);
рублей.
Амортизационные отчисления на программное обеспечение ( 
) зависят от цикла замены ПО. Примем срок морального старения равным 3 годам.
(4.12)
где 
– стоимость ПО (7319 рублей).
Стоимость ПО включает в себя:
- Microsoft "Windows 7 Максимальная" Русская версия DVD (ВОХ) [GLC-00263, GLC-02276] = 10290 рублей («ДНС» от 17.04.2012);
- ErWin лицензия = 20850 рублей;
– срок службы ПО (3 года);
рублей.
Дополнительные расходы ( 
) будем считать равными нулю, т.к. при реализации проекта разработчик занимал уже созданное рабочее место, и дополнительные условия для разработки не создавались.
Суммарные эксплуатационные расходы вычисляются по формуле:
(4.13)
Эксплуатационные расходы на ПК в течение срока создания информационной системы торгового предприятия составили 
рублей.
Расчет эксплуатационных расходов приведен в таблице 4.3.
Таблица 4.3 – Эксплуатационные расходы на ПК в течение срока создания информационной системы
| Статья расхода | Затраты (руб.) |
| Расходы на электроэнергию | 262,1 |
| Стоимость расходных материалов | 274 |
| Расходы на ремонт | 274 |
| Амортизация ПК | 12739,7 |
| Амортизация ПО | 3412,6 |
| Дополнительные расходы | 0 |
| Итого: | 16962,4 |
4.5 Определение себестоимости проекта.
Пример:
Определив затраты на оплату труда, социальные нужды, накладные расходы, можно определить себестоимость проекта, она отображена в таблице 4.4 [13].
Таблица 4.4 – Себестоимость проекта
| Наименование затрат | Всего, руб. |
| Основная заработная плата | 174240 |
| Дополнительная заработная плата | 34848 |
| Социальные отчисления | 59241,6 |
| Накладные расходы | 43368 |
| Эксплуатационные расходы | 16962,4 |
| Общая стоимость | 328660 |
Рисунок 4.1 – Структура затрат на разработку программного комплекса обработки данных наблюдения за технической системой
4.6. Выводы по организационно-экономической части.
Пример:
На основании вышеизложенного, можно сказать, что для разработки системы одним инженером-программистом потребуется 120 рабочих дней, себестоимость разработки составит 330186,5 рублей.
Система является очень выгодной с экономической точки зрения, так как она объединяет в себе аналитическую систему и автоматизирует основные бизнес-процессы предприятия, минимизирует человеческий фактор. При этом в качестве результата внедрения мы получаем сокращение операционных издержек, получение дополнительных доходов вследствие увеличения оборота магазина и более качественного анализа по продажам, что помогает более точно отследить спрос покупателей на товар.
К примеру, на разработку таких программ как: 1С-Papyc: Магазин; БЭСТ-Магазин 1С; Управление Торговлей 8.0; Маркет М; Тирика-Магазин была потрачена сумма в пределах от 500000 рублей, до 1000000 рублей, так как эти системы были реализованы на коммерческих языках программирования и к тому же требуют дополнительного программного обеспечения, которое стоит денег. Наша система была реализована на классе Open Source (открытые исходные тексты), которая является бесплатной, что позволяет сократить затраты на ее производство и обслуживание.
Дата: 2019-04-23, просмотров: 478.
