Datenbank-Designer

Was macht Datenbank-Designer?

Entwerfen Sie vollständige, produktionsreife Datenbankschemata basierend auf Benutzeranforderungen. Generieren Sie umfassende Dokumentation, SQL-Skripte und visuelle ER-Diagramm-Dateien, die mit DrawDB kompatibel sind.

Kern-Design-Prinzipien

Lesen Sie vor jedem Design immer references/design-principles.md, um Folgendes zu verstehen:

• Keine physischen Fremdschlüssel (nur logische Beziehungen)
• realistische Feldgrößen basierend auf der tatsächlichen Nutzung
• Minimales, strategisches Index-Design
• Pflichtkommentare zu allen Tabellen und Feldern
• Standard-Systemfelder (id, Zeitstempel, Soft-Delete)
• snake_case-Namenskonventionen

Arbeitsablauf

Schritt 1: Anforderungen verstehen

Sammeln Sie Informationen über das Datenbank-Design:

1. Datenbanktyp: MySQL 8.0 (Standard), PostgreSQL, SQL Server, etc.
2. Geschäftsdomäne: E-Commerce, Blog, CRM, ERP, etc.
3. Kernentitäten: Welche Haupttabellen werden benötigt?
4. Schlüsselfunktionen: Welche Funktionalität soll die Datenbank unterstützen?
5. Besondere Anforderungen: Gibt es spezifische Einschränkungen oder Vorlieben?

Wenn der Benutzer nur minimale Informationen bereitstellt, leiten Sie fehlende Details intelligent auf Basis gängiger Geschäftsszenarien und bewährter Praktiken ab, die in references/design-examples.md dokumentiert sind.

Wichtige Inferenz-Szenarien:

• Benutzer sagt „Entwirf eine Benutzertabelle“ → Inferieren: Benutzername, Passwort, E-Mail, Telefon, Status
• Benutzer sagt „E-Commerce-System“ → Inferieren: Benutzer-, Produkt-, Bestell-, Bestelldetail-Tabellen
• Benutzer sagt „Blog-System“ → Inferieren: Benutzer-, Artikel-, Kommentar-, Tag-, article_tag-Tabellen

Schritt 2: Referenzdokumentation laden

Laden Sie basierend auf den Designanforderungen die entsprechenden Referenzen:

• Immer laden: references/design-principles.md für die Kern-Design-Regeln
• Für die Formatgenerierung: references/drawdb-formats.md für JSON/DBML-Spezifikationen
• Für Beispiele: references/design-examples.md für ähnliche Systemdesigns

Schritt 3: Datenbankschema entwerfen

Erstellen Sie vollständige Tabellenstrukturen nach den folgenden Richtlinien:

Tabellen-Design-Checkliste

Für jede Tabelle:

• ✅ Standard-Systemfelder hinzufügen (sofern vom Benutzer nicht anders angegeben):

  • id BIGINT AUTO_INCREMENT PRIMARY KEY
  • created_at DATETIME DEFAULT CURRENT_TIMESTAMP
  • updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
  • is_deleted TINYINT(1) DEFAULT 0

• ✅ Geschäftsfelder mit realistischen Größen entwerfen:

  • username: VARCHAR(50)
  • email: VARCHAR(100)
  • phone: VARCHAR(20)
  • title: VARCHAR(200)
  • description: TEXT
  • Siehe references/design-principles.md für vollständige Größenstandards

• ✅ Geeignete Constraints hinzufügen:

  • NOT NULL für Pflichtfelder
  • DEFAULT-Werte für optionale Felder
  • UNIQUE für Felder, die Eindeutigkeit erfordern (aber nicht als Fremdschlüssel)

• ✅ COMMENT zu jeder Tabelle und jedem Feld hinzufügen (in Chinesisch)

• ✅ Keine physischen FOREIGN KEY-Constraints erstellen

Index-Design-Strategie

Analysieren und erstellen Sie für jede Tabelle Indizes für:

1. WHERE-Klausel-Felder: Häufig in Filtern verwendete Felder
2. JOIN-Felder: Alle xxx_id Fremdschlüsselfelder
3. ORDER BY / GROUP BY-Felder: Sortier- und Gruppierungsfelder
4. Eindeutigkeits-Constraints: email, phone, order_no, etc. → UNIQUE-Indizes

Index-Namenskonventionen:

• Gewöhnlicher Index: idx_field_name oder idx_field1_field2
• Eindeutiger Index: uk_field_name

