lign="justify"> Квиток. Властивості: Код, Ціна.
Фільм. Властивості: Код, Назва, Режисер, Країна, Рік, Хронометраж.
Сеанс. Властивості: Код, Дата, Час.
Зал. Властивості: Назва, Місткість.
Бронь. Властивості: Код, ПІБ клієнта.
2.2 Логічне проектування
Логічне проектування бази даних - конструювання інформаційної моделі підприємства на основі існуючих конкретних моделей даних, але без урахування використовуваної СУБД та інших фізичних умов реалізації [5, 58].
Логічне проектування бази даних полягає в перетворенні концептуальної моделі даних в логічну модель даних підприємства з урахуванням обраного типу СУБД (наприклад, передбачається використання деякої реляційної СУБД). Логічна модель даних є джерелом інформації для етапу фізичного проектування. Вона надає розробникові фізичної моделі даних засоби проведення всебічного аналізу різних аспектів роботи з даними, що має винятково важливе значення для вибору дійсно ефективного проектного рішення [5, 60].
Етапи логічного проектування є наступними:
Створення і перевірка локальної логічної моделі даних на основі уявлення про предметної області кожного з типів користувачів.
Усунення особливостей локальної логічної моделі, несумісних з реляційною моделлю.
Визначення набору відносин, виходячи зі структури локальної логічної моделі даних.
Перевірка відносин за допомогою правил нормалізації.
Перевірка відповідності відносин вимогам користувальницьких транзакцій.
Визначення вимог підтримки цілісності даних.
Обговорення розроблених локальних логічних моделей даних з кінцевими користувачами.
Створення і перевірка глобальної логічної моделі даних.
Злиття локальних логічних моделей даних в єдину глобальну модель даних.
Перевірка глобальної логічної моделі даних.
Перевірка можливостей розширення моделі в майбутньому.
Обговорення глобальної логічної моделі даних з користувачами [5; 17].
Об'єкти та їх властивості перетворюються в атрибути та сутності. Вибираються ключові атрибути. Визначаються зв'язку.
Зв'язки бувають чотирьох видів:
) «один-до-одного» - будь-якому екземпляру однієї сутності відповідає тільки один екземпляр іншої сутності, і навпаки;
) «один-до-багатьох» - будь-якому екземпляру перший суті відповідає 0, 1 або кілька примірників другий сутності, але будь-якому екземпляру другу сутність відповідає тільки один екземпляр першої сутності;
) «багато-до-одного» - будь-якому екземпляру перший суті відповідає тільки один примірник другої суті, але будь-якому екземпляру другу сутність відповідає 0, 1 або кілька примірників першого сутності;
) «багато-до-багатьох» - будь-якому екземпляру перший суті відповідає 0, 1 або кілька примірників другий сутності, і будь-якому екземпляру другу сутність відповідає 0, 1 або кілька примірників першого сутності.
Для розроблюваної бази даних кіноцентру «Піраміда» зв'язку наступні (у дужках вказана причина, чому зв'язок є саме такою):
Кінотеатр. Ключовий атрибут - Код. Зв'язок: Кінотеатр-Персонал. Тип зв'язку: 1: M. (В одному кінотеатрі працює безліч персоналу)
Персонал. Ключовий атрибут - Код. Зв'язок: Персонал - Квиток. Тип зв'язку: 1: M. (Один касир продає безліч квитків)
Квиток. Ключовий атрибут - Код.
Фільм. Ключовий атрибут - Код. Зв'язок: Квиток - Фільм. Тип зв'язку: 1: M. (На один фільм продається безліч квитків)
Сеанс. Ключовий атрибут - Код. Зв'язок: Квиток - Сеанс. Тип зв'язку: 1: M. (На один сеанс продається безліч квитків)
Зал. Ключовий атрибут - Назва. Зв'язок: Квиток - Зал. Тип зв'язку: 1: M. (На один зал доводиться безліч квитків)
Бронь. Ключовий атрибут - Код. Зв'язок: Квиток - Бронь. Тип зв'язку: 1: M. (Один клієнт може забронювати безліч квитків)
Для візуального представлення зв'язків в таблиці часто використовують так звану ER-діаграму (додаток Б).
2.3 Фізичне проектування
Фізичне проектування бази даних - опис конкретної реалізації бази даних, що розміщується в зовнішній пам'яті. Фізичний проект описує базові відносини, визначає організацію файлів і складу індексів, що застосовуються для забезпечення ефекти...
