Поняття про інтегровану базу даних як одну із складових програмних забезпечень АРМ

Міністерство культури і туризму України Київський національний університет культури і мистецтв

Інститут готельно-ресторанного і туристичного бізнесу Кафедра міжнародного туризму

Реферат на тему: «Поняття про інтегровану базу даних як одну із складових програмних забезпечень АРМ»

Виконала: Маринич К.

Київ 2010

У сьогоднішньому бізнесі конкуренція постійно посилюється. Щоб досягти успіху доводиться виробляти більше продукції за меншу вартість і швидше, ніж раніше. У нашому стрімкому світі зупинитися — означає програти. Як сказав, одного разу американський філософ Йоги Берра (Yogi Berra), «рано швидко стає пізно». Дуже часто вижити в умовах гострої конкуренції допомагають оперативні дані. Багато бізнесменів розуміють тепер, що інформація — можливо, саме цінне, що у них є. Часто вибірка, оновлення та збереження даних повсякденній діяльності виконуються деякої прикладної програмою, наприклад, бухгалтерської або прийому замовлень.

Ми, фахівці, зазвичай, називаємо програми такого типу додатками оперативної обробки транзакцій OLTP (online transaction processing). Додаток OLTP часто інтерактивно, тобто оновлення даних відбувається в процесі оперативних транзакцій. Для легкого і швидкого доступу до оперативної інформації сьогодні її зазвичай зберігають в реляційній базі даних. Комп’ютерна революція дозволила легко збирати і дешево зберігати великі обсяги оперативних даних. Багато компаній зберігають свої дані за багато років, вірячи, що це може коли-небудь стати в нагоді. Але в більшості з них залишається питання: «Ми знаємо, що всередині цих даних прихована безцінна інформація про наших ринках збуту, товари, послуги та клієнтів. Але як витягувати цю інформацію?» Традиційно, аналіз даних у пошуках необхідної інформації виконувався вручну. Але в останні кілька років стало очевидно, що автоматизація аналізу даних не тільки значно полегшує цей процес, але й економічно вигідна.

Часто ПО аналізу даних називають системами підтримки прийняття рішень (decisionsupport), і говорять про перетворення даних спочатку в інформацію, а потім у знання. Словосполучення складування даних (data warehousing) та розробка данних1) (data mining), ще кілька років тому відомі лише вузьким фахівцям, стали частиною повсякденного словника ділової людини. Розповіді в пресі про компанії, яким за допомогою цих технологій вдалося вийти на передові позиції у своїй галузі, спонукали багато фірм слідувати тим же шляхом. Сховища даних, де накопичується інформація з зібраних оперативних даних, — можливо, одна з найбільш швидко поширюються інформаційних технологій для бізнесу. Деякі консультанти пророкують, що в наступні кілька років приблизно третину всіх витрат на інформаційні технології буде пов’язана з нею. Яке відношення все це має до AS/400?

Імовірно, у найближчі кілька років за допомогою AS/400 буде реалізовано більше сховищ даних, ніж за допомогою будь-якої іншої системи. Причина проста: саме DB2/400 — база даних AS/400 — найбільш широко використовувана багатокористувацька база даних у всьому світі, і саме під її управлінням зосереджений найбільший обсяг оперативних даних. Зазвичай, цей факт дивує навіть у замовників AS/400. IBM не продає DB2/400 як окремий продукт, тому багато хто просто не знають про її позиції на ринку і часто вважають найбільш широко поширеними бази даних від Oracle, Sybase або Microsoft. Дуже мало хто знає про DB2/400. Враховуючи обсяг даних, що зберігаються в базах DB2/400, можна уявити, як багато сховищ даних буде створено на AS/400. За оцінкою IBM більше 60 відсотків замовників AS/400 в наступні кілька років стануть використовувати ті чи інші системи підтримки прийняття рішень. У цій лекції ми розглянемо всі зростаючу роль баз даних і те, як AS/400 вдається тримати першість у цій галузі. Ми зупинимося також на історії DB2/400 і на тому, як вона інтегрована в AS/400. Але спочатку, давайте розберемося, що таке DB2/400? База даних без імені Багато років тому ми вирішили інтегрувати потужну реляційну базу даних у кожну System/38. Потім ця ідея перекочувала і в AS/400.

Ми вважали, що здатність повнофункціональної системи управління базою даних (СКБД) ефективно і надійно обробляти великі обсяги інформації, стане гарною основою всіх додатків для бізнесу. Замість того, щоб робити базу даних окремим продуктом, ми просто вбудували її, навіть не потурбувавшись про окремий імені. Непомітно для очей багато років безіменна база даних тихо робила свою справу. В результаті, навіть не всі наші замовники (40 відсотків, як показали проведені кілька років тому дослідження) знають, що на них щодня працює така потужна база даних. Це і добре, і погано. Добре, що багато замовників не робили ніяких спеціальних зусиль для управління своєю базою даних, а просто користувалися, не відчуваючи при цьому жодної потреби у допомозі адміністратора бази даних. (Цим база даних AS/400 відрізняється від деяких інших, для управління якими потрібно персонал). Погано ж те, що деякі користувачі в один прекрасний день вирішили додати на свої AS/400 базу даних, не знаючи, що вона там вже є. Дійсно, користувачі майже всіх сучасних комп’ютерах, включаючи ПК, окремо купують і інтегрують в систему реляційні бази даних. Тому, вирішили такі замовники, безсумнівно, варто витратитися і встановити реляційну базу даних і на AS/4002).

