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

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


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


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


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



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


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


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


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


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


Багато сучасних СУБД містять візуальні засоби (нерідко входять до складу утиліт адміністрування), що дозволяють створити нову схему бази даних або переглянути вже наявну. Існують також і утиліти (Поставляються окремо від СУБД), що дозволяють розробляти або редагувати метадані. Проте останнім часом все більш популярними стають CASE-засоби (Computer-Aided System Engineering). Існує кілька типів CASE-засобів, але для створення баз даних найчастіше використовуються ті з них, що містять у своєму складі інструменти для створення діаграм «сутність-зв’язок» і проектування даних.


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


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


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


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


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


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


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


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


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


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

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


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


Ряд публікацій проводить градацію категорій логічних моделей за ступенем деталізації опису сутностей, атрибутів і зв’язків. Модель, обговорювана із замовником, що є зазвичай експертом в підлягає автоматизації предметної області, а не програмістом або аналітиком, повинна містити, наприклад, основні сутності та зв’язку, але не зобов’язана мати їх детальну технічну опрацювання (зокрема, описи алгоритмів обробки порушень посилальної цілісності). У той же час модель, що служить основою технічного завдання на розробку клієнтських додатків, зобов’язана містити детальне уявлення структури даних, ключових атрибутів, їх текстовий опис, а також представляти сутності в нормалізованому вигляді (іноді така модель називається повною атрибутивної моделлю). Іншими словами, нормалізація моделі даних зазвичай відбувається на етапі логічного проектування (детальніше про нормалізацію розказано в першій статті даного циклу, опублікованій в КомпьютерПресс № 3’2000).


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


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


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


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


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


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


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

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


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

CREATE TABLE Customer (
CustomerID char(5) NOT NULL,
CompanyName nvarchar(40) NOT NULL,
ContactName nvarchar(30) NULL,
ContactTitle nvarchar(30) NULL,
Address nvarchar(60) NULL,
City nvarchar(15) NULL,
Region nvarchar(15) NULL,
PostalCode nvarchar(10) NULL,
Country nvarchar(15) NULL,
Phone nvarchar(24) NULL,
Fax nvarchar(24) NULL
)
ALTER TABLE Customer
ADD PRIMARY KEY (CustomerID)
CREATE TABLE Order (
OrderID int IDENTITY,
CustomerID char(5) NULL,
EmployeeID int NULL,
OrderDate datetime NULL,
RequiredDate datetime NULL,
ShippedDate datetime NULL,
ShipVia int NULL,
Freight money NULL,
ShipName nvarchar(40) NULL,
ShipAddress nvarchar(60) NULL,
ShipCity nvarchar(15) NULL,
ShipRegion nvarchar(15) NULL,
ShipPostalCode nvarchar(10) NULL,
ShipCountry nvarchar(15) NULL,
FOREIGN KEY (CustomerID)
REFERENCES Customer
)
CREATE INDEX XIF1Order ON Order ( CustomerID)
ALTER TABLE Order ADD PRIMARY KEY (OrderID)

create trigger tU_Customer on Customer for UPDATE as
begin
  declare @numrows int, @nullcnt int,
 @validcnt int, @insCustomerID char(5),
 @errno int, @errmsg varchar(255)
 
  select @numrows = @@rowcount
  if update(CustomerID)
  begin
if exists ( select * from deleted,Order where
Order.CustomerID = deleted.CustomerID )
begin
select @errno = 30005,
@errmsg = ‘Cannot UPDATE Customer because Order exists.’
goto error
end
  end
  return
error:
raiserror @errno @errmsg
rollback transaction
end

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


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


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


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


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


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


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


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

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




































CASE – засіб Виробник URL
Designer 2000 Oracle www.oracle.com/ 
ERwin Computer Associates www.cai.com/ 
PowerDesigner Sybase www.sybase.com/ 
ER/Studio Embarcadero www.embarcadero.com/ 
System Architect Popkin Software www.popkin.com/ 
Visible Analyst Visible Systems www.visible.com 
Visio Enterprise Microsoft www.microsoft.com/ 

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


Designer/2000 (Oracle)


Designer/2000 (попередні версії продукту називалися Oracle * CASE) являє собою універсальне CASE-засіб, що дозволяє моделювати бізнес-процеси, створювати діаграми потоків даних і функціональні моделі. Засіб проектування даних і створення ER-діаграм є лише однією із складових частин цього досить складного продукту і надає можливість зберігати створені моделі даних і описані бізнес-правила в призначеному для цього репозитарії.


