14610

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

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

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

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

Украинкский

2013-06-08

335.55 KB

6 чел.

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

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

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

на тему:

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


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

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

Парадигма для реляційних даних в сховищі даних (парадигма корпоративної інформаційної фабрики КІФ – Corporate Information Factory, CIF) розроблена Інмоном і передбачає, що дані повинні перебувати на низькому рівні ступені деталізації і в третій нормальній формі (3НФ, 3NF).

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

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

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

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

3НФ підхід дозволяє ґранулювати деталізовані та інтеґровані дані, забезпечивши максимальну гнучкість для опрацювання даних.

Білл Інмон також радить, щоб сховище даних містило корпоративно найвищий ґранульований рівень даних. Тоді структура і вміст сховища даних не підпорядковуватимуться вимогам будь-якого відділу, але натомість обслуговуватимуть вимоги корпорації.

На рис. 1 поданий підхід, що використовується у сховищах даних з архітектурою CIF.

Рис 1. Нормалізоване сховище даних із просторовими вітринами підсумкових даних (CIF).

Колись цей підхід був відомий за назвою корпоративного сховища даних (КСД) (enterprise data warehouse, EDW) або проектування сховища даних знизу вверх. Робота такого сховища починається зі скоординованого отримання даних із джерел. Після цього завантажується реляційна база даних із третьою нормальною формою, що містить атомарні дані. Нормалізоване сховище використовується для того, щоб наповнити інформацією додаткові репозиторії презентаційних даних, тобто даних, підготовлених для аналізу. Ці репозиторії, зокрема, включають спеціалізовані сховища даних для вивчення і видобування даних (Data Mining), а також вітрини даних.

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

Наведемо приклад корпоративного сховища даних.

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

Рис. 2. Сховище даних з архітектурою корпоративної фабрики.

Як відмітні характеристики підходу Білла Інмона до архітектури сховищ даних можна назвати наступні.

1.Використання реляційної моделі організації атомарних даних і просторової - для організації сумарних даних.

2. Використання ітеративного або «спірального» підходу при створенні більших сховищ даних, тобто «будівництво» сховища даних не відразу, а по частинах (рис. 8.3). Це дозволяє, при необхідності, вносити зміни в невеликі блоки даних або програмних кодів і рятує від необхідності перепрограмовувати значні обсяги даних у сховищі. Те ж саме можна сказати й про потенційні помилки: вони також будуть локалізовані в межах порівняно невеликого масиву без ризику зіпсувати все сховище.

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

4. Сховище даних – це проект корпоративного масштабу, що охоплює всі відділи й обслуговує потреби всіх користувачів корпорації.

5. Сховище даних – це не механічна колекція вітрин даних, а фізично цілісний об'єкт.

Рис. 3. Ітераційне розроблення сховища даних за методом знизу вверх.

Хід роботи

Предметна область – База даних сайту BetBattles.

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

Користувачі

Ставки

Матчі

Типи матчів

Результати

Групи користувачів

Об‘єкт «Користувачі» зберігатиме інформацію про користувача ресурсу, його логін, хеш пароля, е-мейл, дату реєстрації тощо. «Ставки» - інформація про ставки, зроблені користувачами, на який матч, який прогнозований результат. «Матчі» - інформація про матчі, що відбулися, чи мають відбутися – це команди, які братимуть участь, дата матчу, тип матчу. «Типи матчів» - інформація про те, до якого турніру відноситься матч. «Результати» - тут зберігатимуться результати матчів, котрі відбулися, а також прогнозовані користувачами результати матчів. «Групи користувачів» - це групи всередині яких користувачі можуть змагатися між собою, для груп можуть бути обрані різні матчі для прогнозування, кожен користувач може брати участь одночасно в багатьох групах.

Створимо такі 9 таблиць :

User – дані про користувача;

Bet – зроблені ставки;

Match – матчі, які відбулися, або які заплановані;

Result – результати матчів, а також прогнозовані результати;

MatchType – опис типу матчу;

Group – інформація про групу користувачів;

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

GroupMatchTypeTicket – таблиця для реалізації зв’язку багатодобагатьох між групою та типом матчів (наприклад для того, щоб обрана група змагалася на лише на матчах Ліги чемпіонів, чи Чемпіонату Іспанії).

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

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

Діаграма 1. Діаграма «Сутність-зв'язок» для розроблюваної БД

На базі створеної діаграми побудуємо даталогічну модель бази даних (діаграма 1).

Діаграма 1. Діаграма даталогічна модель для розроблюваної БД


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

create database BetBattles;

go

create table [BetBattles].[dbo].[Users](

[UserId] integer not null IDENTITY(1,1),

[Login] nvarchar(20) not null,

[PasswordHash] nvarchar(32) not null,

[PasswordSault] nvarchar(5) not null,

[E-Mail] nvarchar(30) not null,

[RegistrationDate] Date not null,

[Rate] integer not null,

primary key(UserId)

);

go

create table [BetBattles].[dbo].[Results](

[ResultId] integer not null IDENTITY(1,1),

[Score1] integer not null,

[Score2] integer not null,

primary key(ResultId),

);

go

create table [BetBattles].[dbo].[MatchTypes](

[MatchTypeId] integer not null IDENTITY(1,1),

[Description] nvarchar(50) not null,

primary key(MatchTypeId),

);

go

