Сутність: ПЛАТІЖНА ІНФОРМАЦІЯ
Короткий опис сутності. Платіжні дані юридичних осіб.
Атрибути. Сутність характеризується наступними атрибутами:
- Код
- Номер платіжного рахунку
- Назва банку
- Адреса банку
Зв’язки. Сутність ПЛАТІЖНА ІНФОРМАЦІЯне має зв’язки з іншими сутностями:
Бізнес–правила. ПЛАТІЖНА ІНФОРМАЦІЯ унікально ідентифікується кодом та номером платіжного рахунку, які повинні бути унікальними і обов’язковими.
Сутність: СПІВРОБІТНИК
Короткий опис сутності. Особа яка працює на складі.
Атрибути. Сутність характеризується наступними атрибутами:
- Код співробітника
- Імя
- Прізвище
- По батькові
- Графік роботи
- Місце роботи
- Техніка
Зв’язки. Сутність СПІВРОБІТНИК маєтакі зв’язків з іншими сутностями:
- СПІВРОБІТНИЕ обовязково має графік роботи
- СПІВРОБІТНИК може Місце роботи або Техніку за якими закріплений
Бізнес–правила. СПІВРОБІТНИК унікально ідентифікується кодом співробітника, який повиннен бути унікальними і обов’язковими.
Сутність: ГРАФІК РОБОТИ
Короткий опис сутності. Описує графік роботи спіробітників, техніки та терміналів
Атрибути. Сутність характеризується наступними атрибутами:
- Код граффіку
- Початок роботи
- Кінець роботи
Зв’язки. Сутність ГРАФІК РОБОТИне має зв’язків з іншими сутностями.
Бізнес–правила. ГРАФІК РОБОТИ унікально ідентифікується кодом графіку, який повиннен бути унікальним і обов’язковим.
|
|
|
Сутність: ТЕХНІКА
Короткий опис сутності. Описує техніку яка працює на складі
Атрибути. Сутність характеризується наступними атрибутами:
- Реестраційний номер
- Тип техніки
- Графік роботи
- Співробітника
Зв’язки. Сутність ТЕХНІКА має такі зв’язки з іншими сутностями:
- ТЕХНІКА обовязково має графік роботи.
- ТЕХНІКА обовязково має Співробітника.
Бізнес–правила. ТЕХНІКА унікально ідентифікується Реестраційним номером, який повиннен бути унікальним і обов’язковим.
Сутність: ТЕРМІНАЛ
Короткий опис сутності. Термінал – це пункт видачі чи прийому товару на складі
Атрибути. Сутність характеризується наступними атрибутами:
- Номер терміналу
- Місця
- Графік роботи
Зв’язки. Сутність ТЕРМІНАЛ має такі зв’язки з іншими сутностями:
- ТЕРМІНАЛ обовязково має місця зберігання.
- ТЕРМІНАЛ обовязково має Графік роботи.
Бізнес–правила. ТЕРМІНАЛ унікально ідентифікується Номером терміналу, який повиннен бути унікальним і обов’язковим.
Інформаційно-довідкові задачі
Проведений аналіз предметної області дозволив виділити перелік сутностей, що беруть участь у ведені обліку та організації на складі. Аналіз цих сутностей та їх атрибутів, дозволяє виділити декілька класів типових інформаційно-довідкових задач.
|
|
|
По-перше, інформація, що пов’язана з відпуском та прийомом товарів:
· надання повної інформації по товарам, замовникам та накладним.
· надання інформації по видам, товарів.
По-друге, це інформація організаційного характеру:
· надання інформації про місце зберігання товарів (складм, місцям зберігання або терміналам через які є доступ до місць зберігання товарів).
По-третє, це інформація, що відноситься до процесу керування складом:
· надання інформації по співробітникам;
· техніці
· розпорядком роботи співробітникі та техніки
Логічне та фізичне проектування бази даних
Завдання цього етапу полягає у проведенні логічного та фізичного проектування бази даних.
Логічне проектування — це розробка логічної структури системи баз даних без прив'язки до конкретної СУБД, структур збереження, методам доступу і т.д..
Фізичне проектування – це проект системи бази даних для конкретної СКБД. Під час виконання даного етапу модель сутностей і зв'язків перетворюється в схему бази даних і специфікації позамашинного збереження.
Логічне проектування
|
|
|
У якості логічній моделі бази даних була обрана реляційна модель, оскільки саме реляційна модель використовується у більшості розвинених СКБД.
Для перетворення концептуальної моделі, представленої у вигляді мови ER–моделювання, у реляційну модель, був використаний наступний алгоритм.
· Крок 1. Перетворення сутностей у таблиці. Кожна сутність перетворюється у таблицю. Ім’я сутності представляється у вигляді семантично осмисленого імені у латинському алфавіті.
· Крок 2. Перетворення атрибутів у стовпці. Кожний атрибут перетвориться в стовпець. Ім’я атрибуту представляється у вигляді семантично осмисленого імені у латинському алфавіті. У цей момент уточнюється формат представлення значень стовпця. Факультативні атрибути стають NULL-стовпцями. Обов'язкові атрибути стають NOT NULL-стовпцями.
· Крок 3. Подання унікальних ідентифікаторів ключами таблиць. Складові унікального ідентифікатора сутності стають первинним ключем таблиці. Нагадаємо, що сутність може мати більш ніж один унікальний ідентифікатор Тому вибирається той, котрий використовується найбільше часто. Всі інші унікальні ідентифікатори приймають обмеження цілісності UNIQUE NOT та NOT NULL.
 |