Крім того, нам, співробітникам IBM, було важко пояснити, де власне знаходиться база даних AS/400, так як вона не зосереджена в одному місці. Інтегрована природа системи веде до того, що база розподілена по всій системі. З іншого боку, звичайні бази даних — це окремі програмні компоненти, що працюють поверх ОС. Щоб дістатися до звичайної бази даних, програмі необхідно пройти через ОС або використати абсолютно окремий інтерфейс. Між тим, інтегрована частково над MI, і частково в SLIC, база даних AS/400 більш ефективна, ніж бази, побудовані поверх існуючих систем. База даних AS/400 тісно пов’язана з іншими компонентами системи і взаємодіє з ними способами, недоступними звичайним баз. У 1994 році ми вирішили дати своїй базі даних ім'я, вибравши «DB2 для OS/400» у віддзеркалення того, що наша база даних — частина сімейства реляційних баз даних IBM DB23). Родовий схожість полягає, в основному, у зовнішніх утилітах та підтримки розподілених баз даних. Внутрішньо кожен продукт реалізований посвоєму. Але ім'я DB2 все допомагає усунути враження, що у AS/400 немає сучасної, надійної бази даних. Інтегрована база даних AS/400 вирішує проблеми бізнесу за допомогою новітніх інформаційних технологій. Зростання популярності сховищ даних і засобів їх обробки серед замовників AS/400 — доказ потужності цієї системи. Не доводиться дивуватися, що серед інших нових технологій багато користувачів віддають перевагу саме її. Давайте розглянемо, як AS/400 підтримує сховища і обробку даних, а потім розберемо деякі фундаментальні концепції DB2/400. Сховища даних Отже, ми переконалися у важливості для сучасного бізнесу оперативного зберігання і використання даних і обговорили, чому в цьому випадку може допомогти реляційна база даних.

Оперативні дані динамічні, часто оновлюються, оптимізовані для транзакцій. Інформаційні дані - узагальнюють оперативні, оновлюються рідко (може бути навіть ніколи), і зберігаються у формі, оптимізованої для прийняття рішень, окремо від оперативних, часто навіть на іншій машині. Саме інформаційні дані і складають сховище даних. Слід ясно розуміти, що сховище даних — це концепція, а не конкретний продукт. Це набір засобів для систематизації інформаційних даних, їх зберігання та аналізу для прийняття рішень.

Сховище даних AS/400 складається з чотирьох основних компонентів, а саме:

· коштів трансформації та перетворення даних для заповнення сховища; сервера бази даних;

· аналітичних засобів і програми для користувача інтерфейсу;

· засобів управління інформацією про сам сховище.

Перетворення оперативних даних в інформаційні Створення сховища даних вимагає перетворення оперативних даних в інформаційні. Для цього використовуються так звані засоби трансформації (transformation tools) або засоби перетворення (propagation tools). Їх завдання — не просто витягти дані з однієї або кількох оперативних баз, а й перетворити їх у форму, придатну для зберігання. Візьмемо, наприклад, оперативні дані оптового дистриб’ютора з продажу. Кожен запис містить інформацію про розмір партії проданого товару, форми оплати та про покупця. Так як дані знаходяться у форматі, зручному для реєстрації кожної транзакції, то їх аналіз за допомогою запитів може вимагати занадто багато часу, оскільки більшості аналітичних програм не потрібна інформація за окремими транзакціями. Програма може проаналізувати зібрані дані для прогнозу потреб в товарах, або для оцінки доходів у порівнянні з минулим роком. Для аналізу такого типу — швидкого виявлення тенденцій і потенційних проблем — дані повинні бути перетворені.

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

Автоматичне оновлення сховища даних здійснюється з різною періодичністю: раз на тиждень, раз на день або кожні 10 хвилин. Є багато програм як IBM, так і інших виробників, що дозволяють вибирати дані з баз (DB2 або інших) і імпортувати їх безпосередньо в склад даних AS/400. Сервери баз даних.

Кілька років тому IBM представила спеціальні моделі AS/400, названі серверними. Вони створені для роботи в якості серверів баз даних, серверів комунікацій і пакетної обробки. У ці моделі внесені поліпшення, спеціально призначені для додатків сховищ даних. Ми ще повернемося до серверних моделями, а зараз давайте, детальніше поговоримо про поліпшення у DB2/400. Отже, два найважливіших аспекти підтримки сховищ даних — паралельна обробка та багатовимірні бази даних (MDD). Паралельна обробка Різні прийоми паралельної обробки дозволяють базі даних повністю задіяти всі апаратні можливості. Вибірка і аналіз великих обсягів інформації може вимагати дуже великих ресурсів. На щастя, при обробці бази даних доступ до неї може здійснюватися паралельно, після чого зібрані дані можна аналізувати незалежно і також паралельно. Обробка баз даних — один з прикладів практичного використання масового паралелізму, який ми коротенько торкнулися в лекції 2.

IBM кілька модифікувала AS/400 і DB2/400, що дозволило застосувати масовий паралелізм при роботі з базою даних. Вперше підтримка паралельної обробки уведення-виводу з’явилася в V3R1, що дозволило скористатися можливостями апаратної архітектури AS/400, що має як основні процесори, так і допоміжні, і ввести паралельну обробку на рівні процесора вводу-виводу (IOP) для одного завдання. Ми детально розглянемо IOP в лекції 10, а зараз, забігаючи вперед, скажу, що в потужній AS/400 їх може бути встановлено кілька сотень, причому до різних IOP підключають безліч дискових накопичувачів. Паралельний введення-виведення дозволяє обробляти користувальницький запит до бази даних кількома IOP одночасно. Таким чином, усувається одна з найсерйозніших проблем, що заважають багатьом системам досягти високої продуктивності: затримки при виконанні введення-виведення.

У лекції 2 ми говорили про підтримку SMP в AS/400, коли всі основні процесори працюють паралельно із загальною пам’яттю. При більшості видів обробки окремі завдання виконуються на різних процесорах, при необхідності використовуючи загальні області пам’яті. При обробці запитів до бази даних кожен основний процесор може обробляти частина завдання. Саме так працює засіб паралельної обробки DB2/400. Запит розбивається на окремі, незалежні вкладені запити, які виконуються паралельно декількома основними процесорами, що дозволяє значно скоротити час обробки. Поставити використання декількох процесорів при обробці запиту можна за допомогою відповідної опції команди «CHGQRYA» (Change Query Attribute). Даний метод підвищує продуктивність таких запитів, як пошук в таблиці, групування (groupby), пошук в індексі та з'єднання (join). Підтримкою паралельної обробки бази даних на системах SMP користуються також деякі внутрішні функції SLIC, наприклад, побудова індексу (детально про це ми поговоримо в розділі «Машинний індекс»). Паралелізм присутній на всіх системах версій 3 і 4, але паралельне побудова індексу — тільки на RISC-системах. AS/400 також підтримує конфігурації MPP. При цьому кілька систем AS/400 за допомогою високошвидкісних ліній з'єднуються один з одним у кластер. Один із способів такого з'єднання — через волоконнооптичних кабель за допомогою продукту OptiConnect. Для об'єднання машин серії AS/400е підходить також з'єднання SAN, що дозволяє досягти ще більших швидкостей.

