лучшие книги по экономике
Главная страница

Главная

Замовити роботу

Последние поступления

Форум

Создай свою тему

Карта сайта

Обратная связь

Статьи партнёров


Замовити роботу
Книги по
алфавиту

Б
В
Г
Д
Е
Ж
З
И
К
Л
М
Н
О

Основи інформаційних систем

Страницы [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ]
[ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ] [ 32 ]
[ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ 48 ] [ 49 ] [ 50 ]

6.8. Побудова логічної моделі даних
Наступним кроком, який виконується після нормалізації відношень є побудова логічної моделі БД.
Логічна модель є основою бази даних, вона повинна відображати взаємозв’язки між реляційними таблицями. Між реляційними таблицями можуть бути наступні типи зв’язків 1:1, 1:Б та Б:Б. Найбільш поширеним зв’язком є зв’язок 1:Б. Зв’язок 1:1 зустрічається рідше, тому що дані між якими існує такий тип зв’язку в переважній більшості випадків входять до складу однієї реляційної таблиці. Зв’язок Б:Б безпосередньо не підтримується в реляційних СУБД. Для реалізації такого зв’язку необхідно створювати додаткову реляційну таблицю, яка буде відігравати роль зв’язкової. Зв’язкова таблиця має обов’язково містити первинні ключі таблиць, між якими встановлюється зв’язок.
Деякі сучасні СУБД мають інструментальні засоби побудови логічної моделі даних. Розглянемо побудову такої моделі засобами СУБД Mіcrosoft Access. Логічна модель в середовищі СУБД Mіcrosoft Access називається схемою. Для побудови схеми даних попередньо необхідно створити таблиці, визначивши в них первинні ключі. Приклад схеми, побудованої засобами Access наведено на рис. 6.5.


Рис. 6.5. Схема бази даних
На цій схемі відображені зв’язки між таблицями реляційної БД. Між усіма таблицями встановлений зв’язок типу 1:Б (знак ? позначає в Access багато).
Зв’язок встановлюється між полем первинного ключа об’єкт­ного відношення та полем вторинного ключа зв’язкового відношення. Зв’язок між полем первинного та полем вторинного ключа встановлюється, якщо поля задані одним типом і подані в одному форматі.
Схема в Access забезпечує за змовчування посилкову цілісність та узгодженість даних, які зберігаються в різних таблицях. Так, наприклад, Access не дозволить дозаписати в таблицю «Реалізація» дані про реалізацію виробу якомусь споживачу, якщо дані про цей виріб та відповідного споживача відсутні в таблицях «Виріб» та «Довідник споживачів». Крім того, якщо користувач системи зробить спробу вилучити дані про якісь вироби чи про певних споживачів з таблиць довідкової інформації «Виріб» та «Довідник споживачів» тоді, коли дані про ці вироби та про споживачів занесені до таблиць «Реалізація» та «Договір», то Access повідомить користувача про те, що вилучення відповідних рядків, що пропонується до вилучення, головної таблиці неможливе, так як йому є відповідні записи у підпорядкованих таблицях.
6.9. Поняття сховищ даних
та основи їх створення
Різновидом баз даних є сховище даних (Data WarenHouse). Поняття сховищ даних виникло зовсім недавно. Необхідність розробки нової концепції сховищ даних обумовлена такими факторами:

  • Розвиток інформаційних технологій привів до систем нового типу, які дістали назву систем підтримки прийняття рішень. Ці системи основані на новій технологіі, яка дістала назву OLAP-техно­логії. Основою OLAP-технології є реалізація аналітичних запитів.
  • Системи підтримки прийняття рішень, основані на формуван­ні аналітичних запитів, почали конфліктувати з транзакційними системами оперативної обробки даних (OLTP- системами). Одночасне вирішення оперативних і аналітичних запитів на одній базі даних часто призводить до нестачі ресурсів.
  • Формування аналітичних звітів на основі традиційних баз даних, які вміщують оперативну інформацію, займає дуже багато часу. Причому витрати часу, необхідні для формування аналітич­них звітів, невпинно зростають зі зростанням обсягів оперативної інформації в базі даних. Це призводить до того, що менеджери не встигають готувати відповідні рішення на основі отриманих аналітичних звітів.
  • Дуже часто на підприємстві чи в організації функціонує декілька OLTP-систем, кожна з яких має свою окрему базу даних, в яких використовуються різні структури даних, способи кодування, одиниці вимірювання. Побудова зведеного аналітичного запиту на основі декількох баз даних є дуже складною проблемою, яка спочатку потребує вирішення проблеми узгодженності даних, що зберігаються в різних базах даних.

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

