Sayfa Ayarları
Arama
Kayıt Ol Giriş

Burdasınız: Home » Kategoriler » ORACLE » Ercan Yazgan
Cuma, 05 Kas 2010
Ercan Yazgan

Ercan Yazgan

Oracle Technologies Specialist

Website bağlantısı: E-posta: Bu e-Posta adresi istek dışı postalardan korunmaktadır, görüntülüyebilmek için JavaScript etkinleştirilmelidir

Oracle index kullanımı

Salı, 02 Kasım 2010 22:24 Kategori Oracle

Veritabanına gönderdiğimiz SQL sorgularına daha kısa sürede yanıt almak ve daha düşük donanım gücü tüketmesi açısından için çoğu zaman veritabanına yeni indeksler ekleriz. Sunucuya gönderilen sorgunun içeriğine göre oluşturduğumuz bu indekslerin kullanım sıklığına Oracle veritabanı cost based hesabı yaparak (execution plan) karar vermektedir. Bu konuda veritabanındaki mevcut indesklerin hangi sıklıkla kullanılacağına spesifik olarak “optimizer_index_cost_adj” isimli Oracle sistem parametresi karar verir.

Optimizer_index_cost_adj parametresini biraz açarsak, “1″ ile “10.000″ arasında bir değer atayarak (default değer 100) Oracle ‘ın indeks hassasiyetini arttırıp azaltabilirsiniz. Buna göre parametreye atanacak düşük bir değerde (10-50 arasında) Oracle sonucunu almak istediğiniz sorguya uygun olan bir indeks kullanmaya (force) çalışacaktır. Paremetreye verilecek olan değer arttırıldığı taktirde (misal 200-10.000 arasında) Oracle indeks kullanımından feragat ederek tablo üzerinde full tablescan ‘e yönelecektir.

Performance tuning amaçlı kullanılan optimizer_index_cost_adj parametresini kendi sisteminize uyarlarken dikkat edilmesi gereken nokta, parametrenin değeriyle oynamadan önce veritabanın güncel istatistiğinin alınmasıdır. Buna göre parametre değişikliğinden kaynaklı oluşabilecek yanlış execution plan kullanımı ve akabinde yaşanacak performans kaybının önüne geçilebilir.

Aşağıda örnek bir sorgu çalıştırarak konuyu açıklamaya çalışacağım.

* Öncelikle optimizer_index_cost_adj parametresinin değerini “10″ olarak değiştiriyorum.

SQL> alter system set optimizer_index_cost_adj=10 scope=memory;

* SQL sorgunun execution planını incelemek amacıyla trace ‘i etkileştirip sorgumu çalıştırıyorum.

SQL> select count(*) from test.test_tbl where isim=ahmet, uyelik_tarihi>sysdate-100

--------------------------------------------------------------------------------

Plan name: SYS_SQL_PLAN_9ch1da8da5d612n3

Enabled: YES Fixed: NO Accepted: NO Origin: AUTO-CAPTURE

--------------------------------------------------------------------------------

Plan hash value: 7123371084

----------------------------------------------------------------------------------------------------------------------

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |

----------------------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 32 | 22 (0)| 00:00:01 | | |

| 1 | SORT AGGREGATE | | 1 | 32 | | | | |

| 2 | CONCATENATION | | | | | | | |

| 3 | PARTITION RANGE ITERATOR | | 3 | 96 | 7 (0)| 00:00:01 | KEY | KEY |

|* 4 | TABLE ACCESS BY LOCAL INDEX ROWID| TEST_TBL | 3 | 96 | 7 (0)| 00:00:01 | KEY | KEY |

|* 5 | INDEX RANGE SCAN | TEST_TBL_IDX1 | 2 | | 7 (0)| 00:00:01 | KEY | KEY |

| 6 | PARTITION RANGE ITERATOR | | 90156 | 2817K| 7 (0)| 00:00:01 | KEY | KEY |

|* 7 | TABLE ACCESS BY LOCAL INDEX ROWID| TEST_TBL | 90156 | 2817K| 7 (0)| 00:00:01 | KEY | KEY |

|* 8 | INDEX RANGE SCAN | TEST_TBL_IDX1 | 2 | | 7 (0)| 00:00:01 | KEY | KEY |

| 9 | PARTITION RANGE ITERATOR | | 8 | 256 | 7 (0)| 00:00:01 | KEY | KEY |

|* 10 | TABLE ACCESS BY LOCAL INDEX ROWID| TEST_TBL | 8 | 256 | 7 (0)| 00:00:01 | KEY | KEY |

|* 11 | INDEX RANGE SCAN | TEST_TBL_IDX1 | 2 | | 7 (0)| 00:00:01 | KEY | KEY |

----------------------------------------------------------------------------------------------------------------------

* Oracle ‘ı mevcut indeksleri daha fazla kullanması için düzenledikten sonra, yukarıdaki detaylı execution plan dökümünden anlaşılacağı üzere çalıştırdığımız sorgu tabloda doğru indeksi tespit edip (veritabanı istatistiğinin güncel olmasına bağlı olarak) kullandı.

* Şimdi farklı bir deneme yapmak için optimizer_index_cost_adj parametresinin değerini “2000″ olarak değiştiriyorum. Bu noktada beklentim Oracle ‘ın indeks kullanımından uzaklaşarak aynı sorgu için farklı bir execution plan seçmesi.

SQL> alter system set optimizer_index_cost_adj=2000 scope=memory;

* SQL sorgunun execution planını incelemek amacıyla yine trace işlemini etkileştirip sorgumu çalıştırıyorum.

SQL> select count(*) from test.test_tbl where isim=ahmet, uyelik_tarihi>sysdate-100

--------------------------------------------------------------------------------

Plan name: SYS_SQL_PLAN_1e5dda4d8748d58e

Enabled: YES Fixed: NO Accepted: YES Origin: AUTO-CAPTURE

--------------------------------------------------------------------------------

Plan hash value: 2481613860

-------------------------------------------------------------------------------------------------------

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |

-------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 32 | 1519K (1)| 05:03:50 | | |

| 1 | SORT AGGREGATE | | 1 | 32 | | | | |

| 2 | CONCATENATION | | | | | | | |

| 3 | PARTITION RANGE ITERATOR| | 3 | 96 | 506K (1)| 01:41:16 | KEY | KEY |

|* 4 | TABLE ACCESS FULL | TEST_TBL | 3 | 96 | 506K (1)| 01:41:16 | KEY | KEY |

| 5 | PARTITION RANGE ITERATOR| | 90156 | 2817K| 506K (1)| 01:41:17 | KEY | KEY |

|* 6 | TABLE ACCESS FULL | TEST_TBL | 90156 | 2817K| 506K (1)| 01:41:17 | KEY | KEY |

| 7 | PARTITION RANGE ITERATOR| | 8 | 256 | 506K (1)| 01:41:17 | KEY | KEY |

