Coding Interview Prep · Ders

Yıldız Şema ve Veri Ambarı Tasarımı

Gerçek ve boyut tabloları, normalleştirmeden vazgeçmenin ödünleşimleri ve OLAP modellemesi.

Yıldız Şema ve Veri Ambarı Tasarımı, CoddyKit'te ücretsiz bir Coding Interview Prep dersidir. Bu, 4 dersinin 3. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, Coding Interview Prep öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. Coding Interview Prep kursu toplamda 4 dersten oluşur.

OLTP ve OLAP

Veri ambarı soruları, mülakatçıların doğru biçimde ayırt etmenizi beklediği temel bir ayrımla başlar: OLTP ve OLAP.

OLTP (işlemsel): bütünlük için büyük ölçüde normalleştirilmiş çok sayıda küçük okuma/yazma işlemi. Uygulamayı çalıştırır.
OLAP (analitik): geçmiş veriler üzerinde az sayıda, büyük toplulaştırmalı okuma işlemi; hız için bilinçli olarak normalleştirilmemiştir. Raporlamayı ve gösterge panolarını çalıştırır.

Yıldız şemaları bir OLAP tasarımıdır. Temel amaç, karşılığında bazı yinelemeleri kabul ederek hızlı analitik sorgular elde etmektir.

Gerçekler ve Boyutlar

Yıldız şeması verileri iki tür tabloya ayırır:

Gerçek tablosu: ölçülebilen olayları veya işlemleri (satış, tıklama) içerir. Sayısal ölçüleri ve boyutlara ait yabancı anahtarları tutar.
Boyut tabloları: verileri hangi açıklayıcı bağlama göre dilimlediğinizi belirtir (tarih, ürün, müşteri, mağaza).

Gerçek tablosu merkezde yer alır; boyutlar onu bir yıldızın uçları gibi çevreler. Adı buradan gelir.

Gerçek Tablosunun Yapısı

Gerçek tablosu çoğunlukla yabancı anahtarlardan ve sayısal ölçülerden oluşur. Uzun ve dardır; sürekli büyür.

Ölçüler, toplulaştırdığınız toplanabilir sayılardır: miktar, gelir, maliyet. Ayrıntı düzeyi (bir satır = bir ?) açıkça belirtilmelidir; burada bir satır, tek bir satıştaki tek bir ürün satırını temsil eder.

CREATE TABLE fact_sales (
  sale_id      BIGINT PRIMARY KEY,
  date_key     INT  NOT NULL,   -- FK to dim_date
  product_key  INT  NOT NULL,   -- FK to dim_product
  customer_key INT  NOT NULL,   -- FK to dim_customer
  store_key    INT  NOT NULL,   -- FK to dim_store
  quantity     INT,             -- measure
  revenue      DECIMAL(12,2),   -- measure
  cost         DECIMAL(12,2)    -- measure
);

Boyut Tablosunun Yapısı

Boyutlar kısa ve geniştir: filtreleme ve gruplama için kullandığınız çok sayıda açıklayıcı sütun içerir. Bir sorgunun boyut başına yalnızca bir birleştirmeye ihtiyaç duyması için bilinçli olarak normalleştirilmemişlerdir.

dim_product tablosunun kategori ve markayı ayrı tablolarda değil, aynı satırda tuttuğuna dikkat edin. Bu yineleme kasıtlıdır: sorgu sırasında ek birleştirmeleri önler.

CREATE TABLE dim_product (
  product_key  INT PRIMARY KEY,   -- surrogate key
  product_id   INT,              -- natural/business key
  product_name VARCHAR(100),
  category     VARCHAR(50),      -- denormalized
  brand        VARCHAR(50),      -- denormalized
  unit_price   DECIMAL(10,2)
);

Bir Yıldız Şeması Sorgusu

Tasarımın size sağladığı avantaj budur. Tipik bir analitik sorgu, gerçek tablosunu birkaç boyutla birleştirir, filtreleme yapar ve toplulaştırır. Her boyut için bir birleştirme yapılır; derin zincirler yoktur.

Mülakatçılar sizden bir yıldız şemasına karşı tam olarak bu tür bir sorgu yazmanızı ister.

SELECT d.category,
       t.year,
       SUM(f.revenue) AS total_revenue
FROM fact_sales f
JOIN dim_product d ON d.product_key = f.product_key
JOIN dim_date    t ON t.date_key    = f.date_key
WHERE t.year = 2025
GROUP BY d.category, t.year
ORDER BY total_revenue DESC;

Vekil Anahtarlar

Boyutlar bir vekil anahtar kullanır: veri ambarı tarafından oluşturulan, anlamsız bir tamsayı birincil anahtarıdır (örneğin product_key); kaynak sistemin doğal anahtarından ayrıdır.

Mülakatçıların bunu önemsemesinin nedenleri:

Veri ambarını değişen iş anahtarlarından bağımsızlaştırır.
Gerçek tablolarını dar tutar (tamsayılarla yapılan birleştirmeler hızlıdır).
Yavaş değişen boyutlarla geçmişi izlemek için gereklidir (sonraki sahnede).

Yavaş Değişen Boyutlar

Veri ambarı mülakatlarında sık sorulan bir konu şudur: Bir boyut özniteliği değiştiğinde (örneğin bir müşteri şehir değiştirdiğinde) bunu nasıl ele alırsınız? Bunlara yavaş değişen boyutlar (SCD) denir:

Tür 1: eski değerin üzerine yazılır. Geçmiş tutulmaz.
Tür 2: geçerlilik tarihleri ve güncel kayıt göstergesiyle yeni bir satır eklenir. Geçmişin tamamı tutulur; bunun için vekil anahtarlar gerekir.
Tür 3: bir "önceki değer" sütunu tutulur. Geçmiş sınırlıdır.

