> For the complete documentation index, see [llms.txt](https://learn.vispeahen.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://learn.vispeahen.com/veri-yonetimi/veri-modelleme/star-schema/star-schema-modeli-kurarken-dikkat-edilmesi-gerekenler.md).

# Star Schema Modeli Kurarken Dikkat Edilmesi Gerekenler

Vispeahen'de bir Star Schema modeli kurarken aşağıdaki noktalara dikkat etmek, modelin doğru çalışmasını, performanslı olmasını ve zaman içinde sürdürülebilir kalmasını sağlar.

### 1. İsimlendirme Standardı

Fact ve Dimension tabloları birbirinden ayırt etmek için tutarlı bir önek kullanın: Fact tablolar için “fact\_”, Dimension tablolar için “Dim” öneki (örn. DimTarih, DimUrunKategori, DimBolge, DimMusteri). Model büyüdükçe bu standart, hangi tablonun fact hangi tablonun dimension olduğunu hızlıca ayırt etmeyi sağlar ve ekip içinde ortak bir dil oluşturur.

### 2. Join Kolonlarının Veri Tipi ve Format Uyumu

Fact ve Dimension tablolardaki join kolonlarının veri tipleri (metin-metin, sayı-sayı) ve değer formatları (büyük/küçük harf, boşluk, kod biçimi) birbiriyle uyumlu olmalıdır. Örneğin “city\_code” ile “plaka” kolonlarının aynı kod setini kullanması gerekir. Uyumsuzluk, join'in hiç eşleşmemesine veya raporlarda eksik veri görünmesine yol açar.

### 3. Join Tipi Seçimi: Inner ve Left

Inner join sadece her iki tarafta karşılığı olan kayıtları getirir. Dimension tabloda karşılığı olmayan Fact kayıtları varsa (örneğin henüz tanımlanmamış bir ürün kategorisi), bu kayıtlar Inner join ile dashboard'dan tamamen kaybolur. Fact tablosundaki tüm kayıtların korunması gerekiyorsa Left join tercih edilmeli; Dimension tarafında eşleşmeyen değerler için “Tanımsız” gibi bir varsayılan satır eklemek iyi bir pratiktir.

### 4. DimTarih (Date) Tablosunun Önemi

Zaman bazlı analizler (yıl, ay, çeyrek, hafta, haftanın günü) için ayrı bir DimTarih tablosu oluşturup tüm Fact tablolardaki tarih kolonlarını bu ortak tabloya bağlayın. Bu yaklaşım tutarlı bir tarih hiyerarşisi sağlar ve farklı Fact tablolar arasında tarih bazlı karşılaştırmalı analizleri mümkün kılar.

### 5. Çoka-Bir (Many-to-One) İlişkiyi Koruma

Fact-Dimension join'leri her zaman “many-to-one” (çoka-bir) olmalıdır: bir Fact satırı yalnızca bir Dimension satırına eşleşmelidir. Dimension tablosunda tekrar eden anahtar değerleri varsa join sonucunda satır çoğalması (row duplication) oluşur ve toplamlar (SUM, COUNT) yanlış hesaplanır. Dimension tablosunun anahtar kolonunun benzersiz (unique) olduğundan emin olun.

### 6. Gereksiz Join'lerden Kaçınma ve Performans

Sadece dashboard ve raporlarda gerçekten kullanılacak Dimension tabloları join edin; kullanılmayan join'ler modeli karmaşıklaştırır ve sorgu performansını düşürür. Sık kullanılan join ve filtre kolonlarında, özellikle Fact tablosundaki foreign key kolonlarında indeks tanımlamak performansı önemli ölçüde artırır.

### 7. Kurulumdan Sonra Test ve Doğrulama

Model kurulduktan sonra basit bir dashboard veya rapor ile join sonuçlarını kontrol edin: toplam satır sayısı join öncesi ve sonrasında aynı mı? Beklenen toplamlar (SUM) değişmiyor mu? Bu kontroller, satır çoğalması (row duplication) veya veri kaybı gibi sorunları erken aşamada yakalamanızı sağlar.

{% hint style="warning" %} <mark style="color:$warning;">**Hızlı Kontrol Listesi:**</mark>&#x20;

* Tablo isimleri Fact\_/Dim ön ekiyle tutarlı mı?&#x20;
* Join kolonlarının veri tipi ve formatı eşleşiyor mu?&#x20;
* Join tipi (Inner/Left) doğru seçildi mi?&#x20;
* DimTarih tüm Fact tablolara bağlı mı?&#x20;
* Dimension anahtar kolonu benzersiz mi?
* &#x20;Gereksiz join yok mu ve foreign key'lerde indeks var mı?
  {% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://learn.vispeahen.com/veri-yonetimi/veri-modelleme/star-schema/star-schema-modeli-kurarken-dikkat-edilmesi-gerekenler.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.