|* 8 | TABLE ACCESS FULL | TEST_TBL | 8 | 256 | 506K (1)| 01:41:17 | KEY | KEY |

-------------------------------------------------------------------------------------------------------

* Yukarıdaki tablodan da anlaşılacağı üzere çalıştırdığımız sorgu tabloda full tablescan ‘e girdi. Her ne kadar kullanmakta olduğum tablo partitioning yapılmış olsada sorgu indeks kullanmadığı için daha yüksek bir cost ‘a sahip. Yanlız bu cümleden her zaman indeks kullanmak performans kazandırır gibi bir düşünce oluşmamalı çünkü, indeks kullanım performansı mevcut tablonuza ve bu tabloya gönderdiğiniz SQL sorgusunun içeriğe bağlı olarak değişiklik gösterebilir.

Konuyu sonuca bağlamak gerekirse, optimizer_index_cost_adj parametresi Oracle ‘ın veritabanı performansını doğrudan etkileyebilecek sistem parametrelerinden bir tanesi. Farklı uzmanlar bu parametre için farklı değerler kullanılmasını öneriyor. Örnek olarak ünlü Oracle uzmanı Tom Kyte bu parametrenin AWR raporları gözlenerek cache/hit oranına göre ayarlanması gerektiğini belirtiyor. Diğerleri OLTP sistemler için optimizer_index_cost_adj parametresinin “10-50″ arasında ayarlanmasının performansa büyük etkisi olacağı görüşünü paylaşıyor. Sonuç itibariyle veritabanın performansına doğrudan etki edecek bir parametre için bende öncelikle AWR raporlarını takip edilmesi konusunda hem fikirim.

Alıntıdır --> http://www.boraovali.com/?p=363

PL-SQL (ORACLE) Fonksiyonları / Decode, NVL, NVL2

Salı, 02 Kasım 2010 00:39 Kategori Oracle

PL-SQL Fonksiyonları : NVL

NVL(deger, deger_Null_ise_bu_deger_ile_degistir )

fonksiyonu eğer deger ifadesinin değeri "null" ise, deger_Null_ise_bu_deger_ile_degistir ifadesi ile değiştirir. Diğer durumlarda deger i geri döndürecektir.

Fonksiyonun amacı, null olarak gelen değerleri, belirtilen değer ile değiştirmektir. Bu işlev ile ilgili alandaki tüm değerlerin "null" olmaması garanti edilir.

Nerelerde tercih edilir ?

  • Çoğunlukla sayısal bir değer döndürmesi beklenen alanlardaki veriler eğer "null" ise 0 ile değiştirmek için kullanılır. Örneğin, müşterilerin yıl yıl gerçekleştirdiği tüm ödemeleri toplamak istiyorsunuz. Her bir müşterinin her yıl için ödeme yapmamış olacağı olası ve beklendik bir durumdur. Dolayısıyla müşteri ile dönem ve ödeme tablosunu "left join" ile bağladığınızda, bazı dönemlere ait ödeme kayıtlarınız "null" olarak gelecektir. Aritmetik işleme dahil edebilmek için bu alanları 0 ile değiştirmeniz gerekmektedir.
  • String değerleri birleştimek istediğinizde, "null" kontrolu yapmanız gerekmektedir. Çünkü birleştireceğiniz alanlar (metinler) içinde eğer bir tane bile "null" değere sahip alan varsa, tüm ifadeniz "null" olacaktır. Bu durumda "null" olan değeri '' (boş karakter) ile değiştirmeniz gerekmektedir. Örneğin, il , ilçe ve semt tanımının bulunduğu tablonuzdaki bu alanları birleştirerek müşterinin adresini tek satır halinde elde etmek istiyorsanız, bu alanlardan herhangi birisinin girilmemiş olma ihtimalini (null olma ihtimali) göz ardı etmemelisiniz aksi taktirde sadece semt bilgisi girilmemiş kayıtlar için bile tüm adres degerini "null" olarak elde edersiniz.

select  NVL(donem_toplami,0) as toplam ...

select  NVL(metin1,'') || NVL(metin2,'') || ... || NVL(metinN,'') as olusturulanMetin ...

PL-SQL Fonksiyonları : NVL2

NVL2( deger, deger_Null_degilse_bu_deger_ile_degistir, deger_Null_ise_bu_deger_ile_degistir)

fonksiyonu deger i eğer deger NULL değilse 2. parametre ile NULL is 3.parametre ile değiştirir.

Özelleştirilmiş bir IF-ELSE yazımıdır. Eğer alan "null" değil ise deger_Null_degilse_bu_deger_ile_degistir değeri ile , "null" ise deger_Null_ise_bu_deger_ile_degistir değeri ile değiştirir.

Nerede tercih edilir ?

  • Bir alanın "null" olup olmama durumuna göre kullanıcıya anlamlı bir mesaj vermek istediğinizde kullanabilirsiniz. "null" ise YOK , değil ise VAR yazmak için kullanabilirsiniz.

PL-SQL Fonksiyonları : DECODE

Decode( ifade, aranan_deger1, aranan_deger1e_esit_ise_bu_deger_ile_degistir,aranan_deger2 ,aranan_deger2e_esit_ise_bu_deger_ile_degistir,  [aranan_degerN, aranan_degerNe_esit_ise_bu_deger_ile_degistir]... [hicbiri_ile_eslesmedi_ise_bu_deger_ile_degistir] )

fonksiyonu ifade içersinde aranan_deger1 ... aranan_degerN degerlerini arar ve ifade hangi aranan_deger e karşılık geliyor ise  aranan_degere_esit_ise_bu_deger_ile_degistir degerini döndürür.

Fonksiyonu IF-THEN-ELSE-END kullanımına karşılık gelir. Pl-Sql özelinde CASE-WHEN-ELSE-ENDCASE-WHEN kalıbında istediğiniz herhangi bir koşulu kullanabilirken, Decode eşitlik durumları için elverişlidir. kalıbına karşılık gelir. Bu kalıbın eşitlik durumları için özelleştirilmiş halidir. Yani

Nerelerde tercih edilir ?

  • NVL fonksiyonları sadece "null" ile kıyaslama yaparken, Decode fonksiyonu herhangi bir değer ileNVL fonksiyonlarını kapsar. Onların kullanıldığı heryerde kullanılabilir.  kıyasma yapabilme imkanı tanır. Dolayısyla
  • Belirli kodlara karşılık, bazı tanımlar yazılmak isteniyorsa kullanılır. Örneğin, Decode(IL_KODU,34, 'İSTANBUL', 10, 'BALIKESİR' , 10.5 , 'BANDIRMA' , 35, 'İZMİR' , 35.5 , 'KARŞIYAKA', 'TÜRKİYE') de olduğu gibi dönen il koduna göre İSTANBUL,BALIKESİR, BANDIRMA ... yada hiç eşleşen olmaması durumda TÜRKİYE döndürmek için kullanılabilir.
  • Referans tabloları olmayan değerleri anlamlandırmak için kullanılabilir. DECODE(Alan,1,'Evet', 0, 'Hayır','Belki') şeklinde tanımlarsak, Alan'dan dönen değer 1 ise Evet , 0 ise Hayır , 1 veya 0 dan farklı bir deger döner ise Belki degerini geri döndürecektir.

