apex cuboid

Veri Madenciliği
Bölüm 3. Veri Ambarları
Doç. Dr. Suat Özdemir
w3.gazi.edu.tr/~suatozdemir
Konular
 Veri ambarı nedir?
 Çok boyutlu veri modeli
 Veri ambarı mimarisi
 Veri ambarcılığı
Veri Madenciliği
Doç. Dr. Suat Özdemir
2/35
Veri Ambarları ve OLAP Teknolojisi
 Veri ambarları çok boyutlu ve karmaşık verileri
özetleyen ve katagorize eden teknolojidir.
 Bu teknoloji veri madenciliğinde şu ana kadar
gördüğümüz veri temizleme, birleştirme ve çevirme
işlemlerini kapsamaktadır.
 Veri tabanları çevrim içi analitik işlemenin (Online
Analytical Processing - OLAP) değişik boyutlardaki
ve karmaşıklıktaki veriler için kullanılabilmesine
olanak tanır.
Veri Madenciliği
Doç. Dr. Suat Özdemir
3/35
Veri ambarları
 Veri ambarı
– Bir veri ambarı yönetimsel karar vermeye yardımcı olacak
verilerin konu odaklı, birleştirilmiş, zaman değişken
ve sabit olarak toplanmasıdır (W. H. Inmon).
 Veri ambarcılığı
– Veri ambarı oluşturma ve kullanma işlemi
Veri Madenciliği
Doç. Dr. Suat Özdemir
4/35
Veri ambarı – Konu odaklı
 Müşteri, ürün, satış gibi ana konular için geliştirilirler
 Karar verici makamlar için verinin modellenmesine
ve analizine odaklanır
– Günlük işlemler ya da alışveriş hareketliliği veri
ambarlarının konusu değildir.
 Gereksiz verileri ayıklar ve odaklandığı konu
çerçevesinde basit ve anlaşılabilir bilgiyi sunar
Veri Madenciliği
Doç. Dr. Suat Özdemir
5/35
Veri ambarı – Birleştirilmiş
 Farklı kaynakların bir araya getirilmesi ile oluşur
– relational databases, flat files, on-line
transaction records
 Veri temizleme ve birleştirme teknikleri
uygulanır.
– İsimlendirme, birimler, vb.
– Veriler veri ambarına alındıklarında gerekli
çevrimler yapılır.
 Değişik veri kaynakları arasındaki tutarlılık
sağlanır
Veri Madenciliği
Doç. Dr. Suat Özdemir
6/35
Veri ambarı – Zaman değişkenli
 Zaman değişkeni canlı veri tabanlarına göre daha
uzundur
 Canlı veri tabanları: Güncel veriler bulunur (en çok
geçmiş 1 yıl)
 Veri ambarları: Geçmiş hakkında bilgi verir (geçmiş
5-10 yıl)
 Veri ambarının odaklandığı konu zaman içerisinde
değişebilir
– A data warehouse's focus on change over time is what is
meant by the term time variant.
Veri Madenciliği
Doç. Dr. Suat Özdemir
7/35
Veri ambarı – Statik
 Canlı veritabanlarından alınan veri farklı bir fiziksel
bir ortamda saklanır
 Veri ambarında veri güncellemesi olmaz
 Canlı veritabanlarındaki değişim veri ambarlarını
etkilemez
 Sadece “ilk veri yüklemesi” ve “veri erişimi”
işlemlerini kullanır
Veri Madenciliği
Doç. Dr. Suat Özdemir
8/35
Veri Ambarı - Birleştirilmiş Veritabanları Karşılaştırılması


