НОУ ІНТУІТ, Лекція, Візуальне моделювання баз даних

Схеми даних та модельно-орієнтований підхід

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

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

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

Хороший результат тут не досягається "за один присід" - сіли та спроектували хорошу структуру даних. В даному випадку застосовна базова ідея візуального моделювання: розробку ПЗ зручно проводити як процес створення моделей, що уточнюють один одного. Саме так відбувається перехід від предметної області до працюючого ПЗ.

Модель "сутність-зв'язок"

Отже, під час створення структур баз даних прийнято використовувати моделювання , а чи не відразу писати код, наприклад, на SQL/DDL . Загальноприйнятим способом моделювання структури даних є модель "сутність-зв'язок", запропонована Петером Ченом ще 1976 [8.1].

Мова SQL/DDL є промисловим стандартом завдання схеми реляційних баз даних і підтримується практично всіма промисловими СУБД. Ця мова дозволяє описувати таблиці баз даних, задавати їх поля, індекси, ключі тощодалі. Подальшу інформацію про SQL можна отримати у [8.2], [8.5].

СУБД (система управління базами даних) – це програмне забезпечення, призначене для вирішення завдань розробки, зберігання та програмного доступу до великих масивів даних. Найвідоміші СУБД - це Oracle, Microsoft SQL Server, MySQL. Подальшу інформацію про створення баз даних та різних СУБД можна отримати в [8.2], [8.3], [8.4].

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

Зв'язок( relationship ) - це деяке відношення між двома і більше сутностями, що відображає те, як вони беруть участь у спільній діяльності, взаємодіють один з одним, спільно використовуються деякою іншою сутністю і т.д.

На рис. 8.1,апоказані дві сутності - "Студент" та "Кафедра", - які пов'язані ставленням "Належить". Ще точніше сказати, що студент належить кафедрі. Це приклад спрямованих відносин між двома сутностями.

На рис. 8.1 б показаний приклад рівноправного відношення між двома сутностями: "Викладач" і "Студент" пов'язані ставленням "Іспит". На рис. 8.1 показаний приклад того, як в одному відношенні можуть брати участь більш ніж дві сутності.

Рідко буває так, що сутність означає конкретний елемент предметної галузі – студента Васю, викладача Петрова А.В. Як правило, сутність позначає всіх можливих студентів, всіх можливих викладачів і т. д. Розрізнятимемо сутність-значення і сутність-тип, і аналогічно - зв'язки.

У сутностей-типів з'являються атрибути, які аналогічні атрибутам класів в UMLсамі типи сутностей багато в чому схожі на класи. На рис. 8.1, г показано, які атрибути мають сутності 1 Нижче я називатиму сутності-типи просто сутностями - це звучить коротше і милозвучніше. Тим більше, що сутності-значення в рамках цього курсу більше не знадобляться. "Студент" та "Кафедра". Наприклад, ПІБ - це набір із трьох рядків українською мовою, які представляють прізвище, ім'я та по батькові студента. Номер курсу – це атрибут, який має діапазон значень від одиниці до шести. Атрибут "спеціальність" має значення із певного заданого списку спеціальностей тощо.

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

Про рівні абстракції під час моделювання даних

У процесі проектування схему даних зручно представляти з допомогою наступних моделей (див. рис. 8.2):

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

Далі слідує реалізація схеми даних у вигляді: