4.4 Об’єктно-орієнтована модель даних

Об'єктно-орієнтована модель є подальшим розвитком технології баз даних. Вся сукупність даних, що буде зберігатися й оброблятися в базі даних, подана не у вигляді набору окремих картографічних шарів і таблиць, а у вигляді об'єктів певного класу. Об'єктно-орієнтована модель поряд з геометричною й атрибутивною інформацією зберігає програмний код, що визначає поведінку об'єктів того чи іншого класу при введенні і редагуванні, аналізі або поданні даних. Класи об'єктів являють собою ієрархічну структуру – під ними розуміють загальний батьківський клас (наприклад, робочий простір), на підставі властивостей якого визначаються й описуються похідні класи. У свою чергу, на базі похідних класів другого рівня описуються класи третього, четвертого та інших нижче розміщених рівнів.

Основною перевагою об'єктно-орієнтованої моделі даних в порівнянні з реляційної є можливість відображення інформації про складні взаємозв'язки об'єктів. Об'єктно-орієнтована модель даних дозволяє ідентифікувати окремий запис бази даних і визначати функції їх обробки.

Об’єктно-орієнтована модель даних зазвичай застосовується в тих випадках, коли потрібна високошвидкісна обробка даних з складною структурою.

Об’єктно-орієнтовану модель даних не має сенсу застосовувати, оскільки структура даних не є складною та непотрібно використовувати такі основні принципи, як інкапсуляція, поліморфізм та наслідування.

Проаналізувавши недоліки та переваги усіх моделей даних, прийнято рішення використовувати реляційну модель, оскільки вона швидка в оперуванні з даними та відносно проста в маніпуляції.

5 Проектування нормалізованих відношень

Важливою частиною проектування бази даних являється її нормалізація, тобто зведення бази даних до нормальних форм.

Нормалізація бази даних – покроковий процес розбиття одного відношення відповідно до алгоритму нормалізації на декілька відношень на базі функціональних залежностей.

Нормальна форма – властивість відношення в реляційної моделі даних, що характеризує його з точки зору надмірності, яка потенційно може призвести до логічно помилкових результатів вибірки або зміни даних. Нормальна форма визначається як сукупність вимог, яким має задовольняти відношення.

За умовою необхідно привести універсальне відношення до 3 форми. Розглянемо універсальне відношення: R: { Потяги.[№ потягу], Потяги.[ початкова зупинка], Потяги.[ кінцева зупинка], Потяги.[вид потягу], Потяги.[прибуття], , Потяги.[відправлення], Вид потягу.[Назва], Зупинки.[Назва], Ціна білету.[№ потягу] , Ціна білету.[початкова зупинка] , Ціна білету.[кінцева зупинка], Ціна білету.[ код білету], Ціна білету.[ціна], Ціна білету.[вид вагону], Ціна білету .[прибуття], Ціна білету.[відправлення], Вид вагона .[Назва], Закази.[№ заказу], Закази.[ код білету], Закази .[ПІБ клієнта], Закази.[ дата покупки], Закази.[ дата відправлення], Закази .[№ вагону], Закази .[№ місця ]};

Для того, щоб звести універсальне відношення до першої нормальної форми, необхідно перевірити, чи не повторюються атрибути, а також чи є вони атомарними, тобто кожен атрибут повинен мати єдине значення, а не множину значень. Проаналізувавши універсальне відношення бачимо, що атрибути не повторюються і є атомарними.

Друга нормальна форма вимагає, щоб відношення знаходилось у 1НФ, а також, щоб кожен неключовий атрибут функціонально повно залежав тільки від первинного ключа. Визначимо функціональні залежності, що присутні в універсальному відношенні.

Номер потягу → початкова зупинка, кінцева зупинка, вид потягу, прибуття, відправлення.

Вид потягу(Вид) ;

Вид вагону (Вид);

Зупинки(Назва);

Код білету → початкова зупинка, кінцева зупинка,ціна,вид вагону,ціна білету,№ потягу,.

Номер заказу → код білету, ПІБ клієнта, дата покупки,дата відправлення,номер вагону, номер місця. Отримані відношення (ключові атрибути позначені *) наведено нижче:

• R1: { № потягу *, ], Потяги.[ початкова зупинка], Потяги.[ кінцева зупинка], Потяги.[вид потягу], Потяги.[прибуття], , Потяги.[відправлення]};

• R2: { Вид потягу.[Назва] *};

• R3: { Зупинки.[Назва] * };

• R4: { Ціна білету.[№ потягу] , Ціна білету.[початкова зупинка] , Ціна білету.[кінцева зупинка], Ціна білету.[ код білету] * , Ціна білету.[ціна], Ціна білету.[вид вагону], Ціна білету .[прибуття], Ціна білету.[відправлення]};

• R5: Вид вагона .[Назва] * };

• R6: { Закази.[№ заказу] *, Закази.[ код білету], Закази .[ПІБ клієнта], Закази.[ дата покупки], Закази.[ дата відправлення], Закази .[№ вагону], Закази .[№ місця ]};

Отримані відношення відповідають вимогам другої нормальної форми.

Третя нормальна форма передбачає усунення транзитивних залежностей, тобто, якщо атрибут1 залежить від атрибута2, а атрибут2 залежить від атрибута3, то атрибут1 не повинен залежати від атрибута3. Проаналізувавши усі відношення бачимо, що усі не ключові поля залежать лише від ключового поля і транзитивної залежності немає.

Отже, база даних приведена до третьої нормальної форми.

Оскільки обрано реляційну модель даних, то після нормалізації отримаємо наступні таблиці:

1. Потяги (№ потягу *, початкова зупинка, кінцева зупинка,вид потягу, прибуття , відправлення);

2. Вид потягу (Назва*);

3. Зупинки (Назва);

4. Ціна білету (№ потягу,початкова зупинка, кінцева зупинка, код білету*, ціна, вид вагону, прибуття, відправлення);

5. Вид вагона (Назва *);

6. Закази (№ заказу*, код білету, ПІБ клієнта, дата покупки, дата відправлення, № вагону, № місця );