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

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


 

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

65378. Діагностика вірусних інфекцій пшениці за дії абіотичних чинників 174.5 KB
  Для одержання стабільних валових зборів зерна в Україні важливе значення має наявність сортів озимої пшениці з високим адаптаційним потенціалом до несприятливих чинників довкілля. Тому актуальним є вивчення вмісту...
65379. МЕХАНІЗМ ОЦІНЮВАННЯ ДЕРЖАВНОГО УПРАВЛІННЯ ЗА ЧИННИКОМ ЛЮДСЬКОГО ВИМІРУ 198.5 KB
  На європейському шляху розвитку України найбільш актуальними напрямами є подальша демократизація країни принципова зміна відношення до людини в суспільстві не тільки визначення її у всіх правових та програмних документах як найбільшої суспільної цінності...
65380. ФОРМУВАННЯ ІНФОРМАТИЧНИХ КОМПЕТЕНТНОСТЕЙ МАЙБУТНІХ ВЧИТЕЛІВ ІНФОРМАТИКИ У ПРОЦЕСІ НАВЧАННЯ МЕТОДІВ ОБЧИСЛЕНЬ 238 KB
  Більшість науковців схиляються до ідей компетентнісного підходу в оцінюванні результатів навчання формування компетентностей на основі сучасних досягнень науки і техніки. Сьогодні розробляються стандарти та моделі підготовки фахівців...
65381. Формування високопродуктивних агроценозів багаторічних трав при залуженні орних земель вилучених із обробітку в південному Степу 4.66 MB
  Обґрунтувати теоретичні засади сучасного ландшафтноекологічного стану сільськогосподарських угідь південного Степу та розробити в умовах природного зволоження без зрошення енергоощадні технології створення високопродуктивних агрофітоценозів...
65382. Удосконалення технології обробки стебел безнаркотичних конопель 542 KB
  Наукові дослідження з вивчення властивостей і хімічного складу волокна конопель показали, що воно має високі показники гігроскопічності, повітропроникності, антибактеріальні, гігієнічні та антиелектростатичні властивості.
65383. ІНДИВІДУАЛІЗАЦІЯ ПРОФЕСІЙНОЇ ПІДГОТОВКИ МАЙБУТНІХ ФАХІВЦІВ ШВЕЙНОГО ПРОФІЛЮ 147.5 KB
  Сучасні соціально-економічні перетворення в державі призвели до необхідності переосмислення ідей індивідуалізації, її сутності та можливостей у забезпеченні життєвого, професійного, особистісного самовизначення майбутнього фахівця...
65384. РОЗРОБКА МІКРОПРОЦЕСОРНОГО КЕРУВАННЯ МАТРИЧНИМИ СВІТЛОДІОДНИМИ ВИПРОМІНЮВАЧАМИ 177.5 KB
  Основною причиною великих енергозатрат на освітлення є низький коефіцієнт корисної дії ККД сучасних лампових джерел світла який складає декілька відсотків. За останнє десятиліття розроблені світлодіодні джерела світла ККД яких досягає 80.
65385. УПРАВЛІННЯ ПРОЦЕСОМ ФОРМУВАННЯ ВРОЖАЙНОСТІ ЗЕРНА ПРОСА ПОСІВНОГО 1.49 MB
  Важливим є глибоке вивчення управління сортовими особливостями асиміляційного апарату рослин проса шляхом поєднання абіотичних і біотичних факторів та елементів технології вирощування на продуктивність рослин...
65386. РЕПРЕЗЕНТАЦІЯ ЧАСУ В СОЦІОЛОГІЇ 144.5 KB
  Представники різних наук, які, так чи інакше, підходять до проблематики часу відчувають раціональну потребу об’єднати зусилля у його подальшому вивченні. Спроби співставити і порівняти різні тлумачення часу що пропонують фізики і біологи, геологи і екологи, психологи і логіки...