create table [BetBattles].[dbo].[Matches](

[MatchId] integer not null IDENTITY(1,1),

[MatchTypeId] integer null,

[ResultId] integer null,

[Command1] nvarchar(20) not null,

[Command2] nvarchar(20) not null,

[Date] Date not null,

primary key(MatchId),

CONSTRAINT fk_MatchMatchType FOREIGN KEY (MatchTypeId) REFERENCES [MatchTypes](MatchTypeId),

CONSTRAINT fk_MatchResult FOREIGN KEY (ResultId) REFERENCES [Results](ResultId)

);

go

create table [BetBattles].[dbo].[Bets](

[BetId] integer not null IDENTITY(1,1),

[UserId] integer not null,

[MatchId] integer not null,

[ResultId] integer not null,

[IsReleased] bit not null

primary key(BetId),

CONSTRAINT fk_BetUser FOREIGN KEY (UserId) REFERENCES [Users](UserId),

CONSTRAINT fk_BetMatch FOREIGN KEY (MatchId) REFERENCES [Matches](MatchId),

CONSTRAINT fk_BetResult FOREIGN KEY (ResultId) REFERENCES [Results](ResultId)

);

go

create table [BetBattles].[dbo].[Groups](

[GroupId] integer not null IDENTITY(1,1),

[Name] nvarchar(30) null,

[Start] Date null,

[Finish] Date null,

primary key(GroupId),

);

go

create table [BetBattles].[dbo].[GroupUserTickets](

[GroupUserTicketId] integer not null IDENTITY(1,1),

[GroupId] integer not null,

[UserId] integer not null,

[UserRateInGroup] integer not null,

primary key(GroupUserTicketId),

CONSTRAINT fk_guGroup FOREIGN KEY (GroupId) REFERENCES [Groups](GroupId),

CONSTRAINT fk_guUser FOREIGN KEY (UserId) REFERENCES [Users](UserId)

);

go

create table [BetBattles].[dbo].[GroupMatchTickets](

[GroupMatchTicketId] integer not null IDENTITY(1,1),

[GroupId] integer not null,

[MatchId] integer not null,

primary key(GroupMatchTicketId),

CONSTRAINT fk_gmGroup FOREIGN KEY (GroupId) REFERENCES [Groups](GroupId),

CONSTRAINT fk_gmMatch FOREIGN KEY (MatchId) REFERENCES [Matches](MatchId)

);

go

create table [BetBattles].[dbo].[GroupMatchTypeTickets](

[GroupMatchTypeTicketId] integer not null IDENTITY(1,1),

[GroupId] integer not null,

[MatchTypeId] integer not null,

primary key(GroupMatchTypeTicketId),

CONSTRAINT fk_gmtGroup FOREIGN KEY (GroupId) REFERENCES [Groups](GroupId),

CONSTRAINT fk_gmtMatchType FOREIGN KEY (MatchTypeId) REFERENCES [MatchTypes](MatchTypeId)

);

Результат виконання

Створена база даних та її таблиці зображені на рисунку 1.

Рис. 1. Створена база даних та її таблиці

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

Діаграма 2. Діаграма створеної бази даних. Згенерована СУБД

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


 

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

32903. Философия Жизни в19 в 12.41 KB
  Философия Жизни в19 в. В середине 19 века создается эволюционная концепция жизни. Именно в это время возникает иррационализм который к концу 19 века оформляется в отдельную школу – Философию жизни. Этот целостный поток жизни необъясним в рамках рационализма позитивизма механицизма т.
32905. Фрейдизм 14.38 KB
  Первый: создание концепции бессознательного конец XIX века до 1920 года когда на основе экспериментальных данных он делает вывод о существовании в психике каждого человека достаточно четко выраженных структурных образований которые характеризуются как сознание предсознание и бессознательное. Наиболее существенная разработка этого периода динамическая концепция психики человека включающей такие структуры как Оно Я и сверхЯ. Оно кипящий котел инстинктов рождающий все последующие противоречия и трудности человека. Структура Я...
32906. Религия 12.49 KB
  religio благочестие набожность святыня предмет культа это мировоззрение и мироощущение а также соответствующее поведение и специфические действия культ которые основываются на вере в существование одного или нескольких богов и сверхъестественного мира. отображения мира в сознании человечества.
32907. Русская философия 11.7 KB
  Ее феноменальность заключается в том что русская философия развивалась исключительно автономно самостоятельно независимо от европейской и мировой философии не находилась под влиянием многочисленных философских направлений Запада – эмпиризма рационализма идеализма и др.Характерными чертами русской философии являются:сильная подверженность религиозному влиянию особенно православию и язычеству;специфическая форма выражения философских мыслей – художественное творчество литературная критика публицистика искусство;целостность...
32908. Философия средневековой Руси 10-17вв 12.88 KB
  Философия средневековой Руси 1017вв В истории отечественной философской мысли выделяют несколько периодов: первый философская мысль Древней Руси X – XVII вв. Первый период в истории отечественной философской мысли характеризуется полным преобладанием религиозной мысли. На формирование мысли средневековой Руси заметное влияние оказала патристика особенно учения представителей Каппадокийской школы: В. Формирование и развитие отечественной философской мысли не прерывалось в годы монгольского ига а в XV – XVII веках философская мысль...
32909. Философские дискуссии западников и славянофилов 15.17 KB
  Философские дискуссии западников и славянофилов Первыми представителями органической русской философии были Западники и Славянофилы. Славянофилы противопоставляли Восток Западу оставаясь в философских религиозных историкофилософских воззрениях на русской почве признавая и высоко ценя западноевропейскую культуру философию. Истинное противостояние славянофильства Западу заключено в различном подходе к пониманию основ русской и западноевропейской жизни. Западничество и славянофильство две противоположные но и вместе с тем взаимосвязанные...