Zaman içindeki değişimi izlemek için en sık beklenen yanıt Tür 2'dir.

-- SCD Type 2 dimension
CREATE TABLE dim_customer (
  customer_key INT PRIMARY KEY,   -- surrogate
  customer_id  INT,              -- natural key
  city         VARCHAR(50),
  valid_from   DATE,
  valid_to     DATE,
  is_current   BOOLEAN
);

Yıldız ve Kar Tanesi

Bu karşılaştırma sorusunu bekleyin. Kar tanesi şeması, boyutları alt tablolara normalleştirir (ürün -> kategori -> departman); yıldız şeması ise boyutları düz tutar.

Yıldız: daha az birleştirme, daha hızlı okumalar ve bir miktar yineleme. Sorgu performansı için tercih edilir.
Kar tanesi: daha az depolama alanı ve daha kolay boyut bakımı sağlar; ancak sorgu başına daha fazla birleştirme gerektirir.

Şöyle söyleyin: "Sorgu hızını artırmak için varsayılan olarak yıldızı tercih edin; boyutlar büyük ve yeniden kullanılıyorsa yalnızca kar tanesini kullanın."

Tarih Boyutu

Neredeyse her yıldız şemasında ham bir tarih sütunu yerine özel bir tarih boyutu bulunur. Bu boyut yıl, çeyrek, ay, haftanın günü, tatil göstergeleri ve mali dönemleri önceden hesaplar.

Bu sayede analistler, dağınık tarih işlevleri kullanmak yerine basit bir birleştirmeyle "mali çeyrek" veya "hafta_sonu_mu" değerlerine göre gruplama yapabilir. İstenmeden bir tarih boyutundan söz etmeniz, veri ambarları oluşturduğunuzu gösteren güçlü bir işarettir.

CREATE TABLE dim_date (
  date_key   INT PRIMARY KEY,   -- e.g. 20250131
  full_date  DATE,
  year       INT,
  quarter    INT,
  month      INT,
  day_of_week VARCHAR(10),
  is_weekend BOOLEAN,
  fiscal_qtr VARCHAR(6)
);

Ayrıntı Düzeyini Seçmek

Gerçek tablosuyla ilgili en önemli karar ayrıntı düzeyidir: tek bir satır neyi temsil eder? Her şeyden önce bunu belirleyin.

Çok kaba olursa (mağaza başına gün başına bir satır) ayrıntıları kaybedersiniz.
Çok ince olursa (okutulan ürün başına bir satır) tablo aşırı büyür.

"Sipariş satırı başına, ürün başına bir satır" gibi açık bir ayrıntı düzeyi ifadesi, hangi boyutların ve ölçülerin dahil olması gerektiğini belirler. Mülakatçılar bu disiplini gösterip göstermediğinizi dinler.

Normalleştirmeyi Ne Zaman Bırakmalı

Bunu normalleştirmeyle ilişkilendirin. OLTP sistemleri bütünlük için 3NF'ye normalleştirilir; veri ambarları ise okuma hızını artırmak için boyutları bilinçli olarak normalleştirmez.

Açıklamanız gereken ödün şudur:

Yedekli boyut verileri kabul edilebilir; çünkü veri ambarı, gelişigüzel uygulama yazma işlemleriyle değil, kontrollü ETL ile yüklenir.
Daha az birleştirme, milyarlarca gerçek satırı kapsayan toplulaştırmaları hızlandırır.

Burada önemli olan kuralı bilmeniz değil, doğru değerlendirmeyi yapmanızdır; kıdemli yanıtları diğerlerinden ayıran da budur.

Hızlı Kontrol

Bir satış veri ambarı tasarlıyorsunuz ve bir müşteri taşındığında şehir geçmişinin tamamını korumanız gerekiyor.

Özet: Yıldız Şeması ve Veri Ambarı Tasarımı

Artık veri ambarı modelleme sorularını ele alabilirsiniz:

OLTP bütünlük için normalleştirir; OLAP okuma hızını artırmak için normalleştirmez.
Yıldız şemasında, düz boyutlarla çevrelenmiş merkezi bir gerçek tablosu (yabancı anahtarlar ve sayısal ölçüler) bulunur.
Vekil anahtarlar ve özel bir tarih boyutu kullanın.
Değişiklikleri SCD Tür 2 ile izleyin; gerçek tablosunun ayrıntı düzeyini önce belirleyin.
Sorgu performansı için kar tanesi yerine yıldızı tercih edin.

Sıkça Sorulan Sorular

“Yıldız Şema ve Veri Ambarı Tasarımı” dersi ücretsiz mi?

Evet — “Yıldız Şema ve Veri Ambarı Tasarımı” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve Coding Interview Prep kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. Coding Interview Prep kursu toplamda 4 dersten oluşur.

“Yıldız Şema ve Veri Ambarı Tasarımı” dersinde ne öğreneceğim?

Gerçek ve boyut tabloları, normalleştirmeden vazgeçmenin ödünleşimleri ve OLAP modellemesi. Coding Interview Prep ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.

Coding Interview Prep öğrenmeye başlamak için deneyim gerekli mi?

Önceden deneyim gerekmez. CoddyKit'te Coding Interview Prep, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 3. dersidir.

“Yıldız Şema ve Veri Ambarı Tasarımı” dersi ne kadar sürer?

Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.

Bu Coding Interview Prep dersinde kod yazıp çalıştırabilir miyim?

Evet. Her Coding Interview Prep dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.

Bu kursun tüm dersleri

← Coding Interview Prep Sayfasına Dön