Меблева фірма розробка бази даних (стр. 3 из 7)

У концептуальній моделі моєї бази даних присутні чотири внутрішні сутності. Це Замовник, Договір, Виріб й Матеріал. А також дві підсущності у замовника: Фізична особа та Юридична особа.

Я вибрала цю нотацію тому, що вона одна показує атрибути зв’язку.

Концептуальна модель моєї бази даних зображена на рисунку 2.1.

Рисунок 2.1 – Концептуальна модель бази даних для меблевої фірми

Цей рисунок є графічним зображенням майбутньої бази даних, що чітко показує її структуру та зв’язки між її частинами.

2.2 Розробка специфікації програмних модулів

Після того, як були проаналізовані і з’ясовані всі процедури і функції, які повинна виконувати база даних для меблевої фірми, можна визначити програмний склад для роботи з цією базою.

Після запуску головної форми користувач повинен отримати можливість відкрити всі інші форми. Серед них мають бути наступні:

-Форма довідки, в якій має бути описано призначення даної бази даних та відповідного програмного забезпечення для неї.

-Форма регістрації клієнта “Замовник” – призначена для внесення в базу даних нових та редагування вже існуючих записів клієнтів. Вхідні дані: Фамілія, Ім’я, По батькові, Адреса, Телефон, Примітки (необов’язкова інформація). Крім того клієнт може бути: фізичною особою (серія паспорту, номер паспорту, домашній телефон (необов’язкове поле)); юридичною особою (ім’я фірми, факс, назва банку, МФО, ОКПО, розрахунковий рахунок). Вихідні дані: код замовника.

- Форма обліку договорів “Договір“ – призначена для обліку договорів. Вхідні дані: Термін до установки, Код замовника, Дата закінчення гарантії, загальний вигляд (необов’язкова інформація). Вихідні дані: номер договору.

- Форма обліку виробів “Виріб“ – призначена для введення нових виробів. Вхідні дані: Найменування, Складність, Загальний вигляд (необов’язкова інформація). Вихідні дані: номер виробу.

- Форма адміністрації матеріалів “Матеріал“ – призначена для введення нових та редагування вже існуючих матеріалів. Вхідні дані: Група, Назва, Одиниця виміру, Ціна $, Ціна грн., Зовнішній вигляд (необов’язкова інформація). Вихідні дані: номер матеріалу.

- Форма калькуляції виробів за належністю до договору “Калькуляція” – призначена для забезпечення зв’язку між Договорами, Виробами та Матеріалами, а також коректно повинна запам’ятовувати ціни, при яких буде введений даний елемент калькуляції. Вхідні дані: Номер договору, Номер виробу, Кількість виробів, Номер матеріалу, Кількість матеріалів, ціни в доларах та гривнях. Вихідні дані: зв'язок між Договорами, Виробами та Матеріалами.

- Форма “Звітів та договорів” – призначена для отримання звітів про вироби та матеріали, про договори по конкретних клієнтах, а також для отримання документу договору.

2.3 Розробка логічної моделі бази даних

За технологією проектування, після розробки концептуальної моделі формується логічна модель даних. Вона формується в поняттях баз даних, але не залежить від СУБД.

Визначаємо таблиці, поля таблиць та типи даних, які будуть мати ці поля, а також визначаємо зв’язки між таблицями.

Визначені типи даних переносимі.

Типи:

- числові дані (N);

- текстові, строка (S);

- тип даних дати (D);

- тип Blob (Binary large object) – великий двійковий об’єкт, блок пам’яті. Це можуть бути великі тексти, відео, код;

- інші (O).

Зберігається інформація про ключі (первинні (PK), зовнішні (FK), альтернативні (AK), індексні (IK)).

Зовнішній ключ – один або дукілько атрибутів, за допомогою яких підлегла таблиця зв’язується з батьківською.

Індексний ключ – атрибут, за допомогою якого інформація в таблиці буде впорядкованою.

Альтернативний ключ - один або декілька атрибутів, за допомогою яких будуть здійснюватися запити.

Концептуальну модель даних, отриману у попередній роботі перетворимо на логічну. Для цього виділяємо кожні дві сутності й зв’язки між ними та послідовно переходимо від кожної такої групи до її логічного вигляду.

Здійснивши всі можливі переходи, отримаємо логічну модель моєї бази даних. На ній ми будемо вказувати необов’язкові поля. Вона зображена на рисунке 2.2.

Рисунок 2.2 – Логічна модель бази даних для меблевої фірми

2.4 Розробка алгоритмів і графічних інтерфейсів програмних модулів

