14612

Проектування логічної структури сховища даних з архітектурою зведення даних

Лабораторная работа

Информатика, кибернетика и программирование

7 Лабораторна робота № 3 з дисципліни: Технології сховищ даних на тему: Проектування логічної структури сховища даних з архітектурою зведення даних Мета роботи: Вивчення порядку методів та засобів проектування і побудови сховища даних з ар...

Украинкский

2013-06-08

181.48 KB

9 чел.

7

Лабораторна робота № 3

з дисципліни:

«Технології сховищ даних»

на тему:

«Проектування логічної структури сховища даних з архітектурою зведення даних»

Мета роботи: Вивчення порядку, методів та засобів проектування і побудови сховища даних з архітектурою зведення даних та оцінка часу виконання запитів.

Теоретичні відомості

Зведення даних (Data Vault) (ЗД) – предметно орієнтована, історична і унікально зв'язана множина нормалізованих таблиць, які підтримують одну або більше функціональних предметних областей. Це – гібридний підхід, що поєднує кращі особливості 3-ої нормальної форми (3НФ) і схеми «зірка».

У лабораторінй роботі № 1 подано ориґінальну 3НФ модель, пристосовану до архітектури сховищ даних. Одна особливо складна проблема очевидна, коли значення часу-дати розміщена в первинному ключ таблиці батька (див рис. 1).

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

Рис 1. Використання часу у 3НФ.

Тому подальшим розвитком була схема «зірка», яка вимагала денормалізації, але водночас була краще пристосована до виконання аналітичних завдань. Модель «зірка» добре працює для швидкого подання багатовимірної інформації для певних груп кінцевих користувачів. Її перевагами є: багатовимірний аналіз, сумарні звіти (графи, пошук мінімуму, максимуму, зміна рівнів аґреґування). Проте, як виявилося, така модель не є гнучкою, оскільки її структура є незмінною, жорстко форматованою. Також вона не здатна забезпечити статистичний аналіз.

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

Зведення даних передбачає певну нормалізацію даних, що видозмінена для потреб сховищ даних. Ця архітектура використовує такі модельовані методи: зв’язок багато-до-багатьох, цілісність зв’язків, мінімально надмірні набори даних. Ці методи роблять модель зведення даних гнучкою, поширюваною і послідовною.

На рис. 2 подано модель зв’язків між сутностями предметної області «Торговельна фірма», яка дозволяє перейти до моделі СД зведення даних.

Рис. 2. Схема зведення даних.

Компоненти зведення даних

Є мінімальний ряд компонентів архітектури зведення даних:

  1.  центральна таблиця (Hub) – моделює первинний ключ певної ґранули, тобто є центром зірки,
  2.  таблиця зв’язку (Link entities) – сутність, що є зв’язком між екземплярами Hub,
  3.  таблиці-супутники (Satellite entities) – забезпечують описовий контекст для відповідного екземпляра Hub або Link.

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

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

  1.  Business key – первинний ключ об’єкту певної ґранули описуваної зірки,
  2.  Surrogate key – суроґатний ключ, номер стрічки; використовується тоді, коли певний об’єкт описується декількома рядками,
  3.  Load Date time stamp – дата появи запису в контенті сховища даних,
  4.  Record source – запис про систему, звідки прийшов business key.

Таблиця зв’язку моделює зв'язок багато-до-багатьох на фізичному рівні між двома або більше центральними таблицями. Має наступні атрибути:

  1.  Hub1…HubN key – зовнішні ключі таблиць центрів,
  2.  Surrogate key – суроґатний ключ, номер стрічки; використовується тоді, коли описуються більше ніж два центри і неможливо однозначно визначити унікальний рядок  у зв’язку з повторами значень зовнішніх ключів,
  3.  Load Date time stamp – дата, коли зв'язок вперше був відображений у сховищі даних,
  4.  Record source – запис про систему, звідки прийшов зв'язок.

Таблиці-супутники містять описовий контекст екземплярів Hub або Link. Опис може змінюватися з часом і така сутність повинна вміти зберігати нові або змінені дані. Має обов'язкові атрибути:

  1.  первинний ключ Hub або первинний ключ Link – ключі відповідних екземплярів,
  2.  Load Date time stamp – дата, коли з’явився описовий контент,
  3.  Sequence surrogate number – номер стрічки для сутностей, які мають множинні значення або для організації в підгрупи,
  4.  Record source – запис про початкову систему.

Наявність таблиць центів (Hub) та таблиць зв’язків (Link) дозволяють зменшити розрідженість даних, яка виникає внаслідок багатовимірного подання інформації.