Alıntıdır --> http://dervisali.blogspot.com/2008/06/oracle-functions.html

Temporary Tablespace Alanı Hakkında

Salı, 02 Kasım 2010 00:33 Kategori Oracle

Oracle veritabanında büyük ölçekteki sort işlemleri için sunucumuzun hafızası (RAM) yetersiz kaldığında, bu işlemlerin sabit disk üzerinde gerçekleştirilmesi gerekmektedir. Bu işlemlerin sabit disk üzerinde gerçekleştirildiği Oracle veritabanı alanına temporary tablespace denilir. Temporary tablespace ‘in diğer tablespace ‘lerden farkı, mantıksal anlamda  datafile değil tempfile kullanmasıdır. O nedenle temporary tablespace ‘e yeni bir datafile ekleneceği zaman komut içersinde datafile değil, “tempfile” ifadesini kullanırız.

Veritabanımızın temporary tablespace alanını resize edemediğimiz durumlarda veya yeni bir temporary tablespace alanına ihtiyacımız duyduğumuzda aşağıdaki yönergeleri takip ederek yeni bir temporary tablespace alanı oluşturabiliriz. Bu konuda dikkat etmemiz gereken husus, default temporary tablespace alanı kullanıcılar tarafından aktif olarak sort v.b işlemler kullanıldığından, eski temporary tablespace alanını drop etmeden önce yeni temporary tablespace ‘in oluşturulmasının gerekliliğidir. Şimdi sırasıyla yeni temporary tablespace alanını oluşturup, eksisini sistemden kaldıralım.

  • Öncelikle kendimize yeni bir temporary tablespace alanı oluşturulalım. Tablespace içersindeki datafile ‘ın büyüklüğünü ihtiyacınıza göre ayarlayabilirsiniz. Oluşturacağımız yeni tablespace alanı için aşağıda 16Gb ‘lık bir datafile ekledim fakat, büyük ölçekte kayıtlara sahip tablolar tutuyorsanız buna göre daha geniş temporay tablespace kullanmanız gerekebilir.

SQL> create temporary tablespace YENITEMP tempfile '/oracle/data/yenitemp1.dbf' size 16384M autoextend on next 512M maxsize 32767M;

  • Yeni temporary tablespace alanını veritabanına ekledik. Şimdi yeni eklediğimiz temporary tablespace alanını, default tablespace olarak atayalım. Bundan sonra yapılacak olan sort işlemleri artık yeni oluşturduğumuz tablespace ‘de gerçekleştirilecek.
  • Yeni default temporary tablespace alanımızı kullanmaya başladık, artık eski temporary tablespace alanını drop etmeye hazırız.

SQL> alter database default temporary tablespace YENITEMP;

SQL> drop tablespace ESKITEMP including contents and datafiles;

Tebrikler.

Alıntıdır --> http://www.boraovali.com/?cat=1

Table Partition oluşturma

Salı, 02 Kasım 2010 00:21 Kategori Oracle

Tablonun boyutunun, bir alanındaki yoğunluktan ötürü gigabytelar seviyesinde büyük olduğu durumlarda, verinin sorgulanmasında ve update edilmesinde yavaşlıklar meydana gelecektir. Bu tür durumlarda, tabloyu bloklara (partition) ayırarak, erişim hızını artırabiliriz. Her partition farklı tablespace veya farklı disklerde oluşturulabilir.

Böyle bir uygulama için veritabanı sunucusu en az 2 işlemcili ve 1 Gbyte RAM´e sahip olmalıdır. Konfigurasyon yapılırken unutulmamalıdır ki, Oracle, diğer bir çok uygulamada olduğu gibi, 2 ve 2 nin katları olan değerlerde daha iyi ve daha sorunsuz çalışır.

Bu uygulamaya ne tür durumlarda ihtiyaç duyacağımızı ve nasıl bir çözüm sunacağımızı bir örnekle açıklamaya çalışalım.


Elimizde uzun yıllardır kullandığımız kişi bilgilerinin bulunduğu bir UYE tablomuz olsun. TC.Kimlik No uygulaması duyurulduğunda, basit bir şekilde TC KimlikNo alanını oluşturmuş olalım. İlerleyen süreçte, bu alanın önemi ve kullanımı gittikçe artacağı açıktır. Bu alan önce zorunlu hale getirildi, eksik olanların bilgileri Nüfus Müdürlüğünden çekilip güncellendi, ve sonunda her şey bu alana bağlı çalışmaya başladı. İlk duruma göre bu bilginin bulunduğu tablo standart bir tablo olarak create edilmişti. Fakat devamında tablo oldukça büyüdü, bütün uygulamalar bu tablodaki TC Kimlik No ile yapılmaya başlandı, dolayısıyla select ve update lerde belirgin performans düşüşü meydana geldi. İşte bu noktada "ne yapmamız lazım?" sorusunun cevabı "PARTITIONAL TABLE" olacaktır.

Bir tabloyu Partitional Table yapmaya karar verdiğimizde, öncelikle var olan tablo ile aynı alanlara sahip bir tabloyu aşağıdaki örnekte görüldüğü şekilde Partitional Table olarak create ederiz.

(Bu örneğimizde, UYE isimli bir tablomuz var, bu tabloyu, KAYIT_TARIHI sutununa göre birkaç partitiona bölmek istiyoruz.)

CREATE TABLE UYE_2(
KISI_ID                  NUMBER(6)               NOT NULL,
ADI                       VARCHAR2(30)         NOT NULL,
SOYADI                 VARCHAR2(30)         NOT NULL,
EPOSTA                 VARCHAR2(30)         NOT NULL,
TELEFON                VARCHAR2(10)         NOT NULL,
KAYIT_TARIHI        DATE                      NOT NULL,
BOLUM                   NUMBER(2)              NOT NULL
)

PARTITION BY RANGE (KAYIT_TARIHI) (

PARTITION KAYIT_TARIHI_1995 VALUES LESS THAN (to_date(´01/01/1996´,´DD/MM/YYYY´)),

PARTITION KAYIT_TARIHI _1996 VALUES LESS THAN (to_date(´01/01/1997´,´DD/MM/YYYY´)),

PARTITION KAYIT_TARIHI _1997 VALUES LESS THAN (to_date(´01/01/1998´,´DD/MM/YYYY´)),

PARTITION KAYIT_TARIHI _1998 VALUES LESS THAN (to_date(´01/01/1999´,´DD/MM/YYYY´)),

PARTITION KAYIT_TARIHI _1999 VALUES LESS THAN (MAXVALUE)

);

Burada PARTITION BY RANGE( ) ile kayıtlarımızı, KAYIT_TARIHI sütununa göre partitionlara böldük. Örneğin ilk satırda;  01/01/2006 dan önceki tüm kayıtlar için bu partition kullanılmasını ve partition adının KAYIT_TARIHI_1995 olduğunu belirttik.

select count(KISI_ID) from UYE_2 partition (KAYIT_TARIHI_1995);

şeklinde bir sorgulama yaptığımızda, sorgu sadece KAYIT_TARIHI_1995 partitionunda çalışacağından, bize oldukça fazla performans ve zaman kazancı sağlayacaktır.

Bundan sonra ise, eski tablomuzdaki verilerin exportunu alıp, eski tabloyu silmemiz, yeni tablomuzun adını düzelttikten sonra, export aldığımız verileri import etmemiz gerekmektedir. Bundan sonraki işlemler bu makalenin konusu olmadığından, kısaca yazarak geçiyoruz.

Export İşlemi :

c:>exp hr/hr file=c:uye.exp log=c:uye.log tables="UYE"

SQLPlus kullanılarak, UYE tablosu drop edilir:

SQL>drop table uye cascade constraints;

UYE_2 tablosunun adı UYE olarak değiştirilir:

SQL>rename UYE_2 to UYE;

Son olarak veriler UYE tablosuna import edilir:

C:> imp system/systempsw fromuser=hr touser=hr file=c:uye.exp log=c:imp.log tables="UYE" ignore=y commit=y

Artık elimizde belirli yıllara göre partitionlara böldüğümüz tablomuz mevcut oldu. Eğer gerekirse; Enterprise Manager Console ile Reorganizing Shema Object ?ten partition tabloyu online olarak normal hale getirebiliyoruz.

Bu makaleye katkılarından dolayı Ertuğrul Komut ´a teşekkürler.

http://www.findikkurdu.com/Article.aspx?ID=107' dan alıntıdır.

Dinamik SQL - 1

Pazar, 31 Ekim 2010 14:33 Kategori Oracle

Arkadaşlar bu makalemde sizlere dinamik SQL konusundan söz edeceğim.

Dinamik SQL Nedir ?

Dinamik SQL, senaryosu çalışma zamanından once bilinmeyen SQL cümlecikleri ile program yazma imkanı sağlayan bir tekniktir. Dinamik SQL’in detaylarına girmeden önce sizlere statik SQL den bahsetmek istiyorum. Böylelikle ikisi arasındaki farkı daha net anlayacağınızı düşünüyorum. Statik SQL komutları çalışmadan çalışmaya değişmez. Komutun tüm senaryosu derlendiği anda bilinir ve herhangi bir alter işlemi söz konusu olmadıkça öylece sabitlenir ve şu avantajları sağlar :

1) Hatasız derlenmiş bir SQL komutunda tüm objelerin veritabanında geçerli olduğu bilinir,

2) Hatasız derlenmiş bir SQL komutunda tüm yetkilendirmelerin yerli yerinde olduğu bilinir.

3) Statik SQL komutlarının sağladığı performans dinamik SQL’e göre daha üstündür.

Bu avantajlara baktığımızda dinamik SQL’I ancak, static SQL komutlarıyla başaramadığımız işlerde veya static SQL komutlarının kullanışsız kaldığı durumlarda kullanmayı tercih etmeliyiz.Her ne kadar statik SQL in kısıtlamaları olsa da performans bakımından dinamik SQL e nazaran üstündür. İçinizdeki soruyu duyar gibiyim, “e pekala neden dinamik SQL ?”…

Neden Dinamik SQL ?

Programlarınızda bazı anlarda yazacağınız SQL komutlarının full içeriğini bilmeyebilirsiniz. Yani SQL sorgunuz, kullanıcıdan gelecek değişik input değerlerine gore şekillenme ihtiyacı duyabilir. Lafı karıştırmadan hemen bir örnek verelim;

Bir datawarehouse ortamınız var ve siz bu ortamdaki bir raporlama modülünüzdeki tablo isimlerini derlendiği tarihe gore atamak istiyorsunuz. Mesela INV_01_1997, INV_04_1997, INV_07_1997, INV_10_1997 gibi. Böyle durumlarda raporlama modülünüzde dinamik SQL kullanarak tablolarınızı çalışma zamanında ‘create’ edebilirsiniz.

Veya programınızda bir listeleme modülü var ve sıralamayı kullanıcının belirlemesini istiyorsunuz. Böyle bir durumda ‘order by’ fonksiyonu değişken olacaktır. Yani kullanıcı hangi kritere gore sıralama yapmak istiyorsa ‘order by’ o kritere gore şekillenecektir. Böyle bir durumda da dinamik SQL kullanabilirsiniz.

PL/SQL Blokları İçinde DDL ve SCL Kullanımı

PL/SQL içinde şu tipleri static SQL’ e tercihen kullanabiliriz :

- DDL(Data Definition Language) cümleleri. ‘Create’, ‘Drop’, ‘Grant’, ‘Revoke’ gibi…

- SCL(Session Control Language) cümleleri. ‘Alter Session’, ‘Set Role’ gibi..

Bir örnek verecek olursak :

CREATE TYPE t_emp AS OBJECT (id NUMBER, name VARCHAR2(20))

/

CREATE TYPE t_emplist AS TABLE OF t_emp

/

CREATE TABLE dept_new (id NUMBER, emps t_emplist)

NESTED TABLE emps STORE AS emp_table;




INSERT INTO dept_new VALUES (

10,

t_emplist(

t_emp(1, 'SCOTT'),

t_emp(2, 'BRUCE')));

DECLARE

deptid NUMBER;

ename  VARCHAR2(20);

BEGIN

EXECUTE IMMEDIATE 'SELECT d.id, e.name

FROM dept_new d, TABLE(d.emps) e  -- not allowed in static SQL

-- in PL/SQL

WHERE e.id = 1'

INTO deptid, ename;

END;



Dinamik SQL Kullanım Alanları

- Kullanıcıya çalışma zamanında sorgu seçimi veya kritere gore sıralama v.s işlem seçeneği sunan uygulamalar,

- Çalışma anında veri girişi veya optimizasyon seçeneği sunan uygulamalar,

- Veritabanındaki tablo tanımlamalarının (DDL statements) sürekli değişken olduğu uygulamalar,

- İsteğe ve ihtiyaca gore çalışma anında create edilen tablo vb. objeler içeren uygulamalar.

Konunun başında vermiş olduğumuz datawarehouse örneğine bakarsak, tablo tanımını normalde biliyoruz fakat ismini çalışma anında vermek istiyoruz. Dinamik SQL bu problemi çözüyor.

