14610

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

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

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

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

Украинкский

2013-06-08

335.55 KB

7 чел.

Лабораторна робота № 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. Діаграма створеної бази даних. Згенерована СУБД

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


 

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

23879. Послание архиепископа новгородского Василия ко владыке тверскому Федору о рае 26.5 KB
  Послание о земном рае читается в Софийской первой и Воскресенской летописях под 1347гСвое послание Василий пишет в Тверьузнав о распревозникшей среди тверичей по вопросу о существовании раяСущют 2 представляения о рае:рай находится на землев другом мирекак духовное понятиесугубо мысленноеВасилий убеждает Федора в сущ.нигде не сказаночто земной рай погибон создан богома все дела божьинетленныв Иерусалиме видел калиткукот не двигается с тех поркак Иисус ее претворил не до концаесть ад на земленовгородские ватаги видели вход в...
23880. Сказание об Индийском царстве 27 KB
  Сказание рисует сказочный образ далекой Индии.все о чем человек может мечтать в повседневной жизниобеспеченностьбогатсвообилие всего вокругуверенность в настоящем и будущемвсе это представлено в сказочнопреувеличенном видеИоанн пишетчто он царь над царямии ему подченено 3300царейцарские палаты грандиозны и с земными не могут вступать в сравнениеинд царство населяют не только обычные людино и самые невероятные человеч существарогатыетрехногиемногорукие и тдфантастичен животный мирв Индии есть все и при это нет ни тятяворани...
23881. Литературно-этикетный канун жития. Житие Феодосия Печерского 29 KB
  Житие Феодосия Печерского.Житие ФЕОДОСИЯ ПЕЧЕРСКОГОПмятник древнерусской литературы написанный преподобным Нестором Летописцем.Одним из древнейших русских монастырей был киевопечерскийбольшую роль в истории монастыря сыграл его постриженика затем игуменФеодосийПамятник рассказывает о жизни игумена КиевоПечерского монастыря преподобного Феодосия начиная от его рождения прихода в монастырь до игуменства и смерти.Житие Феодосия Печерского типичное монашеское житие рассказ о благочестивом кротком трудолюбивом праведнике вся жизнь...
23882. Творчество Епифания Премудрого. Житие Стефана Пермского 22.5 KB
  Житие Стефана ПермскогоЕпифаний родился в Ростове в первой половине 14века.Перу Епифания принадлежат 2 жития:Житиве Стефана Пермского и Житие Сергия Радонежского.доводит литературноэтикетный канон до совершенствау него 2ой этапа 1ый этапутверждение канонаЖития Феодосия Печерского и Алексияпышность языкамножество ярких деталейндивид стильЕпифаний неск раз определяет характер писательского труда как плетение словессближение звуковой формы слова и его смыслаМножество повторовпричастных оборотовритмика речитрадиционные метафорыЕпиф...
23883. Творчество Епифания Премудрого.Житие Сергия Радонежского 26.5 KB
  На сороковой день мальчика принесли в церковь крестили и дали ему имя Варфоломей. Они быстро научились грамоте а Варфоломей не мог. Варфоломей рассказал ему о своих неудачах в учебе и попросил помолиться о нем. Старец дал отроку кусок просфоры и сказал что отныне Варфоломей будет даже лучше знать грамоту чем его братья и сверстникитак потом все и будетмотив исполнения желания Мальчик уговорил священника зайти к его родителям.
23884. Хождение за три моря Афанасия Никитина 55 KB
  Билет 36Билет 38Повесть о Петре и ФевронииПовесть о ПиФ была написана в 16 векев век второго монументализма хотя по содержанию и духу она ближе к 15 веку веку русского предвозрождения когда осознавалась ценность человека единство человека и Бога. Жена так и сделала и змей проговорился: Смерть мне суждена от Петрова плеча и от Агрикова мечаБыл у Павла брат Петр и он согласился помочь точнее ему на роду написано сразиться со змеем но где найти Агриков меч они не знают. Один раз Петр в одиночестве пришел в церковь и отрок показал...
23885. Повесть о Горе Злочастии 28.5 KB
  Обобщенная судьба герояДобрый молодец Добрый молодец отказывается от родовой позиции хочет жить своим умом.представляениям только он может менять личинуДобрый молодец верит архангелу все пропиваетснова беден. ЧЕРТЫ лит повести: писалось когда РусьРоссия Родовая позиция уходитмолодец хочет жить своим умом Столкновение этих 2ух позиций Гуманистическая концепцияноваторствосочувствие падшему человеку Появляются: элементы психологизации характеровсочувствие падшему человеку ощущение непостоянства жизни и ее непрочности Боязнь...
23886. Повесть о Савве Грудцыне 27.5 KB
  Месть брошенной женщиныварит зельесавва выпивает и влюбляется и начинает ее домогаться. Савва заболеваетхочет исповедоватьсяно бес не отпускает егоа Савва не хочет отдавать ему душуЭпизод с царством Сатаны:золотой дворец и крылатые юноши вокруг него. Автор сочувствует: Бедныйбедный Савва.
23887. Повесть о Фроле Скобееве 23.5 KB
  Повесть о Карпе Сутулове Сюжет:ЖенаТатьяна. Жена организует свой позор самостоятельно.Воевода велит им выплатить штраф:50010001500половину себе забирает а вторую отдает Татьяны Жена стоит на позции своим умом комическая повесть автор смеется над героями и над Татьяной Сатирическому обличению подвергается распутное поведение духовенства и именитого купечества.