Verİ AmbarI Ve Olap Teknolojİsİ

1. VerİAmbarI Ve OlapTeknolojİsİ

2. İçerİk • Veri Ambarı Nedir? • Çok boyutlu veri modeli • Veri ambarı mimarisi • Veri ambarı uygulaması • Veri ambarından veri madenciliğine Veri Madenciliğine Giriş

3. VerİAmbarINedİr? • Organizasyonun işlemsel veri tabanından ayrı olarak düşünülen bir karar destek veri tabanıdır. • “Veri ambarı özneye dayalı, bütünleşmiş, zaman dilimli ve yöneticinin karar verme işleminde yardımcı olacak biçimde toplanmış olan değişmeyen veriler topluluğudur. ” —W. H. Inmon Veri Madenciliğine Giriş

4. Data Warehouse—Özneye DayalI • Bir veri ambarı, tüketici, tedarikçi firma, ürün ve satış gibi önemli özneler etrafında kurulur. • Veri ambarı bir organizasyonun her güne ait işleri ve hareket işleme faaliyetleri üzerinde yoğunlaşmak yerine karar verecek kimseler için veriye ait modelleme ve analiz üzerinde yoğunlaşır. • Veri ambarları karar destek sürecinde faydalı olmayan veriyi dışarıda tutarak basit ve öz bir bakış sağlar. Veri Madenciliğine Giriş

5. Data Warehouse—Tümleşİk • Bir veri ambarı genellikle ilişkisel veri tabanları, dosyalar ve çevrim içi işlem kayıtları gibi çeşitli farklı türde (heterojen) dosyaları bütünleştirerek oluşturulur. • Veri temizleme ve veri tümleme teknikleri, isimlendirmede, şifreleme yapılarında, nitelik ölçütlerinde ve benzeri konularda tutarlılığı garantilemek için uygulanır. Veri Madenciliğine Giriş

6. Data Warehouse—Zaman dİlİmlİ • Veriler tarihi bir bakış açısından bilgi sağlamak için depolanır(örn: 5-10 yıllık geçmiş içerisinden). • Veri ambarı içerisinde her anahtar yapı zamanın bir elemanı olarak ya kesinlik ya da açıklık içerir. Veri Madenciliğine Giriş

7. Data Warehouse—Değİşmeyen • Veri ambarı hareket işlemeyi, geri almayı, ve rastlantısal kontrol mekanizmalarını gerektirmez. • Veriye erişim için çoğunlukla sadece iki işlem gerektirir: • verinin ilk yüklemesi • verinin erişimi Veri Madenciliğine Giriş

8. Özetle • Veri ambarı • stratejik kararları verme konusunda bir kurumun ihtiyacı olan bilgiyi depolayan • karar destek veri modelinin fiziksel bir sunumu gibi çalışan, • anlamsal olarak tutarlı bir veri deposudur. • Veri ambarı aynı zamanda sıklıkla, yapısal ve/veya planlanmamış sorgular, analitik raporlar ve karar vermeyi desteklemek için çeşitli farklı türde kaynaklardan veriyi bütünleştirerek oluşturulan bir mimari olarak da görülür. Veri Madenciliğine Giriş

9. Veri AmbarlarIve İşlemselVerİtabanISİstemlerİArasIndakiFarklar • Çevrim içi işlemsel veri tabanları sistemlerinin önemli bir görevi, çevrim içi işlemeyi ve sorgulamayı gerçekleştirmektir. • Bu sistemlere çevrim içi hareket işleme sistemleri(on-linetransactionprocessing OLTP) denir. • Bu sistemler bir organizasyona ait alım, envanter, imal-yapım, bankacılık, ücret bordrosu, kayıt ve hesaplama gibi bir organizasyona ait günlük işlemlerin çoğunu karşılamaktadır. • Diğer bir yandan veri ambarı sistemleri kullanıcılara veya bilgi çalışanlarına, veri analizi ve karar verme rolü içerisinde hizmet eder. • Böyle sistemler, farklı kullanıcıların çeşitli ihtiyaçlarına yer vermek amacıyla veriyi değişik formatlarda gösterebilir ve organize edebilir. • Bu sistemler, çevrim içi analitik işleme sistemleri(on-lineanalyticalprocessing OLAP) olarak bilinirler. Veri Madenciliğine Giriş