Розподіл бази даних по дисках всіх систем кластера дозволяє створювати дуже великі бази, з якими паралельно працюють декілька сотень процесорів. IBM називає таку конфігурацію MPP слабко зв’язаної паралельної системою бази даних, у зв’язку з відсутністю поділу пам’яті за межами окремої системи в кластері. Тут використовується докладно обговорювався в лекції 2 підхід sharednothing, схожий на той, що застосовується в SP2.

Різниця в тому, що вузли кластера AS/400 знаходяться в різних фізичних корпусах, але, незважаючи на це, для користувача кластер виглядає як єдина база даних. Технологія слабко зв’язаної паралельної бази даних дозволяє розбивати запити на частини, з якими може впоратися окремий вузол. На відміну від SMP-паралельної бази даних, у кожного вузла — власні пам’ять та дисковий простір. Кожен вузол кластера працює з порцією фізичного файлу або таблиці, і запит до нього виконується для відповідної порції файлу. Кожен вузол може містити один або декілька процесорів, адже вузол — це просто AS/400. Додаток, що виконується на будь-якому комп’ютері кластера, може працювати з базою так, як якщо б вона повністю розміщувалася на цьому комп’ютері. Розподіленість бази по вузлах кластера робить DB2/400 прозорою як для додатків, так і для кінцевого користувача. Для завдання імен систем у групі вузлів у CL були введені нові команди, до деяких команд були додані нові параметри для підтримки розподілу файлів бази по вузлах. Після розосередження по вузлах, файл при виконанні операцій вставки, оновлення та видалення виглядає як локальний. Головна перевага слабко пов’язаних паралельних систем — відсутність верхньої межі кількості вузлів, що означає практично необмежене зростання продуктивності і місткості. Можливості розширення концепції кластерів AS/400 в майбутньому ми розглянемо в лекції 12.

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

У результаті вийде куб, дуже схожий на тривимірну електронну таблицю, в кожній клітинці якої - величина доходів від продажу. Далі можна використовувати різні засоби аналізу продажів товарів у регіонах протягом деякого періоду часу. AS/400 підтримує багатовимірні структури даних безпосередньо в самій базі даних DB2/400 або за допомогою продуктів, розроблених бізнес-партнерами. Перевага багатовимірних структур даних полягає в можливості швидко отримати відповідь на поставлене питання у вигляді зрізу даних з будь-якого вимірювання або проходу крізь структуру для отримання даних нових рівнів. Оскільки час відповіді на запити зазвичай дуже мало, такий багатомірний аналіз часто називають оперативної аналітичної обробкою OLAP (online analytical processing). Іноді різним підрозділам однієї організації потрібні інформаційні дані в різних формах. Усередині MDD можна створювати спеціалізовані сховища даних (data mart), які містять інформаційні дані, що відповідають потребам конкретного відділу або робочої групи. У цьому випадку сховище даних всієї організації складається з набору таких спеціалізованих сховищ для окремих структурних одініць 4).

Аналіз даних та інструментарій кінцевих користувачів Терміном «інтелектуальний бізнес» (business intelligence) позначають методи обробки інформації, що застосовуються для прийняття рішень у бізнесі. Засоби інтелектуального ведення бізнесу — це програмні пакети, які використовуються для аналізу даних в сховищі даних на AS/400. Зазвичай, ці програми працюють на ПК і здатні звертатися до сховища даних на AS/400 безпосередньо. Є три основні категорії бізнесінформаціонних засобів: програми підтримки прийняття рішень DSS (decision support system); управлінські інформаційні системи EIS (executive information system); засоби розробки даних. Програми DSS дозволяють кінцевому користувачу будувати гіпотезу і потім генерувати запити для її перевірки. При цьому передбачається, що у користувача є якесь загальне уявлення про те, що потрібно знайти в сховище даних, і це дозволяє йому видавати довільні запити і генерувати звіти. Це кошти найпростішого типу, так як вони просто повертають інформацію за запитом користувача. EIS об'єднують засоби підтримки прийняття рішень з деякими розширеними можливостями аналізу.

Зазвичай, вони мають доступ до засобів за межами сховища даних, наприклад, можуть використовувати оперативні новини з Інтернету для отримання інформації з світових ринків. Як і DSS, EIS передбачає наявність у запитувача деякого уявлення про те, що саме слід шукати. І EIS, і DSS забезпечують пошук потрібної користувачу інформації шляхом перевірок. Але як бути, якщо Ви не можете чітко сформулювати питання? Ви знаєте, що в базі даних прихована важлива інформація, але не можете придумати, як до неї дістатися. Тоді Вам потрібна розробка даних — засіб прийняття рішень на основі відкриттів. Розробка даних дозволяє відшукувати інформацію при незначному обсязі вказівок від користувача або зовсім без таких. Система виконує пошук шаблонів і зв’язків. На практиці існує нескінченна безліч варіантів такого способу пошуку. Наприклад, роздрібний торговець може використовувати розробку даних для того, щоб визначити, які товари купуються разом.

Аналіз та оцінка звичок покупців дуже корисні при оцінці попиту на товар, або виявленні груп покупців з найвищим потенціалом. Розробка даних використовується також у банківській справі для виявлення підробок кредитних карток: шляхом «просіювання» великих обсягів інформації можна виявляти відхилення від норми. Технологія розробки даних прийшла з миру штучного інтелекту. Засоби IBM для пошуку шаблонів і взаємозв'язків даних комбінують нейронні мережі та статистичні алгоритми. Нейронна мережа підтримує основний крок розробки даних в процесі відкриття знань. Відповідна технологія була розроблена в Рочестері в період проекту Fort Knox (докладніше про це — у Додатку) і вперше з’явилася на ринку на початку 90х років у вигляді утиліти для сховищем даних. Існують дві форми метаданих — технічні та бізнесданние.

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