Також одним із підвидів ЗД є матрична методологія, яка розширена ще однією таблицею Малюнок (Picture) для фіксації історичності даних та історичності зв’язків. Приклад матричної методології до проектування сховищ даних подано на рис. 8.3.

Проектування на основі зведення даних передбачає такі етапи.

  1.  Моделювання Hub. Передбачає виявлення сутностей проблемної області.
  2.  Моделювання Links. Виявлення можливих взаємозв'язків між сутністю, транзакціями та процесами функціонування, що є в проблемній області.
  3.  Моделювання Satellites. Виявлення описового контенту як для сутностей – Hubs, так і для транзакцій – Links, що об’єднують сутності.

Рис. 8.3. Схема матричної ЗД.

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

Проектування за методологією ЗД вимагає дотримання таких правил.

  1.  Первинні ключі таблиць-центрів не можуть міститися в інших екземплярах таблиць центів.
  2.  Зв'язок між центрами відображається за допомогою Link.
  3.  Link повинен містити не менше двох зовнішніх ключів таблиць-центрів.
  4.  Link може використовуватися для зв'язку більше двох таблиць-центрів.
  5.  Link може посилатися на інший екземпляр Link.
  6.  Surrogate keys (номери стрічок) можуть бути присутніми в Hub і Link.
  7.  Таблиці-супутники можуть описувати як Hub, так і Link.
  8.  Таблиці-супутники повинні містити дату завантаження інформації або посилання на окрему таблицю дат.
  9.  Таблиці-супутники фіксують тільки зміни, в них немає повторів рядків, дані групуються за вмістом і частотою змін.

Перед перетворенням сховища даних з іншою архітектурою в архітектуру з використанням ЗД необхідно дослідити наявні структури даних:

  1.  незалежні таблиці – не перетворюються, копіюються повністю,
  2.  чи визначені відношення первинних-зовнішніх ключів,
  3.  чи використовуються в моделі номери стрічок – якщо використовуються, необхідно заново наповнити дані,
  4.  чи можна класифікувати інформацію за класом або типом даних,
  5.  наскільки часто змінюються атрибути.

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

Зведення даних може застосовуватись для різних предметних областей. Маленький список можливостей поданий нижче.

  1.  Динамічні сховища даних – побудовані на динамічних автоматизованих змінах, що виконуються як до процесу, так і до структури в межах сховища.
  2.  Сховища дослідження – дозволяється споживачам керувати структурами сховища даних без втрати вмісту.
  3.  Застосування «брудних» даних – дозвіл використовувати історичні та неочищені дані для видобування даних (штучного інтелекту).
  4.  Швидке з'єднання зовнішньої інформації – здатність швидко зв'язати і пристосувати структури, щоб внести зовнішню інформацію і відобразити це в межах сховища даних без руйнування наявного вмісту.

Хід роботи

  1.  Додамо користувачів у таблицю Users. Результат виконання зображений на рисунку 1:

use BetBattles

go

Одиничне додавання:

insert into Users([Login], [E-Mail], RegistrationDate, PasswordHash, PasswordSault, IsAdmin)

values ('admin', 'adminBetBattles@gmail.com', GETDATE(), 'qwertyuiopasdfghjklzxcvbnmlkjhgf', 123, 1);

go

Групове додавання:

insert into Users([Login], [E-Mail], RegistrationDate, PasswordHash, PasswordSault, [IsAdmin])

values ('admin2', 'admin2BetBattles@gmail.com', GETDATE(), 'q1wertyigoasdfghjklzxcvbnmlkjhgf', 123, 1),

 ('user1', 'ololo@mail.ru', GETDATE(), '627ertyuihjgsdfhjklxcfgtimlkjhgf', 89, 0),

 ('Chuck', 'chuck@google.com', GETDATE(), '787er93ihjgsdfgklzfxcutimlkjhgf', 42, 1);

go

Рис.1. Таблиця Users після виконання додавання

  1.  Створимо файли з даними для таблиць Groups та Matches. Використовуючи настпуні скрипти додамо дані до таблиць. Результати виконання представлені на рисунку 2.

BULK

INSERT Groups

FROM 'D:\NULP\4Kurs2semestr\SUBD\groups.db'

WITH

(

FIELDTERMINATOR = '\t',

ROWTERMINATOR = '\n'

)

GO

BULK

INSERT Matches

FROM 'D:\NULP\4Kurs2semestr\SUBD\matches.db'

WITH

(

FIELDTERMINATOR = '\t',

ROWTERMINATOR = '\n'

)

GO

Рис.2. Таблиці Groups та Matches з доданими даними

