Повна версія

Головна arrow Інформатика arrow Бази даних: проектування

  • Увеличить шрифт
  • Уменьшить шрифт


<<   ЗМІСТ   >>

Моделювання квазіструктурірованних даних

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

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

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

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

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

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

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

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

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

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

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

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

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

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

image272

Мал. 4.61. Приклад простий квазіструктури

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

Іншими прикладами об'єктів, які можуть описуватися подібним чином, є:

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

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

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

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

Однією з істотних проблем застосування квазіструктурірованной інформації є визначення типу даних, які повинні зберігатися в якості значення, що вводиться користувачем. Найбільш універсальним є використання символьних типів даних, але тин даних "Character" не дозволить зберегти дані великих розміром. Щоб це зробити, в сутність "Властивості категорій товарів" додається ще одне поле, яке характеризується типом "CLOB", що позначає зберігання великих текстових даних [1] .

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

Додавання нової сутності "Тип даних властивостей" дозволяє визначитися з правилами обробки даних, представлених символьним типом даних (рис. 4.64). Важливо звернути увагу на атрибут цієї сутності "Код тип даних". Такий атрибут дуже часто зустрічається в базах даних, визначаючи абревіатурне незмінне значення, яке характеризує певний екземпляр даних. Оскільки екземпляр даних описується зазвичай на національній мові і може змінюватися при зміні мови, то повинен бути якийсь атрибут, який не буде залежати від національної мови. Таким атрибутом вказують шифр або код типу даних, який формується і визначається розробником.

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


Мал.  4.63.  Модель квазіструктури з ієрархічно пов'язаними властивостямиimage273



image274

Мал. 4.64. Модель квазіструктури з типізацією властивостей



image275

Мал. 4.65. Приклад зв'язку квазіструктури з реляційної структурою



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

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

  • - Для обробки даних необхідно однозначно визначити правила типізації даних і реалізовувати обробку значень відповідно до певних правил (наприклад, якщо значення можуть бути різних типів і передбачається обмежити користувачеві роботу в частині правильності внесених значень, то необхідно створити додаткову сутність "Тип даних", пов'язану з сутністю "Властивості");
  • - При обробці квазізначеній, пов'язаних з класифікаторами або таблицями реляційної бази даних, необхідно по суті "Значення" або по суті "Властивості" визначити атрибути, які вкажуть, де знаходяться необхідні дані. Додатково це обмеження вимагає від розробника чіткості в іменуванні сутностей, що забезпечують зберігання даних класифікаторів і зв'язок.

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

  • [1] У різних інструментальних засобах тип даних дня зберігання великих текстових даних може відрізнятися і представляється варіантами: CLOB. Text і т.д.
 
<<   ЗМІСТ   >>