Designer/2000, призначений для використання головним чином з Oracle 8, підтримує всі особливості даної СУБД, включаючи об’єктні типи даних (CLOB, Arrays, вкладені таблиці тощо), так само як і специфічні особливості фізичної реалізації бази даних Oracle. Для Oracle 7 і Oracle 8 це CASE-засіб дозволяє створити визначення ролей, згенерувати тригери, що реалізують бізнес-логіку, яка описана в моделях, що використовуються при генерації бази даних, а також cгенеріровать об’єкти для розподілених бази даних. Крім того, за допомогою Designer/2000 можна створювати фізичні моделі та здійснювати зворотне проектування і для інших СУБД – Oracle RDB, DB2, Microsoft SQL Server, Sybase, ODBC-джерел даних, а також здійснювати зворотне проектування на підставі DDL-сценаріїв, якщо вони відповідають стандарту ANSI SQL.


Вельми привабливою особливістю Designer/2000 є можливість генерації форм Oracle Developer/2000, проектів Visual Basic, класів C + +, звітів Oracle Reports, додатків для Oracle Web Application Server.


Додаткова інформація доступна на Web-сайті за адресою: www.oracle.com/tools/designer/.


ERwin (Computer Associates)


ERwin розроблений компанією Logic Works, яка в 1988 році була придбана фірмою Platinum Technologies, а її, в свою чергу, придбала компанія Computer Associates. Цей продукт протягом останніх десяти років займає лідируючі позиції серед засобів проектування даних.


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


ERwin не орієнтований на якусь конкретну СУБД і підтримує більше 20 типів СУБД, включаючи СУБД всіх провідних виробників серверів баз даних (Oracle, Sybase, Microsoft, IBM, Informix), а також усі популярні формати настільних СУБД (включаючи dBase, Clipper, FoxPro, Access, Paradox), крім, можливо, самих останніх версій. Справа в тому, що нові версії ERwin не випускалися вже досить давно – як мінімум рік не було оновлень наявної версії і більше двох років не випускалися нові версії цього продукту. Тому при використанні ERwin з останніми версіями деяких СУБД можуть виникнути проблеми (Наприклад, деякі типи даних SQL Server 7.0 це CASE-засіб підтримує не зовсім коректно). Тим не менш ERwin залишається одним з найпопулярніших в світі продуктів цього класу завдяки підтримці великої кількості платформ, простоті інтерфейсу і, що важливо, підтримці специфічних особливостей організації фізичної пам’яті найбільш популярних серверних СУБД. Наприклад, для СУБД Oracle, Microsoft SQL Server, Sybase цей продукт дозволяє змінювати місце розташування і параметри зберігання індексів, майже для всіх популярних серверних СУБД створювати кластеризованих індекси і для багатьох з них – вказувати характеристики табличних просторів і сегментів відкоту.


Виноска: Кластеризованих індекс – спосіб індексування, при якому дані в таблиці фізично розташовані відсортованими за значенням поля, на якому побудований індекс. Для кожної таблиці може бути створений тільки один кластеризованих індекс.


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


ERwin підтримує обмін моделями з репозитарієм Designer/2000 і Microsoft Repository, а також генерацію клієнтських додатків для Visual Basic і PowerBuilder.


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


Нещодавно компанією Computer Associates був випущений новий продукт – ERwin Examiner, що представляє собою інструмент перевірки баз даних і DDL-скриптів з метою виявлення помилок проектування даних, що позначаються на цілісності даних і продуктивності сервера, таких, наприклад, як помилки нормалізації, суперечливі ключі і т.д. В результаті перевірки ERwin Examiner пропонує способи усунення знайдених помилок, генеруючи відповідні DDL-скрипти. На нашому CD-ROM ви можете знайти статтю Сергія Маклакова, присвячену цьому продукту. Ознайомлювальні версії ERwin, ModelMart і ERwin Examiner ви також можете знайти на нашому CD-ROM.


Додаткова інформація доступна на Web-сайті за адресою: www.cai.com/products/alm/erwin.htm.


PowerDesigner (Sybase)


PowerDesigner (колишній S-Designor, що належав компанії PowerSoft) являє собою інструмент, до складу якого входять засіб створення концептуальних (тобто логічних) моделей, засіб створення фізичних моделей і засіб об’єктно-орієнтованого моделювання, що використовується при генерації клієнтських додатків. Засіб створення фізичних моделей являє собою окремий продукт – PowerDesigner PhysicalArchitect. До складу продукту PowerDesigner DataArchitect входять засоби створення концептуальних і фізичних моделей, до складу PowerDesigner Developer – кошти об’єктно-орієнтованого моделювання та створення фізичних моделей, а до складу PowerDesigner ObjectArchitect – всі три засоби.


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


Крім серверних СУБД виробництва Sybase (Adaptive Server Enterprise 12.0, Sybase SQL Anywhere) PowerDesigner DataArchitect здатний працювати з будь-якими ODBC-джерелами. Як і ERwin, він підтримує генерацію тригерів серверних СУБД, що здійснюють стандартну обробку подій, пов’язаних з порушеннями посилальної цілісності.


