Простота і складність проектування баз даних за допомогою ERwin, CASE-засоби (моделювання), Програмування, статті

Зміст



Введення

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

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

ERwin – це не просто засіб проектування, а й інструмент розробки, здатний автоматично створювати таблиці і генерувати тисячі рядків тексту збережених процедур і тригерів для всіх популярних СУБД. Революціоннаятехнологія Complete – Compare (Завершити-Порівняти) дозволяє організувати ітеративну розробку, підтримуючи постійну узгодженість моделі і бази даних. Завдяки інтеграції з популярними середовищами розробки програм, ERwin дозволяє прискорити створення додатків для обробки даних.

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

І це далеко не повний перелік всіх достоїнств програмного продукту.

Однак за уявною простотою, доступністю і “легкістю” розробки моделей і прототипів баз даних ховаються дуже серйозні “підводні камені”, які здатні з самого початку процесу створення інформаційної системи “відвести” проектувальника в сторону від бажаного результату. І справа тут, безумовно, не в самому програмному засобі, а в тому, наскільки добре розробник володіє теорією проектування реляційних баз даних. Перебуваючи в рамках ERwin, у недосвідченого розробника може скластися враження, що створювані моделі даних оптимальні за визначенням, тобто внаслідок того, що вони створюються на базі майже досконалого стандарту IDEF1X.

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


Типи зв’язків

У стандарті IDEF1X визначені типи зв’язків, показані в табл.1.

Таблиця 1. Типи зв’язків стандарту IDEF1X




















Ідентифікує зв’язок



Неідентіфіцірующей зв’язок



Рекурсивна зв’язок



Зв’язок типу “багато-до-багатьох”



Зв’язок супертіпа з підтипами

Проаналізуємо сутність кожної з наведених у табл.1 зв’язків.


Звідки з’являється ідентифікація

У IDEF1X визначені залежні і незалежні сутності. Зв’язки між такими сутностями, як показано в табл.1, можуть бути ідентифікуючими або неідентіфіцірующей. Дані типи зв’язків припускають посилання дочірньої (Залежної) сутності на асоційовану запис в батьківській (незалежною) сутності. Іншими словами дочірня сутність не може бути визначена без її зв’язку з батьківської сутністю. Проте цей висновок є скоріше наслідком, ніж причиною формування залежних і незалежних сутностей.

Розглянемо простий приклад. Нехай є сутність СТУДЕНТ, показана на рис.1.

Рис. 1. Сутність СТУДЕНТ

З класичної теорії реляційних баз даних згадаємо, що для забезпечення цілісності даних і виключення появи різного роду аномалій необхідно, щоб кожне відношення знаходилося, як мінімум в третій нормальній формі (3НФ). При цьому 3НФ передбачає нетранзитивно залежність неключових атрибутів від первинного ключа. У випадку з сутністю СТУДЕНТ такі залежності є (наприклад, НОМЕР Залікова книжка ® НОМЕР ГРУПИ ® НОМЕР ФАКУЛЬТЕТУ). Відомо, що для усунення таких залежностей необхідно виконати операцію проекції на атрибути, які служать причиною цих залежностей. Результатом проекції відносини на відповідні атрибути (згідно реляційної алгебри) є також ставлення, як показано на рис. 2.

 

А) Б)

Рис. 2. Результати проекції відносини СТУДЕНТ

Перевіривши утворилися сутності СТУДЕНТ і ГРУПА на нормальність можна переконатися, що сутність ГРУПА не знаходиться в 3НФ. Отже, необхідна наступна проекція, яка приведе до появи іншого незалежної суті, наприклад, СПЕЦІАЛЬНІСТЬ.



Таким чином, залежні та незалежні сутності при формуванні логічної структури бази даних з’являються зовсім не тому, що одна “не може жити” без іншого (як, до речі, це намагаються піднести в деяких оглядових статтях), а в результаті нормалізації відносин.

Отже, за простотою і легкістю реалізації в ERwin залежних і незалежних сутностей, стоять більш серйозні причини їх виникнення.


Багатогранність зв’язків

Особливої ​​уваги заслуговують також типи зв’язків “мноіе-ко-многим” і супертіпа з підтипами.

Стандарт EDEF1X допускає присутність в моделі обох типів зв’язків. Проте без їх дозволу фізична база даних буде далека від оптимальної. Тут слід зазначити, що ERwin надає можливість вибору способу вирішення цих зв’язків, особливо для зв’язків типу супертіп-ПІДТИПИ.

Стандартним дозволом зв’язку “багато-до-багатьох” є механізм, показаний на рис. 3.

 

Рис. 3. Дозвіл зв’язку “багато-до-багатьох”

З рис.3 видно, що якщо Е / 1 і Е / 2 відповідають умовам нормальності, то і сутність Е/2_Е/1 також нормальна.

Якщо в схемі бази даних присутні підтипи, то для вирішення таких зв’язків передбачено два способи:


як показано на рис. 4.

Рис. 4. Дозвіл зв’язку супертіп-ПІДТИПИ

Наскільки кожне із запропонованих дозволів оптимально можна судити тільки виходячи зі змісту сутностей Е / 1, Е / 2 і Е / 3. Однак при перетворенні логічної моделі у фізичну базу даних очевидні формальні переваги та недоліки кожного дозволу, які зведені в табл.2.

Таблиця 2. Характеристика типів дозволу зв’язку супертіп-ПІДТИПИ
















Всі підтипи в одну сутність

Для кожного підтипу окрема сутність

Переваги



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


  • більш зрозумілі правила підтипів;
  • додаток працює тільки з потрібними таблицями.

Недоліки



  • занадто загальне рішення, швидше за все потребує нормалізації;
  • потрібна додаткова логіка роботи з різними наборами стовпців у фізичній базі даних;
  • потенційно “вузьке” місце (у зв’язку з блокуваннями);
  • стовпці підтипів повинні бути необов’язковими.


  • занадто багато таблиць;
  • потенційна втрата продуктивності;
  • над супертіпов неможливі модифікації.

Таким чином, пропонованими способами дозволу зв’язку супертіп-ПІДТИПИ слід користуватися дуже обережно, внаслідок можливості отримання небажаних (аномальних) результатів.

Існує, однак, більш простий і надійний спосіб вирішення зв’язку супертіп-ПІДТИПИ, який також реалізований в ERwin (див. рис. 5).

 

Рис. 5. Ідентифікація підтипів

Показаний на рис. 5 спосіб вирішення зв’язку супертіп-ПІДТИПИ методом ідентифікації підтипів майже завжди дає необхідну нормальність сутностей і забезпечує цілісність даних.

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

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


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*