DBMS-Datenmodelle erklärt: Typen, Ebenen und PostgreSQL-Beispiele

Um eine Datenbank richtig zu verwalten, muss man die Grundlagen von Datenmodellen verstehen.

In Datenbankmanagementsystemen (DBMS)dienen Datenmodelle als Blaupausen, die festlegen, wie Infos gespeichert, verknüpft und abgerufen werden.

Sie sind die Übersetzungsschicht zwischen den Geschäftsanforderungen („Wir müssen Kunden, Bestellungen und Produkte nachverfolgen“) und der technischen Umsetzung („Wir speichern das in vier Tabellen, die durch Fremdschlüssel miteinander verbunden sind“).

Ein gut durchdachtes Datenmodell hilft dabei:

• Legt den Umfang des Systems fest
• Legt die Regeln fest, die dafür sorgen, dass die Daten korrekt bleiben.
• Sorgt für langfristige Skalierbarkeit
• Verbessert die Leistung

In diesem Leitfaden schauen wir uns klassische und moderne Datenmodelle, Abstraktionsebenen, Designprozesse und fortgeschrittene Optimierungsstrategien an – alles anhand eines PostgreSQL-E-Commerce-Datensatzes.

Warum Datenmodelle so wichtig sind

Hier sind ein paar kurze Gründe, warum du dich mit Datenmodellen auskennen solltest und warum sie wichtig sind.

• Brücke zwischen den Teams: Business-Analysten und Entwickler arbeiten mit derselben logischen Struktur.
• Datenintegritäts: Einschränkungen verhindern ungültige, unvollständige oder doppelte Daten.
• Performance-: Gut modellierte Datenbanken machen schnelle Suchvorgänge und Verknüpfungen möglich.
• Skalierbarkeit: Rechnet mit zukünftigem Wachstum und neuen Anforderungen.
• Konsistenz: Stellt sicher, dass Daten in verschiedenen Teilen des Systems dasselbe bedeuten.

Was ist ein Datenmodell in einem DBMS?

Ein Datenmodell in einem Datenbankmanagementsystem (DBMS) ist ein Entwurf, der von Datenbanken verwendet wird, um zu definieren, wie Daten organisiert, gespeichert und abgerufen werden.

Das Datenmodell bietet eine strukturierte Möglichkeit, Datenelemente und ihre Beziehungen darzustellen, was eine effiziente Datenverwaltung und -bearbeitung ermöglicht.

Ein Datenmodell hilft dabei, Fragen zu beantworten wie:

• „Welche Daten haben wir denn?“
• Wie hängt eine Art von Daten mit einer anderen zusammen?
• „Welche Regeln müssen diese Daten befolgen?“

Ein Datenmodell macht alle wichtigen Infos und Antworten auf diese Fragen für Datenbankadministratoren leicht verständlich.

Zweck eines Datenmodells

Ein Datenmodell strukturiert und organisiert Infos in einer Datenbank. Das sorgt für Klarheit und Einheitlichkeit bei der Datenverarbeitung innerhalb eines Systems.

Hier sind ein paar häufige Gründe, warum ein Datenmodell gebraucht wird:

• Struktur-: Organisiert Infos auf logische Weise.
• Beziehungen: Zeigt, wie Datenelemente miteinander interagieren.
• Einschränkungen: Sorgt dafür, dass die Daten korrekt bleiben und die Geschäftslogik eingehalten wird.
• Abstraktion: Nutzer müssen sich keine Gedanken darüber machen, wie die Daten physisch gespeichert werden.

Warum das wichtig ist

Ohne ein klares Datenmodell riskierst du Folgendes:

• Doppelte Daten, die in verschiedenen Formaten gespeichert sind.
• Verwaiste Datensätze, die keine gültige übergeordnete Entität haben.
• Unterschiedliche Interpretationen derselben Daten.
• Schlechte Abfrageleistung wegen einer nicht optimierten Struktur.

Hier ist eine einfache SQL-Abfrage, die zeigt, wie eine Datenbank geändert werden kann, um Struktur, Beziehungen und Einschränkungen einzubauen.

ALTER TABLE Orders
ADD CONSTRAINT fk_customer
FOREIGN KEY (CustomerID)
REFERENCES Customer(CustomerID);

Dadurch wird sichergestellt, dass jede Bestellung mit einem bestehenden Kunden verbunden ist, was eine einfache, aber wirkungsvolle Methode ist, um die Integrität zu wahren.

