5.11. Побудова логічних та фізичних моделей засобами case- технології eRwin компанії Computer Associates
ERwin – CASE-засіб проектування баз даних від фірми Computer Associates. ERwin поєднує графічний інтерфейс Windows, інструменти для побудови ER-діаграм, редактори для створення логічного і фізичного опису моделі даних і прозору підтримку провідних реляційних СУБД.
ERwin не прив'язаний до технології певної фірми, що постачає СУБД або засоби розробки. Він підтримує різні сервери баз даних і настільні СУБД, а також може звертатися до бази даних через інтерфейс ODBC. Так, в ERwin вбудована підтримка 23 СУБД, серед яких: Oracle; Microsoft SQL Server тощо. Зауважимо, що мова йде тільки про реляційні СУБД.
ERwin можна використовувати спільно з деякими популярними засобами розробки клієнтських частин додатків: PowerBuilder, Visual Basic, Delphi. Крім того, ERwin підтримує роботу в середовищі групової розробки Model Mart, яке є продуктом тієї ж Computer Associates.
Процес моделювання в ERwin ґрунтується на методології проектування реляційних баз даних IDEF1X. Дана методологія була розроблена для ВПС США і тепер широко використовується в урядових установах і приватних компаніях, як в самих США, так і далеко за їх кордонами. Вона визначає стандарти термінології і графічного зображення типових елементів на ER-діаграмах.
Відзначимо, що деякі позначення можуть трохи розходитися з традиційними, прийнятими в ER-моделі, хоча в ERwin версії 4.0 існує можливість вибору традиційної нотації. (При викладі матеріалу використана нотація IDEF1X). Крім того, існує низка відмінностей, пов'язаних з тим, що дана методологія орієнтована на розробку реляційних БД. Але це не вносить помітних коректив в сам підхід до розробки структури БД, а жорстка стандартизація дозволяє уникнути такого недоліку ER-моделей, як можливість різного трактування.
ERwin має два рівня подання моделі – логічний і фізичний.
Логічний рівень – це абстрактний погляд на дані, на ньому дані подаються так, як виглядають в реальному світі, і можуть називатися так, як вони називаються в реальному світі, наприклад ”Постійний клієнт”, ”Відділ” або ”Прізвище співробітника”. Об'єкти моделі, що подаються на логічному рівні, називаються сутностями і атрибутами. Логічна модель даних може бути побудована на основі іншої логічної моделі, наприклад на основі моделі процесів (BPwin).
Логічна модель даних є універсальною і жодним чином не пов'язана з конкретною реалізацією СУБД.
Фізична модель даних, навпаки, залежить від конкретної СУБД, фактично будучи відображенням системного каталогу. У фізичній моделі міститься інформація про усі об'єкти БД. Оскільки стандартів на об'єкти БД не існує (наприклад, немає стандарту на типи даних), фізична модель залежить від конкретної реалізації СУБД. Отже, одній і тій же логічної моделі можуть відповідати декілька різних фізичних моделей. Якщо в логічній моделі не має значення, який саме тип даних має атрибут, то у фізичній моделі важливо описати усю інформацію про конкретні фізичні об'єкти – таблиці, колонки, індекси, процедури тощо.
Поділ моделі даних на логічні і фізичні дозволяє розв'язати декілька важливих задач.
Документування моделі. Багато СУБД мають обмеження на іменування об'єктів (наприклад, обмеження на довжину імені таблиці або заборона використання спеціальних символів – пробілу, тире тощо). Найчастіше розробники ІС мають справу з нелокалізованими версіями СУБД. Це означає, що об'єкти БД можуть називатися короткими словами, тільки латинськими символами і без використання спеціальних символів (тобто не можна назвати таблицю реченням або тільки одним словом). Крім того, проектувальники БД нерідко зловживають ”технічними” найменуваннями, в результаті таблиця і колонки отримують найменування типу RTD_324 або CUST_A12 тощо. Отриману в результаті структуру можуть зрозуміти тільки фахівці (а найчастіше усього тільки автори моделі), її неможливо обговорювати з експертами предметної області. Поділ моделі на логічну і фізичну дозволяє вирішити цю проблему. На фізичному рівні об'єкти БД можуть називатися так, як цього вимагають обмеження СУБД. На логічному рівні можна цим об'єктам дати синоніми – імена більш зрозумілі непрофесіоналам, у тому числі на кирилиці і з використанням спеціальних символів. Наприклад, таблиці CUST_A12 може відповідати сутність – ”Постійний клієнт”. Така відповідність дозволяє краще задокументувати модель і дає можливість обговорювати структуру даних з експертами предметної області.
Масштабування. Створення моделі даних, зазвичай, починається зі створення логічної моделі. Після опису логічної моделі, проектувальник може вибрати необхідну СУБД і ERwin автоматично створить відповідну фізичну модель. На підставі фізичної моделі ERwin може згенерувати системний каталог СУБД або відповідний SQL-скрипт. Цей процес називається прямим проектуванням (Forward Engineering). Тим самим досягається масштабованість – створивши одну логічну модель даних, можна згенерувати фізичні моделі під будь-яку підтримувану ERwin СУБД. З іншого боку, ERwin здатний за змістом системного каталогу або SQL-скрипту відтворити фізичну і логічну модель даних (Reverse Engineering). На підставі отриманої логічної моделі даних можна згенерувати фізичну модель для іншої СУБД і потім згенерувати її системний каталог. Отже, ERwin дозволяє вирішити задачу з переносу структури даних з одного сервера на інший. Наприклад, можна перенести структуру даних з Oracle на Informix (або навпаки) або перенести структуру dbf-файлів в реляційну СУБД, тим самим, полегшивши розв'язок з переходу від файл-серверної до клієнт-серверної ІС.
Зауважимо, однак, що формальний перенос структури ”плоских” таблиць на реляційну СУБД зазвичай неефективний. Для того щоб отримати вигоди від переходу на клієнт-серверну технологію, структуру даних треба модифікувати.
Для перемикання між логічною і фізичною моделлю даних слугує список вибору у лівій частині панелі інструментів Erwin (рис. 5.7).
Рис. 5.7. Перемикання між логічною і фізичною моделями
При перемиканні, якщо фізичної моделі ще не існує, вона буде створена автоматично.
Для створення логічних моделей даних в ERwin можна використовувати дві нотації: IDEF1X і IE (Information Engineering). Методологія IDEF1X була розроблена для армії США і широко використовується в державних установах США, фінансових і промислових корпораціях. Методологія IE використовується переважно в промисловості.
Перемикання між нотаціями можна здійснити шляхом вибору команд Model → Model Properties. Після того як відкриється діалогове вікно Model Properties (рис. 5.8) треба розкрити вкладку Notation й перемкнути радіокнопку у фреймі Logical Notation в потрібне положення.
Рис. 5.8. Діалогове вікно Model Properties
На рис.5.9. представлений вид фрагмента логічної моделі даних для роботи з заявками клієнтів в двох нотаціях: IDEF1X і IE. Зовні дві зазначені нотації відрізняються тільки позначеннями відповідних зв'язків між сутностями моделі. Тут розглядаються три сутності: Паспортні дані клієнтів, Клієнти і Країни. Між зазначеними сутностями Паспортні дані клієнтів – Клієнти і Країни – Клієнти встановлений зв'язок, що їх ідентифікує.
Рис. 5.9. Дві нотації IDEF1X і IE, що використовуються для побудови логічної моделі даних в ERwin