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

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


 

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

7167. Фінансовий ринок. Класифікація структурних складових фінансового ринку 179.5 KB
  Фінансовий ринок Фінансовий ринок як механізм міжгалузевого перебігу капіталу, та перерозподілу коштів. Функції фінансового ринку. Класифікація структурних складових фінансового ринку. Фондовий ринок. Фінансові інститут...
7168. Інфляція та грошові реформи 1.08 MB
  Інфляція та грошові реформи Суть інфляції. Теоретичні концепції інфляції. Основні форми інфляції. Основні показники вимірювання інфляції. Методи регулювання інфляції. Грошові реформи: поняття та цілі. Класиф...
7169. Економічні потреби і виробничі можливості суспільства. Економічні інтереси 125.5 KB
  Економічні потребиі виробничі можливостісуспільства. Економічні інтереси План 1. Виробничі можливості суспільства і продукт виробництва 2. Виробничий потенціал і межа виробничих можливостей 3. Економічні потреби суспільства. Закон зроста...
7170. Економічна система суспільства 79 KB
  Економічна система суспільства План 1. Сутність і основні структурні елементи економічної системи 2. Продуктивні сили як матеріальна основа економічної системи 3. Економічні відносини як соціальна форма і спосіб організації економічної системи. Екон...
7171. В чем заключаются сущность и принципиальные различия между либеральной, консервативной и социалистической идеологиями 61.08 KB
  В чем заключаются сущность и принципиальные различия между либеральной, консервативной и социалистической идеологиями? Либерализм (либеральная идеология) - учение и общественно-политическое течение, содержащее установку на обеспечение свободы л...
7172. Охорона праці. Методичні вказівки до дипломної роботи 73.49 KB
  Питання наукової організації праці, культури виробництва, ефективності та якості праці нерозривно пов'язані з умовами й охороною праці. Хоч насиченість сучасного виробництва найновітнішою технікою служить...
7173. Теоретичні основи впровадження рейтингової системи педагогічного контролю у процес професійної підготовки майбутніх фахівців з фізичного виховання 289 KB
  Теоретичні основи впровадженнярейтингової системи педагогічного контролюу процес професійної підготовкимайбутніх фахівців з фізичного виховання ЗМІСТ Вступ Розділ І. Аналіз літератури 1.1. Кваліметрія знань як компонент концепції н...
7174. Проверка поведения, ее теоретические основы и ее практическое выполнение 114 KB
  Рудольф Менцель Проверка поведения, ее теоретические основы и ее практическое выполнение I РАЗДЕЛ: Принципиальное наблюдение за поведением защитно-караульной собаки Введение Выращивание — это формирование определенных форм в живом мире. Заводчи...
7175. Металлургия черных металлов. Учебное пособие по дипломному проектированию 2.01 MB
  Введение Во второй части пособия авторы представили методику расчета количества рабочих и ИТР, показан пример расчета фонда заработной платы, расчет себестоимости продукции, дан расчет показателей экономической эффективности проектируемо...