Еволюція реляційної бази даних. Перша комерційна база даних з реляційними можливостями з’явилася в System/38. Ця унікальна технологія випереджала інші реляційні бази приблизно на три роки, що дозволило System/38 вийти на передові позиції на ринку. Розробники System/38 шукали більш ефективний спосіб обробки записів, у порівнянні з System / 3. Перша System / 3 була розроблена як машина одиничних записів. Вона підтримувала тільки пакетну обробку, тобто застосування повинне було обробити всі записи в файлі одну за одною. Перші записи розміщувалися на перфокартах, колода перфокарт становила файл. Пізніше, з’явилася можливість збереження файлів на диску, хоча оброблялися вони як і раніше за допомогою перфокарт. Типове додаток одиничних записів спочатку сортувати записи у файлі. Записи могли мати кілька полів, що містять таку інформацію, як ім'я клієнта, номер рахунку, номер деталі і так далі. Вибиралося одне з цих полів, зване ключем, і всі записи сортувалися за значенням ключового поля в певному порядку. Механічний сортувальник перфокарт в більшості машин одиничних записів використовувався дуже інтенсивно.

Після сортування файл оброблявся послідовно, запис за записом, до кінця. Пізніше в System / 3 була додана інтерактивна обробка. Застосування дисків дозволило звертатися до записів у довільному порядку. Пошук потрібного запису здійснювався за допомогою індексу — невеликого файлу, в якому кожного запису основного файла відповідають лише два поля. Перше містить значення ключа, а друге — дисковий адресу запису з співпадаючим значенням. Для сортування записів індексу за значеннями ключа використовувалася особлива програма. Потім індекс зберігався на диску разом з основним файлом. Для пошуку запису із заданим значенням ключа система спочатку переглядала індекс. Після цього для вибірки повного запису використовувався дисковий адресу, що зберігається разом з цим значенням. Так як розмір пам’яті System / 3 був дуже невеликим, зберігати в пам’яті об'ємні індекси цілком було неможливо. Це знижувало ефективність пошуку із-за необхідності кількох звернень до диска. System/34 була першою моделлю сімейства System / 3, призначеної для роботи в інтерактивному, а не в пакетному режимі. Розміри пам’яті в System/34 були також невеликі, так що IBM вирішила прискорити пошук потрібного запису в індексі, а для цього — усунути необхідність зчитувати індекс з диска. Частина доріжок диска була зарезервована для індексу, для контролера диска була розроблена спеціальна апаратура. Бажане значення ключа процесор передавав дискового контролера. Потім контролер починав зчитувати інформацію доріжки, відшукуючи значення ключа. Виявивши шукане, апаратура контролера зчитувала наступне поле адреси і повертала його процесору. Процесор використовував отриманий адреса для зчитування цілого запису з деякої іншої частини диска. Ця операція була названа скануванням. Функція сканування значно підвищила ефективність інтерактивної обробки, завдяки повного усунення етапу звернення до диску для зчитування індексу. Але при цьому потрібно вмонтувати в пам’яті ще один невеликий індекс. Індекс у пам’яті вказував, на який індексного доріжці диска слід виконувати пошук. Пізніше аналогічна операція сканування була реалізована в System/36 для обробки файлів. Для System/38 також була важлива дуже висока ефективність інтерактивної обробки. Недоліком описаної процедури сканування була її занадто тісна прив’язка до апаратури. Були також і інші обмеження: максимально можливе число індексів, обмеження способів їх обробки і ін Так як System/38 повинна була мати однорівневу пам’ять, розробники вирішили помістити всі файли і індекси в цю велику пам’ять. Якщо повернутися назад до щойно описаної файлової структурі, то ми побачимо двовимірну таблицю, де рядки-це записи, а стовпці - поля записів. Розробники порахували, що найбільш ефективним буде організувати файл System/38 просто як двовимірну таблицю в пам’яті. Вони також вважали, що продуктивність обробки підвищиться, якщо таблицю обробляти «на місці» без сортування записів. Щоб добитися цього, вони вбудували індекс у таблицю так, що сортування просто не потрібно (докладніше про це — далі, в розділі «Машинні індекси»).

По суті, передбачалося, що в System/38 ніколи не буде програми сортування. Однак, така програма була і є. Її написав Дік Бейнс, назвавши «Conversion Reformat Utility», ймовірно, щоб приховати її сутність і запобігти використання прикладними програмістами в нових проектах1). Ця програма, тим не менше, була — а, може бути, є і до цього дня — найшвидшим способом сортування та вибірки записів з великих файлів. Джим Слоан (Jim Sloan), колишній розробник і проектувальник, який брав участь у створенні компілятора CL, розробив у складі свого набору QUSRTOOL утиліту для користувачів, інтерфейс якої до цієї програми сортування дозволяв використовувати зовнішні імена полів. У процесі розробки бази даних Перрі Тейлор (Perry Taylor) випадково натрапив на технічний звіт Є. Ф. Кодда (EF Codd). Кодд, який вважається творцем реляційної бази даних, працював над проектом System / R (R — реляційна) в дослідницькому центрі IBM в Каліфорнії. Базою у визначенні Кодда була двовимірна таблиця, над якою можна було виконувати чотири елементарних операції. Перша операція — впорядкування (order) — дозволяла обробляти рядки або стовпці в певному порядку по ключовому полю, друга — вибірка (selection) — вибирати записи за значенням ключового поля, а третина — проекція (projection) — здійснювати вибірку з таблиці заданих полів, і нарешті, четверта — з'єднання (join) — розглядати кілька таблиць як одну велику. Таким чином, реляційна база даних представляла собою просто двовимірну таблицю з операціями упорядкування, вибірки, проекції і з'єднання. Перрі відразу ж зрозумів, що розробники System/38 будують дуже схожу базу даних, за винятком того, що в ній немає з'єднання. Він подзвонив Кодда, щоб повідомити про роботи в Рочестері і запропонувати свою підтримку. Але Кодд відповів, що, на його думку, реляційні бази даних призначені тільки для великих систем; а малим потрібні тільки функції сортування і злиття. За словами Перрі, розмова не була сердечним.

