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

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


 

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

37297. МЕТОД ПРОЕКЦИЙ. Центральные проекции и их основные свойства. 902.5 KB
  Перпендикуляр к плоскости перпендикулярен любой прямой проведенной в этой плоскости. Плоскости перпендикулярны если прямая принадлежащая одной плоскости перпендикулярна другой плоскости. Если прямая линия параллельна прямой лежащей в плоскости то она параллельна этой плоскости.
37298. Теория обучения и воспитания 481 KB
  Методические рекомендации и план освоения учебной дисциплины 13 Описание учебнометодического комплекса дисциплины Теория обучения и воспитания 15 Виды учебной работы 16 Тематический план курса 16 8. Задачи: Вооружить студентов системой научных знаний о сущности и особенностях процессов обучения воспитания и развития; Раскрыть потенциалы образовательной среды и ее возможные модификации для обеспечения качества образования; Активизировать развитие у студентов профессиональнопедагогического мышления умения видеть и анализировать...
37299. Перехідна характеристика об’єкта керування 101.5 KB
  Користуючись теоремою розкладення та стандартною функцією перетворення Лапласа розрахувати та побудувати перехідні характеристики об'єкта керування. Перехідну характеристику ht будуємо за допомогою стандартної операції зворотного перетворення Лапласа програмного середовища Mthcd. Спочатку знаходимо перетворення за Лапласом вихідної величини hp Задаємо початкові умови: Знайдемо перехідну функцію за допомогою теореми розкладення. Спочатку знаходимо перетворення за Лапласом...
37300. Общие требования к курсовой работе (для юридических дисциплин) 190 KB
  Структура и содержание курсовой работы Тема курсовой работы избирается студентом исходя из его интересов и согласовывается с научным руководителем. После утверждения темы студентом разрабатывается план работы который также должен быть согласован с научным руководителем. В дальнейшем при написании работы студенту рекомендуется обсуждать с руководителем наиболее принципиальные и спорные вопросы темы. Структура и содержание курсовой работы должны в полной мере раскрывать избранную тему.
37301. Физиология центральных и периферических эндокринных органов 57.54 KB
  Все процессы жизнедеятельности организма строго согласованы между собой по скорости, времени и месту протекания. В организме человека эту согласованность на периферии осуществляют внутриклеточные и межклеточные механизмы регуляции, важнейшую роль в которых играют гормоны.
37302. Инженерный анализ моделей технических систем с помощью MathCAD 72.5 KB
  Освоить программу MathCAD и получить практические навыки ее использования при инженерном анализе моделей технических систем.
37303. Провести анализ напряженно-деформированного состояния конструкции балочного типа с заданным поперечным сечением, при статическом нагружении 512 KB
  Ввод координат 2 Задание материала Для задания характеристик материала выберем пункт меню Model= Mteril Модель= Материал. Рисунок 2 Задание материала и его свойств Для сохранения введенного материала в библиотеке нажмем кнопку Sve ответив при этом утвердительно на запрос о подтверждении занесения Ст. Рисунок 3 Выбор типа конечных элементов Нажмем кнопку Shpe Форма для задания формы и размеров поперечного сечения балки. Рисунок 4 Задание формы поперечного сечения балки Выберем из списка Shpe сечение Chnnel C Section...
37305. Проектирование усилительного устройства, цифрового устройства 968.5 KB
  Усилитель напряжения УН усиливает входной сигнал до необходимого уровня. Действующее значение напряжения: .4 Выбор и расчёт усилителя напряжения Каскад УН строим на базе инвертирующего усилителя.2 Инвертирующий усилитель напряжения на ОУ 1.