CREATE OR REPLACE PROCEDURE query_invoice(

month VARCHAR2,

year VARCHAR2) IS

TYPE cur_typ IS REF CURSOR;

c cur_typ;

query_str VARCHAR2(200);

inv_num NUMBER;

inv_cust VARCHAR2(20);

inv_amt NUMBER;

BEGIN

query_str := 'SELECT num, cust, amt FROM inv_' || month ||'_'|| year

|| ' WHERE invnum = :id';

OPEN c FOR query_str USING inv_num;

LOOP

FETCH c INTO inv_num, inv_cust, inv_amt;

EXIT WHEN c%NOTFOUND;

-- process row here

END LOOP;

CLOSE c;

END;

/

Datafile ve Tablespace Kavramları

Cumartesi, 30 Ekim 2010 17:15 Kategori Oracle

DATAFILE VE TABLESPACE KAVRAMLARI

Oracle Veritabanı üzerinde dataların yani verilerin saklandığı yer fiziksel olarak DataFile mantıksal olarak ise TableSpace olarak ifade edilmektedir.

 

 

Bir veritabanında verilerin nasıl saklandığının hiyerarşik yapısı aşağıdaki şekildeki gibidir :

Tablespace

Tablespace ler üzerinde ki işlemler Tablespace online iken yapılmaktadır.

System Table space kesinlikle undo yada temp tablespace olarak kullanılmamalıdır,

Tablespaceler read only yada normal mod arasında çevrim yapılabilirler.

Not : Tablespace bir veya fazla datafile içierebilir fakat bir datafile ancak bir tablespace’e tahsis edilir.

DataFile

Bir DataFile yalnızca bir tablespace e verilebilir.

Büyüklüğü ve optimizasyonu değiştirilebilir

Segment

Bir Datafile bir yada birden fazla segment içerebilir,

Bir segment birden fazla Tablespace e dağılabilir

Extends

Bir Segment bir veya daha fazla extend ten oluşur,

Bir segment yaratıldığında tek extend vardır ama daha sonra arttırılabilir,

DataBlocks

Extandler içinde bulunan en küçük birimdir,

Boyutu DB_BLOCK_SIZE ile Database yaratılırken belirlenir ve daha sonra değiştirilemez.

Database bloklarının büyüklüğü işletim sistemi ile doğru orantılıdır,

Oracle’ da blokların başlangıç boyutu DB_BLOCK_SIZE ile belirlenir. Bunun yanısıra Oracle, standart olmayan beş farklı blok boyutu tanımlama olanağı sunar. Gereksiz I/O işlemlerine engel olmak için veri blok uzunlığu max sınırlar içinde işletim sisteminin blok uzunluğunun bir kaç katı olmalıdır. Data bloklar, Oracle veritabanının en küçük depolama birimidir.

Oracle Alert ve Trace Dosyaları

Cumartesi, 30 Ekim 2010 17:08 Kategori Oracle

Bu makalemde kariyer hedefi olarak dba olmayı seçen arkadaşlara yönelik bir konu paylaştım. Dba konularına girdiğinizde birçok gez alert ve trace dosyalarıyla birebir iletişim halinde olacaksınız :) çünkü bu dosyalarda veritabanı ile ilgili önemli log'lar barındırılır ve dba pozisyonunda olan kişiler bu loglar aracılığıyla veritabanı sağlığında önemli roller oynayacaklardır.



ALERT VE TRACE DOSYALARI

Veritabanı açılıp kapatılırken veya bu aşamanın adımlarında herhangi bir hata durumunda oluşan hatanın bilgileri alertSID.log dosyasına yazılır. Bu dosyada veritabanı ile ilgili bütün bilgiler vardır. Dosyanın default yeri :

$ORACLE_HOME/rdbms/log

Lokasyonu BACKGROUND_DUMP_DEST parametresi ile belirlenebilir.

BACKGROUND TRACE

Background prosesler yürütülürken oluşan hatalar sonucunda oluşan dosyalardır. Lokasyonu BACKGROUND_DUMP_DEST parametresi ile belirlenir ve dosyanın formatı SID_ProcessName_PID.trc şeklindedir. Örnek olarak : db01_lgwr_23845.trc

USER TRACE

User prosessler üzerinde meydana gelen hatalar sonucunda oluşan dosyalardır. Bu dosyaların lokasyonu USER_DUMP_DEST parametresi ile belirlenir ve formatı da SID_ora_PID.trc şeklindedir. Örnek olarak : db01_ora_23845.trc bir user trace dosyasıdır.

User Trace işlemi yine bizde parametrelerce belirlenip yürütülebilen bir bilgidir.

Session bazlı olarak,

SQL > ALTER SESSION SET SQL_TRACE = TRUE

Komutuyla,

Yada Paramatre file’ından

SQL_TRACE = TRUE yapılarak user trace enable edilebilir.

Adım Adım Oracle BI

Cuma, 29 Ekim 2010 23:26 Kategori Oracle



ORACLE BI ANSWERS

Başlat -> Programlar -> Oracle Buisness Intelligence ->Welcome to Oracle BI EE tıklıyoruz.


Şekil-22

 

Oracle BI Interactive Dashboards linkine tıklıyoruz. Açılan sayfada “Answers” linkine bastığımızda browserda aşağıdaki (Şekil-23) deki ekran kesitini görebiliriz :


Şekil-23

Görüldüğü gibi Oracle BI Administrator arayüzünde presentation katmanındaki ARACTAKIP veritabanı burada görünüyor. Linke tıklayarak devam edelim.

 


Şekil-24

Yukarıdaki (Şekil-24) te görüldüğü gibi Presentation katmanında yaptığımız herşeyi burada görebiliyoruz. Ekranda görünen “Columns” bölgesine hangi alanları rapora dahil etmek istiyorsak onları koyuyoruz. “Filters” kısmında ise bunların nasıl görüneceğini belirteceğiz.

3.3.1 Columns

Ekranda görünen ARACTAKIP altındaki tablolara bağlı alanlardan hangilerini raporda görmek istiyorsak onlara tıklayarak sağdaki Columns kısmına dahil ediyoruz.


Şekil-25

İstenilen kolonlar seçildikten sonra rapor izlemek için iki seçeneğimiz vardır. Birincisi ekranda görünen sağ üst köşedeki önizleme butonuna basmak. İkincisi ise tab ekranındaki “Results” tabına basmak. Fakat Filterlarımız sürekli değişeceği için önizleme yapmak daha pratiktir. Çünkü arka planda filterlarımızda değişiklik yaparken önizlemede refresh yaparak güncel olarak değişiklikleri takip edebiliriz.

Ayrıca

Butonuna basarak raporlara Pivot ekleyebiliriz. Böylelikle istenilen alanları pivot seçerek hedef rapora ulaşabiliriz. Örnek olarak aşağıdaki şekilde marka ve seri bilgilerine göre pivot çekilmiştir. Ayrıca bu alanlara isteğe bağlı olarak da SQL fonksiyonları dahil edilebilir. Aşağıdaki (Şekil-27)de Araç kodu toplamı alınmıştır.

 