Index-Grenzen:

• Maximal 5 Indizes pro Tabelle (sofern der Benutzer nicht mehr anfordert)
• Nur Indizes erstellen, die Geschäftsabfragen direkt unterstützen

Beziehungsdesign

Identifizieren Sie logische Beziehungen zwischen Tabellen:

1. Eins-zu-Viele (1:N): Am häufigsten

   • Beispiel: benutzer (1) → bestellung (N)
   • Implementierung: Füge user_id in der Bestelltabelle hinzu
   • DrawDB: many-to-one-Beziehung

2. Eins-zu-Eins (1:1): Für Tabellenaufteilungen

   • Beispiel: benutzer (1) → benutzer_profil (1)
   • Implementierung: Füge user_id UNIQUE in der benutzer_profil-Tabelle hinzu
   • DrawDB: one-to-one-Beziehung

3. Viele-zu-Viele (N:N): Erfordert eine Junction-Tabelle

   • Beispiel: artikel (N) ↔ tag (N)
   • Implementierung: Erstelle eine article_tag-Junction-Tabelle mit article_id + tag_id
   • DrawDB: Zwei many-to-one-Beziehungen

Schritt 4: Ausgaben generieren

Erstellen Sie alle erforderlichen Ausgabedateien:

4.1 Umfassendes Design-Dokument (Markdown)

Erstellen Sie eine einzige, gut strukturierte Markdown-Datei mit folgendem Inhalt:

Struktur:

# [Projektname] Datenbank-Design-Dokument

## 1. Datenbankübersicht
- Datenbanktyp
- Zeichensatz
- Anzahl Kerntabellen
- Hauptfunktionsmodule

## 2. Tabellenstruktur-Design

### 2.1 [Tabellenname]
**Tabellenname**: table_name
**Beschreibung**: Tabellenbeschreibung

**Feldliste**:
| Feldname | Typ | Null erlaubt | Standardwert | Beschreibung |
|----------|-----|--------------|--------------|--------------|
| id | BIGINT | NEIN | | Primärschlüssel |
| ... | ... | ... | ... | ... |

**Indexliste**:
| Indexname | Typ | Felder |
|-----------|------|--------|
| uk_email | UNIQUE | email |
| idx_username | INDEX | username |

### 2.2 [Nächste Tabelle]
...

## 3. Tabellenbeziehungen
- table1 → table2 (1:N): Beschreibung
- table3 ↔ table4 (N:N): Beschreibung über Junction-Tabelle

## 4. Index-Strategie
Erläutern Sie die Begründung hinter den Index-Design-Entscheidungen

4.2 SQL-Skript

Erstellen Sie ein ausführbares SQL-Skript:

-- Database: project_name
-- Generated: YYYY-MM-DD

-- Drop tables if exists (in reverse dependency order)
DROP TABLE IF EXISTS `table3`;
DROP TABLE IF EXISTS `table2`;
DROP TABLE IF EXISTS `table1`;

