Головна | Про нас | Зворотній зв'язок
Тема. Концептуальна, логічна і фізична моделі даних. Забезпечення несуперечності і цілісності даних. Проектування логічної і фізичної БД.
КОНЦЕПТУАЛЬНА, ЛОГИЧЕСКАЯ І ФІЗИЧНА МОДЕЛІ
Процес створення інформаційної моделі починається з визначення концептуальних вимог майбутніх користувачів БД.
Концептуальна модель відображає предметну область у вигляді взаємопов'язаних об'єктів без вказівки способів їх фізичного зберігання. Концептуальна модель представляє інтегровані концептуальні вимоги всіх користувачів до бази даних даної предметної області.
При цьому зусилля розробника повинні бути спрямовані в основному на структуризацію даних, що належать майбутнім користувачам БД, і виявлення взаємозв'язків між ними. Можливо, що відображені в концептуальної моделі взаємозв'язку між об'єктами виявляться згодом нереалізованим засобами обраної СУБД. Це зажадає зміни концептуальної моделі. Версія концептуальної моделі, яка може бути реалізована конкретної СУБД, називається логічною моделлю.
Логічна модель відображає логічні зв'язки між атрибутами об'єктів незалежно від їх змісту і середовища зберігання і може бути реляційної, ієрархічної або мережевий. Таким чином, логічна модель відображає логічні зв'язки між інформаційними даними в даній концептуальній моделі.
Різним користувачам в інформаційній моделі відповідають різні підмножини її логічної моделі, які називаються зовнішніми моделями користувачів. Таким чином, зовнішня модель користувача являє собою відображення концептуальних вимог цього користувача в логічної моделі і відповідає тим уявленням, які користувач отримує про предметну область на основі логічної моделі. Отже, наскільки добре спроектована зовнішня модель, настільки повно і точно інформаційна модель відображає предметну область і настільки повно і точно працює автоматизована система управління цією предметною областю.
Логічна модель відображається у фізичну пам'ять, яка може бути побудована на електронних, магнітних, оптичних, біологічних чи інших принципах.
Внутрішня модель предметної області визначає розміщення даних, методи доступу і техніку індексування в даній логічної моделі і інакше називається фізичною моделлю.
Інформаційні дані будь-якого користувача в БД повинні бути незалежні від всіх інших користувачів, т. Е. Не повинні впливати на існуючі зовнішні моделі. Це перший рівень незалежності даних. З іншого боку, зовнішні моделі користувачів ніяк не пов'язані з типом фізичної пам'яті, в якій зберігатимуться дані, і з фізичними методами доступу до цих даних. Це положення відображає другий рівень незалежності даних.
Забезпечення несуперечності і цілісності даних в базі
Для користувачів АІС важливо, щоб база даних відображала предметну область однозначно і несуперечливо, т. Е. Щоб вона задовольняла умові цілісності.
Виділяють два основних типи обмежень за умовою цілісність-ності:
1. Кожен рядок таблиці повинна відрізнятися від інших її рядків значенням хоча б одного стовпчика.
Співробітники відділу можуть виявитися повними тезка-ми, що народилися в один і той же день. Щоб не порушити умови цілісності, додаємо в таблицю новий стовпець - «№ пропуску», перетворюючи її в відношення (див. Рис. 1.4). Таким чином, перше ог-зпечних забезпечується наявністю в таблиці - щодо пер-первинних ключа.
У реальних базах даних назви не роблять ключовими через їх довжини (уповільнення процесу пошуку), а також через те, що вони можуть змінюватися (складності з супроводом системи).
Методологія логічного моделювання даних
Тепер у нас є завершена логічна модель даних. Згадаймо, які кроки потрібно здійснити, щоб отримати її:
1. Виявити і змоделювати суті.
2. Виявити і змоделювати зв'язку між сутностями.
3. Виявити та змоделювати атрибути.
4. Вказати унікальний ідентифікатор для кожної сутності.
5. Провести нормалізацію.
На практиці процес рідко відбувається в такій послідовності. Як показує наш приклад, часто виникають бажання і необхідність перескакувати між сутностями, зв'язками, атрибутами і ідентифікаторами. Важливо не стільки строго слідувати послідовності кроків, скільки виявити і зафіксувати всі дані, необхідні для правильного моделювання системи.
Модель даних, яку ми створили в цьому розділі, дуже проста. Ми розповіли, як створити модель, відповідну по типу і складності тим баз даних, з якими ви, швидше за все, зіткнетеся, розробляючи бази даних для MySQL або mSQL. Ми не торкнулися цілої маси прийомів проектування і понять, які не мають великого значення при проектуванні маленьких баз даних і можуть бути знайдені в будь-якому підручнику, присвяченому проектування баз даних.