Şekil-27

 

Rapor sonucu aşağıdaki (Şekil-28) gibidir :


Şekil-28

 

İleride bu Pivot Table modülüne daha ayrıntılı değineceğiz.

 

3.3.2 Filters

Bu kısımda ise raporumuza yeni bir yüz kazandırıyoruz. Yani OLAP küpünün çok yüzlülüğü burada devreye girmiş oluyor. Şekille izah edecek olursak :


Şekil-29

Columns kısmına eklediğimiz alanın altında şekilde işaretlenmiş butona tıkladığımızda ekrandaki gibi Create/Edit Filter penceresi açılıyor ve buradan istediğimiz yılı veya yıllar arasındaki sonuçları böylelikle rapora dahil etmiş oluyoruz. Hatta sağ tarafta görünen Limited Choices seçeneğinin altında istediğimiz yıllara ait sadece belirli ayları da çekebiliriz.

Burada columns kısmına attığımız her alana bir filter ekleyerek çekeceğimiz raporlarla OLAP küpünün ne anlama geldiğini pratik olarak görmüş oluyoruz.Ekleyeceğimiz her yeni ve değişik filter, bize OLAP küpüne farklı yüzlerinden bakma olanağı sağlıyor.

3.3.3 Pivoted Tables

Şimdi ise bu raporun nasıl oluşturulduğuna anlamak için Pivot Table bileşenlerine bir göz atalım :

Gördüğümüz üzere bu modül beş adet bileşenden oluşmaktadır.


Şekil-31

a)Pages : segmenti rapor görünümüne combobox özelliği katar. Yani örnek verecek olursak ; Columns kısmındaki “İşyeri Bilgileri (Başkanlık)” alanını 'Pages' segmentine koyarsak raporda önümüze bir combobox çıkar ve hangi başkanlığa ait verileri görmek istiyorsak seçip ona göre raporu görürüz.

b)Sections : Bu segment ise raporun tek sayfa üzerinde ayrı tablolar halinde görüntülenmesini sağlar. Aynı örnek üzerinde gösterecek olursak ; “İşyeri Bilgileri (Başkanlık)” alanını bu segmente sürüklediğimizde, raporda her başkanlık için ayrı tablolar görünecektir.

c) Columns : Bu segmente koyduğumuz kolonlar bizim bizzat sonucunu görmek istediğimiz alanlardır. Adından da anlaşılacağı gibi raporda görünecek kolonlar yani tablonun sütunlarıdır. Önemli olan nokta ise , kriterlerin bu segmentte bulunması raporun tek tablo halinde bütün olarak görünmesini sağladığını bilmektir.

d) Rows : Buraya ise raporda görmek istediğimiz verilerdir. Şekildeki gibi 2006 yılının aylarına göre yapılan dağılımın sonuçlarını görmek istiyoruz. Adından da anlaşılacağı gibi görünecek tablonun satırlarıdır.

e) Measures : Pivot table'ın püf noktasıdır diyebiliriz. Bu segmente ekleyeceğimiz alan direkt olarak bizim kriterimizdir. Yani bizati görmek istediğimiz sonuçtur. Örnek raporda gördüğümüz gibi toplam yakıt miktarının yıl içindeki aylara başkanlık bazında dağılımını inceledik (Sum(harcanan_yakit)).

3.3.4 Chart Pivoted Tables

Raporlarımız tablo görünümü haricinde uygulama gereksinimine veya kullanıcı tercihine göre farklı görsellerde olabilir. Bu değişik görselleri oluşturmak üzerine Toolun sunduğu geniş bir kütüphane vardır. Bunları seçmek için aşağıdaki (Şekil-33)de görüldüğü gibi “Chart Pivoted Table” seçeneğini işaretliyoruz.


Şekil-33

Hemen yanında görünen “Chart Position” seçeneği ise oluşacak chartın tablonun neresinde görüneceğini belirler. Veya tablo görünümü istemeyip sadece Chart şeklinde görünmesini sağlayabiliriz.

Ayrıca bu chart görünümüne de istediğimiz gibi bir görünüm kazandırabiliriz. Bunu da Graph seçeneğinden belirleriz. Bu seçeneğin altında aşağıdaki şekilde görüldüğü gibi birçok seçenek sunulmuştur.


Şekil-35

Mesela Graph tipini “Pie” seçtiğimizde ve Type olarak da “3D” seçtiğimizde görünüm aşağıdaki (Şekil-36) gibi olacaktır :

 

 


Şekil-36

Bu görünüm üzerinde de isteğe bağlı olarak dilimlerin üzerine bilgileri yazdırmak, en büyük dilimi ayırmak vs. işlemler pratik olarak gerçekleştirilebilir. Bunu da aşağıdaki (Şekil-37) aracılığyla kolayca anlayabiliriz :


Şekil-37

Göründüğü gibi her dilime ayrı renk vererek istediğimiz dilimi ayırabiliyoruz. Böylelikle raporun daha net anlaşılması sağlanır. Bu işlemlerden sonra raporumuzun yeni görünümü aşağıdaki (Şekil-38) gibi olur


Şekil-38

Veri bilgilerinin pozisyonu ve gösterim şekilleri de yine bu görsel menüden isteğe bağlı olarak değiştirilebilir...

 

Oracle BI genel bakış

Cuma, 29 Ekim 2010 22:46 Kategori Oracle

2.5 ORACLE BI EE GENEL KISIMLARI

Bu makalede ise sizlere son yıllarda sıkça adını duyduğumuz bir iş zekası tool'u olan Oracle BI' dan bahsedeceğim.

Oracle BI Suite EE, temel olarak iki bölümden oluşmaktadır;

1.   Yönetim Bölümü: Veri kaynağı tanımlama, modelleme ve yönetim aktivitelerinin gerçekleştirildiği bölüm

2.   Raporlama Bölümü: Raporların, etkileşimli gösterim tablolarının (dashboard) hazırlandığı, anlık (ad-hoc) sorgulalamarın gerçekleştirildiği ve veri dağıtım işlemlerinin tanımlandığı bölüm

2.5.1 Yönetim Bölümü

Fiziksel veri kaynaklarını tanımlama, bunları kullanarak modelleme yapma ve bunları kullanıma sunma işlemleri bu bölümde yapılır. İçerisinde üç katman yer alır.

1.   Fiziksel Katman: Bu katmanda fiziksel veri kaynakları tanımları bulunur. Her kaynak için bir bağlantı havuzu (connection pool) yaratılır ve bu sayede fiziksel kaynaklara erişimler kontrol edilir. Ayrıca bu katman veri kaynağının tipine göre bağlantı tipini de (ODBC ya da doğrudan) ayarlamaktadır.

