екземпляр сутності бере участь у зв'язку, то клас приналежності - обов'язковий, інакше - необов'язковий.
Судячи з предметної області автоматизируемой системи, сутностей в системі буде 4:
а) Відповідальна особа;
б) Замовлення;
в) Клієнт;
г) Товар.
Первинні ключі для більш зручного використання краще призначити сурогатні, наприклад: №_Заказа.
Замовлення має статус (стан), вже виконано або знаходиться на оформленні;
Замовлення має певний товар (товари), і ці товари можуть також належати іншим замовленнями;
Купити (замовити) товар може будь-який клієнт, якщо немає вікового обмеження;
За кожним замовленням закріплено відповідальну особу.
На основі цих даних можна побудувати діаграму ER-типу:
Малюнок 1. Діаграма ER-типу
Дослідження набору відносин на надмірність:
Якщо ступінь зв'язку M: N , то генеруємо трьох відносини, по одному на кожну сутність, ключами відносин будуть ключі відповідної сутності й одне відношення для зв'язку. Ставлення зв'язки серед своїх атрибутів повинно містити ключі пов'язують сутностей.
Order_Product:
а) Order (Order_No, Client_No, INN, Date_O, Order_status)
б) Product (Product_No, Category, Name_product, Cost, Kolichestvo_products, Date_P)
в) Order_Product (Order_No, Product_No, Kolichestvo_orders, Sold_orders, OrderProduct_No)
Якщо ступінь зв'язку 1: N і клас приналежності N -связной суті є обов'язковим, то генеруємо два відношення. Ключами відносини будуть ключі відповідної сутності. Крім того ключ однозв'язної суті додається як атрибуту у відношення виділене для N -связной сутності.
Responsible_person- Order:
а) Responsible_person (INN, Surname, Name, Patronymic)
б) Order (Order_No, Client_No, INN, Date_O, Order_status)
Client-Order:
а) Client (Client_No, Surname_C, Name_C, Patronymic_C, Adress, Telephone, Date_C, Unit)
б) Order (Order_No, Client_No, INN, Date_O, Order_status)
Набір попередніх відносин є надлишковим, тому існує відносини, безліч атрибутів якого було б підмножиною атрибутів іншого відношення даного набору. Отже, попередній набір відносин не є остаточним. Тоді остаточним набором буде:
а) Order (Order_No, Client_No, INN, Date_O, Order_status)
б) Product (Product_No, Category, Name_product, Cost, Kolichestvo_products, Date_P)
в) Order_Product (Kolichestvo_orders, Sold_orders, OrderProduct_No, Order_No, Product_No)
г) Responsible_person (INN, Surname, Name, Patronymic)
д ) Client (Client_No, Surname_C, Name_C, Patronymic_C, Adress, Telephone, Date_C, Unit)
3.2 Проектування бази даних за допомогою CASE-засобів
(англ. Computer-Aided Software Engineering) - набір інструментів і методів програмної інженерії для проектування програмного забезпечення, який допомагає забезпечити високу якість програм, відсутність помилок і простоту в обслуговуванні програмних продуктів.
Також під CASE розуміють сукупність методів і засобів проектування інформаційних систем з використанням CASE-інструментів. У нашому випадку CASE-засобом є програма ERwin.
.2.1 Коротко про IDEF1X (Information Modeling) - одна з методологій сімейства IDEF. Застосовується для побудови інформаційної моделі, яка представляє структуру інформації, необхідної для підтримки функцій виробничої системи чи середовища.
Метод IDEF1, розроблений Т. Ремей (T. Ramey), також заснований на підході П. Чена і дозволяє побудувати модель даних, еквівалентну реляційної моделі в третій нормальній формі. В даний час на основі вдосконалення методології IDEF1 створена її нова версія - методологія IDEF1X. IDEF1X розроблена з урахуванням таких вимог, як простота вивчення і можливість автоматизації. IDEF1X-діаграми використовуються поруч поширених CASE-засобів (зокрема, ERwin, Design/IDEF).
автоматизований інформаційний база даний
3.2.2 Побудова логічної...
