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

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

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

Для даної предметної області об’єктно-орієнтована модель не підходить, адже усі дані тісно взаємозв’язані по суті являють собою один великий клас з безліччю полів. Якщо ж розбити дані на менші об’єкти, наприклад за сутностями, то ці об’єкти не будуть відповідати основним концепціям об’єктної орієнтації, адже вона передбачає клас як тип даних, а об’єкти як екземпляри класу, а це в даному випадку неможливе. Також в даній предметній області немає сенсу застосовувати такі основні принципи об’єктної орієнтації як інкапсуляцію, наслідування і поліморфізм. Тому дана модель не підходить для нашої теми [2].

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

5 Проектування нормалізованих відношень предметної області «оператор мобільного зв’язку»

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

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

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

За умовою необхідно привести універсальне відношення до 3 форми. Розглянемо універсальне відношення R = {Абонент.[ПІБ], Абонент.[місто], Абонент.[номер телефона], Абонент.[тариф], Абонент.[зона обслуговування], Тариф.[Назва тарифу], Тариф.[Вартість], Тариф.[Дата підключення], Зона обслуговування.[Назва Зони обслуговування], Зона Обслуговування.[Місто], Зона обслуговування.[ [Кількість абонентів]], Персонал.[ПІБ], Персонал.[Зона обслуговування яку обслуговує працівник], Персонал.[Кількість інвентаря], Персонал.[ Дата прийняття на робоче місце], Персонал.[ Спеціалізація], Партнери.[Назва підприємства], Партнери.[Контактний телефон], Партнери.[Aдресa], Партнери.[Контактне лице], Партнери.[Область співпраці], Інвентар.[ Працівник якому приписаний прилад], Інвентар.[дата купівлі], Інвентар.[Назва], Інвентар.[Функціональність]}.

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

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

Прізвище, Ім’я, По-батькові абонента → адреса , номер телефона, тариф, зона обслуговування;

Назва тарифу → вартість, дата підключення, додаткові послуги;

Зона обслуговування → кількість абонентів, місто;

Прізвище, Ім’я, По-батькові працівника →назва підприємства, адреса, спеціалізація, кількість одиниць інвентаря, дата прийняття на робоче місце;

Контактне лице → назва підприємства , обсласть співпраці контактний телефон.

Назва обладнання → функціональність, дата покупки ;

Більшість отриманих відношень мають неоднозначний ключ, тому в них введено атрибути ID. Отримані відношення (ключові атрибути позначені *) наведено нижче:

• R1: { Абонент[ID, [ПІБ], [Місто], [номер телефонна], [тариф], [Зона обслуговування]};

• R2: { Зона обслуговуванняID*, [Місто], [Кількість абонентів]};

• R3:{ ТарифID*, [назва тарифу], [вартість], [Дата підключення], };

• R4: { ІнвентарID*, [ID - ідентифікаційний код працівника якому приписаний прилад], [дата купівлі], [Назва], [Функціональність], };

• R5: { ПерсоналІD*, [ПІБ], [ІD ідентифікаційний код зони обслуговування яку обслуговує працівник], [Кількість інвентаря], [Дата прийняття на робоче місце], [Спеціалізація]} ;

• R6: { ПартнериІD*, [назва підприємства], [контактний телефон], [Aдресa], [контактне лице], [область співпраці] };

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

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

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

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

• Абонент (ID*, [ПІБ], [Місто], [Номер телефонна], [Тариф],) ;

• Зона обслуговування (ID*, [Місто], [Кількість абонентів]) ;

• Тариф (ID*, [назва тарифу], [вартість], [Дата підключення], ) ;

• Інвентар (ID*, [ID - працівника], [дата купівлі], [Назва], [Функціональність],) ;

• Персонал (ІD*, [ПІБ], [ІD зони обслуговування], [Кількість інвентаря], [Дата прийняття на робоче місце], [Спеціалізація]) ;

• Партнери (ІD*, [назва підприємства], [контактний телефон], [Aдресa], [контактне лице], [область співпраці] ).