Головна форма повинна містити елементи, які дозволятимуть перейти до інших форм, таких, як довідка, фрми обліку клієнтів. договорів та виробів, форм адміністрації матеріалів та калькуляції, а також форму звытыв та договору. Такими елементами можуть бути кнопки, при натисканні якої бе визиватися відповідна форма. Також головна форма, як і всі інші, повинна мати кнопку виходу. Форма довідки повинна містити інформацію про те, для чого призначена база даних та відповідне програмне забезпечення, а також інформацію про розробника. Форма клієнтів фірми повинна містити такі поля: код замовника, його Ф.І.П., адрес, телефон, примітки (необов’язкове поле), а також групу вибору чи є клієнт фізичною або юридичною особою і відповідно до цього поля серія паспорта, номер паспорта, контактний телефон (необов’язкове поле) або і’мя фірми, факс, назва банку, МФО, ОКПО, розрахунковий рахунок. Вказана група повинна буде почергово відкривати та закривати доступ до полей фізичної та юридичної особи. Крім кнопки виходу повинна бути кнопка добавити запис. Ця кнопка при натисканні перевіряє чи всі необхідні поля були заповнені, якщо так, то видавати повідомлення про перше з полей, які залишилися пустими, інакше – добавляти запис. Це робиться шляхом перевірки того, чи не є текст кожного з полів нульовим.

Форма договір повинна містити такі поля: код договору, код замовника, дата заключення, термін до установки, дата закінчення гарантії. Кнопка добавити запис повинна працювати так само, як і відповідна кнопка на формі клієнтів.

Форма виріб повинна містити такі поля: номер виробу, найменування, складність та загальний вигляд (необов’язкове поле), а також такі ж кнопки добавити та вийти.

Форма калькуляція повинна мати такі поля: номер договору, номер виробу, кількість виробів, номер матеріалу, кількість матеріалів, ціна закупки матеріала в гривнях, ціна закупки матеріала в доларах (тобто рівень цін, при якому було замовлено цей матеріал), поточна ціна матеріала в гривнях та поточна ціна матеріаля в доларах (тобто поточний рівень цін). Крім того ця форма повинна мати автоматизоване управління всіма чотирма цінами, що контролюватиме їх однозначне та точне введення та спрощений механізм додовання схожих записів. Поточні ціни добавлятимуться шляхом копіювання з таблиці матеріалів після введення матеріалів, а ціни даного елемента калькуляції після натискання на кнопку “Цена” копіюватимуться із поточних цін. Форма матеріалів повинна мати такі поля: номер матеріалу, його гнупа, назва, одиниця виміру, ціна за одиницю маткріалу в доларах та ціна за одиницю маткріалу в гривнях, зовнішній вигляд (необов’язкове поле) та знову ж кнопки навігації.

Форма звітів та договорів повинна мати елементи управління (наприклад, кнопки), які дозволятимуть продивлятися, зберігати та друкувати звіти по матеріалах, виробах, договорах та сам документ договору.

2.5 Розробка фізичної моделі бази даних

2.5.1 Вибір засобів розробки

Вибір засобів розробки було остаточно визначено у першому розділі в пункті Постановка задачі як вимогу замовника. База даних буде розроблятися у середовищі Microsoft Access. Програмний код у такому випадку буде написаний мово Visual Basic.

2.5.2 Розробка фізичної моделі даних

На цьому этапі здійснюється прив’язка до конкретного середовища розробки.

На фізічній моделі представляється вся інформація з логіченої моделі, але визначається її конкретний тип саме у вибраному середовищі розробки. Наприклад, число в логічній моделі повинно бути уточнено у фізичній моделі як ціле, байт або довге ціле. Для вещественого числа необхідно вказувати кількість знаків після коми. Для строки або текста довжина, тобто кількість символів. Для цього для кожної таблиці із логичної моделі будується табличка, що показана у таблиці 2.1.

Таблица 2.1 – Зразок таблиці відповідності логічної та фізичної моделі

Ім’я фізичної моделі	Ім’я логічної моделі	Тип	Довжина тексту	Кількість знаків післе коми	Ключі

Середовище розробки моєї бази даних – Micrsoft Access. Воно дозволяє називати поля російськими буквами і навіть використовувати пробіли у назвах. Тому імена фізічної й логічної моделей будуть співпадати. Тому в таблицях я буду об’єднувати поля Ім’я фізичної моделі та Ім’я логічної моделі в поле Ім’я моделі.

Таблиця відповідності логічної та фізичної моделей для таблиці Договір зображена у таблице 2.2.

Таблиця 2.2 – Відповідність моделей для таблиці Договір

Ім’я модели	Тип	Ключі
№ договору	Лічильник	РК
Код замовника	Довге ціле	FK
Термін до установки	Дата/Час
Дата закінчення гарантії	Дата/Час
Загальний вигляд	Поле об’екту OLE
Дата заключення	Дата/Час

Таблиця відповідності логічної та фізичної моделей для таблиці Вироби зображена у таблиці 2.3.

Таблиця 2.3 – Відповідність моделей для таблиці Вироби

Ім’я моделі	Тип	Довжина текстау	Ключі
№ виробу	Лічильник	РК
Найменування	Текстовий	30	IK
Складність	Байт
Загальний вигляд	Поле об’екту OLE

Таблиця відповідності логічної та фізичної моделей для таблиці Матеріал зображена у таблиці 2.4.