ERD Tasarımcısı

Bir veritabanı sunucusu olmadan ilişkisel bir şema tasarlayın: tablo ekleyin, bunlara türleri, anahtarları ve varsayılanları olan sütunlar verin, sonra ilişkilerle bağlayın. Varlık-ilişki diyagramı yazdıkça yeniden çizilir ve aynı model MySQL, PostgreSQL, SQL Server, SQLite veya Oracle için CREATE TABLE DDL'i, Mermaid erDiagram kaynağı ya da burada yeniden içe aktarabileceğiniz ya da Geçiş Oluşturucu'da açabileceğiniz taşınabilir şema JSON'u olarak dışa aktarılır. Her şey yerel çalışır.
ERD nedir? ERD, varlık-ilişki diyagramının kısaltmasıdır ve bitmiş bir veritabanının kaydı değil, bir veritabanının tasarım çizimidir. Yararlı bir karşılaştırma bir bina planıdır: çalışan veritabanı binadır, ERD plandır ve kimse önce beton döküp sonra ölçmez. Bu sayfa o plan için çizim masasıdır — modeli burada şekillendirirsiniz ve DDL, Mermaid kaynağı ve şema JSON'u hepsi o tek modelden basılır; böylece resim, ürettiği SQL'den sapamaz.
Aynı diyagram üç düzeyde. Kavramsal bir ERD yalnızca önemli şeyleri ve nasıl ilişkili olduklarını, programcı olmayanın kontrol edebileceği sözcüklerle adlandırır. Mantıksal bir ERD her şeyi tanımlayan anahtarları ekler ve çoktan çoğa bağlantıları çözer; yine de hiçbir motorun lehçesine bağlanmaz. Fiziksel bir ERD, belirli bir ürünün istediklerini doldurur — tür genişlikleri, varsayılanlar, boş bırakılabilirlik, benzersiz kısıtlar, silme kuralları — ve MySQL, PostgreSQL, SQL Server, SQLite veya Oracle seçtiğinizde buradan dışa aktardığınız düzeydir.
Kutular nereden gelir. Sistemin bir açıklamasını okuyun ve isimleri altı çizin: müşteri, fatura, ürün, sevkiyat. Bunlar tablolardır. Bir isme bağlı olgular ve nitelikler — bir fatura tarihi, bir birim fiyat, bir e-posta adresi — onun sütunlarıdır. “Bir sipariş bir müşteri tarafından verilir” gibi iki ismi birbirine bağlayan bir fiil bir ilişkidir ve üst satırın tanımlayıcı anahtarını alt satıra yabancı anahtar olarak kopyalayarak saklanır.
Bir bağlantı çoktan çoğa olduğunda. Bir tarif birçok malzeme kullanır ve bir malzeme birçok tarifte yer alır; bu yüzden hiçbir tablo diğerinin anahtarını kendini tekrarlamadan tutamaz. Cevap, tek işi onları eşleştirmek olan üçüncü bir varlıktır — birleşim (ya da ilişkisel) tablosu; her taraf için bir yabancı anahtar tutar ve çoğu zaman bu anahtar çiftini kendi birincil anahtarı yapar. Çoğunlukla bu tür eşleştirme tablolarından oluşan bir model tamamen normaldir: bir beyaz tahtadaki çoktan çoğa çizgi, gerçek şemada her zaman bir kutuya dönüşmek zorundadır.
DDL var olmadan önce neden uğraşmalı. Bir çizimdeki yanlış bir çizgiyi silmek bir dakika alır; yayından sonra bulunan aynı hata canlı veri üzerinde bir geçiş maliyetidir. Bir diyagram aynı zamanda geliştirici olmayanların inceleyebildiği tek eserdir ve ilişki hataları — ters yönlü bir kardinalite, eksik bir benzersiz anahtar, üst satırsız bırakılabilen alt satırlar — burada açıkça kötü çizgiler olarak görünür; 400 satırlık bir DDL dosyasında ise kısıtların arasında gizlenirler.
İleri mi geri mi? Bu tasarımcı ileri gider: önce model, sonra DDL çıkar. Kardeş SQL'den ERD'ye sayfası ters yönde gider — mevcut CREATE TABLE deyimlerini yapıştırırsınız ve diyagramı yeniden kurar; veritabanı zaten varsa daha hızlı yoldur.
1 — Tablolar
Düzenle Tablo adı Sütunlar İlişkiler Actions
2 — Sütunlar
Sütun Tür PK AI NN UQ Varsayılan Actions
PK = birincil anahtar, AI = otomatik artış / kimlik, NN = null değil, UQ = benzersiz
3 — İlişkiler (yabancı anahtarlar)
Alt tablo Alt sütun Actions Üst tablo Üst sütun Silince Actions
Bir yabancı anahtar, DDL'de bir CONSTRAINT ... FOREIGN KEY satırına dönüşür.
4 — Dışa aktarma
Mermaid erDiagram kaynağı
JSON modeli veritabanı araç ailesinin değişim biçimidir: bir önce/sonra şeması olarak Geçiş Oluşturucu'ya yapıştırın ya da daha sonra düzenlemeye devam etmek için buraya yeniden içe aktarın.