PowerDesigner Developer і PowerDesigner ObjectArchitect можуть генерувати код клієнтських програм для PowerBuilder, а також класи Java і компоненти JavaBeans. Можливо і зворотне проектування діаграм класів з вихідних текстів Java, байт-кодів та архівів Java. Підтримується також генерація коду Web-додатків і об’єктів для Sybase Enterprise Application Server на основі фізичної моделі.


PowerDesigner DataArchitect може імпортувати логічні і фізичні моделі ERwin.


PowerDesigner DataArchitect може зберігати свої моделі даних в колективно поділюваному репозитарії, керованому за допомогою засобу PowerDesigner MetaWorks та доступному як додатковий модуль у складі будь-якого з перерахованих вище продуктів.


Зазначимо, що PowerDesigner DataArchitect вельми популярний на російському ринку, причому не тільки серед користувачів СУБД і засобів розробки Sybase.


Ознайомчу версію PowerDesigner DataArchitect ви зможете знайти на нашому CD-ROM.


Додаткова інформація доступна на Web-сайті за адресою: www.sybase.com/products/designtools/powerdesigner/.


ER/Studio (Embarcadero Technologies)


ER / Studio менш відомий в нашій країні, ніж ERwin і PowerDesigner DataArchitect. Однак можливості цього продукту також заслуговують на увагу.


За своїм призначенням цей продукт схожий з ERwin – він представляє собою спеціалізоване засіб проектування даних і не містить в своєму складі інструментів для об’єктно-орієнтованого моделювання або моделювання бізнес-процесів. Список підтримуваних СУБД у цього продукту досить широкий і включає всі найбільш популярні серверні та настільні СУБД. На відміну від ERwin остання версія цього продукту коректно підтримує нові типи даних SQL Server 7.


ER / Studio підтримує написання макросів на SAX Basic (клон Visual Basic for Applications). Ця мова дозволяє створювати макроси для виконання однотипних операцій, наприклад додавання стандартних полів до новостворюваних сутностей. За допомогою цього ж мови можна генерувати стандартні тригери і процедури, що зберігаються для вставки, видалення, зміни записів. Код на цій мові можна навіть налагоджувати і звертатися до властивостей сутностей для конструювання серверного коду. Однак, на відміну від ERwin, ER / Studio не дозволяє додати до кожної таблиці свої шаблони тригерів або переглянути код конкретного тригера в процесі розробки моделі – щоб отримати код одного тригера, потрібно згенерувати скрипт для всієї моделі.


Моделі ER / Studio можна зберегти не тільки у вигляді DDL-скрипта, а й у форматі XML. Можна також створити репозитарій для їх зберігання в будь серверної СУБД. ER / Studio може імпортувати моделі ERwin, але при імпорті губляться зв’язку шаблонів серверного коду з конкретними таблицями, і не всі макроси ERwin коректно перетворюються в макроси SAX Basic.


ER / Studio дозволяє згенерувати Java-класи для клієнтських додатків.


Зазначимо, що ER / Studio є COM-сервером, що дозволяє використовувати його в інших додатках, надаючи їм можливість перегляду і редагування моделей даних, а також створювати інші рішення на його основі.


Ознайомчу версію ER / Studio ви зможете знайти на нашому CD-ROM.


Додаткова інформація доступна на Web-сайті за адресою: www.embarcadero.com/products/Design/erdatasheet.htm.


System Architect (Popkin Software)


System Architect 2001 являє собою універсальне CASE-засіб, що дозволяє здійснити не тільки проектування даних, а й структурне моделювання. Засіб проектування даних і створення ER-діаграм є однією з складових частин цього продукту.


Цей продукт підтримує СУБД практично всіх провідних виробників, включаючи Oracle (Oracle 8), Sybase, DB2, SQL Server, IBM (AS400, DB2), Informix, Sybase, Access, dBASE, Paradox та ін


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


Всі компоненти System Architect дозволяють документувати процес роботи над проектом, включаючи технічне завдання, план тестування та ін


Моделі System Architect 2001, як і у випадку інших CASE-засобів, можна зберігати в репозитарії. Однак на відміну від традиційних репозитаріїв, що володіють більш-менш стандартною структурою збережених даних, репозитарій System Architect є налаштованим – до записала об’єктів можна додавати додаткові властивості, певні користувачем.


System Architect володіє вбудованим Visual Basic for Application, що дозволяє створювати різноманітні рішення на базі цього продукту, включаючи автоматичну генерацію моделей та проектної документації.


