Meta Verileri Modelleme i

IBM Cognos Framework Manager
Sürüm 10.2.2
Meta Verileri Modelleme için
Yönergeler Kılavuzu
򔻐򗗠򙳰
Not
Bu bilgileri ve desteklediği ürünü kullanmadan önce, “Bildirimler” sayfa 51 bölümündeki bilgileri okuyun.
Ürün Bilgileri
Bu belge, IBM Cognos Business Intelligence Sürüm 10.2.2 için geçerlidir ve sonraki yayınlar için de geçerli olabilir.
Licensed Materials - Property of IBM (Lisanslı Malzeme - IBM'in Malıdır)
© Copyright IBM Corporation 2005, 2014.
İçindekiler
Giriş . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Bölüm 1. Meta Verileri Modelleme için Yönergeler . . . . . . . . . . . . . . . . . . 1
IBM Cognos Modelleme Kavramları . . . . .
İlişkisel Modelleme Kavramları . . . . . .
Model Tasarımı ile İlgili Dikkat Edilecek Noktalar
Boyutlu Modelleme Kavramları. . . . . .
İlişkisel Model Oluşturma . . . . . . . .
İlişkisel Modelleme Temelini Tanımlama . . .
Modelin Boyutlu Temsilini Tanımlama . . .
Modeli Düzenleme . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 1
. 1
. 10
. 17
. 19
. 19
. 27
. 30
Bölüm 2. IBM Cognos Yazılımı Tarafından Oluşturulan SQL . . . . . . . . . . . . . 35
Boyutlu Sorgular . . . . . . . . . . . . .
Tekli Olgu Sorgusu . . . . . . . . . . .
Uyumlu Boyutlarda Çoklu Olgu, Çoklu Gren Sorgusu .
1-n İlişkileri 1-1 İlişkiler Olarak Modelleme . . . .
Uyumsuz Boyutlarda Çoklu Olgu, Çoklu Gren Sorgusu.
Belirsiz Şekilde Tanımlanmış Boyutları ve Olguları Çözme
Sıradüzen Düzeyini Temsil Eden Sorgu Konuları . .
Bölünmemiş Olması Gereken Sorguları Çözme . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
35
37
39
41
44
45
46
Bildirimler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Dizin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
© Copyright IBM Corp. 2005, 2014
iii
iv
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
Giriş
IBM® Cognos Framework Manager bir meta veri modelleme aracıdır. Model, bir veya birden
çok veri kaynağındaki bilgilerin iş sunumudur. Bu iş sunumuna güvenlik ve çoklu dil yeteneği
eklediğinizde, tek bir model dünyanın dört bir yanındaki birçok kullanıcı grubunun
ihtiyaçlarına hizmet edebilir.
Belge, iş raporlaması ve çözümlemesinde kullanım için meta verileri modelleme hakkında
anlamanız gereken temel IBM Cognos modelleme kavramlarını ele almaktadır. Ayrıca
ilişkisel modelin oluşturulmasını kapsar.
Hedef Kitle
Bu belge, IBM Cognos modelleme kavramlarını anlamanıza yardımcı olmak için
tasarlanmıştır.
Bilgi Bulma
Ürün belgelerini web üzerinde bulmak için, IBM Knowledge Center'a
(http://www.ibm.com/support/knowledgecenter) erişin.
Geleceğe yönelik beyanlar
Bu belgeler ürünün mevcut işlevini açıklar. Şu anda mevcut olmayan öğeler için referanslar
eklenebilir. Bundan gelecekte herhangi bir bulunabilirlik anlamı çıkarılmamalıdır. Bu tür
referansların hiçbiri herhangi bir malzemeyi, kodu veya işlevi sunmak üzere bir taahhüt, söz
veya yasal yükümlülük değildir. Özelliklerin ve işlevlerin geliştirilmesi, sunulması ve
zamanlaması yalnızca IBM'nin takdirindedir.
Örneklerde garanti reddi
Sample Outdoors Company, Great Outdoors Company, GO Satış, Sample Outdoors veya
Great Outdoors adlarının herhangi bir değişik kullanımı ve Planlama Örneği, IBM ve IBM
müşterileri için örnek uygulamalar geliştirmede kullanılan örnek verilerin yer aldığı hayali iş
operasyonlarını temsil etmektedir. Bu kurgusal kayıtlarda satış işlemleri, ürün dağıtımı,
finansman ve insan kaynaklarına ilişkin örnek veriler bulunmaktadır. Gerçek isimlerle,
adreslerle, iletişim numaralarıyla veya işlem değerleriyle her türlü benzerlik tesadüfidir. Diğer
örnek dosyaları el ile ya da bilgisayar kullanılarak üretilen kurgusal verileri, akademik veya
kamusal kaynaklardan derlenmiş gerçeğe dayalı verileri ya da telif haklarının sahibi
tarafından örnek uygulamalar geliştirmek üzere kullanımına izin verilen verileri içerebilir.
Başvurulan ürün adları bunların hak sahiplerinin ticari markaları olabilir. Yetkisiz çoğaltma
yasaktır.
Erişilebilirlik özellikleri
Erişilebilirlik özellikleri, hareket veya görme yeteneği kısıtlaması gibi fiziksel engeli olan
kullanıcıların bilgi teknolojisi ürünlerini kullanmasına yardımcı olur. IBM Cognos
Framework Manager, erişilebilirlik özelliklerine sahiptir. Bu özellikler hakkında bilgi için,
Framework Manager Kullanıcı Kılavuzu'nun erişilebilirlik bölümüne bakın.
© Copyright IBM Corp. 2005, 2014
v
vi
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
Bölüm 1. Meta Verileri Modelleme için Yönergeler
IBM Cognos Framework Manager, IBM Cognos BI için sorgu oluşturmayı tetikleyen bir meta
veri modelleme aracıdır. Model, bir veya daha fazla veri kaynağı için fiziksel bilgileri ve iş
bilgilerini içeren bir meta veri derlemidir. IBM Cognos BI, çeşitli OLAP veri kaynaklarının
yanı sıra, normalleştirilmiş ve normal dışı ilişkisel veri kaynaklarında performans yönetimini
etkinleştirir.
Farklı bir dilde IBM CognosMeta Verileri Modelleme için Yönergeler belgesine erişmek üzere
installation_location\c10\webcontent\documentation konumuna gidin ve istediğiniz dilin
klasörünü açın. Sonra ug_best.pdf dosyasını açın.
IBM Cognos Modelleme Kavramları
Başlamadan önce, iş raporlaması ve çözümlemesinde kullanılmak üzere meta verileri
modelleme hakkında temel IBM Cognos modelleme kavramlarını anlamanız gerekir.
İlişkisel Modelleme Kavramları
IBM Cognos Framework Manager'da modelleme yapılırken, veri kaynağınızı mükemmel bir
yıldız şeması olacak şekilde tasarlamaya gerek olmadığının anlaşılması önemlidir. Veri
kaynağınız, uygulamanız için gerek duyduğunuz performansı sunacak şekilde eniyilenmiş
olduğu sürece, parçalanmış ve diğer normalleştirilmiş şema formları da eşit şekilde kabul
edilebilir. Genellikle, yıldız şeması kavramlarına uyan mantıksal bir model oluşturmanızı
öneririz. Bu, IBM Cognos Analysis Studio için bir gereksinim olup kullanıcılarınız için
verileri düzenlemenin etkili bir yoludur.
Karmaşık bir veri kaynağıyla uygulamanızı geliştirmeye başlarken, kullanıcılarınızın işi nasıl
göreceğini temsil eden ve öngörülebilir sorgular ve sonuçlar sunmak için bu belgedeki
yönergeler kullanılarak tasarlanmış, basitleştirilmiş bir görünüm oluşturmanız önerilir.
Düzgün oluşturulmuş bir ilişkisel model, uygulamanızın temeli olarak hareket eder ve IBM
Cognos yazılımındaki boyutlu yeteneklerden yararlanmayı seçerseniz, size sağlam bir
başlangıç noktası sunar.
Bir yıldız şeması veri kaynağı ile başlıyorsanız, yıldız şeması oluşturulmasında kullanılan
kavramlar, sorgu ve çözümleme için uygulamaların oluşturulmasında da uygun olduğundan,
modelleme için daha az emek gerekir. Bu belgedeki yönergeler, uygulamanızın
gereksinimlerini karşılayacak bir model tasarlamanızda size yardımcı olacaktır.
Satır Sayısı
İki sorgu konusu arasında ilişkiler vardır. İlişkinin satır sayısı, iki sorgu konusunun her biri
için ilgili satırların sayısıdır. Satırlar, ilişkinin ifadesine göre ilişkilendirilir; bu ifade
genellikle temel tabloların birincil ve yabancı anahtarlarına başvuruda bulunur.
IBM Cognos yazılımı, bir ilişkinin satır sayısını aşağıdaki şekillerde kullanır:
v olgu verilerinin çift sayımını önlemek için
v yıldız şeması modellerinde yaygın olan döngüsel birleştirmeleri desteklemek için
v temel veri kaynağı sistemine erişimi eniyilemek için
v olgular veya boyutlar olarak hareket eden sorgu konularını tanımlamak için
© Copyright IBM Corp. 2005, 2014
1
Farklı temel tablolardan çoklu olgular kullanan bir sorgu, her bir temel olgu tablosu için ayrı
sorgulara bölünür. Her bir tekli olgu sorgusu, ilgili olgu tablosunun yanı sıra o olgu tablosuyla
ilişkili boyutlu tablolara da başvurur. Bu ayrı ayrı sorguları tek bir sonuç kümesinde
birleştirmek için başka bir sorgu kullanılır. Bu ikinci işlem genellikle ekli sorgu olarak ifade
edilir. coalesce ve tam dış birleştirme gördüğünüzde, ekli sorgunuz olduğunu bilirsiniz.
Ekli sorgu aynı zamanda IBM Cognos yazılımının farklı ayrıntı düzeylerinde verileri düzgün
şekilde ilişkilendirmesine de olanak sağlar. Bkz. “Çoklu olgu, çoklu gren sorguları” sayfa 7.
Oluşturulan Sorgularda Satır Sayısı:
IBM Cognos yazılımı hem minimum-maksimum satır sayısını hem de isteğe bağlı satır
sayısını destekler.
0:1 içinde, 0 minimum satır sayısıdır ve 1 maksimum satır sayısıdır.
1:n içinde, 1 minimum satır sayısıdır ve n maksimum satır sayısıdır.
1:1 - 1:n olarak belirtilen satır sayısı ile ilişki genellikle maksimum satır sayılarına
odaklanılırken 1 - n olarak ifade edilir.
Minimum 0 satır sayısı, ilişkinin isteğe bağlı olduğunu belirtir. Sorgunun, bir eşleşme
olmaması durumunda ilişkinin diğer tarafındaki bilgileri korumasını istiyorsanız, minimum 0
satır sayısı belirtirsiniz. Örneğin, müşteri ile gerçek satış arasındaki bir ilişki, 1:1 - 0:n olarak
belirtilebilir. Bu, herhangi bir satış verisi bulunmasa da, raporların istenen müşteri bilgilerini
göstereceğini belirtir.
Bu nedenle bir 1 - n ilişkisi şu şekilde de belirtilebilir:
v 0:1 - 0:n
v
v
v
0:1 - 1:n
1:1 - 0:n
1:1 - 1:n
Satır sayısını anlamanıza yardımcı olması için İlişki Tanımlaması iletişim kutusunda İlişki
etkisi deyimini kullanın. Örneğin, Satış Personeli (1:1) Siparişler (0:n) ile birleştirilir.
Satır sayısı, olgu sorgusu konularının algılanmasını belirlediğinden ve olgu verilerinin çift
sayımını önlemek için kullanıldığından, satır sayısının modelde doğru şekilde
yakalandığından emin olunması önemlidir.
IBM Cognos yazılımı sorgular oluştururken satır sayısını uygulamak için şu temel kuralları
izler:
v Satır sayısı bir sorgu bağlamında uygulanır.
v 1 - n satır sayısı, n tarafındaki olgu verilerini ve 1 tarafındaki boyut verilerini ifade eder.
v Bir sorgu konusu, belirli bir sorguyu yanıtlamak için gereken ilişkilere bağlı olarak bir olgu
sorgusu konusu olarak veya bir boyutlu sorgu konusu olarak hareket edebilir.
Modelinizdeki satır sayısının ifade ettiği davranışın bir değerlendirmesini görmek için Model
Advisor'ı kullanın.
2
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
Daha fazla bilgi için, bkz. “Tekli Olgu Sorgusu” sayfa 35 ve “Uyumlu Boyutlarda Çoklu
Olgu, Çoklu Gren Sorgusu” sayfa 37.
Bir Sorgu Bağlamında Satır Sayısı:
Bir sorgu bağlamında satır sayısının rolü, çoklu olgu sorguları oluşturulurken sorgunun ne
zaman ve nerede bölüneceğini belirlemek için kullanıldığından önemlidir. Boyutlar ve olgular
yanlış şekilde tanımlanırsa, performansı düşürecek şekilde gereksiz yere ekli sorgular
oluşturulabilir veya yanlış sonuçlar verecek şekilde sorgular yanlış biçimde oluşturulabilir.
Aşağıdaki örnekler, IBM Cognos yazılımı tarafından satır sayısının nasıl yorumlandığını
gösterir.
Örnek: Boyut ve Olgu Olarak Hareket Eden Sorgu Konuları:
Bu örnekte, Satış Şubesi, Sipariş Üstbilgisi'ne göreli bir boyut olarak hareket eder ve Sipariş
Üstbilgisi de, Satış Şubesi'ne göreli bir olgu olarak hareket eder.
Örnek: Sorguya Dahil Edilen Dört Sorgu Konusu:
Bu örnekte, bir sorguya dört sorgu konusu da dahil edilmiştir. Satış personeli ve Sipariş
ayrıntıları, olgular olarak değerlendirilir. Sipariş üstbilgisi ve Satış şubesi, boyutlar olarak
değerlendirilir.
Bu sorgu için oluşturulan SQL bölünecek ve Satış personeli ve Sipariş ayrıntıları olgular
olarak değerlendirilecektir. Bu iki alt sorgunun sonuçları, Satış şubesinden alınan bilgiler
Bölüm 1. Meta Verileri Modelleme için Yönergeler
3
kullanılarak eklenir. Bu, Satış şubesine göre Sipariş üstbilgisi ve Sipariş ayrıntıları bilgilerinin
yanında, Satış şubesine göre Satış personeli bilgilerini listeleyen bir rapor sunar.
Örnek: Sorguya Dahil Edilen Üç Sorgu Konusu:
Bu örnekte, bir sorguya yalnızca üç sorgu konusu dahil edilmiştir. Sipariş ayrıntıları
kullanılmaz. Sipariş üstbilgisi şimdi bir olgu olarak değerlendirilir. Satış personeli bir olgu
olarak değerlendirilmeye devam eder.
Bu örnekteki SQL aynı zamanda yukarıdakine benzer bir sonuç döndüren bir ekli sorgu da
oluşturur. Ekleme işleminin, tam dış birleştirme kullanarak işlemin her iki tarafından da
bilgileri koruduğunu unutmayın.
Belirteçler
Belirteçler, bir sorgu konusundaki veri gruplarını veya alt kümelerini temsil ederek ayrıntı
düzeyini yansıtır ve bu yinelenen verilerin doğru toplamasını sağlamak için kullanılır.
Belirteçler, veri kaynağındaki dizinler ve anahtarlar kavramıyla yakından ilişkili olup veri
kaynağındaki benzersiz anahtar ve dizin bilgileri temel alınarak içe aktarılır. Her zaman içe
aktarılan belirteçleri gözden geçirmenizi ve gerekirse bunları değiştirmenizi veya ek
belirteçler oluşturmanızı öneririz. Belirteçleri değiştirerek, veri kaynağınızdaki dizin ve
anahtar bilgilerini geçersiz kılabilir ve raporlama ve çözümleme gereksinimlerinize daha
uygun bilgilerle değiştirebilirsiniz. Belirteçler ekleyerek, uygulamanız için ilgili olan
yinelenen veri gruplarını temsil edebilirsiniz.
Benzersiz bir belirteç örneği olarak, aşağıdaki Zaman örneğinde Gün belirteci verilebilir.
Benzersiz olmayan bir belirteç örneği, Ay belirtecidir; Ay belirtecindeki anahtar, belirli bir
aydaki gün sayısı için yinelenir. Benzersiz olmayan bir belirteç tanımladığınızda, İle Grupla
belirtmeniz gerekir. Bu, IBM Cognos yazılımına, söz konusu belirteçle ilişkili anahtarlar veya
öznitelikler verilerde yinelendiğinde, çift sayımı önlemek için toplama işlevleri ve gruplama
uygulaması gerektiğini belirtir. Hem Benzersiz Tanımlanmış hem de İle Grupla seçili olan
veya her ikisi de seçili olmayan belirteçler belirtmeniz önerilmez.
Yıl Anahtarı
Ay Anahtarı
Ay Adı
Gün Anahtarı
Gün Adı
2006
200601
06 Ocak
20060101
Pazar, 1 Ocak,
2006
2006
200601
06 Ocak
20060102
Pazartesi, 2 Ocak,
2006
Bu veri kümesi için şu şekilde üç belirteç tanımlayabilirsiniz -- iki İle Grupla belirteci (Yıl ve
Ay) ve bir benzersiz belirteç (Gün). Bu kavram, düzey ve sıradüzen kavramlarına benzer
ancak bu kavramlarla aynı değildir.
4
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
Belirtecin Adı
Anahtar
Öznitelikler
Benzersiz
Tanımlanmış
İle Grupla
Yıl
Yıl Anahtarı
Yok
Hayır
Evet
Ay
Ay Anahtarı
Ay Adı
Hayır
Evet
Gün
Gün Anahtarı
Gün Adı
Evet
Hayır
Ay Anahtarı
Ay Adı
Yıl Anahtarı
Bu durumda her bir anahtar, veriler içindeki bir grubu tanımlamak için yeterince bilgi
içerdiğinden her bir belirteç için yalnızca bir anahtar kullanırız. Genellikle anahtar, ayın hangi
yıla ait olduğunu netleştirmek için yeterince bilgi içermiyorsa Ay zorluk yaratır. Ne var ki bu
durumda Ay anahtarı Yıl anahtarını içerir ve bu nedenle, yılların bir alt gruplaması olarak
ayları tanımlamak için tek başına yeterlidir.
Not: Yıl bağlamı olmadan ayları gruplayan bir belirteç oluşturabilseniz de, Şubat 2006 için
tüm verilerin birlikte gruplanması yerine, tüm yılların Şubat ayına ilişkin tüm veriler birlikte
gruplanacağından bu, raporlama için daha az yaygın olan bir tercihtir.
Çok Bölümlü Anahtarlar ile Belirteçleri Kullanma
Yukarıdaki Zaman boyutu örneğinde, bir belirteç için her bir veri kümesini tanımlamak üzere
tek bir anahtar yeterliydi ancak bu durum her zaman geçerli olmaz.
Örneğin, aşağıdaki Coğrafya boyutu, bir belirteç dışında tüm belirteçler için çok bölümlü
anahtar tanımlarını kullanır.
Bölge
Bölge Anahtarı
Eyalet/İl
Şehir Anahtarı
Kuzey Amerika
ABD
Illinois
Springfield
Kuzey Amerika
ABD
Missouri
Springfield
Kuzey Amerika
ABD
California
Dublin
Avrupa
İrlanda
n/a
Dublin
Zaman ile ilgili örneğe benzer şekilde, bu veri kümesi için şu şekilde üç belirteç
tanımlayabilirsiniz -- iki İle Grupla belirteci (Eyalet ve İl) ve bir benzersiz belirteç (Şehir).
Belirtecin Adı
Anahtar
Öznitelikler
Benzersiz
Tanımlanmış
İle Grupla
Bölge
Bölge Anahtarı
Yok
Hayır
Evet
Eyalet/İl
Eyalet/İl Anahtarı
Yok
Hayır
Evet
Yok
Evet
Hayır
Şehir
Bölge Anahtarı
Eyalet/İl Anahtarı
Şehir Anahtarı
Bu durumda, Şehir için benzersizliği sağlamak amacıyla Bölge Anahtarı, Eyalet/İl Anahtarı
ve Şehir Anahtarı kullandık. Bize sağlanan verilerde bazı şehir adları eyalet ya da
Bölüm 1. Meta Verileri Modelleme için Yönergeler
5
illerdeyinelendiğinden, dolayısıyla bölgeler için de yinelendiğinden bunu yaptık.
Belirteçler Belirtildikleri Sırayla Değerlendirilir
Belirteçlerde bir sıradüzen kavramı yoktur, ancak bir değerlendirme sırası vardır. IBM
Cognos yazılımı bir sorgu konusundaki öğeler seçimine baktığında, bunları, Belirteçler
sekmesinde belirlenen sırayla birer birer her belirteçle (anahtarlar ve öznitelikler) karşılaştırır.
Böylece IBM Cognos yazılımı, en uygun belirteci seçer.
Aşağıdaki örnekte, geçerli ay, aydaki gün sayısı ve yerelleştirilmiş ay adları öznitelikleri, Ay
anahtarıyla ilişkilendirilmiştir. Bu özniteliklerden herhangi birine başvuruda bulunan bir sorgu
gönderildiğinde, eşleşme ölçütlerinin karşılanacağı ilk belirteç Ay belirtecidir. Başka bir
öznitelik gerekli değilse, belirteçlerin değerlendirmesi Ay belirtecinde durur ve bu belirteç,
SQL'de group ve for yantümceleri için kullanılır.
Boyutun diğer özniteliklerinin de dahil olduğu durumlarda, bu öznitelikler önceki bir
belirteçle eşleşmediyse, IBM Cognos yazılımı bir eşleşme buluncaya veya son belirtece
ulaşıncaya kadar değerlendirmeye devam eder. Bu nedenle de benzersiz bir belirteç, onunla
ilişkilendirilen tüm sorgu öğelerine sahiptir. Başka bir eşleşme bulunmazsa, verilerin
gruplanma şeklini belirlemek için tüm veri kümesinin benzersiz anahtarı kullanılır.
Belirteçlerin Kullanılacağı Zamanlar
Belirteçler, veri ayrıntı düzeyiyle ilgili çeşitli sorunları çözmek için kullanılabilse de, bunları
her zaman aşağıdaki birincil durumlarda kullanmanız gerekir:
v Boyut olarak hareket eden bir sorgu konusunun birden çok ayrıntı düzeyi vardır ve olgu
verileriyle farklı anahtar kümelerinde birleştirilecektir.
Örneğin, Zaman birden çok düzeye sahiptir ve Ay Anahtarında Stok ile ve Gün
Anahtarında Satış ile birleştirilmiştir. Daha fazla bilgi için bkz. “Çoklu olgu, çoklu gren
sorguları” sayfa 7.
v Yinelenen bir anahtar veya öznitelikte diğer toplama işlevlerinin sayılması ya da
gerçekleştirilmesi gerekmez.
6
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
Örneğin, Zaman bir Ay Anahtarına ve her bir gün için yinelenen bir özniteliğe (Aydaki gün
sayısı) sahiptir. Bir raporda Aydaki gün sayısını kullanmak istiyorsanız, aydaki her bir gün
için Aydaki gün sayısı toplamını istemezsiniz. Bunun yerine, seçilen Ay Anahtarı için
Aydaki benzersiz gün sayısı değerini istersiniz. SQL'de bu XMIN(Days in the month for
Month_Key) olur. Ayrıca Cognos SQL'de bir Group by yantümcesi de vardır.
Belirteçler kullanmanız gerektiğinde daha az yaygın durumlar oluşur:
v Veri kaynağından metin BLOB verilerini alırken veri satırını benzersiz şekilde tanımlamak
istiyorsunuz.
Blob verilerinin sorgulanması için ek anahtar veya dizin tipi bilgileri gerekir. Veri
kaynağında bu bilgiler yoksa, belirteçleri kullanarak bunu ekleyebilirsiniz. Raporlama için
oluşturulan ilişkilerle çakışan, veri kaynağından içe aktarılan belirteçleri geçersiz kılın.
Sorgu konusu blob verilerine eriştiğinde çoklu kesim anahtarlarını kullanamazsınız. Özet
sorgularında blob verileri, sorgunun özet kısmından ayrı olarak alınmalıdır. Bunu yapmak
için, satırı benzersiz şekilde tanımlayan bir anahtara ihtiyacınız vardır ve anahtarın birden
çok kesimi olmamalıdır.
v Bir sorgu konusu için belirtilen benzersiz belirteçten daha az anahtar kullanan bir birleşme
belirtilir.
Birleşmeniz, ilişkilerin 0..1 1..1 tarafında benzersiz bir belirtecin anahtarları tarafından
başvurulan bir sütun alt kümesinde oluşturulduysa, bir çakışma olacaktır. Belirteci
tamamen kabul etmek için ilişkiyi değiştirerek veya ilişkiyi desteklemek için belirteci
değiştirerek bu çakışmayı giderin.
v Raporlama için oluşturulan ilişkilerle çakışan, veri kaynağından içe aktarılan belirteçleri
geçersiz kılmak istiyorsunuz.
Örneğin, birden çok sütun için iki sorgu konusunda belirteçler vardır ancak sorgu konuları
arasındaki ilişki yalnızca bu sütunların bir alt kümesini kullanmaktadır. İlişkide ek
sütunların kullanılması uygun değilse, sorgu konusunun belirteç bilgilerini değiştirin.
Çoklu olgu, çoklu gren sorguları
Boyutlu verileri içeren bir tablo, farklı anahtar sütunlarında çoklu olgu tablolarıyla
birleştirildiğinde, ilişkisel veri kaynaklarında çoklu olgu ve çoklu gren sorguları oluşur.
Bu bölümde, terim boyutunun kavramsal yönden kullanıldığını unutmayın. 1:1 veya 0:1 satır
sayısı içeren bir sorgu konusu, bir boyut olarak hareket eder. Daha fazla bilgi için bkz. “Satır
Sayısı” sayfa 1.
Boyutlu sorgu konusu genellikle yinelenen anahtar içeren öznitelik verilerinin ayrı gruplarına
veya düzeylerine sahiptir. IBM Cognos Studio ürünleri, otomatik olarak raporda bulunan en
düşük ortak ayrıntı düzeyine toplanır. Yinelenen verileri içeren sütunlarda toplamlar
oluşturulurken çift sayım olasılığı oluşur. Verilerin ayrıntı düzeyi doğru şekilde
modellendiğinde çift sayım önlenebilir.
Not: En düşük ortak düzeyin altında bir ayrıntı düzeyinde verileri raporlayabilirsiniz. Bu,
daha yüksek ayrıntı düzeyindeki verilerin yinelenmesine neden olur, ancak belirteçler düzgün
şekilde uygulandıysa, toplamlar etkilenmeyecektir.
Bu örnek, iki boyutlu sorgu konusunu (Zaman ve Ürün) paylaşan iki olgu sorgu konusunu
(Satış ve Ürün tahmini) gösterir.
Bölüm 1. Meta Verileri Modelleme için Yönergeler
7
Bu örnekte, ayrıntı düzeyi sorununun merkez noktası Zaman'dır. Satış, Gün anahtarında
Zaman ile birleştirilmiş ve Ürün tahmini de Ay anahtarında Zaman ile birleştirilmiştir. Farklı
birleşim anahtarları nedeniyle, Zaman üzerinde minimum iki belirteç net şekilde
tanımlanmalıdır. Örneğin, Ay ve Gün için belirteçlerin tanımlanmış anahtarları vardır. Gün,
Zaman için benzersiz anahtardır ve aydaki her bir gün için Ay anahtarları yinelenir.
Örneğin, Ay için belirteç şu şekildedir.
8
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
Ürün sorgu konusu en az üç belirtece sahip olabilir: Ürün yelpazesi, Ürün tipi ve Ürün. Ürün
anahtarında her iki olgu tablosuyla ilişkiye sahiptir. Ürün sorgu konusuyla ilgili bir ayrıntı
düzeyi sorunu yoktur.
Varsayılan olarak, en düşük ortak ayrıntı düzeyindeki her bir olgu tablosundan kayıtları almak
için bir rapor toplanır. Satış içindeki Miktarı, Ürün tahmini içindeki Beklenen hacmi, Zaman
içindeki Ayı ve Ürün içindeki Ürün adını kullanan bir rapor oluşturursanız, bu rapor, en düşük
ortak ayrıntı düzeyindeki her bir olgu tablosundan kayıtları alır. Bu örnekte bu, ay ve ürün
düzeyindedir.
Birden çok ayrıntı düzeyinde veri bulunduğunda çift sayımı önlemek üzere Zaman sorgu
konusu için en az iki belirteç oluşturun. Örnek için bkz. “Belirteçler” sayfa 4.
Ay
Ürün adı
Miktar
Beklenen hacim
Nisan 2007
Aloe Relief
1.410
1.690
Nisan 2007
Course Pro Umbrella
132
125
Şubat 2007
Aloe Relief
270
245
Şubat 2007
Course Pro Umbrella
Şubat 2006
Aloe Relief
1
88
92
Zaman sorgu konusunda belirteçleri düzgün şekilde belirtmezseniz, yanlış toplama oluşabilir.
Örneğin, Ürün tahmininde Ay düzeyinde bulunan Beklenen hacim değerleri, Zaman sorgu
konusunda her gün için yinelenir. Belirteçler düzgün şekilde ayarlanmazsa, Beklenen hacim
için değerler, aydaki gün sayısına çarpılır.
Ay
Ürün adı
Miktar
Beklenen hacim
Nisan 2007
Aloe Relief
1.410
50.700
Nisan 2007
Course Pro Umbrella
132
3.750
Şubat 2007
Aloe Relief
270
7.134
Şubat 2007
Course Pro Umbrella
29
Bölüm 1. Meta Verileri Modelleme için Yönergeler
9
Ay
Ürün adı
Miktar
Beklenen hacim
Şubat 2006
Aloe Relief
88
2.576
Beklenen hacim sütunundaki farklı sayılara dikkat edin.
Model Tasarımı ile İlgili Dikkat Edilecek Noktalar
Bir model oluşturulurken, tüm uygulamalar için uygun bir model sunacak tek bir iş akışı
olmadığının anlaşılması önemlidir. Modelinize başlamadan önce, işlevselliğe, kullanım
kolaylığına ve performansa ilişkin uygulama gereksinimlerinin anlaşılması önemlidir. Veri
kaynağının tasarımı ve uygulama gereksinimleri, bu bölümde sorulan soruların çoğunun
yanıtını belirleyecektir.
İlişkileri ve Belirteçleri Nerede Oluşturmalısınız?
Sık sorulan bir soru da ilişkilerin nerede oluşturulacağıdır. İlişkiler, veri kaynağı sorgu
konuları arasında mı, model sorgu konuları arasında mı yoksa her ikisi arasında mı
oluşturulmalıdır? Bu, modellemekte olduğunuz veri kaynağının karmaşıklığına bağlı
olduğundan, yanıt farklılık gösterir.
Veri kaynağı sorgu konuları ile çalışılırken, ilişkiler ve belirteçler birbirine ait olur.
Model sorgu konuları ile çalışılırken, ilişkiler ve belirteçler kullanılmasına ilişkin, dikkate
almanız gereken yan etkiler vardır:
v Model sorgu konusu bir görünüm olarak hareket etmeye başlar; böylece bir sorgu konusu
için SQL Oluşturma tipinde Görünüm Olarak veya Küçültülmüş ayarını geçersiz kılar.
Başka bir deyişle, sorgu konusundaki hangi öğelere başvurulursa başvurulsun, SQL aynı
kalır. Daha fazla bilgi için bkz. “Küçültülmüş SQL Nedir?” sayfa 11.
v Model sorgu konusu, bağımsız bir nesne olur.
Başka bir deyişle, başvurulan nesneler arasındaki ilişkiler dışında temel ilişkiler artık
uygulanmaz. Önceden temel sorgu konularının meta verilerinden çıkarsanan ek ilişkiler
oluşturulması gerekebilir.
v Bir model sorgu konusunda bir belirteç oluşturulduğunda, ayrıca bir ilişki oluşturulmadığı
sürece belirteç yok sayılır.
Küçültülmüş SQL ayarını kasıtlı olarak geçersiz kılan ve modeli basitleştiren bir model
sorgu konusundaki ilişki örneği şudur. Bu örnekte, Sipariş Üstbilgisi ve Sipariş Ayrıntıları,
tek bir olgu olarak hareket etmeleri için birleştirilmiştir. Bunlar kendi klasörlerine yerleştirilir
ve Sipariş Üstbilgisi ile Sipariş Ayrıntıları arasındaki ilişki dışında, bunlara yönelik tüm
ilişkiler silinir. Bir model sorgu konusu oluşturulup ilişkiler eklendikten sonra önem taşıyacak
tek ilişki budur.
Modelde ilişkilerin ve belirteçlerin nerede belirtileceğine karar vermek için, küçültülmüş
SQL'in uygulamanız üzerindeki etkisini anlamanız gerekir.
10
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
İlişkiler, belirteçler ve küçültülmüş SQL hakkında daha fazla bilgi için, IBM Cognos
Framework Manager Kullanıcı Kılavuzu içindeki Model Advisor konularına bakın.
Küçültülmüş SQL Nedir?
Küçültülmüş SQL kullandığınızda, oluşturulan SQL yalnızca seçilen sorgu öğelerine ilişkin
değerleri elde etmek için gereken minimum birleşmeler ve tablolar kümesini içerir.
Küçültülmüş SQL'in ne anlama geldiğine ilişkin bir örneği görmek için, şu Ürün tablolarını
kullanabilirsiniz. Ürün Yelpazesi, Ürün Tipi, Ürün ve Ürün (Çok Dilli) adlı dört sorgu konusu
da birbiriyle birleşir.
Bunlar bir sorgu konusunda birleştirilebilir.
Ürünler model sorgu konusunu bir bütün olarak sınarsanız, sorgunun from yantümcesinde
dört tabloya başvurulduğunu görürsünüz.
select
PRODUCT_LINE.PRODUCT_LINE_CODE as Product_Line_Code,
PRODUCT_LINE.PRODUCT_LINE_EN as Product_Line,
PRODUCT_TYPE.PRODUCT_TYPE_CODE as Product_Type_Code,
PRODUCT_TYPE.PRODUCT_TYPE_EN as Product_Type,
PRODUCT.PRODUCT_NUMBER as Product_Number,
PRODUCT_MULTILINGUAL.PRODUCT_NAME as Product_Name
PRODUCT_MULTILINGUAL.DESCRIPTION as Product_Description,
PRODUCT.INTRODUCTION_DATE as Introduction_Date,
Bölüm 1. Meta Verileri Modelleme için Yönergeler
11
PRODUCT.PRODUCT_IMAGE as Product_Image,
PRODUCT.PRODUCTION_COST as Production_Cost,
PRODUCT.MARGIN as Margin
from
gosl_82..gosl.PRODUCT_LINE PRODUCT_LINE,
gosl_82..gosl.PRODUCT_TYPE PRODUCT_TYPE,
gosl_82..gosl.PRODUCT PRODUCT,
gosl_82..gosl.PRODUCT_MULTILINGUAL PRODUCT_MULTILINGUAL
where
(PRODUCT_MULTILINGUAL."LANGUAGE" - N’EN’)
and
(PRODUCT_LINE.PRODUCT_LINE_CODE = PRODUCT_TYPE.PRODUCT_LINE_CODE)
and
(PRODUCT_TYPE.PRODUCT_TYPE_CODE = PRODUCT.PRODUCT_TYPE_CODE)
and
(PRODUCT.PRODUCT_NUMBER = PRODUCT_MULTILINGUAL.PRODUCT_NUMBER
Yalnızca Ürün adını sınarsanız, sonuçta elde edilen sorgunun, gerekli tablo olan Ürün (Çok
Dilli) tablosunu kullandığını görürsünüz. Bu, küçültülmüş SQL'in etkisidir.
select
PRODUCT_MULTILINGUAL.PRODUCT_NAME as Product_Name
from
gosl_82..gosl.PRODUCT_MULTILINGUAL PRODUCT_MULTILINGUAL
where
(PRODUCT_MULTILINGUAL."LANGUAGE" - N’EN")
Örnek: Küçültülmüş SQL Önemli Olduğunda
Normalleştirilmiş bir veri kaynağını modelliyorsanız, bazı isteklerde kullanılan tablo sayısını
azaltıp daha iyi performans göstereceğinden, küçültülmüş SQL daha fazla ilginizi çekebilir.
Bu durumda, veri kaynağı sorgu konuları arasında ilişkiler ve belirteçler oluşturmak ve sonra
ilişkiler içermeyen model sorgu konuları oluşturmak en iyisi olacaktır.
Nesneler arasında ilişkiler olmadığında yıldız şeması grupları oluşturamayacağınıza dair
yanlış bir düşünce yaygındır. Durum böyle değildir. Gruba dahil edilecek model sorgu
konularını seçin ve Yıldız Şeması Gruplama sihirbazını kullanın. Veya kısayollar
oluşturabilir ve bunları yeni bir ad alanına taşıyabilirsiniz. İlişkiler için kısayollarınız olması
gerekmez; bu özellik çizgede tamamen görseldir. Studio ürünlerinde sorgu oluşturma ve
sunum üzerindeki etki aynıdır.
Örnek: Küçültülmüş SQL, Öngörülebilir Sorgular Kadar Önemli
Olmadığında
Veri kaynağında, tek bir veri nesnesiymiş gibi hareket ettiklerinden emin olmanız için
kapsüllemeniz gereken bazı öğeler olabilir. Buna örnek olarak, her zaman bir olguyla
birleştirilmiş olması gereken bir güvenlik tablosu verilebilir. Sample Outdoors Satış
modelinde, Sipariş Üstbilgisi ve Sipariş Ayrıntıları, birlikte bir olguyu temsil eden ve her
zaman birlikte sorgulanmasını istediğiniz bir tablolar kümesidir. Örnek için bkz. “İlişkileri ve
Belirteçleri Nerede Oluşturmalısınız?” sayfa 10.
Meta Veri Önbelleğe Alma Nedir?
IBM Cognos Framework Manager, veri kaynağından içe aktarılan meta verileri depolar.
Ancak modelde uyguladığınız belirli eylemlere ve düzenleyici ayarlarına bağlı olarak, bir
sorgu hazırlanırken bu meta veriler kullanılmayabilir.
Çalıştırma zamanında gelişmiş model taşınabilirliğine izin ver düzenleyicisini
etkinleştirirseniz, Framework Manager bir sorgu oluşturmadan önce her zaman meta veriler
hakkında bilgi için veri kaynağını sorgular. Bu düzenleyiciyi etkinleştirmediyseniz, çoğu
12
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
durumda Framework Manager, veri kaynağını sorgulamak yerine, modelde depolanan meta
verilere erişir. Ana kural dışı durumlar şunlardır:
v Bir veri kaynağı sorgu konusundaki SQL değiştirildiğinde. Bu, makroların kullanımını
içerir.
v Bir veri kaynağı sorgu konusuna hesaplama veya süzgeç eklendiğinde.
Not: Oluşturulan meta veri sorguları, çoğu ilişkisel veritabanı yönetim sistemi satıcısı
tarafından desteklenir ve çoğu raporlama uygulaması üzerinde belirgin bir etki oluşturmaz.
Sorgu Konuları ve Boyutlar
Sorgu konuları ve boyutlar, farklı amaçlara hizmet eder. Boyut, OLAP davranışını sunacak
şekilde, ilişkisel kaynakların boyutlu modellemesi için kullanılırken, sorgu konusu, ilişkisel
sorgular oluşturmak için kullanılır ve yıldız şeması kuralları kullanılarak oluşturulabilir.
Sorgu konuları, boyutların temeli olduğundan, herhangi bir boyutlu model için temel başarı
ölçütü, düzgün bir ilişkisel model olmasıdır.
Yalnızca raporlarda detayı azaltmayı ve detaya inmeyi etkinleştirmek, Studio ürünlerinde üye
işlevlerine erişmek veya IBM Cognos Analysis Studio olanağını kullanmak istiyorsanız
boyutlu model gereklidir. Birçok uygulama için, OLAP işlevselliğine gerek yoktur. Örneğin,
uygulamanız, detayı azaltma ve detaya inme gereksinimi olmadan birincil olarak geçici sorgu
veya raporlama içindir. Ya da bir IBM Cognos ReportNet modelini koruyorsunuzdur. Bu
durumlarda, yalnızca sorgu konularını temel alarak paketleri yayınlamayı seçebilirsiniz.
Sorgu konuları için belirteçler, normal boyutlar için düzeyler ve sıradüzenlerle aynı değildir,
ancak bunlar tek bir sıradüzenle yakından ilişkilendirilebilir. Boyutlar için temel olarak sorgu
konularınızı kullanmayı planlıyorsanız, oluşturmayı planladığınız sıradüzenlerin yapısını
dikkate almanız ve toplama sırasında doğru sonuçları destekleyecek belirteçleri
oluşturduğunuzdan emin olmanız gerekir. Aşağıdakilerden emin olun:
v Sorgu konusu, normal boyutta sıradüzenin her bir düzeyi için belirtilmiş bir belirtece sahip
olmalıdır.
v Belirteçler, normal boyuttaki düzeylerle aynı sırada belirtilmelidir.
v Farklı şekilde toplama yapan birden çok sıradüzeniniz olmasını planlıyorsanız, diğer
sıradüzen için kaynak olarak farklı belirteçler içeren ek bir sorgu konusu oluşturmanız
gerekebilir.
Doğru sonuçlar ve yüksek performans sunan eksiksiz bir ilişkisel model oluşturarak, boyutlu
model geliştirmeye ilişkin güçlü bir temeliniz olur. Ayrıca, Studio ürünlerinin kullanımına
sunulan nesneler ile veri kaynağı arasında, sorgu konuları veya boyutlar olarak bir model
nesneleri katmanı bulunmasını sağlayarak, kullanıcılarınızı değişikliğe karşı daha iyi
koruyabilirsiniz.
Model Nesneleri ve Kısayollar
Model nesneleri ile kısayollar arasındaki temel fark, model nesnelerinin öğeleri dahil etme
veya kapsam dışı bırakma ve öğeleri yeniden adlandırma konusunda size özgürlük
sunmasıdır. Dahil olan sorgu öğelerini sınırlamanız veya öğelerin adlarını değiştirmeniz
gerekiyorsa, kısayollar yerine model nesnelerini kullanmayı tercih edebilirsiniz.
Kısayollar, sunum açısından bakıldığında, model nesnelerinden daha az esnektir, ancak hedef
nesne güncellendiğinde otomatik olarak güncellendiklerinden daha az bakım gerektirirler.
Bakım konusuna ilişkin endişeleriniz varsa ve sorgu konusunun görünümünü özelleştirmeniz
gerekmiyorsa, kısayolları kullanın.
IBM Cognos Framework Manager iki tür kısayola sahiptir:
v normal kısayollar, bunlar hedef nesneye ilişkin basit bir başvurudur.
Bölüm 1. Meta Verileri Modelleme için Yönergeler
13
v diğer ad kısayolları, bunlar tamamen bağımsız davranışa sahip olarak, orijinal nesnenin bir
kopyasıymış gibi hareket eder. Diğer ad kısayolları yalnızca sorgu konuları ve boyutlar için
kullanılabilir.
Normal kısayollar genellikle yıldız şeması grupları ile uyumlu boyutlar olarak kullanılır ve
birçok yerde tamamen aynı ada ve görünüme sahip birden çok başvuru oluşturur. Aşağıdaki
örnekte, Ürünler ve Sipariş Zamanı için oluşturulan kısayollar, başvurular olarak hareket eder.
Hem Ürün Tahmini hem de Satış Hedefi içinden Ürünler getiren bir sorgu yazılırsa, bu sorgu,
orijinali temel alan Ürünler tanımını kullanır ve bu tanım sorguda yalnızca bir defa
görüntülenir.
Diğer ad kısayolları genellikle oyun boyutlarında veya paylaşılan tablolarda kullanılır. Oyun
boyutuna ilişkin bir örnek bu belgede zaten bulunduğundan, paylaşılan tablolar durumuna göz
atacağız. Bu örnekte, Satış Personeli ve Satış Şubesi farklı sıradüzenler olarak
değerlendirilebilir. Veri bilgimize dayanarak, personel şubeler arasında hareket
edebildiğinden, bizim Satış Şubesi'ne ve Satış Personeli'ne karşı siparişleri bağımsız olarak
veya birlikte raporlayabilmemiz gerektiğini biliyoruz. Bunu başarmak için, Satış Personeli
sıradüzeninde bir düzey olarak kullanılabilen, Satış Şubesi'ne ilişkin bir diğer ad
oluşturmamız gerekir.
14
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
Yeni diğer ad kısayolu yerindeyken, aynı anda geçerli şube bilgileri ile birlikte, satış şubesi
tarafından yapılan siparişleri ve satış personeli tarafından yapılan siparişleri gerektiren
sorgular oluşturulabilir.
Önceki sürümden bir modeli açtığınızda, Kısayol İşleme düzenleyicisi, Otomatik olarak
ayarlanır. Otomatik değeri kullanıldığında, kısayollar önceki sürümdekilerle aynı şekilde
çalışır; başka bir deyişle, hedefi ile aynı klasörde bulunan bir kısayol bir diğer ad veya
bağımsız eşgörünüm gibi hareket ederken, modelde başka bir yerde bulunan bir kısayol da
orijinale ilişkin başvuru olarak hareket eder. İşleme Biçimi özelliğinden yararlanmak için,
modeli doğrulamanız ve onarım sırasında düzenleyiciyi Belirtik olarak değiştirmeniz önerilir.
Onarım işlemi, Otomatik ayarının izlediği kuralları temel alarak İşleme Biçimi özelliğindeki
doğru değere ilişkin kısayolları değiştirir; başka bir deyişle, kısayolların İşleme Biçimi
özellikleri üzerinde bir veya daha fazla değişiklik yapmayı seçmediğiniz sürece modelinizin
davranışında bir değişiklik olmayacaktır.
Yeni bir model oluşturduğunuzda, Kısayol İşleme düzenleyicisi her zaman Belirtik olarak
ayarlanır.
Düzenleyici Belirtik olarak ayarlandığında, İşleme Biçimi özelliğinden kısayol davranışı
alınır ve kısayolların modelin neresinde bulunduğunu düşünmeden kısayolların nasıl
davranacağı konusunda tam denetim elde edersiniz.
Klasörler ve Ad Alanları
Ad alanlarıyla ilgili bilinmesi gereken en önemli şey, raporları yazmaya başladıktan sonra,
yayınlanan ad alanlarının adları üzerinde yaptığınız tüm değişikliklerin, IBM Cognos
içeriğinizi etkileyecek olmasıdır. Ad alanının adı değiştirildiğinde, meta verilerde yayınlanan
nesnelerin tanıtıcıları değiştiğinden bu durum oluşur. Ad alanı, IBM Cognos Framework
Manager'da nesne tanıtıcısının parçası olarak kullanıldığından, her bir ad alanının modelde
benzersiz bir adı olması gerekir. Bir ad alanındaki her bir nesnenin de benzersiz bir adı
olmalıdır. Yıldız şeması grupları stratejisinin bir parçasını, ad alanındaki her bir nesne için
otomatik olarak benzersiz bir tanıtıcı oluşturulacak şekilde ayrı bir ad alanına kısayolların
yerleştirilmesi oluşturur. İlişkisel veritabanları için bu, farklı yıldız şeması gruplarındaki
uyumlu boyutlara kısayollar için aynı adı kullanmamıza olanak sağlar.
Güncellenen modele karşı bir sorgu, rapor veya çözümleme çalıştırmayı bir sonraki
deneyişinizde bir hata alırsınız. Yayınladığınız ad alanını yeniden adlandırmanız gerekirse,
hangi raporların etkilendiğini belirlemek için Yayınlama Etkisini Çözümle seçeneğini
kullanın.
Klasörler, ad alanlarından daha basittir. Bunlar yalnızca düzenleme amaçlı olup nesne
tanıtıcılarını veya içeriğinizi etkilemez. Konuya veya işlevsel alana göre nesneleri
düzenlemek için klasörler oluşturabilirsiniz. Bu, özellikle büyük projelerde meta verileri
bulmanızı kolaylaştırır.
Klasörlerin en büyük zorluğu, tüm sorgu konuları, boyutlar ve kısayollar için benzersiz adlar
gerektirmeleridir. Bu nedenle, paylaşılan nesnelerin barındırılması için ideal değildir.
Model Hesaplamaları için İşlemlerin Sırasını Ayarlama
Bazı durumlarda, genellikle oranla ilgili hesaplamalarda, matematiksel işlemden önce
hesaplama terimlerinde toplama gerçekleştirilmesi kullanışlı olacaktır.
Örneğin, aşağıdaki Sipariş ayrıntıları olgusu, her bir siparişle ilgili bilgileri içerir:
Bölüm 1. Meta Verileri Modelleme için Yönergeler
15
Marj, kâr oranını hesaplayan bir hesaplamadır:
Margin = (Revenue - Product cost) / Revenue
Sipariş ayrıntıları olgusunu kullanarak her bir ürüne ilişkin Gelir, Ürün maliyeti ve Marj'ı
göstermek için bir sorgu çalıştırırsak, aşağıdaki sonuçları alırız:
Ürün numarası
Gelir
Ürün maliyeti
Kenar Boşluğu
1
23.057.141 ABD Doları 11.292.005 ABD Doları %61038
2
11.333.518 ABD Doları 6.607.904 ABD Doları
%49606
Marj değerinin yanlış olabileceğine dikkat edin. Bu, Marj hesaplamasında kullanılan
işlemlerin sırasından kaynaklanır. Marj şu şekilde hesaplanır:
Margin = sum( (Revenue - Product cost) / Revenue )
Toplama, matematiksel işlemden sonra gerçekleşmiştir ve bu durumda istenmeyen sonuçlar
üretilir.
Marj için istenen değerleri üretmek üzere, toplamayı matematiksel işlemden önce yapmamız
gerekir:
Margin = ( sum(Revenue) - sum(Product cost) ) / sum(Revenue)
Bu aşağıdaki sonuçları üretir:
Ürün numarası
Gelir
Ürün maliyeti
Kenar Boşluğu
1
23.057,141 ABD Doları 11.292.005 ABD Doları %51,03
2
11.333.518 ABD Doları 6.607.904 ABD Doları
%41,70
IBM Cognos Framework Manager'da Marj için bağımsız bir hesaplama oluşturup bunun
Düzenli Toplama özelliğini Hesaplanmış olarak ayarlayarak bunu başarabilirsiniz.
Hesaplamanın ifadesindeki her bir sorgu, Düzenli Toplama özelliğinde belirtildiği gibi
toplanır. Gelir ve Ürün maliyeti için Düzenli Toplama özellikleri Toplam olarak ayarlanır ve
böylece hesaplama yapılırken, bu terimleri toplamak için toplam kullanılır.
16
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
Not: Hesaplanan toplama tipi, sorgu konuları içinde gömülü bulunan hesaplamalar için
desteklenmez. Yalnızca bağımsız hesaplamalar için ve ölçü boyutlarına gömülen ve aynı ölçü
boyutundan ölçüleri temel alan hesaplamalar için desteklenir.
Örneğin, Satış ölçü boyutuna gömülen Marj hesaplamasını düşünün:
Bu örnekte Marj, aynı ölçü boyutunda (Satış) bulunan Gelir ve Ürün maliyeti ölçülerini temel
alır. Marj için Düzenli Toplama özelliği Hesaplanmış olarak ayarlanırsa, şu şekilde toplanır:
Margin = sum(Revenue - Product cost ) / sum(Revenue)
Marj, Ürün maliyeti ve Gelir'in kaynak sorgu öğelerini temel alıyorsa (Satış (model).Ürün
maliyeti, Satış (model).Gelir), hesaplanan toplama desteklenmez ve toplama otomatik olarak
hareket eder. Bu durumda Marj şu şekilde toplanır:
Margin = sum( Revenue - Product cost) / Revenue)
Sorgu öğelerinin toplanma şeklini değiştirme hakkında daha fazla bilgi için, bkz. IBM Cognos
Framework Manager Kulanıcı Kılavuzu.
Model Boyutu Etkisi
Modelinizin boyutu, Framework Manager uygulamanızın verimliliğini etkileyebilir.
Çok büyük modeller, daha uzun işleme sürelerine ve aşırı durumlarda belleğin dolmasına
neden olacaktır. Yayınlama Etkisini Çözümle, Rapor Bağımlılıklarını Bul, Paketleri Yayınla
ve Model Advisor'ı Çalıştır gibi eylemler, 50 megabayt'ın altındaki modellerde en iyi şekilde
performans gösterir.
Boyutlu Modelleme Kavramları
Meta verilerin OLAP sunumunu, detayı azaltma ve detaya inmeyi ve çeşitli OLAP işlevlerini
etkinleştirmek için normal boyutlar ve ölçü boyutları kullanılır. İlişkisel veri kaynağı ile IBM
Cognos Analysis Studio'yu kullanmak istiyorsanız, yıldız şeması grupları (birden çok boyut
içeren tek bir olgu) kullanmanız gerekir.
Modelinizi oluştururken, yıldız şeması kavramlarının uygulandığı bir ilişkisel modeli temel
alarak model normal boyutlarını ve model ölçü boyutlarını oluşturmanız önerilir.
Veri kaynağı sorgu konularını veri kaynağı boyutlarına dönüştürebilseniz de, veri kaynağı
boyutları, sorgu konularına veya model boyutlarına kıyasla sınırlı işlevsellik içerir ve genel
kullanım için önerilmez.
Normal Boyutlar
Normal boyutlar, ölçü boyutlarında modellenen veriler için bağlam sağlayan açıklayıcı
verileri temsil eder. Bir normal boyut, düzeyler adı verilen bilgi gruplarına ayrılır. Böylece
çeşitli düzeyler, sıradüzenler halinde düzenlenebilir. Örneğin, bir ürün boyutu, Ürün adlı tek
bir sıradüzende düzenlenmiş Ürün Yelpazesi, Ürün Tipi ve Ürün düzeylerini içerebilir. Başka
bir örnek de, iki sıradüzen halinde düzenlenmiş Yıl, Çeyrek, Ay, Hafta ve Gün düzeylerini
içeren bir zaman boyutudur. Tek bir YÇAG sıradüzeni, Yıl, Çeyrek, Ay ve Gün düzeylerini
içerirken; diğer YHG sıradüzeni de Yıl, Hafta ve Gün düzeylerini içerir.
En basit tanımıyla bir düzey, her biri tek bir sorgu öğesine başvuran bir iş anahtarı ve bir
başlıktan oluşur. Bir düzeyin eşgörünümü (veya satırı), o düzeyin bir üyesi olarak tanımlanır.
Bölüm 1. Meta Verileri Modelleme için Yönergeler
17
Geçerli ve daha yüksek düzeylerin iş anahtarlarının değerlerini içeren bir üye benzersiz adıyla
tanımlanır. Örneğin, [gosales].[Products].[ProductsOrg].[Product]->[All
Products].[1].[1].[2], [gosales] ad alanındaki [Products] boyutunun ProductsOrg
sıradüzeninin dördüncü düzeyinde (Product) bulunan bir üyeyi tanımlar. Bu ürün için başlık
TrailChef Canteen olup bu, meta veri ağacında ve raporda gösterilen addır.
Düzeyin iş anahtarı bir düzey için her bir veri kümesinin tanımlanmasında yeterliyse, o düzey
benzersiz olarak tanımlanabilir. Birçok farklı ürün tipine atanmış ürün numaraları
olmadığından, Sample Outdoors Satış modelinde Ürün düzeyinin üyeleri, Ürün tipi
tanımlamasını gerektirmez. Daha yüksek ayrıntı düzeylerinden anahtarlar gerekli olduğundan,
benzersiz olarak tanımlanmayan bir düzey, çok bölümlü anahtarlar kullanan bir belirtece
benzer. Bkz. “Çok Bölümlü Anahtarlar ile Belirteçleri Kullanma” sayfa 5. Kök üyelerin
içindeki üyeler benzersiz değilse, ancak düzey benzersiz olarak tanımlanırsa, benzersiz
olmayan üyeler için veriler tek bir üye olarak raporlanır. Örneğin, Şehir benzersiz olarak
tanımlanırsa ve ada göre tanımlanırsa, Londra, İngiltere ve Londra, Kanada için veriler
birleştirilir.
Ölçü Boyutları
Ölçü boyutları, normal boyutlar tarafından açıklanan niceliksel verileri temsil eder. Çeşitli
OLAP ürünlerindeki birçok terimlerle bilindiği kadarıyla bir ölçü boyutu, olgu verilerini
içeren bir nesnedir. Ölçü boyutları, bir olgu sorgusu konusunu boyutlu sorgu konusuyla
birleştirmek için kullanılan yabancı anahtarları içermediğinden, olgu sorgusu konularından
farklılık gösterir. Bunun nedeni, ölçü boyutunun bir ilişkisel veri nesnesiymiş gibi
birleştirilmek üzere tasarlanmamış olmasıdır. Sorgu oluşturma amacıyla bir ölçü boyutu,
temel sorgu konuları aracılığıyla normal bir boyutla ilişkisini türetir. Benzer şekilde, diğer
ölçü boyutlarıyla ilişki de uyumlu boyutlar olarak davranacak şekilde oluşturulmuş sorgu
konularını temel alan normal boyutlar aracılığıyla gerçekleşir. Çoklu olgu ve çoklu gren
sorgulamayı etkinleştirmek için, normal boyutlar ve ölçü boyutları oluşturmadan önce uygun
şekilde oluşturulmuş sorgu konularınızın ve belirteçleriniz olması gerekir.
Kapsam İlişkileri
Kapsam ilişkileri, ölçülerin raporlama için kullanılabilir olduğu düzeyi tanımlamak üzere
yalnızca ölçü boyutları ile normal boyutlar arasında bulunur. Bunlar birleşimler ile aynı
değildir ve Where yantümcesini etkilemezler. Bir sorgunun nasıl oluşturulacağını belirlemek
için bir kapsam ilişkisinde ayarlanmış koşullar veya ölçütler yoksa bu, yalnızca belirtilen bir
olgu ile bir boyutun sorgulanıp sorgulanamayacağını belirtir. Bir kapsam ilişkisinin olmayışı,
çalıştırma zamanında bir hataya yol açabilir veya raporda başka öğeler olduğunda olgu
verilerinin beklenenden yüksek bir düzeyde toplanmasına neden olabilir.
Ölçü boyutu için kapsam ilişkisi ayarlarsanız, ölçü boyutundaki tüm ölçüler için aynı ayarlar
geçerli olur. Veriler, ölçü boyutundaki ölçüler için farklı bir düzeyde raporlanırsa, bir ölçüde
kapsamı ayarlayabilirsiniz. Verilerin raporlanabileceği en düşük düzeyi belirtebilirsiniz.
Bu örnekte, Satış Hedefi ölçü boyutu, Sipariş Zamanı Boyutunun Sipariş Ayı düzeyi ve Ürün
Boyutunun Ürün düzeyi kapsamında yer alan yalnızca bir ölçüye sahiptir. Başka bir deyişle,
kullanıcılarınız ay düzeyinin ötesinde detaya inmeyi denediğinde, yinelenen verileri görürler.
18
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
İlişkisel Model Oluşturma
İlişkisel veri kaynaklarının boyutlu modellemesi, IBM Cognos Framework Manager'da
kullanılabilir, ancak bu düzgün bir ilişkisel modelin varlığına bağlıdır.
IBM Cognos ReportNet, çoklu olgu sorgulamayı etkinleştirmek ve çift sayımı önlemek için
bazı boyutlu yetenekler sağlamıştır. IBM Cognos ReportNet'ten sonra gelen IBM Cognos
yazılımı, ilişkisel veri kaynakları ile OLAP yeteneğinin ve meta verilerin boyutlu temsili için
özel olarak tasarlanmış özelliklere sahiptir. IBM Cognos ReportNet olanağında ilişkisel
modellemeye uygulanan kavramlar, Framework Manager Kullanıcı Kılavuzu'nda belgelenen
birkaç değişiklik ile birlikte korunmuştur.
Yeni bir Framework Manager modeli oluşturduğunuzda, boyutlu modelleme yeteneklerini
kullanmayı tasarlamasanız da, sorgu oluşturmayı tanımlamak için ortak bir adım kümesini
izlersiniz. Raporlarda detayı azaltmayı veya detaya inmeyi etkinleştirmek, Studio ürünlerinde
üye işlevlerine erişmek veya bir ilişkisel veri kaynağını IBM Cognos Analysis Studio
olanağında kullanmak istediğinizde onu boyutlu olarak modellemeniz gerekir.
İlişkisel Modelleme Temelini Tanımlama
Model, bir veya daha fazla ilişkili raporlama uygulaması için gereken ilgili nesneler
kümesidir. Düzgün bir ilişkisel model bir boyutlu modelin temelidir.
İlişkisel modelleme temelini tanımladığınızda şunları dikkate alın:
v Meta verileri içe aktarma. İçe aktarma hakkında bilgi için, IBM Cognos Framework
Manager Kullanıcı Kılavuzu'na bakın.
v “İçe Aktarılan Meta Verileri Doğrulama”.
v “Belirsiz İlişkileri Çözme” sayfa 20.
v Olgular ve boyutlar için satır sayısını çözümleyerek ve ilişkilerin ve belirteçlerin nereye
koyulacağına karar vererek yıldız şeması kavramlarını kullanıp ilişkisel modelin
kolaylaştırılması “Model Tasarımı ile İlgili Dikkat Edilecek Noktalar” sayfa 10.
v Gerekirse, veri güvenliği ekleyin. Veri güvenliği hakkında bilgi için, Framework Manager
Kullanıcı Kılavuzu'na bakın.
Daha sonra, gerekirse modelin boyutlu temsilini tanımlayabilir ve sunum için modeli
düzenleyebilirsiniz.
İçe Aktarılan Meta Verileri Doğrulama
Meta verileri içe aktardıktan sonra, içe aktarılan meta verileri kontrol etmeniz gerekir.
Şu alanları doğrulayın:
v ilişkiler ve satır sayısı
v belirteçler
Bölüm 1. Meta Verileri Modelleme için Yönergeler
19
v sorgu öğeleri için Kullanım özelliği
v sorgu öğeleri için Düzenli Toplama özelliği
Burada ilişkiler ve satır sayısı açıklanmaktadır. Kullanım ve Düzenli Toplama özellikleri
hakkında bilgi için, Framework Manager Kullanıcı Kılavuzu'na bakın.
Olgular ve Boyutlar için Satır Sayısını Çözümleme:
Bir ilişkinin satır sayısı, belirli bir anahtar kümesi (veya birleşme) temel alınarak başka bir
tablonun satırlarıyla ilgili olan bir tablonun satır sayısını tanımlar. Satır sayısı, hangi sorgu
konularının olgular veya boyutlar olarak hareket ettiğini belirlemek için IBM Cognos yazılımı
tarafından kullanılır. Sonuç olarak IBM Cognos yazılımı, ortak bir boyut tabloları kümesiyle
birleştirilmiş çoklu olgu tablonuz olduğunda yıldız şeması verilerinden kaynaklanan ortak bir
döngüsel birleştirme formunu otomatik olarak çözebilir.
Öngörülebilir sorgular sağlamak için, satır sayısının nasıl kullanıldığının anlaşılması ve
modelinizde doğru şekilde uygulanması önemlidir. Temel veri kaynağı şemasını incelemeniz
ve satır sayısının öngörülemez sorgu sonuçlarına yol açabilecek şekilde olguları veya
boyutları yanlış olarak tanımladığı alanları ele almanız önerilir. Satır sayısının nasıl
yorumlandığını anlamanıza yardımcı olması için, Framework Manager'daki Model Advisor
özelliği kullanılabilir.
Daha fazla bilgi için bkz. “Satır Sayısı” sayfa 1.
Belirsiz İlişkileri Çözme
Bir sorgu konusu veya boyut tarafından temsil edilen veriler, birden çok bağlam ya da rolde
görüntülenebildiğinde veya birden çok şekilde birleştirilebildiğinde belirsiz ilişkiler oluşur.
En yaygın belirsiz ilişkiler şunlardır:
v “Oyun Boyutları”
v “Döngüsel Birleştirmeler” sayfa 23
v “Yansıma ve Yinelemeli İlişkiler” sayfa 24
Sorgu oluşturma sorunlarına neden olabilecek ilişkileri vurgulamak için Model Advisor
özelliğini kullanabilir ve aşağıda açıklanan yollardan birini kullanarak bunları çözebilirsiniz.
Sorunları çözmek için burada ele alınanlardan başka yollar da olduğunu unutmayın. Ana
hedef, net sorgu yollarına olanak sağlamaktır.
Oyun Boyutları:
Kendisi ile başka bir tablo arasında birden çok geçerli ilişki olan bir tablo, oyun boyutu adıyla
bilinir. Bu, Zaman ve Müşteri gibi boyutlarda en yaygın olarak görülür.
Örneğin, Satış olgusu; Sipariş Günü, Sevkiyat Günü ve Kapanış Günü anahtarlarında Zaman
sorgu konusuyla birden çok ilişkiye sahiptir.
20
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
İçe aktarılan nesneler, olgu sorgu konuları ve oyun boyutlu sorgu konuları için ilişkileri
kaldırın. Her bir rol için model sorgu konusu oluşturun. Kullanıcılarınıza görüntülenen meta
veri ağacının uzunluğunu azaltmak için gereksiz sorgu öğelerini kapsam dışı bırakmayı
düşünün. Her bir model sorgu konusu ile olgu sorgu konusu arasında tek bir uygun ilişki
bulunduğundan emin olun. Not: Bu, Küçültülmüş SQL ayarını geçersiz kılar, ancak Zaman
boyutunun tek bir tablo temsili verildiğinde, bu durumda sorunlu olarak değerlendirilmez.
Aynı kavramları paylaşmayan diğer olgularla bu rollerin nasıl kullanılacağına karar verin.
Örneğin, Ürün tahmini olgusu yalnızca bir zaman anahtarına sahiptir. Zaman için oluşturulan
Bölüm 1. Meta Verileri Modelleme için Yönergeler
21
rollerin tümünün veya herhangi birinin, Ürün tahmini olgusu için geçerli olup olmadığını
belirlemek üzere verilerinizi ve işinizi bilmeniz gerekir.
Bu örnekte, aşağıdakilerden birini yapabilirsiniz:
v Uyumlu zaman boyutu olacak ek bir sorgu konusu oluşturun ve bunu net bir şekilde
uyumlu boyut olarak adlandırın.
Kullanacağınız en yaygın rolü seçin. Daha sonra, bu sürümün gerekli olduğu tüm olgularla
birleştirildiğinden emin olabilirsiniz. Bu örnekte, Kapanış Günü seçilmiştir.
v Sevkiyat Günü, Sipariş Günü ve Kapanış Günü'nü, Ürün tahmini olgusunu içeren birbiriyle
değiştirilebilen zaman sorgu konuları olarak değerlendirebilirsiniz.
Bu durumda, Ürün tahmini olgusu ile oyun boyutlarının her biri arasında birleştirmeler
oluşturmanız gerekir. Ürün tahmini olgusunu sorgularken aynı anda yalnızca bir zaman
boyutunu kullanabilirsiniz; aksi takdirde raporunuz herhangi bir veri içermeyebilir.
Örneğin, Ay_anahtarı=Sevkiyat Ayı Anahtarı (200401) ve Ay anahtarı=Kapanış Ayı
Anahtarı (200312).
22
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
Boyutlu modelleme yapıyorsanız, her bir model sorgu konusunu, normal boyut için kaynak
olarak kullanın ve boyutu ve sıradüzenleri uygun şekilde adlandırın. Her bir role karşılık
gelen bir kapsam ilişkisi olmadığından emin olun.
Döngüsel Birleştirmeler:
Modeldeki döngüsel birleştirmeler genellikle bir öngörülemez davranış kaynağıdır. Bu, yıldız
şeması döngüsel birleştirmelerini içermez.
Not: Satır sayısının, olguları ve boyutları net şekilde tanımlaması durumunda IBM Cognos
yazılımı, ortak bir boyut tabloları kümesinde birleştirilmiş çoklu olgu tablonuz olduğunda
yıldız şeması verilerinden kaynaklanan döngüsel birleştirmeleri otomatik olarak çözebilir.
Döngüsel birleştirmeler olması durumunda sorunların birincil işareti, belirsiz şekilde
tanımlanan sorgu konularıdır. Sorgu konuları belirsiz şekilde tanımlandığında ve bir döngüsel
birleştirmenin parçası olduğunda, verilen bir sorguda kullanılan birleştirmeler; ilişkilerin
konumu, birleşim yollarındaki kesimlerin sayısı ve diğer her şey eşitse, alfabetik olarak ilk
birleşim yolu gibi çok sayıda faktör temel alınarak kararlaştırılır. Bu, kullanıcılarınızın aklını
karıştırabilir ve biz birleşim yollarını net şekilde modellemenizi öneririz.
Satış Personeli ve Şube, belirsiz şekilde tanımlanan sorgu konuları ile döngüsel birleştirmenin
güzel bir örneğini sağlar.
Bu örnekte, Şubenin doğrudan Sipariş ile birleştirilmesi veya Satış Personeli aracılığıyla
Sipariş ile birleştirilmesi mümkündür. Ana sorun, Şube ile Sipariş birlikte olduğunda aldığınız
sonucun, birleşim yolu Şube - Satış Personeli - Sipariş olduğunda aldığınız sonuçtan farklı
olmasıdır. Bunun nedeni, çalışanların şubeler arasında hareket edebilmesidir; böylece yıl
boyunca hareket eden çalışanların yaptıkları satışların çoğu önceki şubeyle ilişkili olsa da, bu
çalışanlar geçerli şubelerine toplanır. Bunun modellenme şeklinden dolayı, hangi birleşim
Bölüm 1. Meta Verileri Modelleme için Yönergeler
23
yolunun seçileceğine ilişkin bir garanti yoktur ve bu büyük olasılıkla sorguda hangi öğelerin
seçildiğine bağlı olarak değişiklik gösterecektir.
Yansıma ve Yinelemeli İlişkiler:
Yansıma ve yinelemeli ilişkiler, iki veya daha fazla ayrıntı düzeyini ifade eder. IBM Cognos
Framework Manager, yansıma ilişkilerini içe aktarır, ancak sorgular yürütürken bunları
kullanmaz. Kendinden birleşimli olan yansıma ilişkileri, modelde yalnızca temsil amacıyla
gösterilmektedir.
Çalışan bir yansıma ilişkisi oluşturmak için, bir diğer ad kısayolu, veri kaynağı sorgu
konusunun bir kopyası veya bir model sorgu konusu oluşturabilirsiniz. Daha sonra, orijinal
sorgu konusu ile yeni bir sorgu konusu arasında bir ilişki oluşturursunuz. Hangi sorgu
öğelerinin sorgu konusuna dahil olacağını belirtebildiğinizden, model sorgu konusu
kullanılması, esneklik için daha iyi bir seçim olacaktır. Bakım açısından bakıldığında,
kısayollar daha iyi bir çözümdür. Daha fazla bilgi için bkz. “Model Nesneleri ve Kısayollar”
sayfa 13.
Örneğin, Satış Personeli sorgu konusu, Sales_Staff_Code ile Manager_Code arasında
yinelemeli ilişkiye sahiptir.
24
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
Manager öğesini temsil etmesi için bir model sorgu konusu oluşturun. Yönetici ile Satış
Personeli arasında 1..1 - 1..n ile bir ilişki oluşturun. Ardından yeni bir model sorgu
konusunda birleştirin.
Satış Personeli'ni temel alan, Manager için bir model sorgu konusunu kullanan basit bir iki
düzeyli yapı için model şöyle görünür:
Yinelemeli, dengeli bir sıradüzen için, sıradüzendeki her bir ek düzey için bunu yineleyin.
Çok yinelemeli veya dengesiz bir sıradüzen için, sıradüzenin veri kaynağında
düzleştirilmesini ve düzleştirilmiş sıradüzeni tek bir normal boyutta modellemenizi öneririz.
İlişkisel Modeli Basitleştirme
Boyutlu verilere ve olgu verilerine yıldız şeması kavramlarını uygulayarak modeli
basitleştirebilirsiniz.
Açıklayıcı Verileri Temsil Eden Sorgu Konularını Modelleme:
IBM Cognos boyutlu modelleme, modelin mantıksal katmanlarına yıldız şeması ilkeleri
uygulamanızı gerektirir.
Bölüm 1. Meta Verileri Modelleme için Yönergeler
25
Normalleştirilmiş veya parçalanmış veri kaynakları genellikle tek bir iş kavramını açıklayan
birçok tablo içerir. Örneğin, normalleştirilmiş bir Ürün temsili, 1..n ilişkisiyle ilişkilendirilmiş
dört tablo içerebilir. Her bir Ürün Yelpazesi bir veya daha daha fazla Ürün Tipi'ne sahiptir.
Her bir Ürün Tipi bir veya daha daha fazla Ürün'e sahiptir. Ürünler birçok dilde adlara ve
tanımlara sahiptir; bu nedenle Ürün (Çok Dilli) referans tablosunda bulunurlar.
Modeli basitleştirmenin bir yolu, her bir açıklayıcı iş kavramı için tek bir model sorgu konusu
oluşturmaktır. Kullanıcılarınız, tek tek sorgu konuları arasındaki ilişkiyi bilmeyebilir, bu
nedenle bunların birlikte gruplanması yardımcı olacaktır; ayrıca, her bir model nesnesini
genişletme ve bir sorgu öğesi seçme gerekliliği de daha fazla emek gerektirir.
Çözümleme için bir sonraki adım, her bir sorgu konusu için bir düzey ile normal boyut
oluşturulmasıdır.
Olgu Verilerini Modelleme:
Veri kaynaklarının genellikle olgular içeren ana detay tabloları olur. Örneğin, veri eklemek ve
güncellemek için Sipariş üstbilgisi ve Sipariş ayrıntıları tabloları kullanıldığında, ana detay
yapısı yararlıdır. Raporlama ve çözümleme için bu tablolar kullanıldığında, modeli
basitleştirmek için bunları tek bir mantıksal iş kavramında birleştirmeyi tercih edebilirsiniz.
Veya bunların arasına, İade Edilen Öğeler gibi bir boyut eklemeyi de seçebilirsiniz. Hangi
çözümü seçeceğiniz, gereksinimlerinize bağlıdır.
26
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
Bu örnekteki modeli basitleştirmek için yıldız şeması kavramları uygulayarak, hem Sipariş
üstbilgisi hem de Sipariş ayrıntılarının yabancı anahtarlarını birleştiren ve Sipariş ayrıntıları
düzeyindeki tüm ölçüleri içeren tek bir model sorgu konusu oluşturun. Bu sorgu konusu,
Sipariş üstbilgisi ve Sipariş ayrıntılarının birleştirildiği aynı sorgu konularıyla
birleştirilmelidir. İki veri kaynağı sorgu konusundan, bunlar arasındaki birleşmeyi tanımlayan
ilişki dışında, orijinal ilişkileri kaldırmayı seçebilirsiniz. Sorgu konularını modellemek için
ilişkiler oluşturmanın avantajları ve dezavantajlarına ilişkin bir tartışma için, “Küçültülmüş
SQL Nedir?” sayfa 11 içindeki örneklere bakın.
Aşağıdaki örnekte, Sipariş üstbilgisi ve Sipariş ayrıntıları, Satış adlı yeni bir model sorgu
konusunda birleştirilmiştir. Bu sorgu konusu, Ürün, Zaman ve Sipariş yöntemi ile
birleştirilmiştir.
Çözümlemenin sonraki adımı, model sorgu konusunu temel alan bir ölçü boyutu
oluşturulmasıdır.
Modelin Boyutlu Temsilini Tanımlama
İlişkisel veri kaynaklarının boyutlu modellemesi, IBM Cognos Framework Manager
tarafından kullanılabilir duruma getirilen bir yetenektir. Sıradüzenler ve düzeyler ile boyutlar
modelleyebilir ve birden çok ölçü içeren olgulara sahip olabilirsiniz. Daha sonra modeldeki
kapsamı ayarlayarak boyutları ölçülerle ilişkilendirebilirsiniz.
Raporlarda detayı azaltmayı veya detaya inmeyi etkinleştirmek, Studio ürünlerinde üye
işlevlerine erişmek veya bir ilişkisel veri kaynağını IBM Cognos Analysis Studio olanağında
kullanmak istediğinizde onu boyutlu olarak modellemeniz gerekir.
Temel katman olarak ilişkisel modeli kullanabilir ve daha sonra modelin boyutlu temsilini
tanımlayabilirsiniz.
Böylece sunum için modeli düzenleyebilirsiniz. Bkz. “Modeli Düzenleme” sayfa 30.
Normal Boyutlar Oluşturma
Normal bir boyut, açıklayıcı bilgiler ve iş anahtarı bilgileri içerir ve bilgileri, en yüksek
ayrıntı düzeyinden en düşük ayrıntı düzeyine doğru bir sıradüzende düzenler. Genellikle
Bölüm 1. Meta Verileri Modelleme için Yönergeler
27
birden çok düzeye sahiptir ve her bir düzey bir anahtar ve bir başlık gerektirir. Düzeyiniz için
tek bir anahtarınız yoksa, bir hesaplamada anahtar oluşturmanız önerilir.
Model normal boyutları, önceden modelde tanımlanan model sorgu konularını veya veri
kaynağını temel alır. Her bir düzey için bir iş anahtarı ve bir dizgi tipinde başlık tanımlamanız
gerekir. Modeli doğruladığınızda, iş anahtarı ve başlık bilgilerinin yokluğu algılanır. Model
normal boyutlarını ölçü boyutlarıyla birleştirmek yerine, temel sorgu konularında birleşmeler
oluşturun ve normal boyut ile ölçü boyutu arasında bir kapsam ilişkisi oluşturun.
Birden Çok Sıradüzen ile Boyutları Modelleme
Aynı verilere farklı yapısal görünümler uygulanabildiğinde birden çok sıradüzen oluşur.
Sıradüzenlerin ve gerekli raporların özelliğine bağlı olarak, belirli bir duruma uygulanan
modelleme tekniğini değerlendirmeniz gerekebilir.
Örneğin, yönetici veya coğrafya tarafından satış personeli görüntülenebilir. IBM Cognos
Studio ürünlerinde bu sıradüzenler ayrıdır; öte yandan bunlar aynı temel sorguya bağlı olan,
birbiriyle değiştirilebilen mantıksal yapılardır.
Burada satış personeli, iki sıradüzen içeren tek bir boyuttur:
Framework Manager'da sıradüzenler şu şekilde tanımlanır.
28
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
Framework Manager'da normal boyutlarda birden çok sıradüzen belirtebilirsiniz. Normal bir
boyut için birden çok sıradüzen, aynı sorgunun görünümleri olarak hareket eder. Ancak bir
sorguda aynı anda yalnızca bir sıradüzen kullanabilirsiniz. Örneğin, bir çapraz tablo
raporunun satırlarında bir sıradüzen ve sütunlardaki aynı boyuttan başka bir sıradüzen
kullanamazsınız. Her iki sıradüzenin de aynı raporda olması gerekiyorsa, her bir sıradüzen
için birer tane olacak şekilde iki boyut oluşturmanız gerekir. Çok farklı düzeyler veya toplama
içeren birden çok sıradüzeniniz olması durumunda, söz konusu sıradüzen için temel olarak
uygun belirteçlere sahip ayrı bir sorgu konusu bulunacak şekilde modellemeyi seçebilirsiniz.
Tek gereksinim, bir sıradüzen için temel olarak kullanılan herhangi bir sorgu konusunun, olgu
verilerini sağlayan sorgu konusuna tanımlanmış bir birleşmesinin olması gerekliliğidir.
Her bir sıradüzen için ayrı boyutlar şunlardır.
Bölüm 1. Meta Verileri Modelleme için Yönergeler
29
Her bir sıradüzen için çok farklı sütun kümeleri ilişkiliyse ve sıradüzenlerin ayrı ve daha basit
sorgular içeren ayrı boyutlar olarak modellenmesi kullanıcılarınız için daha kolaysa bu
yaklaşımı kullanın.
Ölçü Boyutları Oluşturma
Ölçü boyutu bir olgular derlemidir. Aralarında geçerli bir ilişki olan bir veya daha fazla sorgu
konusu için bir ölçü boyutu oluşturabilirsiniz.
Model ölçü boyutları yalnızca niceliksel öğelerden oluşmalıdır. Tasarımı gereği model ölçü
boyutları, üzerinde birleşme yapılacak anahtarlar içermediğinden, model ölçü boyutlarıyla
birleşmeler oluşturulması mümkün değildir. Model ölçü boyutlarını normal boyutlarla
birleştirmek yerine, temel sorgu konuları üzerinde birleşmeler oluşturun. Daha sonra bunlar
arasında el ile bir kapsam ilişkisi oluşturun veya her iki boyutun da aynı ad alanında olup
olmadığını algılayın.
Kapsam İlişkileri Oluşturma
Kapsam ilişkileri, ölçülerin raporlama için kullanılabilir olduğu düzeyi tanımlamak üzere
yalnızca ölçü boyutları ile normal boyutlar arasında bulunur. Bunlar birleşimler ile aynı
değildir ve Where yantümcesini etkilemezler. Bir sorgunun nasıl oluşturulacağını belirlemek
için bir kapsam ilişkisinde ayarlanmış koşullar veya ölçütler yoksa bu, yalnızca belirtilen bir
olgu ile bir boyutun sorgulanıp sorgulanamayacağını belirtir. Kapsam ilişkisinin olmayışı,
çalıştırma zamanında bir hataya yol açar.
Ölçü boyutu için kapsam ilişkisi ayarlarsanız, ölçü boyutundaki tüm ölçüler için aynı ayarlar
geçerli olur. Veriler, ölçü boyutundaki ölçüler için farklı bir düzeyde raporlanırsa, bir ölçüde
kapsamı ayarlayabilirsiniz. Verilerin raporlanabileceği en düşük düzeyi belirtebilirsiniz.
Bir ölçü boyutu oluşturduğunuzda IBM Cognos Framework Manager, ölçü boyutu ile var olan
her bir normal boyut arasında bir kapsam ilişkisi oluşturur. Framework Manager, en düşük
ayrıntı düzeyinden başlayarak ölçü boyutu ile normal boyutlar arasında bir birleşim yolu arar.
Kullanılabilir birçok birleşim yolu varsa, Framework Manager'ın oluşturduğu kapsam ilişkisi
sizin tasarladığınız olmayabilir. Bu durumda kapsam ilişkisini düzenlemeniz gerekir.
Modeli Düzenleme
İlişkisel modelleme temelinde çalışıp boyutlu temsil oluşturduktan sonra, modeli
düzenleyebilirsiniz.
v Veri kaynağındaki meta verileri ayrı bir ad alanında veya klasörde tutun.
30
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
v Sorgu konuları kullanılarak sorgulamayı etkileyen karmaşıklıkları gidermek için bir veya
daha fazla isteğe bağlı ad alanı veya klasör oluşturun.
IBM Cognos Analysis Studio olanağını kullanmak için, modelde boyutlu nesneler ile meta
verileri temsil eden bir ad alanı veya klasör olmalıdır.
v Boyutlara veya sorgu konularına ilişkin kısayollar içeren meta verilerin genişletilmiş iş
görünümü için bir ya da daha fazla ad alanı veya klasör oluşturun.
İş görünümünü modellemek için iş kavramlarını kullanın. Bir model, her biri farklı bir
kullanıcı grubuna uygun olan birçok iş görünümü içerebilir. İş görünümlerini yayınlarsınız.
v “Yıldız Şeması Grupları” oluşturun.
v Gerekirse, nesne güvenliği uygulayın.
v Paketler oluşturun ve meta verileri yayınlayın.
Burada ele alınmayan konular hakkında bilgi için, Framework Manager Kullanıcı Kılavuzu'na
bakın.
Yıldız Şeması Grupları
Uyumlu boyut kavramı, boyutlu modellemeye özgü değildir, sorgu konuları için de eşit
düzeyde geçerlidir.
Kullanıcılarınız için hızlı şekilde hangi nesnelerin birbirine ait olduğuna ilişkin bağlam
sağlayacak kısayol grupları oluşturmak üzere Yıldız Şeması Gruplama sihirbazını kullanın.
Bu, modeli kullanıcılarınız için daha kolay kullanılabilir bir hale getirir. Yıldız şeması
grupları farklı gruplarda paylaşılan boyutların yinelenmesine izin vererek çoklu olgu
raporlamasını da kolaylaştırabilir. Bu, kullanıcılarınızın farklı grupların ortak olarak neye
sahip olduklarını ve çapraz işlevsel veya çoklu olgu raporlamasını nasıl yapabildiklerini
görmesine yardımcı olur. Daha fazla bilgi için bkz. “Çoklu olgu, çoklu gren sorguları” sayfa
7.
Yıldız şeması grupları ayrıca birden çok birleşim yolu içeren sorgular için bağlam da sağlar.
Modelin iş görünümünde yıldız şeması grupları oluşturarak, birçok birleşim yolu kullanılabilir
olduğunda bunlardan hangisinin seçileceğini netleştirebilirsiniz. Bu özellikle olgusuz sorgular
için kullanışlıdır.
Birden Çok Uyumlu Yıldız Şeması veya Olgusuz Sorgular:
Büyük ihtimalle birden çok olgu sorgu konusuyla birleştirilen boyutlu sorgu konularını
görürsünüz. Ölçü boyutundan veya olgu sorgu konusundan herhangi bir öğeyi dahil etmeden
birden çok boyuttan ya da boyutlu sorgu konusundan öğeleri kullanarak raporlama
yaptığınızda, birleşme belirsizliği bir sorundur. Bu, olgusuz sorgu olarak adlandırılır.
Örneğin, Ürün ve Zaman boyutları, Ürün tahmini ve Satış olgularıyla ilişkilidir.
Bölüm 1. Meta Verileri Modelleme için Yönergeler
31
Bu ilişkileri kullanarak, yalnızca Ürün ve Zaman içindeki öğeleri kullanan bir raporu nasıl
yazabilirsiniz? İş sorusu, 2005'te satış için hangi ürünlerin tahmin edildiği veya 2005'te
gerçekte hangi ürünlerin satıldığıdır. Bu sorgu yalnızca Ürün ve Zaman'ı içerse de, bu
boyutlar çoklu olgular aracılığıyla ilişkilidir. Hangi iş sorusunun sorulduğunu tahmin etmenin
bir yolu yoktur. Olgusuz sorgu için bağlamı belirlemeniz gerekir.
Bu örnekte, biri Ürün, Zaman ve Ürün tahminine ilişkin kısayolları içeren ve diğeri de Ürün,
Zaman ve Satış'ı içeren iki ad alanı oluşturmanızı öneririz.
32
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
Tüm yıldız şemaları için bunu yaptığınızda, tek bir ad alanında tüm boyutlara ve olguya
ilişkin kısayolları yerleştirerek birleşme belirsizliğini giderirsiniz. Her bir ad alanındaki
uyumlu boyutlar için kısayollar aynıdır ve orijinal nesneye başvuruda bulunur. Not: Normal
boyutlar ve ölçü boyutları için de tamamen aynı kural geçerlidir.
Her bir yıldız şeması için bir ad alanı olduğunda, kullanıcılarınız için hangi öğelerin
kullanılacağı netlik kazanmış olur. 2005'te gerçekte hangi ürünlerin satıldığına ilişkin bir
rapor oluşturmak için, Satış Ad Alanından Ürün ve Yıl'ı kullanırlar. Bu bağlamda geçerli olan
tek ilişki, Ürün, Zaman ve Satış arasındaki ilişki olup bu, verileri döndürmek için kullanılır.
Bölüm 1. Meta Verileri Modelleme için Yönergeler
33
34
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
Bölüm 2. IBM Cognos Yazılımı Tarafından Oluşturulan SQL
IBM Cognos yazılımı tarafından oluşturulan SQL çoğu zaman yanlış anlaşılır. Bu belge,
yaygın durumlarla sonuçlanan SQL'i açıklamaktadır.
Not: Bu belgede gösterilen SQL örnekleri, uzunluk açısından düzenlenmiş olup belirli
örnekleri vurgulamak için kullanılmaktadır. Bu örnekler, 8.2 sürümü örnek modelini kullanır.
Farklı bir dilde IBM CognosMeta Verileri Modelleme için Yönergeler belgesine erişmek
üzere, installation_location\c10\webcontent\documentation konumuna gidin ve istediğiniz
dilin klasörünü açın. Sonra ug_best.pdf dosyasını açın.
Boyutlu Sorgular
Boyutlu sorgular, çoklu olgu sorgulamayı etkinleştirmek için tasarlanmıştır.
Çoklu olgu sorgulamanın temel amaçları şunlardır:
v Olgularda, boyutlardakinden daha fazla satır bulunduğunda olduğu gibi, ortak boyutlar
arasında olgu verileri mükemmel şekilde hizalanmadığında verileri korumak.
v Her bir olgunun, uygun gruplamaya sahip tek bir sorguda temsil edildiğinden emin olarak
farklı ayrıntı düzeylerinde olgu verileri bulunduğunda çift sayımı önlemek. Bazı
durumlarda temel sorgu konuları için belirteçlerin oluşturulması gerekebilir.
Tekli Olgu Sorgusu
Yıldız şeması grubu üzerinde yapılan bir sorgu, tekli olgu sorgusu ile sonuçlanır.
Bu örnekte, yazılan herhangi bir sorgunun odak noktası Satış'tır. Boyutlar, Satış içindeki
verilerin daha anlamlı olmasını sağlayan öznitelikler ve tanımlar sunar. Boyutlar ile olgu
arasındaki tüm ilişkiler, 1-n ilişkisidir.
© Copyright IBM Corp. 2005, 2014
35
Ay ve ürünü süzgeçten geçirdiğinizde, sonuç şu şekildedir.
36
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
Uyumlu Boyutlarda Çoklu Olgu, Çoklu Gren Sorgusu
Çoklu olgular ve uyumlu boyutlarda yapılan bir sorgu, her bir olgu tablosu ile boyutları
arasındaki satır sayısını takip eder ve her bir olgu tablosundan tüm satırları döndürmek için
SQL yazar.
Örneğin, Satış ve Ürün Tahmini'nin her ikisi de olgudur.
Bunun basitleştirilmiş bir temsil olduğunu ve IBM Cognos modelleme önerileri kullanılarak
oluşturulan bir modelde bunun nasıl görüneceğine ilişkin bir örnek olmadığını unutmayın.
Sonuç
Ay ve Ürün'e göre Satış ve Ürün Tahmini üzerinde yapılan tek tek sorgular şu sonuçları üretir.
Satış içindeki veriler gerçekte gün düzeyinde depolanır.
Bölüm 2. IBM Cognos Yazılımı Tarafından Oluşturulan SQL
37
Satış ve Ürün Tahmini üzerinde yapılan bir sorgu, her bir olgu tablosu ile boyutları arasındaki
satır sayısını takip eder ve her bir olgu tablosundan tüm satırları döndürmek için SQL yazar.
Olgu tabloları; ortak anahtarları, ay ve ürün üzerinde eşleşirler ve mümkün olan yerlerde en
düşük ortak ayrıntı düzeyinde toplanırlar. Bu durumda, günler aylara toplanır. Bu tür bir sorgu
için genellikle boş değerler verilir çünkü bir olgu tablosundaki boyutlu öğelerin bir birleşimi
başka bir olgu tablosunda bulunmayabilir.
Şubat 2004'te Course Pro Umbrellas'ın tahminde yer aldığına, ancak herhangi bir gerçek satış
olmadığına dikkat edin. Satış ve Ürün Tahmini içindeki veriler, farklı ayrıntı düzeylerinde
bulunur. Satış içindeki veriler gün düzeyinde ve Ürün Tahmini de ay düzeyindedir.
SQL
IBM Cognos yazılımı tarafından oluşturulan SQL, ekli sorgu olarak bilinir ve çoğu zaman
yanlış anlaşılır. Ekli sorgu, ortak anahtarlardaki tam dış birleştirme ile bir araya getirilmiş, her
bir yıldız için birer tane olacak şekilde birden çok alt sorgu kullanır. Amaç, sorgunun herhangi
bir tarafında oluşan tüm boyutlu üyeleri korumaktır.
Aşağıdaki örnek, uzunluk için düzenlenmiş olup ekli sorguların ana özelliklerini yakalamak
için bir örnek olarak kullanılır.
select
coalesce(D2.MONTH_NAME,D3.MONTH_NAME) as MONTH_NAME,
coalesce(D2.PRODUCT_NAME,D3.PRODUCT_NAME) as PRODUCT_NAME,
D2.EXPECTED_VOLUME as EXPECTED_VOLUME,
D3.QUANTITY as QUANTITY
from (select TIME.MONTH_NAME as MONTH_NAME,
PRODUCT_LOOKUP.PRODUCT_NAME as PRODUCT_NAME,
XSUM(PRODUCT_FORECAST_FACT.EXPECTED_VOLUME for
TIME.CURRENT_YEAR,TIME.QUARTER_KEY,TIME.MONTH_KEY,
PRODUCT.PRODUCT_LINE_CODE, PRODUCT.PRODUCT_TYPE_CODE,
PRODUCT.PRODUCT_KEY) as EXPECTED_VOLUME
from
(select TIME.CURRENT_YEAR as CURRENT_YEAR,
TIME.QUARTER_KEY as QUARTER_KEY,
TIME.MONTH_KEY as MONTH_KEY,
XMIN(TIME.MONTH_NAME for TIME.CURRENT_YEAR,
TIME.QUARTER_KEY,TIME.MONTH_KEY) as MONTH_NAME
from TIME_DIMENSION TIME
group by TIME.MONTH_KEY) TIME
join PRODUCT_FORECAST_FACT PRODUCT_FORECAST_FACT
on (TIME.MONTH_KEY = PRODUCT_FORECAST_FACT.MONTH_KEY)
join PRODUCT PRODUCT on (PRODUCT.PRODUCT_KEY =
PRODUCT_FORECAST_FACT.PRODUCT_KEY)
where
(PRODUCT.PRODUCT_NAME in (’Aloe Relief’,’Course Pro
Umbrella’)) and
(TIME.MONTH_NAME in (’April 2004’,’February 2004’,’February
2006’))
group by
TIME.MONTH_NAME,
38
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
PRODUCT_LOOKUP.PRODUCT_NAME
) D2
full outer join
(select TIME.MONTH_NAME as MONTH_NAME,
PRODUCT_LOOKUP.PRODUCT_NAME as PRODUCT_NAME,
XSUM(SALES_FACT.QUANTITY for TIME.CURRENT_YEAR,
TIME.QUARTER_KEY, TIME.MONTH_KEY,
PRODUCT.PRODUCT_LINE_CODE, PRODUCT.PRODUCT_TYPE_CODE,
PRODUCT.PRODUCT_KEY ) as QUANTITY
from
select TIME.DAY_KEY,TIME.MONTH_KEY,TIME.QUARTER_KEY,
TIME.CURRENT_YEAR,TIME.MONTH_EN as MONTH_NAME
from TIME_DIMENSION TIME) TIME
join SALES_FACT SALES_FACT
on (TIME.DAY_KEY = SALES_FACT.ORDER_DAY_KEY)
join PRODUCT PRODUCT on (PRODUCT.PRODUCT_KEY = SALES_FACT.PRODUCT_KEY)
where
PRODUCT.PRODUCT_NAME in (’Aloe Relief’,’Course Pro Umbrella’))
and (TIME.MONTH_NAME in (’April 2004’,’February 2004’,’February
2006’))
group by
TIME.MONTH_NAME,
PRODUCT.PRODUCT_NAME
) D3
on ((D2.MONTH_NAME = D3.MONTH_NAME) and
(D2.PRODUCT_NAME = D3.PRODUCT_NAME))
Coalesce Deyimi Nedir?
coalesce deyimi, uyumlu boyutlardan sorgu öğelerini ele almanın verimli bir aracıdır. Sorgu
konusundan döndürülen ilk boş olmayan değeri kabul etmek için kullanılır. Bu deyim, bir tam
dış birleştirme yapılırken hiç yineleme içermeyen tam anahtar listesine olanak sağlar.
Tam Dış Birleştirme Neden Vardır?
Tam dış birleştirme, her bir olgu tablosundan tüm verilerin alındığundan emin olmak için
gereklidir. İç birleştirme yalnızca stoktaki bir öğe satıldıysa sonuçlar verir. Sağ dış birleştirme,
öğelerin stokta olduğu tüm satışları verir. Sol dış birleştirme, satışa sahip olan stoktaki tüm
öğeleri verir. Tam dış birleştirme, neyin stokta bulunduğunun ve neyin satıldığının anlaşılması
için tek yoldur.
1-n İlişkileri 1-1 İlişkiler Olarak Modelleme
Verilerde bir 1-n ilişki varsa, ancak 1-1 ilişki olarak modellenmişse, meta veriler tarafından
IBM Cognos yazılımına sağlanan bilgiler yetersiz olduğundan SQL yakalamaları önlenemez.
1-n ilişkileri 1-1 olarak modellendiğinde oluşan en yaygın sorunlar şunlardır:
v Çoklu gren sorguları için çift sayım otomatik olarak önlenmez.
IBM Cognos yazılımı olguları algılayamaz ve daha sonra uyumlu boyutlarda farklı ayrıntı
düzeyleri ve sıradüzen ilişkileri ile işlem yaparken oluşabilecek çift sayımı telafi etmek için
bir ekli sorgu oluşturamaz.
v Çoklu olgu sorguları otomatik olarak algılanmaz.
IBM Cognos yazılımı, çoklu olgu sorgusunu algılamak için yeterli bilgiye sahip
olmayacaktır. Çoklu olgu sorguları için bir iç birleştirme gerçekleştirilir ve son
değerlendirilen birleştirme bırakılarak döngüsel birleştirme ortadan kaldırılır. Bir
birleştirmenin bırakılması büyük olasılıkla sorguya dahil olan boyutlara ve olgulara bağlı
olarak yanlış veya öngörülemez sonuçlara yol açabilir.
Bölüm 2. IBM Cognos Yazılımı Tarafından Oluşturulan SQL
39
Satır sayısı, yalnızca sorgu konuları veya boyutlar arasında 1-1 ilişkileri kullanılacak şekilde
değiştirildiyse, Zaman veya Zaman ve Ürün ile Ürün Tahmini ve Satış üzerinde yapılan bir
sorgunun sonucu, dairesel başvuruyu önlemek için bir birleştirmeyi bırakan tek bir Select
deyimini oluşturur.
Aşağıdaki örnek, Satış veya Ürün Tahminine karşı yapılan tek tek sorguların sonuçlarına
kıyasla bu sorgunun sonuçlarının yanlış olduğunu göstermektedir.
Tek tek sorguların sonuçları şu şekildedir.
Bu sorguları tek bir sorguda birleştirdiğinizde, sonuçlar şöyle olur.
SQL
Modelde dairesel bir birleşim yolu algılandığından, oluşturulan SQL, birleşim yolunu
tamamlamak için gerekli olan ilişkilerden birini içermemiştir. Bu örnekte, Zaman ile Ürün
Tahmini arasındaki ilişki bırakılmıştır.
Dairesel bir birleşim yolu, nadiren kullanışlı sonuçlar üreten bir sorguyla sonuçlanır.
select
TIME_.MONTH_NAME as MONTH_NAME,
PRODUCT_LOOKUP.PRODUCT_NAME as PRODUCT_NAME,
XSUM(SALES_FACT.QUANTITY for
TIME_.CURRENT_YEAR, TIME_.QUARTER_KEY, TIME_.MONTH_KEY,
PRODUCT.PRODUCT_LINE_CODE, PRODUCT.PRODUCT_TYPE_CODE,
PRODUCT.PRODUCT_KEY ) as QUANTITY,
40
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
XSUM(PRODUCT_FORECAST_FACT.EXPECTED_VOLUME for TIME_.CURRENT_YEAR,
TIME_.QUARTER_KEY, TIME_.MONTH_KEY, PRODUCT.PRODUCT_LINE_CODE,
PRODUCT.PRODUCT_TYPE_CODE, PRODUCT.PRODUCT_KEY ) as EXPECTED_VOLUME
from
(select TIME.DAY_KEY,TIME.MONTH_KEY, TIME.QUARTER_KEY,
TIME.CURRENT_YEAR,TIME.MONTH_EN as MONTH_NAME
from TIME_DIMENSION TIME) TIME
join
SALES_FACT on (TIME_.DAY_KEY = SALES_FACT.ORDER_DAY_KEY)
join
PRODUCT_FORECAST_FACT on (TIME_.MONTH_KEY =
PRODUCT_FORECAST_FACT.MONTH_KEY)
join
PRODUCT (PRODUCT.PRODUCT_KEY = PRODUCT_FORECAST_FACT.PRODUCT_KEY)
where
(PRODUCT.PRODUCT_NAME in (’Aloe Relief’,’Course Pro Umbrella’))
and
(TIME_.MONTH_NAME in (’April 2004’,’February 2004’,’February 2006’))
group by
TIME_.MONTH_NAME, PRODUCT.PRODUCT_NAME
Uyumsuz Boyutlarda Çoklu Olgu, Çoklu Gren Sorgusu
Sorguya uyumsuz bir boyut eklenirse, ekli sorgu tarafından döndürülen sonuçların özellikleri
değiştirilir. Sorgunun bir tarafı, diğer tarafıyla ortak olmayan boyutlara sahip olduğundan,
kayıtları, en düşük ortak ayrıntı düzeyine toplamak artık mümkün değildir. Döndürülen sonuç
aslında iki bağıntılı listedir.
Bölüm 2. IBM Cognos Yazılımı Tarafından Oluşturulan SQL
41
Sonuç
İlgili yıldız şemalarındaki tek tek sorguların sonuçları şöyle görünür.
Her iki yıldız şemasından aynı öğelerin sorgulanması şu sonucu üretir.
42
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
Bu sonuçta, Satış içindeki kayıtlar için ayrıntı düzeyinin daha düşük olması, her bir ay ve ürün
birleşimi için daha fazla kaydın döndürülmesiyle sonuçlanır. Şimdi, Ürün Tahmini'nden
döndürülen ve Satış'tan döndürülen satırlar arasında bir 1-n ilişkisi vardır.
Bunu, uyumlu boyutlarda çoklu olgu, çoklu gren sorgusu örneğinde döndürülen sonuçla
karşılaştırdığınızda, daha fazla kaydın döndürüldüğünü ve Beklenen Hacim sonuçlarının
birden çok Sipariş Yöntemi arasında yinelendiğini görebilirsiniz. Sorguya Sipariş Yöntemi
eklenmesi, Miktar verileri ile Beklenen Hacim verileri arasındaki ilişkiyi etkili şekilde bir 1-n
ilişkisine dönüştürür. Beklenen Hacim içinden tek bir değerin Miktar içinden tek bir değerle
ilişkilendirilmesi artık mümkün değildir.
Ay anahtarı üzerindeki gruplama, bu örnekteki sonucun çoklu olgu, çoklu gren sorgusundaki
sonuçla aynı olan ancak daha yüksek ayrıntı düzeyine sahip olan veri kümesine dayalı
olduğunu gösterir.
SQL
Bu örnek için oluşturulan ekli SQL, çoklu olgu, çoklu gren sorgusunda oluşturulan SQL'e çok
benzer. Temel fark, Sipariş Yöntemi'nin eklenmesidir. Sipariş Yöntemi uyumlu bir boyut
değildir ve yalnızca Satış Olgusu tablosuna karşı sorguyu etkiler.
select
D2.QUANTITY as QUANTITY,
D3.EXPECTED_VOLUME as EXPECTED_VOLUME,
coalesce(D2.PRODUCT_NAME,D3.PRODUCT_NAME) as PRODUCT_NAME,
coalesce(D2.MONTH_NAME,D3.MONTH_NAME) as MONTH_NAME,
D2.ORDER_METHOD as ORDER_METHOD
from
(select
PRODUCT.PRODUCT_NAME as PRODUCT_NAME,
TIME.MONTH_NAME as MONTH_NAME,
ORDER_METHOD.ORDER_METHOD as ORDER_METHOD,
XSUM(SALES_FACT.QUANTITY for TIME.CURRENT_YEAR,TIME.QUARTER_KEY,
TIME.MONTH_KEY,PRODUCT.PRODUCT_LINE_CODE,PRODUCT.PRODUCT_TYPE_CODE,
PRODUCT.PRODUCT_KEY,ORDER_METHOD_DIMENSION.ORDER_METHOD_KEY) as
QUANTITY
from
PRODUCT_DIMENSION PRODUCT
Bölüm 2. IBM Cognos Yazılımı Tarafından Oluşturulan SQL
43
join
SALES_FACT SALES_FACT
on (PRODUCT.PRODUCT_KEY = SALES_FACT.PRODUCT_KEY)
join
ORDER_METHOD_DIMENSION ORDER_METHOD
on (ORDER_METHOD.ORDER_METHOD_KEY = SALES_FACT.ORDER_METHOD_KEY)
join TIME_DIMENSION TIME
on ( TIME.DAY_KEY = SALES_FACT.ORDER_DAY_KEY)
where
(PRODUCT.PRODUCT_NAME in (’Aloe Relief’,’Course Pro Umbrella’))
and
( TIME.MONTH_NAME in (’April 2004’,’February 2004’,’February 2006’))
group by
PRODUCT.PRODUCT_NAME,
TIME.MONTH_NAME,
ORDER_METHOD.ORDER_METHOD
) D2
full outer join
(select
PRODUCT.PRODUCT_NAME as PRODUCT_NAME,
TIME.MONTH_NAME as MONTH_NAME,
XSUM(PRODUCT_FORECAST_FACT.EXPECTED_VOLUME for TIME.CURRENT_YEAR,
TIME.QUARTER_KEY,TIME.MONTH_KEY,PRODUCT.PRODUCT_LINE_CODE,
PRODUCT.PRODUCT_TYPE_CODE,PRODUCT.PRODUCT_KEY) as EXPECTED_VOLUME
from
PRODUCT_DIMENSION PRODUCT
join
PRODUCT_FORECAST_FACT PRODUCT_FORECAST_FACT
on (PRODUCT.PRODUCT_KEY = PRODUCT_FORECAST_FACT.PRODUCT_KEY)
join
(select
TIME.CURRENT_YEAR as CURRENT_YEAR,
TIME.QUARTER_KEY as QUARTER_KEY,
TIME.MONTH_KEY as MONTH_KEY,
XMIN(TIME.MONTH_NAME for TIME.CURRENT_YEAR, TIME.QUARTER_KEY,
TIME.MONTH_KEY) as MONTH_NAME
from
TIME_DIMENSION TIME
group by
TIME.CURRENT_YEAR,
TIME.QUARTER_KEY,
TIME.MONTH_KEY
) TIME
on (TIME.MONTH_KEY = PRODUCT_FORECAST_FACT.MONTH_KEY)
where
(PRODUCT.PRODUCT_NAME in (’Aloe Relief’,’Course Pro Umbrella’))
and
(TIME.MONTH_NAME in (’April 2004’,’February 2004’,’February 2006’))
group by
PRODUCT.PRODUCT_NAME,
TIME.MONTH_NAME
) D3
on ((D2.PRODUCT_NAME = D3.PRODUCT_NAME) and
(D2.MONTH_NAME = D3.MONTH_NAME))
Belirsiz Şekilde Tanımlanmış Boyutları ve Olguları Çözme
Bir sorgu konusu, diğer sorgu konularına ilişkin hem n hem de 1 ilişkilerine katılırsa, belirsiz
şekilde tanımlanmış olarak değerlendirilir. Belirsiz şekilde tanımlanmış bir sorgu konusu,
sorgu oluşturma açısından bakıldığında her zaman zararlı değildir. Aşağıdaki durumları
kullanarak sorgu konularını değerlendirmenizi öneririz. Bu değerlendirmenin amacı, gereksiz
sorgu bölünmelerini önlemek ve oluşan bölünmelerin kasıtlı ve doğru olduğundan emin
olmaktır.
44
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
Sıradüzen Düzeyini Temsil Eden Sorgu Konuları
Zararlı olmayan, belirsiz şekilde tanımlanmış bir sorgu konusunun en sık görüldüğü durum,
sorgu konusunun, açıklayıcı bir sıradüzenin ara düzeyini temsil etmesi durumudur. Örnek
olarak, şu Ürün sıradüzeni verilebilir.
Bu örnekte, hem Ürün tipi hem de Ürün, belirsiz olarak tanımlanmış diye nitelendirilebilir.
Ancak bu belirsizlik, oluşturulan sonuçlara veya bu sorgu konularından birini ya da daha
fazlasını kullanan herhangi bir sorgunun performansına zarar vermez. Olgu algılama için
kurallar kullanılarak, herhangi bir sorguda, Ürün tahmini veya Satış sorgu konularından bir
öğeyi birleştiren yalnızca bir olgu tanımlandığından, bu sorgu örüntüsünü düzeltmeniz
gerekmez. Çözümleme amacıyla modelleme yapılırken, sıradüzenlerin tek bir normal boyutta
daraltılması en iyi uygulama olmaya devam eder.
Bu örnek kullanılarak yazılabilen sorgular arasında şunlar yer alır:
Bir sorguda, şu sorgu konularından öğeler
kullanılır:
Sorguda olgu olarak hareket eden sorgu
konusu:
Ürün yelpazesi ve Ürün tipi
Ürün tipi
Ürün yelpazesi, Ürün tipi ve Ürün
Ürün
Ürün yelpazesi, Ürün tipi, Ürün ve Satış
Satış
Bölüm 2. IBM Cognos Yazılımı Tarafından Oluşturulan SQL
45
Bir sorguda, şu sorgu konularından öğeler
kullanılır:
Sorguda olgu olarak hareket eden sorgu
konusu:
Ürün yelpazesi ve Satış
Satış
Ürün tipi ve Ürün tahmini
Ürün tahmini
Bölünmemiş Olması Gereken Sorguları Çözme
Sorgular bölünmüşse, ancak bölünmemesi gerekiyorsa, bu sorguları çözmeniz gerekir.
Tüm ilişkilerin n tarafındaki sorgu konuları, olgular olarak tanımlanır. Aşağıdaki örnekte,
Sipariş Üstbilgisi ve Ülke (Çok Dilli)'nin olgular olarak hareket ettiğini görebiliriz. Gerçekte,
Ülke (Çok Dilli) sorgu konusu yalnızca açıklayıcı bilgileri içerir ve bir referans tablosu olarak
görülür. Boyutlu modelleme veya iş modelleme açısından bakıldığında, Ülke (Çok Dilli),
Ülke'nin bir uzantısıdır.
Modelin bu şekilde bırakılması neden soruna yol açar?
Şehir, ülke veya bölge başına sipariş sayısıyla ilgili bir rapor yazarak bu modeli sınayın. Bu
modelin kullanılması, yanlış bir sonuç döndürür. Şehirler için sayılar doğrudur, ancak bazı
şehirler, yanlış ülkede veya bölgede olarak gösterilmektedir. Bu, yanlış şekilde ilişkilendirilen
bir sonuca örnektir.
Genellikle buna benzer bir şey gördüğünüzde bakılacak ilk yer, SQL'dir.
SQL
Bu örnekte, modelde birden çok olgumuz olduğunda anlam ifade eden bir ekli sorguyu
görüyoruz. Ekli sorgu, temelde birden çok olguyu eklemeye çalışan bir sorgudur. Modelde
tanımlanan uyumlu veya ortak boyutlar için belirteçlerin yanı sıra, olguları birbiriyle
46
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
ilişkilendiren ilişkileri kullanır. Bir ekli sorgu, tam dış birleştirme içeren iki sorgu tarafından
tanımlanabilir. Sarmalayıcı sorgu, uyumlu boyutlarda bir coalesce deyimi içermelidir.
SQL'de aşağıdaki sorunlara dikkat edin:
v Sorguda coalesce deyimi yoktur.
v RSUM, geçerli bir anahtar oluşturma girişimini belirtir.
select
D3.COUNTRY as COUNTRY,
D2.CITY as CITY,
D2.number_of_orders as number_of_orders
from
(select
SALES_BRANCH.CITY as CITY,
XCOUNT(ORDER_HEADER.ORDER_NUMBER for SALES_BRANCH.CITY) as
number_of_orders,
RSUM(1 at SALES_BRANCH.CITY order by SALES_BRANCH.CITY
asc local)
as sc
from
gosales.gosales.dbo.SALES_BRANCH SALES_BRANCH
join
gosales.gosales.dbo.ORDER_HEADER ORDER_HEADER
on (SALES_BRANCH.SALES_BRANCH_CODE = ORDER_HEADER.SALES_BRANCH_CODE)
group by
SALES_BRANCH.CITY
order by
CITY asc
) D2
full outer join
(select
COUNTRY_MULTILINGUAL.COUNTRY as COUNTRY,
RSUM(1 at COUNTRY_MULTILINGUAL.COUNTRY order by
COUNTRY_MULTILINGUAL.COUNTRY asc local) as sc
from
gosales.gosales.dbo.COUNTRY_MULTILINGUAL COUNTRY_MULTILINGUAL
group by
COUNTRY_MULTILINGUAL.COUNTRY
order by
COUNTRY asc
) D3
on (D2.sc = D3.sc)
Her bir sorgudaki ekli sütunlara bakarak, bunların ilişkisiz ölçütlerde hesaplandığını görürüz.
Bu, rapordaki ülkeler veya bölgeler ile şehirler arasında neden belirgin bir ilişki olmadığını
açıklar.
O halde neden bir ekli sorgu görüyoruz? Bu soruyu yanıtlamak için, modele bakmamız
gerekir.
Bu örnekte, raporda kullanılan sorgu öğeleri farklı sorgu konularından gelmiştir. Ülke veya
bölge, Ülke (Çok Dilli) öğesinden gelmiş; Şehir, Satış Şubesi'nden gelmiş ve Sipariş Sayısı
da, Sipariş Üstbilgisi sorgu konusundaki Sipariş Numarasında yer alan bir sayımdan gelmiştir.
Bölüm 2. IBM Cognos Yazılımı Tarafından Oluşturulan SQL
47
Sorun, sorgu altyapısının bunu bir çoklu olgu sorgusu olarak görmesi nedeniyle sorgunun
bölünmesidir. Ancak, her iki olgunun ortak olarak sahip olduğu bir öğe bulunmadığından,
bölme, üzerinde ekleme yapılacak geçerli bir anahtara sahip değildir.
Bu sorunu çözmenin birden çok yolu vardır ancak her iki yol da verilerin anlaşılmasını
gerektirir.
Çözüm 1
1-1 ile ilişkinin satır sayısını değiştiren Ülke (Çok Dilli) öğesine bir süzgeç ekleyebilirsiniz.
Select *
from [GOSL].COUNTRY_MULTILINGUAL
Where
COUNTRY_MULTILINGUAL."LANGUAGE"=’EN’
Veya ilişkiye bir süzgeç ekleyebilir ve satır sayısını 1-1 olarak değiştirebilirsiniz.
COUNTRY.COUNTRY_CODE = COUNTRY_MULTILINGUAL.COUNTRY_CODE
and COUNTRY_MULTILINGUAL.LANGUAGE = ’EN’
Her iki seçim de, bu sorguda tek bir olguya sahip olan bir modelle sonuçlanır.
Çözüm 2
İlgili sorgu konularını birleştirerek modeli basitleştirin. Bu, modeli basitleştirip sorgu
oluşturmada hata olasılıklarını azaltarak en büyük avantajı sunar.
48
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
Her iki çözüm ile de sorgunun sonucu şimdi doğrudur.
SQL artık bir ekli sorgu değildir.
select
Country.c7 as COUNTRY,
SALES_BRANCH.CITY as CITY,
XCOUNT(ORDER_HEADER.ORDER_NUMBER for Country.c7,SALES_BRANCH.CITY)
as number_of_orders
from
(select
COUNTRY.COUNTRY_CODE as c1,
COUNTRY_MULTILINGUAL.COUNTRY as c7
from
gosales.gosales.dbo.COUNTRY COUNTRY
join
gosales.gosales.dbo.COUNTRY_MULTILINGUAL COUNTRY_MULTILINGUAL
on (COUNTRY.COUNTRY_CODE = COUNTRY_MULTILINGUAL.COUNTRY_CODE)
where COUNTRY_MULTILINGUAL.LANGUAGE=’EN’
) Country
join
gosales.gosales.dbo.SALES_BRANCH SALES_BRANCH
on (SALES_BRANCH.COUNTRY_CODE = Country.c1)
join
gosales.gosales.dbo.ORDER_HEADER ORDER_HEADER
on (SALES_BRANCH.SALES_BRANCH_CODE = ORDER_HEADER.SALES_BRANCH_CODE)
group by
Country.c7,
SALES_BRANCH.CITY
Bölüm 2. IBM Cognos Yazılımı Tarafından Oluşturulan SQL
49
50
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
Bildirimler
Bu bilgiler, tüm dünyada sunulan ürünler ve hizmetler için geliştirilmiştir.
Bu malzeme, diğer dillerde IBM'den edinilebilir. Ancak başka dildeki sürüme erişebilmek için
ürünün ya da ürün sürümünün ilgili dildeki bir kopyasına sahip olmanız gerekebilir.
IBM, diğer ülkelerde bu belgede ele alınan ürünleri, hizmetleri veya özellikleri sunmayabilir.
Şu anda bölgenizde kullanılabilir olan ürünler ve hizmetlerle ilgili bilgiler için yerel IBM
temsilcinizle görüşün. Bir IBM ürünü, programı veya hizmetine ilişkin herhangi bir başvuru,
yalnızca IBM ürünü, programı ya da hizmetini bildirecek veya ima edecek şekilde
tasarlanmamıştır. Bunun yerine herhangi bir IBM fikri mülkiyet hakkını ihlal etmeyen,
işlevsel olarak eşdeğer bir ürün, program veya hizmet kullanılabilir. Ancak, IBM dışı ürün,
program veya hizmetlerin çalışmasını değerlendirmek ve doğrulamak, kullanıcının
sorumluluğudur. Bu belge, satın aldığınız Program veya lisans yetkisine dahil edilmemiş
ürünleri, hizmetleri ya da özellikleri açıklayabilir.
IBM, bu belgede açıklanan konuları kapsayan patentlere veya beklemedeki patent
uygulamalarına sahip olabilir. Bu belgedeki bilgiler size bu patentlerin lisansını vermez.
Lisans sorgularını yazılı olarak şu adrese gönderebilirsiniz:
IBM Director of Licensing
IBM Corporation
North Castle Drive
Armonk, NY 10504-1785
ABD
İkili bayt (DBCS) bilgileriyle ilgili lisans sorguları için ülkenizdeki IBM Fikri Mülkiyet
Departmanı ile görüşün veya yazılı olarak şu adrese sorgu gönderin:
Intellectual Property Licensing
Legal and Intellectual Property Law
IBM Japan Ltd.
19-21, Nihonbashi-Hakozakicho, Chuo-ku
Tokyo 103-8510, Japonya
Aşağıdaki paragraf, İngiltere ya da bu tür hükümlerin yerel yasalarla uyuşmadığı diğer
ülkelerde geçerli değildir: IBM BU YAYINI, HAK İHLALİ YAPILMAYACAĞINA DAİR
ZIMNİ GARANTİLERLE TİCARİLİK VEYA BELİRLİ BİR AMACA UYGUNLUK İÇİN
ZIMNİ GARANTİLER DE DAHİL OLMAK VE FAKAT BUNLARLA SINIRLI
OLMAMAK ÜZERE AÇIK YA DA ZIMNİ HİÇBİR GARANTİ VERMEKSİZİN
"OLDUĞU GİBİ" ESASIYLA SAĞLAMAKTADIR. Bazı devletler, belirli işlemlerde açık
veya zımni garanti feragatnamesine izin vermez, bu nedenle bu bildirim sizin için geçerli
olmayabilir.
Bu bilgiler, teknik tutarsızlıklar veya tipografik hatalar içerebilir. Buradaki bilgiler üzerinde
düzenli olarak değişiklikler yapılır; bu değişiklikler, yeni yayın basımlarında birleştirilecektir.
IBM, önceden bildirimde bulunmaksızın, bu yayında açıklanan ürünler ve/veya programlar
üzerinde iyileştirmeler ve/veya değişiklikler yapabilir.
© Copyright IBM Corp. 2005, 2014
51
Bu bilgiler içinde, IBM dışı Web sitelerine yapılan başvurular yalnızca kolaylık sağlamak için
sunulmuş olup bu Web sitelerinin onaylandığını belirtmez. Bu Web sitelerindeki malzemeler,
bu IBM ürününe ilişkin malzemeler arasında yer almaz ve bu Web sitelerinin kullanımı
tamamen sizin sorumluluğunuzdadır.
IBM, size hiçbir sorumluluk yüklemeden, sizin sağladığınız ve uygun olduğuna inandığı her
türlü bilgiyi kullanabilir ya da dağıtabilir.
(i) bağımsız olarak oluşturulan programlar ile diğer programlar (bu da dahil) arasındaki bilgi
alışverişini ve (ii) alışverişi yapılan bilgilerin karşılıklı kullanımını etkinleştirme amacıyla bu
programla ilgili bilgi edinmek isteyen programın lisans sahipleri şu adresle iletişim
kurmalıdır:
IBM Software Group
Attention: Licensing
3755 Riverside Dr.
Ottawa, ON K1V 1B7
Kanada
Bazı durumlarda ücret ödeme gibi ilgili hüküm ve koşullara tabi olarak bu bilgiler kullanıma
sunulabilir.
Bu belgede açıklanan lisanslı program ve program için kullanıma sunulan tüm lisanslı
malzeme, IBM Müşteri Sözleşmesi, IBM Uluslararası Lisans Sözleşmesi veya bizimle yapılan
herhangi bir eşdeğeri sözleşme koşulları altında IBM tarafından sağlanmaktadır.
Burada bulunan tüm performans verileri, denetimli bir ortamda belirlenmiştir. Bu nedenle,
diğer işletim ortamlarında elde edilen sonuçlar büyük ölçüde değişiklik gösterir. Bazı
ölçümler, geliştirme düzeyi sistemlerde yapılmış olabilir ve bu ölçümlerin genel olarak
kullanılabilir sistemlerde aynı olacağına dair bir garanti yoktur. Ayrıca bazı ölçümler,
dışdeğerleme yoluyla belirlenmiş olabilir. Gerçek sonuçlar değişiklik gösterebilir. Bu belgenin
kullanıcıları, belirli ortamları için uygun verileri doğrulamalıdır.
IBM dışı ürünlerle ilgili bilgiler, bu ürünlerin tedarikçilerinden, yayınlanan duyurularından
veya diğer genel kullanıma sunulmuş kaynaklardan alınmıştır. IBM, bu ürünleri test etmemiş
olup IBM dışı ürünlerle ilgili performans doğruluğunu, uyumluluğu veya diğer iddiaları
onaylayamaz. IBM dışı ürünlerin yetenekleriyle ilgili sorular, bu ürünlerin tedarikçilerine
yöneltilmelidir.
IBM'in gelecekteki yönelimi veya amacıyla ilgili tüm beyanlar, önceden bildirimde
bulunulmaksızın değiştirilebilir ya da geri çekilebilir ve yalnızca hedef ve amaçları temsil
eder.
Bu bilgiler, günlük işlemlerde kullanılan veri ve rapor örneklerini içerir. Bunları olabildiğince
eksiksiz şekilde göstermek için, örneklerde kişi, şirket, marka ve ürünlerin adları yer
almaktadır. Tüm bu adlar kurgusal olup kullanılan ad ve adreslerin gerçek bir kuruluşla olan
benzerliği tamamen tesadüftür.
Bu bilgileri elektronik kopya olarak görüntülüyorsanız, fotoğraflar ve renkli resimler
görünmeyebilir.
Konuşlandırılan yapılandırmalara bağlı olarak bu Yazılım Olanağı, her bir kullanıcının
aşağıdaki bilgilerini toplayan kalıcı tanımlama bilgilerini ve oturumu kullanabilir:
v ad
v kullanıcı adı
52
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
v parola
Bu bilgileri aşağıdaki amaçlarla kullanır:
v
v
v
v
v
oturum yönetimi
kimlik doğrulaması
gelişmiş kullanıcı kullanılabilirliği
tek oturum açma yapılandırması
oturum yönetimi, kimlik doğrulaması, gelişmiş kullanıcı kullanılabilirliği ve tek oturum
açma yapılandırması dışındaki işlevsel amaçlar ya da kullanımı izleme
Bu tanımlama bilgileri devre dışı bırakılamaz.
Bu Yazılım Olanağı için konuşlandırılan yapılandırmalar, müşteri olarak size tanımlama
bilgileri ya da diğer teknolojiler aracılığıyla son kullanıcılardan kimliği tanımlayıcı bilgiler
toplama yeteneği sağlıyorsa, bildirim ve izin gereksinimleri de dahil olmak üzere, bu tür veri
toplama işlemleriyle ilgili geçerli yasalar hakkında yasal danışmanlığa başvurmanız gerekir.
Tanımlama bilgileri de dahil olmak üzere çeşitli teknolojilerin bu amaçla kullanımı hakkında
daha fazla bilgi için, http://www.ibm.com/privacy adresindeki IBM'in Gizlilik İlkesine ve
http://www.ibm.com/privacy/details adresindeki IBM'in Çevrimiçi Gizlilik Bildirimine
("Tanımlama Bilgileri, Web İşaretleri ve Diğer Teknolojiler" başlıklı bölümde bulunur) ve
http://www.ibm.com/software/info/product-privacy adresindeki "IBM Yazılım Ürünleri ve
Hizmet Olarak Yazılım Gizlilik Bildirimi" bölümüne bakın.
Ticari Markalar
IBM, IBM logosu ve ibm.com, International Business Machines Corp.'un dünya çapında
birçok farklı hukuk düzeninde kayıtlı bulunan ticari markaları ya da tescilli ticari markalarıdır.
Diğer ürün ve hizmet adları, IBM veya diğer şirketlerin ticari markaları olabilir. IBM ticari
markalarının güncel bir listesine www.ibm.com/legal/copytrade.shtml adresindeki “Copyright
and trademark information (Telif hakkı ve ticari marka bilgileri) başlıklı konudan ulaşılabilir”.
Bildirimler
53
54
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
Dizin
A
H
ana detay tabloları 26, 30
ayrıntı düzeyi 24
hesaplamalar
işlemlerin sırası 15
hesaplamalar için işlem sırası 15
hesaplamalar için işlemler 15
hesaplamalar için toplama 15
hesaplanan toplama tipi 15
B
belirsiz ilişkiler 20
belirsiz nesneler 45
belirteçler
sorgu nesneleri 13
tanımlama 4
birden çok geçerli ilişki 20, 23
birden çok sıradüzen 28
bire bir ilişkiler 39
bire çok ilişkiler 39
birleştirmeler
döngü 23
boyutlar
belirsiz 45
model 7
normal 7, 13, 17, 27
oyun 20
ölçü 17, 30
paylaşılan 17
sıradüzenler 28
sorgu nesneleri 7
tanımlama 20
yıldız şeması grupları 31
boyutlu sorgular 35
çoklu olgular ve grenler 37, 41
tekli olgu 35
boyutlu veri 26
İ
içe aktarılan meta veriler
kontrol etme 19
ilişkiler
1-n 39
ayrıntı düzeyleri 24
belirsiz 20
birden çok geçerli 20, 23
kontrol etme 19
satır sayısı 2
ilişkisel meta verileri boyutlu olarak modelleme
ilişkisel modelleme kavramları 1
isteğe bağlı satır sayısı 2
K
kavramlar 1
kısayollar 13
M
maksimum satır sayısı 2
minimum satır sayısı 2
model nesneleri
kısayollar 13
Ç
çapraz olgu sorguları 19, 20
çift sayım 19, 39, 45
çoklu gren sorguları 7, 37, 41
çoklu olgu sorguları 7, 37, 41
çözme
belirsiz nesneler 45
sorguları bölme 46
N
normal boyutlar 7, 13, 17
oluşturma 27
oyun 20
sıradüzenler 28
normalleştirilmiş veri kaynakları
D
DMR (boyutlu olarak modellenmiş ilişkisel) meta veri
döngüsel birleştirmeler 19, 23
E
ekli sorgular
19
G
geçerli ilişkiler
birden çok 20
© Copyright IBM Corp. 2005, 2014
27
27
26
O
olgu verisi 26
olgular 30
belirsiz 45
tanımlama 20
olgusuz sorgu 31
oluşturma
normal boyutlar 27
ölçü boyutları 30
yıldız şeması grupları
oyun boyutları 20
31
55
Ö
sorgular (devamı var)
çoklu olgu 7, 37, 41
ekli 19
olgusuz 31
split 46
tekli olgu 35
sorguları bölme 46
SQL 35
ölçü boyutları 17
oluşturma 30
oyun 20
P
parçalanmış veri kaynakları
paylaşılan boyutlar 17
26
tekli olgu sorguları
toplama 4
S
satır sayısı
1-1 39
1-n 39
boyutlar ve olgular 20
kontrol etme 19
kurallar 2
sorgular 2
türler 2
satır sayısı kuralları 2
sıradüzenler 4, 7
birden çok 28
sorgu nesneleri
belirteçler 13
boyutlar 7
yıldız şeması grupları 31
sorgular
çoklu gren 7
56
T
35
U
uyumlu boyutlar 31
çoklu olgular 37, 41
uyumlu yıldız şeması grupları
Y
yansıma ilişkileri 24
yıldız şeması grupları 17
birden çok uyumlu 31
oluşturma 31
yıldız şeması kavramları 25
yinelemeli ilişkiler 24
IBM Cognos Framework Manager Sürüm 10.2.2: Meta Verileri Modelleme için Yönergeler Kılavuzu
31