Beispiel für die Einrichtung eines Datensatzes mit PostgreSQL

Bevor wir mit weiteren Erklärungen weitermachen, erstellen und verwenden wir einen einfachen E-Commerce-Datensatz, um die Konzepte in diesem Leitfaden zu veranschaulichen.

Wir nehmen die folgenden Entitäten in den Datensatz auf.

1. Kunde: Speichert Käuferinfos.
2. Produkt: Lagert Artikel, die zum Verkauf stehen.
3. Bestellungen: Zeichnet jede Kauftransaktion auf.
4. Bestellpositionen: Speichert Infos darüber, welche Produkte in jeder Bestellung sind.

Hier ist ein einfaches ASCII-ER-Diagramm, das die Beziehungen zwischen den Tabellen zeigt, die wir erstellen werden.

Customer ───< Orders ───< OrderItems >─── Product

Das passt zu dieser Idee:

• Ein Kunde → mehrere Bestellungen.
• Eine Bestellung → mehrere Bestellpositionen.
• Ein Produkt → kann in vielen Bestellungen vorkommen.

Erstellen eines Schemas einer Tabelle

Als Nächstes werde ich die Tabellen erstellen und sie in PostgreSQL ausführen, um die Abfragen zu starten.

Hier ist das Schema und der SQL-Code zum Erstellen der benötigten Tabellen.