|
|
|
Рис. Концептуальна ER-модель
Сутність може унікально ідентифікуватися комбінацією атрибутів і/або зв'язків. При використанні в ідентифікаторі сутності зв'язку до складу первинного ключа включається зовнішній ключ, який посилається на ту таблицю, з якою пов’язаний той або інший зв’язок.
· Крок 4. Перетворення зв'язків багато-до-одного й один-до-одного в зовнішні ключі. Зв'язки типу багато-до-одного й один-до-одного породжують зовнішні ключі. Інакше кажучи, необхідно взяти унікальні ідентифікатори кожної сутності, розташованої в закінчення зв'язку зі ступенем один, і ввести його у відношення, розташоване з боку зв'язку "багато" як стовпці. Факультативним зв'язкам відповідають NULL-стовпці. Обов'язковим зв'язкам відповідають NOT NULL-стовпці.
· Крок 5. Введення спеціальних первинних ключів. Для більш адекватного відображення логічного проекту бази даних у фізичний, вводимо у всі таблиці один спеціальний стовпець з обмеженням цілісності первинного ключа. Всі ті стовпці, які мають властивість первинного ключа згідно з концептуальною моделлю, набувають обмеження цілісності UNIQUE таNOTNULL.
Повна логічна база даних на основі концептуальної моделі з урахуванням обмежень цілісності та наведеного вище алгоритму детально представлена в наступних таблицях.
В даній базі даних, міститься 11таблиць. Далі в таблиці наведений опис кожної таблиці.
| Ім’я стовпця | Тип | Довжина | Призначення | Обмеження цілісності стовпців |
| GOODS | ||||
| Code | лічильник | Унікальне значення | Первинний ключ | |
| Name | строка | 50 | Назва товару | Обов’язковий |
| EAN13 | строка | 50 | Код EAN13 товару | Первиний ключ Обов’язковий Унікальний |
| Cost | Дійсне число | Max,10 | Ціна товару | |
| TypeFK | Ціле число | Код типу товару | Обовязковий Зовнішній ключ, що посилається на первинний ключ відношення GOODS_TYPE | |
| StoringPlaceFK | Ціле число | Місце зберігання товару | Обовязковий Зовнішній ключ, що посилається на первинний ключ відношення Storage | |
| Number_of_units | Ціле число | Кількість одиниць товару в наявності | Обов’язковий | |
| BILL | ||||
| Number | лічильник | Унікальне значення | Первинний ключ Обовязковий | |
| Type | строка | Визначає тип накладної | Обов’язковий, може приймати значення: (ПОСТАВКА, ЗАМОВЛЕННЯ) | |
| ContractorFK | ціле число | 50 | Код Контрагента | Зовнішній ключ, що посилається на первинний ключ відношення Contractor Обовязковий |
| GoodsFK | ціле число | Код товару який внесенно до накладної | Зовнішній ключ, що посилається на первинний ключ відношення GOODS Обовязковий | |
| Number_of_units | ціле число | Кількість товарів | Обов’язковий | |
| Cost | Дійсне число | Max,10 | Ціна всіх товарів | Суммарна ціна всіх товарів |
| Financially_responsible_personFK | ціле число | Код Співробітника який є матеріально відповідальним за дану операцію | Зовнішній ключ, що посилається на первинний ключ відношення EMPLOYEE Обовязковий | |
| WAREHOUSE | ||||
| Num | лічильник | Унікальне значення | Первинний ключ Обовязковий | |
| StorageFK | ціле число | Номер місця зберігання | Обовязковий Зовнішній ключ, що посилається на первинний ключ відношення STORAGE | |
| GOODS_TYPE | ||||
| TypeCode | лічильник | Унікальне значення | Первинний ключ Обовязковий | |
| Description | строка | 50 | Опис типу товару | Обовязковий Може приймати тільки такі значення · Бакалія · Хімія · Техніка · Одяг та взуття · Парфумерія · Овочі · Фрукти |
| STORAGE | ||||
| StorageNum | лічильник | Унікальне значення | Первинний ключ. Обов’язковий | |
| EmployeeFK | ціле число | Код співробітника закріпленого за місцем | Обов’язковий Зовнішній ключ, що посилається на первинний ключ відношення EMPLOYEE | |
| GoodsFK | ціле число | Код товару який зберігається | Обов’язковий Зовнішній ключ, що посилається на первинний ключ відношення GOODS | |
| WarehouseFK | Ціле число | Код скалду на якому знаходиться | Обов’язковий Зовнішній ключ, що посилається на первинний ключ відношення WAREHOUSE | |
| TerminalFK | Циле число | Код терміналу через який є доступ до місця зберігання | Обов’язковий Зовнішній ключ, що посилається на первинний ключ відношення TERMINAL | |
| CONTRACTOR | ||||
| Code | лічильник | Унікальне значення | Первинний ключ Обовязковий | |
| Name | ціле число | Назва контрагента | Первинний ключОбов’язковий | |
| Billing_infoFK | Ціле число | 10 | Платіжна інформація код платіжної інформації | Зовнішній ключ, що посилається на первинний ключ відношення BILLING_INFORMATION Обов’язковий |
| Adress | строка | 50 | Адреса кконтрагента | |
| BILLING_INFORMATION | ||||
| Code | лічильник | Унікальне значення | Первинний ключОбов’язковий | |
| BankName | строка | 50 | Назва банку | Обов’язковий |
| Account_Number | строка | 20 | Номер рахунку | Унікальинй Обов’язковий |
| BankAdres | строка | 20 | Адреса банку | Обов’язковий |
| EMPLOYEE | ||||
| Code | лічильник | Унікальне значення | Первинний ключОбов’язковий | |
| Name | строка | 50 | Імя спіробітника | Обов’язковий |
| Last_Name | Строка | 50 | Прізвище співробітника | Обов’язковий |
| Middle_Name | Строка | 50 | По батькові співробітника | Обов’язковий |
| ScheduleFK | Ціле число | Код графіку роботи | Зовнішній ключ, що посилається на первинний ключ відношення SCHEDULE Обов’язковий | |
| StorageNumFK | Ціле число | Номер місця зберігання | Зовнішній ключ, що посилається на первинний ключ відношення STORAGE | |
| TechnicNumFK | Ціле число | Номер транспортного засобу | Зовнішній ключ, що посилається на первинний ключ відношення TECHNIC | |
| SCHEDULE | ||||
| Code | лічильник | Унікальне значення | Первинний ключОбов’язковий | |
| StartTime | Дата | Час початку роботи | Обов’язковий | |
| EndTime | Дата | Час кінця роботи | Обов’язковий | |
| TECHINC | ||||
| Reg_number | лічильник | Унікальне значення | Первинний ключОбов’язковий | |
| Type | строка | 50 | Назва техніки | Обов’язковий Може приймати значення · Навантажувач · Грузовий · Кран |
| Schedule_CodeFK | Ціле число | Код графіку роботи | Обовязковий Зовнішній ключ, що посилається на первинний ключ відношення SCHEDULE Обов’язковий | |
| Employee_CodeFK | Код співробітника | обовязковий Зовнішній ключ, що посилається на первинний ключ відношення EMPLOYEE Обов’язковий | ||
| TERMINAL | ||||
| Num | лічильник | Унікальне значення | Первинний ключОбов’язковий | |
| EmployeeFK | Ціле число | Код співробітника закріпленог о за місцем | Зовнішній ключ, що посилається на первинний ключ відношення EMPLOYEE Обов’язковий | |
| ScheduleFK | Ціле число | Код графіку роботи | Обов’язковий Зовнішній ключ, що посилається на первинний ключ відношення SCHEDULE Обов’язковий | |
| StorageFK | Ціле число | Місця в реміналі | Обов’язковий Зовнішній ключ, що посилається на первинний ключ відношення STORAGE Обов’язковий | |
Фізичне проектування
База даних спроектована для її збереження у СКБД Oracle, яка підтримує реляційну модель даних і є об’єкто-реляційною СКБД. Ця СКБД має дуже розвинені можливості по створенню та супроводу баз даних, оскільки володіє найбільш розвиненою системою типів даних, можливостями індексування полів, що дозволяє одержувати доступ до даних за мінімальний час, а також функціями по забезпеченню підтримки цілісності даних між реляційними таблицями, що дозволяє розробнику мінімізувати тимчасові витрати на створення бази даних, а кінцевому користувачеві витрати на підтримку цілісності збережених даних і одержання даних з бази даних. Робота з базою даних підтримується за допомогою реляційної мови запитів SQL.
Логічна модель бази даних легко відображається в реляційну фізичну модель, оскільки логічна модель була побудована з використанням реляційної структури даних. Крім того, логічна модель була приведена у третю нормальну форму, тому усі відношення представляються у фізичній моделі окремими таблицями. Ніякі злиття відношень в одну таблицю для підвищення ефективності виконання окремих класів запитів не виконуються у зв’язку з тим, що такі класи запитів не були знайдені. У результаті отримано сімнадцять таблиць реляційної бази даних, де кожне відношення прямо відповідає окремій таблиці, атрибути кожного відношення стають полями цієї таблиці, а первинні ключі відношень стають первинними ключами таблиць.
Дата добавления: 2018-04-05; просмотров: 245; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!