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

Роль проектування даних у життєвому циклі інформаційних систем

Життєвий цикл інформаційної системи у випадку починається на момент прийняття рішення про її створення і закінчується на момент виведення її з експлуатації. Основними його етапами (якщо опустити деталі) зазвичай є:

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

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

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

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

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

Нижче ми розглянемо процес проектування даних за допомогою таких інструментів.

Складові процесу проектування даних

Процес проектування даних можна умовно поділити на два етапи: логічне моделювання та фізичне проектування. Результатом першого з них є так звана логічна (або концептуальна) модель даних, що зазвичай виражається діаграмою «сутність-зв'язок» або ER (Entity-Relationship) діаграмою, яка представлена ​​в одній із стандартних нотацій, прийнятих для відображення подібних діаграм. Результатом другого етапу є готова база даних чи DDL-скрипт на її створення.

Логічне моделювання

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

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

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

Зв'язок з логічної точки зору є співвідношенням між сутностями, яке нерідко може бути виражене звичайними фразами, наприклад: «Клієнт розміщує замовлення» («A customer places an order» - цією фразою цілком можна описати зв'язок, зображений на рис. 1), де іменниками є назви пов'язаних між собою сутностей.

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

Зазначимо, що на етапі логічного проектування можна описати поведінку СУБД при порушенні правил цілісності, що визначаються даним зв'язком (наприклад, при видаленні відомостей про замовника, який розмістив хоча б одне замовлення, для зв'язку, зображеного на рис. 1).

case-засоби

Мал. 1. Приклад зв'язку між сутностями логічної моделі

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

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

Фізичне проектування даних

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

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

Зноска: DDL (Data Definition Language) - мова визначення даних, підмножина мови SQL

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

Приклад діаграми, що відображає фізичну модель SQL Server 7.0, відповідну наведеної вище логічної моделі, представлений на рис. 2

програмування

Мал. 2. Приклад найпростішої фізичної моделі даних

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

Зазвичай, сучасні засоби проектування даних підтримують кілька типів СУБД (наприклад, ERwin фірми Computer Associates підтримує понад 20 різних СУБД). Рівень підтримки тієї чи іншої платформи у різних засобах проектування даних може бути різним. Наприклад, конкретний засіб може підтримувати або не підтримувати для даної СУБД такі особливості, як створення процедур, що зберігаються, генерація об'єктів фізичної пам'яті (табличних просторів, сегментів відкату та ін), завдання розташування об'єктів бази даних у фізичних об'єктах і т.д. Тому, вибираючи засіб проектування даних для вирішення конкретного завдання, варто поцікавитися, якими є його можливості з точки зору підтримки особливостей тієї чи іншої платформи - при вдалому розкладі можна заощадити чимало часу на «ручне» доведення бази даних (або DDL-скрипта для її генерації) ) до необхідного стану. При цьому, природно, чим більше можливостей і платформ підтримує конкретний засіб проектування даних, тим дорожче воно коштує (слід зазначити, що CASE-кошти взагалі ставляться до не найдешевших програмнихпродуктам - ціни на них становлять зазвичай від однієї до кількох десятків тисяч доларів).

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

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

Крім того, переважна більшість засобів проектування даних дозволяють відновлювати фізичну модель даних їх системного каталогу і представляти її у вигляді ER-діаграми (цей процес називається зворотним проектуванням - reverse engineering), а також синхронізувати системний каталог і фізичну модель. При створенні інформаційної системи, яка повинна використовувати успадковані від попередніх систем дані, така особливість дуже корисна - у цьому випадку логічне проектування можна почати з модифікації вже наявної моделі (цей процес отримав назву round-trip engineering).

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

Найбільш популярні засоби проектування даних

Отже, коротко розглянемо особливості найпопулярніших CASE-засобів, що застосовуються для проектування даних. Їх список наведено у таблиці.

Найпопулярніші засоби проектування даних