Тон Кодда він порівняв з тоном поліцейських під час перехресного допиту їх захисниками на процесі О. Дж. Сімпсона (OJ Simpson) — ввічливий, але холодний. Кодд і Тейлор більше ніколи не розмовляли. Через три роки після оголошення System/38 база даних System / R була оголошена як DB2 і визнана в якості першої реляційної бази данних2). Так як спочатку System/38 не підтримувала операції з'єднання, то вона вважається першою комерційної базою даних з реляційними можливостями. Дволика база даних Говорячи про базу даних, ми маємо на увазі не просто деякий місце для розміщення даних. Ми говоримо про систему управління базою даних. СУБД — середовище для зберігання та вибірки даних, що включає визначення даних, правила забезпечення їх цілісності та механізми підтримки, а також операції збереження та вибірки даних. СУБД повинна мати інтерфейс, щоб користувачі могли працювати з нею. У цьому розділі ми представимо два інтерфейси СУБД AS/400: DDS (Data Description Specifications) і SQL (Structured Query Language), в наступних розділах — детально розглянемо саму СУБД. Коли IBM починала проект System/38, стандартних інтерфейсів до реляційної бази даних не існувало. Тому проектувальникам довелося розробити власний унікальний інтерфейс для цієї системи. Не дивно, що цей інтерфейс DDS дуже схожий на файлову систему, яку повинен був замінити.

Творці інтерфейсу обмежилися декількома системними командами і функціями управління базою даних, а також ввели в MI команди для таких операцій як читання, запис, оновлення і видалення. Програмісти могли безпосередньо використовувати ці команди з таких мов як RPG і Cobol. Наприклад, багато хто використовує DDSRPG: DDS для визначень даних, RPG для доступу до них. Інтерфейс DDS перейшов з System/38 в AS/400, і багато як і раніше, віддають перевагу його. Колишнім користувачам мейнфреймів, який перейшов на AS/400, він також подобається, оскільки дуже схожий на інтерфейс бази даних для великих систем IBM — IMS (Information Management System). Приблизно в той же час, коли розроблялася AS/400, IBM та інших фірмах виконувалися проекти по стандартизації SQL (з System / R) в якості мови реляційних баз даних. Проект просувався не дуже гладко, на створення стандарту було потрібно близько десятиліття. Ingres багато років використовувала мову-суперник QUEL, поки, нарешті, теж не піддалася загальної тенденції. Розгромна в 1988 році AS/400 підтримувала і власний інтерфейс DDS, і SQL.

Оператори SQL можуть включатися безпосередньо в програми на RPG, Cobol і С, замінюючи «рідні» команди, такі як читання, запис і оновлення. Для трансляції цих операторів SQL DB2/400 містить прекомпілятори. При більш уважному погляді стає видно, що DB2/400 складається з двох окремих частин. Власне СУБД і мова DDS входять до складу OS/400. Query Manager and SQL Development Kit — особливий продукт, що купується окремо. Як випливає з назви, цей продукт містить Query Manager — ПО AS/400 для кінцевого користувача, що дозволяє видавати запити на SQL. До складу продукту входять крім того інтерактивний користувальницький інтерфейс до SQL (Interactive SQL), а також прекомпілятори для різних мов, що використовуються при вставці операторів SQL в ЯВУ. До нещастя склалося так, що IBM вимагає від Вас платити за SQL окремо, тоді як DDS входить до складу OS/400. Така ситуація — основна причина непопулярності SQL у багатьох користувачів AS/400, які вважають його зовнішнім продуктом, яким він насправді не є. Сьогодні більшість розробників баз даних в Рочестері думають в термінах SQL, а не DDS. Інтерфейс DDS буде підтримуватися і далі, але нові функції, швидше за все, будуть в SQL. Хоча AS/400 і підтримує два різних інтерфейсу до бази даних, вкрай важливо розуміти, що сама база даних тільки одна. Доступ до даних, визначення даних та маніпуляції з ними на AS/400 можливі як за допомогою DDS, так і за допомогою SQL. Так як інтерфейс SQL використовує ті ж команди MI, що і DDS, кожен з інтерфейсів може працювати з об'єктами даних, створених за допомогою іншого інтерфейсу. Ця можливість плутання двох інтерфейсів забезпечує базі даних AS/400 додаткові міць і гнучкість. Найбільша проблема двох інтерфейсів складається в плутанині, що викликається термінологічними відмінностями. Як і у випадку розходжень імен між об'єктами OS/400 і системними об'єктами MI, імена для різних інтерфейсів бази даних підбиралися різними групами. Наприклад, в інтерфейсі DDS є фізичні файли, що містять дані. Як ми бачили раніше, фізичний файл — це двовимірна таблиця. В інтерфейсі SQL той же самий фізичний файл називається таблицею, що більше підходить для цієї структури. Логічний файл в інтерфейсі DDS не містить дані, а вказує на реальні дані і дає програмі деяку їх проекцію. У SQL логічний файл називається проекцією (view). Аналогічно, те, що в термінології DDS — запис і поле, в інтерфейсі SQL — рядок і стовпець (щоб відобразити концепцію таблиці). Як функціонує база даних У цьому розділі ми розглянемо різні компоненти бази даних AS/400. Я не ставив тут перед собою завдання проінструктувати Вас, як використовувати цю базу даних. Вже є цілий ряд хороших книг, присвячених зовнішнім аспектам бази даних і використанню двох її інтерфейсів в программах1). А я лише хочу запропонувати Вам огляд характеристик СУБД та основ її функціонування. Розділ складається з двох частин. У першій міститься опис основних функцій, які повинні бути присутніми в кожній СУБД, та їх реалізації в AS/400. У другій — огляд інших характеристик бази даних, деякі з яких мають відношення до продуктивності, а інші забезпечують підтримку використання AS/400 в якості сервера бази даних.

