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

1. Введення. Проблема переходу в архітектуру клієнт-сервер.

У 80-х і початку 90-х років в нашій країні було створено безліч програмних продуктів, призначених для автоматизації діяльності підприємств та організацій. Як правило, такі програми були реалізовані в архітектурі файл-сервер і для їх створення застосовувалися досить популярні тоді засоби розробки додатків Clipper, FoxPro або Paradox. В сучасних умовах перед підприємствами постають завдання, які файл-серверні додатки вирішити не можуть або вирішують недостатньо ефективно, а саме:


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


  1. Проводиться зворотне проектування структури даних файл-серверного додатку. Зауважимо, що для зворотного і прямого проектування може бути використаний CA Erwin).
  2. Модель даних конвертується 1:1 в структуру реляційного сервера і проводиться пряме проектування системного каталогу реляційної СУБД.
  3. За допомогою будь-якого інструменту (купленої або створеної самостійно утиліти) дані переносяться з файлів Paradox або dbf в реляційну СУБД.
  4. Проводяться мінімальні зміни клієнтської частини (наприклад, листується модуль, відповідальний за доступ до даних).

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

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


  1. Зворотне проектування структури даних
  2. Побудова логічної моделі. Метою цього етапу є виключення надмірності при зберіганні даних і ліквідація аномалій при операціях вставки, видалення та редагування.



  1. Побудова фізичної моделі на основі створеної логічної моделі. Основною метою створення фізичної моделі є підвищення продуктивності інформаційної системи.



  1. Забезпечення інформаційної безпеки засобами СУБД, в тому числі за рахунок надання і позбавлення привілеїв, створення тимчасових таблиць, процедур і тригерів
  2. Створення сховищ даних. Метою цього етапу є забезпечення високої продуктивності при аналізі інформації.
  3. Пряме проектування системного каталогу реляційної СУБД.
  4. Перенесення даних з файлів Paradox або dbf в реляційну СУБД.
  5. Зміни клієнтської частини.

Нижче буде детально розглянута реалізація етапів 1-7 за допомогою CASE-засобів фірми Computer Associated.

2. Зворотне проектування структури даних з файлів Paradox або dbf.

Створення моделі даних існуючих файлів Paradox або dbf (зворотне проектування) може бути здійснено за допомогою автоматично Erwin – CASE-засобу нижнього рівня фірми Computer Associated. Erwin підтримує роботу більш ніж з 20-ю СУБД різних виробників, у тому числі з файлами Paradox або dbf.

Для виконання зворотного проектування в головному меню Erwin слід вибрати пункт Tasks / Reverse Engineer …



Рис. 1 Діалог ERwin Template Selection.


При цьому виникає діалог ERwin Template Selection (мал. 1), в якому потрібно вибрати шаблон діаграми, потім діалог вибору СУБД, в якому необхідно вибрати тип бази даних (рис 2):

Access;
Clipper;

DBase III;
DBase IV;
FoxPro;
Paradox;

Рис. 2. Діалог Reverse Engineer – Select Target Server /

і, нарешті, діалог завдання опцій зворотного проектування Reverse Engineer – Set Options (рис. 3).



Рис. 3. Діалог Reverse Engineer – Set Options.


У діалозі Reverse Engineer – Set Options можна поставити такі опції:

Група Reverse Engineer From дозволяє задати джерело зворотного проектування – базу даних або SQL (DDL)-скрипт. За допомогою кнопки Browse можна вибрати текстовий файл, що містить SQL-скрипт.

Група Items to Reverse Engineer дозволяє задати об’єкти БД, на основі яких буде створена модель. За допомогою списку вибору Option Set, а також кнопок New, Update і Delete можна створювати і редагувати іменовані конфігурації об’єктів БД, які можуть бути використані багаторазово при інших сеансах зворотного проектування.

