Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
бази даних
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
КН
Кафедра:
Не вказано
Інформація про роботу
Рік:
2024
Тип роботи:
Звіт до лабораторної роботи
Предмет:
Архітектура
Частина тексту файла (без зображень, графіків і формул):
МІНІСТЕРСТВО ОСВІТИ І НАУКИ
НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ „ЛЬВІВСЬКА ПОЛІТЕХНІКА”
Кафедра ІСМ
/
Звіт до лабораторної роботи №2
Проектування логічної структури сховища даних з архітектурою
шини
Львів-2014р.
Тема бази даних: олімпійські ігри London 2012.
Мета: Вивчення порядку, методів та засобів проектування і побудови сховища даних з
архітектурою шини та оцінка часу виконання запитів.
Теоретичні відомості
Є різні варіанти фізичної реалізації архітектури шини. Простіший варіант моделі – «зірка» (star schema) подає собою радіальну схему, у центрі розміщена головна таблиця фактів, що аналізуються, та пов’язаних з нею таблиць вимірів, що вміщують довідкову інформацію. Така схема оптимізується під найбільш поширені запити, тому реляційні таблиці вимірів можуть бути ненормалізованими.
Якщо таблиці вимірів нормалізовані, то така модель називається «сніжинкою» (snowflake schema). Модель даних складається з двох типів таблиць: однієї таблиці фактів (fact table) – центр «зірки», і декількох таблиць вимірів (dimension table) за кількістю вимірів в моделі даних – проміння «зірки».
Сховище даних з архітектурою шини, або підхід Ральфа Кімбола, або Просторове Сховище [61]. У цій моделі первинні дані перетворяться в інформацію, придатну для використання, на етапі підготовки даних. При цьому обов'язково приймаються до уваги вимоги до швидкості опрацювання інформації і якості даних. Як і в моделі Білла Інмона, підготовка даних починається зі скоординованого добування даних із джерел. Ряд операцій відбувається централізовано, наприклад, підтримка і зберігання загальних довідкових даних, інші дії можуть бути розподіленими.
Область подання просторово структурована, при цьому вона може бути централізованою або розподіленою. Просторова модель сховища даних містить ту ж атомарну інформацію, що й нормалізована модель, але інформація структурована по-іншому, щоб полегшити її використання й виконання запитів. Ця модель включає як атомарні дані, так і узагальнювальну інформацію (аґреґати у зв'язаних таблицях або багатомірних кубах) відповідно до вимог продуктивності або просторового розподілу даних. Запити в процесі виконання звертаються до усе нижчого рівня деталізації без додаткового перепрограмування з боку користувачів або розроблювачів застосування.
На відміну від підходу Білла Інмона, просторові моделі будуються для обслуговування бізнес- процесів (які, у свою чергу, пов'язані з бізнес-показниками або бізнес-подіями), а не бізнес-відділів. Наприклад, дані про замовлення, які повинні бути доступні для загалькорпоративного використання, вносяться в просторове сховище даних тільки один раз, на відміну від КІФ-підходу, у якому їх довелося б тричі копіювати у вітрини даних відділів маркетинґу, продажів і фінансів. Після того, як у сховищі появляється інформація про основні бізнес-процеси, консолідовані просторові моделі можуть видавати їхні перехресні характеристики. Матриця корпоративного сховища даних з архітектурою шини виявляє й підсилює зв'язок між показниками бізнес-процесів (фактами) і описовими атрибутами (вимірами).
Підсумовуючи все вищевикладене, можна відзначити типові риси підходу Ральфа Кімбола.
Використання просторової моделі організації даних з архітектурою «зірка» (star scheme) – детальніше розглянуто далі.
Використання дворівневої архітектури, що включає стадію підготовки даних, недоступну для кінцевих користувачів, і сховище даних з архітектурою шини як таке. До сховища входять кілька вітрин атомарних даних, кілька вітрин аґреґованих даних і персональна вітрина даних, але воно не містить одного фізично цілісного або централізованого сховища даних.
Сховище даних з архітектурою шини має наступні характеристики:
воно просторове;
воно містить як дані про транзакції, так і сумарні дані;
воно містить вітрини даних, що описують тільки одну предметну область або мають тільки одну таблицю фактів (fact table);
вітрини даних додаються у міру необхідності;
воно може містити безліч вітрин даних у межах однієї бази даних.
Сховище даних не є єдиним фізичним репозиторієм (на відміну від підходу Білла Інмона). Це «віртуальне» сховище.
Хід роботи
Створення схеми сховища даних з архітектурою зірка.
Створення таблиць:
create database Star character set utf8 collate default;
create table Star.Країни (
ID_країни int not null auto_increment,
Країна char(45) not null,
primary key (ID_країни)
);
create table Star.Вид_спорту (
ID_спорту int not null auto_increment,
Назва char(45) not null,
primary key (ID_спорту)
);
create table Star.Дисципліна (
ID_дисципліни int not null auto_increment,
Країна char(45) not null,
primary key (ID_дисципліни)
);
create table Star.Стадіони (
ID_стадіону int not null auto_increment,
Стадіон char(45) not null,
дата_відкриття date not null,
місткість int not null,
адреса char(45) not null,
primary key (ID_стадіону)
);
create table Star.Спортсмени (
ID_спортсмена int not null auto_increment,
Прізвище char(45) not null,
Імя char(45) not null,
дата_народження date not null,
primary key (ID_спортсмена)
);
create table Star.Медаль (
ID_медалі int not null auto_increment,
ID_спорту int not null,
ID_дисципліни int not null,
ID_стадіону int not null,
ID_спортсмена int not null,
ID_країни int not null,
медаль enum('gold','silver','bronze'),
primary key (ID_медалі),
constraint Медаль_Спортсмени foreign key(ID_спортсмена)
references Star.Спортсмени(ID_спортсмена) on delete no action
on update no action,
constraint Медаль_Країни foreign key(ID_країни)
references Star.Країни(ID_країни) on delete no action
on update no action,
constraint Медаль_Стадіони foreign key(ID_стадіону)
references Star.Стадіони(ID_стадіону) on delete no action
on update no action,
constraint Медаль_Дисципліна foreign key(ID_дисципліни)
references Star.Дисципліна(ID_дисципліни) on delete no action
on update no action,
constraint Медаль_Вид_спорту foreign key(ID_спорту)
references Star.Вид_спорту(ID_спорту) on delete no action
on update no action
);
Заповнення таблиць вимірів:
INSERT INTO Star.країни
VALUES (1, 'USA'),
(2, 'Jamaica'),
(3, 'Ukraine'),
(4, 'Korea'),
(5, 'Cuba'),
(6, 'Hungry');
INSERT INTO Star.вид_спорту
values (1,'swimming'),
(2,'track and fields'),
(3,'box');
INSERT INTO Star.спортсмени
VALUES (1, 'Phelps', 'Michael',"1991.01.01"),
(2, 'Bolt', 'Usein',"1991.01.01"),
(3, 'Lomachenko', 'Vasyl',"1988.02.17"),
(4, 'Lohte', 'Ryan',"1984.08.03"),
(5, 'Blayke', 'Johan',"1989.12.26"),
(6, 'Gatlin', 'Jastin',"1982.02.10"),
(7, 'Ware', 'Woren',"1989.10.13"),
(8, 'Han', 'Chan',"1984.12.30"),
(9, 'Toledo', 'Garcia',"1989.09.15"),
(10, 'Cech', 'Peter',"1985.12.03"),
(11, 'Walcot', 'Teo',"1993.01.01"),
(12, 'Pjatnycja', 'Olexiy',"1987.08.01"),
(13, 'Usyk', 'Oleksandr',"1988.04.29"),
(14, 'Spic', 'Mark',"1979.08.03"),
(15, 'Blake', 'QWE',"1989.12.26"),
(16, 'Berinchyk', 'Denys',"1988.08.10"),
(17, 'Shelestuk', 'Taras',"1985.11.13"),
(18, 'Syao', 'Chan',"1984.11.25"),
(19, 'Maylls', 'Anthony',"1982.03.15"),
(20, 'Laslo', 'Cheh',"1984.12.03");
INSERT INTO Star.стадіони
VALUES (1, 'Aquatic Centre', "2011.03.12", 17500 , 'Olympic Parc'),
(2, 'ExCel', "2010.06.20", 10000 , 'Newham'),
(3, 'Olympic Stadium', "2011.02.12", 80000 , 'Olympic Parc');
INSERT INTO Star.дисципліна
values (1, '200 m complex'),
(2, '100 m'),
(3, '200 m'),
(4, '60 kg'),
(5, '66 kg'),
(6, '75 kg'),
(7, '96 kg'),
(8, 'javelin throw'),
(9, '400'),
(10, '800'),
(11, '1500'),
(12, '400 m complex'),
(13, '100 m bras'),
(14, '200 m bras'),
(15, '100 m butterfly'),
(16, '200 m butterfly'),
(17, 'long jump');
Заповнення таблиці фактів:
delimiter //
create procedure input2()
begin
Declare i integer;
Declare j integer;
Declare k integer;
Declare l integer;
Declare m integer;
set i = 1;
while (i < 4) do
set j = 1;
while (j < 11) do
set k = 1;
while (k < 4) do
set l = 1;
while (l < 11) do
set m = 1;
while (m < 4) do
insert into Star.Медаль(ID_спорту,ID_дисципліни,ID_стадіону,ID_спортсмена,ID_країни) values(i, j, k, l, m);
set m = m + 1;
end while;
set l = l + 1;
end while;
set k = k + 1;
end while;
set j = j + 1;
end while;
set i = i + 1;
end while;
end;
//
Запит
select *from Star.медаль, Star.стадіони
where медаль.ID_стадіону=стадіони.ID_стадіону
and Стадіон='ExCel';
Час виконання запиту:
/
Схема:
/
Створення схеми сховища даних з архітектурою сніжинка
Схема даних:
/
Запит
select *from snowflake.медаль, snowflake.стадіони_доп,snowflake.стадіони
where медаль.ID_стадіону=стадіони.ID_стадіону
and стадіони_доп.ID_стадіону=стадіони.ID_стадіону
and Стадіон='ExCel';
Час виконання
/
Висновок: Під час виконання лабораторної роботи ознайомилась з порядком, методами та засобами проектування і побудови сховища даних з архітектурою шини та здійснила оцінку часу виконання запитів.
За результатами вимірів часу виконання я дійшла висновку, що працювати із архітектурою «Зірка» вигідніше, адже час виконання запиту менший.
10.11.2016 22:11-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора