VERİ TABANI YÖNETİMİ Ders 12: Veri Ambarı & OLAP

... konulu sunumlar: "VERİ TABANI YÖNETİMİ Ders 12: Veri Ambarı & OLAP"— Sunum transkripti:

1 VERİ TABANI YÖNETİMİ Ders 12: Veri Ambarı & OLAP
Yrd. Doç. Dr. Altan MESUT Trakya Üniversitesi Bilgisayar Mühendisliği

2 Veri Ambarı Nedir? Veri ambarı, bir işletmenin ya da kuruluşun değişik birimleri tarafından toplanan bilgilerden değerli olanlarının, gelecekte analiz işlemlerinde kullanılması amacıyla işletimsel sistem veritabanından farklı bir ortamda birleştirilmesinden oluşan büyük çaplı bir veri deposudur. Bir veri ambarı ilgili veriyi kolay, hızlı ve doğru biçimde analiz etmek için gerekli işlemleri yerine getirir. Veri ambarı kullanıldığında, günlük işletimsel görevlerle yeterince meşgul olan veritabanı kullanılmadan, analiz işlemleri farklı bir ortamda yapılır.

3 Veri Ambarı Mimarisi

4 ETL (Extract-Transform-Load) (Çıkarım-Dönüştürme-Yükleme)
Veri çıkarımı, veri ambarının kullandığı kaynaklardan (veri tabanı ve/veya diğer kaynaklar) veri elde etme işlemidir. Kaynaklardan çıkarılan veri genellikle geçici dosyalara yüklenilir. Dönüştürme aşamasında ise, elde edilen verilerdeki fazlalıklar atılır (veri temizleme) ve her veri sorgulamalarda kullanılabilecek uygun veri türüne dönüştürülür. Yükleme, dönüştürülen verinin veri ambarına aktarılması işlemidir.

5 Metadata Türleri Teknik Metadata: Bu tur Metadata sistem adminlerini ve ambar tasarımını yapan kullanıcılar için gerekli geliştirme ve bakim işlemleri ile ilgili verilerdir. (İşletimsel veri tabanlarından ambara dönüşüm için kullanılan algoritmalar, veri temizleme ve düzeltimi için kullanılan kurallar, erişim hakları, vs.) İş Metadata, kullanıcıların veri ambarında saklanılan bilginin perspektifini anlamasına yardımcı olacak bilgileri içerir (Sorgu, rapor, web sayfası, resim, video, vs).

6 Veri Madenciliği Nedir?
Veri madenciliği, veri ambarları üzerinde AI (yapay zeka), istatistiksel ve matematiksel teknikleri kullanarak, saklanılan büyük miktarlardaki veriler üzerinden, anlamlı yeni ilişkiler, desenler ve eğilimler keşfetme işlemidir.

7 Veri Madenciliğinin Kullanım Amaçlarından Bazıları:
Stratejik Analiz: Bir KDS (Karar Destek Sistemi) olmasından dolayı Finansal Analiz: Maliyetlerin azaltılması dolayısıyla rekabet avantajının sağlanması Satış analizi ve trendler üzerine odaklanmak Müşterilerin gizli kalmış satın alma eğilimlerini tespit etmek İşler arasında ilişkilerin belirlenebilmesi Müşteri ihtiyaçlarına çabuk cevap verebilme (Etkin CRM)

8 OLAP (On-Line Analytical Processing)
OLAP araçları, hızlı gözden geçirim, özetleme ve veri analizi için tasarlanmış, çok boyutlu veri tabanı motorunda verinin çok boyutlu gösterimine olanak sunan araçlardır. OLAP araçları ile; En çok kâr getiren müşterilerim kimlerdir? (Bayi ve perakendeci bazında.) En kârlı ürünlerim nelerdir? Hangi işletme ya da mağazamda, en çok hangi saat ve günlerde hareketlilik olmaktadır? gibi sorular hızlı bir şekilde cevaplanabilmektedir.

