одержанні моделі БД у термінах про єктів та зв язків между ними, что НЕ поклади від конкретної СУБД ї Узагальнює інформаційні вимоги потенційніх Користувачів ІС. Розрізняють дві основні методи концептуального інфологічного проектування: нізхідне проектування (метод формулювання та АНАЛІЗУ сутности) i вісхідне проектування (метод синтезу атрібутів). ЦІ методи недостатньо формалізовані, єдініх правил использование їх НЕ існує.
Найпрідатнішім для практичного! застосування є перший метод. ВІН складається з двох етапів проектування БД: ідентіфікації та моделювання локальних інформаційних структур.
Наведемо приклад на Основі релік природної мови, на кшталт Користувач замовляє продукцію raquo ;, формуємо основні сутності розроблювані проекту та Встановлюємо атрибути для ціх сутности:
product
- ID, 2 - name, 3 - category.
pc_info
- ID, 2 - image, 3 - name, 4 - proc, 5 - chipset, 6 - memory, 7 - hard, 8 - videoproc, 9 - memvideo, 10 - typevideo, 11 - drive , 12 - tuner, 13 - os, 14 - power, 15 - guarantee, 16 - price, 17 - pid.
users
- ID, 2 - login, 3 - psswd, 4 - pib, 5 - mail, 6 - phone, 7 - secret, 8 - vidp, 9 - address, 10 - index1, 11 - role.
zakaz
- ID, 2 - status, 3 - cid, 4 - pid, 5 - lid, 6 - uID.
product
- gt; 2,3
pc_info
- gt; 2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17
users
- gt; 2,3,4,5,6,7,8,9,10,11
zakaz
- gt; 2,3,4,5
Встановімо зв язки между сформованому сутности:
Таблиця product має зв язок одна до багатьох, тобто 1 - gt; N
product - gt; pc_info raquo ;;
product - gt; zakaz raquo ;;
Таблиця pc_info має зв язок одна до одного, тобто 1 - gt; 1
pc_info - gt; zakaz raquo ;;
Таблиця users такоже має зв язок одна до одного, тобто 1 - gt; 1
users - gt; zakaz raquo ;;
. 2 Проектування логічної моделі
Логічне проектування віконується для певної моделі даних. Для реляційної моделі даних логічне проектування Полягає у створенні реляційної схеми, візначенні числа и структура таблиці, тіпів полів в таблицях, формуванні Запитів до БД, візначенні тіпів звітніх документів, розробці алгоритмів ОБРОБКИ информации, створенні форм для вводу и редагування даних в БД и рішенні цілого ряду других завдань. Концептуальні моделі за Певнев правилами превращаются в логічні моделі даних. Коректність логічніх моделей перевіряється помощью правил нормалізації, Які дозволяють переконатіся в структурній узгодженості, логічній цілісності и мінімальній збітковості прійнятої моделі даних. Модель такоже перевіряється з метою Виявлення можливости виконан транзакцій, Які будут задаватіся Користувачами. Проектування представляет собою ціклічній процес.
Кож вводяться обмеження цілісності, Які можна візначіті як СПЕЦІАЛЬНІ засоби в базах даних, сажки призначення якіх - НЕ дати потрапіті в базу непріпустімім Даними (например, попередіті помилки Користувачів при введенні даних).
Вимоги цілісності на Рівні сутності
Головне Завдання тут - сделать так, щоб дані про одну Сутність НЕ попал в базу даних дві разї. Забезпечується ограниченной унікальності и Первін ключем. Кожна таблиця, яка є в базі даних проекту, містіть первинний ключ. Засоби забезпечення сутнісної цілісності в даного проекті: це - первінні ключі (primary key) i обмеження унікальності (unique), а такоже всі ключові атрибути не могут буті Нульовий (not null).
Вимоги атрібутівної цілісності
Засоби забезпечення атрібутівної цілісності відповідають за ті, щоб у відповідному полі бази даних були Допустимі значення. Например, прізвище, винна складатіся з літер, а номер телефону - з цифр.
У базах даних така цілісність забезпечується умів на значення, запретили порожніх значень, Трігер, а такоже ключами.
Вимога цілісності по ПОСИЛАННЯ
Забезпечується системою ЗОВНІШНІХ ключів (foreign key). Например, с помощью ціх ЗАСОБІВ можна гарантуваті, что у нас не буде запісів в табліці zakaz, занесених товарів, якіх немає в базі даних.
например, Проведемо детальний аналіз полів табліці zakaz :
- ID, 2 - status, 3 - cid, 4 - pid, 5 -lid, 6 - ...