Рис. 6.6. Схема взаємозв’язку OLTP та OLAP систем
Таким чином сховище даних (Data WarenHouse) це особлива форма організації бази даних, котра призначена для зберігання в погодженому вигляді агрегованої інформації, що отримується на основі баз даних різних OLTP-систем та зовнішніх джерел.
Сховища даних характеризуються предметною орієнтацією, інтегрованістю, підримкою хронології, незмінністю і мінімальною надлишковістю. Ці основні особливості сховищ даних були виз­начені в 1992 році їх винахідником Біллом Інмоном (Bіll Іnmon). Вони незалежно від реалізації притаманні всім сховищам даних і полягають ось у чому.

  • Предметна орієнтація. Дані в сховищі даних організовані у відповідності до основних напрямків діяльності підприємства чи фірми (замовники, продажі, склад і т.п.). У цьому полягає відмінність сховищ даних від організації оперативної БД, в якій дані пода­ються у відповідно до процесів (відвантаження товару, виписка рахунків і т.п.) Предметна організація даних не лише спрощує аналіз, а й значно прискорює проведення аналітичних розрахунків. Тобто сховища орієнтовані на бізнес-поняття, а не на бізнес процеси.
  • Інтегрованість. Первинні дані оперативних баз даних перевіряються, певним чином добираються, приводяться до одного виду, необхідною мірою агрегуються ( тобто обраховуються сумарні показники) і завантажуються у сховище даних. Такі інтегровані дані набагато простіше аналізувати.
  • Підтримка хронології. Дані, які вибираються з оперативних баз даних нагромаджуються в сховищі даних у вигляді «історичних пластів», кожен із яких характеризує певний період часу. Це дозволяє проводити аналіз зміни показників у часі.
  • Незмінність. Дані сховища даних, що характеризують кожен «історичний пласт», ні в якому разі не підлягають змінам. Це теж є суттєвою відмінністю даних, що зберігаються у сховища даних, від оперативних даних. Оперативні дані можуть дуже часто змінюватись, з даними сховища можливі лише операції їх первинного завантаження, пошуку та їх читання.
  • Мінімальна надлишковість. Незважаючи на те, що інформація до сховищ даних завантажується з БД OLTP-систем, це не призводить надлишковості даних. Зведення до мінімуму надлишковості даних забезпечується тим, що перш ніж завантажувати дані до сховищ, їх фільтрують і певним чином очищають від таких даних, які не потрібні і не можуть бути використані в OLAP-системах.