9 Veri Ambarı (OLAP) Veri Tabanı (OLTP) Off-Line çalışır
Veri değişiminden çok sorgulama yapılır Eski veriler saklandığı için veri miktarı çok Üst yönetim ve analistler kullanır (Kullanıcı sayısı az) Veri madenciliği gibi uzun ve karmaşık süreçler sonucunda analizler yapılabilir Veri Tabanı (OLTP) On-Line çalışır Veri değişimi işlemleri yoğunluktadır (DML) Güncel veriler saklandığı için veri miktarı daha az Veriye ulaşmak ve değiştirmek isteyen her kullanıcıya hitap eder (Kullanıcı sayısı çok) Sorgularla istenilen sonuçlara anında ulaşılır

10 Veri ambarı yerine veri tabanı (işletimsel sistem) kullanılırsa …
İşletimsel sistemlerde sürekli değişen veri “karar verme işlemi” için uygun değildir. İşletimsel sistemlerde kompleks bir sorgu yapılacaksa, bir çok tablodan veri toplanması gereklidir. İşletimsel sistemlerde sadece işlemsel veriler saklanılır. Geçmişe yönelik veri saklanılmaz. Organizasyondaki farklı uygulamalar, farklı teknolojiler ve ortamlar kullanabilmektedir. Böyle sistemlerde veri analiz ve sorgulaması, verinin yeri ve ortak bir formata dönüşüm işlemlerini içerdiğinden zor olabilir.

11 Veri Pazarları (Data Marts)
Birleşik verilerin tutulduğu veri ambarına ilave olarak kullanılan veri deposu olarak tanımlanabilir. Veri pazarı, belirli kullanıcı grubu için yaratılan veri bölümüdür. Veri pazarı, normalize edilmemiş, özetlenmiş, toplanılmış veri topluluğu olabilir.

12 Veri Ambarı ile Veri Pazarı Arasındaki Farklar
Veri pazarı sadece bir özne alana veya sadece bir grup kullanıcı üzerine odaklanır. Bir organizasyon sadece bir veri ambarına sahip olur, fakat bir çok veri pazarı içerebilir. Veri pazarları veri ambarlarının aksine, işletimsel veri kaynakları bilgisine sahip değildir. Çünkü veri pazarları, veri ambarlarının aksine daha az bilgi içerirler bu nedenle kullanıcılar için çok daha çabuk ve kolayca anlaşılabilirler.

13 Veri Ambarı İçin Kullanılan Modelleme Teknikleri
Veritabanı tasarımında kullanılan E-R modeli iki boyutlu olup, tüm varlıklara eşitmiş gözü ile bakılır. Veri ambarları için çok boyutlu perspektifi gerçekleyebilecek yeni modelleme teknikleri keşfedilmiştir: Yıldız (Star) Kar Tanesi (Snowflake) Karma (Mixed)

14 Yıldız (Star) Modeli Gerçek tablosu, temel iş ölçümlerini içeren niteliklerden oluşur. Bir gerçek tablo, o tabloya ait spesifik nitelikler ve boyut tablolarıyla ilişkili yabancı anahtarları içermektedir. Boyut tablosu, gerçek tablosunda saklanılan veriyi indeksler ve organize eden niteliklerden oluşmaktadır. Boyut tablosu, boyutu tanımlayan nitelikleri içermektedir.

15 Kar Tanesi (Snowflake) Modeli
Kar tanesi modeli, yıldız modelinin geliştirilmiş halidir. Gerçek tablolarının her bir boyut tablosu başka boyut tablolarına da sahiptir. Boyut tabloları, bir çok niteliğe sahip olduklarında, normalize edilmeleri gereklidir. Yıldız modeli normalize edilmiş boyut tablolarını desteklemediğinden, bu durumda kar tanesi modeli tercih edilmelidir.

16 Kar Tanesi Modelinin Avantajları ve Dezavantajları
Tüm tekrarlanılan veriler kaldırıldığından, saklama alanı korunmuş olur. Büyük normalize edilmemiş tablolar yerine, Join’ler için normalize edilmiş daha küçük tablolar kullanılır. Dezavantajları: Sorgu sonucunda Join edilmesi gereken tabloların sayısının belirlenmesindeki zorluk Belirli bir sorguda kullanılacak tabloyu belirlemedeki zorluk

