Ücretsiz · Kayıt yok · .mmd dosyalarıyla çalışır

Mermaid ER diyagramı editörü

Varlık-ilişki diyagramı tabloları, sütunlarını ve birbirlerine nasıl bağlandıklarını gösterir. Asıl konu veritabanı şemasıysa ve ilginç sorular anahtarlar ile çokluklar hakkındaysa uygundur — bire çok, isteğe bağlı ya da ara tablo üzerinden. Davranışı ve kalıtımı olan tipler için sınıf diyagramı daha iyidir.

Bunu editörde aç →Kılavuzu okuyun

Ara tablolu normalleştirilmiş sipariş şeması

Dikkate değer yer sipariş kalemindeki `}o--||` işaretidir: çoktan çoğa ilişki, iki tablo doğrudan bağlanıyormuş gibi yapmak yerine kendi sütunları olan bir ara tablo üzerinden böyle dürüstçe anlatılır. Fiyatı yalnızca üründe değil kalemde de tutmak, diyagramın görünür kılması gereken türden bir karardır. Her ilişki etiketinin tırnak içinde olduğuna da dikkat edin — Türkçede bu isteğe bağlı değil.

erDiagram
    MÜŞTERİ ||--o{ SİPARİŞ : "sipariş verir"
    SİPARİŞ ||--|{ SİPARİŞ_KALEMİ : "içerir"
    ÜRÜN ||--o{ SİPARİŞ_KALEMİ : "içinde geçer"
    MÜŞTERİ ||--o{ ADRES : "şuraya gönderilir"
    SİPARİŞ ||--o| FATURA : "karşılığında kesilir"

    MÜŞTERİ {
        int id PK
        string eposta UK "küçük harfe çevrilerek saklanır"
        string ad_soyad
        datetime kayıt_tarihi
    }
    SİPARİŞ {
        int id PK
        int musteri_id FK
        string durum
        decimal tutar
    }
    SİPARİŞ_KALEMİ {
        int siparis_id PK, FK
        int urun_id PK, FK
        int adet
        decimal birim_fiyat "sipariş anındaki fiyat"
    }
    ÜRÜN {
        int id PK
        string stok_kodu UK
        string ad
    }
    ADRES {
        int id PK
        int musteri_id FK
        string posta_kodu
    }
    FATURA {
        int id PK
        string fatura_no UK
        decimal kdv_tutari
    }

Bunu editörde aç

Reklam

Çözümlü örnekler

1. İki varlık ve bir ilişki

Her ER ilişkisi iki noktadan sonra bir etiket ister — akış şeması kenarının aksine isteğe bağlı değildir. Cümle gibi okunur: MÜŞTERİ sipariş verir SİPARİŞ.

erDiagram
    MÜŞTERİ ||--o{ SİPARİŞ : "sipariş verir"

Editörde aç

2. Sütunları eklemek

Her nitelik satırı `tip ad` biçimindedir ve iki parça da zorunludur. `PK`, `FK` ve `UK` anahtarları gösterir; sondaki tırnaklı metin sütuna düşülen nottur.

erDiagram
    MÜŞTERİ ||--o{ SİPARİŞ : "sipariş verir"
    MÜŞTERİ {
        int id PK
        string eposta UK
        string ad_soyad
    }
    SİPARİŞ {
        int id PK
        int musteri_id FK
        datetime verildi "UTC olarak"
    }

Editörde aç

3. Bir şey söyleyen çokluk

Her varlığa en yakın iki işaret o varlığın çokluğudur. Bu örnek, bir siparişin en az bir kalemi olması gerektiğini ama bir müşterinin hiç siparişi olmayabileceğini söyler: şemanın zorlaması, diyagramın da göstermesi gereken gerçek bir kısıt.

erDiagram
    MÜŞTERİ ||--o{ SİPARİŞ : "sipariş verir"
    SİPARİŞ ||--|{ SİPARİŞ_KALEMİ : "içerir"
    SİPARİŞ_KALEMİ }o--|| ÜRÜN : "şuna atıfta bulunur"

Editörde aç

4. Ara tablo üzerinden çoktan çoğa

Mermaid doğrudan çoktan çoğa ilişki çizebilir, ama şemada bu neredeyse hiç yoktur: altta bir ara tablo yatar. Onu çizmek daha dürüsttür ve ilişkinin kendisine ait sütunlara yer açar.

erDiagram
    ÖĞRENCİ ||--o{ KAYIT : "şuna kaydolur"
    DERS ||--o{ KAYIT : "üzerinden yürütülür"
    KAYIT {
        int ogrenci_id PK, FK
        int ders_id PK, FK
        datetime kayit_tarihi
        string harf_notu "geçene kadar boş"
    }
    ÖĞRENCİ {
        int id PK
        string ad_soyad
    }
    DERS {
        int id PK
        string kod UK
    }

Editörde aç

5. Kendine dönen ilişkiler

Bir tablo kendisiyle ilişkilenebilir: yönetim zinciri, kategori ağacı, yorum dizisi. Etiketin önemi burada her zamankinden büyüktür, çünkü ilişkinin iki ucu da aynı varlıktır.

erDiagram
    ÇALIŞAN ||--o{ ÇALIŞAN : "yönetir"
    ÇALIŞAN {
        int id PK
        int yonetici_id FK "üst yönetim için boş"
        string ad_soyad
        string unvan
    }

Editörde aç

ER diyagramı sözdizimi özeti

Çokluk, ilişkinin her ucunda iki işaretle yazılır ve içeriden dışarıya okunur. Soldaki çift soldaki varlığı, sağdaki çift sağdakini anlatır.

Sözdizimi	Anlamı
erDiagram	Diyagramı açar. Büyük-küçük harfe duyarlı ve noktalı i ile: `erdiagram` da `erDıagram` da çalışmaz.
A \|\|--o{ B : "etiket"	İlişki. Etiket zorunludur.
\|\|	Tam olarak bir.
o\|	Sıfır ya da bir.
}\|	Bir ya da daha çok.
}o	Sıfır ya da daha çok.
--	Tanımlayan ilişki — düz çizgi.
..	Tanımlamayan ilişki — kesik çizgi.
A { ... }	A varlığının nitelik bloğu.
int id PK	Nitelik: önce tip, sonra ad, sonra isteğe bağlı anahtar işareti.
PK / FK / UK	Birincil, yabancı, benzersiz anahtar.
int id PK, FK	Virgülle ayrılmış birden çok anahtar işareti.
string eposta "not"	Sondaki tırnaklı metin sütuna düşülen nottur.
A \|\|--o{ B : "şuna aittir"	Etikette bir boşluk varsa tırnak ZORUNLUDUR. Tırnaksız etiket ilk boşlukta kesilir ve kalan her sözcük hayalet bir varlığa dönüşür.

Reklam

ER diyagramını bozan altı hata

ER, altı tip içinde dilbilgisi en katı olanıdır: başka diyagramlarda geçen şeyler burada doğrudan geri çevrilir. Ama Türkçe yazarken özellikle kolay düşülen sessiz bir hatası da vardır. Hepsi Mermaid 11.12.2 üzerinde yeniden üretildi.

Ne görüyorsunuz

Çizilir, etiket kesiktir ve diyagramda yazmadığınız varlıklar belirir

Neden

İlişki etiketinde boşluk var ve tırnak yok. Türkçede en çok engel çıkaracak hata budur, çünkü ilişki ifadelerimiz neredeyse her zaman çok sözcüklüdür: «sipariş verir», «şuna aittir», «içinde geçer». Ölçüldü: `MÜŞTERİ ||--o{ SİPARİŞ : sipariş verir` hiçbir hata vermez, etiketi «sipariş»e kısaltır ve «verir» adında boş bir varlık oluşturur. Üç sözcükte iki hayalet varlık doğar. İki tablo dört kutu olarak çizilir ve hiçbir şey bunu haber vermez — viewBox'ın 128'den 368 piksele çıkması dışında.

Çözüm

Boşluk içeren her etiketi tırnağa alın. Türkçede bu pratikte her etiket demektir; her seferinde karar vermek yerine kural edinmek daha kolaydır.

Hatalı

erDiagram
    MÜŞTERİ ||--o{ SİPARİŞ : sipariş verir

Doğru

erDiagram
    MÜŞTERİ ||--o{ SİPARİŞ : "sipariş verir"

Ne görüyorsunuz

Parse error, sonu: Expecting 'COLON', 'STYLE_SEPARATOR', got 'NEWLINE'

Neden

Etiketsiz ilişki. Akış şeması kenarının aksine iki nokta ve etiket zorunludur: onlarsız satır olması gerekenden erken biter.

Çözüm

İki nokta ve bir yüklem ekleyin; boşluk içeriyorsa tırnak içinde.

Hatalı

erDiagram
    MÜŞTERİ ||--o{ SİPARİŞ

Doğru

erDiagram
    MÜŞTERİ ||--o{ SİPARİŞ : "sipariş verir"

Ne görüyorsunuz

Parse error, sonu: got 'UNICODE_TEXT'

Neden

Geçersiz çokluk belirteci. Yalnızca `||`, `o|`, `}|` ve `}o` (ve aynalanmış biçimleri) geçerlidir; başka her şey devrilir. `oo`, gösterimin bakışımlı olduğu varsayımından doğan tipik bir yazım hatasıdır.

Çözüm

Dört çiftten birini kullanın. `||--o{` — tam olarak bir, sıfır ya da daha çoğa — yabancı anahtarların çoğunu karşılar.

Hatalı

erDiagram
    MÜŞTERİ ||--oo{ SİPARİŞ : "sipariş verir"

Doğru

erDiagram
    MÜŞTERİ ||--o{ SİPARİŞ : "sipariş verir"

Ne görüyorsunuz

Parse error, sonu: Expecting 'ATTRIBUTE_WORD', got 'BLOCK_STOP'

Neden

Niteliğin adı var ama tipi yok. ER nitelikleri `tip ad` biçiminde yazılır ve tip isteğe bağlı değildir — şemasız veritabanlarından gelenleri bu şaşırtır.

Çözüm

Her niteliğe bir tip verin. Gerçek şemada yoksa uydurun: `string`, `int`, `json`.

Hatalı

erDiagram
    MÜŞTERİ {
        eposta
    }

Doğru

erDiagram
    MÜŞTERİ {
        string eposta
    }

Ne görüyorsunuz

Parse error, sonu: Expecting 'NON_IDENTIFYING', 'IDENTIFYING', got 'UNICODE_TEXT'

Neden

İki çokluk işareti arasındaki çizgi yanlış. Tam olarak iki karakter olmalıdır: tanımlayan ilişki için `--`, tanımlamayan için `..`. Tek tire, `--` işaretinin kısaltması değil bir sözdizimi hatasıdır.

Çözüm

Çokluk çiftleri arasına `--` ya da `..` yazın.

Hatalı

erDiagram
    MÜŞTERİ ||-o{ SİPARİŞ : "sipariş verir"

Doğru

erDiagram
    MÜŞTERİ ||--o{ SİPARİŞ : "sipariş verir"

Ne görüyorsunuz

Çokluk çizilir, ama tersi olan kısıtı anlatır

Neden

Her varlığa en yakın iki işaret o varlığa aittir ve bunu ters okumak çok kolaydır. `MÜŞTERİ ||--o{ SİPARİŞ` bir müşterinin sıfır ya da daha çok siparişi olduğunu söyler. Bunu `MÜŞTERİ }o--|| SİPARİŞ` diye çevirirseniz her müşterinin tam olarak bir siparişe ait olduğunu iddia etmiş olursunuz; bunun anlamı yoktur ve en ufak bir itiraz olmadan çizilir.

Çözüm

İçeriden dışarıya okuyun: MÜŞTERİ'ye değen işaretler kaç müşteri olduğunu anlatır, kaç sipariş olduğunu değil.

Hatalı

erDiagram
    MÜŞTERİ }o--|| SİPARİŞ : "sipariş verir"

Doğru

erDiagram
    MÜŞTERİ ||--o{ SİPARİŞ : "sipariş verir"

Çizim üzerine notlar

Bu sitenin kullandığı Mermaid 11.12.2 üzerinde ölçüldü.

Yerleşimi varlık sayısı değil ilişkiler belirler

Birbirine zincir gibi bağlanmış varlıklar yüksek bir sütun olarak çizilir: kırk varlık yaklaşık 116×7315 viewBox verir, üç varlıkta bu 116×470'tir. Ama aynı kırk varlık tek bir merkezî tabloya bağlandığında çok daha geniş ve alçak bir şey çıkar. Buradaki altı tip içinde verinizin biçiminin resmin biçimini boyutundan daha çok değiştirdiği tek tip budur; bu yüzden sığmayan bir şema, çoğu kez ilişkilerin sayısını değil hangilerini çizdiğinizi değiştirerek düzelir.

Türkçede neredeyse her etiket tırnak ister

Bunu yinelemeye değer, çünkü bu sayfadaki en pahalı sessiz hata budur. İngilizce ilişki etiketleri tek sözcük olabilir — places, contains, references — bu yüzden İngilizce belgelerde tırnaklar süs gibi görünür. Türkçede ise etiketlerin çoğu «sipariş verir», «şuna aittir» gibi çok sözcüklüdür ve tırnaksız dağılırlar. Pratik kural: etiketi her zaman tırnağa alın ve bunu düşünmeyi bırakın.

Varlık adları büyük-küçük harfe duyarlı, Türkçe harfler serbest

`MÜŞTERİ` ile `müşteri` iki ayrı varlıktır ve ikisini bir diyagramda anmak uyarısız biçimde iki kutu verir. Büyük harf geleneğini Mermaid dayatmaz, ama tam da kazara yapılan küçük harfli atfı görünür kıldığı için ona uymakta yarar vardır. Türkçe harfler varlık ve sütun adlarında sorunsuz çalışır — sınandı: `MÜŞTERİ`, `SİPARİŞ_KALEMİ` ve `ÖĞRENCİ` beklendiği gibi çizilir. Yine de şemanın Türkçe harf taşıyıp taşımayacağına baştan karar verip ona sadık kalmak akıllıcadır; yarısı `SİPARİŞ` yarısı `SIPARIS` olan bir şema sessizce ikiye katlanır.

Dilbilgisi altı tip içinde en katısı

İlişki etiketleri zorunludur, nitelik tipleri de öyle, çokluk belirteçleri ise kapalı bir küme oluşturur. Hemen her şeyin çizildiği ve hataların sustuğu Gantt ile karşılaştırıldığında ER erken ve yüksek sesle devrilir. Bu bir üstünlüktür: bir ER diyagramı çizildiyse, muhtemelen kastettiğiniz diyagramdır — tırnaksız etiketler bunun açık istisnasıdır.

Etiketler HTML olduğu için PNG dışa aktarımı yeniden çizer

Varlıkların nitelik tabloları SVG içindeki `<foreignObject>` içinde çizilir, bu yüzden tarayıcılar bunları doğrudan canvas üzerine rasterleyemez. Bu sitenin PNG dışa aktarımı önceden sessizce SVG dosyası veriyordu; artık diyagramı önce düz SVG metin etiketleriyle yeniden çiziyor ve tam boyutta doğru bir PNG üretiyor, dizgisi ancak fark edilir ölçüde farklı.

Başka bir diyagramın daha uygun olduğu durumlar

Kalıtıma, arayüzlere ya da metotlara ihtiyacınız varsa bu yanlış diyagramdır: ER'de bu kavramların hiçbiri yoktur. Sınıf diyagramı kullanın ve onun tablolarınızı değil kodunuzu modellediğini kabul edin.

Şema büyükse, tamamının ER diyagramı kimsenin okumadığı bir duvar posterine dönüşür. Tam o an anlattığınız şeye değen beş tabloyu çizin, gerisini kadraj dışında bırakın; diyagram bir envanter değil bir savdır.

Ve asıl soru verinin nasıl saklandığı değil sistemler arasında nasıl aktığıysa, buna sistem başına bir alt grubu olan bir akış şeması cevap verir, ER diyagramı vermez.

Diğer diyagram türleri

Yazan Dominik Malsch · Son güncelleme: 8 Eylül 2026

Editörü aç →