Data warehouse sorusu

[Marty]

selam,

oncelikle aramaya inanip sunu buldum http://forum.paticik.com/read.php?6,6145883,page=2 riglous cok guzel dokturmus. ellerine saglik.

simdi, data warehouse la ilgili odev gibi birsey yapiyorum, konusu universite icin data warehouse. notlar, dersler, bolumler, siniflar, semesterlar falan var.

dwh, hangi bolumde kac ogrenci var, x dersinden alinan son 3 yildaki notlar nedir tarzi sorulara cevap olmasi gerekiyo.

elimde kimballin bi kitabi var, ordan da calisiyorum yalniz, sorularim var


su anda aklima gelen soyle mesela

fact table
[list=1]
[*] student
[*] timekey
[*] coursekey
[*] modulekey
[*] assesmentkey
[*] mark
[/list]
time, course, module, assesment dimensionlari dusundum, baska ne koyabilirim?

soru: semesterlari time in icine mi koysam yoksa semester dimensioni mi yapsam bilemedim. 2si arasinda ne fark olur?

daha da sorularim olucak.
i'll be back

[reyou]

ingilizcelerini anlayamadim ben, turkcelerini yazarsan bole ders, ogrenci, kredi notu falan oyle daha rahat yardimci olabilirim kendi adima sahsima, sahsen ben bizzat kendim.

[riglous]

Semester'i time dimension'a koyman senin icin avantajli olacaktir. Sonucta semester bilgisi time dimension ile 1-to-n baglantili. Herhangi bir time_key, iki semester'i point etmez. Unutma ki fact tablolarin dar ve uzun, dimension'lar ise sisman ama kisa olmali. Yani time dimension'a semster'la ilgili her turlu bilgiyi koy ama yeterki fact tablosuna yeni bir kolon ekleme (bunu kural gibi dusunme tabi, yapmak istedigini gerceklestirdigin surece kurallar falan hikaye). Semester'i aslinda fiscal year gibi dusunebilirsin. Buna bagli olarak bulundugu semester'in kacinci gunu, haftasi ayi vs. gibi bilgileri tutman tasarim acisindan mantikli.

Module ve assesment dimension'larinda ne oldugunu bilmiyorum, daha dogrusu elinde baska ne bilgi var, bilmedigim icin yorum yapmak da zor oluyor.

KPI'larin belirlendikten sonra, bunlari hangi ayrintida vermen gerekiyor, bunu dusun.

Genel olarak bir tasarim yaparken onemli olan senin sunman gereken KPI'lar. Bunlardan ayni granulitede olanlari gruplayip fact tablolarina yazarsin. Yalniz ayrimi yapaken derived KPI'lari goz onunde bulundurmak gerekiyor. Yani aggregation'la hesaplayabileceksen gidip ayri fact tablosuna yazman gerekmez.

Bu gruplama islemini yaptiktan sonra kac tane fact tablon var, kac tane dimension'in var cikar ortaya. Ondan sonra zaten bir cross tablo yapiyorsun. x fact tablosunu yapabilmek icin y ve x dimension'lari gerekiyor. a fact tablosu icin y ve b dimension'lari gerekiyor gibi. Bunun sonucunda da hangi dimension en cok kullaniliyorsa ilk once onu tasarliyorusun. Sonra fact tablosunu olusturuyorsun.

----
Su an icin iki KPI soylemissin. Birisi kurs ve ogrenci-ders kayitlari transaction tablosunu kullanarak bulunuyor. Bunu bir fact tablosuna koyarsin, course_id, time_key, student_cnt koyuyorsun zaten. Boylece her donem hangi dersten kac ogrenci var raporlayabilirsin. semester_id de koyabilirsin tabi; bu durumda semester dimension yaratabilirsin, view olarak yaratman daha mantikli ama karar senin burada. Sonucta o doneme ait olan ilk time_key'i koyman da ayni sonucu verecektir. Yer cekimsiz ortamda yaptigini dusunursek, semester dimension'i olustur bir tane, view olarak, distinct semester bilgilerini tutsun. Ama view olsun ki, time_dim'de tuttugun bilgileri ikinci bir defa tutmus olma. Daha sonra time_dim'de semester'larla ilgili degisiklik yaparsan view'lara direk yansir. Ayrica kisa tablo oldugu icin sikinti yaratmaz.

Diger KPI'da ise tanimi biraz daha ayrintili yapman lazim. Her semester ogrencilerin sayisi degisebiliyor derslerdeki. Sen 3 yillik tum notlarin ortalamasini mi alacaksin, yoksa her donem siniflarin ortalamasinin ortalamasini mi? Buna gore mapping ve tasarim degisecegi icin onemli. Bence semester_key, course_key ve o donemdeki ortalamasini tut. Boylece bir ustteki fact tablosunu kullanabilirsin. Ogrenci bilgilerini de tutman gerekmez.

Sorun olursa bir iki gun icinde yanitlayabilirim. Ondan sonra askere gidiyorum, cevap veremem..

Bir de mark deme grade de.

[Marty]

bu kadar cabuk cevap beklemiyodum acikcasi.

ogrenci fact tablosu
ogrenci no
zaman
bolum
ders
assessment i ceviremedim.
puan

bana verilen descriptionda grade degil mark dendigi icin mark dedim,

assessment dimensionda
in-class test - sinif ici test
coursework - ceviremedim
final exam -

tarzi seyler var.

bu cross table dedigin bus matrix denen sey heralde, ben direkt atlayip fact ve dimension table lara girismistim. dedigin gibi yapayim.

module ders
course bolum bu arada.