17 Karma (Mixed) Modeli Bazı veritabanı dizaynlarında, boyut tabloları veri hacminde çok geniş farklılıklar gösterir. Böyle durumlarda tüm tasarımda ne yıldız ne de kar tanesi modeli kullanılamaz. Her iki modelin bir kombinasyonuna ihtiyaç duyulur. Bu kombinasyon modeline karma model denilmektedir.

18 Küp (Cube) Verinin hızlı bir şekilde analizine izin veren veri yapısıdır. Yıldız modeli için verilen örnek bir küp üzerinde aşağıdaki gibi saklanabilir: Gerçek tablosu : Çok boyutlu (3D) küp : day 2 day 1

19 Küp İşlemleri Örnek: Toplam Hesaplama . . . sale(c1,*,*) 129
day 2 . . . day 1 sale(c1,*,*) 129 sale(c2,p2,*) sale(*,*,*) rollup drill-down

20 Özet Tablolar (Materialized Views)
Özet tablolar (MV) bir sorgunun sonucunu saklar. Görüntüden farkı, görüntü sorgunun sonucunu değil sadece sorguyu saklar. Yani sorgunun kapsadığı tablo yada tablolardaki veriler değiştikçe görüntü de değişir. Fakat MV ayrı bir tablo gibi sorgu sonucunu sakladığından dolayı, ilgili tablolar değiştikçe içeriği değişmez. Bu nedenle “CREATE TABLE AS SELECT …” komutu ile bir tablo oluşturmaya benzer. Bir tablodan farkı ise, belirli zaman aralıkları ile sorgunun tekrar çalıştırılıp, değişmiş olabilecek bilgilerin güncellenebilmesidir. Karmaşık sorguların yavaşlığından kurtulmak için veri ambarı ile ilgili sorgulamaların hızlandırılması için kullanılır.

21 Özet Tablolar (Materialized Views)
MV’ler ilk olarak Oracle veritabanında kullanılmaya başlanmış (Oracle 8i’den önceki ismi Snapshot idi), daha sonra IBM DB2 ve MS SQL Server tarafından da kullanılmıştır. Tablolara olan benzerliğinden dolayı IBM DB2’da “Materialized Query Tables” ismi verilmiştir. MV üzerinde de tablolarda olduğu gibi indeks oluşturabildiği için MS SQL Server’da ise “Indexed Views” olarak isimlendirilmiştir.

22 MV Yaratma CREATE MATERIALIZED VIEW base_lookup_mv PARALLEL
BUILD IMMEDIATE REFRESH FAST ON COMMIT ENABLE QUERY REWRITE AS SELECT l.nam ,COUNT(b.tot) count_tot ,SUM(b.tot) sum_tot ,AVG(b.tot) avg_tot FROM base_table b, lookup_table l WHERE b.id = l.id GROUP BY l.nam; İşlem Süreleri: Normal Insert : 60 s MV Insert : 70 s Normal Select : 1,015 s MV Select : s Conn hr/hr; Set timing on; DROP TABLE base_table; CREATE TABLE base_table AS SELECT MOD(rownum, 20) id, round(dbms_random.VALUE(1000, )) tot FROM all_objects, (SELECT * FROM all_tab_cols WHERE ROWNUM < 50); DROP TABLE lookup_table; CREATE TABLE lookup_table AS SELECT MOD(rownum, 20) id, table_name nam FROM user_tables WHERE rownum < 20; SELECT l.nam, AVG(b.tot) FROM base_table b, lookup_table l WHERE b.id = l.id GROUP BY l.nam; INSERT INTO base_table FROM all_objects; commit; CREATE MATERIALIZED VIEW LOG ON base_table WITH SEQUENCE, ROWID (id,tot) INCLUDING NEW VALUES; CREATE MATERIALIZED VIEW LOG ON lookup_table WITH SEQUENCE, ROWID (id,nam) DROP MATERIALIZED VIEW base_lookup_mv; CREATE MATERIALIZED VIEW base_lookup_mv PARALLEL BUILD IMMEDIATE REFRESH FAST ON COMMIT ENABLE QUERY REWRITE AS SELECT l.nam ,COUNT(b.tot) count_tot ,SUM(b.tot) sum_tot ,AVG(b.tot) avg_tot SELECT name, value FROM v$parameter WHERE name like 'query_rewrite_%'; -----