Семантичний інструмент побудови баз даних

1. Прикладом інструменту для побудови баз даних і додатків, який покликаний підвищити зручність проектування...
2. Семантичне розширення реляційної моделі
3. Забезпечення динаміки систем
4. Оперативні і аналітичні системи
5. Універсальна інструментальне середовище
6. що маємо
7. література
8. Переваги та недоліки систем баз даних
9. реляційні системи
10. Приклади використання qWORD-XML

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

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

Семантичне розширення реляційної моделі

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

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

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

qWORD-XML ґрунтується на розширеній реляційної моделі даних RM / T [1], семантично більш повної, ніж базова реляційна модель. RM / T була запропонована Тедом Коддом в 1979 році для розширення семантичних аспектів реляційної моделі і підтримує певну атомарному і молекулярну семантику. Перша представляється n-мірними відносинами (в крайньому випадку бінарними), які є мінімальними смисловими одиницями, а друга - смисловими одиницями, великими n-мірних відносин. RM / T підтримує чотири виміри молекулярної семантики: декартову агрегацію, узагальнення, агрегацію покриття і передування подій. Характеристична агрегація і узагальнення можуть бути описані деревовидної структурою, а асоціативна агрегація і агрегація покриття - горизонтальними зв'язками між об'єктами. Таким чином, в RM / T, по суті, пропонується введення молекулярної структури (дерева з горизонтальними зв'язками) поверх атомарної структури (n-мірного відносини).

Логіко-математичний апарат ієрархічної бази даних з горизонтальними зв'язками в загальному випадку набагато складніше, ніж в реляційної базі даних. У RM / T для реалізації зв'язків між об'єктами використовуються спеціальні графові відносини, відповідно передбачається спеціальний набір операцій маніпулювання такими відносинами. Тому в операційному плані RM / T орієнтована на програмістів, а не на користувачів, але в структурному плані більш природна і інтуїтивно зрозуміла.

Через свою складність RM / T не отримала свого часу широкого поширення, але поява і розвиток платформи XML уможливило формальний опис ієрархічної моделі з горизонтальними зв'язками. Причиною повернення до ієрархічної моделі даних (у варіанті XML) стало більш природне для людини відображення семантики предметної області. У моделі даних XML допустимими структурами є дерева, вузли яких - елементи, що володіють атрибутами і вмістом. Для адресації в дереві елементів використовується мова XPath, в якому передбачається впорядкованість елементів дерева. Горизонтальні зв'язки між елементами можуть бути визначені за допомогою мов XLink і XPointer. Для запитів по дереву елементів служить мову XQuery, а для перетворення структури дерева елементів - мова XSLT. Об'єктна модель документа DOM включає в себе набір низькорівневих операцій маніпулювання вузлами документа.

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

Забезпечення динаміки систем

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

Для XML-документів можуть бути використані різні мови опису схем, наприклад XDR, XML Schema, Relax NG, Schematron. Деякі мови підтримують відкриту модель інформаційного наповнення, що дозволяє додавати в XML-документ елементи і їх атрибути, що не були попередньо описані в задекларованої схемою документа. Отже, застосування моделі даних XML дозволяє модифікувати схему даних не тільки в процесі створення бази даних, але і під час її експлуатації.

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

Фактично, в qWORD-XML ієрархічна модель даних в варіанті XML накладається поверх реляційної, що дозволяє, з одного боку, зберегти строгість реляційної моделі, а з іншого - привнести в неї додаткову молекулярну семантику [2]. Таким чином, забезпечується поєднання достоїнств реляційної і дореляціонних моделей.

Ієрархія моделюється як дерево інформаційних об'єктів зі специфічним для даного об'єкту набором понять ( «реквізитів»). Об'єкти відповідають елементам XML-документа, а поняття - атрибутам елементів. З іншої точки зору об'єкти відповідають реляційним відносин, а поняття - атрибутам відносин ( Мал. 1 ).

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

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

Горизонтальні зв'язки об'єктів можна отримувати за рахунок застосування однакових значень понять в різних об'єктах. Можливість описувати віртуальні і посилальні об'єкти дозволяє створювати відображення ієрархії, що не відповідає спроектованому дереву.

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

Мінливість даних в часі враховується за рахунок підтримки системою динамічних зв'язків між елементами даних ( Мал. 3 ). Такі зв'язки можуть бути описані за допомогою мов XLink і XPointer. Розглянемо приклад бази даних (рис. 3а). Громадянам видаються документи, в яких є посилання на адреси їх реєстрації. Якщо адреса змінюється, то для раніше створеного документа повинна зберігатися посилання на правильну адресу.

При погляді на базу з точки зору прикладного значення даних документів об'єкти повинні розташовуватися так, як показано на рис 3б. Для створення такого відображення об'єкт «Адреса» описується як контрольний, і для нього встановлюється прапор «Виробляти динамічну корекцію». В цьому випадку відбувається шляхом зміни примірника «Адреса» система буде автоматично створювати і модифікувати для примірника «Документ» значення поняття прямого зв'язку з екземпляром «Адреса».

Наприклад, нехай код примірника об'єкта «Громадянин» дорівнює AAAА. При створенні екземпляра «Документ» йому присвоюється код AAAА | АА. При створенні екземпляра «Адреса» йому присвоюється код AAAА | А, а в поняття прямого зв'язку примірника «Документ» автоматично записується значення А (додаток до коду примірника «Громадянин», що дозволяє отримати код примірника «Адреса», на який посилається даний екземпляр «Документ »). Тепер, припустимо, створюється новий екземпляр «Документ» AAAА | АВ. Якщо «Адреса» не змінюється, то в поняття прямого зв'язку цього примірника «Документ» автоматично записується значення А (рис. 3в). При модифікації «Адреси» автоматично створюється його новий екземпляр AAAА | B, в який копіюються незмінені значення понять з примірника AAAА | А. У поняття прямого зв'язку примірника «Документ» AAAА | АВ записується значення В, а значення поняття прямого зв'язку примірника «Документ» AAAА | АА не змінюється (рис. 3г).

Оперативні і аналітичні системи

На практиці підприємства використовують дві окремі бази даних: з оперативними даними (транзакційні системи, OLTP), призначену для підтримки поточної діяльності організації, і з аналітичними даними (системи підтримки прийняття рішення, DSS), призначену для підтримки прийняття рішень. Ці системи різняться за умовами функціонування і вимогам до ресурсів. OLTP-системи зазвичай характеризуються жорсткими вимогами до продуктивності, передбачуваним рівнем загального навантаження і високим коефіцієнтом використання. DSS, навпаки, зазвичай варіюються за вимогами до продуктивності, рівень їх навантаження непрогнозіруем і їм з непередбачуваною регулярністю доводиться обробляти великі обсяги даних. За допомогою qWORD-XML можлива реалізація як оперативних, так і аналітичних інформаційних систем.

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

М - процедурний мову програмування без жорсткої парадигми, який стандартизований ISO, ANSI і FIPS. Головним достоїнством М-систем є ефективний механізм управління зовнішньою пам'яттю у вигляді B * -дерев, які на логічному рівні представляються через глобальний - збережені на диску і розсортовані по строковим індексам масиви довільної розмірності. Пам'ять в масиві займають лише ті елементи, для яких визначено значення. Координація доступу до глобальних змінних в багатокористувацької середовищі здійснюється за допомогою блокувань; М підтримує обробку транзакцій і мережеве взаємодія. На цій мові можуть бути реалізовані всі відомі моделі даних. Разом з тим M - це перш за все мова розробки СУБД, а не роботи з ними.

Як надбудови над М-системою можуть використовуватися СУБД Cache? компанії InterSystems або GT.M компанії Sanchez Computer Associates. Ці СУБД мають всі характеристики промислових систем, такі як висока продуктивність, надійність, масштабованість, відкритість і переносимість. Ще один важливий фактор - вартість рішення. М-системи можуть служити основою для реалізації оперативних і аналітичних систем, оскільки задовольняють основним вимогам до таких систем: висока продуктивність і ефективна обробка транзакцій для OLTP-систем, ефективне зберігання і обробка великих обсягів даних, високий рівень безпеки даних для DSS-рішень.

Cache? - комерційний продукт, а GT.M має відкриту архітектуру, реалізація якої в версії для платформи x86 / Linux вільно розповсюджується разом з вихідними кодами. За своїм вбудованим інструментальним можливостям GT.M поступається Cache ?, але завдяки відкритості системи можлива реалізація власних інтерфейсів.

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

Універсальна інструментальне середовище

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

Інструментальне середовище qWORD-XML являє собою універсальний браузер, реалізований на Delphi як клієнтську програму до M-сервера. В універсальному браузері взаємодія з базою даних здійснюється через екранні форми, що описують або все дерево об'єктів, або його частину у вигляді, зручному для конкретного робочого місця. Відображення складається в загальному випадку з дерева об'єктів, дерева примірників об'єктів і панелей інструментів (рис. 4). База даних проектується візуально як набір взаємопов'язаних об'єктів.

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

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

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

Розглянемо, наприклад, аналітичну обробку, сенс якої полягає в угрупованні та узагальненні даних. Угруповання зазвичай виконується відповідно до багатьох критеріями. Аналітична обробка можлива всередині одного відображення (рис. 5). Перед виконанням аналітичної обробки можна організувати попередній пошук даних по об'єктах і значенням їх понять. Для завдання пошукових умов використовується колонка «Умова». Результати виводяться у вигляді різних графічних зображень, перехресної таблиці або екранної форми.

Розглянемо запит, націлений на розподіл документів по організаціям (складам бюро), в яких видані документи, і по підлозі громадян, яким видано документи. Завдання аналітичного запиту встановлюється спеціальними маркерами A, D, Y в рядках, відповідних аналізованих ознаками. Колонка A призначена для позначки понять, значення яких будуть використані в якості індексів аналітичного зрізу. Можливо завдання відразу декількох аналітичних зрізів (A1, A2 і т.д.). В даному випадку ми задали зріз A1 за кодами організацій, а A2 - по полам.

Колонка D призначена для позначки понять, значення яких будуть застосовуватися як обчислювані агреговані значення аналітичного зрізу. В даному випадку маркером D також позначено поняття «код організації», оскільки нам потрібно просто отримати кількість документів. В колонках Num, Sum, Min, Max, Mid за допомогою маркера Y вибираються необхідні агрегує функції: кількість значень, їх сума, мінімальне / максимальне значення, їх середнє арифметичне. Колонка «Аналітика» призначена для опису виразів перетворення значень з Аi і D до їх агрегування.

що маємо

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

література

1. Кодд Е.Ф. Розширення реляційної моделі для кращого відображення семантики. // СУБД, 1996, № 5.
2. Веселов В., Долженков А. Досвід побудови XML-СУБД // Відкриті системи, 2002 № 6.

Анатолій Долженков ( [email protected] ) - директор з науки компанії «СП. АРМ », Дмитро Тимофєєв ( [email protected] ) - аспірант Інституту інформатики і автоматизації РАН (Санкт-Петербург).

Переваги та недоліки систем баз даних

Дореляціонние системи (ієрархічні та мережні)

Преимущества

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

Недоліки

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

реляційні системи

Преимущества

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

Недоліки

• Примітивність типів даних стає причиною обмежень застосовності реляційної моделі в нетрадиційних областях (наприклад, САПР), в яких потрібні складні структури.
• Можливості опису семантики предметної області мінімальні. Реляційна база даних являє собою сукупність взаємопов'язаних відносин, для яких повинні підтримуватися обмеження цілісності даних.

Приклади використання qWORD-XML

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

Інформаційно-аналітична система органів соціального захисту населення суб'єкта федерації. Завдання системи пов'язані з реалізацією перекладу всіх фахівців органів соціального захисту на новий рівень інформаційної підтримки з формуванням відомчої «інформаційної вертикалі» і поетапним створенням єдиного інформаційного простору соціальної сфери суб'єкта федерації.

Автоматизована інформаційно-довідкова і аналітична система «Реабілітаційний відновлювальний центр». Типовий комплекс для підтримки інформаційних потоків і баз даних, що використовуються в реабілітаційних установах.

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