2.   Modelleme Katmanı: Fiziksel katmanda bulunan veri kaynakları, iş modelleme katmanında yapılacak çalışmalar için temel teşkil ederler. Bu katmanda yapılacak çalışmalar ile OLTP sistemlerinin kayıt yaratmaya elverişli fakat sorgu yapmaya elverişli olmayan normalize yapıları denormalize edilebilmekte, farklı veri kaynaklarından gelen bilgiler aynı modelde birleştirilebilmekte, boyut (dimension) tanımlamaları yapılmakta ve ölçütler (metric) oluşturulabilmektedir. Bu katman sayesinde kullanıcılar OLTP sisteminden soyutlanmaktadır.

Modelleme sırasında OLTP tabloları en iyi sorgu performansı almak için Star şema denilen yapılara dönüştürülür. Gerçek (Fact) tabloları oluşturulur, bunların çevrelerine boyut  (dimension) tabloları konur ve boyutlardaki kırılımlar oluşturulur.

3.   Sunum Katmanı: Bu katmanın çıktısı, kullanıcıların rapor ve sorgu hazırlamakta kullanacakları yapılardır. Bu katman sayesinde, eldeki alanlar kurum içerisinde kullanılan terminolojiye dönüştürülebilir ve modelleme için gerekli olan ama iş birimleri için herhangi bir değer taşımayan alanlar (tekliği sağlayan anahtar alanlar gibi) maskelenebilir.

Yönetim Bölümüne ait bir resim :


Şekil-2

Kullanıcı yaratma, kullanıcı grubu yaratma ve yetkilendirme işlemleri yine bu bölümde  yönetilmektedir. Oracle BI EE'nin çok etkili bir yetkilendirme yapısı yapısı vardır. Kullanıcılar ve gruplar, konu alanı bazında, bu alan içerisindeki tablo bazında ve bu tablonun alanı bazında yetkilendirmeye tabi tutulabilmektedirler.

2.5.2 Raporlama Bölümü

Yönetim bölümünde hazırlanmış konu alanları raporlama bölümü tarafından kullanılır. Oracle BI EE'nin yaygın olarak kullanılan kısmı bu bölümdür. Bu bölüm tamamen Web tabanlıdır ve WEB Browser'lar ile erişilerek kullanılmaktadır.

Dasboard: Kullanıcı sisteme ilk girdiğinde kendisinin kullanabileceği etkileşimli gösterge tablosu (dashboard) ile karşılaşır. Bir dasboard birden fazla sayfa içerebilir ve bir sayfa birçok raporu barındırabilir. Dashboard'lar uçaklardaki kokpitlere benzetilebilir. Burası genel durum hakkında bilgi almak için en uygun yerdir. Oracle BI EE, etkileşimli dasboard'ları sayesinde kullanıcıların raporlar üzerinden detaylara inmelerine (drill-down) olanak tanır. Böylelikle isteğe bağlı olarak özetten detaya inilebilir. Detaya inme işlemi her türlü rapor (tablo, grafik, pilot tablo vs.) üzerinden gerçekleştirilebilir. Kullanıcılar kendi yetkileri dahilinde mevcut dashboard'ları değiştirebilir, yenilerini hazırlayabilir ve bunları genel kullanıma sunabilir. Dashboard'ların zengin içerik seçenekleri vardır. Raporlar, başka raporlara ya da dashboardlara erişim sağlayan linkler, imajlar, hazırlanmış raporların listelenebileceği "folder" objeleri ve HTML kodunun yazılabileceği HTML objeleri dashboardlar içerisinde bulunabilirler.

Answers: Raporlar "Answers" denilen bölüm içerisinde hazırlanmaktadır. Buraya erişen kullanıcı bir konu alanı seçerek rapor ya da sorgu hazırlamaya başlayabilir. Daha önce hazırlanmış raporların değiştirilmesi de yine "answers" bölümünden gerçekleştirilir. Kullanıcılar hazırladıkları raporlar sonra kullanmak üzere saklayabilirler ya da diğer kullanıcılarla paylaşabilirler. Herhangi bir durumu incelemek üzere yapılacak anlık (ad-hoc) sorgulamalar da yine bu bölümden gerçekleştirilir.


Olap Küpü Nedir

Cuma, 29 Ekim 2010 22:43 Kategori Oracle

OLAP KÜPÜ NEDİR

İlişkisel veri tabanlarının kullanımı ve sonrasında ortaya çıkan veri ambarlarının büyüklüğü ile beraber, verilere daha hızlı şekilde erişme ve çok boyutlu analiz ihtiyaçları doğmuştur. Çevrimiçi Analitik İşleme (OLAP) veritabanları karar destek sorgularını kolaylaştırır. OLAP, işlemleri işlemek yerine sorgulama ve raporlama için en iyi duruma getirilmiş bir veritabanı teknolojisidir. OLAP'ın kaynak verileri, yaygın olarak veri depolarında depolanan Çevrimiçi İşlem İşleme (OLTP) veritabanlarıdır. OLAP verileri bu geçmiş verilerinden türer ve karmaşık çözümlemelere izin veren yapılar halinde derlenir. OLAP verileri hiyerarşik olarak da düzenlenir ve tablo yerine küplerde depolanır. Çözümlenecek verilere hızlı erişim sağlamak için çok boyutlu yapılar kullanan karmaşık bir teknolojidir. Bu düzenleme, Özet Tablo raporu veya Özet Grafik raporunun, tüm ülke veya bölgedeki toplam satışlar gibi yüksek düzeyde özetleri görüntülemesini, buna ek olarak satışların bölgelere göre güçlü mü, yoksa zayıf mı olduğu konularında da ayrıntı görüntülemesini kolaylaştırır. OLAP veritabanları iki temel veri türü içerir: konuya hakim biçimde iş kararları almak için kullandığınız sayısal veriler, miktarlar ve ortalamalar olan ölçüler ve bu ölçüleri düzenlemek için kullandığınız kategoriler olan boyutlar. OLAP veritabanları, verileri çözümlemek için bildiğiniz kategorileri kullanarak verileri pek çok ayrıntı düzeyiyle düzenlemenize yardımcı olur.

OLAP KÜP BİLEŞENLERİ

Aşağıdaki bölümlerde bu bileşenlerin her biri daha ayrıntılı bir biçimde açıklanmaktadır:

Küp Ölçüleri, çözümlemek istediğiniz boyutların her birinin düzey ve hiyerarşilerine göre derleyen bir veri yapısıdır. Küpler; zaman, coğrafya ve ürün türü gibi çeşitli boyutları satış veya stok rakamları gibi özet verilerle birleştirir. Küpler, matematikte bildiğimiz anlamda birer "küp" değildirler, çünkü eşit kenarlara sahip olmaları gerekmez. Ancak, karmaşık bir kavram için yerinde bir benzetme olduğunu söyleyebiliriz.