10. OLTP ve OLAP • Kullanıcılar ve sistem yönelimi: • OLTP sistemi müşteri merkezlidir: • Bilgi teknolojisi uzmanları, satıcılar ve müşteriler tarafından işlemsel bilgi ve sorgulama için kullanılır. • OLAP sistemi pazar merkezlidir: • Analistleri, uzmanları ve yöneticileri içine alan bilgi çalışanları tarafından veri analizi için kullanılır. • Veri İçerikleri: • OLTP sistemi, tipik olarak karar vermede kolayca kullanılmak için fazla detaylı olan güncel veriyi yönetir. • Bir OLAP sistemi, büyük miktarlarda tarihi veriyi yönetir, özetleme ve toplamada kolaylıklar sağlar ve öğe boyutunda farklı seviyelerindeki bilgiyi saklar ve yönetir. Bu özellikler veriyi karar vermede kullanabilmek için daha kolay bir hale getirir. • Veritabanı Tasarımı: • OLTP sistemi genelde varlık-bağıntı (entity-relationshipER) veri modelini ve uygulama merkezli veritabanı tasarımını seçer. • OLAP sistemi,tipik olarak ya yıldız yada kar tanesi modelini ve özne merkezli bir veri tabanı tasarımını tercih eder. Veri Madenciliğine Giriş

11. OLTP ve OLAP • İnceleme: • OLTP sistemi bir kurum veya bölüm içerisindeki bir güncel veriye, tarihi veriyi veya farklı organizasyonlardaki veriyi kapsamadan, temel olarak odaklanır. • OLAP sistemi genellikle bir veritabanı şemasının çoklu versiyonlarını tararken, bir organizasyonun evrimsel sürecine bağlı olarak, aynı zamanda pek çok veri deposundan bilgi tümleme sonucunda kaynağı farklı organizasyonlardan başlayan bilgiyle ilgilenir. Büyük hacimlerinden dolayı, OLAP verileri çoklu saklama ortamlarında depolanır. • Erişim Desenleri: • OLTP sisteminin erişim desenleri temel olarak kısa, basit(atomik) işlem bilgilerden oluşur. Böyle bir sistem uyumluluk kontrolü ve kurtarma mekanizmaları gerektirir. • Bununla birlikte, OLAP sistemlere erişim, pek çoğunun karmaşık sorgu olabilecek olmasına karşın çoğunlukla salt okunur işlemler (çoğu veri ambarının güncel bilgi yerine tarihi bilgiyi depolaması nedeniyle) şeklindedir. Veri Madenciliğine Giriş

12. OLTP vs. OLAP Veri Madenciliğine Giriş

13. Neden AyrIBİrVerİAmbarIGereklİOlsun? • DBMS: erişim yöntemleri, birinci anahtarı kullanarak indeksleme, özel kayıtları araştırma ve sorguları optimize etme gibi bilinen görev ve iş yüklerinden hareketle tasarlanır ve ayarlanır. • Diğer tarafta, veri ambarı sorguları sıklıkla karmaşıktır. Özetlenmiş seviyelerdeki verilerin büyük gruplarının hesaplanması ile ilgilenir, ve özel veri organizasyonu, erişim ve çok boyutlu incelemeye dayanan sunum yöntemleri gerektirebilir.   • OLAP sorgusu sıklıkla, kümeleme ve özetleme için veri kayıtlarına salt okunur erişime ihtiyaç duyar.   • İşlemselveritabanlarının veri ambarlarından ayrılması işlemi, bu iki sistem içerisindeki farklı yapılar, içerikler ve veri kullanımları üzerine kurulmuştur. • Karar destek için tarihi bilgi gerekli iken, işlemsel veritabanları tipik olarak tarihi veriye bakmaz. Bu bağlamda, işlemsel veritabanlarındaki veri çok olmasına rağmen, karar verme için gereken tamlıktan uzaktır. • Karar destek, heterojen kaynaklardan gelen verinin birleştirilmesine(kümeleme ve özetleme gibi) ve sonuç olarak yüksek kalitede, temiz ve tümleşik veriye ihtiyaç duyar. • Karşıt olarak, işlemselveritabanları sadece hareketler gibi analizden önce birleştirilmeye ihtiyacı olan ,detaylı ham veri içerirler. Veri Madenciliğine Giriş

