Меблева фірма розробка бази даних (стр. 2 из 7)
a) Діаграма потоків даних нульового рівня.
Є дві сутності: клієнт та працівник фірми. Вони обмінюються даними із системою, дають й отримують різноманітну інформацію. Система не конкретизована й уточнюється на наступних рівнях.
Ця діаграма для моєї бази даних показана на рисунку 1.1.
 |
Рисунок 1.1 – Діаграма потоків даних фірми нульового рівня
б) Діаграма потоків даних фірми першого рівня показана на рисунку 1.2.
Разбиваємо основну задачу на шість підзадач: регіструвати клієнта, обробити запит, облік виробів, створити калькуляцію, заключити договор й адмініструвати матеріали.
 | ||
 | ||
 | ||
-
 | ||||||||||
 | ||||||||||
 | ||||||||||
 | ||||||||||
 | ||||||||||
 | ||||||||||
База даних фірми
Рисунок 1.2 – Діаграма потоків даних фірми першого рівня
Відповідність потока даних нульового, першого та другого рівней наведена в таблиці 1.1.
Таблица 1.1 – Таблиця відповідності потоків даних фірми
| Дані 0 рівня | Поток даних 1 рівня | Поток даних 2 рівня |
| Інформація від клієнта | Особисті дані клиєнта | |
| Запит клиєнта | ||
| № клиєнта | ||
| Замовлення | Дані про замовлення | |
| Інформація для контракту | ||
| Інформація для клієнта | № клиента | |
| Відповідь на запит | ||
| Договір | № Договору | |
| Документ договір | ||
| Інформація від робітника фірми | Дані про новий матеріал | |
| Дані по виробу | ||
| Дані по калькульції | ||
| Інформація для робітника фірми | № матеріала | |
| № вироба | ||
| Калькуляція | ||
| Договір | № Договору | |
| Документ договір |
в) Створюємо діаграму потоків даних фірми другого рівня
Укладення договору розбивається на створення договору (5.1) та створення документу договору (контракту) (5.2). Це декомпозиція задачі про укладення договору на створення запису у таблиці договорів та створення документу про те, що договір було укладено. Діаграма потоків данних фірми другого рівня показана на рисунке 1.3.
 |