Після цього ми поговоримо про внутрішню реалізації деяких фундаментальних функцій бази даних. Функції СУБД Є багато способів реалізації реляційної бази даних, але будь-яка система управління нею повинна надавати наступні сім функцій: визначення та опис таблиць бази даних; операції з даними (вставка, вибірка, оновлення і видалення); можливість визначити, що представляють собою дані незалежно від програми; можливість створювати нові проекції даних для задоволення змінюються вимог прикладних програм; множинні проекції даних для різних прикладних програм, захист даних; цілісність даних. Тепер подивимося, як ці функції реалізовані в AS/400.

Опис даних і створення файлів. Для опису фізичних і логічних файлів бази даних можна використовувати «рідний» мова СУБД AS/400 — DDS. Він містить оператори, ключові слова і параметри, що дозволяють описувати як атрибути самого файлу, так і полів записів бази даних. DDS можна також застосовувати для опису файлів пристроїв, що використовуються AS/400. Ці файли пристроїв містять інформацію про формат і типах даних, використовуваних підключеними до системи фізичними пристроями. DDS дозволяє визначити кілька атрибутів полів записів бази даних. Серед них ім'я поля, його довжина і рід даних (текстові або числові). Залежно від типу даних поля можна задати деякі інші специфічні атрибути. Наприклад, якщо поле містить десяткові дані, можна задати загальне число десяткових цифр і число цифр справа від коми. реляційний інтеграційний база

Оператори DDS поміщаються в розділах вихідних файлів, які потім перетворюються на файлові об'єкти за допомогою команд OS/400 «CRTPF» («Create Physical File») і «CRTLF» («Create Logical File»). Для опису атрибутів файлів бази даних можна використовувати і SQL. На відміну від DDS, що представляє собою тільки мова опису даних, один оператор SQL і описує, і створює таблиці і проекції (view). У SQL визначення файла невіддільне від команди створення. Наприклад, оператор SQL «Create table» задає ім'я таблиці, імена стовпців (полів) та їх атрибути. Крім того, при виконанні цього оператора створюється і сама таблиця. Створення фізичних файлів і таблиць Фізичні файли або, в термінології SQL, таблиці містять власне дані. Запис фізичного файлу має фіксований набір полів. Кожне поле може мати (хоча і не часто) змінну довжину. У термінології SQL таблиця містить рядки фіксованої довжини із стовпцями змінної дліни2). Фізичний файл складається з двох частин.

У першій знаходяться атрибути файлу та опису полів. У набір атрибутів файлу входять його ім'я, власник, розмір, кількість записів, ключові поля і деякі інші характеристики. Опису полів задають атрибути для кожного поля записів. Друга частина фізичного файлу містить власне дані. Вона може складатися з одного або декількох розділів, що дозволяють поділяти файл. Усі записи у всіх розділах обов’язково мають один і той же формат. Це зручний спосіб поділу записів: наприклад, інформацію поточного місяця можна помістити в один розділ, а інформацію минулого — в іншій. AS/400. Тепер же вона — основа всієї розробки даних в IBM. Управління сховищем даних Метадані - це дані про дані. Вони використовуються для управління Кожен розділ має унікальне ім'я, яке можна використовувати для доступу до записів. Таблиці SQL можуть складатися тільки з одного розділу, що відповідає самій суті реляційної моделі: всі дані зберігаються в двовимірних таблицях. Файли ж мають декілька розділів — тривимірні. Для створення фізичного файлу використовується системна команда «CRTPF». Вона створює фізичний файл по операторам з вихідного файлу.

Новостворений фізичний файл не містить записів даних, для їх додавання необхідно використовувати окрему програму або утиліту. Як було зазначено раніше, оператор визначення даних SQL також створює таблицю. Оператор «Create table» можна виконати за допомогою Query Manager, Interactive SQL, або вставивши його в програму на МВР. Таблиця, створена цим оператором, є фізичним файлом, ідентичним створеному за допомогою «рідного» інтерфейсу.

Створення логічних файлів і проекцій Логічні файли дають можливість доступу до даних у форматі, відмінному від використовується для їх зберігання в одному або декількох фізичних файлах. Логічні файли забезпечують незалежність даних і програм, яка буде обговорюватися в наступному розділі. Вони не містять записів даних, а лише відносний номер запису (індекс) даних у фізичному файлі. Часто кажуть, що логічний файл задає шлях доступу до даних. Структура логічного файлу може бути як дуже простий, так і дуже складною. Логічні файли і проекції можна підрозділити на чотири категорії. Перерахую їх. Прості логічні файли і проекції, які відображають дані з одного фізичного файлу або таблиці на інший опис логічних записів. Багатоформатний логічні файли, що забезпечують доступ до декількох фізичних файлів, кожен з яких має власний формат записів. Даний тип логічного файлу може бути створений тільки за допомогою «рідного» інтерфейсу; за допомогою SQL його створити не можна. Логічні файли об'єднання (join), що задають одне визначення логічної запису, побудоване з будь-якої комбінації полів двох або більше фізичних файлів, таблиць, логічних файлів або проекцій. При цьому загальне число фізичних файлів і таблиць не повинен перевищувати 32. Проекції SQL (view), які схожі на логічні файли об'єднання і дають ті ж результати, але реалізовані зовсім інакше. Файли об'єднання зберігають шлях доступу для кожного об'єднання. Проекції же SQL визначають шляхи доступу під час виконання, керуючись зберігаються всередині шаблоном визначення запиту (Query Definition Template).

Подібно фізичному, логічний файл складається з двох частин. Перша — точно така ж, як і у фізичної файлу. Вона містить атрибути файлу та опису полів. Друга частина містить відносні номери записів даних фізичної файлу. Програмі, яка використовує логічний файл, видимі тільки ті дані фізичної файлу, які відповідають опису полів логічного файлу. Для створення логічного файлу використовується системна команда «CRTLF». Вона використовує оператори DDS у вихідному файлі для створення логічного файлу. Оператори DDS у вихідному файлі задають імена одного або декількох фізичних файлів, які є основою для логічного. Створений логічний файл містить відносні номери записів даних з одного або декількох фізичних файлів. Оператор SQL «Create view» задає таблицю, подану проекцією, разом з описом стовпців проекції. Результат створення проекції - логічний файл, ідентичний створюваному при використанні «рідного» інтерфейсу. Логічні файли виконують три операції: форматування, включаючи проекцію, об'єднання і створення похідних полів (field derivation); вибірку записів; упорядкування. Логічний файл, створений за допомогою DDS, може здійснювати всі три операції. Файл, створений за допомогою SQL, може виконувати або форматування (проекція SQL), або впорядкування (індекс SQL), але не обидві відразу. На SQL не можна створити проекцій, що виділяють підмножина записів фізичного файлу. Проекція SQL може бути створена за допомогою DDS, але DDS зазвичай не використовується для створення файлів, що мають тільки можливості проекцій SQL. Словник даних і каталоги Опис компонентів всіх фізичних і логічних файлів містяться на кожній AS/400 в одному місці.