2. kpi da, benim anladigim kadariyla siniflarin ortalamasi gerekiyor, son 3 yilda ders notlari nasil degismis diyo tam olarak.
bir kpi da da mesela yine son 3 yilda bir derse kac ogrenci kayit olmus.

bunlari ornek olarak vermis, en az bunlari yapicam acikcasi.

yemek falan yiyip senin dedigin sekilde basliyim ben table lari cikarayim yavastan.

cok saolun.

[riglous]

Bilmiyorum aklinda ne var ama simdiden sikinti olmamasi icin bir iki noktadan bahsedeyim. Su anda karsilasmadigin icin muhtemelen sikinti yasamiyorsun ama isi tek seferde cikarmaya calisma. Soyle ki elinde transactional tablolar var. Bunlardan yola cikarak sen bu verdigin ogrenci fact tablosunu olusturacaksin. Yalniz senden istenen KPI, bu fact tablosu kullanilarak hesaplanacak ve ayri bir tabloda duracak. Onun adi ne olacak?

Genelde OLTP'den OLAP'a yapi degistirirken ara tablolara ihtiyacin olur. Calisma tablolarina ihtiyacin olur. Tek seferde nihai sonuca varmak istemezsin. Soyle dusun, senin transaction tablolarinin durdugu schema ODS olsun (operational data store). Burasi senin verinin ilk hali ve production sistemiyle birebir ayni. Tablo isimleri de genelde ayni birakilir.
Bunun uzerine senin kullanilabilir hale getirdigin tablolar olur genelde, bu schema'ya DWH denir. Bu ogrenci_fact burada durur. Bunun uzerinde de sen KPI'larini tuttugun bir schema yaparsin, adi genelde DM olur.
Genelde DM schemasindaki tablolara FACT veya DIMENSION denir. Onlar nihai haldedir ve son kullanici tarafindan kullanilabilir bilgi icerir.
DWH tarafindaki isimlendirme ise genelde tablonun hangi bilgiyi tuttugu ile alakali oluyor ama icinde fact vs. gecmez genelde. student_grades dersin.

Buradaki yontem genelde buyuk sistemlerde boyle oluyor. Tercih senin tabi. Neticede is bittikten sonra 30 tane daha KPI ekle demezler heralde.

[Marty]

valla aklimdaki tamamen yazdiklarim iste, coursework bu. OLTP den OLAP a gecis falan olmiycak. bus matrix, granularity, dimension ve fact table lari cikaricam, aciklamalarini yapicam.

daha sonra access da warehouse u kurup ornek data ile doldurucam.
sql le de 3 rapor cikaricam,
son 3 yilda derslerin ortalama notlari nasil degisti,
verilen yil ve semesterda ayni hocadan birden fazla ders ala kac ogrenci var,
son 3 yilda sinifta kalan ogrencilerin bolumlere gore oranlari

access de inventory miydi, sales miydi birseyler yapmistim. basitti diye kalmis aklimda, sql hic hatirlamiyorum. su ilk bolumu bitireyim, bunlarla ilgili endise etmeye baslarim sdf

[Marty]

biraz okuyup birseyler yaptiktan sonra basit geldi. basit geldigine gore birseyleri kaciriyorum heralde. neyse.


cross table i yaptim, fact ve dimensionlari yaptim sayilir.

soyle bir sorum var, dersler dimensionim var. bir de assessments dimensionim var. icinde test, coursework, final, project vs olan.

daha dogrusu once boyle 2 dimensionim vardi, artik bunlari birlestirdim. butun sinavlari vs yi derslerin icine sokusturdum. kimballin kitapta basitlik ve ulasilabilirligi dimension table space e tercih ediyoruz tarzi birsey demis diye boyle yaptim.

iyi mi oldu kotu mu oldu bir fikrim yok. ne dersiniz?

[kzpmaza]

Başlıkta Dota yazıyo sanıp geldim.

[riglous]

Bu tabloyu oluşturduktan sonra bir dersin ortalamasını hesaplarken nasıl bir yol izleyeceksin? Oradaki hesaplama yöntemin önemli.

[Marty]

hii, anladim. ben bodoslama yapiyodum. o zaman bakayim tekrar.

aklima en basit su sekil geldi, assessmenti ayri dimension yapicam. snowflake olucak derslere bagli. fact table a da, ders ortalama notu koyucam, butun derslerin son 3 yildaki ortalama notlari istendiginde zaten factte ders ortalamasi var. cok basit olucak.

ya da sabah bakayim, beynim bulandi iyice

[dEaThMooN]

DWH yapısını istenilen raporlara göre şekillendirebilirsin tabii çoğu zaman kesin kurallara oturtturamıyorsun bu fact'tir bu dimension'dır gibi.

Bahsettiğin 3 raporu her türlü çıkartırsın ama ben okuduğumda direk kafamda oluşan şöyle birşey:

En fazla veriyi oluşturacak kısım sınav sonuçları gibi.

Dimension'lar : Department_D , Date_D, Course_D, Student_D

Scores_F
--------
Date_Key (Time)
Department_key
Course_Key (Sınavları da bunun içine ekleriz ve ya başka dimension olabilir..)
Student_Key
Score


Bu yapı belki işte Belli bir tarih aralığında yapılan sınavlardaki başarıyı ölçerken öğrencilerle ilgili olan detaylı bilgilerin olduğu tabloya gitmeden sonuca ulaşmanı sağlar.

Veya bölüm bazında ortalamalar fln fişmekan.



Feci uykum var saçmalamış da olabilirim.

İyi geceler :)