14. İçerİk • Veri Ambarı Nedir? • Çok boyutlu veri modeli • Veri ambarı mimarisi • Veri ambarı uygulaması • Veri ambarından veri madenciliğine Veri Madenciliğine Giriş

15. Tablodan VerİKüplerİneDoğru • “Veri küpü nedir?” • Veri küpü verinin çoklu boyutta modellenmesini ve incelenmesini sağlar. • Boyutlar ve bilgiler ile tanımlanır. • boyutlar, organizasyonun kayıtlarını tutmak istediği perspektifler veya varlıklar ile ilgilidir. • Örnek olarak mağazanın zaman, adet, şube ve yer ile ilgili satış kayıtlarını tutmak için bir satış veri ambarı kurabilir. • Bu boyutlar mağazaya, aylık satışların adedi, şubeleri ve parçaların satıldığı yerler gibi kayıtların izinin tutulmasına imkan verir. • Her boyut, boyut tablosu denen, boyutu daha detaylı anlatan bir ilgili tabloya sahip olabilir. • Örnek olarak, bir parça için boyut tablosu parça adı, marka ve tip niteliklerini içerebilir. Boyut tabloları kullanıcılar veya uzmanlar tarafından belirtilebilir veya veri dağıtımları temel alınarak otomatik olarak yaratılabilir ve uyarlanabilir. Veri Madenciliğine Giriş

16. all 0-D(apex) cuboid time item location supplier 1-D cuboids time,location item,location location,supplier 2-D cuboids time,supplier item,supplier time,location,supplier 3-D cuboids item,location,supplier time,item,supplier 4-D(base) cuboid Cube time,item time,item,location time, item, location, supplier Veri Madenciliğine Giriş

17. Veri Madenciliğine Giriş

18. Veri Madenciliğine Giriş

19. Veri Madenciliğine Giriş

20. Veri Madenciliğine Giriş

21. Veri Madenciliğine Giriş

22. VerİambarlarInI modellemek • Veri ambarı için en popüler veri modeli, çok boyutlu modeldir. • Çok boyutlu veri modeli • yıldız şema, • kar tanesi şema • olgu takımyıldızı Veri Madenciliğine Giriş

23. Yıldız Şema • En çok bilinen modelleme örneği • İçerisinde veri ambarının içerdiği en önemli veri kısmını gereksiz fazlalık olmadan içinde bulunduran büyük bir merkezi tablo (olgu tablosu) • her biri bir boyut için olmak üzere küçük yardımcı tablolar kümesi (boyut tabloları) bulunduran yıldız şemadır. • Şema çizgesi, merkezi olgu tablosunun etrafında merkezden çıkan bir desen içerisinde gösterilen boyut tabloları ile, starburst yapısına benzer. Veri Madenciliğine Giriş

24. item time item_key item_name brand type supplier_type time_key day day_of_the_week month quarter year location branch location_key street city state_or_province country branch_key branch_name branch_type Örnek Yıldız Şema Sales Fact Table time_key item_key branch_key location_key units_sold dollars_sold avg_sales Measures Veri Madenciliğine Giriş

25. Kar Tanesİ Şema • Kar tanesi şema, bazı boyut tablolarının normalize edildiği, bundan dolayı verinin ek tablolara doğru ileri bölündüğü, yıldız şema modelinin değişik bir biçimidir. • Sonuç şema çizgesi kar tanesine yakın bir şekil oluşturur. • Kar tanesi ve yıldız şema modelleri arasındaki önemli fark kar tanesi modelinde boyut tablolarının gereksiz fazlalıkları azaltmak için normalize edilmiş formda saklanabilir olmasıdır. • Böyle bir tabloyu yönetmek kolay ve kayıt yerinden tasarruf etmeyi sağlar çünkü büyük bir boyut tablosu, boyutsal yapı olarak sütunlar içerdiğinde devasa hale gelebilir. • Bunun yanında yerden kazanç sağlama, olgu tablosunun tipik büyüklüğü ile karşılaştırıldığında önemsizdir. • Dahası kar tanesi yapısı, bir sorguyu işletmek için daha çok katılım gerekli olacağından, tarama-gözden geçirme performansının etkinliğini de düşürebilir. • Sonuç olarak, sistem performansı ters biçimde etkilenebilir. Bundan dolayı, veri ambarı tasarımında kar tanesi şema, yıldız şema kadar popüler değildir. Veri Madenciliğine Giriş