У термінах «рідного» інтерфейсу це місце називається словником даних. Словник даних — це спеціальний об'єкт OS/400, який обслуговується менеджером бази даних та до якого можуть звертатися користувачі для пошуку інформації про структуру і місця використання файлів. Менеджер бази даних автоматично оновлює інформацію в словнику даних щоразу при створенні нового об'єкта СУБД. Словник даних дозволяє розробникам додатків і користувачам отримати уявлення про структуру бази даних на будь-якій системі. «Які формати записів?», «Які атрибути даних?», «Де в системі використовується якесь ім'я?» , — За допомогою словника даних можна знайти відповіді на ці та інші питання. В інтерфейсі SQL словник даних називається загальносистемним каталогом. SQL також дозволяє розробникам створювати інші каталоги. Кожна колекція (collection) SQL (бібліотека в «нормальній» термінологією) може (хоч і необяза тельно) мати власний каталог. Незалежність даних і програм Використання комбінації фізичних і логічних файлів в AS/400 дозволяє досягти незалежності програм від використовуваних ними даних. Відділення опису даних від програм досягається тим, що прикладні програми розглядають дані у форматі, відмінному від того в якому вони зберігаються фізично. Концепція відділення програм і даних — одна з основ технологічної незалежності архітектури System/38 і AS/400. Розглянемо структуру фізичного файлу, що містить крім самих даних їх опис, часто зване зовнішнім описом файлу. Як System/38, так і AS / 400 мають зовні описані дані, які не треба поміщати в програму. Це означає, що програма не визначає, як дані повинні фізично зберігатися. Крім того, одна прикладна програма може працювати з файлами, які містять дані в різних форматах.

Формат логічного файлу, так само як і формат фізичного — зовнішній, так що за допомогою логічних файлів можна перевизначити формат запису програми. На малюнку 6.1 показаний дуже простий приклад, який ілюструє деякі функції логічних файлів: використання програмою логічного файлу для отримання іншого уявлення даних фізичної файлу. Рис. 6.1. Незалежність даних і програм Зверніть увагу на виділені поля. Кожна запис фізичного файлу містить шість полів; в той же час програма, за допомогою логічного файлу, «бачить» тільки чотири з них. Можливість виключення полів з логічного файлу дозволяє реалізовувати захист на рівні полів. Користувачі мають доступ тільки до тих полів, які їм дозволено бачити. Це лише один прийом захисту в AS/400 Більш докладно тема захисту розглядається в лекції 7. Інша функція, відображена на малюнку — можливість переупорядоченія полів запису. Порядок проходження в логічній запису полів загального доходу (gross) і федерального прибуткового податку (FIT) змінено на зворотний. Іншими словами, програма незалежна від порядку проходження полів. К рім того, малюнок 6.1 ілюструє перевизначення полів запису. У фізичному файлі полі спільного доходу представляє собою упаковане десяткове число, що містить 7 цифр, дві з яких розташовані праворуч від коми. Однак програма написана так, що поле загального доходу повинно мати зонний десятковий формат з 8 цифрами, дві з яких розташовані праворуч від коми. Логічний файл забезпечує потрібне програмі подання, а також здійснює перетворення між упакованим і зонним десятковим форматами. Використання множинних логічних файлів, побудованих над одним і темже фізичним файлом, надає альтернативні шляхи доступу до даних і забезпечує розподіл даних між програмами. На малюнку 6.2 показаний ще один логічний файл для іншої програми, який був доданий до першого прикладу. Тепер кожна програма має своє уявлення записів, що зберігаються у фізичному файлі, і доступ тільки до тих полів, до яких він дозволений. Поля, присутні в обох логічних файлах, дозволяють програмам спільно використовувати дані. Рис. 6.2. Спільне використання даних Дуже важливо підкреслити, що обидві програми працюють з тими ж самими фізичними даними, — копіювання даних немає. Оновлення даних, виконане однією програмою, стає негайно «мабуть» інший. Ця можливість роботи програм з поточними значеннями даних, а не з копіями, використовується в System/38 і AS/400 протягом уже майже 20 років. Захист даних Отже, логічні файли дозволяють захищати дані на рівні записів і полів. Ми побачили на прикладі, що поля можете захистити, просто не включаючи їх в опис логічного файлу. Розглянуті нами приклади прості, і в них не показана можливість вибірки записів. Досягти захисту на рівні поля можна за допомогою вибірки і пропуску на рівні логічного файлу. В результаті, користувачі отримають доступ тільки до даних, що задовольняє критеріям вибірки. Якщо у користувача немає доступу до какомулібо файлу, то даний файл захищений. Якщо користувач, який не має прав на доступ, наприклад, до загального доходу, спробує запустити програму, яка використовує цей шлях, то програма не буде працювати. Всі логічні і фізичні файли AS/400 — це системні об'єкти, і для доступу до них необхідні відповідні права. Захист даних забезпечується шляхом комбінації логічних файлів і компонента управління доступом операційної системи. Ми можемо надати конкретному користувачу наступні види доступу до будь-якій фізичній файлу: доступ до всього файлу (за допомогою засобів управління доступом); дозволити деякі типи операцій з файлом, наприклад, читання, але не її поновлення (за допомогою засобів управління доступом); доступ до деяких полях (з допомогою логічного файлу); доступ до деяких протоколів (з допомогою логічного файлу). Цілісність та відновлення даних Цілісність даних, що зберігаються в базі вкрай важлива. Між тим, при одночасному читанні і зміні даних багатьма користувачами існує ймовірність їх руйнування. База даних AS/400 надає надійні засоби забезпечення цілісності даних. Засоби відновлення даних необхідні на той випадок, якщо дані все-таки зруйнуються або стануть недоступними. Часто вважають, що таке може статися лише внаслідок апаратних збоїв. У AS/400 є навіть декілька засобів запобігання псування даних при апаратному збої - це так звані засоби забезпечення доступності (availability). Але хоча апаратний збій — найбільш поширена причина псування даних, програми також можуть містити помилки, після яких потрібно відновлення даних. Докладне обговорення цілісності даних та їх подальшого відновлення зажадало б окремої книги. А ми зможемо лише коротко описати кошти, що надаються базою даних AS/400, а також те, як деякі з цих коштів реалізовані апаратно. Журнал Журнал — це хронологічний порядок змін даних, призначена для відновлення попередньої версії набору даних. У AS/400 підтримуються журнали різних типів, у тому числі журнал бази даних. При внесенні зміни до запису журналіруемого файлу бази даних, в журнал поміщається копія запису разом з інформацією, яка описує причину зміни. Ведення записів підтримується двома об'єктами OS/400: журналом і приймачем журналу. Журнал ідентифікує журналіруемие об'єкти, а приймач містить записи журналу. Для гарантії збереження інформації приймачі журналу можуть негайно записуватися на диск. Крім іншого, запис журналу містить наступну інформацію: імена файлу, бібліотеки і програми, відносний номер запису, дату і час зміни; а також ідентифікацію завдання, користувача і робочої станції. Разом з цією інформацією в приймач журналу записується копія зміненої запису. AS/400 може також записати в журнал копію запису перед виконанням зміни. Журнали бази даних використовуються для відновлення, як при збоях системи, так і у випадках помилок в програмах. При аварійній зупинці системи з-за апаратного або програмного збою файли бази даних, для яких вівся журнал, автоматично відновлюються при перезавантаженні і будуть оновлені відповідно до інформації, записаної в приймачах журналу. Якщо програма ввела в файл, для якого ведеться журнал, помилкові дані, то AS/400 може відновити такий файл як прямим, так і зворотним способом. У першому випадку спочатку відновлюється резервна версія файлу, потім до нього застосовуються запису журналу, зроблені до того моменту часу, коли відбувся збій. При зворотному відновленні хибні зміни видаляються з файлу, але для цього в журналі повинні бути копії записів як до, так і після зміни.

