Зберігання інформації

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

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

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

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

Сховище даних (ХД - використовують також терміни Data Warehouse, "склад даних", "інформаційне сховище") - це база, що зберігає дані, агреговані за багатьма вимірами. Основні відмінності ХД від БД: агрегування даних; дані з ХД ніколи не видаляються; поповнення ХД відбувається на періодичній основі; формування нових агрегатів даних, залежать від старих - автоматичне; доступ до ХД здійснюється на основі багатовимірного куба або гіперкуба.

Альтернативою сховищу даних є концепція вітрин даних (Data Mart). Вітрини даних - безліч тематичних БД, що містять інформацію, що відноситься до окремих інформаційних аспектів предметної області.

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

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

За відношенню до користувачів застосовують трирівневу уявлення для опису предметної області: концептуальне, логічне і внутрішнє (фізичне) (рис. 4.7).

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

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

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

Ієрархічна модель є різновидом мережевої, що є сукупністю дерев (лісом).

Мал. 4.7. Опис предметної області

Мал. 4.8. Фрагмент предметної бази даних "Збут" і одне з його можливих концептуальних уявлень

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

Подання предметної бази даних "Збут" на логічному рівні для різних моделей показано на рис. 4.9.

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

За найбільш характерними ознаками БД можна класифікувати наступним чином:

за способом зберігання інформації:

• • інтегровані;
• • розподілені;

за типом користувача:

Мал. 4.9. Подання предметної бази даних "Збут" на логічному рівні для різних моделей

• • монопользовательскіе;
• • розраховані на багато користувачів;

за характером використання даних:

• • прикладні;
• • предметні.

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

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

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

• 1. Копійовані дані. Однакові копії даних зберігаються в різних місцях використання, так як це дешевше передачі даних. Модифікація даних контролюється централізовано;
• 2. Підмножина даних. Групи даних, сумісні з початковою базою даних, зберігаються окремо для місцевої обробки;
• 3. Реорганізовані дані. Дані в системі інтегруються при передачі на вищий рівень;
• 4. Секціонірованние дані. На різних об'єктах використовуються однакові структури, але зберігаються різні дані;
• 5. Дані з окремою підсхемою. На різних об'єктах використовуються різні структури даних, що об'єднуються в інтегровану систему;
• 6. Несумісні дані. Незалежні бази даних, спроектовані без координації, що вимагають об'єднання.

Важливий вплив на процес створення БД надає внутрішній зміст інформації. Існує два напрямки:

• • прикладні БД, орієнтовані на конкретні програми, наприклад, може бути створена БД для обліку і контролю надходження матеріалів;
• • предметні БД, орієнтовані на конкретний клас даних, наприклад, предметна БД "Матеріали", яка може бути використана для різних додатків.

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

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

Основні стандарти СУБД:

• • незалежність даних на концептуальному, логічному, фізичному рівнях;
• • універсальність (по відношенню до концептуального і логічного рівнів, типу ЕОМ);
• • сумісність, ненадмірність;
• • безпеку і цілісність даних;
• • актуальність і керованість.

Існують два основних напрямки реалізації СУБД: програмне і апаратне.

Програмна реалізація (надалі СУБД) є набором програмних модулів, працює під управлінням конкретної ОС і виконує наступні функції:

• • опис даних на концептуальному і логічному рівнях;
• • завантаження даних;
• • збереження даних;
• • пошук і відповідь на запит (транзакцію);
• • внесення змін;
• • забезпечення безпеки і цілісності.

Забезпечує користувача наступними мовними засобами:

• • мовою опису даних (МОД);
• • мовою маніпулювання даними (ЯМД);
• • прикладним (вбудованим) мовою даних (ПЯД, ВЯД).

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

• • паралельна обробка;
• • розподілена логіка;
• • асоціативні ЗУ;
• • конвеєрні ЗУ;
• • фільтри даних і ін.

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

Етап концептуального проектування полягає в описі і синтезі інформаційних вимог користувачів в початковий проект БД. Результатом цього етапу є високорівневе представлення інформаційних вимог користувачів на основі різних підходів.

Мал. 4.10. Сукупність процедур проектування БД

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

На етапі фізичного проектування вирішуються питання, пов'язані з продуктивністю системи, визначаються структури зберігання даних і методи доступу.

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

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

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

Моделі додатків можуть бути класифіковані в такий спосіб:

• 1. Програми, що використовують єдиний файл;
• 2. Програми, що використовують кілька файлів, в тому числі:
  • • допускають незалежну паралельну обробку;
  • • допускають синхронізовану обробку.

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

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

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

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

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

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

Призначення складу даних - інформаційна підтримка прийняття рішень, а не оперативна обробка даних. Тому база даних і склад даних не є однаковими поняттями. Архітектура ХД представлена на рис. 4.11.

Основні принципи організації сховищ даних наступні [44,45].

Мал. 4.11. Архітектура ХД

• 1. Предметна орієнтація. В оперативній базі даних зазвичай підтримується кілька предметних областей, кожна з яких може послужити джерелом даних для ХД. Наприклад, для магазину, τορι-ующсго відео- та музичною продукцією, інтерес представляють наступні предметні області: клієнти, відеокасети, CD-диски та аудіокасети, співробітники, постачальники. Явно простежується аналогія між предметними областями ХД і класами об'єктів в об'єктно-орієнтованих базах даних. Це говорить про можливість застосування методів проектування, що застосовуються в об'єктно-орієнтованих СУБД.
• 2. Кошти інтеграції. Приведення різних уявлень одних і тих же сутностей до деякого загального типу.
• 3. Сталість даних. В ХД не підтримуються операції модифікації в сенсі традиційних баз даних. В ХД підтримується модель "масових завантажень" даних, здійснюваних в задані моменти часу за встановленими правилами на відміну від традиційної моделі індивідуальних модифікацій.
• 4. Хронологія даних. Завдяки засобам інтеграції реалізується певний хронологічний тимчасової аспект, властивий вмісту ХД.

Основні функції репозитаріїв:

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

Розглянемо коротко основні напрямки наукових досліджень в області баз даних:

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