Рисунок 1.3 – Діаграма потоків даних фірми другого рівня
Ми отримали попередні дані про таблиці майбітньої бази даних. Їх запишемо в таблиці 1.2, де перший стовпчик є назвою таблиці, а другий складає шапку таблиці.
Таблица 1.2 – Атрибути, що відповідають потокам даних
| Поток даних | Атрибути |
| Особисті дані клієнта | Ф.І.П., адрес проживання, контактний телефон, інформація про те, чи є клієнт фізичною (домашній телефон та серія й номер паспорта) або юридичною особою (назва фірми, яку він представляє, факс та дані про банківський рахунок (назва банка, ОКПО, МФО, розрахунковий рахунок)), помітки |
| Запит клієнта | Номер договора, до якого відноситься виріб, найменування виробу, зовнішній вигляд виробу |
| № клиента | № клієнта |
| № Договору | № договору |
| Документ договір | Ф.І.П., найменовання виробу, код замовника, вартість, дата підписання, срок до якого потрібно установити виріб, дата закінчення гарантії |
| Дані про замовлення | Ф.І.П., найменовання виробу, код замовника, дата підписання, срок до якого потрібно установити виріб, дата закінчення гарантії |
| Інформація для контракту | Ф.І.П., найменовання виробу, код замовника, вартість, дата підписання, термін до установки, дата закінчення гарантії, загальний вигляд виробу |
| Дані про матеріал | Група, назва, вартість в грн., вартість в $, зовнішній вигляд |
| Дані по калькуляції | № виробу, назва матеріалу, одиниця виміру, кількість, вартість за одиницю матеріалу на час укладання договору |
| Дані по виробу | № виробу, № заказа, найменування, складність, ціна, загальний вигляд |
| № матеріалу | № матеріалу |
| № виробу | № виробу |
| Калькуляція | № Договору, № виробу, № матеріалу, кількість виробів, кількість матеріалів, ціна закупки матеріалу в $, ціна закупки матеріалу в грн. |
1.3 Постановка задачі
Необхідно об’єднати чисельну інформацію, яку зберігає фірма, у базу даних, для прискорення й спрощення роботи з цією інформацію.
Цей програмний продукт повинен виконувати такі функції, як регістрація клієнта, обробка запиту клієнта, підписання договору з ним, введення нових (або змінення вже існуючих) матеріалів та створення калькуляції виробів, а також підрахунок вартості виробу по калькуляції, та облік виробів.
Ця програма повинна чітко й зрозуміло давати можливість вводити інформацію про клієнта з урахуванням того, чи він є фізичною або юридичною особою, вводити нові матеріали та вироби, заключати договори та коректно вводити калькуляцію по виробам та договорам.
Таким чином кожен з розділів, вказаних у діаграмі потоків даних повинен бути присутнім у програмі у вигляді окремої форми, яку можна буде вибрати із головного меню або із підлеглих меню, і яка давитиме можливість ввести дані, необхідні для того, щоб заповнити усі поля відповідної таблиці, а також повинна контролювати процес введення – тобто не дозволяти вводити запис, в якому деякі обов’язкові поля залишилися пустими і виводити спеціальне повідомлення про те що необхідно заповнити перше з пустих полей.
Програма буде виконана у середовищі Microsoft Access, це необхідно замовнику для забезпечення кращої взаємодії майбутньої бази даних з іншими програмними продуктами та файлами, що зберігаються на комп’ютері замовника.
Системні вимоги до розробленого програмного засобу. Для нормальної роботи програми необхідно мати:
- наявність Microsoft Office 2003 на вашому комп’ютері;
- 5 Mb вільного простору на жорсткому диску;
- достатня оперативна пам’ять 32 Mb;
- відео карта 16 Mb;
- комп’ютер Intel Pentium III, Mobile CPU 1000 MHz;
- система Microsoft Windows XP Professional версія 2002 Service Pack 2.
2 РОЗРОБЛЕННЯ ПРОЕКТУ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ МЕБЛЕВОЇ ФІРМИ З БАЗОЮ ДАНИХ МЕБЛЕВОЇ ФІРМИ
2.1 Розробка концептуальної моделі бази даних
Наступним шагом після аналізу предметної області під час подібних досліджень є створення концептуальної моделі майбутньої бази даних. Це її графичне зображеня в термінах предметної області.
Ця модель показує структуру майбутньої бази даних, зв’язки що в ній діють, взаємодію основних сутностей.
Ця концептуальна модель буде відображати сутності прямокутниками, причому якщо це слабка сутність (сама по собі існувати не може, тобто не може існувати без інших сутностей), то вона буде представлена подвійнтм прямоукутником. Також на ній будуть відображені атрибути, характеристики цих сутностей (зображені овалами) та зв’язки між сутностями (зображені ромбами).
В цілому це частина інфологічної моделі предметної області, яка визначає сукупність інформаційних об’єктів, їх атрибутів та відношень між об’єктами, динамику зміни предметної області, а також характер інформаційних вимог користувача.
Спочатку складається концептуальна модель бази даних. Вона визначає систему основних понять та правил комбінування цими класами понять, які не залежать від язиків розробки і ї смисловою структурою бази даних.
Якщо в структурі нічого не будет змінюватися, то концептуальна модель також не зміниться.
При проектуванні баз даних використовуються діаграми сутність-зв’язок ERD (Entity Relationship Diagrams). Іноді ця модель називаеться моделлю Чена. Це семантична модель, не іерархія, а одна діаграма, яку можна розбити на частини для більш зручної роботи. Згідно з цією нотацією на діаграмах зображуються сутності, інформацію про яких ми будемо зберігати в базі даних. Це сутності внутрішні, хоча є й одноймені зовнішні сутності.