Veritabanlarının birleştirilmesi OLTP (on-line transaction processing):
– Farklı veritabanları arasında bir arabulucu katman
– Sorgulama tabanlı, karmaşık ve kaynak açısından verimsiz
– Bir sorgulamayı her veritabanı için alt sorgulamalara ayır
– Sonucu birleştir
Veri ambarı OLAP (on-line analytical processing):
– Veri daha sonra kullanılmak üzere birleştirilip veri ambarında saklanıyor
Sorgulama
Sorgulama
Alt
Sorgular
Birleştir
me
Veri
Ambarı
Sonuç
Veri ambarı
Veri Madenciliği
Doç. Dr. Suat Özdemir
Arayüz
Sonuç
Birleştirilmiş veri tabanları
9/35
OLTP vs. OLAP
OLTP
OLAP
users
clerk, IT professional
knowledge worker
function
day to day operations
decision support
DB design
application-oriented
subject-oriented
data
current, up-to-date
detailed, flat relational
isolated
repetitive
historical,
summarized, multidimensional
integrated, consolidated
ad-hoc
lots of scans
unit of work
read/write
index/hash on prim. key
short, simple transaction
# records accessed
tens
millions
#users
thousands
hundreds
DB size
100MB-GB
100GB-TB
metric
transaction throughput
query throughput, response
usage
access
Veri Madenciliği
Doç. Dr. Suat Özdemir
complex query
10
Çok boyutlu veri modeli
 Çoklu boyutlu veri modelinin temel birimi fact
table lardır
 A fact table is a table that contains the
measures of interest.
 Odaklanılan özellik ve boyutları özetler
 Örneğin “satış verisi” odaklanılan bir özellik
olabilir.
 Bu nitelik “fact table” içinde istenilen
hassasiyette (granularity) tutulur.
– Örneğin “bir şube için günlük satış değeri”
– Bu durumda “fact table” üç kolondan (nitelik) oluşur:
zaman, şube ve satış tutarı.
Veri Madenciliği
Doç. Dr. Suat Özdemir
11/35
Çok boyutlu veri modeli
 Lookup Table: The lookup table provides the
detailed information about the attributes.
 Her bir niteliğin detaylı bilgisini tutar
 Örneğin “Quarter” niteliği için “lookup table” very
ambarındaki tüm Quarter değerlerini içerir
 Her bir satır (Quarter) gerekli olan diğer bilgileri
içerir Unique ID, format vb.
Veri Madenciliği
Doç. Dr. Suat Özdemir
12/35
Star schema
 Çok boyutlu veri modeli star schema (veri küpü)
lardan oluşturulur
 Star schema da merkezde bir fact table bulunur.
 Fact table ilişkili lookup table larla bağlantılıdır.
 Her nitelik bir lookup table ile gösterilir
 Her lookup table için primary key fact table daki bir
foreign key ile bağıntılıdır.
Veri Madenciliği
Doç. Dr. Suat Özdemir
13/35
Star schema
 Assume a data warehouse
that keeps store sales data
 Dimensions are time, store,
product, and customer.
 The lines between two tables
indicate that there is a
primary key / foreign key
relationship between the two
tables.
 Note that different
dimensions are not related to
one another.
Veri Madenciliği
Doç. Dr. Suat Özdemir
14/35
Örnek
Veri Madenciliği
Doç. Dr. Suat Özdemir
15/35
Snowflake schema
 The snowflake schema is an extension of the
star schema, where each point of the star
explodes into more points.
 Star schema da her nitelik bir lookup table
(dimension table) ile gösterilir
 Snowflake schema da o dimensional table birden
fazla lookup table olarak normalize edilir
– Her tablo boyut hiyeraşisinde bir seviyedir
– Yıl -> Ay -> Gün gibi
Veri Madenciliği
Doç. Dr. Suat Özdemir
16/35
Snowflake schema
 The Time Dimension that consists of 2 different hierarchies:
1. Year → Month → Day
2. Week → Day
 There are 4 lookup tables in a snowflake schema.
 A lookup table for year, a lookup table for month, a lookup table for
week, and a lookup table for day.
 Year is connected to Month, which is then connected to Day. Week
is only connected to Day.
Veri Madenciliği
Doç. Dr. Suat Özdemir
17/35
Örnek Snowflake Schema
Veri Madenciliği
Doç. Dr. Suat Özdemir
18/35
Snowflake schema
 The main advantage of the snowflake schema is the
improvement in query performance due to
minimized disk storage requirements and joining
smaller lookup tables.
– Sometimes the performance may be negavitely affected due to
increased number of join operations
 The main disadvantage of the snowflake schema is
