Проектирование автоматизированной системы управления интернет продажами
Анализ объекта автоматизации. Описание организационно-штатной структуры фирмы. Выявление недостатков существующей технологии управления продажами. Проектирование ИС управления интернет торговлей. Обоснование модели БД в выбранной существующей системе.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 25.12.2011 |
| Размер файла | 2,4 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Филиал федерального государственного бюджетного образовательного учреждения высшего профессионального образования
«САМАРСКИЙ ГОСУДАРСТВЕННЫЙ АЭРОКОСМИЧЕСКИЙ УНИВЕРСИТЕТ имени академика С.П. КОРОЛЕВА (национальный исследовательский университет)»
в городе Тольятти Самарской области
Кафедра радиоэлектроники и системотехники
Проектирование автоматизированной системы управления интернет продажами
Тольятти 2011
Реферат
АВТОМАТИЗАЦИЯ, CASE ТЕХНОЛОГИИ, ОФОРМЛЕНИЕ ЗАКАЗОВ, ИНТЕРНЕТ МАГАЗИН, ПРИНЯТИЕ РЕШЕНИЙ, ИНФОЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ, ЛОГИЧЕСКАЯ МОДЕЛЬ ДАННЫХ, БАЗЫ ДАННЫХ.
Предметом исследования является процесс управления продажами, включающий в себя продвижение товаров на рынок и управление объёмами производства. Объект исследования - отдел продаж на фирме производства обуви «Rep'S».
Цель курсовой работы: спроектировать автоматизированную систему управления интернет продажами.
Создание системы управления продажами для фирмы «Rep'S» актуально, так как фирма нуждается в значительном расширении, а внедрение системы должно сильно сократить трудоёмкость оформления заказов, увеличить количество продаж. Новизной проектируемой системы является добавление в систему продаж модуля поддержки принятия решения о производстве продукции.
В результате проведённых исследований выяснилось, что для автоматизации процесса продаж на фирме «Rep'S» необходимо разработать систему, позволяющую оформлять заказы удалённо, полноценно работать с клиентами и упрощающую процесс принятия решений о производстве продукции для прямого сбыта. Для этого была разработана технология управления продажами и спроектирована база данных для описанной системы.
Содержание
- Введение 4
- 1. Описание и моделирование предметной области 6
- 1.1 Анализ объекта автоматизации 6
- 1.1.1 История фирмы «Rep'S» 6
- 1.1.2 Описание организационно-штатной структуры фирмы «Rep'S». Выделение области автоматизации 7
- 1.1.3 Постановка проблемы 8
- 1.2 Формализация существующих бизнес-процессов на фирме «Rep'S» 9
- 1.2.1 Моделирование существующей технологии управления продажами 9
- 1.2.2 Выявление недостатков существующей технологии управления продажами 12
- 1.2.3 Поиск путей решения проблем. Обоснование принятых решений 14
- 1.2.4 Формализация требований к будущей технологии 15
- 1.3 Выбор и обоснование технологии проектирования 16
- 2. Проектирование ИС управления интернет продажами 19
- 2.1 Выбор и разработка архитектуры системы 19
- 2.2 Разработка модели информационной системы управления интернет продажами 20
- 3. Проектирование базы данных ИС 25
- 3.1 Инфологическое (концептуальное) проектирование 25
- 3.2 Обоснование модели БД в выбранной существующей системе 27
- 3.3 Построение логической модели БД 27
- Заключение 31
- Литература 33
- Приложения 34
Введение
Мы живём в веке глобализации, автоматизации и рыночных отношений. Каждая фирма пытается выйти на рынок более высокого уровня, привлечь наибольшее число покупателей, увеличить объёмы производства продукции и показатели качества, то есть конкурентноспособность продукции. И тем самым, повысить уровень прибыли от предпринимательской деятельности. Но расширение производства и его совершенствование требует большого увеличения управленческого состава и обслуживающего персонала. В свою очередь этот фактор значительно повышает количество расходов, не связанных с производством продукции непосредственно. Фирма, рассматриваемая в данном проекте, развивается и нуждается в увеличении объёма продаж продукции. Для этого необходимо расширить рынок сбыта, то есть увеличить число покупателей. Это можно решить, в частности, путём разработки и внедрения интернет магазина, который будет достаточно полно отражать характеристики продукции, тем самым привлекать покупателей, и позволять составлять заказы удалённо. Так как производством и сбытом занимается фирма производитель, то для большей эффективности производства необходимо разработать систему анализа продаж и систему поддержки принятия решений по производству. Создание такой системы актуально, так как фирма нуждается в значительном расширении, а внедрение системы должно сильно сократить трудоёмкость оформления заказов, увеличить количество продаж. Новизной проектируемой системы является добавление в систему продаж модуля поддержки принятия решения для менеджера по продажам.
Предметом исследования является процесс управления продажами, включающий в себя продвижение товаров на рынок и управление объёмами производства. Объект исследования - отдел продаж на фирме производства обуви «Rep'S».
Цель курсового проекта: спроектировать автоматизированную систему управления интернет продажами.
Для достижения данной цели необходимо решить следующие задачи:
1. Рассмотреть структуру существующих процессов продаж на фирме и выявить их недостатки.
2. Рассмотреть возможные пути решения выделенных проблем и выбрать наиболее подходящий.
3. Сформулировать требования к будущей технологии управления продажами.
4. Разработать архитектуру и модель информационной системы.
5. Рассмотреть аналоги разрабатываемой системы и выбрать базовую систему для модификации (если это возможно).
6. Спроектировать/модифицировать базу данных.
Пояснительная записка состоит из введения, трех глав и заключения.
В первой главе описывается фирма, для которой проектируется система, определяется область автоматизации, рассматривается базовая технология, и выявляются её недостатки, производится поиск возможных путей решения и выбор наиболее подходящего. Также в этой главе будут сформулированы требования к будущей технологии и выбрано CASE-средство, в котором будет проектироваться новая технология.
Во второй граве разрабатывается архитектура будущей системы и сама предлагаемая технология. Также выбирается существующая система, которая будет модифицироваться под требования новой технологии. Это необходимо для сокращения времени и затрат на разработку.
В третьей главе проектируется база данных. Проектирование включает в себя построение инфологической модели данных, описание логической модели баз данных системы, взятой для модификации, и доработку логической модели баз данных до требований новой технологии.
1. Описание и моделирование предметной области
1.1 Анализ объекта автоматизации
В данном пункте описывается деятельность фирмы «Rep'S», организационно-штатная структура, краткая история возникновения и развития. Также будет определена автоматизации и выявлена проблема для автоматизации.
1.1.1 История фирмы «Rep'S»
Фирма «RepS» основана 19 марта 2004 года на Украине в городе Харькове. Данная фирма занимается производством обуви, включая разработку новых моделей, их создание и продвижение на рынок.
Директор фирмы долгое время был сапожником, а потом решил попробовать создать своё дело. Он арендовал помещение и набрал команду рабочих из четырёх человек. Начатое дело стало приносить свои результаты. Постепенно фирма развивалась, расширялись производственные площади, увеличивалось количество рабочих. Но это развитие фирмы происходило очень медленно из-за большой конкуренции и отсутствия стабильности продаж.
В настоящее время количество всех работников фирмы составляет 15 человек. Товарооборот составляет в среднем 1000 пар обуви в месяц. Всё производство сосредоточено в одном цехе. Налажен процесс конвейерного пошива.
1.1.2 Описание организационно-штатной структуры фирмы «Rep'S». Выделение области автоматизации
Организационно-штатная структура фирмы небольшая. Основная часть работников сосредоточена в цехе производства продукции.
Рисунок 1 - Организационно-штатная структура фирмы «Rep'S»
Директор контролирует процессы продаж и производства и учувствует в процессе планирования производства: формирует указания на разработку новых моделей и пошив обуви для реализации на рынке; закупает материалы; ведёт бухгалтерию.
Менеджер по продажам занимается продвижением товара на рынок: рекламирует продукцию, ищет покупателей, оформляет заказы, структурирует заказы для принятия решения по производству продукции.
Остальные работники участвуют непосредственно в изготовлении продукции.
В настоящее время самой проблемной областью на данной фирме является продвижение товара на рынок, так как именно этот процесс напрямую влияет на товарооборот и развитее фирмы. Следовательно, именно деятельность отдела продаж необходимо автоматизировать.
Функции отдела продаж:
1. Реклама.
2. Поиск покупателей.
3. Поддерживание контактов с покупателями.
4. Учёт требований покупателей к производимой продукции.
5. Формирование заказов.
6. Структурирование заказов для принятия решения по производству обуви.
7. Приём с производства и продажа товара.
Для развития производства все эти функции необходимо автоматизировать, чтобы оптимизировать затраты. Процессы продаж и планирования производства продукции для продажи неразрывно связаны. В планировании производства участие принимает директор. Таким образом, деятельность директора будет автоматизирована частично. После автоматизации эта функция директора будет переведена в обязанности отдела продаж.
1.1.3 Постановка проблемы
Фирма «Rep'S» развивается и нуждается в увеличении объёма продаж. Но существует несколько проблем, препятствующих развитию.
Чтобы увеличить количество продаж необходимо расширить рынок сбыта, найти новых покупателей. Если данную проблему решать путём увеличения сотрудников, которые будут рекламировать продукцию, то сильно увеличится состав работников, не связанных непосредственно с производством продукции. То есть появятся новые затраты. Для оптимизации этих затрат предлагается разработать систему, которая автоматизирует процесс продвижения товара на рынок.
Существует вторая причина, приводящая к необходимости разработки автоматизированной системы - процесс планирования производства трудоёмкий и специфичный. С одной стороны он занимает много времени на этапе исследования рынка и конкурентно способной продукции. С другой стороны часто из-за дефицита времени нет возможности детально исследовать рынок, решения принимаются интуитивно и не всегда являются правильными, что влечёт за собой потери от нереализованного товара. То есть при принятии решений присутствует человеческий фактор, который приводит к увеличению количества нереализованной продукции и, следовательно, к финансовым потерям.
1.2 Формализация существующих бизнес-процессов на фирме «Rep'S»
1.2.1 Моделирование существующей технологии управления продажами
Вся работа фирмы регламентируется внутренними документами организации, предпочтениями покупателей (учитываются в маркетинге). Процесс производства протекает в соответствии с технологией изготовления каждой модели обуви. Реклама продукции и выбор покупателя происходит на основе предоставляемого ассортимента - экземпляров продукции.
В процессах фирмы учувствуют:
ѕ клиент;
ѕ менеджер;
ѕ мастер;
ѕ рабочие.
Назначение каждого участника будет отображено в диаграммах бизнес-процессов.
Вспомогательными механизмами являются бланк оформления заказа и телефон, с помощью которого менеджер связывается с заказчиком.
Рисунок 2 - Диаграмма нулевого уровня процесса продаж при наличии определённого заказа на изготовление обуви
Работа фирмы при наличии заказа делится на 4 стадии:
1. Оформление заказа.
2. Проверка наличия товара на складе.
3. Выполнение заказа.
4. Передача заказа клиенту.
Рисунок 3 - Декомпозиция процесса продаж при наличии определённого заказа на изготовление обуви
Декомпозиции подлежат процессы «Оформить заказ» и «Отдать заказ».
Процесс «Отправить заказ на производство» не декомпозируется, так как оформление заказа и производство продукции происходят в одном здании. Передача заказа на производство не требует дополнительных ресурсов и механизмов. Этот процесс является целостным и не подлежит разложению на составляющие процессы.
Процесс «Выполнить заказ» не рассматривается, так как его организация не влияет на процесс оформления заказов.
Рисунок 4 - Декомпозиция процесса оформления заказа
Оформление заказа происходит вручную.
После того как заказ будет полностью выполнен, менеджер получает информацию о выполнении заказа, созванивается с заказчиком и передаёт товар.
Рисунок 5 - Декомпозиция процесса передачи заказа
На выходе работы фирмы выполненный заказ, который получает клиент.
1.2.2 Выявление недостатков существующей технологии управления продажами
Недостатками существующей технологии продвижения товара на рынок являются:
1. Малоэффективные затраты на реализацию сбыта продукции.
2. Увеличение затрат на реализацию при расширении производства кратное увеличению товарооборота.
3. Присутствие человеческого фактора при принятии решения о производстве обуви на склад для дальнейшей продажи оптовым покупателям.
Сложность продвижения товара заключается в длительном процессе поиска покупателей, что влечёт за собой немалые дополнительные затраты. К таким затратам относятся: затраты на аренду помещения для организации торговой точки, затраты на перевозку товара в торговую точку, оплата продавцу. Рассмотрим эти затраты подробнее. Период рассмотрения 1 месяц, товарооборот - 1000 пар обуви.
Таблица 1. Затраты на продвижение товара
|
Статьи расхода |
Размер выплаты, руб. |
Число выплат в месяц |
Сумма, руб. |
||
|
1. |
Затраты на аренду помещения для организации торговой точки |
7500 |
1 |
7 500 |
|
|
2. |
Затраты на перевозку товара в торговую точку |
450 |
10 |
4 500 |
|
|
3. |
Оплата продавцу |
8000 |
1 |
8 000 |
|
|
ИТОГ: |
20 000 |
Таким образом, общие затраты на сбыт при содержании одной торговой точки составляют 20 000 руб.
Эти затраты формируют первый и основной недостаток используемой технологии сбыта - малоэффективные затраты на реализацию сбыта продукции. Второй недостаток вытекает из первого при расширении производства.
Для увеличения товарооборота необходимо увеличить сбыт. Для этого необходимо содержать несколько торговых точек в разных частях города. То есть при попытке увеличить товарооборот в 2 раза все перечисленные затраты также увеличатся в 2 раза и составят 40000 руб. неэффективных затрат. Потери от ошибочных решений в планировании производства продукции различные. Иногда они доходят до 40000 рублей в месяц. Следовательно, необходимо разработать такую технологию продвижения товаров, которая позволит сократить до минимума затраты на реализацию и сократит увеличение затрат на реализацию при расширении производства, а также позволит оптимизировать процесс анализа продаваемой продукции и упростить процесс принятия решения по производству продукции на склад для дальнейшего сбыта.
1.2.3 Поиск путей решения проблем. Обоснование принятых решений
Существует несколько путей решения поставленной проблемы:
ѕ разработать систему «с нуля». Такой подход применяется, если не существует аналогов необходимой системы, или аналоги существуют, но сильно расходятся с требованиями к функционалу, стоимости и другим параметрам.
ѕ внедрить аналог нужной системы. Такой подход применяется, если уже существует система (коробочный продукт), которая очень близка по функционалу и другим требованиям к требованиям разрабатываемой системы.
ѕ дописать имеющуюся систему до требуемого функционала. Такой подход используется в случае, если существует система, функционал которой удовлетворяет всем требованиям, кроме каких-то нескольких функций. Этот подход целесообразно применять, если существующая система не велика по стоимости, и затраты на приобретение и доработку этой системы не больше затрат, необходимых на решение проблемы с помощью первых двух подходов. Известно, что в настоящее время существует множество бесплатных систем интернет магазинов. Они наделены очень мощным функционалом и ориентированы на самые различные требования заказчика. Но в таких системах не предусмотрены функции обработки информации, которые позволяют облегчить процесс принятия решения по производству и планированию. Эти функции необходимо дописать. Таким образом, целесообразно взять за основу существующую бесплатную систему и доработать её.
1.2.4 Формализация требований к будущей технологии
Для разработки системы необходимо описать требования к функционалу, интерфейсу, удобству использования. Но целью данной работы является проектирование системы. Поэтому будут описаны только требования к функционалу, так как функции влияют на структуру баз данных.
Структура баз данных должна позволять осуществлять следующие функции и удовлетворять требованиям:
1. Общие требования:
ѕ неограниченное количество категорий и товаров;
ѕ неограниченное количество товаров в каждой категории;
ѕ неограниченное количество подкатегорий в каждой категории;
ѕ статистика по заказам и покупателями
2. Функциональность для покупателей:
ѕ возможность видеть историю своих заказов и текущий статус заказа;
ѕ возможность редактировать свои данные;
ѕ заказы могут оформлять только зарегистрированные пользователи;
ѕ товары могут просматривать все;
ѕ отзывы о товарах для обмена опытом покупателей;
ѕ опросы покупателей;
ѕ покупатели могут подписываться на рассылку
3. Функциональность администраторской части:
ѕ администраторская часть защищена паролем;
ѕ неограниченное количество администраторов магазина;
ѕ разделение прав для администраторов магазина;
ѕ создание статусов для администраторов магазина и настройка прав;
ѕ добавление, редактирование и удаление категорий, товаров, производителей, покупателей, отзывов о товарах, заказов;
ѕ настройки параметров управления магазином и отображения информации
4. Функциональность товаров:
ѕ дополнительные атрибуты товаров;
ѕ автоматический учет остатка товара на складе;
ѕ управление возможностью заказывать товары, которые закончились на складе;
ѕ неограниченное количество картинок для товаров
5. Модуль принятия решения:
ѕ показ статистики по продажам;
ѕ возможность формировать критерии эффективности товара
Эти требования позволяют определить некоторые взаимосвязи таблиц и обязательные атрибуты.
1.3 Выбор и обоснование технологии проектирования
В настоящее время используется большое количество подходов, которые позволяют, создавать модели бизнес-процессов предприятий. Особенно выделяют: структурный (функциональный), объектно-ориентированный, отдельно выделяется методология ARIS. Описание каждого подхода и его нотаций описано в источнике [3].
При проектировании данной системы будет использоваться объектно-ориентированный подход. Это объясняется тем, что нотация данного подхода (UML) позволяет достаточно полно и наглядно описать предметную область и позволяет легко изменять проект (при изменении одного объекта или процесса не надо изменять все остальные, как, например, в структурном подходе). Также UML является достаточным для проектирования данной системы, следовательно, методология ARIS, включающая UML и другие методологии, будет избыточна.
Существуют следующие средства для проектирования с помощью UML:
ѕ Visual Paradigm 6.1 Enterprise [4];
ѕ Rational Rose [5];
ѕ Borland Together [6];
ѕ ArgoUML [7];
ѕ Netbeans UML Plugin [8];
ѕ Eclipse Omondo Plugin [9];
ѕ Enterprise Architect [10].
Для выбора наиболее подходящего будут использоваться следующие критерии:
1. Возможность генерации программного кода на языке PHP.
2. Возможность производить реверс кода.
3. Поддержка ОС Windows.
4. Стоимость приобретения.
5. Опыт успешного использования (отзывы).
6. Простота освоения и использования.
Все критерии кроме стоимостного оценивается следующими балами:
0 - не удовлетворят требованию
5 - частично удовлетворяет требованию
10 - полностью удовлетворяет требованию
Стоимостной критерий является наиболее важным, поэтому его баллы выше:
0 - высокая стоимость;
10 - средняя стоимость;
20 - бесплатно
Таблица 2. Исходные данные для выбора CASE-средства
|
Visual Paradigm 6.1 Enterprise |
Rational Rose |
Borland Together |
ArgoUML |
Netbeans UML Plugin |
Eclipse Omondo Plugin |
Enterprise Architect |
||
|
Возможность генерации программного кода на языке PHP |
10 |
0 |
0 |
10 |
5 |
0 |
10 |
|
|
Возможность производить реверс кода |
10 |
0 |
0 |
10 |
0 |
10 |
10 |
|
|
Поддержка ОС Windows |
10 |
10 |
10 |
10 |
10 |
10 |
10 |
|
|
Стоимость приобретения |
20 |
0 |
10 |
20 |
20 |
10 |
10 |
|
|
Опыт успешного использования (отзывы) |
10 |
10 |
10 |
10 |
0 |
5 |
10 |
|
|
Простота освоения и использования. |
10 |
5 |
10 |
10 |
10 |
5 |
10 |
|
|
ИТОГ: |
70 |
25 |
40 |
70 |
45 |
40 |
60 |
Анализ показал, что наиболее подходящие для проектирования CASE-средства это Visual Paradigm и Enterprise Architect. При проектировании будет использоваться Visual Paradigm, так как имеется опыт работы в данной программе. В данной главе была описана краткая история, структура и деятельность фирмы по производству обуви «Rep'S». Была рассмотрена предметная область, определена область автоматизации. Автоматизации подлежит отдел продаж. В разделе расписана используемая технология отдела. Проблемой используемой технологии является не эффективные затраты на продвижение товара и значительное их увеличение при расширении фирмы. Также были выдвинуты требования к новой технологии продвижения товара и принятия решения.
2. Проектирование ИС управления интернет продажами
Для проектирования системы будет использоваться методология RAD. Согласно этой методологии результатом фазы проектирования должны быть:
ѕ общая информационная модель системы;
ѕ функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;
ѕ точно определенные с помощью CASE-средства интерфейсы между автономно разрабатываемыми подсистемами;
ѕ построенные прототипы экранов, отчетов, диалогов.
В итоге должна получиться схема базы данных, удовлетворяющая требованиям новой технологии и включающая все необходимые таблицы, для реализации заданного функционала.
2.1 Выбор и разработка архитектуры системы
Предлагаемая технология базируется на работе с данными по методу «запрос-ответ». Такой метод работы с данными обеспечивает архитектура системы «клиент-сервер». На сервере сосредоточена база данных, которая хранит информацию о продукции и покупателях. Покупатель получает доступ к базе данных через интернет с помощью любого браузера. Обработка информации происходит на сервере, клиенту отсылается ответ.
Архитектура “клиент-сервер” бывает:
??двухзвенная;
??трехзвенная;
??многозвенная.
Компоненты проектируемой системы:
1. Web-сервер + PHP модуль.
2. SQL-сервер.
3. Браузер клиента.
Таким образом, в системе учувствуют 3 звена: приложение (браузер клиента), web-сервер, SQL-сервер. Архитектура предлагаемой системы выглядит следующим образом:
Рисунок 6 - Архитектура системы автоматизированного управления продажами
Итак, предлагаемая технология реализуется в трёхзвенной архитектуре «клиент-сервер». Взаимодействие модулей отображено на рисунке выше.
автоматизация интернет продажа проектирование
2.2 Разработка модели информационной системы управления интернет продажами
Разрабатываемая информационная система позволяет формировать заказ со стороны клиента и управлять продажами со стороны менеджера. Функции, выполняемые системой, отображены на рисунке ниже.
Рисунок 7 - Диаграмма вариантов использования системы управления продажами
В рамках курсовой работы будут рассмотрены 2 варианта использования «Формирование заказа для производства на склад» и «Формирование требований к новым моделям».
Рисунок 8 - Диаграмма вариантов использования процесса формирования заказа для производства на склад
Процессы «Формирование списка истории продаж» и «Анализ истории продаж» выполняет функциональный модуль обработки статистики.
Рисунок 9 - Диаграмма последовательности процесса «Формирование заказа для производства на склад»
Алгоритм функции обработки статистики представлен в приложении А.
Рисунок 10 - Диаграмма последовательности процесса «Формирование требований к новым моделям»
Алгоритмы функций формирования полной статистики и анализа статистики представлены в приложениях В и С соответственно.
Диаграмма классов, описывающая иерархию классов и методы системы, представлена ниже.
Методы, прописанные в классе «Class_statistika», отвечают за функции обработки статистики (метод «statistikaProdazh»), её спецификация отображена в приложении 1; формирования полной статистики по атрибутам (метод «statistikaAtributov»), её спецификация отображена в приложении 2; анализа статистики (метод «analisAtributov»), её спецификация отображена в приложении3.
Рисунок 11 - Диаграмма классов системы
3. Проектирование базы данных ИС
Проектирование баз данных включает в себя этапы:
1. Системный анализ предметной области.
2. Инфологическое проектирование (концептуальная модель).
3. Даталогическое проектирование (логическая модель).
4. Физическое проектирование.
Анализ предметной области был произведён в разделе 1. Физическое проектирование произведено не будет, так как проектируемая система не привязана к определённой СУБД.
3.1 Инфологическое (концептуальное) проектирование
Инфологическое проектирование предполагает построение семантической модели предметной области, то есть информационной модели высокого уровня абстракции. Концептуальное моделирование будет производится по методологии Питера Чена. Модель включает в себя описание информационных объектов - сущностей, и связей между ними [11].
Сущности:
1. Пользователь.
2. Статус.
3. Заказ.
4. Назначение.
5. Этап ЖЦ.
6. Товар.
7. Атрибут (например, цвет).
8. Значение атрибута товара (например, синий, зелёный).
9. Цена.
10. Документ (например, изображение1).
11. Тип документа (например, картинка).
12. Категория.
13. Комментарии.
Сущность «Пользователь» подразумевает под собой и клиента, и менеджера. Эти сущности отличаются друг от друга статусом. Сущности связаны следующим образом:
Рисунок 12 - Концептуальная модель
Сущности связаны между собой отношениями «один-ко-многим» и «многие-ко-многим». Отношение товара и цены как «один-ко-многим» означает, что один и тот же товар может иметь разную цену за счёт удорожания или удешевления, цена товара зависит от даты поставки. Отношение заказа и товара как «многие-ко-многим» означает, что в одном заказе может присутствовать несколько разных товаров, а один и тот же товар (наименование товара) может присутствовать в разных заказах. Аналогично можно описать все отношения между сущностями.
3.2 Обоснование логической модели БД в выбранной существующей системе
В настоящее время можно выделить несколько основных моделей логического представления данных:
1. Реляционная модель. Состоит из отношений и элементов отношений.
2. Многомерная модель. Состоит из измерений. Измерение - это множество однотипных данных, образующих одну из граней гиперкуба.
3. Темпоральная модель. Состоит из трех компонент: структура данных DS, операции OP и ограничения целостности C.
4. Объектная модель. Состоит из данных, оформленных в виде моделей объектов произвольного типа.
5. Иерархическая модель. Состоит из упорядоченного набора экземпляров в виде дерева без множественного наследования.
6. Сетевая модель. Состоит из упорядоченного набора экземпляров в виде дерева с множественным наследованием.
Для решения поставленной задачи необходимо реализовать отношения между сущностями и обеспечить целостность данных. Реляционная модель является достаточной для построения базы данных.
3.3 Построение логической модели БД
При построении логической модели нормализация выполнялась до третей нормальной формы. Дальнейшая нормализация не требуется, так как при нормализации до третей нормальной формы избыточность данных полностью исчезает. Построенная модель не требует денормализации.
Каждая сущность имеет свой идентификатор, он является первичным ключом. Некоторые сущности могут иметь альтернативные ключи, которые тоже однозначно определяют запись. Например, таблица «Комментарий» имеет альтернативный ключ «Число - Логин - ИД_Товара», этот ключ полностью идентифицирует запись. Отчёт по альтернативным ключам представлен в приложении 4. Для модели определены инверсные ключи. Инверсный ключ - это атрибут или группа атрибутов, которые используются для доступа к сущности (так, как если бы они были первичными ключами), однако не обязательно находят только один экземпляр. В таблице «Пользователь» определён инверсный ключ «Статус». Это объясняется тем, что запросы по пользователю будут осуществляться по его статусу, например, отобразить всех менеджеров. Отчёт по инверсным ключам представлен в приложении 4. В системе должна реализовываться ссылочная целостность. Для примера рассмотрим реализацию ссылочной целостности для связи «Т_Пользователь Т_Комментарий», где Т_Пользователь - родительская таблица, Т_Комментарий - дочерняя таблица (имеет внешний ключ таблицы Т_Пользователь). Ссылочная целостность для этой связи описана в таблице ниже.
Таблица 3 - Описание ссылочной целостности для связи «Т_Пользователь Т_Комментарий»
|
Действие |
Параметр |
|
|
Удаление записи из дочерней таблицы(Child Delete) |
NO ACTIONS - при удалении кортежа из дочерней таблицы никаких действий по отношению к родительской таблице не предпринимается. |
|
|
Добавление записи в дочернюю таблицу(Child Insert) |
RESTRICT - вставке нового кортежа в дочернюю таблицу возможна только в том случае если в родительской таблице существует кортеж с соответствующим первичным ключом. |
|
|
Изменение записи в дочерней таблице (Child Update) |
RESTRICT - обновление внешнего ключа в дочерней таблице возможно только в том случае если в родительской таблице существует кортеж с соответствующим первичным ключом. |
|
|
Удаление записи из родительской таблицы (Parent Delete) |
SET NULL - при удалении кортежа из родительской таблицы значение внешнего ключа в дочерней таблице делается null. |
|
|
Добавление записи в родительскую таблицу (Parent Insert) |
NONE - никаких действий по поддержанию ссылочной целостности не требуется. |
|
|
Изменение записи в родительской таблице (Parent Update) |
CASCADE - при обновлении первичного ключа в родительской таблице в дочерней таблице обновляется соответствующий вторичный ключом. |
Отчёт по ссылочной целостности всех связей представлен в приложении 5.
Рисунок 13 - Логическая модель данных
Заключение
В данной работе была проанализирована деятельность фирмы Rep'S. В качестве области автоматизации взят отдел продаж.
Смоделированы существующие процессы в отделе продаж и выделены недостатки такие как:
1. Малоэффективные затраты на реализацию сбыта продукции.
2. Увеличение затрат на реализацию при расширении производства кратное увеличению товарооборота.
3. Присутствие человеческого фактора при принятии решения о производстве обуви на склад для дальнейшей продажи оптовым покупателям.
Были рассмотрены различные подходы для решения подобных проблем. Для решения поставленной проблемы было решено дописать уже имеющуюся систему до требуемого функционала. Для проектирования системы был выбран объектный подход.
Проектирование производилось на CASE-средстве Visual Paradigm. Система реализуется в трёхзвенной архитектуре «клиент-сервер» и включает в себя компоненты: Web-сервер + PHP модуль, SQL-сервер, браузер клиента. Для проектирования был выбран RAD-подход. При проектировании системы определены внешние сущности и разработана диаграмма вариантов использования всей системы в целом.
Из этой диаграммы разобраны два варианта использования «Формирование заказа для производства на склад» и «Формирование требований к новым моделям». Для каждого из них построены диаграммы последовательности, определены модули, выполняющие определённые функции и описаны спецификации этих функций. Они представлены в приложениях.
Также спроектирована диаграмма классов для реализации функционала системы.
При проектировании баз данных было произведено инфологическое проектирование, результатом которого является диаграмма Питера Чена. Результатом фазы проектирования является логическая модель данных системы.
Литература
1. Хетагуров Я.А., Проектирование АСОИУ / Я.А. Хетагуров - М.: Высш. шк., 2006. - 223с.
2. Ларман К., Применение UML и шаблонов проектирования / К. Ларман - М.: Вильямс, 2002. - 624с.
3. Рябышева И.В. Сравнительный анализ подходов к проектированию ИС [Электронный ресурс]. - Режим доступа: http://www.ict.nsc.ru/ws/YM2004/8666/index.htm.
4. Visual Paradigm 6.1 Enterprise [Электронный ресурс] : [Официальный сайт Visual Paradigm]. - Режим доступа: www.visual-paradigm.com/product/sde/vs/editions/community.jsp.
5. Rational Rose [Электронный ресурс] : [Официальный сайт IBM]. - Режим доступа: www-01.ibm.com/software/awdtools/developer/rose.
6. Borland Together [Электронный ресурс]. - Режим доступа: www.interface.ru/fset.asp?Url=/borland/bt.htm
7. ArgoUML [Электронный ресурс] : [Официальный сайт ArgoUML]. - Режим доступа:: argouml.tigris.org.
8. Netbeans UML Plugin [Электронный ресурс] : [Официальный сайт Netbeans]. - Режим доступа: netbeans.org/features/uml.
9. Eclipse Omondo Plugin [Электронный ресурс] : [Официальный сайт Visual Paradigm]. - Режим доступа: www.visual-paradigm.com/solution/eclipseuml.
10. Enterprise Architect [Электронный ресурс]. - Режим доступа: www.sparxsystems.com.
11. Обзор нотаций, используемых при построении диаграмм "сущность-связь" [Электронный ресурс]. - Режим доступа: http://pda.mstu.edu.ru/study/materials/zelenkov/ch_2_4.html.
Приложение 1
П. 1 - Алгоритм функции обработки статистики (метод «statistikaProdazh»)
Приложение 2
П. 2 - Алгоритм функции формирования полной статистики по атрибутам (метод «statistikaAtributov»)
Приложение 3
П. 3 - Алгоритм функции анализа статистики (метод «analisAtributov»)
Запрашиваемый для отчёта процент совпадения - это критерий отбора атрибутов моделей, его задаёт менеджер. Данный критерий показывает сколько процентов проданной за данный период обуви имеет определённое значение атрибута (например, материал замша 13%, то есть 13% всей проданной за данный период времени было из замши).
Приложение 4
Отчёт по ключам
|
Key Group(s) of "Т_Атрибут" Entity |
||
|
Name |
Type |
|
|
Primary Key |
PK |
|
|
Alternate Key 1 |
AK1 |
|
|
IE_Atribut |
IE1 |
|
|
Foreign Key 1 |
IF1 |
|
|
Member(s) of "Primary Key" Key Group |
||
|
Name |
||
|
ИД_Атрибут |
||
|
Member(s) of "Alternate Key 1" Key Group |
||
|
Name |
||
|
Атрибут |
||
|
ИД_ЗначениеАтрибута |
||
|
Member(s) of "IE_Atribut" Key Group |
||
|
Name |
||
|
Атрибут |
||
|
Member(s) of "Foreign Key 1" Key Group |
||
|
Name |
||
|
ИД_ЗначениеАтрибута |
||
|
Primary Key Attribute(s) of "Т_Атрибут" Entity |
||
|
Name |
||
|
ИД_Атрибут |
|
Key Group(s) of "Т_Атрибут Т_Товар" Entity |
||
|
Name |
Type |
|
|
Primary Key |
PK |
|
|
Foreign Key 1 |
IF1 |
|
|
Foreign Key 2 |
IF2 |
|
|
Member(s) of "Primary Key" Key Group |
||
|
Name |
||
|
ИД_Атрибут |
||
|
ИД_Товара |
||
|
Member(s) of "Foreign Key 1" Key Group |
||
|
Name |
||
|
ИД_Атрибут |
||
|
Member(s) of "Foreign Key 2" Key Group |
||
|
Name |
||
|
ИД_Товара |
||
|
Primary Key Attribute(s) of "Т_Атрибут Т_Товар" Entity |
||
|
Name |
||
|
ИД_Атрибут |
||
|
ИД_Товара |
|
Key Group(s) of "Т_Документ" Entity |
||
|
Name |
Type |
|
|
Primary Key |
PK |
|
|
IE_DocForTovar |
IE1 |
|
|
Foreign Key 1 |
IF1 |
|
|
Foreign Key 2 |
IF2 |
|
|
Member(s) of "Primary Key" Key Group |
||
|
Name |
||
|
ИД_Документа |
||
|
Member(s) of "IE_DocForTovar" Key Group |
||
|
Name |
||
|
ИД_Товара |
||
|
Member(s) of "Foreign Key 1" Key Group |
||
|
Name |
||
|
ИД_ТипДокумента |
||
|
Member(s) of "Foreign Key 2" Key Group |
||
|
Name |
||
|
ИД_Товара |
||
|
Primary Key Attribute(s) of "Т_Документ" Entity |
||
|
Name |
||
|
ИД_Документа |
|
Key Group(s) of "Т_Заказ" Entity |
||
|
Name |
Type |
|
|
Primary Key |
PK |
|
|
IE_Polsovatel |
IE1 |
|
|
IE_Nasnachenie |
IE2 |
|
|
Foreign Key 2 |
IF2 |
|
|
Foreign Key 3 |
IF3 |
|
|
Member(s) of "Primary Key" Key Group |
||
|
Name |
||
|
ИД_Заказа |
||
|
Member(s) of "IE_Polsovatel" Key Group |
||
|
Name |
||
|
Логин |
||
|
Member(s) of "IE_Nasnachenie" Key Group |
||
|
Name |
||
|
ИД_НазначениеЗаказа |
||
|
Member(s) of "Foreign Key 2" Key Group |
||
|
Name |
||
|
Логин |
||
|
Member(s) of "Foreign Key 3" Key Group |
||
|
Name |
||
|
ИД_НазначениеЗаказа |
||
|
Primary Key Attribute(s) of "Т_Заказ" Entity |
||
|
Name |
||
|
ИД_Заказа |
|
Key Group(s) of "Т_Заказ Т_Товар" Entity |
||
|
Name |
Type |
|
|
Primary Key |
PK |
|
|
Foreign Key 1 |
IF1 |
|
|
Foreign Key 2 |
IF2 |
|
|
Member(s) of "Primary Key" Key Group |
||
|
Name |
||
|
ИД_Заказа |
||
|
ИД_Товара |
||
|
Member(s) of "Foreign Key 1" Key Group |
||
|
Name |
||
|
ИД_Заказа |
||
|
Member(s) of "Foreign Key 2" Key Group |
||
|
Name |
||
|
ИД_Товара |
||
|
Primary Key Attribute(s) of "Т_Заказ Т_Товар" Entity |
||
|
Name |
||
|
ИД_Заказа |
||
|
ИД_Товара |
|
Key Group(s) of "Т_ЗначениеАтрибута" Entity |
||
|
Name |
Type |
|
|
Primary Key |
PK |
|
|
Member(s) of "Primary Key" Key Group |
||
|
Name |
||
|
ИД_ЗначениеАтрибута |
||
|
Primary Key Attribute(s) of "Т_ЗначениеАтрибута" Entity |
||
|
Name |
||
|
ИД_ЗначениеАтрибута |
|
Key Group(s) of "Т_ИсторияЦен" Entity |
||
|
Name |
Type |
|
|
Primary Key |
PK |
|
|
Alternate Key 1 |
AK1 |
|
|
IE_Tovar |
IE1 |
|
|
Foreign Key 1 |
IF1 |
|
|
Member(s) of "Primary Key" Key Group |
||
|
Name |
||
|
ИД_УчётТовара |
||
|
Member(s) of "Alternate Key 1" Key Group |
||
|
Name |
||
|
ИД_Товара |
||
|
ЦенаПродажи |
||
|
Member(s) of "IE_Tovar" Key Group |
||
|
Name |
||
|
ИД_Товара |
||
|
Member(s) of "Foreign Key 1" Key Group |
||
|
Name |
||
|
ИД_Товара |
||
|
Primary Key Attribute(s) of "Т_ИсторияЦен" Entity |
||
|
Name |
||
|
ИД_УчётТовара |
|
Key Group(s) of "Т_Категория" Entity |
||
|
Name |
Type |
|
|
Primary Key |
PK |
|
|
Foreign Key 1 |
IF1 |
|
|
Member(s) of "Primary Key" Key Group |
||
|
Name |
||
|
ИД_КатегорияТовара |
||
|
Member(s) of "Foreign Key 1" Key Group |
||
|
Name |
||
|
ИД_КатегорияТовара |
||
|
Primary Key Attribute(s) of "Т_Категория" Entity |
||
|
Name |
||
|
ИД_КатегорияТовара |
|
Key Group(s) of "Т_Коментарий" Entity |
||
|
Name |
Type |
|
|
Primary Key |
PK |
|
|
Alternate Key 1 |
AK1 |
|
|
IE_Data |
IE1 |
|
|
IE_Polsovatel |
IE2 |
|
|
IE_Tovar |
IE3 |
|
|
Foreign Key 1 |
IF1 |
|
|
Foreign Key 2 |
IF2 |
|
|
Member(s) of "Primary Key" Key Group |
||
|
Name |
||
|
ИД_Коментарий |
||
|
Member(s) of "Alternate Key 1" Key Group |
||
|
Name |
||
|
Число |
||
|
Логин |
||
|
ИД_Товара |
||
|
Member(s) of "IE_Data" Key Group |
||
|
Name |
||
|
Число |
||
|
Member(s) of "IE_Polsovatel" Key Group |
||
|
Name |
||
|
Логин |
||
|
Member(s) of "IE_Tovar" Key Group |
||
|
Name |
||
|
ИД_Товара |
||
|
Member(s) of "Foreign Key 1" Key Group |
||
|
Name |
||
|
Логин |
||
|
Member(s) of "Foreign Key 2" Key Group |
||
|
Name |
||
|
ИД_Товара |
||
|
Primary Key Attribute(s) of "Т_Коментарий" Entity |
||
|
Name |
||
|
ИД_Коментарий |
|
Key Group(s) of "Т_НазначениеЗаказа" Entity |
||
|
Name |
Type |
|
|
Primary Key |
PK |
|
|
Member(s) of "Primary Key" Key Group |
||
|
Name |
||
|
ИД_НазначениеЗаказа |
||
|
Primary Key Attribute(s) of "Т_НазначениеЗаказа" Entity |
||
|
Name |
||
|
ИД_НазначениеЗаказа |
|
Key Group(s) of "Т_Пользователь" Entity |
||
|
Name |
Type |
|
|
Primary Key |
PK |
|
|
IE_Status |
IE2 |
|
|
Foreign Key 1 |
IF1 |
|
|
Member(s) of "Primary Key" Key Group |
||
|
Name |
||
|
Логин |
||
|
Member(s) of "IE_Status" Key Group |
||
|
Name |
||
|
ИД_Статус |
||
|
Member(s) of "Foreign Key 1" Key Group |
||
|
Name |
||
|
ИД_Статус |
||
|
Primary Key Attribute(s) of "Т_Пользователь" Entity |
||
|
Name |
||
|
Логин |
|
Key Group(s) of "Т_Событие" Entity |
||
|
Name |
Type |
|
|
Primary Key |
PK |
|
|
IE_SobPolsovatel |
IE1 |
|
|
Foreign Key 1 |
IF1 |
|
|
Foreign Key 3 |
IF3 |
|
|
Foreign Key 4 |
IF4 |
|
|
Member(s) of "Primary Key" Key Group |
||
|
Name |
||
|
ИД_Заказа |
||
|
ИД_ЭтапаЖЦ |
||
|
Member(s) of "IE_SobPolsovatel" Key Group |
||
|
Name |
||
|
Логин |
||
|
Member(s) of "Foreign Key 1" Key Group |
||
|
Name |
||
|
ИД_Заказа |
||
|
Member(s) of "Foreign Key 3" Key Group |
||
|
Name |
||
|
ИД_ЭтапаЖЦ |
||
|
Member(s) of "Foreign Key 4" Key Group |
||
|
Name |
||
|
Логин |
||
|
Primary Key Attribute(s) of "Т_Событие" Entity |
||
|
Name |
||
|
ИД_Заказа |
||
|
ИД_ЭтапаЖЦ |
||
|
Key Group(s) of "Т_СообщенияПроизводителю" Entity |
||
|
Name |
Type |
|
|
Primary Key |
PK |
|
|
IE_MesPolsovatel |
IE1 |
|
|
IE_Data |
IE2 |
|
|
Foreign Key 1 |
IF1 |
|
|
Member(s) of "Primary Key" Key Group |
||
|
Name |
||
|
ИД_Предложения |
||
|
Member(s) of "IE_MesPolsovatel" Key Group |
||
|
Name |
||
|
Логин |
||
|
Member(s) of "IE_Data" Key Group |
||
|
Name |
||
|
Число |
||
|
Member(s) of "Foreign Key 1" Key Group |
||
|
Name |
||
|
Логин |
||
|
Primary Key Attribute(s) of "Т_СообщенияПроизводителю" Entity |
||
|
Name |
||
|
ИД_Предложения |
|
Key Group(s) of "Т_Статус" Entity |
||
|
Name |
Type |
|
|
Primary Key |
PK |
|
|
Alternate Key 1 |
AK1 |
|
|
Member(s) of "Primary Key" Key Group |
||
|
Name |
||
|
ИД_Статус |
||
|
Member(s) of "Alternate Key 1" Key Group |
||
|
Name |
||
|
Статус |
||
|
Primary Key Attribute(s) of "Т_Статус" Entity |
||
|
Name |
||
|
ИД_Статус |
||
|
Key Group(s) of "Т_ТипДокумента" Entity |
||
|
Name |
Type |
|
|
Primary Key |
PK |
|
|
Member(s) of "Primary Key" Key Group |
||
|
Name |
||
|
ИД_ТипДокумента |
||
|
Primary Key Attribute(s) of "Т_ТипДокумента" Entity |
||
|
Name |
||
|
ИД_ТипДокумента |
|
Key Group(s) of "Т_Товар" Entity |
||
|
Name |
Type |
|
|
Primary Key |
PK |
|
|
Alternate Key 1 |
AK1 |
|
|
Foreign Key 4 |
IF4 |
|
|
Member(s) of "Primary Key" Key Group |
||
|
Name |
||
|
ИД_Товара |
||
|
Member(s) of "Alternate Key 1" Key Group |
||
|
Name |
||
|
НаименованиеМодели |
||
|
ИД_КатегорияТовара |
||
|
Member(s) of "Foreign Key 4" Key Group |
||
|
Name |
||
|
ИД_КатегорияТовара |
||
|
Primary Key Attribute(s) of "Т_Товар" Entity |
||
|
Name |
||
|
ИД_Товара |
||
|
Key Group(s) of "Т_ЭиапыЖЦ" Entity |
||
|
Name |
Type |
|
|
Primary Key |
PK |
|
|
Member(s) of "Primary Key" Key Group |
||
|
Name |
||
|
ИД_ЭтапаЖЦ |
||
|
Primary Key Attribute(s) of "Т_ЭиапыЖЦ" Entity |
||
|
Name |
||
|
ИД_ЭтапаЖЦ |
Приложение 5
Отчёт по ссылочной целостности
|
Parent Entity(s) of "R15" Relationship |
||||||
|
Name |
||||||
|
Т_Атрибут |
||||||
|
Child Entity(s) of "R15" Relationship |
||||||
|
Name |
||||||
|
Т_Атрибут Т_Товар |
||||||
|
Referential Integrity(s) of "R15" Relationship |
||||||
|
Parent Insert |
Parent Update |
Parent Delete |
Child Insert |
Child Update |
Child Delete |
|
|
Cascade |
Cascade |
Restrict |
Restrict |
No Action |
|
Parent Entity(s) of "R7" Relationship |
||||||
|
Name |
||||||
|
Т_Заказ |
||||||
|
Child Entity(s) of "R7" Relationship |
||||||
|
Name |
||||||
|
Т_Событие |
||||||
|
Referential Integrity(s) of "R7" Relationship |
||||||
|
Parent Insert |
Parent Update |
Parent Delete |
Child Insert |
Child Update |
Child Delete |
|
|
Cascade |
Cascade |
Restrict |
Restrict |
No Action |
|
Parent Entity(s) of "R18" Relationship |
||||||
|
Name |
||||||
|
Т_Заказ |
||||||
|
Child Entity(s) of "R18" Relationship |
||||||
|
Name |
||||||
|
Т_Заказ Т_Товар |
||||||
|
Referential Integrity(s) of "R18" Relationship |
||||||
|
Parent Insert |
Parent Update |
Parent Delete |
Child Insert |
Child Update |
Child Delete |
|
|
Cascade |
Restrict |
Restrict |
Restrict |
No Action |
||
|
Parent Entity(s) of "R16" Relationship |
||||||
|
Name |
||||||
|
Т_ЗначениеАтрибута |
||||||
|
Child Entity(s) of "R16" Relationship |
||||||
|
Name |
||||||
|
Т_Атрибут |
||||||
|
Referential Integrity(s) of "R16" Relationship |
||||||
|
Parent Insert |
Parent Update |
Parent Delete |
Child Insert |
Child Update |
Child Delete |
|
|
Cascade |
Cascade |
Restrict |
Restrict |
No Action |
|
Parent Entity(s) of "R9" Relationship |
||||||
|
Name |
||||||
|
Т_Категория |
||||||
|
Child Entity(s) of "R9" Relationship |
||||||
|
Name |
||||||
|
Т_Категория |
||||||
|
Referential Integrity(s) of "R9" Relationship |
||||||
|
Parent Insert |
Parent Update |
Parent Delete |
Child Insert |
Child Update |
Child Delete |
|
|
Cascade |
Cascade |
Restrict |
Restrict |
No Action |
|
Parent Entity(s) of "R10" Relationship |
||||||
|
Name |
||||||
|
Т_Категория |
||||||
|
Child Entity(s) of "R10" Relationship |
||||||
|
Name |
||||||
|
Т_Товар |
||||||
|
Referential Integrity(s) of "R10" Relationship |
||||||
|
Parent Insert |
Parent Update |
Parent Delete |
Child Insert |
Child Update |
Child Delete |
|
|
No Action |
Cascade |
Restrict |
Restrict |
Restrict |
No Action |
|
Parent Entity(s) of "R17" Relationship |
||||||
|
Name |
||||||
|
Т_НазначениеЗаказа |
||||||
|
Child Entity(s) of "R17" Relationship |
||||||
|
Name |
||||||
|
Т_Заказ |
||||||
|
Referential Integrity(s) of "R17" Relationship |
||||||
|
Parent Insert |
Parent Update |
Parent Delete |
Child Insert |
Child Update |
Child Delete |
|
|
Cascade |
Restrict |
Restrict |
Restrict |
|||
|
Parent Entity(s) of "R3" Relationship |
||||||
|
Name |
||||||
|
Т_Пользователь |
||||||
|
Child Entity(s) of "R3" Relationship |
||||||
|
Name |
||||||
|
Т_Заказ |
||||||
|
Referential Integrity(s) of "R3" Relationship |
||||||
|
Parent Insert |
Parent Update |
Parent Delete |
Child Insert |
Child Update |
Child Delete |
|
|
No Action |
Cascade |
Restrict |
Restrict |
Restrict |
No Action |
|
Parent Entity(s) of "R2" Relationship |
||||||
|
Name |
||||||
|
Т_Пользователь |
||||||
|
Child Entity(s) of "R2" Relationship |
||||||
|
Name |
||||||
|
Т_Событие |
||||||
|
Referential Integrity(s) of "R2" Relationship |
||||||
|
Parent Insert |
Parent Update |
Parent Delete |
Child Insert |
Child Update |
Child Delete |
|
|
Cascade |
Set Null |
Restrict |
Restrict |
No Action |
|
Parent Entity(s) of "R4" Relationship |
||||||
|
Name |
||||||
|
Т_Пользователь |
||||||
|
Child Entity(s) of "R4" Relationship |
||||||
|
Name |
||||||
|
Т_Коментарий |
||||||
|
Referential Integrity(s) of "R4" Relationship |
||||||
|
Parent Insert |
Parent Update |
Parent Delete |
Child Insert |
Child Update |
Child Delete |
|
|
Cascade |
Set Null |
Restrict |
Restrict |
No Action |
|
Parent Entity(s) of "R5" Relationship |
||||||
|
Name |
||||||
|
Т_Пользователь |
||||||
|
Child Entity(s) of "R5" Relationship |
||||||
|
Name |
||||||
|
Т_СообщенияПроизводителю |
||||||
|
Referential Integrity(s) of "R5" Relationship |
||||||
|
Parent Insert |
Parent Update |
Parent Delete |
Child Insert |
Child Update |
Child Delete |
|
|
Cascade |
Cascade |
Restrict |
Restrict |
No Action |
|
Parent Entity(s) of "R1" Relationship |
||||||
|
Name |
||||||
|
Т_Статус |
||||||
|
Child Entity(s) of "R1" Relationship |
||||||
|
Name |
||||||
|
Т_Пользователь |
||||||
|
Referential Integrity(s) of "R1" Relationship |
||||||
|
Parent Insert |
Parent Update |
Parent Delete |
Child Insert |
Child Update |
Child Delete |
|
|
Cascade |
Restrict |
Restrict |
Cascade |
No Action |
|
Parent Entity(s) of "R19" Relationship |
||||||
|
Name |
||||||
|
Т_ТипДокумента |
||||||
|
Child Entity(s) of "R19" Relationship |
||||||
|
Name |
||||||
|
Т_Документ |
||||||
|
Referential Integrity(s) of "R19" Relationship |
||||||
|
Parent Insert |
Parent Update |
Parent Delete |
Child Insert |
Child Update |
Child Delete |
|
|
Cascade |
Restrict |
Restrict |
Restrict |
No Action |
|
Parent Entity(s) of "R14" Relationship |
||||||
|
Name |
||||||
|
Т_Товар |
||||||
|
Child Entity(s) of "R14" Relationship |
||||||
|
Name |
||||||
|
Т_Документ |
||||||
|
Referential Integrity(s) of "R14" Relationship |
||||||
|
Parent Insert |
Parent Update |
Parent Delete |
Child Insert |
Child Update |
Child Delete |
|
|
Cascade |
Cascade |
Restrict |
Restrict |
No Action |
||
|
Parent Entity(s) of "R13" Relationship |
||||||
|
Name |
||||||
|
Т_Товар |
||||||
|
Child Entity(s) of "R13" Relationship |
||||||
|
Name |
||||||
|
Т_Заказ Т_Товар |
||||||
|
Referential Integrity(s) of "R13" Relationship |
||||||
|
Parent Insert |
Parent Update |
Parent Delete |
Child Insert |
Child Update |
Child Delete |
|
|
Cascade |
Restrict |
Restrict |
Restrict |
No Action |
||
|
Parent Entity(s) of "R8" Relationship |
||||||
|
Name |
||||||
|
Т_Товар |
||||||
|
Child Entity(s) of "R8" Relationship |
||||||
|
Name |
||||||
|
Т_Коментарий |
||||||
|
Referential Integrity(s) of "R8" Relationship |
||||||
|
Parent Insert |
Parent Update |
Parent Delete |
Child Insert |
Child Update |
Child Delete |
|
|
Cascade |
Cascade |
Restrict |
Restrict |
No Action |
|
Parent Entity(s) of "R12" Relationship |
||||||
|
Name |
||||||
|
Т_Товар |
||||||
|
Child Entity(s) of "R12" Relationship |
||||||
|
Name |
||||||
|
Т_Атрибут Т_Товар |
||||||
|
Referential Integrity(s) of "R12" Relationship |
||||||
|
Parent Insert |
Parent Update |
Parent Delete |
Child Insert |
Child Update |
Child Delete |
|
|
Cascade |
Cascade |
Restrict |
Restrict |
No Action |
|
Parent Entity(s) of "R11" Relationship |
||||||
|
Name |
||||||
|
Т_Товар |
||||||
|
Child Entity(s) of "R11" Relationship |
||||||
|
Name |
||||||
|
Т_ИсторияЦен |
||||||
|
Referential Integrity(s) of "R11" Relationship |
||||||
|
Parent Insert |
Parent Update |
Parent Delete |
Child Insert |
Child Update |
Child Delete |
|
|
Cascade |
Cascade |
Restrict |
Restrict |
No Action |
||
|
Parent Entity(s) of "R6" Relationship |
||||||
|
Name |
||||||
|
Т_ЭиапыЖЦ |
||||||
|
Child Entity(s) of "R6" Relationship |
||||||
|
Name |
||||||
|
Т_Событие |
|
Referential Integrity(s) of "R6" Relationship |
||||||
|
Parent Insert |
Parent Update |
Parent Delete |
Child Insert |
Child Update |
Child Delete |
|
|
Cascade |
Restrict |
Restrict |
Restrict |
No Action |
Размещено на Allbest.ru
Подобные документы
Разработка проекта конфигурации для компании с учетом требований конечного пользователя. Процесс управления продажами как неотъемлемый компонент процесса управления предприятием. Описание структуры информационного фонда системы. Расчет себестоимости.
дипломная работа [1,6 M], добавлен 02.12.2012Общая характеристика деятельности организации. Выявление недостатков существующей системы управления. Определение потребности в медицинском оборудовании. Выбор поставщиков по лотам. Контроль пуско-наладочных работ. Анализ надежности и отказоустойчивости.
дипломная работа [4,8 M], добавлен 14.03.2013Постановка задач и требований к проектируемому интернет-приложению. Обоснование выбора системы управления базы данных и языков программирования. Разработка архитектуры заданного интернет-приложения, технико-экономическое обоснование его эффективности.
дипломная работа [461,3 K], добавлен 24.02.2013Обзор средств автоматизации торговли. Обзор состояния Интернет-торговли и роли в них аукционов. Описание процесса проектирования автоматизированной системы. Расчет экономической эффективности от внедрения программного продукта. Охрана труда работников.
дипломная работа [569,0 K], добавлен 09.09.2008Организация и продажа оргтехники. Цели автоматизированной системы и автоматизируемые функции. Характеристика функциональной структуры информационной системы. Проектирование функциональной части объекта автоматизации. Обоснование выбора подсистемы.
курсовая работа [129,6 K], добавлен 19.12.2010Предметная область предприятия по производству мебели: изучение и диагностический анализ структуры предприятия, его деятельности и существующей системы обработки информации. Проектирование моделей, форм входных и выходных документов предприятия.
курсовая работа [545,7 K], добавлен 30.01.2013Построение модели деятельности организации в IDEF0. Описание средств размещения данных в Интернет (форум, e-mail, web-site, хостинг). Выбор инструментальной среды разработки, логическое проектирование, установка и тестирование информационной системы.
дипломная работа [1,9 M], добавлен 13.01.2014Общие сведения о системе управления контентом, модели представления данных и критерии её оценки. Проектирование функций пользователей "SiteONas" с ролью "Суперадминистратор". Проблема, решаемая в программном продукте, трудоемкость его разработки.
дипломная работа [6,0 M], добавлен 29.06.2012Средства, используемые при разработке интернет-приложения. Язык обработки сценариев на стороне web-сервера. Система управления базами данных MySQL. Проектирование front-offiсe. Проектирование ER модели данных с использованием модели "сущность-связь".
курсовая работа [3,5 M], добавлен 15.01.2014Разработка интернет-магазина, который специализируется на продаже книг. Сравнение технологий и средств разработки: языки программирования и программное обеспечение. Социальные сети и система управления контентом. Проектирование модели базы данных.
курсовая работа [3,6 M], добавлен 25.06.2012