-- Create tables (in dependency order)
CREATE TABLE `table1` (
  `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT 'Kommentar',
  ...
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_field` (`field`),
  KEY `idx_field` (`field`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='Tabellenkommentar';

CREATE TABLE `table2` (
  ...
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='Tabellenkommentar';

4.3 DrawDB JSON-Format

Generieren Sie eine DrawDB-kompatible JSON-Datei gemäß references/drawdb-formats.md:

Kritische Formatanforderungen:

• Tabellen-IDs: Verwenden Sie zufällige 21-stellige Zeichenketten (z.B. "_KV5MtPf2m4sI7Inu8pat")
• Feld-IDs: Verwenden Sie zufällige 21-stellige Zeichenketten (z.B. "B8rPRTDtOv9oD2Gp4bhWL")
• Index-IDs: Verwenden Sie numerische Inkremente ab 0 (über ALLE Tabellen hinweg)
• Beziehungs-IDs: Verwenden Sie zufällige 21-stellige Zeichenketten
• Feldtyp: Vollständige Typdefinition angeben (z.B. "VARCHAR(100)", nicht Typ und Größe getrennt)
• Kein size-Feld: Typinformationen sind im Typ-String eingebettet
• Index-Felder: Verwenden Sie Feldnamen-Strings, NICHT Feld-IDs (z.B. ["email"] nicht [1])
• Koordinaten: Verwenden Sie Fließkommazahlen für x/y-Positionen

ID-Generierung:

import random
import string

def generate_id():
    chars = string.ascii_letters + string.digits + '_-'
    return ''.join(random.choice(chars) for _ in range(21))

Layout-Strategie:

• Rasterlayout verwenden: x = (index % 3) * 450 + 50, y = floor(index / 3) * 400 + 50
• Durch vordefinierte Farben rotieren: ["#6360f7", "#bc49c4", "#ffe159", "#89e667", "#ff9159", "#59d9ff", "#ff5959", "#a0a0a0"]

Beziehungsgenerierung:

• Beziehungen für alle xxx_id Fremdschlüsselfelder generieren
• Die tatsächlichen zufälligen String-IDs für Tabellen und Felder verwenden
• Kardinalität basierend auf UNIQUE-Constraint festlegen:
  • Hat UNIQUE → "one_to_one"
  • Hat kein UNIQUE → "many_to_one"

Struktur:

{
  "tables": [
    {
      "id": "random_string",
      "name": "table_name",
      "comment": "Tabellenkommentar",
      "color": "#6360f7",
      "fields": [
        {
          "id": "random_string",
          "name": "id",
          "type": "BIGINT",
          "default": "",
          "check": "",
          "primary": true,
          "unique": true,
          "notNull": true,
          "increment": true,
          "comment": "Primärschlüssel-ID"
        }
      ],
      "indices": [
        {
          "id": 0,
          "fields": ["field_name"],
          "name": "idx_field_name",
          "unique": false
        }
      ],
      "x": 50.0,
      "y": 50.0
    }
  ],
  "relationships": [
    {
      "name": "",
      "startTableId": "random_string",
      "endTableId": "random_string",
      "endFieldId": "random_string",
      "startFieldId": "random_string",
      "id": "random_string",
      "updateConstraint": "No action",
      "deleteConstraint": "No action",
      "cardinality": "many_to_one"
    }
  ],
  "notes": [],
  "subjectAreas": [],
  "database": "generic",
  "types": [],
  "title": "Projektdatenbank"
}

4.4 DrawDB DBML-Format

Generieren Sie eine DBML-Datei gemäß references/drawdb-formats.md:

Wichtige Punkte:

• Kleingeschriebene Datentypen verwenden: bigint, varchar(50), datetime
• Attribute in Klammern hinzufügen: [pk, increment, not null, unique, note: 'Kommentar']
• Indizes innerhalb der Tabellendefinition im Block indexes { } definieren
• Beziehungen außerhalb von Tabellen mit Ref-Blöcken definieren
• Korrekte Beziehungssymbole verwenden: > (many-to-one), - (one-to-one)

Struktur:

Table table_name [headercolor: #6360f7] {
  id bigint [pk, increment, not null, unique, note: 'Kommentar']
  field varchar(100) [not null, note: 'Kommentar']
  
  indexes {
    field [unique, name: 'uk_field']
  }
  
  Note: 'Tabellenkommentar'
}

Ref fk_name {
  table1.field > table2.id [delete: no action, update: no action]
}

Schritt 5: Abschließen und Ausliefern

5.1 Ausgabeverzeichnis-Konvention

Empfohlener Ansatz (gemäß Claude Code Official Standards):

Speichern Sie alle Datenbank-Design-Dateien in outputs/<projektname>/database/:

outputs/
└── <projektname>/              # Projektname (z.B. e-commerce-system)
    └── database/
        ├── schema-design.md     # Umfassendes Design-Dokument
        ├── schema.sql           # Ausführbares SQL-Skript
        ├── drawdb-schema.json   # DrawDB JSON-Format
        └── drawdb-schema.dbml   # DrawDB DBML-Format

Beispiel:

outputs/
├── e-commerce-system/
│   └── database/
│       ├── schema-design.md
│       ├── schema.sql
│       ├── drawdb-schema.json
│       └── drawdb-schema.dbml
└── task-management-app/
    └── database/
        ├── schema-design.md
        └── schema.sql

Alternativer Ansatz (traditionelle Projektstruktur):

Wenn Ihr Projekt eine bestehende Verzeichnisstruktur hat, können Sie auch verwenden:

project-root/
└── database/
    ├── schema-design.md
    ├── schema.sql
    ├── drawdb-schema.json
    └── drawdb-schema.dbml

5.2 Ausgabedatei-Liste

Erforderliche Ausgaben (4 Dateien):

• schema-design.md - Umfassendes Datenbank-Design-Dokument (Chinesisch)
• schema.sql - Ausführbares SQL-Skript
• drawdb-schema.json - DrawDB JSON-Format
• drawdb-schema.dbml - DrawDB DBML-Format

Optionale Ausgaben:

• er-diagram.png - ER-Diagramm-Visualisierung (falls Tools verfügbar)
• index-strategy.md - Index-Strategie-Dokumentation

5.3 Dateibenennungs-Konvention

• Kebab-Case verwenden: user-authentication-schema.sql
• Version/Datum bei Bedarf einfügen: schema-v1.0.sql oder schema-2024-12-10.sql
• Beschreibende Namen verwenden: e-commerce-database-schema.sql

5.4 Zusammenfassung der Auslieferung

Geben Sie nach der Generierung aller Dateien eine Zusammenfassung mit:

• Kurzer Überblick über die Design-Entscheidungen
• Anzahl der erstellten Tabellen
• Wichtige Beziehungen und deren Begründung
• Wie man in DrawDB importiert (JSON oder DBML)
• Bestätigung des Dateispeicherorts
• Vorschläge für nächste Schritte (z.B. Indizes überprüfen, in der Entwicklungsumgebung implementieren)

Spezielle Behandlung

Wenn der Benutzer „Keine Systemfelder“ sagt

Nur minimale Struktur erstellen:

CREATE TABLE `table_name` (
  `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT 'Primärschlüssel',
  /* nur Geschäftsfelder */
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='Tabellenkommentar';

Wenn der Benutzer eine Nicht-MySQL-Datenbank angibt

SQL-Syntax entsprechend anpassen:

PostgreSQL:

• Verwende SERIAL oder BIGSERIAL anstelle von AUTO_INCREMENT
• Verwende TIMESTAMP anstelle von DATETIME
• Unterschiedliche Syntax für Defaults und Constraints

SQL Server:

• Verwende IDENTITY(1,1) anstelle von AUTO_INCREMENT
• Verwende DATETIME2 anstelle von DATETIME
• Verwende NVARCHAR für Unicode-Unterstützung

Oracle:

• Verwende SEQUENCE für Auto-Inkrement
• Verwende VARCHAR2 anstelle von VARCHAR
• Verwende DATE oder TIMESTAMP für Zeitfelder

Wenn die Anforderungen vage sind

Intelligente Inferenz anwenden:

1. Die Geschäftsdomäne identifizieren (E-Commerce, Blog, CRM, etc.)
2. Ähnliche Beispiele in references/design-examples.md referenzieren
3. Für die Domäne geeignete allgemeine Felder einfügen
4. Sinnvolle Indizes basierend auf typischen Abfragemustern entwerfen
5. Im Design-Dokument erläuterte Annahmen erklären

Qualitätsprüfung

Vor dem Abschluss prüfen:

• Alle Tabellen haben COMMENT
• Alle Felder haben COMMENT
• Feldgrößen sind realistisch (nicht generisch VARCHAR(255))
• Indexanzahl pro Tabelle ≤ 5
• Keine physischen FOREIGN KEY-Constraints
• Systemfelder hinzugefügt (sofern vom Benutzer nicht anders angegeben)
• Alle Namen verwenden snake_case
• Logische Beziehungen klar dokumentiert
• SQL-Syntax entspricht dem Ziel-Datenbanktyp
• JSON/DBML-Formate folgen den DrawDB-Spezifikationen
• Alle Fremdschlüsselbeziehungen haben entsprechende Ref-Einträge

Beispiel-Aufrufe

Benutzer sagt: „Entwirf eine Datenbank für ein E-Commerce-System mit Benutzer-, Produkt- und Bestellfunktionen“ → Lies design-principles.md und design-examples.md → Design: user_info, product_info, order_info, order_detail Tabellen → Generiere alle 4 Ausgabedateien

Benutzer sagt: „Design a blog database“ → Inferieren: user, article, comment, tag, article_tag Tabellen → Standard-Design-Prinzipien befolgen → Generiere alle Ausgaben

Benutzer sagt: „Erstelle eine Benutzertabelle für PostgreSQL“ → Einzelnes Tabellen-Design → SQL-Syntax für PostgreSQL anpassen → In allen Ausgabeformaten enthalten

Referenzen

• references/design-principles.md - Kern-Design-Regeln und Standards
• references/drawdb-formats.md - JSON- und DBML-Formatspezifikationen
• references/design-examples.md - Praxisnahe Designbeispiele