6.9.1. Архітектура сховищ даних
Сховища даних можуть включати такі компоненти: віртуальне сховище даних, корпоративне сховище даних, кіоски чи вітрини даних.
Віртуальне сховище даних — це репозитарій метаданих, які описують джерела надходження інформації, структуру даних сховища, методи агрегації та завантаження даних, відомості про структуру бізнес-понять та інші дані про дані, що зберігаються у сховищі.
Корпоративні сховища даних (enterprіse data warehouses) вміщують інформацію, зібрану із певної множити оперативних БД, яка характеризує всю корпорацію і необхідна для виконання консолідованого аналізу діяльності корпорації в цілому. Такі сховища охоплюють всі численні напрямки діяльності корпорації і використовуються для прийняття як тактичних та і стратегічних рішень. Розробка корпоративного сховища даних дуже трудоміст­кий процес, який може становити від одного до кількох років, а обсяги сховища можуть досягати від 50 Гбайт до кількох терабайт.
Кіоски чи вітрини даних (data marts)це певна підмножина кор­поративних даних, які характеризують конкретний аспект діяльності корпорації, наприклад роботу якогось її підрозділу. Кіоск може отримувати дані з корпоративного сховища даних (залежний кіоск) чи бути незалежним, і тоді джерелом поповнення його даними будуть оперативні БД. Розробка кіоска даних потребує значно менше часу і в середньому триває близько трьох-чотирьох місяців.
Корпоративні сховища даних та кіоски будуються за подібними принципами і використовують практично одинакові технології.
В останні часи з’явилось поняття глобального сховища даних, в якому сховище даних розглядається як єдине джерело інтегрованих даних для всіх вітрин даних.
6.9.2. Моделі сховищ даних
Сховища повинні надавати можливість параметризації даних за різними ознаками, наприклад банківські операції під час їх аналізу необхідно групувати за часом їх виконання, за клієнтами, за їх обсягами у вартісному виразі, за контрагентами, видами валют та іншими ознаками. Тобто дані мають бути представлені у сховищі таким чином, щоб надавати можливість їх багатовимірного аналізу. Основи багатовимірного аналізу були започатковані Е.Ф. Коддом (E. F. Codd) в 1993 р.
Найбільш вдалою формою представлення даних, що надасть можливість багатовимірної їх параметризації є подання даних у вигляді неплоскої реляційної моделі, а багатовимірної моделі. В основу OLАP-систем покладено поняття гіперкуба, тобто багатовимірного куба, у комірках якого зберігаються необхідні для аналізу дані.
Проте нині існує три варіанти побудови систем на основі сховищ даних: MOLAP (Multіdіmensіonal OLAP), ROLAP (Relatіonal OLAP) і HOLAP (Hybrіd OLAP). В MOLAP-системі гіперкуб реалізується як спеціальна модель нереляційної структури, яка швид­ше забезпечує доступ до даних, ніж реляційні моделі, але вимагає додаткових витрат пам’яті.
В ROLAP — системах гіперкуб це лише користувацький інтерфейс, який моделюється на традиційній реляційній базі даних. Дані в сховищі представляються у вигляді моделі, що дістала назву «зірка» (star schema). Ця модель складається з таблиць двох типів: однієї таблиці даних, що аналізуються, тобто фактів (fact table) — центр зірки і декількох таблиць, які характеризують пев­ні виміри цих фактів (demensіon table). Таблиця фактів вміщує числові характеристики якогось напрямку діяльності компанії чи фірми, наприклад обсяги продажу, а також ключі таблиць вимірів. Таблиці вимірів містять додаткові характеристики ключових полів, як правило, це довідкові дані, наприклад дані про назву товару, назву його виробника, тип товару та інші. Зауважимо, що дані таблиць вимірів денормалізовані.
Якщо ж таблиці вимірів нормалізовані, то така модель називається «сніжинкою» (snowflake schema). В ROLAP– системах зберігаються агреговані дані.
Такий підхід дозволяє зберігати великі обсяги даних, але вони не досить ефективні при виконанні аналітичних операцій, тому системи, побудовані на реляційних моделях, розглядаються швид­ше як інтелектуальні генератори звітів. Але досі ці системи пе-
реважають так, як в реляційні моделі вкладені великі інвестиції
і вони є більш зрозумілими і звичними.
HOLAP-системи — це комбінований варіант зберігання даних, який використовує обидва типи СУБД. У багатовимірній СУБД зберігаються агрегати даних, а докладні дані, які мають невеликий обсяг, зберігаються в реляційній СУБД.


 Запитання для самоперевірки

    • Дайте визначення поняття машинної бази даних та характеризуйте її структуру.
    • Схарактеризуйте недоліки файлових структур даних та передумови розробки концепції БД.
    • Схарактеризуйте поняття і класифікацію АБД.
    • Визначте які компоненти входять до складу АБД та стисло схарактеризуйте основні з них.
    • Мовні засоби АБД їх призначення та характеристика.
    • Перелічіть та стисло схарактеризуйте основні рів­ні подання даних в базі даних.
    • Схарактеризуйте особливості побудови реляційної моделі БД.
    • Які обмеження накладає реляційна модель на БД?
    • Що таке нормалізація реляційних відношень? Які переваги має нормалізована БД?
    • Дайте визначення першої нормальної форми.
    • Дайте визначення другої нормальної форми.
    • Дайте визначення третьої нормальної форми.
    • Дайте визначення четвертої нормальної форми.
    • Дайте визначення оптимальної логічної моделі БД та характеризуйте правила її побудови.
    • Дайте визначення поняття сховища даних та його призначення.
    • Схарактеризуйте особливості сховищ даних та його відмінності від бази даних.
    • Схарактеризуйте основні моделі побудови сховищ даних.

Страницы [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ]
[ 16 ] [ 17 ] [ 18 ] [ 19 ] [ 20 ] [ 21 ] [ 22 ] [ 23 ] [ 24 ] [ 25 ] [ 26 ] [ 27 ] [ 28 ] [ 29 ] [ 30 ] [ 31 ] [ 32 ]
[ 33 ] [ 34 ] [ 35 ] [ 36 ] [ 37 ] [ 38 ] [ 39 ] [ 40 ] [ 41 ] [ 42 ] [ 43 ] [ 44 ] [ 45 ] [ 46 ] [ 47 ] [ 48 ] [ 49 ] [ 50 ]


ВНИМАНИЕ! Содержимое сайта предназначено исключительно для ознакомления, без целей коммерческого использования. Все права принадлежат их законным правообладателям. Любое использование возможно лишь с согласия законных правообладателей. Администрация сайта не несет ответственности за возможный вред и/или убытки, возникшие или полученные в связи с использованием содержимого сайта.
© 2007-2022 BPK Group.