System Architect 2001 дозволяє генерувати код клієнтських програм для Visual Basic, Delphi і PowerBuilder (на сьогоднішній день це практично єдине CASE-засіб, що підтримує генерацію коду Delphi), класи C + +, а також код і текстові екранні форми COBOL.


Ознайомчу версію System Architect ви зможете знайти на нашому CD-ROM.


Додаткова інформація доступна на Web-сайті за адресою: www.popkin.com/products/sa2001/data/data.htm.


Visible Analyst (Visible Systems Corporation)


Visible Analyst – вельми популярний продукт компанії Visible Systems Corporation. Широко відомі також раніше вироблені цією компанією CASE-засобу EasyER і EasyCASE – попередники Visible Analyst.


Цей продукт випускається в трьох редакціях: Visible Analyst DB Engineer, який включає засоби проектування даних, Visible Analyst Standard, який окрім проектування даних дозволяє здійснювати структурне моделювання, і Visible Analyst Corporate, який крім зазначених вище можливостей дозволяє здійснювати також об’єктно-орієнтоване моделювання.


Visible Analyst підтримує досить широкий спектр СУБД з точки зору генерації серверного коду, включаючи Oracle 7, Sybase SQL Server (System 10 і 4.x); Informix, DB2, Ingres. Останні версії багатьох серверних СУБД (Oracle 8, Microsoft SQL Server 6.5/7/2000, останні версії серверів Sybase) в цьому списку поки що немає.


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


Моделі Visible Analyst можна зберігати в многопользовательском репозитарії, створеному в одній з серверних СУБД.


Крім того, Visible Analyst дозволяє на оcнове створених моделей генерувати код для Visual Basic, С + + і COBOL.


Відзначимо, що продукти сімейства Visible Analyst мають відносно невисоку вартість, що також є їх вельми привабливою рисою.


Демонстраційну версію Visible Analyst ви зможете знайти на нашому CD-ROM.


Додаткова інформація доступна на Web-сайті за адресою: www.visible.com/dataapp/daprods.html.


Visio Enterprise (Microsoft)


Продукт під назвою Visio, придбаний у січні 2000 року корпорацією Microsoft разом з його розробником – компанією Visio Corporation, позиціонувався на ринку як один з найпопулярніших засобів створення схем і діаграм. Те, що один з членів сімейства Microsoft Visio 2000 – Visio 2000 Enterprise – містить в своєму складі повноцінне CASE-засіб, було певною мірою сюрпризом для користувачів CASE-інструментів. Проте, якщо вдуматися, поява своїх засобів проектування даних, моделювання бізнес-процесів і об’єктно-орієнтованого моделювання у Microsoft – крок цілком закономірний, оскільки такі засоби з’являються рано чи пізно у більшості виробників популярних серверних СУБД і засобів розробки, яким Microsoft є вже досить давно.


Як і переважна більшість засобів проектування даних, Visio Enterprise дозволяє виробляти пряме і зворотне проектування даних, перетворювати логічну модель у фізичну. Цим засобом підтримуються всі ODBC-і OLE DB-джерела даних. З його допомогою можна створювати тригери для стандартної обробки порушень посилальної цілісності в разі, якщо DDL-скрипт створюється для Microsoft SQL Server, і серверні обмеження, якщо скрипт створюється для іншої СУБД. Відзначимо, що Visio при генерації скриптів дозволяє вказувати параметри організації фізичної пам’яті Oracle, Informix, Microsoft SQL Server, DB2 та деяких інших СУБД.


Відзначимо, що крім засобів проектування даних Visio включає засоби об’єктно-орієнтованого моделювання і генерації коду додатків Visual Basic 6, а також класів C + + і Java. Моделі Visio можна зберігати в Microsoft Repository.


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


Подробиці про Visio і його використанні ви зможете знайти в статті Олексія Федорова «Знайомство з Microsoft Visio 2000», опублікованій в листопадовому номері нашого журналу.


Додаткова інформація доступна на Web-сайті за адресою: www.microsoft.com/office/visio/.


Висновок


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


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



  1. Підтримка створення логічних моделей, що не залежать від СУБД, і генерації фізичних моделей на їх основі.

  2. Підтримка декількох типів СУБД, включаючи не тільки серверні, але й настільні.

  3. Підтримка специфічних особливостей тих чи інших СУБД провідних виробників (генерація тригерів, управління фізичним зберіганням даних).

  4. Здатність здійснювати зворотне проектування на основі або наявної бази даних, або наявного DDL-скрипта.

  5. Можливість генерації звітів і проектної документації на основі створеної моделі.

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

  7. Підтримка генерації коду для одного або декількох засобів розробки або мов програмування. Слід зазначити, що в цьому відношенні найпопулярнішим засобом розробки є, мабуть, Visual Basic.

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

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


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

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

Ваш отзыв

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

*

*