Das Problem: Warum nicht einfach Excel?
Viele Unternehmen verwalten ihre Daten in Excel-Tabellen. Das funktioniert bei kleinen Datenmengen, führt aber schnell zu Problemen:
| Auftrag | Kunde | Adresse | Betrag |
|---|---|---|---|
| A-001 | Müller GmbH | Hauptstr. 5, Berlin | 1.200 € |
| A-002 | Müller GmbH | Hauptstr. 5, Berlin | 3.500 € |
| A-003 | Müller GmbH | Hauptstr. 5, Berlin | 800 € |
| A-004 | Schmidt AG | Parkweg 12, München | 2.100 € |
Die Adresse der Müller GmbH steht 3x — bei Adressänderung müssen alle geändert werden!
| Nr. | Kundenname | Adresse |
|---|---|---|
| K-01 | Müller GmbH | Hauptstr. 5, Berlin |
| K-02 | Schmidt AG | Parkweg 12, München |
| Auftrag | Kunde | Betrag |
|---|---|---|
| A-001 | → K-01 | 1.200 € |
| A-002 | → K-01 | 3.500 € |
| A-003 | → K-01 | 800 € |
Adresse steht nur 1x — Änderung an einer Stelle reicht!
Das Prinzip heißt: Daten aufteilen und verknüpfen. Jede Information wird nur einmal gespeichert. Statt Kundendaten in jedem Auftrag zu wiederholen, verweist der Auftrag auf den Kunden — über eine Nummer.
Die Lösung: Karteikästen statt Excel-Chaos
KARTEIKASTEN "Kunden" KARTEIKASTEN "Aufträge"
________________________ ________________________
| | | |
| Nr.: K-0042 | | Nr.: A-2026-0015 |
| ____________________ | | ____________________ |
| | | |
| Firma: Müller GmbH | .----| Kunde: K-0042 -------.
| Name: Hans Müller | | | ____________________ |
| E-Mail: hm@mueller.de | | | |
| Tel.: 030-12345 | | | Bezeichnung: Server |
| Ort: Berlin | | | Status: In Bearb. |
| Str.: Hauptstr. 5 | | | Fällig: 15.04.2026 |
|________________________| | | Betrag: 4.500 EUR |
| |________________________|
|
"Der Auftrag VERWEIST | VERWEIS = Der Auftrag
auf Kundenkarte K-0042" ---' schaut in den Kunden-
kasten nach
Zwei Karteikästen mit einem Verweis: Der Auftrag „kennt“ seinen Kunden über die Kundennummer.
Das ist die Grundidee: Getrennte Karteikästen für verschiedene Dinge (Kunden, Aufträge, Produkte), die über Verweise miteinander verbunden sind.
Die wichtigsten Begriffe — einfach erklärt
In UDM und in der Datenwelt gibt es einige Grundbegriffe. Hier sind sie mit Alltagsvergleichen erklärt:
| Begriff | Was es ist | Alltagsvergleich |
|---|---|---|
| Tabelle | Eine Sammlung gleichartiger Daten | Ein Karteikasten (z. B. „Kunden“) |
| Datensatz | Ein einzelner Eintrag in einer Tabelle | Eine einzelne Karteikarte |
| Feld / Spalte | Eine bestimmte Information innerhalb eines Datensatzes | Eine Beschriftung auf der Karteikarte (z. B. „Firmenname“) |
| Verweis (Beziehung) | Eine Verknüpfung zwischen zwei Tabellen | „Siehe Karteikarte Nr. 42 im Kundenkasten“ |
| Eindeutige Nummer (ID) | Eine Kennung, die jeden Datensatz einzigartig macht | Die Personalnummer — keine zwei Personen haben dieselbe |
Beziehungen: „Wer gehört zu wem?“
Die wichtigste Art von Verknüpfung in Geschäftsdaten ist die 1-zu-viele-Beziehung (kurz: 1:n). Das bedeutet:
+-----------------+ +------------------+
| | | |
| KUNDEN | | AUFTRÄGE |
| | | |
| K-0042 |<---------| Kunde: K-0042 | Auftrag A-001
| Müller GmbH |<---------| Kunde: K-0042 | Auftrag A-002
| |<---------| Kunde: K-0042 | Auftrag A-003
| | | |
+-----------------+ +------------------+
1 : viele
"Ein Kunde kann mehrere Aufträge haben."
"Jeder Auftrag gehört zu genau einem Kunden."
1-zu-viele-Beziehung: Ein Kunde, mehrere Aufträge.
Warum ist das wichtig? Weil Sie in UDM später genau solche Fragen stellen werden:
- „Zeige mir alle Aufträge von Kunde Müller“
- „Wie viele Aufträge hat dieser Kunde insgesamt?“
- „Was ist der Gesamtumsatz dieses Kunden?“
Das funktioniert nur, wenn die Beziehung zwischen Kunden und Aufträgen sauber eingerichtet ist.
Beziehungen können auch über mehrere Stufen gehen
In unserem Beispiel kommen später noch Auftragspositionen dazu. Dann entsteht eine Kette:
KUNDEN AUFTRÄGE POSITIONEN
+-----------+ +-----------+ +-----------+
| Müller |<----| Auftrag 1 |<-----| Pos. 1 |
| GmbH | | |<-----| Pos. 2 |
| | | |<-----| Pos. 3 |
+-----------+ +-----------+ +-----------+
+-----------+ +-----------+
| Auftrag 2 |<-----| Pos. 1 |
| |<-----| Pos. 2 |
+-----------+ +-----------+
"Ein Kunde hat viele Aufträge.
Ein Auftrag hat viele Positionen."
Verkettete Beziehungen: Kunde → Aufträge → Positionen.
Datentypen: „Was darf in dieses Feld?“
Jedes Feld auf einer Karteikarte hat einen bestimmten Typ — es legt fest, welche Art von Information dort hineinpasst. Das kennen Sie aus dem Alltag: In ein Datumsfeld schreiben Sie kein Wort, und in ein Namensfeld keine Zahl.
| Datentyp | Was hineinpasst | Beispielfelder |
|---|---|---|
| Text | Buchstaben, Zahlen, Sonderzeichen — beliebige Eingabe | Firmenname, E-Mail, Straße, Beschreibung |
| Zahl | Ganze Zahlen oder Dezimalzahlen | Menge, Einzelpreis, Gesamtbetrag |
| Datum | Ein Kalenderdatum, optional mit Uhrzeit | Erstellt am, Fällig am, Geburtstag |
| Ja/Nein | Nur zwei Zustände: an oder aus | Aktiv?, Bezahlt?, Freigegeben? |
| Auswahlliste | Ein Wert aus einer vordefinierten Liste | Status (Offen / In Bearbeitung / Erledigt), Priorität (Niedrig / Normal / Hoch) |
| Verweis | Zeigt auf einen Datensatz in einer anderen Tabelle | „Welcher Kunde?“, „Welcher Auftrag?“ |
Unser Datenmodell: Die Basis für das Tutorial
Für unser Beispiel „Auftragsmanagement“ starten wir mit zwei Tabellen. Im Laufe des Tutorials kommen weitere hinzu:
KUNDEN AUFTRÄGE
============================== ==============================
Kundennr Text (autom.) Auftragsnr Text (autom.)
Firmenname Text (Pflicht) Bezeichnung Text (Pflicht)
Ansprechp. Text Status Auswahlliste
E-Mail Text Erstellt am Datum (autom.)
Telefon Text Fällig am Datum
PLZ Text Gesamtbetrag Zahl
Ort Text ...............................
Strasse Text Kunde Verweis → KUNDEN
Zugewiesen an Text
1 : viele
|___________________________________|
"Ein Kunde kann beliebig viele Aufträge haben."
Das Startmodell für Stufe 1: Kunden und Aufträge mit ihren Feldern.
Dieses Modell wird im Laufe des Tutorials wachsen:
| Stufe | Neue Tabellen | Warum |
|---|---|---|
| Stufe 1 | Kunden, Aufträge | Die Basisdaten unserer App |
| Stufe 2 | Positionen, Status-Historie | Detaildaten und Nachverfolgung |
| Stufe 4 | Tickets, Ticket-Kommentare | Die zweite App nutzt die gleichen Kunden |
Das UDM-Prinzip: Von Daten zur App
Jetzt wissen Sie, wie Daten strukturiert werden. Aber wie wird daraus eine Anwendung? Hier kommt UDM ins Spiel:
IHRE DATEN UDM-KONFIGURATION FERTIGE APP
============ ================= ============
+----------+ +---------------+ +----------+
| Kunden | ------> | Welche Felder | ------> | Kunden- |
| Aufträge | | anzeigen? | | liste |
| Positio- | | | | |
| nen | | Wer darf was? | | Auftrags-|
| ... | | | | formular |
+----------+ | Was passiert | | |
| bei Klick? | | Dash- |
Sie haben | | | board |
Datenbanken | Wie sieht das | | |
mit Tabellen | Dashboard | | ... |
| aus? | +----------+
+---------------+
Ihre Benutzer
Sie konfigurieren arbeiten mit
im Admin Client der fertigen App
UDM macht aus Ihren Daten eine App — Sie konfigurieren, was angezeigt wird und wer was tun darf.
Das Besondere an UDM: Sie programmieren nicht — Sie konfigurieren. Statt Code zu schreiben, legen Sie im Admin Client fest:
- Was wird gespeichert? → Entities (Datenobjekte) mit Feldern
- Was wird angezeigt? → Ansichten (Listen, Diagramme, Dashboards)
- Wie wird bearbeitet? → Formulare mit Validierung
- Wer darf was? → Rollen und Berechtigungen
- Was passiert automatisch? → Aktionen und Hintergrund-Jobs
In UDM ist das als 5-Schichten-Modell organisiert:
.---------------------------------------------------. | SCHICHT 5: APP | | "Was sieht der Benutzer?" | | Menüstruktur, Navigation, Berechtigungen | |---------------------------------------------------| | SCHICHT 4: ANSICHT & FORMULAR | | "Wie werden Daten dargestellt und bearbeitet?" | | Listen, Charts, Dashboards, Dialoge | |---------------------------------------------------| | SCHICHT 3: DATENABFRAGE | | "Welche Daten sollen angezeigt werden?" | | Filter, Verknüpfungen, berechnete Felder | |---------------------------------------------------| | SCHICHT 2: DATENOBJEKT | | "Was wird gespeichert?" | | Felder, Datentypen, Beziehungen | |---------------------------------------------------| | SCHICHT 1: SYSTEMANBINDUNG | | "Wo liegen die Daten?" | | Datenbankverbindung, Datenbereich | '---------------------------------------------------'
Die 5 Schichten von UDM — von der Datenbank bis zur fertigen App.
- Warum man Daten aufteilt statt alles in eine Tabelle zu packen
- Was Tabellen, Datensätze, Felder und Verweise sind
- Wie 1-zu-viele-Beziehungen funktionieren (Kunde → Aufträge)
- Welche Datentypen es gibt (Text, Zahl, Datum, Ja/Nein, Auswahlliste, Verweis)
- Wie UDM aus Daten und Konfiguration eine App macht