Ölçü Bir küpte bulunan ve küpün bulgu tablosundaki bir sütunu temel alan değerler kümesidir ve genellikle sayısal değerler halindedir. Ölçüler, küpteki önceden işlenmiş, derlenmiş ve çözümlenmiş merkezi değerlerdir. Yaygın örnekler arasında satış, kar, gelir ve maliyet sayılabilir.

Üye Bir hiyerarşide, bir veya daha çok veri yinelenmesini temsil eden öğedir. Bir üye benzersiz veya benzer olabilir. Örneğin, bir zaman boyutunun yıl düzeyinde 2007 ve 2008 benzersiz üyeleri temsil eder, ancak ay düzeyinde Ocak benzer üyeleri temsil eder çünkü birden fazla yılın verilerini içeriyorsa zaman boyutunda birden fazla Ocak bulunabilir.

Hesaplanan üye Değeri çalışma esnasında ifade kullanılarak hesaplanan boyut üyesidir. Hesaplanan üye değerleri diğer üyelerin değerlerinden türetilebilir. Örneğin, Kar hesaplanan üyesi, Maliyetler üyesinin değerini Satışlar üyesinin değerinden çıkararak belirlenebilir.

Boyut Bir küpte, kullanıcının anladığı ve veri çözümleme için temel olarak kullandığı düzenlenen bir veya daha fazla düzey hiyerarşileri grubudur. Örneğin bir coğrafya boyutu Ülke/Bölge, İl/İlçe ve Şehir için düzey içerebilir. Ya da bir zaman boyutu yıl, çeyrek, ay ve gün için hiyerarşi düzeyleri içerebilir. Özet Tablo raporu veya Özet Grafik raporunda, her hiyerarşi, daha düşük veya daha yüksek düzeyleri göstermek için genişletebileceğiniz ve daraltabileceğiniz alanlar kümesi haline gelir.

Hiyerarşi Boyutun üyelerini, her üyenin bir üst üyesi ve sıfır veya daha fazla alt üyesi olacak şekilde düzenleyen mantıksal ağaç yapısıdır. Alt öğe, geçerli üyeyle doğrudan ilgili bir hiyerarşide bir sonraki alt düzeyin bir üyesidir. Örneğin Çeyrek, Ay ve Gün düzeylerini içeren bir Zaman hiyerarşisinde Ocak Çyr1'in alt öğesidir. Üst öğe, geçerli üyeyle doğrudan ilgili bir hiyerarşide bir sonraki üst düzeyin bir üyesidir. Üst değer genellikle bütün alt öğelerin değerlerinin birleşimidir. Örneğin; Çeyrek, Ay ve Gün düzeylerini içeren bir Zaman hiyerarşisinde, Çyr1 Ocak'ın üst öğesidir.

Düzey Bir hiyerarşi içinde, veriler alt ve üst ayrıntı düzeyleri olarak düzenlenebilir. Örnek olarak Zaman hiyerarşisinde Yıl, Çeyrek, Ay ve Gün düzeyleri verilebilir.

OLAP VERİTABANININ ÖZELLİKLERİ

Çok boyutlu inceleme özelliğine sahip olması Şeffaflık Erişilebilirlik Her seviyede sorgulama için aynı performansı gösterebilme özelliği İstemci-Sunucu yapısında olması Sınırsız şekilde çapraz raporlama olanağının olması En alt seviyedeki verilerin otomatik olarak ayarlanması Her şarta uygun boyutlandırılabilir olması Çok kullanıcı desteğinin olması Her seviyede verilerin değiştirilebilir olması Esnek raporlama özelliği, Boyut ve gruplamalarda sınır olmaması şeklindedir

OLAP, yukarıdan aşağıya doğru bakmak isteyen, detaylarla uğraşmaktan yorulan yöneticiler ve analistlerin, verilere çok hızlı şekilde bakabilmelerini sağlayan bir veri kümesidir. “Kim?” ve “Ne Zaman?” sorularından başka, “Neden?” ve “Eğer şu olursa...” sorularının da yanıtını verir. (Ör : Eğer şeker fiyatları 5% lira ve taşıma maliyetleri 10% düşerse, yıllık, çeyrekler, aylık, haftalık ve günlük bazında kârlılık ne olur gibi. Hatta abartılırsa ve veritabanı buna müsaitse saat ve dakikaya dahi inilebilir.) Bu kırılımdaki raporların performansı hep aynıdır. Yani raporu yıllık sorgulama ile saatlik sorgulama arasında geçen süre aynıdır.

Akıllı raporlama araçları sayesinde, neden sorularının cevapları da kolaylıkla alınabilmektedir. Genel eğilimden farklılık gösteren, uç değerler yaratan elemanları birçok analiz aracı, sayısal detaylara girmeden, sadece renklerle bile görüntüleyebilmektedir.

OLAP’ı sadece büyük özet tablolar gibi yorumlamak doğru olmaz. Excel kullanıcıların tanıdıkları pivot tabloların, çok gelişmiş ve hızlı bir hali olarak düşünüle bilir. Tasarlanan bir OLAP yapısının, hiyerarşilerini ve boyutlarını görmek mümkün olsa da, verileri nasıl tuttuğunu, nasıl sorgulanacağını sadece mdx sayesinde görebiliriz. Fakat dışarıdan baktığımızda iç içe geçmiş küpler olarak yorumlayabiliriz. Bu nedenle OLAP yapılarına, “küp” adı verilmiştir.

Bir veri ambarınızın olması, OLAP’a ihtiyacınız olmadığı anlamına gelmez. Veri ambarları ve OLAP birbirlerinin tamamlarlar. Veri ambarı verileri barındırmaya yarar. OLAP ise, bu yığın halinde duran verileri anlamlı hale getirip analizler yapmaya yarar.

Örnek vermek gerekirse; pazarlama departmanlarında pazar araştırmalarında, satış tahminleri, promosyon ve kampanya analizleri, müşteri analizleri sonuçlarının değerlendirilmesi ve demografikler bazında incelenmesi seviyesinde de olmazsa-olmaz araçlardan biri olarak yer almaktadır. Üretim ile ilgili uygulamaları ise en yoğun olarak üretim planlama ve hata analizleridir. Farklı ürün tipleri ile çalışılan yapılarda, çok boyutlu düşünme imkanı sayesinde maliyetler ve fiyatlamalar, kolaylıkla çıkarılabilmektedir. Finans departmanları ise OLAP’ı bütçeleme, finansal performans analizleri ve finansal modelleme amaçları ile kullanabilir. Strateji belirleme, Satış analizleri ve gelecek tahminleri ise, satış departmanlarındaki OLAP uygulamadır.

  • «
  •  Başlangıç 
  •  Önceki 
  •  1 
  •  2 
  •  Sonraki 
  •  Son 
  • »
Sayfa 1 / 2
Powered by T3 Framework