26. supplier item time item_key item_name brand type supplier_key supplier_key supplier_type time_key day day_of_the_week month quarter year city location branch location_key street city_key city_key city state_or_province country branch_key branch_name branch_type Örnek Kartanesİ Şema Sales Fact Table time_key item_key branch_key location_key units_sold dollars_sold avg_sales Measures Veri Madenciliğine Giriş

27. Olgu TakImyIldIzI Şema • Karmaşık uygulamalar boyut tablolarını paylaşmak için çoklu olgu tabloları gerektirebilir. • Bu çeşit bir şema yıldızların toplamı olarak görülebilir ve bundan dolayı adına galaksi şema veya olgu takımyıldızı denir. Veri Madenciliğine Giriş

28. item time item_key item_name brand type supplier_type time_key day day_of_the_week month quarter year location location_key street city province_or_state country shipper branch shipper_key shipper_name location_key shipper_type branch_key branch_name branch_type Örnek TakImyIldIzIŞema Shipping Fact Table time_key Sales Fact Table item_key time_key shipper_key item_key from_location branch_key to_location location_key dollars_cost units_sold units_shipped dollars_sold avg_sales Measures Veri Madenciliğine Giriş

29. Cube Definition Syntax (BNF) in DMQL • Cube Definition (Fact Table) define cube <cube_name> [<dimension_list>]: <measure_list> • Dimension Definition (Dimension Table) define dimension <dimension_name> as (<attribute_or_subdimension_list>) • Special Case (Shared Dimension Tables) • First time as “cube definition” • define dimension <dimension_name> as <dimension_name_first_time> in cube <cube_name_first_time> Veri Madenciliğine Giriş

30. Defining Star Schema in DMQL • define cubesales_star [time, item, branch, location]: • dollars_sold = sum(sales_in_dollars), units_sold=count(*) • define dimensiontime as (time_key, day, day_of_week, month, quarter, year) • define dimensionitemas (item_key, item_name, brand, type, supplier_type) • define dimensionbranchas (branch_key, branch_name, branch_type) • define dimensionlocationas (location_key, street, city, province_or_state, country) Veri Madenciliğine Giriş

31. Defining Snowflake Schema in DMQL define cube sales_snowflake [time, item, branch, location]: dollars_sold = sum(sales_in_dollars), avg_sales = avg(sales_in_dollars), units_sold = count(*) define dimension time as (time_key, day, day_of_week, month, quarter, year) define dimension item as (item_key, item_name, brand, type, supplier(supplier_key, supplier_type)) define dimension branch as (branch_key, branch_name, branch_type) define dimension location as (location_key, street, city(city_key, province_or_state, country)) Veri Madenciliğine Giriş

32. Defining Fact Constellation in DMQL define cube sales [time, item, branch, location]: dollars_sold = sum(sales_in_dollars), avg_sales = avg(sales_in_dollars), units_sold = count(*) define dimension time as (time_key, day, day_of_week, month, quarter, year) define dimension item as (item_key, item_name, brand, type, supplier_type) define dimension branch as (branch_key, branch_name, branch_type) define dimension location as (location_key, street, city, province_or_state, country) define cube shipping [time, item, shipper, from_location, to_location]: dollar_cost = sum(cost_in_dollars), unit_shipped = count(*) define dimension time as time in cube sales define dimension item as item in cube sales define dimension shipper as (shipper_key, shipper_name, location as location in cube sales, shipper_type) define dimensionfrom_locationas location in cube sales define dimensionto_locationas location in cube sales Veri Madenciliğine Giriş

33. A Concept Hierarchy: Dimension (location) all all Europe ... North_America region Germany ... Spain Canada ... Mexico country Vancouver ... city Frankfurt ... Toronto L. Chan ... M. Wind office Veri Madenciliğine Giriş

34. View of Warehouses and Hierarchies Specification of hierarchies • Schema hierarchy day < {month < quarter; week} < year • Set_grouping hierarchy {1..10} < inexpensive Veri Madenciliğine Giriş

35. Date 2Qtr 1Qtr sum 3Qtr 4Qtr TV Product U.S.A PC VCR sum Canada Country Mexico sum All, All, All A Sample Data Cube Total annual sales of TV in U.S.A. Veri Madenciliğine Giriş

