Datenmodell, das in fünf Jahren noch trägt?
Wir modellieren mit dir von Grund auf — oder reviewen ein bestehendes Modell ehrlich und sagen dir, was trägt und was zur Hypothek wird. Mit Sanierungspfad, wenn nötig.
Dataverse-Datenmodellierung: Best Practices aus der Praxis
Die meisten Dataverse-Probleme in Sanierungsprojekten sind keine Plattformfehler — es sind Modellierungsentscheidungen, die unter Zeitdruck getroffen und nie korrigiert wurden. Ein zu lockerer Datentyp, ein falsches Beziehungsverhalten: einzeln harmlos, in Summe ein Modell, das niemand mehr anzufassen wagt.
Dieser Beitrag ist die Praxisanleitung: die Entscheidungen, die ein Datenmodell in fünf Jahren noch tragfähig machen. Die Gesamteinordnung liefert unser Dataverse-Leitfaden — hier geht es ans Eingemachte.
1. Erst das Modell, dann die App
Die wichtigste Regel ist eine Haltung: Dataverse ist datenzentrisch. Du baust nicht eine App, sondern ein Datenmodell, um das herum mehrere Apps, Flows und Berichte entstehen. Wer mit dem App-Screen anfängt, baut ein Modell, das genau eine App versteht und jede zweite blockiert. Konkret: Bevor der erste Screen entsteht, steht das Entitätenmodell auf dem Whiteboard — Tabellen, Beziehungen, Schlüssel. Fühlt sich an Tag eins langsamer an, ist über das Projekt deutlich schneller.
2. Normalisierung — und wann du sie bewusst brichst
Normalisiere zuerst. Jedes fachliche Konzept bekommt seine eigene Tabelle, Wiederholungen werden über Beziehungen abgebildet — ein Projekt hat einen Kunden über einen Lookup, nicht den Kundennamen dupliziert. Es gibt genau einen guten Grund zu denormalisieren: Lese-Performance bei häufigen, teuren Abfragen. Dafür hat Dataverse Rollup-Spalten und berechnete Spalten. Beide sind kontrollierte Denormalisierung: redundant, aber von der Plattform konsistent gehalten — der Unterschied zu einem manuell kopierten Feld, das beim ersten Update auseinanderläuft.
Das nächste Schaubild zeigt die Entscheidung: wann normalisiert, wann kontrolliert denormalisiert.
3. Datentypen: jeder Kompromiss ist eine Hypothek
Wähle den engsten Datentyp, der die Anforderung erfüllt — die eine Regel, die in Sanierungen die meiste Arbeit spart und am häufigsten verletzt wird:
- Auswahl mit festen Werten ist Choice, kein Freitext. Freitext heißt „ja", „Ja", „JA ", „j" — und ein Reporting, das nichts mehr gruppiert.
- Geldbetrag ist Currency mit Währung, kein Decimal. Decimal verliert die Währung unwiederbringlich.
- Datum ist Date/DateTime, kein Text. Datum als Text zerstört jede Zeitauswertung und Sortierung.
- Ja/Nein ist Yes/No, kein String und kein Zwei-Werte-Choice.
- E-Mail/URL bekommen das passende Format, damit Validierung und Verlinkung greifen.
Der Schmerz kommt verzögert: Beim Modellieren spürst du nichts. Beim ersten Bericht, der ersten Integration, der ersten Migration zahlst du — mit Datenbereinigung obendrauf.
4. Beziehungen und ihr Verhalten — die unterschätzte Falle
Dataverse kennt 1:N, N:1 und N:N — die Art ist meist offensichtlich. Übersehen wird fast immer das Beziehungsverhalten (Cascade Behavior): Was passiert mit Kind-Datensätzen, wenn der Eltern-Datensatz gelöscht, neu zugewiesen oder geteilt wird?
Die Plattformstandards sind selten das, was du fachlich willst. „Cascade All" beim Löschen heißt: Wer einen Kunden löscht, löscht jedes verknüpfte Projekt, jede Aktivität, jede Notiz mit — einer der häufigsten Datenverluste in jungen Umgebungen, unsichtbar bis er passiert.
Die Praxisregel: Jede Beziehung mit bewusst gesetztem Verhalten anlegen, nie den Default durchwinken. Drei Fragen — Löschen? Neuzuweisen? Teilen? — fachlich begründet, nicht technisch geraten.
Bei N:N zusätzlich: Eine native N
5. Namenskonventionen und der Publisher-Präfix
Unsexy, aber projektprägend. Drei Regeln, die wir durchsetzen:
- Ein Publisher-Präfix, einmal festgelegt, nie geändert. Er steht vor jedem Tabellen- und Spaltennamen; ein nachträglicher Wechsel ist faktisch eine Neumodellierung.
- Anzeigename und Schemaname bewusst. Dataverse entfernt beim Schemanamen interne Unterstriche — was du als
hub_afa_methodeentwirfst, heißt in der APIhub_afamethode. Code dagegen ohne Schemaname-Prüfung baut Laufzeitfehler ein. - Konsistente Bezeichner. Singular oder Plural, Deutsch oder Englisch — egal welche Konvention, aber eine, durchgängig. Gemischte Konventionen sind für jeden neuen Entwickler ein Ratespiel.
6. Standardtabelle erweitern oder eigene bauen
Die Verlockung, alles in Account und Contact zu stopfen, ist groß. Die Faustregel ist einfach und wird trotzdem permanent verletzt:
- Eigenständiges fachliches Ding (Projekt, Asset, Vertrag) — eigene Tabelle.
- Eigenschaft eines bestehenden Dings (Branche eines Kunden, Position eines Kontakts) — Spalte an der Standardtabelle.
Jede Verletzung — ein eigenständiges Konzept als loses Feldbündel an Account — erschwert Auswertung, Berechtigung und Wiederverwendung. Berechtigung ist hier kein Nebenaspekt: Eine eigene Tabelle ist zeilengenau berechtigbar, ein Feldbündel an Account erbt die Account-Sicht. Mehr dazu: Security Roles in Dataverse.
Das nächste Schaubild zeigt die Entscheidung.
7. Globale vs. lokale Choices und Alternate Keys
Zwei Bausteine mit großer Hebelwirkung:
Choices: Wird ein Wertekatalog an mehr als einer Stelle gebraucht — Status, Priorität, Region — gehört er global, einmal definiert und überall referenziert. Sonst pflegst du dieselbe Liste fünfmal und sie driften auseinander. Ein wirklich tabellenspezifischer Choice bleibt lokal, sonst vermüllt der globale Namensraum.
Alternate Keys: Für jede Tabelle, in die von außen Daten eingespielt werden (Integration, Import, ERP-Sync), definierst du einen Alternate Key auf dem Fachschlüssel — Kundennummer, SKU, Belegnummer. Ohne ihn identifiziert jede Integration Datensätze über die GUID, die sie nicht kennt, und erzeugt Dubletten. Er entscheidet über saubere oder doppelte Datenbasis. Mehr dazu im Dataverse-Leitfaden und in Dataverse vs. SQL vs. SharePoint.
8. Die Modellierungs-Checkliste
Was wir vor jedem Go-Live durchgehen:
- Steht das Entitätenmodell, bevor der erste Screen gebaut wurde?
- Ist jedes Feld so eng typisiert wie fachlich möglich?
- Hat jede Beziehung ein bewusst gesetztes Cascade-Verhalten?
- Tragen N mit eigenen Daten eine echte Zwischentabelle?
- Ist der Publisher-Präfix einmal festgelegt und die Benennung durchgängig?
- Sind wiederverwendete Wertelisten global, einmalige lokal?
- Hat jede integrationsrelevante Tabelle einen Alternate Key?
Wird auch nur ein Punkt mit „nein" beantwortet, wird er vor dem Go-Live korrigiert — nicht „später". Jetzt fast kostenlos, mit Produktivdaten teuer.
Fazit
Gute Dataverse-Modellierung ist unspektakulär: enge Datentypen, bewusste Beziehungsverhalten, eigene Tabellen für eigenständige Konzepte, globale Choices für wiederverwendete Listen, ein Alternate Key für jede Integration. Nichts davon ist schwierig — alles wird unter Zeitdruck übersprungen.
Die ehrliche Wahrheit: Fast jedes „das machen wir später sauber" wird nie sauber gemacht und kostet am Ende ein Vielfaches. Die Stunde sauberer Modellierung am Anfang ist die billigste im ganzen Projekt.
Quellen
- Microsoft Learn — Spaltentypen (Datentypen) in Dataverse
- Microsoft Learn — Kaskadierungsverhalten von Tabellenbeziehungen
- Microsoft Learn — Mit alternativen Schlüsseln arbeiten
- Microsoft Learn — Tabellendefinitionen: Schema- und logischer Name
- Microsoft Learn — Dataverse-Standards und Namenskonventionen (Publisher-Präfix)
- Erfahrungswerte aus Dataverse-Projekten (Medienstürmer)