Група Reverse Engineer (Доступна тільки при зворотному проектуванні з БД) дозволяє включити в модель системні об’єкти (вікно вибору System Objects) і встановити фільтр на видобувні таблиці за їх власнику.

Установка опції Primary Keys в групі Infer означає, що ERwin буде генерувати первинні ключі на основі аналізу індексів. Якщо включена опція Relations, ERwin буде встановлювати зв’язки на основі імен колонок первинного ключа або індексів. Ці опції мають сенс, тільки якщо зв’язку не прописані явно.

Група Case Conversion дозволяє задати опції конвертації регістра при створенні логічних і фізичних імен моделі.

Після установки необхідних опцій можна клацнути по кнопці Next, після чого з’являється діалог зв’язку з БД, встановлюється сеанс зв’язку з сервером (для настільних БД повинен бути встановлений і налаштований ODBC – Драйвер і починається процес зворотного проектування, під час якого показується статус процесу в діалозі Reverse Engineer-Status. В результаті процесу створюється нова модель даних.
 

3. Побудова логічної моделі даних.

Основні компоненти діаграми Erwin – це сутності, атрибути та зв’язки. Кожна сутність є безліччю подібних індивідуальних об’єктів, званих екземплярами. Кожен екземпляр індивідуальний і повинен відрізнятися від всіх інших примірників. Атрибут виражає певну властивість об’єкта. З точки зору БД (фізична модель) сутності відповідає таблиця, екземпляру сутності – рядок в таблиці, а атрибуту – колонка таблиці.

Побудова моделі даних передбачає визначення сутностей і атрибутів, тобто необхідно визначити, яка інформація буде зберігатися в конкретній сутності чи атрибуті. Erwin має набір інструментів для створення логічної моделі-палітра і панель інструментів, діалоги редагування зв’язків, сутностей і атрибутів, інструмент створення незалежних атрибутів, різні рівні представлення моделі, інструменти роботи з великими моделями. Підтримуються нотації IDEF1X і IE.

Розрізняють три рівні логічної моделі, що відрізняються за глибиною подання інформації про дані:


Діаграма сутність-зв’язок являє собою модель даних верхнього рівня. Вона включає сутності та взаємозв’язку, що відображають основні бізнес-правила предметної області. Така діаграма не занадто деталізована, в неї включаються основні сутності та зв’язки між ними, які задовольняють основним вимогам, що пред’являються до інформаційної системи. Діаграма сутність-зв’язок може включати зв’язки багато-до-багатьох і не включати опис ключів. Як правило, ERD використовується для презентацій та обговорення структури даних з експертами предметної області. Для створення ERD на основі отриманої в результаті зворотного проектування моделі даних файлів Paradox або dbf слід описати основні первинні ключі та встановити зв’язки між сутностями (рис. 4).



Рис. 4. Фрагмент діаграми сутність-зв’язок.


Модель даних, заснована на ключах – більш детальне представлення даних. Вона включає опис всіх сутностей і первинних ключів і призначена для представлення структури даних і ключів, які відповідають предметної області. Erwin підтримує проектування наступних типів ключів:

Первинний ключ. Атрибути первинного ключа показуються у верхній частині списку атрибутів сутності.

Зовнішній ключ. Створюється автоматично при створенні зв’язку і позначаються символами (FK).

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

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

Атрибути, що беруть участь в неунікальний індексах, називаються Inversion Entries (інверсійні входи). Inversion Entry – це атрибут або група атрибутів, які не визначають примірник сутності унікальним чином, але часто використовуються для звернення до екземплярів сутності. ER win генерує неунікальний індекс для кожного Inversion Entry. Для редагування альтернативних ключів і інверсійних входів використовується закладка Key Group діалогу Attribute Editor (мал. 5).



Рис.5. Закладка Key Group діалогу Attribute Editor.


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

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

Перша нормальна форма (1NF). Сутність знаходиться в першій нормальній формі тоді й тільки тоді, коли всі атрибути містять атомарні значення. Серед атрибутів не повинно зустрічатися повторюваних груп, то є кілька значень для кожного екземпляра.

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

Для приведення суті до другої нормальної форми слід


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

Для приведення суті до другої нормальної форми слід


ERwin не містить повний алгоритм нормалізації і не може проводити нормалізацію автоматично, однак його можливості полегшують створення нормалізованої моделі даних. Заборона на присвоєння неунікальний імен атрибутів в рамках моделі (при відповідній установці опції Unique Name) полегшує дотримання правила “один факт – в одному місці”. Імена ролей атрибутів зовнішніх ключів та уніфікація атрибутів також полегшує побудова нормалізованої моделі.

Після побудови повної атрибутивної моделі необхідно перевірити якість отриманої моделі. До недавнього часу ця задача вирішувалася вручну і вимагала значних ресурсів. У жовтні 2000 року компанія Computer Associates випустила новий програмний продукт серії ER win – ER win Examiner. Цей заснований на базі знань інструмент дозволяє аналізувати структуру баз даних з метою виявлення недоліків і помилок проектування. ER win Examiner доповнює функціональність Erwin ERX, автоматизуючи трудомістку задачу пошуку та виправлення помилок, і одночасно підвищуючи кваліфікацію модельників даних завдяки вбудованої системи навчання. Принципова схема роботи ER win Examiner показана на рис.6.

Рис.6. Принципова схема роботи ERwin Examiner.

ER win Examiner підтримує роботу з наступними СУБД:


Помилки, зумовлені і виправляється за допомогою ER win Examiner, об’єднані в чотири категорії. У першу категорію (Columns) входять помилки проектування колонок. Нижче наведено фрагмент списку помилок цієї категорії:


Друга категорія об’єднує помилки проектування індексів і обмежень (Indexes and Constraints). У цю групу входять наступні помилки:


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

У четверту категорію входять помилки зв’язків (Relationships):



Результатом діагностики помилок може стати звіт генерація SQL-скрипта, коригуючого помилки моделювання.

Ключовий можливістю ER win Examiner є можливість навчання модельників даних. При виклику опису помилки (кнопка “i” зліва від імені помилки в закладці Diagnostics) з’являється діалог з описом помилки, що містить кнопку Teach Me. Клацніть по цій кнопці викликає довідку з даної проблеми, включаючи приклади та опис шляхів вирішення проблеми. Отже, модельник даних навчаються в першу чергу тим темам, які вони погано знають.

Крім виявлення помилок, ER win Examiner дозволяє також порівнювати моделі даних і зливати моделі. Для роботи з великими моделями передбачена зручна навігація по моделі і робота з подмодели, причому діагностика може бути проведена в рамках окремої подмодели.
 

4. Побудова фізичної моделі даних.

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

Основними об’єктами фізичної моделі є таблиці і колонки. ERwin автоматично створює імена таблиць і колонок на основі імен відповідних сутностей і атрибутів, враховуючи максимальну довжину імені та інші синтаксичні обмеження, що накладаються СУБД. При генерації імені таблиці або колонки за умовчанням всі прогалини автоматично перетворюються на символи підкреслення, а довжина імені обрізається до максимальної довжини, допустимої для вибраної СУБД. Для модифікації таблиць і колонок в Erwin використовуються редактори Table Editor і Column Editor.

Денормализация. В результаті нормалізації всі взаємозв’язки даних стають правильно визначені, виключаються аномалії при оперуванні з даними, модель даних стає легше підтримувати. Однак, часто нормалізація даних не веде до підвищення продуктивності інформаційної системи в цілому. В результаті нормалізації замість однієї таблиці може з’явиться декілька. Хоча загальна кількість рядків у цих таблицях може бути менше, ніж у вихідній (до нормалізації), тепер для отримання повної інформації про серверу БД необхідно звертатися одночасно до декількох таблиць (об’єднання таблиць, join). Час виконання запиту з об’єднанням може у багато разів перевершувати час виконання запиту до однієї таблиці, загальна продуктивність інформаційної системи в результаті нормалізації швидше за все впаде. З метою підвищення продуктивності при переході на фізичний рівень доводиться свідомо відходити від нормальних форм для того, щоб використовувати можливості конкретного сервера або інформаційної системи в цілому.

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

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


Налаштування індексів і створення об’єктів фізичної пам’яті. ERwin дозволяє створювати об’єкти фізичної пам’яті і налаштовувати індекси з урахуванням конкретної реалізації СУБД. Ця особливість Erwin забезпечує створення високопродуктивних додатків для будь-якої з обраних СУБД. На рис.7 показана закладка ORACLE діалогу Index Editor. Видно, що при проектуванні індексу можна врахувати специфічні властивості СУБД Oracle.


 

Рис.7. Закладка ORACLE діалогу Index Editor.

Перенесення функціональності на сервер. Створення процедур і тригерів.

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

Зокрема, цілісність даних може підтримуватися сервером автоматично на основі правил посилальної цілісності. Правила посилальної цілісності (referential integrity, RI) – логічні конструкції, які виражають бізнес-правила використання даних і являють собою правила вставки, заміни та видалення. При генерації схеми БД на основі зв’язків, що створюються в логічній моделі, Erwin генерує правила декларативною посилальної цілісності, які повинні бути приписані для кожного зв’язку, і тригери, що забезпечують посилальну цілісність.

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

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

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

Тригером називається процедура, яка виконується автоматично, як реакція на подію. Такою подією може бути вставка, зміна або видалення рядка в існуючій таблиці. Тригер повідомляє СУБД, які дії потрібно виконати при виконанні команд SQL INSERT, UPDATE або DELETE для забезпечення додаткової функціональності, виконуваної на сервері.

Тригер посилальної цілісності – Особливий вид тригера, який використовується для підтримки цілісності між двома таблицями, які пов’язані між собою. Якщо рядок в одній таблиці вставляється, змінюється або видаляється, то тригер посилальної цілісності (RI-тригер) повідомляє СУБД, що потрібно робити з тими рядками в інших таблицях, у яких значення зовнішнього ключа збігається зі значенням первинного ключа вставленої (зміненої, віддаленій) рядка. За замовчуванням ERwin генерує тригери, що дублюють декларативну посилальну цілісність. Наприклад, якщо видаляється клієнт з таблиці CUSTOMER, рис. 8, то в залежності від встановлених правил посилальної цілісності можуть бути згенеровані RI-тригери, які будуть впливати на відповідні видаляється клієнтові замовлення з таблиці ORDER. Команда DELETE може бути оброблена наступними способами:


Рис.8

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

Шаблони тригерів посилальної цілісності зв’язуються з сутностями в залежності від типу зв’язку і ролі сутності в цьому зв’язку. Тип зв’язку та роль суті визначають, яке правило посилальної цілісності буде за замовчуванням доповнено шаблоном тригера. Зв’язки можуть бути: ідентифікуючими, неідентіфіцірующей (nulls allowed), неідентіфіцірующей (no nulls), зв’язками підтипу.

Роль сутності в зв’язку може бути – батьківська (Parent) або дочірня (Child) сутність. Якщо сутність є батьківського в даному зв’язку, то ER win присвоює їй шаблон тригера для батьківської сутності. Якщо сутність є дочірньою в даному зв’язку, то ER win присвоює їй шаблон тригера для дочірньої сутності. Код тригера, який генерується шаблоном тригера для батьківського суті, вказує СУБД, що потрібно робити при вставці, зміні або видаленні рядка в батьківській таблиці зв’язку. Код тригера, який генерується шаблоном тригера для дочірньої суті, вказує СУБД, що потрібно робити при вставці, зміні або видаленні рядка в дочірній таблиці зв’язку.

Нижче наведено текст шаблона тригера, що відповідає правилу посилальної цілісності ON PARENT DELETE RESTRICT.

/* ERwin Builtin %Datetime */
/* %Parent %VerbPhrase %Child ON PARENT DELETE RESTRICT */
select count(*) into numrows
from %Child
where
/* %%JoinFKPK(%Child,:%%Old,” = “,” and”) */
%JoinFKPK(%Child,:%Old,” = “,” and”);
if (numrows > 0)
then
raise_application_error(
-20001,
“Cannot DELETE %Parent because %Child exists.”
);
end if;

При генерації схеми СУБД для Oracle 7.2 буде згенеровано тригер:

create trigger tD_CUSTOMER after DELETE on CUSTOMER for each row
— ERwin Builtin Tue Jan 26 21:55:13 1999
— DELETE trigger on CUSTOMER
declare numrows INTEGER;
begin
/* ERwin Builtin Tue Jan 26 21:55:13 1999 */
/ * CUSTOMER розміщує ORDER ON PARENT DELETE RESTRICT * /
select count(*) into numrows
from ORDER
where
/* %JoinFKPK(ORDER,:%Old,” = “,” and”) */
ORDER.CustomerID = :old.CustomerID;
if (numrows > 0)
then
raise_application_error(
-20001,
“Cannot DELETE CUSTOMER because ORDER exists.”
);
end if;

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

5. Забезпечення інформаційної безпеки засобами СУБД

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

Будь-який сучасний реляційний сервер дозволяє створювати користувачів і надавати або відбирати привілеї для кожного користувача. Команди надання та позбавлення привілеїв описані стандартом мови SQL (підмножина DCL, Data Control Language):

Команди DCL дозволяють задавати або позбавляти стандартних привілеїв для об’єктів:


Команда GRANT дозволяє надавати права користувачеві на об’єкт, наприклад

GRANT INSERT ON Salespeople TO Scott

надає привілей вставляти дані (INSERT) в таблицю Salespeople користувачеві Scott. Параметр PUBLIC дозволяє надавати права всім користувачам, зареєстрованим в системі, параметр ALL – Надавати права на всі об’єкти, наприклад

GRANT ALL PRIVILEGES ON Salespeople TO Scott

надає всі стандартні привілеї користувачеві Scott;

GRANT INSERT, SELECT ON Salespeople TO PUBLIC

надає привілеї INSERT, SELECT на таблицю Salespeople всім користувачам.

Для позбавлення привілеїв використовується команда REVOKE, яка також може використовуватися з параметрами PUBLIC і ALL, наприклад

REVOKE INSERT, SELECT ON Salespeople FROM Scott

позбавляє привілеїв INSERT, SELECT на таблицю Salespeople користувачеві Scott.

Особливо ефективним є застосування механізму надання та позбавлення привілеїв спільно з використанням уявлень (view).

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



Рис. 9. Створення подання.


Для редагування подання служить діалог View Editor (рис.10). Для його виклику слід натиснути правою кнопкою миші по наданню й обрати в меню пункт View Editor.

Рис.10. Діалог View Editor.

При генерації схеми бази даних Erwin генерує команду SQL для створення вистави на основі інформації, внесеної в закладках Select, From і Where. Текст команди можна переглянути або перевизначити в закладці SQL.

Подання може включати тільки частина колонок таблиці (або декількох таблиць). Адміністратор бази даних може створити таке уявлення, і командою GRANT дати привілеї на операції всім користувачам, при цьому позбавити користувачів прав на вихідні таблиці. Крім того, в закладці Where може бути включено умова фільтрації, яке дозволить включити в подання тільки частина рядків. У підсумку, використовуючи механізм уявлень, можна надати користувачам доступ до підмножини рядків і колонок вихідних таблиць, приховавши від них іншу інформацію.

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

Тригери виконуються автоматично і приховані для користувача. Це дає можливість контролю та аудиту критичної інформації.

Розглянемо простий приклад. Припустимо, бізнес-правила вимагають, щоб при будь-якій зміні імені клієнта (колонка CustomerName таблиці CUSTOMER , Рис.11) в таблиці SECURITY створювалася рядок, в якій би фіксувалося колишнє значення імені, нове значення, дата зміни та ім’я користувача, яка провела зміна.

Рис. 11. Таблиці CUSTOMER і SECURITY.

Нижче наведено код тригера (мовою вибраного сервера, у прикладі – Oracle 7.2), автоматично генерується Erwin за шаблоном, який підтримує ці бізнес-правила:

create trigger SecurWrite
BEFORE UPDATE OF
CustomerName
on CUSTOMER
REFERENCING OLD AS old1 NEW AS new1
for each row
/* ERwin Builtin Tue Jan 26 21:24:37 1999 */
/* default body for SecurWrite */
begin
Insert into Security (OldName,NewName, UserUpdate, UpdateDate)
values (:old1.CustomerName,:new1.CustomerName, User, Sysdate);
end;
/
 

6. Створення сховищ даних

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

Рішенням проблеми може бути розміщення всіх даних в єдиній спеціалізованій базі даних, званої сховищем даних (Data Warehouse).

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


Все це пред’являє до їх проектування та реалізації сховищ підвищені вимоги. ERwin є незамінним інструментом для проектування сховищ даних з кількох причин:


  1. Хоча реалізувати сховище даних можна на будь-якому сервері БД, існують спеціалізовані сервера, спеціально призначені для підтримки сховищ даних. Erwin підтримує генерацію схеми БД для двох таких серверів – Teradata і Red Brick.
  2. Як було зазначено вище, при проектуванні сховища необхідно створювати докладні специфікації для всіх, в тому числі самих різних типів джерел даних. Erwin підтримує на фізичному рівні пряме і зворотне проектування об’єктів більш ніж для 20 типу БД, тому є ідеальним CASE-засобом для роботи з гетерогенними інформаційними системами.
  3. Для ефективного проектування сховищ даних ERwin використовує розмірну (Dimensional) модель. Dimensional – методологія проектування спеціально призначена для розробки сховищ даних.

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

ERwin підтримує методологію моделювання сховищ завдяки використанню спеціальної нотації для фізичної моделі – Dimensional. Найбільш простий спосіб перейти до нотації Dimensional в ERwin – при створення нової моделі (меню File / New) в діалозі ERwin Teamplate Selection вибрати зі списку пропонованих шаблонів DIMENSION. В шаблоні DIMENSION зроблені всі необхідні для підтримки нотації розмірного моделювання настройки, які, втім, можна встановити вручну.

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

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

Схема зірка зазвичай містить одну велику таблицю, яка називається таблицею факту (fact table), поміщену в центр, і навколишні її менші таблиці, звані таблицями розмірності (dimensional table), з’єднаними c таблицею факту у вигляді зірки радіальними зв’язками. У цих зв’язках таблиці розмірності є батьківськими, таблиця факту – дочірньою. Схема зірка може мати також консольні таблиці (outrigger table), приєднані до таблиці розмірності. Консольні таблиці є батьківськими, таблиці розмірності – дочірніми.

В розмірної моделі, ERwin позначає іконкою роль таблиці в схемі зірка (рис.12)

Таблиця факту (fact table)

Таблиця розмірності (dimensional table),

Консольна таблиця (outrigger table).

Рис. 12. Позначення таблиць у схемі “зірка”.

Перш ніж створити базу даних зі схемою типу зірка, необхідно проаналізувати бізнес-правила предметної області з метою з’ясування центрального питання, відповідь на який найбільш важливий. Всі інші питання повинні бути об’єднані навколо цього основного питання і моделювання повинно починатися з цього основного питання. Дані, необхідні для відповіді на це питання, повинні бути поміщені в центральну таблицю моделі – таблицю факту. Наприклад, якщо необхідно створювати звіти про загальну суму доходу від продажів за період або за типом товару або по продавцям, слід розробляти модель так, щоб кожен запис в таблиці факту представляла загальну суму продажу, для кожного клієнта за певний період часу для кожного продавця. У прикладі (рис.13), таблиця факту містить сумарні дані про продажі (“SALE”), а таблиці розмірності містять дані про замовника і замовленнях (“CUSTOMER”), продуктах (“PRODUCT”), продавців (“SALESPEOPLE”) та періоди часу (“TIME”).



Рис.13. Схема зірка.


Таблиця факту є центральною таблицею в схемі зірка (рис. 13). Вона може складатися з мільйонів рядків і містити підсумовуючі або фактичні дані, які можуть допомогти відповісти на необхідні питання. Вона з’єднує дані, які зберігалися б у багатьох таблицях традиційних реляційних базах даних. Таблиця факту і таблиці розмірності пов’язані ідентифікуючими зв’язками, при цьому первинні ключі таблиці розмірності мігрують в таблицю факту в якості зовнішніх ключів. В розмірної моделі напрямки зв’язків явно не показуються – вони визначаються типом таблиць. Первинний ключ таблиці факту цілком складається з первинних ключів всіх таблиць розмірності. У прикладі (таблиця факту “SALE”) первинний ключ складається з чотирьох зовнішніх ключів: CustomerID, SalespeopleID, TimeID і ProductID.

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

У прикладі таблиця “SALE” – таблиця факту; “CUSTOMER”, “TIME”, “SALESPEOPLE” і “PRODUCT” – таблиці розмірності, які дозволяють швидко отримувати інформацію про те, хто і коли зробив покупку, який продавець і на яку суму продав, і які саме товари були продані.

При проектуванні сховища даних важливо визначити джерело даних (для кожної колонки), метод, яким вихідні дані витягуються, перетворюються, і фільтруються перш, ніж вони імпортуються в сховище даних. Сховище даних може об’єднувати інформацію з текстових файлів і багатьох баз даних, як реляційних (у тому числі інших БД на платформі Informix), так і нереляційних, в єдину систему підтримки прийняття рішень. Щоб підтримувати регулярні оновлення та перевірки якості даних, необхідно знати джерело для кожної колонки в сховище даних. Для документування інформації про джерела даних використовується редактор Data Warehouse Source Editor (Рис.14.).

Рис.14. Діалог Data Warehouse Source Editor.

Імена таблиць і колонок джерел даних можуть бути імпортовані як з баз даних (зворотне проектування), так і з інших моделей ERwin. Кожному джерела може бути задано ім’я та визначення.

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

7. Пряме проектування системного каталогу реляційної СУБД.

Після завершення роботи над фізичною моделлю можна згенерувати системний каталог СУБД. Цей процес називається прямим проектуванням (Forward Engineering). При генерації фізичної схеми ER win включає тригери посилальної цілісності, збережені процедури, індекси, обмеження та інші можливості, доступні при визначенні таблиць в обраній СУБД.


 


Рис. 15. Діалог Schema Generation.


Для генерації системного каталогу БД слід вибрати пункт меню Tasks / Forward Engineer / Schema Generation або натиснути кнопку на панелі інструментів. З’являється діалог Schema Generation (рис. 15). У діалозі Schema Generation слід вказати параметри генерації схеми і клацнути по кнопці Generate. З’являється діалог зв’язку з сервером (Клієнтська частина сервера повинна бути попередньо встановлена ​​на тій же машині, що і Erwin). Після встановлення сеансу зв’язку виконується SQl-скрипт, який створює об’єкти бази даних.

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


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


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

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

Ваш отзыв

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

*

*