Проектування інформаційних систем. Частина 3. Етапи розробки проекту: заключні стадії проектування, схема бази даних, Комерція, Різне, статті

Частина 2


Зміст



Прикінцеві стадії проектування


Проектування процесу тестування


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


Коли генерація модуля завершена, виконують автономний тест, який переслідує дві основні мети:



Після того як автономний тест пройшов успішно, група згенерованих модулів проходить тести зв’язків, які повинні відстежити взаємний вплив модулів.


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


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


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


Вимоги до безпеки, доступу, обслуговування системи


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


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


Складання специфікацій


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


Повнота проектування


Перед початком розробки модулів потрібно ще раз перевірити повноту проектування. Один з корисних інструментів – матриця використання таблиць схеми бази даних по модулям.


Перехід до реалізації


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


Як можна використовувати проектувальників на етапі розробки? Наведемо деякі приклади:



Схема бази даних


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


ER-модель та її відображення на схему даних


Результат етапу аналізу – побудова інформаційної моделі. Здавалося б, справа це просте: сутності стають таблицями, а атрибути сутностей – стовпцями таблиць; ключі стають первинними ключами, для можливих ключів визначається обмеження unique, зовнішні ключі стають деклараціями посилальної цілісності. Аналітики, як правило, не вникають в особливості реалізації тієї чи іншої СУБД, тому при проектуванні схеми бази даних проектувальник стикається з конструкціями в інформаційній моделі, які не реалізовані або важко реалізувати в обраній СУБД.


Наведемо кілька прикладів обмежень реалізації СУБД:



Подібних прикладів, коли не тільки ER-модель, а й інші продукти аналізу не можуть бути перенесені автоматично на модель даних, можна навести безліч. Кожен такий випадок ініціює зміну інформаційної моделі. Рішення проблеми визначається можливостями СУБД, вибраної для реалізації проекту. Якщо проблем, не дозволяються в рамках даної СУБД, накопичується дуже багато, то проектувальники можуть поставити питання про зміну СУБД. Таке питання піднімається саме на стадії проектування, оскільки якщо вже розробники зіткнуться з подібними проблемами, то ціна зміни СУБД буде вище. Ясно, що однакових СУБД не буває: те, що добре працює в одній, може погано працювати або взагалі не працювати в іншій, незважаючи на запевнення виробників СУБД в підтримці стандартів SQL. Що стосується збережених процедур і тригерів, то тут взагалі важко говорити про підтримку SQL92/PSM.


Питання продуктивності інформаційної системи також впливають на відображення ER-моделі на модель даних. За рахунок потужного сервера баз даних можна домогтися більшої швидкості реакції системи, але потужність апаратного комплексу обмежена. Продуктивність системи в цілому залежить в тому числі і від нормалізації. Часто до 80% запитів до бази даних є вибірками даних, а з’єднання з того чи іншого атрибуту належить до витратним операціям, в першу чергу з’єднання по нечислових атрибутам. Збільшити продуктивність системи можна за допомогою введення надлишкової інформації – денормалізації. Слід зазначити, що рішення про це не приймається на основі однієї ER-моделі – потрібно уважно проаналізувати потоки даних. Критичні процеси є хорошими кандидатами для денормалізації: за часом виконання, за частотою виконання, за великим обсягом оброблюваних даних, за частотою зміни оброблюваної інформації, по явному пріоритету. Часто до денормалізації вдаються з метою прискорення виконання звітів. Для перевірки ефективності тієї чи іншої денормалізації залучаються тестери.


Типи даних


Як правило, СУБД підтримують невеликий набір базових типів даних: числові типи (цілі, речові з плаваючою і фіксованою крапкою), рядки (символів і байт), дата і час (або комбінований тип datetime), BLOB (і його різновиди, наприклад BLOB-поля для зберігання тільки тексту). В інформаційній моделі кожному атрибуту відповідає домен. Оскільки не всі реалізації СУБД підтримують домени, то в цьому випадку при визначенні моделі даних обмеження домену описують як обмеження стовпця таблиці (якщо таке можливо); зокрема використовують check constraints, тригери. Слід зазначити, що при визначенні типів стовпців таблиць потрібно враховувати, які типи даних підтримуються в словнику даних СУБД. Наприклад, в Oracle ключові слова integer, smallint, real підтримуються транслятором SQL, але в словнику даних їм відповідають number (38), number (38), float (63), так як Oracle зберігає дані в двійковій-десятковому форматі з плаваючою крапкою, а не в двійковому форматі з плаваючою крапкою, і 38-восьмизначні число ніяк не можна назвати словом smallint.