36. Verİ Küpü oluşturma-örnek • Market satış verileri • Zaman-reyon satış verisi Veri Madenciliğine Giriş

37. Yönetici zaman-ürün boyutuna şube boyutunu ekleyerek sonuçları görmek istiyor. Veri Madenciliğine Giriş

38. Veri Madenciliğine Giriş

39. Verİ küpünü oluşturan küboİdler Veri Madenciliğine Giriş

40. Çok Boyutlu VerİModelİndeOLAP OperasyonlarI • “Kavram hiyerarşileri OLAP içerisinde nasıl yardımcı olur?” • Çok boyutlu modelde veriler çoklu boyutlara organize edilmiştir ve her boyut, kavram hiyerarşisi tarafından tanımlanan çok boyutlu soyutlamalar içermektedir. • Bu organizasyon kullanıcılara, veriyi farklı perspektiflerden inceleme esnekliği sağlar. • Belirli sayıda OLAP veri küpü işlemleri, bu farklı incelemeleri gerçekleştirmek için, eldeki verinin etkileşimli sorgusu ve analizine imkan veren biçimde mevcuttur. • Bundan dolayı OLAP, etkileşimli veri analizi için kullanıcı dostu bir ortam sunmaktadır. Veri Madenciliğine Giriş

41. Tİpİk OLAP OperasyonlarI • Roll-up: Bu operasyon (bazı satıcılar tarafından drill-up operasyonu olarak da adlandırılır.) ya bir boyut için kavram hiyerarşisinin tepesine tırmanarak, yada boyut azaltımı ile bir veri küpünde kümeleme işlemi gerçekleştirir. • Rollupişlemi boyut azaltımı ile birlikte yapıldığında verilen küpten bir veya daha çok boyut silinir. Örnek olarak sadece yer ve zaman boyutları bulunan bir satışlar veri küpü düşünelim. Rollup işleminin zaman boyutunu sildiğini farz edelim, bu durumda toplam satışlar yer ve zamana göre kümelenmek yerine, sadece yere göre kümelenecektir. Veri Madenciliğine Giriş

42. Roll-Up Veri Madenciliğine Giriş

43. TİpİkOLAP OperasyonlarI • Drill-down (): Roll-upişleminin tersidir. • Az detaylı veriden daha detaylı veriye doğru yönlendirme sağlar. • Drilldown işlemi, ya bir boyut için kavram hiyerarşisinde aşağı doğru inerek ya da ek boyutlar tanıtarak gerçekleştirilebilir. • Örn. Sonuç veri küpü, toplam satışları çeyreklere ait özetler halinde vermek yerine, aylık detaylar ile birlikte vermektedir. • Drilldown işlemi eldeki veriye daha fazla detay eklediği için, bir küp yapısına yeni boyutlar da ekleyerek oluşturulabilir. Veri Madenciliğine Giriş

44. Drill-down Veri Madenciliğine Giriş

45. Roll-up, Drilldown Veri Madenciliğine Giriş

46. TİpİkOLAP OperasyonlarI • Sliceişlemi verilmiş olan küpte, bir alt küp ile sonuçlanan, bir boyut üzerinde seçme gerçekleştirmesidir. • Şekilde zaman boyutu için time=”Q1” kriterini kullanarak merkezi küpten satış verilerinin seçildiği bir slice işlemi görünmekedir. • Diceişlemi ise iki veya daha fazla boyut üzerinde seçim işlemi gerçekleştirerek bir alt küp tanımlar. • Şekil şu üç boyutu ilgilendiren seçim kriterine: (location= ”Toronto” or “Vancouver”) and(time= ”Q1” or”Q2”) and( item= ”homeentertainment” or“computer”) dayanarak merkezi küpte yapılan dice işlemini göstermektedir. Veri Madenciliğine Giriş

47. Slice Veri Madenciliğine Giriş

48. Dice Veri Madenciliğine Giriş

49. TİpİkOLAP OperasyonlarI • Pivot(rotate-döndürme): Pivot işlemi, veriye ait alternatif bir görünüm sağlamak amacıyla veri eksenlerini döndüren görsellikle ilgili bir işlemdir. • Şekil parça ve yer eksenlerinin 2 boyutlu olarak yer değiştirdiği bir döndürme işlemini göstermektedir. Veri Madenciliğine Giriş

50. Pivot Veri Madenciliğine Giriş