CREATE TABLE Customer (
    CustomerID SERIAL PRIMARY KEY,
    CustomerName VARCHAR(100) NOT NULL,
    Email VARCHAR(100) UNIQUE NOT NULL,
    Phone VARCHAR(20),
    CreatedAt TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE Product (
    ProductID SERIAL PRIMARY KEY,
    ProductName VARCHAR(100) NOT NULL,
    Category VARCHAR(50),
    Price NUMERIC(10, 2) NOT NULL
);

CREATE TABLE Orders (
    OrderID SERIAL PRIMARY KEY,
    CustomerID INT NOT NULL,
    OrderDate DATE NOT NULL,
    Status VARCHAR(20) DEFAULT 'Pending',
    FOREIGN KEY (CustomerID) REFERENCES Customer(CustomerID)
);

CREATE TABLE OrderItems (
    OrderItemID SERIAL PRIMARY KEY,
    OrderID INT NOT NULL,
    ProductID INT NOT NULL,
    Quantity INT NOT NULL CHECK (Quantity > 0),
    FOREIGN KEY (OrderID) REFERENCES Orders(OrderID),
    FOREIGN KEY (ProductID) REFERENCES Product(ProductID)
);

Beispieldaten einfügen

Als Nächstes fügen wir ein paar grundlegende Infos in die 

INSERT INTO Customer (CustomerName, Email, Phone)
VALUES
('Alice Brown’, '[email protected]', '91234567'),
('Bob McKee', '[email protected]', '98765432');

INSERT INTO Product (ProductName, Category, Price)
VALUES
('Laptop', 'Electronics', 1200.00),
('Wireless Mouse', 'Electronics', 25.50),
('Office Chair', 'Furniture', 150.00);

INSERT INTO Orders (CustomerID, OrderDate, Status)
VALUES
(1, '2025-08-01', 'Shipped'),
(2, '2025-08-02', 'Pending');

INSERT INTO OrderItems (OrderID, ProductID, Quantity)
VALUES
(1, 1, 1),
(1, 2, 2),
(2, 3, 1);

Dein ER-Diagramm für die Datenbank sollte so aussehen:

Wichtige Teile eines DBMS-Datenmodells

Ein solides Datenmodell hat vier Hauptteile:

1. Einheiten

Bei der Datenmodellierung sind Entitäten die zentralen, eindeutigen Objekte oder Konzepte innerhalb eines Systems, über die wir Daten speichern wollen. Entitäten werden oft als Tabellen in einer Datenbank dargestellt. 

Beispiele für Entitäten in unserem Datensatz:

• Customer
• Product
• Orders
• OrderItems

Diese Sachen sind die wichtigsten „Substantive“ in der Datenbank.

Entitäten sind das Fundament. Alle anderen Teile des Modells, wie Attribute, Beziehungen und Einschränkungen, bauen darauf auf.

2. Attribute

In der Datenmodellierung sind Attribute Merkmale oder Eigenschaften, die eine Entität beschreiben. Sie zeigen die spezifischen Datenpunkte, die eine Entität beschreiben, wie den Namen, die E-Mail-Adresse oder die Anschrift eines Kunden.

Beispiele:

• Für „ Customer “: CustomerName, Email, Phone.
• Für „ Product “: ProductName, Price, Category.

Einfach gesagt, sind Attribute die Details, die dir bei jeder Entität wichtig sind. Das sind meistens Spalten in einer Tabelle.

3. Beziehungen

Beziehungen in einem Datenmodell zeigen, wie verschiedene Entitäten oder Tabellen miteinander verbunden sind, und stellen die Verbindungen zwischen ihnen dar. Stell dir diese als logische Verbindungen zwischen Entitäten vor.

Beispiele in unserem Datensatz:

• Ein „ Customer “ kann mehrere „ Orders “ haben (1-zu-viele).
• Ein „ Order ” kann mehrere „ Products ” über „ OrderItems ” haben (viele-zu-viele, aufgelöst durch eine Verknüpfungstabelle).

Beziehungen sorgen dafür, dass das Datenmodell die Verbindungen in der echten Welt richtig abbildet.

4. Einschränkungen

Bei der Datenmodellierung sind Einschränkungen Regeln, die die in einer Datenbank zulässigen Werte begrenzen und so die Genauigkeit, Konsistenz und Integrität der Daten sicherstellen.

Einschränkungen helfen dabei, die Datenbank sauber zu halten, indem sie verhindern, dass falsche oder widersprüchliche Daten reinkommen.

Beispiele:

• UNIQUE Einschränkung für Customer.Email.
• CHECK Beschränkung, um sicherzustellen, dass Quantity > 0 in OrderItems funktioniert.

PostgreSQL-Beispiel

Hier ist ein Beispiel für die Verwendung einiger Arten von Einschränkungen in einer SQL-Abfrage.

CREATE TABLE OrderItems_Constraint (
    OrderItemID SERIAL PRIMARY KEY,
    OrderID INT NOT NULL,
    ProductID INT NOT NULL,
    Quantity INT NOT NULL CHECK (Quantity > 0),
    FOREIGN KEY (OrderID) REFERENCES Orders(OrderID),
    FOREIGN KEY (ProductID) REFERENCES Product(ProductID)
);

In diesem Beispiel haben wir die Einschränkungen „ PRIMARY “, „ CHECK “, „ NOT NULL “ und „ REFERENCES “ benutzt.

Arten von Datenmodellen in DBMS

In Datenbanken gibt's verschiedene Arten von Datenmodellen. Das zeigt, wie Daten je nach ihrer Art gespeichert werden.

Klassische Modelle

Schauen wir uns erst mal ein paar gängige klassische Modelle an, die in Datenbankmanagementsystemen verwendet werden.

Hierarchisches Modell

Ein hierarchisches Datenmodell sortiert Daten in einer Baumstruktur, wo jeder Datensatz (Knoten) einen einzigen übergeordneten Eintrag (außer dem Stammknoten) hat und mehrere untergeordnete Einträge haben kann.

• Struktur-: Daten, die in einem Baumformat gespeichert sind; jeder Elternteil kann mehrere Kinder haben, aber jedes Kind hat nur einen Elternteil.
• Anwendungsfälle: Alte Banksysteme, Flugbuchungssysteme.
• Vorteile: Super schnell für One-to-Many-Lookups.
• Nachteile: Es ist echt schwierig, viele-zu-viele-Beziehungen zu handhaben.

Beispiel (XML-ähnliche Darstellung):

<Customer id="1">
    <Name>Alice Brown</Name>
    <Orders>
        <Order id="1" date="2025-08-01"/>
    </Orders>
</Customer>

Moderne Versionen davon findet man oft in XML/JSON-Speichern, aber das Modell selbst geht auf frühe Mainframe-DBMS wie IMS zurück.

Netzwerkmodell

Ein Netzwerkdatenmodell ist eine flexible Art, Daten und Beziehungen darzustellen, besonders praktisch für komplizierte, viele-zu-viele-Verbindungen. 

Es nutzt eine Grafikstruktur mit Knoten (die Entitäten darstellen) und Kanten (die Beziehungen darstellen), um Daten zu organisieren, was im Vergleich zu hierarchischen Modellen effizientere und direktere Zugriffspfade ermöglicht.

• Struktur-: Grafik mit Datensätzen, die über Zeiger miteinander verbunden sind.
• Vorteile: Kann mit komplizierten Mehr-zu-Mehr-Beziehungen umgehen.
• Nachteile: Kompliziert abzufragen und zu pflegen.

Relationales Modell

Das relationale Datenmodell ist eine Methode, um Daten in Tabellen mit Zeilen und Spalten zu strukturieren, was eine effiziente Speicherung, Abfrage und Verwaltung von Informationen ermöglicht.

• Struktur-: Daten in Tabellen, Zeilen und Spalten.
• Vorteile: SQL-Unterstützung, ACID-Konformität, Normalisierung.
• Nachteile: Verbindungen können bei großem Umfang teuer sein.

Beispielabfrage aus unserem Datensatz:

SELECT c.CustomerName, o.OrderID, o.OrderDate
FROM Customer c
JOIN Orders o ON c.CustomerID = o.CustomerID;

Diese Abfrage zeigt, wie man mit der Funktion „ JOIN “ Beziehungen zwischen den Tabellen „ Customer “ und „ Orders “ herstellt.

Das ergibt die folgende Tabelle:

Moderne Modelle

Mit der Weiterentwicklung der Datenbanktechnologie sind auch ein paar moderne Modelle aufgetaucht. Hier sind ein paar Beispiele:

Objektorientiertes Modell

Das objektorientierte Modell bringt Datenbank- und objektorientierte Programmierkonzepte zusammen. Es unterstützt Vererbung und Kapselung.

Objekt-relationales Modell

Das objektrelationale Modell ist eine Mischung aus relationalem und objektorientiertem Modell.

Nosql-Modelle

Nosql-Datenmodelle sind anders als die starren, tabellenbasierten Strukturen von traditionellen relationalen Datenbanken. Sie bieten flexible Schemata und verschiedene Methoden zur Datenorganisation, um große Mengen unstrukturierter und halbstrukturierter Daten zu verarbeiten.

Hier sind ein paar Beispiele für nosql-Modelle:

• Schlüssel-Wert-: Redis (schnelle Suchvorgänge).
• Dokument: MongoDB (flexibles JSON).
• Spaltenfamilien-: Cassandra (Speicher mit breiten Spalten).
• Grafik: Neo4j (Daten mit vielen Beziehungen).

Hier ist ein Beispiel für ein Dokumentdatenmodell (MongoDB-Dokument):

{
    "CustomerName": "Alice Brown",
    "Orders": [
        {"ProductName": "Laptop", "Quantity": 1}
    ]
}

Abstraktionsstufen der Datenmodellierung

Der Prozess der Datenmodellierung läuft auf drei verschiedenen Ebenen ab – konzeptionell, logisch und physisch.

Diese Ebenen sind die verschiedenen Detailstufen, die beim Entwerfen einer Datenbank oder eines Informationssystems verwendet werden. Sie helfen dabei, die Komplexität zu bewältigen, indem sie sich auf bestimmte Aspekte der Daten und ihrer Struktur konzentrieren.

Konzeptionell

Das konzeptionelle Datenmodell ist die höchste, technologieunabhängige Abstraktion im Datenmodellierungsprozess. Es geht darum, die wichtigsten Elemente und ihre Beziehungen in einem System zu erklären, ohne zu sehr ins technische Detail zu gehen.

Diese Ebene erfasst Geschäftsanforderungen und -beziehungen.

Beispiel: Unser ER-Diagramm zeigt Customer → Orders.

Logisch

Das logische Datenmodell ist die zweite Abstraktionsebene. Es beschreibt Entitäten, Attribute und Beziehungen, ohne eine bestimmte Datenbank zu erwähnen.

Diese Schicht macht aus dem konzeptionellen Modell ein DBMS-spezifisches Schema. Es beschreibt Tabellen, Schlüssel und Beziehungen, ohne auf Details zur Speicherung einzugehen.

Körperlich

Die physische Datenmodellschicht hat ein Schema mit Indizes, Partitionen und Speicherparametern.

Hier ist ein Beispiel für einen Index:

CREATE INDEX idx_order_customer ON Orders(CustomerID);

Jetzt schauen wir uns diesen Index mit dieser Abfrage an:

SELECT indexname, indexdef
FROM pg_indexes
WHERE tablename = 'orders';

Wie du im folgenden Index sehen kannst, haben wir einen neuen Index namens „ idx_order_customer ” erstellt.

Datenmodellierungsprozess

Datenmodellierung ist ein strukturierter Ansatz, um Geschäftsanforderungen in einen technischen Entwurf zu verwandeln, der festlegt, wie Daten gespeichert, verknüpft und abgerufen werden. 

Wenn man es richtig macht, hilft Datenmodellierung dabei, Redundanzen zu vermeiden, die Datenqualität zu verbessern und die spätere Wartung einfacher zu machen.

Quelle: Spickzettel zu den Dimensionen der Datenqualität

Der Prozess läuft normalerweise in Etappen ab. Schauen wir uns das mal genauer an.

1. Anforderungserfassung

Das Sammeln von Anforderungen ist die Basis für den ganzen Prozess der Datenmodellierung. Im Moment versuchst du zu verstehen, was das Unternehmen braucht und warum.

Es gibt verschiedene Möglichkeiten, Anforderungen effektiv zu erfassen. 

• Interviews mit den Beteiligten ermöglichen es dir, direkt mit den Leuten zu reden, die die Datenbank nutzen oder davon abhängig sind, wie zum Beispiel Business-Analysten, Manager oder Entwickler.
• Dokumentenüberprüfungen helfen dir, bestehende Systeme zu verstehen, indem du dir alte Berichte, Arbeitsabläufe oder alte Datenbankschemata anschaust.
• Workshops können verschiedene Abteilungen zusammenbringen, um sich über Datendefinitionen abzustimmen und Lücken zu finden.

Das Ergebnis dieser Phase sollte ein klarer Satz dokumentierter Anforderungen sein, die die Datenentitäten, Beziehungen und Geschäftsregeln beschreiben. 

In unserem Beispiel-Datensatz für den Einzelhandel könnten die Leute zum Beispiel sagen, dass sie Kundenbestellungen, Produkte und Bestelldaten verfolgen wollen, um Kennzahlen wie den Gesamtumsatz pro Produktkategorie und die Wiederkaufsrate zu berechnen.

2. Konzeptioneller Entwurf

Das Konzeptdesign nimmt diese Geschäftsanforderungen und macht daraus eine visuelle, übergeordnete Darstellung der Daten. 

In dieser Phase konzentrierst du dich darauf, welche Entitäten es gibt und wie sie miteinander verbunden sind, ohne dich um technische Details wie Primärschlüsseltypen oder Indizierungsstrategien zu kümmern.

Hier kommen Entity-Relationship-Diagramme (ER-Diagramme) ins Spiel. ER-Diagramme zeigen Entitäten (z. B. Kunde, Produkt, Bestellung), ihre Eigenschaften und die Beziehungen zwischen ihnen. 

Für unseren Datensatz:

• Customer könnte Kunden-ID, Name, E-Mail-Adresse umfassen.
• Product könnte Produkt-ID, Name, Kategorie beinhalten.
• Order könnte OrderID, OrderDate enthalten.
• OrderItem könnte OrderItemID, OrderID, ProductID, Quantity, Price enthalten.

Die Beziehungen könnten so aussehen:

• Ein Kunde kann mehrere Bestellungen machen.
• Eine Bestellung kann mehrere Artikel haben.
• Ein Produkt kann in mehreren Bestellpositionen auftauchen.

Dieses Diagramm ist ein wichtiger Bezugspunkt für sowohl die Geschäfts- als auch die Technikteams.

3. Logisches Design

Das logische Design baut auf dem konzeptionellen Modell auf, indem Datenbankregeln, vor allem die Normalisierung, angewendet werden. 

Normalisierung ist der Prozess, bei dem eine relationale Datenbank so strukturiert wird, dass Redundanzen und Abhängigkeiten minimiert werden. Das läuft oft in Schritten ab (1NF, 2NF, 3NF), wobei jeder Schritt bestimmte Anforderungen hat.

• In 1NFsicherst du, dass alle Felder atomar sind (keine Mehrfachwerte in einer Spalte) und dass es keine sich wiederholenden Gruppen gibt.
• 2NF entfernt partielle Abhängigkeiten – das heißt, wenn du einen zusammengesetzten Schlüssel hast, müssen alle Nicht-Schlüssel-Attribute vom gesamten Schlüssel abhängen.
• 3NF entfernt transitive Abhängigkeiten und stellt sicher, dass Nicht-Schlüsselattribute nur vom Primärschlüssel abhängen und nicht von anderen Nicht-Schlüsselattributen.

In unserem Beispiel gehört die E-Mail-Adresse des Kunden nur in die Tabelle „ Customer “ und nicht doppelt in die Tabelle „ Order “. Genauso sollten Infos zu Produktkategorien in der Tabelle „ Product “ gespeichert werden und nicht über mehrere Datensätze in „ OrderItem “ verteilt sein.

4. Physikalisches Design

Das physische Design nimmt das logische Modell und passt es an ein bestimmtes Datenbanksystem wie PostgreSQL oder MySQL an. In dieser Phase geht's um Entscheidungen zu Datentypen, Speicheroptimierung und Leistungsoptimierung.

Indizes sind hier ein wichtiger Faktor. Wenn du zum Beispiel einen Index zu „ OrderDate “ in der Tabelle „ Order “ hinzufügst, kannst du Abfragen, die nach Datum filtern, echt beschleunigen.

Partitionierung kann auch bei großen Datensätzen eingesetzt werden, indem die Daten nach Datum, Bereich oder Hash-Schlüsseln in überschaubare Teile aufgeteilt werden, um die Abfrageleistung zu verbessern. 

Du legst auch Einschränkungen fest, wie zum Beispiel Fremdschlüssel, um die Datenintegrität auf Datenbankebene sicherzustellen.

5. Validierung

Sobald das Design fertig ist, muss man es vor der Veröffentlichung überprüfen. 

Dazu lädt man Beispieldaten, am besten realistische Testdaten, die den erwarteten Datenmengen entsprechen, und führt Abfragen durch, die die tatsächliche Nutzung simulieren.

In unserem Einzelhandelsdatensatz könntest du zum Beispiel eine Abfrage machen, um die Verkaufszahlen pro Monat zu berechnen und sicherzustellen, dass die Zahlen mit den Erwartungen des Unternehmens übereinstimmen. 

Du würdest auch Randfälle testen, z. B. was passiert, wenn eine Bestellung ohne Artikel aufgegeben wird (was bei korrekten Einschränkungen eigentlich nicht möglich sein sollte).

6. Einsatz

Der letzte Schritt ist, das validierte Design in die Produktion zu bringen. Das sollte mit versionskontrollierten Migrationsskripten gemacht werden, damit man die Änderungen im Laufe der Zeit verfolgen kann.

Zur Bereitstellung gehört auch, dass man die Überwachung von Leistung und Fehlern einrichtet und sicherstellt, dass das Schema gut dokumentiert ist, damit zukünftige Änderungen ohne Probleme gemacht werden können. 

Nach der Bereitstellung ist es üblich, das Design regelmäßig zu überprüfen, da auch neue Anforderungen auftauchen können.

Vorteile von Datenmodellen

Ein gut durchdachtes Datenmodell hat echt viele Vorteile.

1. Klarheit: Datenmodelle bieten eine gemeinsame Sprache für Geschäfts- und Technikteams. Wenn sich alle einig sind, was ein „Kunde“ ist und wie das mit „Bestellungen“ zusammenhängt, gibt's weniger Missverständnisse und die Entwicklung geht schneller voran.
2. Integritäts: Einschränkungen wie Fremdschlüssel und eindeutige Indizes sorgen dafür, dass keine falschen Daten ins System kommen. Das schützt die Datenqualität und macht die Berichterstattung zuverlässiger.
3. Performance-: Durch die Verwendung von Indizes und die Optimierung von Verknüpfungen können Datenmodelle die Abfragegeschwindigkeit deutlich verbessern. Das ist besonders wichtig für analytische Abfragen, die große Datensätze bearbeiten.
4. Skalierbarkeit: Ein gutes Modell lässt sich leichter erweitern. Wenn das Unternehmen zusätzliche Funktionen braucht, um Werbeaktionen oder Treuepunkte später im Prozess zu verfolgen, kannst du neue Tabellen hinzufügen, ohne die bestehenden Arbeitsabläufe zu stören.

Nachteile von Datenmodellen

1. Komplexitäts: In großen Systemen kann das Datenmodell ziemlich kompliziert sein, mit Hunderten von Tabellen und Beziehungen. Das kann Neulinge abschrecken und erfordert spezielle Kenntnisse, um sich zurechtzufinden.
2. Kosten: Qualifizierte Datenmodellierer einzustellen und Modellierungstools für Unternehmen zu kaufen, kann echt teuer sein. Für kleine Unternehmen könnte das eine ziemlich große Investition bedeuten.
3. Steifigkeits: Relationale Schemata sind nicht so flexibel wie nosql-Lösungen. Änderungen an Modellen müssen sorgfältig geplant werden, damit nachgelagerte Anwendungen und Abhängigkeiten nicht kaputtgehen.
4. Anbieterabhängigkeit: Wenn man sich stark auf bestimmte Datenbankfunktionen verlässt (wie die Oracle-spezifische Indizierung oder die erweiterte Partitionierung von SQL Server), kann das zukünftige Migrationen teuer und kompliziert machen.

Fortgeschrittene Modellierungsmethoden

Datenmodellierung kann auch fortgeschrittene Methoden zur Umsetzung haben.

1. Dimensionale Modellierung

Dimensionsmodellierung ist in Data Warehousing üblich, wo es darum geht, analytische Abfragen intuitiv und schnell zu machen.

Dazu braucht man spezifische Schemata:

• Sternschema: Eine zentrale Faktentabelle (z. B. OrderItems) speichert Metriken, während mehrere Dimensionstabellen (z. B. Customer, Product, Date) beschreibende Attribute speichern. Diese Struktur ist für BI-Tools einfach abzufragen.

So könnte es aussehen:

Quelle: Abfragen des Sternschemas

• Snowflake-Schema: Dimensionstabellen werden in Untertabellen normalisiert, was Speicherplatz spart, aber mehr Verknüpfungen braucht. Zum Beispiel könnte „ Product “ in die Tabellen „ Product “ und „ Category “ aufgeteilt werden.

2. Entity-Relationship-Modellierung (ER-Modellierung)

ER-Modellierung ist eher typisch für Transaktionssysteme. Es legt Wert auf Normalisierung, um die Datenintegrität sicherzustellen. Manchmal wird die Denormalisierung gezielt eingesetzt, um die Leseleistung zu verbessern, vor allem bei Daten, auf die man oft zugreift.

3. Polyglott-Modellierung

Beim Polyglot-Modellieren werden verschiedene Datenbanktypen für unterschiedliche Arbeitslasten genutzt. 

Du könntest zum Beispiel PostgreSQL für Bestelltransaktionen und MongoDB für einen Produktkatalog mit flexiblen Attributen nutzen. So kannst du das richtige Werkzeug für die richtige Aufgabe nutzen, aber es macht die Bedienung komplizierter.

Leistungsoptimierung und Designprinzipien

1. Häufige Anti-Muster

• Über-Normalisierung: Wenn du Daten in zu viele kleine Tabellen aufteilst, kann das zu vielen Verknüpfungen und langsamen Abfragen führen.
• Unterindexierung: Wenn du oft gefilterte Spalten nicht indizierst, kann das zu vollständigen Scans der Tabelle und Performance-Problemen führen.

2. Überlegungen zu nosql

Bei nosql-Systemen basiert das Design oft auf Zugriffsmustern und nicht auf strikter Normalisierung. Die Daten sind so organisiert, dass man möglichst wenige Abfragen für gängige Vorgänge braucht, und Partitionierung ist wichtig, um Engpässe zu vermeiden.

3. ACID-Kompromisse

Relationale Systeme wie PostgreSQL unterstützen ACID-Eigenschaftenund sorgen so für Datenkonsistenz. Viele nosql-Datenbanken lockern diese Garantien, um die Geschwindigkeit und Skalierbarkeit zu verbessern, und tauschen dabei Konsistenz gegen letztendliche Konvergenz ein.

Fazit

Datenmodelle sind ein wichtiger Teil vom Datenbankdesign und können ganz unterschiedlich aussehen. In modernen Unternehmen muss man aber Optimierungen vornehmen, damit diese Modelle richtig gut funktionieren.

Die Technik entwickelt sich ständig weiter und wird immer auf den neuesten Stand gebracht. In der Datenbranche muss man also ständig dazulernen und sich anpassen. Wenn du mehr über Datenbanken wissen willst, schau dir unseren Kurs zum Thema an. Datenbankdesign oder Einführung in relationale Datenbanken in SQL an, um loszulegen.

Lieber lesen? Unsere Artikel über Datenmodellierungstools oder DBMS-Interviewfragen könnten dir helfen.