the additional maintenance efforts needed due to
the increase number of lookup tables.
Veri Madenciliği
Doç. Dr. Suat Özdemir
19/35
Star schema - örnek
Veri Madenciliği
Doç. Dr. Suat Özdemir
20/35
Star schema – query örneği
SELECT
dim_store.store_address,
SUM(fact_sales.quantity) AS quantity_sold
FROM
fact_sales
INNER JOIN dim_product ON fact_sales.product_id = dim_product.product_id
INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id
INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id
WHERE
dim_time.action_year = 2016
AND dim_store.city = 'Berlin'
AND dim_product.product_type = 'phone'
GROUP BY
dim_store.store_id,
dim_store.store_address
Veri Madenciliği
Doç. Dr. Suat Özdemir
21/35
Snowflake schema - örnek
Veri Madenciliği
Doç. Dr. Suat Özdemir
22/35
Snowflake schema – query örneği
SELECT
dim_store.store_address,
SUM(fact_sales.quantity) AS quantity_sold
FROM
fact_sales
INNER JOIN dim_product ON fact_sales.product_id = dim_product.product_id
INNER JOIN dim_product_type ON dim_product.product_type_id = dim_product_type.product_ty
INNER JOIN dim_time ON fact_sales.time_id = dim_time.time_id
INNER JOIN dim_year ON dim_time.year_id = dim_year.year_id
INNER JOIN dim_store ON fact_sales.store_id = dim_store.store_id
INNER JOIN dim_city ON dim_store.city_id = dim_city.city_id
WHERE
dim_year.action_year = 2016
AND dim_city.city = 'Berlin'
AND dim_product_type.product_type_name = 'phone'
GROUP BY
dim_store.store_id,
dim_store.store_address
Veri Madenciliği
Doç. Dr. Suat Özdemir
23/35
Çok boyutlu veri modeli
 Star schema “veri küpü” olarak da bilinir
 Veri ambarları veriyi “star schema/veri küpü” olarak gören çok
boyutlu veri modelini kullanır.
 Bir veri küpü, örneğin “satış”, veriyi bir çok boyutta
modellememizi ve görmemizi sağlar.
– Ürün veya zaman gibi boyut tabloları
 Veri ambarcılığı literatüründe, n-D boyutlu küp base cuboid
(baz küboid) olarak adlandırılır. En yüksek seviyeden özet
veriyi gösteren 0-D boyutlu küp apex cuboid (tepe küboid)
olarak adlandırılır. Tüm küboidlerin oluşturduğu örgüde veri
küpü olarak adlandırılır.
Veri Madenciliği
Doç. Dr. Suat Özdemir
24/35
Veri küpü
all
time
0-D(apex) cuboid
item
time,location
time,item
location
supplier
item,location
time,supplier
1-D cuboids
location,supplier
2-D cuboids
item,supplier
time,location,supplier
3-D cuboids
time,item,location
time,item,supplier
item,location,supplier
4-D(base) cuboid
time, item, location, supplier
Veri Madenciliği
Doç. Dr. Suat Özdemir
25/35
Çok boyutlu veri
 Ürün ay ve bölgenin bir fonksiyonu olarak satış verisi
Dimensions: Product, Location, Time
Hierarchical summarization paths
Industry Region
Year
Product
Category Country Quarter
Product
City
Office
Month Week
Day
Month
Veri Madenciliği
Doç. Dr. Suat Özdemir
26/35
Veri Küpü Oluşturma-Örnek
 SMARKET’in satış verilerini tutmak için bir veri
ambarı oluşturmak
 Başlama noktası “zaman-reyon” boyutlarında “satış
miktarı (TL)” verisini tutan 2-boyutlu tablo
Şube: Çankaya
Reyon
Zaman
Veri Madenciliği
Doç. Dr. Suat Özdemir
Manav
Şarküteri
Fırın
İlkbahar
1000
850
350
Yaz
1352
940
298
Sonbahar
1450
658
314
Kış
1500
965
365
27/35
Veri Küpü Oluşturma-Örnek
 SMARKET yöneticisini “zaman-ürün” boyutlarına
birde “şube” boyutunu ekleyerek sonuçları
görmek istiyor
 Sonuçlar çeşitli şubelerin değer tabloları bir araya
