Проектування автоматизованих інформаційних систем. Інформаційна система музичного магазину "LARGO"
Аналіз бізнес-потреб магазину та основних завдань автоматизації процесів купівлі-продажу. Визначення категорій користувачів і класів даних, розробка матриці подій для менеджера товару. Інфологічне та даталогічне проектування інформаційної системи.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | курсовая работа |
Язык | украинский |
Дата добавления | 07.06.2013 |
Размер файла | 940,2 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
МІНІСТЕРСТВО ОСВІТИ І НАУКИ, МОЛОДІ ТА СПОРТУ УКРАЇНИ
НАЦІОНАЛЬНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ УКРАЇНИ
„КИЇВСЬКИЙ ПОЛІТЕХНІЧНИЙ ІНСТИТУТ”
ПОЯСНЮВАЛЬНА ЗАПИСКА
на тему: Проектування автоматизованих інформаційних систем. Інформаційна система музичного магазину "LARGO"
Студент групи
Керівник
Київ 2012
Анотація
Дана курсова робота присвячена проектуванню автоматизованої інформаційної системи музичного магазину «LARGO».
В роботі спроектовано базу даних для магазину, яка включає дані про товари, клієнтів та постачальників магазину. Розглянуто шляхи взаємодії між цими даними.
Також в роботі розроблено схеми, за використання яких робота співробітників магазину «LARGO» стане значно простішою завдяки мінімізації впливу людського фактору на дані системи.
Реферат
Актуальність теми.
Автоматизація процесів купівлі-продажу магазину «LARGO» є дуже важливою, бо вона націлена на прискорення роботи працівників магазину, значне спрощення обліку товарів, оптимізацію часу, що витрачається на оформлення документів тощо.
Об'єктом дослідження
Об'єктом дослідження обрано магазин «LARGO».
Предметом дослідження
Предметом дослідження є організація процесів управління товаром (а саме купівля, продаж, замовлення товару в постачальників, оформлення клієнтських замовлень тощо) у магазині „LARGO”. При цьому об'єктом дослідження є магазин «LARGO».
Мета роботи.
Необхідно автоматизувати процеси купівлі-продажу магазину «LARGO», з метою прискорити роботу працівників магазину, спростити облік товарів, оптимізувати час, що витрачається на оформлення документів тощо.
Методи дослідження.
Процес покупки - інструментарій CPN, DFD, ERD, IDEF3.
Процес замовлення у постачальника - інструментарій CPN, DFD, ERD, IDEF3.
Наукова новизна.
Предмет дослідження - організація процесів управління товаром. Завдяки автоматизації процеси управління товаром протікатимуть по новому, а саме з мінімальним втручанням людського фактору.
Практична цінність
Завдяки автоматизації співробітники магазину не нестимуть відповідальність за деякі процеси. Наприклад в процесі обліку товарів співробітники не повинні самостійно рахувати кількість товарів, яку необхідно закупити: це зробить програма, дані в якій оновлюються після кожної клієнтської покупки.
Апробація роботи.
Курсову роботу було використано при побудові програми, що реалізує керування АІС магазину «LARGO».
Структура та обсяг роботи.
Курсова робота складається з вступу, 5 розділів та висновків.
У вступі надано загальну характеристику роботи.
У першому розділі розглянуто магазин до автоматизації та описано деякі зміни, які відбудуться після автоматизації.
У другому розділі сформульовано основні вимоги до розроблюваної системи.
У третьому розділі описано семантичну модель даних програми.
У четвертому розділі розглянуто етап даталогічного проектування.
У п'ятому розділі розглянуто основні бізнес-процеси.
У висновках проаналізовано отримані результати роботи.
Робота виконана на 26 аркушах, містить посилання на список використаних літературних джерел з _ найменувань. У роботі наведено 9 рисунків та 7 таблиць.
Ключові слова: база даних, дані, модель, бізнес-правила, ключі, поля, таблиці, SQL, реляційний, сутність, відношення, організація, організаційна структура, нормалізація, СУБД, інформаційні системи, ІС, замовлення, купівля, музичні інструменти, співробітник, касир, менеджер товару, постачальник, автоматизація.
Зміст
Список термінів, скорочень та позначень
Вступ
1. Аналіз підприємства автоматизації
1.1 Границі проекту
1.2 Бізнес-потреби
1.3 Безпека
1.4 Продуктивність
1.5 Супровід
1.6 Розширюваність
1.7 Доступність
1.8 Людський фактор
1.9 Методології
1.10 Масштабованість
2. Постановка задачі
2.1 Категорії користувачів
2.2 Класи даних
2.3 Бізнес правила
3. Інфологічне проектування
3.1 Загальна ERD
4. Даталогічне проектування
5. Моделювання бізнес процесів
5.1 DFD
5.2 IDEF3
Висновки
- Список літературних джерел
Список термінів, скорочень та позначень
PK - primary key, первинний ключ
FK - foreign key, зовнішній ключ
АИС - автоматизована інформаційна система
БД - база даних
ИМД - ієрархічна модель даних
ИПС - інформаційно-пошукова система
КБД - ключ бази даних
ПО - предметна область
РК - резервна копія
РМД - реляційна модель даних
РСУБД - реляційна система управління базами даних
СМД - сітьова модель даних
СОД - системи обробки даних
СУБД - система управління базами даних
Вступ
Магазин «LARGO», який було засновано в 2011 році, займається продажем музичних інструментів та музичного обладнання. Час існування магазину - 1 рік. В магазині працює двоє співробітників: касир та менеджер товару. На даний момент всі записи щодо здійснених продажів та закупівель ведуться співробітниками в письмовому вигляді без використання ПК.
В зв'язку з поступовим розширенням магазину необхідно перенести всі облікові записи в електронний вигляд для більш ефективної роботи працівників магазину.
Це можна зробити, створивши АІС магазину, тобто розробивши програму, яка передбачатиме занесення всіх змін, які відбуваються під час здійснення стандартних операцій з товаром (замовлення товару в постачальників, покупка товару клієнтом тощо), в базу даних.
Метою даної роботи є проектування такої АІС: розробка структури майбутньої бази даних, опис всіх її таблиць та взаємодій між ними.
Робота базується на попередній документації магазину та зроблена з використанням інформації щодо розробки АІС.
1. Аналіз підприємства автоматизації
1.1 Границі проекту
В проекті існують такі обмеження:
- можливість обслуговування покупців: в середньому не більше 1 покупця за хвилину;
- обмежено кількість товару на складі, але є додаткова можливість замовити товар понад цієї кількості;
- обмежено години роботи магазину;
- обмежено кількість працюючих: один касир та один менеджер товару.
Приблизний час життя проекту (магазину) - мінімум 2 роки (з яких минув 1 рік).
Очікується розширення технічної бази магазину: 2 ПК для співробітників.
Було вирішено автоматизувати систему, але так як кількість коштів обмежена, прийнято рішення автоматизувати лише процеси управління товаром (без процесів розрахунку економічних показників, таких як ЗП, податки тощо).
1.2 Бізнес-потреби
Весь облік документів був на паперових носіях. Бізнес потреба - перенести все в електронну форму.
1.3 Безпека
Безпека системи описана в таблиці 1.1
Таблиця 1.1 - Безпека
Позиція |
До автоматизації |
Після автоматизації |
|
Потреба в безпеці |
безпека необхідна для конфіденційності, доступності і цілісності |
безпека необхідна для підтримки конфіденційності, доступності і цілісності даних |
|
Поділ на адміністратора, групи, гостей та клієнтів |
Лише клієнти, детальніше - див. таблицю 1.2 |
розподілення на адміністратора та клієнтів, див. таблицю 1.2 |
|
Вплив існуючого оточення |
впливає на конфіденційність |
впливає на конфіденційність |
|
Відмовостійкість |
Забезпечується постійним доступом до документів |
Повинен забезпечити адміністратор |
|
Супровід |
див. таблицю 1.2 - Супровід |
див. таблицю 1.2 - Супровід |
|
Розміщення бази даних захисту |
документація зберігається в магазині |
дані зберігаються на сервері поза межами магазину |
|
Контекст захистів, необхідний рівень безпеки |
конфіденційність: доступ до документації лише для персоналу; доступність: забезпечення постійного доступу до документації; цілісність: цілісність документів в фізичному розумінні |
конфіденційність: доступ до даних лише для персоналу та адміністратора; доступність: забезпечення постійного доступу до сервера; цілісність: цілісність бази даних в інформаційному сенсі |
|
Аудит |
Проводиться співробітниками |
Проводиться адміністратором |
|
Існуючі політики безпеки. |
Політики безпеки обмежують доступ до документації за допомогою ключів до шухлядок (в фізичному сенсі) |
Політики безпеки обмежують доступ до бази даних або конкретних таблиць на основі інформації про облікові дані користувачів. |
1.4 Продуктивність
Число транзакцій в середньому близько 20 транзакцій за годину. В гіршому випадку - 60 транзакцій за годину. На продуктивність впливатиме людський фактор, адже для покупки товару необхідне втручання касира (оформлення заказу та його виконання)
1.5 Супровід
Супровід системи описано в таблиці 1.2.
Таблиця 1.2 - Супровід
Позиція |
До автоматизації |
Після автоматизації |
|
Розповсюдження програми |
магазин "LARGO" |
магазин "LARGO" |
|
Передбачуваний супровід |
супровід в разі помилок в документації здійснюється самими касиром та менеджером товару |
іноді необхідний професіональний супровід (в разі виникнення збоїв системи) - підтримувати систему повинен адміністратор |
|
Місцезнаходження та рівень знань групи супроводу |
група супроводу знаходиться в магазині під час його роботи, не потрібні додаткові знання |
місцезнаходження: поза межами магазину (викликається при виникненні проблем), рівень знань спеціаліста повинен забезпечувати безперебійну роботу сервера, вільний доступ користувачів до інформації, безпеку БД |
1.6 Розширюваність
На даний момент окрім автоматизування процесів необхідне таке розширення:
· створити базу клієнтів;
· додати процеси автоматичного розрахунку кількості товарів, яку треба замовити в постачальника;
Після автоматизації наступним кроком буде таке розширення:
· додати розрахунку процеси показників (прибутки, рівень зарплатні, податки тощо);
· додати дані щодо цих економічних показників: атрибут «Заробітна плата» тощо.
1.7 Доступність
· Заплановані простої: під час прийому товару.
1.8 Людський фактор
Вплив людського фактору описано в таблиці 1.3.
Таблиця 1.3 - Людський фактор
Позиція |
До автоматизації |
Після автоматизації |
|
Користувачі системи |
Співробітники магазину (касир та менеджер товару) |
Співробітники магазину (касир та менеджер товару) |
|
Спеціальні можливості |
Відсутні |
інтерфейс повинен передбачати просте виконання стандартних функцій (додати клієнта, оформити замовлення тощо) |
|
Мобільні користувачі |
Користувачі системи |
Користувачі системи, за умови, що програму буде встановлено на мобільні пристрої |
|
Потреба в навчанні |
для роботи необхідно навчити співробітників вести документацію |
необхідно навчити співробітників користуватись програмою для ведення документації |
|
довідкова система |
Відсутня |
необхідно створити довідкову систему |
|
Спеціальні потреби |
Відсутні |
Відсутні |
1.9 Методології
Для здійснення автоматизації магазину буде використовуватись програмне забезпечення, а саме СУБД Oracle, CASE-засоби, такі як ERWIN або POWERDESIGNER.
1.10 Масштабованість
При збільшенні кількості користувачів лише збільшиться кількість записів в таблицях, що зберігають дані про касирів та менеджерів товару, тобто в цьому випадку масштабованість передбачено.
При зростанні організації скоріш за все з'являться нові посади, і в цьому випадку масштабованість не передбачено: потрібна буде підтримка адміністратора для розширення бази належним чином.
При зростанні даних лише збільшиться кількість записів в таблиці, що зберігає дані про товари, тобто в цьому випадку масштабованість передбачено.
2. Постановка задачі
2.1 Категорії користувачів
Категорії користувачів наступні: касири, менеджери товару.
Касири зобов'язані працювати з клієнтом. Перелік основних функцій, до яких повинен мати доступ касир:
· Оформлювати замовлення клієнта;
· Якщо замовлення буде виконано пізніше, заносити клієнта до клієнтської бази, для можливості підтримки зв'язку з ним;
· Приймати грошові кошти за замовлення;
· Після проведення покупки робити відмітку про те, що замовлення виконано та сплачено.
· У разі виникнення проблем звертатись до директора.
Менеджери товару зобов'язані працювати з товаром. Перелік основних функцій, до яких повинен мати доступ менеджер товару:
· Перевіряти замовлення на поставку, яке автоматично складається програмою щотижня;
· Приймати товар та вносити його в базу;
· Проводити переоблік товарів;
· У разі виникнення проблем звертатись до директора.
2.2 Класи даних
Класи даних, необхідні для роботи програми:
· Дані про товар;
· Дані про постачальників;
· Дані про клієнтів;
· Дані про клієнтські замовлення;
· Дані про щотижневі замовлення на поставку.
2.3 Бізнес правила
магазин автоматизація продаж інформаційний
Таблиця 2.1 - Матриця подій для менеджера товару
№ |
Описание события |
Тип событий |
Реакция на событие |
|
1 |
М замовляє товар в постачальника |
N |
Підготувати замовлення автоматично, видати запит на підтвердження, відправити замовлення |
|
2 |
М приймає поставку товару |
N |
Надати форму прийняття поставки, змінити "кількість товару на складі" в базі, відмітка "замовлення виконано" |
|
3 |
М приймає поставку товару, але товар надано не в повному обсязі |
NN |
Надати форму прийняття поставки, але не ставити відмітку «замовлення виконано». Звернутися до директора |
|
4 |
М хоче змінити «стандартну кількість товару на складі» |
NN |
Звернутися до директора |
Таблиця 2.2 - Матриця подій для менеджера товару
№ |
Описание события |
Тип событий |
Реакция на событие |
|
1 |
К оформлює замовлення, за умови, що товар є на складі |
N |
Надати вибір, надати форму замовлення та записати замовлення |
|
2 |
К оформлює замовлення, але товару немає на складі |
N |
Надати вибір, надати форму замовлення та записати замовлення |
|
3 |
К надає товар клієнту та отримує гроші за цей товар |
N |
Надати форму завершення замовлення, провести зміни в базі (відмітка "замовлення виконано") |
|
4 |
К надає товар клієнту, але не отримує гроші за цей товар |
NN |
Звернутися до директора |
|
5 |
Клієнт відмовляється від замовлення. К записує відмову |
N |
Надати форму відміни замовлення. провести зміни в базі (анулювати бронь) |
3. Інфологічне проектування
3.1 Загальна ERD
Загальну ERD представлено на рис.
Рисунок 3.1 - Загальна ERD
Опис всіх сутностей (таблиць бази) представлено в таблиці 3.1. Відносини між сутностями вказано на Рисунку 3.1.
Таблиця 3.1 - Список таблиць в базі.
Назва таблиці |
Призначення таблиці та опис інформації, яка в ній міститься |
Ключ |
|
товари |
інформація про товари, які продаються в магазині. |
тов_id |
|
постачальники |
для кожного товару існує свій постачальник. Інформація про постачальників зберігається в цій таблиці. |
пост_id |
|
категорії |
інформація про категорії товарів (такі як духові інструменти, аксесуари тощо). |
кат_ id |
|
замовлення |
інформація про час замовлення, про те, який клієнт його зробив та який касир його оформив. |
зак_ id |
|
orderitems |
інформація про товари в кожному замовленні. Таблиця потрібна для збереження даних про те, який товар в якій кількості присутній в кожному з замовлень |
зак_ id, тов_id |
|
касири |
інформація про співробітників, що займають посаду касира |
кас_ id |
|
клієнти |
інформація про клієнтів |
кл_ id |
|
замовлення на поставку |
щотижня список товарів, які потрібно привезти, відправляється постачальникам. В цій таблиці - інформація про кожне таке замовлення |
П_зак_ id |
|
Пост_orderitems |
інформація про товари в кожному замовленні на поставку. Таблиця потрібна для збереження даних про те, який товар в якій кількості присутній в кожному з замовлень на поставку |
П_зак_ id, тов_id |
|
менеджери товару |
інформація про співробітників, що займають посаду менеджера товару |
мен_ id |
4. Даталогічне проектування
Атрибути всіх таблиць, ключі, типи даних атрибутів та їх опис представлено в таблиці 4.1.
Таблиця 4.1 - Атрибути таблиць бази
Назва таблиці |
Ключ |
Назва атрибута |
Тип даних |
Пояснення |
|
товари |
PK |
тов_id |
integer |
унікальний ідентифікатор товару |
|
тов_назв |
char(20) |
назва товару |
|||
тов_кол-во |
integer |
кількість товару в наявності |
|||
тов_стнд_кол-во |
integer |
стандартна кількість товару. Якщо кількість товару в наявності менше стандартної кількості, проводиться закупка |
|||
тов_цена |
decimal(10;2) |
ціна одиниці товару |
|||
FK |
пост_id |
integer |
номер постачальника, який відповідає за даний товар |
||
FK |
кат_id |
integer |
номер категорії, до якої відноситься товар |
||
постачальники |
PK |
пост_id |
integer |
унікальний ідентифікатор постачальника |
|
пост_имя |
char(40) |
ім'я постачальника |
|||
пост_тел |
char(20) |
номер телефону постачальника |
|||
категорії |
кат_назв |
char(20) |
назва категорії |
||
PK |
кат_id |
integer |
унікальний ідентифікатор категорії |
||
кат_опис |
text(100) |
опис категорії |
|||
замовлення |
FK |
кас_id |
integer |
касир, який оформив замовлення |
|
PK |
зак_id |
integer |
унікальний ідентифікатор замовлення |
||
FK |
кл_id |
integer |
клієнт, який зробив замовлення |
||
зак_дата |
datetime |
дата замовлення |
|||
зак_вып |
bool |
чи виконане замовлення |
|||
зак_оплачен |
bool |
чи сплатив клієнт замовлення |
|||
orderitems |
PK, FK |
зак_id |
integer |
унікальний ідентифікатор замовлення |
|
PK, FK |
тов_id |
integer |
унікальний ідентифікатор товару |
||
кол-во |
integer |
кількість даного товару в замовленні |
|||
касири |
PK |
кас_id |
integer |
унікальний ідентифікатор |
|
кас_имя |
char(40) |
ім'я касира |
|||
кас_контак |
text(100) |
контактні дані касира |
|||
клієнти |
PK |
кл_id |
integer |
унікальний ідентифікатор |
|
кл_имя |
char(40) |
ім'я клієнта |
|||
кл_тел |
char(20) |
номер телефону клієнта |
|||
замовлення на поставку |
FK |
мен_id |
integer |
унікальний ідентифікатор менеджера, який прийняв поставку |
|
PK |
П_зак_id |
integer |
унікальний ідентифікатор замовлення |
||
П_зак_дата |
datetime |
дата замовлення |
|||
П_зак_вып |
bool |
чи виконане замовлення |
|||
пост_orderitems |
PK, FK |
зак_id |
integer |
унікальний ідентифікатор замовлення |
|
PK, FK |
тов_id |
integer |
унікальний ідентифікатор товару |
||
кол-во |
integer |
кількість даного товару в замовленні |
|||
менеджери товару |
PK |
мен_id |
integer |
унікальний ідентифікатор |
|
мен_имя |
char(40) |
ім'я менеджера |
|||
мен_контак |
text(100) |
контактні дані менеджера |
5. Моделювання бізнес процесів
5.1 DFD
Рисунок 5.1 - DFD, процес покупки товару
Рисунок 5.2 - DFD, процес замовлення товару в постачальника
5.2 IDEF3
· PFDD
На рисунку 5.1 представлено діаграму PFDD першого рівня. Для таких процесів як №23 «sdelka» та №31 «postavka» було зроблено декомпозицію. Декомпозиція цих процесів представлена на рисунках 5.2 та 5.3 відповідно.
Рисунок 5.3 - PFDD першого рівня
Рисунок 5.4 - PFDD другого рівня, що розкриває процес №23 «sdelka»
Рисунок 5.5 - PFDD другого рівня, що розкриває процес №31 «postavka»
· OSTN
Рисунок 5.6 - OSTN для замовлення
Рисунок 5.7 - OSTN для клієнта
Рисунок 5.8 - OSTN для товару
Висновки
· В даній роботі було спроектовано АІС магазину «LARGO».
· Було виявлено, що для автоматизованої роботи магазину необхідні наступні таблиці в базі даних:
- товари
- постачальники
- категорії
- замовлення
- orderitems
- касири
- клієнти
- замовлення на поставку
- Пост_orderitems
- менеджери товару
· Було сформульовано вимоги до програми та спроектовано взаємозв'язки між таблицями в базі даних.
Список літературних джерел
1. http://www.belani.narod.ru [1]
Размещено на Allbest.ru
Подобные документы
Даталогічне проектування баз даних та концептуальне (інфологічне) проектування (побудова ER-діаграми та нормалізація даних) інформаційної системи. Фізичне проектування інформаційних систем (СУБД Access: об’єкти бази, створення таблиць, запитів та форм).
курсовая работа [3,5 M], добавлен 09.01.2010Розробка моделі системи "Автомобільного магазину". Вивчення основи мови моделювання UML. Створення її для визначення, візуалізації, проектування й документування програмних систем. Використання діаграм кооперацій, послідовності, станів та класів.
курсовая работа [257,8 K], добавлен 10.12.2014Проектування інформаційної системи; концептуальне (інфологічне) проектування, побудова ER-діаграми, нормалізація даних. Даталогічне проектування баз даних, фізичне проектування інформаційних систем. СУБД Access: об'єкти, створення таблиць, запитів, форм.
курсовая работа [13,9 M], добавлен 09.01.2010Характеристика категорій користувачів баз даних. Проектування інформаційної системи: концептуальне (інфологічне), даталогічне та фізичне. Опис бази даних "Каталог мобільних телефонів": принципи створення таблиць, запитів та форм. Інструкція користувача.
курсовая работа [63,2 K], добавлен 14.12.2010Розгляд процесу автоматизації бази даних для довідника астронома. Основи реляційних баз даних для проектування інформаційних систем. Застосування тригерів для забезпечення цілісності даних і реалізації складної бізнес–логіки в системних процедурах.
курсовая работа [22,3 K], добавлен 12.03.2019Інфологічна модель програмного забезпечення. Формалізація технології проектування інформаційної системи. Єдина система класифікації і кодування. Проектування технологічних процесів обробки даних в діалоговому режимі. Класифікація діалогових систем.
контрольная работа [126,9 K], добавлен 22.09.2009Проектування бази даних предметної області "Магазин будівельних матеріалів". Аналіз сукупності вхідних і вихідних даних, шляхи удосконалення інформаційної системи обліку товару. Організація інформаційної бази, розробка логічної і фізичної моделі.
курсовая работа [559,2 K], добавлен 09.05.2016Компоненти структурно-інформаційної системи. Розділення інформаційної системи (ІС) на окремі частини (декомпозиція) як метод проектування. Склад і зміст робіт на стадії робочого проектування ІС, його технологічна мережа. Система захисту інформації.
контрольная работа [34,2 K], добавлен 20.09.2009Життєвий цикл інформаційної системи як упорядкована сукупність змін його стану між початковим і кінцевим станами. Умови забезпечення адаптивного характеру розвитку ІС. Технологія проектування інформаційної системи, технологічна мережа проектування.
реферат [252,2 K], добавлен 20.06.2010Автоматизування процесу надходження та продажу товарів магазину за допомогою розробки баз даних (на прикладі магазину з продажу матеріалів для творчості). Вимоги до інформаційного забезпечення. Властивості концептуальної моделі програмного забезпечення.
курсовая работа [1,6 M], добавлен 29.12.2013