СУБД підтримують два види строкових типів: з фіксованою довжиною (наприклад, char), коли зберігається рівно стільки символів, скільки зазначено в описі атрибута, і зі змінною довжиною (наприклад, varchar), коли зберігається реальна довжина значення атрибута, а кінцеві пробіли рядка усікаються. Семантика порівняння рядків в СУБД також різна, і якщо ваша думка про порівняння рядків розходиться з тим, як це реалізовано в СУБД, то доведеться змиритися з цим як з особливістю СУБД. Наприклад (описано поведінку Oracle 7.x), якщо порівнюються значення A рівне ‘ab’ і B рівне ‘ab’ двох атрибутів типу varchar різної довжини, то sql повідомить, що . Щоб уникнути подібних «фокусів», потрібно, зокрема, слідкувати за тим, щоб програма не вставляли незначущі кінцеві пробіли в значення атрибутів цих типів.


Індекси, кластери


У правильно спроектованій базі даних кожна таблиця містить первинний ключ, що означає наявність індексу. У більшості СУБД використовуються індекси . Відзначимо, що якщо використовується складовою індекс, то пошук по всіх атрибутів, що входять в індекс, починаючи з другого, буде повільним. Припустимо, визначено індекс index1 (id1, id2), в цьому випадку пошук значень, задовольняють умові id2 = 1, буде повільним (не виключено, що оптимізатор взагалі не буде використовувати цей індекс для обробки даної умови і буде прийнято рішення про повне сканування даних), а пошук значень, що задовольняють умові id1 = 1 and id2 = 1, буде швидким. Дані особливості слід враховувати при визначенні індексів у схемі бази даних, а саме:



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


Для того щоб вибрати той чи інший тип індексу, потрібно уважно вивчити керівництво адміністратора СУБД. Оптимізатор SQL використовує різні типи доступу до даних при обробці запитів, і індексування істотно впливає на вибір оптимізатора.


Наведемо деякі способи доступу до даних на прикладі вибірки select id, name from xtable where id = 10:



Ми привели тільки деякі правила виконання операції пошуку в залежності від наявності і типу індексу. У реалізації використовуваної вами СУБД можуть бути прийняті інші принципи. Подробиці використання типів сканування при пошуку даних даються в керівництві по налаштуванню СУБД і в керівництві адміністратора СУБД.


А чому б не проіндексувати все, якщо індексний пошук швидше повного сканування? Очевидно, що індекс займає місце на диску, питання в тому – скільки. Наприклад, індексується атрибут integer – це 4 байта. Але в крім власне значення ключа в індексі зберігаються і внутрішній ідентифікатор кортежу, і деяка службова інформація, так що все разом може становити 4-8 байт. Щоб точно порахувати цю величину для використовуваної вами СУБД, слід звернутися до керівництва адміністратора: подивіться розмір ідентифікаторів ROWID (Oracle), RID (DB2) і т.д., а також розмір сторінки індексу (як правило, це 4 Кбайт).


При виборі стратегії індексації слід дотримуватися двох простих принципів:



Зверніть увагу, зберігає чи СУБД в індексах NULL. Якщо NULL в індексі не зберігається, то ймовірність використання повного сканування для атрибутів без декларації not NULL різко підвищується. Якщо NULL зберігається в індексі (зазвичай його вважають найбільшим або найменшим при побудові і спеціальним значенням при побудові bitmap і хеш-індексів), то з’ясуєте, для яких операцій пошуку індекси будуть використані оптимізатором SQL. Ця інформація, як правило, міститься в керівництві адміністратора. Можна перевірити і експериментально, створивши тестову таблицю з об’ємом даних приблизно 20 тис. записів (щоб оптимізатор не вибирав повне сканування через малого обсягу) і виконавши досліджуваний запит, а потім зробити explain плану запиту (якщо подібний сервіс надається СУБД).


Тимчасові дані


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


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


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


Наведемо приклад обробки ціни товару (код товару, початкова дата, кінцева дата, ціна):

create table prices
(id integer, date_from date not null,
date_to date, price decimal not null,
constraint p_range check date_from < date_to);

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

select price from prices
where id = :PRODUCT_CODE
and date_from < :WHEN_DATE
and date_to >=
nvl(:WHEN_DATE, to_date(’01/12/4721’, ’DD/MM/YYYY’);

Тут: PRODUCT_CODE і: WHEN_DATE позначають змінні включає мови, дата ’01 / 12/4721 ‘є найбільшою з підтримуваних СУБД (ця дата може бути й інший). Подібні операції краще оформляти у вигляді збережених процедур, функцій або претранслірованних запитів. У сховищах даних часто обробляються архівні дані, для яких обробка часових рядів також актуальна.


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


А також як потрібно показувати не відому на даний момент дату, наприклад момент, коли ціна товару перестане бути актуальною? Зробіть це значення рівним NULL або найбільшим значенням (визначте його як default-значення для атрибута). Слід зазначити, що значення default в більшості реалізацій СУБД працюють тільки при вставці нових записів. Можна, звичайно, створити тригер, який спрацьовує після виконання операції insert або update і перетворює null в найбільшу з допустимих значень дати. Але в цьому випадку, коли користувач буде працювати з подібною інформацією, то може забути, звідки взялася та чи інша дата. Якщо ви спроектували схему бази даних та запити таким чином, то всі програми, що працюють з вибірками даних, повинні відповідати таким вимогам:



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


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


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


Зберігання об’єктів даних


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



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


Захист даних


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


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


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


Деякі проектувальники дуже люблять використовувати описаний вище метод захисту даних – це схоже на інкапсуляцію. Іноді проектувальники будують на КАСКАДІРУЕТСЯ виклики збережених процедур вельми складні протоколи доступу до даних, імітуючи мандатну захист. Такий підхід має свої переваги і недоліки. З одного боку, будь-який доступ до даних прихований збереженої процедурою або пакетом, але з іншого – в цьому випадку словник даних сильно перевантажений. Однак далеко не всі реалізації СУБД добре працюють з курсорами в збережених процедурах і пакетах, оскільки це викликає надмірну завантаження процесора. Крім того, в більшості реалізацій СУБД пропозиції SQL, виконувані з збереженої процедури або пакета, мають більш високий пріоритет, ніж операції SQL, виконувані з програми користувача. У зв’язку з цим велика кількість викликів збережених процедур може істотно сповільнити виконання запитів безпосередньо з додатків користувача. У будь-якому випадку, щоб зробити захист даних, «закриваючи» будь-який запит збереженої процедури, потрібно, щоб СУБД мала досить розвинений мова та дозволяла, наприклад, виконувати синтаксичний розбір і щоб усередині самої процедури можна було будувати як статичні, так і динамічні пропозиції SQL.


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


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


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


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



Відповіді на ці питання дозволять більш реально оцінити ситуацію і уточнити вимоги замовника, формалізовані аналітики. Буває, що замовлення працездатності системи в режимі 24х7 зовсім не є обгрунтованим і система простоює, наприклад, 50% часу. Якщо ж вимога 24х7 дійсно відображає особливості даного бізнесу, то ці питання допоможуть побудувати відповідну стратегію захисту даних від збоїв. Якість побудованої при проектуванні стратегії захисту має бути перевірено тестерами, причому їхня робота по генерації та проведення тестів, що імітують відмови обладнання, повинна проводитися як на етапі проектування, так і протягом усього етапу розробки – в цілях раннього виявлення дефектів стратегії захисту даних від збоїв.


Обмін даними із зовнішніми системами


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


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


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


Інтерфейси обміну з зовнішніми системами можна розбити на наступні категорії:



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


При аналізі задач завантаження та вивантаження даних проектувальник повинен розглянути:



а також:



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


При завантаженні даних зі старої системи проектувальники можуть зіткнутися з великим об’ємом неочищених даних – з порушеннями цілісності даних, що виникли через збої системи, «латок» розробників, інших неприємностей. Можливо, що на вас буде чинитися тиск з тим, щоб допустити наявність неочищених даних в новій системі. Якщо не вжити заходів з очищення даних, то, ймовірно, більшість спроектованих обмежень цілісності потрібно буде послабити, щоб завантажити хоч якусь частину даних. Ціна такої поступки досить висока: дані ви прийняли, але ослаблені раніше обмеження вже не можна відновити, так як вони вже порушені (це відслідковується СУБД автоматично). Звідси випливає висновок: піддаватися тиску не можна, так як кілька днів, витрачених на очищення даних, стоять так мало в порівнянні з наявністю в інформаційній системі даних, що не володіють елементарною цілісністю.


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


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


create table t(id int primary key, name char(10);
create table tx(i int, j int references t(id));
create table tx(i int, j int references t(id) on delete no action on update no action);
create table tx(i int, j int, foreign key j references t(id) on delete no action on update no action);
create table tx(i int, j int, foreign key j references t on delete no action on update no action);
create table tx(i int, j int, constraint t_ref_cascade foreign key j references t(id) on delete no action on update no action);

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

Частина 4


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


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

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

Ваш отзыв

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

*

*