getirilerek gösterilebilir.
Zaman
Şube: Çankaya
Şube: Ulus
Şube: Eryaman
Reyon
Reyon
Reyon
Şarküteri Fırın Manav
Şarküteri Fırın Manav
Şarküteri
Fırın
Manav
İlkbahar
1000
850
350
2950
850
350
4155
850
350
Yaz
1352
940
298
6541
940
298
2140
940
298
Sonbahar
1450
658
314
1450
547
314
7520
658
654
Kış
1500
965
365
1500
965
365
1500
965
365
Veri Madenciliği
Doç. Dr. Suat Özdemir
28/35
Veri Küpü Oluşturma-Örnek
 Değer tablolarının birleştirmesi ile elde edilen tablo
çok açık değil/anlaşılması zor
 Farklı boyutlar için özet bilgi (toplam, ortalama, vs.)
elde etmek mümkün değil
 Veri küpü şeklinde ifade edilebilir
Veri Madenciliği
Doç. Dr. Suat Özdemir
29/35
Veri Küpü Oluşturma-Örnek
Zaman
Fırın
Şarküteri
Manav
Toplam
İlkbahar Yaz Sonbahar Kış
Toplam
Çankaya
Ulus
Şube
Reyon
Eryaman
Toplam
Hepsinin toplamı
Veri Madenciliği
Doç. Dr. Suat Özdemir
30/60
Veri küpünü oluşturan küboidler
Toplam
0-D (apex) cuboid
Reyon
Reyon, Zaman
Zaman
Şube
Reyon, Şube
1-D cuboids
Zaman, Şube
2-D cuboids
3-D (base) cuboid
Reyon, Zaman, Şube
Veri Madenciliği
Doç. Dr. Suat Özdemir
31/35
Veri Küpü Oluşturma-Örnek
 Bir başka boyut daha eklenseydi, 3B küplerin yan
yana getirilmesi ile yada 4-boyutlu bir küp ile
gösterilebilirdi.
Veri Madenciliği
Doç. Dr. Suat Özdemir
32/35
Veri küpünde OLAP işlemleri
 Genelleme/Roll up (drill-up): Temelde veri özetleme
işlemidir. 2 şekilde yapılabilir
– Oluşturulan hiyeraşi üzerinde yukarı doğru çıkılır (ay yıl)
– Boyut azaltımı yapılır.
 Derinleme/Drill down (roll down): roll-up işleminin tersidir.
– Oluşturulan hiyeraşi üzerinde aşağılara inilerek veri detaylandırılır
– Yeni boyutlar oluşturulabilir
 Slice and dice: project and select
– Veride istenilen bölge (dilim ya da küp) belirlenir ve “kesilerek” alınır
 Pivot (rotate):
– Veri küpü çevrilir, görsel olarak değiştirilir
– 3B veriden 2B veriler serisine çevrilebilir
Veri Madenciliği
Doç. Dr. Suat Özdemir
33/42
OLAP İşlemleri
Veri Madenciliği
Doç. Dr. Suat Özdemir
34/35
Veri Ambarı Mimarisi
Diğer
Kaynaklar
Veritabanları
Metadata
Veri çek
İşle
Yükle
Yenile
İzleme
Birleştirme
OLAP Server
Hizmet
Veri ambarı
Veri
madenciliği
Veri “Mart”ları
Veri kaynakları
Veri Madenciliği
Doç. Dr. Suat Özdemir
Veri depolama
OLAP motoru Son kullanıcı
36/35
Veri Ambarı Kullanımı
 Three kinds of data warehouse applications
– Information processing
• supports querying, basic statistical analysis, and reporting
using crosstabs, tables, charts and graphs
– Analytical processing
• multidimensional analysis of data warehouse data
• supports basic OLAP operations, slice-dice, drilling, pivoting
– Data mining
• knowledge discovery from hidden patterns
• supports associations, constructing analytical models,
performing classification and prediction, and presenting the
mining results using visualization tools
Veri Madenciliği
Doç. Dr. Suat Özdemir
39/35
Kaynak
 http://www.1keydata.com/
 http://www.nytimes.com/2012/03/29/technology/new-usresearch-will-aim-at-flood-of-digital-data.html?_r=0
Veri Madenciliği
Doç. Dr. Suat Özdemir
40/35