Системний захист шляхи доступу SMAPP Минулого користувачі AS/400 були змушені миритися з довгим часом перезавантаження після аварійної зупинки: шляхи доступа1), відкриті для оновлення файлу, повинні були бути побудовані заново. Згадайте, що в лекції 5 ми згадали можливість відкладеної корекції логічного файлу. Внаслідок цього цілісність логічного файлу при аварійній зупинці може порушитися. У залежності від числа і розміру відкритих шляхів доступу по ключу, часовий проміжок, необхідний для їх відновлення, може бути значним, для великих систем — кілька годин. Як ми тільки що говорили, в AS/400 є засоби журналювання, в тому числі і для логічних файлів. Якщо користувач задіє ведення журналу для шляхів доступу, то час перезавантаження системи може бути значно скорочено. Потенційна складність полягає в тому, що користувач повинен спочатку визначити, для яких файлів необхідно вести журнал, оцінити розмір приймачів журналу і дати команду активізації журналювання. Деякі так і роблять, але, на жаль, таких користувачів меншість. Для автоматичного ведення журналу IBM розробила SMAPP (System-Managed Access Path Protection). Система сама обчислює максимальний час, необхідний на відновлення шляхів доступу після збою і відповідно визначає необхідний обсяг журналірованія шляхів доступу. Користувач завжди може збільшити або зменшити обчислене системою час. Чим час менше, тим більше системних ресурсів буде потрібно для ведення журналу. Таким чином, ведення журналу передбачає вибір між системними ресурсами, призначеними для нормальної роботи, і запобіжними заходами на випадок аварійної перезавантаження. Після обчислення або завдання користувачем максимально допустимого часу, система переглядає всі шляхи доступу по ключу, що існують в базі даних; потім обчислює загальний час, необхідний для відновлення всіх цих шляхів. Якщо час перевищує максимально допустимий, то система автоматично починає ведення журналу для окремих шляхів доступу, щоб гарантувати мінімізацію часу на відновлення. SMAPP використовує спеціальну область ведення журналу, що не вимагає дій з боку користувача.

Ця область — циклічна, тобто після досягнення кінця запис триває з початку. Система завжди підтримує в цій області достатня кількість записів. Управління транзакціями Іноді цілісність даних може бути порушена, особливо, якщо з записами фізичного файлу працюють кілька користувачів. Припустимо, що один користувач зчитує запис, збираючись оновити какоето її полі. Що станеться, якщо те ж саме поле запису одночасно оновлює і інший користувач? Якщо другий користувач змінить поле після того, як значення поля лічено першим користувачем, порушиться чи цілісність даних? На щастя, цього не відбудеться, тому що база даних забезпечує захист від паралельного оновлення. Однак, при більш складних варіантах одночасного зміни кількох записів, система не гарантує автоматичного захисту. Припустимо, що необхідно одночасно змінити декілька взаємопов'язаних записів. Часто, для опису такої ситуації використовується приклад з банкоматом. Користувач банківського терміналу запускає транзакцію: вставляє в машину кредитну картку, вводить ідентифікаційний код і вибирає тип транзакції. У результаті цього клієнтська запис зчитується з бази даних центрального комп’ютера, який може розташовуватися на іншому кінці міста або земної кулі. Якщо клієнт запитує видачу готівки, то по вмісту запису перевіряється, чи достатній залишок грошей на рахунку. Потім залишок зменшується на затребувану величину і банкомату посилається команда на видачу грошей. Що якщо трапилася поломка, і банкомат не може видати готівку? Перш ніж ця невдала транзакція завершиться, слід скасувати зміну залишку на рахунку клієнта. Засіб, що використовується для цього в AS/400, — управління транзакціями (commitment control.