- •Реферат
- •Abstract
- •Содержание
- •Введение
- •1Результаты предпроектного обследования. Формулировка задач проектирования
- •1.1 Описание предметной области
- •1.2 Обоснование необходимости создания аис
- •1.3 Обзор существующих разработок
- •1.4 Выбор комплекса задач, подлежащих автоматизации
- •1.5Выбор средств реализации
- •2Техническое задание
- •2.1 Общие сведения
- •2.2 Назначение и цели создания системы
- •2.3 Характеристика объекта автоматизации
- •2.4 Требования к системе
- •2.4.1 Требования к структуре и функционированию системы
- •2.4.2 Требования к численности и квалификации персонала
- •2.4.3 Требования к надежности
- •2.4.4 Требования к защите информации от несанкционированного доступа
- •2.4.5 Требования по сохранности информации при авариях
- •2.4.6 Дополнительные требования
- •2.4.7 Требования к функциям, выполняемым системой
- •2.4.8 Требования кинформационномуобеспечению
- •2.4.9 Требования кпрограммномуобеспечению
- •2.4.10 Требования ктехническомуобеспечению
- •2.5 Состави содержаниеработ по созданию системы
- •3.1.1 Концептуальная модель предметной области
- •3.2.2 Внутренняя модель предметной области
- •3.3 Характеристика входной информации
- •3.4 Характеристика выходной информации
- •3.6 Разработка пользовательского интерфейса
- •4Описание применения
- •4.1 Назначение программы
- •4.2 Условия применения
- •4.3 Описание задачи
- •4.3.1Подсистема взаимодействия с клиентами
- •4.3.2АрМоператора закупки
- •4.3.3АрМоператора склада
- •4.3.4 Подсистема управления и мониторинга
- •4.5 Входные и выходные данные
- •5Технико-экономическое обоснование проекта
- •5.1 Обоснование целесообразности разработки проекта
- •5.2 Оценка уровня качества разрабатываемого продукта
- •5.3 Организация и планирование работ по разработке проекта
- •5.4 Расчет затрат на разработку проекта
- •5.5 Расчет эксплуатационных затрат
- •5.6 Оценка эффективности разработанного проекта
- •6Безопасность жизнедеятельности
- •6.1Перечень и анализосновных опасных и вредных факторовв рабочем помещении и на рабочем месте пользователя пэвм
- •6.2 Микроклимат
- •6.3 Шум и вибрация
- •6.4 Электромагнитные излучения
- •6.5 Электробезопасность
- •6.6 Освещение
- •6.7 Расчет световых характеристик помещения
- •Заключение
- •Список использованных источников
- •Приложение а. Экранные формы
3.1.1 Концептуальная модель предметной области
Основными конструктивными элементами концептуальной модели являются сущности, их атрибуты (свойства) и связи между сущностями. Сущность – любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущности и связи между ними концептуальной модели представляются в виде реляционной таблицы (отношения). Отношение, соответствующее сущности, содержит атрибуты (столбцы), являющиеся атрибутами сущности и описывающие сущность (объект). Атрибут или некоторое множество атрибутов, которые однозначно определяют объект называются первичным ключом.
Удобно представлять отношение как таблицу, где каждая строка есть кортеж, и каждый столбец соответствует одному компоненту. Столбцы при этом называются атрибутами и им присваивают имена. Список имён атрибутов называется схемой отношения. Совокупность схем отношений, используемых для представления информации, называются схемой базы данных, а текущие значения соответствующих отношений – базой данных.
При разработке концептуальной модели, прежде всего, следует определить сущности. С этой целью нужно сделать следующее:
необходимо понять, какая информация должна храниться и обрабатываться и можно ли это определить как сущность;
присвоить этой сущности имя;
выявить атрибуты сущности и присвоить им имя;
определить уникальный идентификатор сущности.
Выявив сущности, необходимо определить, какие связи имеются между ними, т.к. именно эти связи и определяют в конечном итоге интегрированную базу данных.
При определении связей (естественно, рассматриваем только те связи, которые имеют отношение к решаемым задачам) необходимо учитывать следующее:
то, как экземпляр одной сущности связан с экземпляром другой сущности;
то, как должны быть установлены связи, чтобы была возможность ответа на все запросы пользователей (исходя из их информационных потребностей).
Далее необходимо присвоить связям имена и определить тип связей.
На втором этапе построенные локальные модели объединяются в обобщенную концептуальную модель, после чего необходимо привести модель к требуемому уровню нормальной формы.
На основании результатов анализа предметной области выделены ее сущности (таблица 3.1), а также атрибуты этих сущностей (таблица 3.2):
Таблица 3.1 – Перечень сущностей предметной области
Идентификаторсущности |
Назначение |
Client |
Заказчик |
Order |
Заказ |
OrderItem |
Позиция заказа (конкретный заказанный товар) |
Invoice |
Счет на оплату заказа |
Basket |
Корзина покупок |
ParcelIn |
Входящая посылка, поступившая из магазина |
ParcelOut |
Исходящая посылка, доставляющая клиентам выкупленные для них товары |
ParcelOutItems |
Элемент содержимого исходящей посылки (каждая отдельно взятая покупка) |
Таблица 3.2 – Атрибуты сущностей предметной области
Сущность |
Атрибут |
Назначение |
1 |
2 |
3 |
Client |
client_id |
Идентификатор заказчика (Перв. ключ) |
fullname |
Полное имя заказчика | |
|
Адрес электронной почты | |
address |
Почтовый адрес | |
city |
Город | |
state |
Область, край, республика | |
postcode |
Почтовый индекс | |
country |
Страна | |
phonenumber |
Телефонный номер | |
password |
Пароль | |
Order |
order_id |
Идентификатор заказа (Перв. ключ) |
ordernum |
Внутренний номер заказа | |
client_id |
Идентификатор заказчика (Внеш. ключ) | |
date |
Дата размещения заказа | |
invoice_id |
Идентификатор счета (Внеш. ключ) | |
status |
Статус заказа | |
notes |
Заметки | |
OrderItem |
orderitem_id |
Идентификатор товара (Перв. ключ) |
order_id |
Идентификатор заказа (Внеш. ключ) | |
orderitemstatus |
Статус товара | |
basket_id |
Идентификатор корзины (Внеш. ключ) | |
room |
Литер помещения склада | |
rack |
Номер стеллажа | |
shelf |
Номер полки | |
place |
Номер места на полке | |
title |
Наименование товара | |
url |
URLстраницы с описанием товара | |
code |
Артикул товара | |
color |
Цвет товара | |
size |
Размер товара | |
price |
Цена товара | |
amount |
Заказанное количество экземпляров | |
photo |
Фотография товара | |
parcelout_id |
Идентификатор исходящей посылки (Внеш. ключ) |
Продолжение таблицы 3.2
Invoice |
invoice_id |
Идентификатор счета (Перв. ключ) |
invoicenum |
Внутренний номер счета | |
invoicedate |
Дата выставления счета | |
duedate |
Дата окончания действия счета | |
datepaid |
Дата фактической оплаты | |
subtotal |
Сумма счета | |
credit |
Сумма, погашенная за счет средств с виртуального лицевого счета заказчика | |
invoicestatus |
Статус счета | |
paymentmethod |
Использованный способ оплаты | |
invoicenotes |
Заметки | |
Basket |
basket_id |
Идентификатор корзины (Перв. ключ) |
baskettitle |
Наименование | |
datecreated |
Дата создания | |
datepassedtoshopping |
Дата передачи на выкуп товаров | |
datecompleted |
Дата завершения выкупа товаров | |
basketstatus |
Статус корзины | |
basketnotes |
Заметки | |
ParcelIn |
parcelin_id |
Идентификатор входящей посылки (Перв. ключ) |
date_arrival |
Дата поступления | |
sender |
Информация об отправителе | |
senderpostcarrier |
Почтовый оператор | |
sendertracking |
Трек-номер посылки | |
basket_id |
Идентификатор корзины, в рамках выкупа которой поступила посылка (Внеш. ключ) | |
parcelinnotes |
Заметки | |
ParcelOut |
parcelout_id |
Идентификатор отправленной посылки (Перв. ключ) |
parceloutaddress |
Адрес назначения посылки | |
dateshipping |
Дата отправки | |
postcarrier |
Почтовый оператор | |
tracking |
Трек-номер посылки | |
length |
Длина | |
width |
Ширина | |
height |
Высота | |
weight |
Вес | |
parceloutnotes |
Заметки |
ER-диаграмма системы на уровне концептуальной модели представлена на рисунке 3.1.
Рисунок 3.1 ER-диаграмма системы на уровне концептуальной модели
БД как модель предметной области отражает ее реальное состояние в любой фиксированный момент времени в виде текущей конфигурации хранимых данных. При этом любое хранимое в БД значение любого семантически значимого атрибута в любой момент времени должно быть истинным значением характеристики соответствующего объекта предметной области. Кроме того, состояние БД в любой момент времени должно иметь осмысленную интерпретацию в терминах предметной области. Это называется требованием поддержания целостности состояния БД.
В рассматриваемой структуре БД каждая сущность идентифицируется уникальным ключом, разработана система внешних ключей. База данных не содержит несогласованных значений внешних ключей, то есть при работе с записями обеспечивается возможность каскадного обновления связанных полей и каскадного удаления связанных записей. Целостность, определяемая пользователем, поддерживается обеспечением выбора значений внешних ключей из списков без разрешения варианта ввода недопустимого значения.
Нормализация предусматривает определение требуемых атрибутов с последующим созданием из них нормализованных таблиц, основанных на функциональных зависимостях между этими атрибутами. Отношение, в котором на пересечении каждой строки и каждого столбца содержится атомарное (или единственное) значение, находится в 1-й нормальной форме. При этом необходимо, чтобы отношение имело первичный ключ.
Вторая нормальная форма применяется к отношениям с составными ключами, т.е. к таким отношениям, первичный ключ которых состоит из двух или более атрибутов. Отношение с первичным ключом на основе единственного атрибута всегда находится во 2-й нормальной форме. Отношение, которое находится в 1-й нормальной форме и каждый атрибут которого, не входящий в состав первичного ключа, зависит только от полного значения ключа и не зависит ни от какого отдельного атрибута, входящего в состав первичного ключа, имеет вторую нормальную форму (каждый неключевой атрибут функционально полно зависит от ключа).
Отношение находится в 3-й нормальной форме, если оно представлено во 2-й нормальной форме и не имеет не входящих в первичный ключ атрибутов, которые находились бы в транзитивной функциональной зависимости от этого первичного ключа.
Разработанная модель находится в 3-й нормальной форме, так как:
– атрибуты сущностей являются атомарными;
– каждый неключевой атрибут функционально полно зависит от первичного ключа;
– в модели отсутствуют транзитивные зависимости неключевых атрибутов от ключа.