Рис.3. Змінена таблиця Users

  1.  У таблиці Users замінимо всіх користувачів адміністраторів на звичайних користувачів, а користувачів не адміністраторів, а також змінимо всі логіни на жартівливі. Результати зміни даних у таблицях представлені на рисунку 3:

use BetBattles

go

UPDATE Users

SET IsAdmin = 1 - IsAdmin;

UPDATE Users

SET Login = Login + 'BetWarrior';

Рис. 4. Результат зміни даних у таблиці Users

  1.  З таблиці Matches видалимо всі матчі, що відбувалися 25 лютого та раніше. Результати представлені на рисунку 4:

use BetBattles

go

delete from Matches

where Date<='2012-02-25'

Рис. 4. Таблиця Matches після видалення даних

Висновок: Під час виконання даної лабораторної роботи, я вивчив порядок, методи та засоби проектування і побудови сховища даних з архітектурою зведення даних та способи оцінки часу виконання запитів.


 

А также другие работы, которые могут Вас заинтересовать

24734. ПИТАНИЕ ДЕТЕЙ ПЕРВОГО ГОДА ЖИЗНИ. Искусственное и смешанное вскармливание 97 KB
  Слайд 2 Причины перевода ребенка на ИВ: гипо менее 1 5 суточного объема или агалактия у матери; самовольный перевод матерью ребенка на ИВ; противопоказания со стороны матери для лактации; отсутствие у ребенка матери; противопоказания со стороны ребенка врожденные нарушения обмена веществ галактоземия фенилкетонурия и т. Причины перевода ребенка на ИВ: гипо менее 1 5 суточного объема или агалактия у матери самовольный перевод матерью ребенка на ИВ противопоказания со стороны матери для лактации отсутствие у ребенка матери...
24735. Внутриутробное инфицирование 204.5 KB
  Слайд 1 Роль плацентарного барьера в развитии внутриутробного инфицирования: фетоматеринские трансфузии развиваются более чем в 50 всех беременностей; трансплацентарный пассаж эритроцитов наблюдается уже в четвертойвосьмой неделе гестации; эмбриопатии патология плода 3 10 нед беременности заканчивается либо гибелью эмбриона либо формированием врожденных пороков развития; при инфицировании в ранний фетальный период до 28 нед. беременности чаще возникает гипотрофия плода с низкой массой тела при рождении; при позднем инфицировании...
24737. Перечислить и дать характеристику основным причинам сложности программного обеспечения. Общие признаки любой сложной системы; приемы борьбы со сложностью ПО 328 KB
  Модульность это представление системы в виде совокупности обособленных сегментов связь между которыми обеспечивается посредством связей между классами определяемыми в этих сегментах. Ещё бывает динамический полиморфизм при котором реализация функциичлена класса выбирается в зависимости от фактического типа указателя на объект через который она вызывается. Общее понятие класса языка С. Синтаксис описания класса.
24738. Теория языков программирования и методы трансляции 233.96 KB
  Если синтаксический анализ предназначен для распознавания и проверки правильности различных конструкций языка с точки зрения их синтаксиса структуры то семантический анализ предназначен для контроля этих конструкций с точки зрения их смыслового содержания. Фаза генерации кода предназначена для перевода промежуточной программы на машинный язык мы будем предполагать коды Ассемблера. Языки...
24739. Системы искусственного интеллекта. Модель логики предикатов первого порядка 418.5 KB
  Задаваемые при описании формальной системы правила вывода называют также правилами вывода заключений т. Различают два типа правил вывода. Правила вывода. Правила вывода устанавливают отношения на множестве формул исчисления высказываний.
24740. Линейные списки – стеки, очереди, деки. Набор процедур для работы со связанным стеком, очередью 1.08 MB
  Способы обхода бинарного дерева. Древовидная структура это конечное множество содержащее один или более узлов n такое что: 1 имеется один специально обозначенный узел называемый корнем данного дерева. Линия связи между парой узлов дерева называется обычно ветвью. Те узлы которые не ссылаются ни на какие другие узлы дерева называются листьями или терминальными вершинами рис.
24741. English Speaking Countries 17.49 KB
  The Commonwealth of Australia territories are the continent of Australia the island of Tasmania and number of smaller islands. Australia has an area of nearly eight million square kilometres. The population of Australia is over sixteen million people.
24742. Outstanding people of Russia Federation 16.41 KB
  The names of Russian scientists and writers poets composers and painters are worldfamous Pushkin Lermontov Chehov Levitan. It is almost impossible to name a branch of science in the development of which the Russian scientists haven't played the greatest role. Works of our Russian writes and poets are translated into many languages.