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

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 на фізичному рівні містить кнопки внесення подань і встановлення зв'язків між таблицями та уявленнями. Для внесення подання потрібно клацнути по кнопці
 


Рис. 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>

*

*