Зв'язок між сутностями замовлення і послуга характеризується однією або декількома послугами, які замовляє замовник. При цьому одна і та ж послуга може бути в декількох замовленнях.
Зв'язок між сутностями замовлення і комплектація характеризується однією або декількома комплектаціями, які замовляє замовник. При цьому одна і та ж комплектація може бути в декількох замовленнях.
Зв'язок між сутностями замовлення і об'єкт характеризується об'єктом (тільки одним), на який націлена послуга замовлення. Хоча один і той же об'єкт може бути в декількох замовленнях.
Зв'язок між сутностями постачальник і комплектація характеризується комплектацією, яку постачає постачальник.
При проектуванні бази даних слід дотримуватися правил нормалізації таблиць:
Правило 1: Кожне поле будь-якої таблиці повинно бути унікальним.
Правило 2: Кожна таблиця повинна мати унікальний ідентифікатор (первинний ключ), який може складатися з одного або декількох полів таблиці.
Правило 3: Для кожного значення первинного ключа має бути одне і тільки одне значення будь-якого з шпальт даних, і це значення має ставитися до об'єкта таблиці.
Правило 4: Повинна бути можливість змінювати значення будь-якого поля (що не входить в первинний ключ), і це не повинно спричинити за собою зміну іншого поля [8].
Малюнок 4. Інформаційно-логічна модель
Кожен агрегований об'єкт буде представлений окремою таблицею бази даних. Елементи даних будуть представлені полями таблиць. Імена таблиць і їх полів підберемо виходячи з імен об'єктів та елементів даних.
У мережній моделі даних поняття головного і підлеглих об'єктів дещо розширені. Будь-який об'єкт може бути і головним, і підлеглим (в мережевій моделі головний об'єкт позначається терміном власник набору raquo ;, а підлеглий - терміном член набору ). Один і той же об'єкт може одночасно виступати і в ролі власника, і в ролі члена набору. Це означає, що кожен об'єкт може брати участь у будь-якому числі взаємозв'язків.
Концептуальна модель транслюється потім у модель даних, сумісну з обраної СУБД.
. 4.3 Обмеження, накладиваемость на дані
Забезпеченням цілісності бази даних називається система заходів, спрямованих на підтримку правильності даних у базі в будь-який момент часу.
У СУБД цілісність даних забезпечується набором спеціальних пропозицій, званих обмеженнями цілісності. Обмеження цілісності - це набір певних правил, які встановлюють допустимість даних і зв'язків між ними. Обмеження цілісності в більшості випадків визначаються особливостями предметної області.
Обмеження цілісності можуть ставитися до різних об'єктів БД: атрибутам (полях), записам, відносинам, зв'язкам між ними і т. п.
Для полів можуть використовуватися такі види обмежень:
· Тип і формат поля автоматично допускають введення тільки даних певного типу.
· Вибір типу поля Date у форматі ДД.ММ.ГГ дозволить користувачеві ввести тільки шість чисел. При цьому перша пара цифр не зможе перевищити в кращому випадку значення 31, а друга - 12.
· Завдання діапазону значень, як правило, використовується для числових полів. Діапазон допустимих значень може бути обмежений з двох сторін (закритий діапазон), а може з якоїсь однієї: верхньої або нижньої (відкритий діапазон).
· Неприпустимість порожнього поля дозволяє уникнути появи в БД нічийних записів, в яких пропущені будь-які обов'язкові атрибути.
· Завдання списку значень дозволяє уникнути зайвого різноманітності даних, якщо його можна обмежити.
· Перевірка на унікальність значення якогось поля дозволяє уникнути записів-дублікатів. Навряд чи буде зручно в довіднику клієнтів мати кілька записів для одного і того ж особи.
3. Експериментальна частина
Основною метою побудови автоматизованої інформаційної системи фірми Вікна Маріо є зберігання інформації про діяльність фірми (її замовленнях), про її співробітників і замовниках.
У будь-який момент інформація про поточний стан справ фірми може бути переглянута на формах або роздрукована зі звітів БД.
3.1 Розробка програмних модулів
. 1.1 Розробка таблиць
Існує три різновиди зв'язків між таблицями бази даних:
