Datenbankmodellierung

[Asura]

Guten Abend,

ich habe mich mal wieder weiter an mein hobbymäßiges Projekt eines Finanzcheckprogramms gesetzt und weiter an der Datenbankmodellierung gearbeitet.

Ich bin leider was Datenbank angeht noch absoluter Anfänger, weshalb ich mir natürlich nicht zu 100 % sicher sein kann, was

• Unabhängigkeit
• Konsistenz
• Integrität

angeht. Deswegen bitte ich hier einfach mal rüber zu schauen und eventuell Kritik, Verbesserungsvorschläge zu nennen.
Wenn Fragen zur Funktion gewisser Attribute auftreten, werde ich diese hier beantworten.

Würde mich da über eine Überprüfung freuen!

[TigerLilly]

Inhaltlich sage ich nichts, da weiß ich natürlich über dein Projekt zu wenig.Aber allgemein:

Das Password würde ich nicht in der DB speichern, sondern nur den Hash dazu.

Vielleicht wäre es eine Idee, nicht den IBAN abzulegen, sondern noch eine Tabelle Banken zu machen + zu verlinken. Dann kannst du auch den BIC + den Namen der Bank ablegen.

Die Kategorien würde ich eher als Mainkategorien --> Subkategorien --> Kategorien ablegen, aber vielleicht gibt es für deinen Ansatz einen besonderen Grund. Jetzt spießt sich das etwas.

Ich benenne den PK einer Tabelle immer als <Tabellenname>ID, denn heißen die FKs und die PKs gleich. Jedenfalls aber sollten die FKs die referenzierte Tabelle wiedergeben (BankAccountsID vs BankID als FK zu bankaccounts.ID).

Ich bin auch etwas neurotisch, was durchgängige Namensgebung anbelangt: "users" ist Mehrzahl, das ist gut + passend, "senderreceiver" ist Einzahl, das würde ich auch als "senderreceivers" benennen.

Reservierte Bezeichner sind immer problematisch, darum würde ich "Type" nicht nehmen, sondern "TypeFixed", ebenso "Date". Generell bevorzuge ich Bezeichner, die mir sagen, was das Attribut beinhaltet + Type ist sehr nichtssagend. Ich würde auch abgekürzte Bezeichner (Evalu) vermeiden.

HTH :thumb:

[mkinzler]

Der Plural von Receiver ist Receiver

[mjustin]

Für Tabellennamen bevorzuge ich Singular statt Plural. Zum Beispiel "Status" anstatt "Statuses", Category anstatt Categories, unabhängig davon ob die Tabelle einen oder viele Datensätze enthalten kann. Vergleiche AppleBag: auch wenn mehrere Äpfel darin sind, ist es kein ApplesBag. Tabellen sind ähnlich, Container.

Bei der Benennung der Felder würde ich auch an die Erstellung und Wartung des Codes denken und da spielt die eindeutige Benennung eine Rolle. BankAccountsID sowohl in der Tabelle Account als auch in den verknüpften Tabellen wäre bei einer Suche im Sourcecode oder den Datenbankmetadaten nicht so eindeutig wie FKBankAccountsID. Bei Foreignkeys verwende ich FK_TABELLENNAME (anstatt den Namen des PK der referenzierten Tabelle), das ist bei der Suche leichter zu finden.

Über die Pluralbildung von "fixed" könnte man nachdenken :)

[TigerLilly]

Zitat:

Zitat von mkinzler (Beitrag 1399041)

Der Plural von Receiver ist Receiver

https://www.dict.cc/deutsch-englisch...C3%A4nger.html
https://en.wiktionary.org/wiki/receiver

Aber im Grunde ging es mir um die Einheitlichkeit: immer Einzahl oder immer Mehrzahl. beides lässt sich gut argumentieren.

[mkinzler]

https://de.wiktionary.org/wiki/Receiver :?

[TigerLilly]

Zitat:

Zitat von mkinzler (Beitrag 1399044)

https://de.wiktionary.org/wiki/Receiver :?

Die Mehrzahl von "Receiver" in Deutsch(!) ist Receiver, da hast du recht. Die Mehrzahl von "receiver" in Englisch - und das DB-Modell ist in Englisch - ist "Receivers".

[StepByStep]

Moin!

Zum Thema IBAN: Da schließe ich mich TigerLilly in etwa an, aber eine Banktabelle hast du quasi schon mit "bankaccounts". Du hast jetzt zwei Tabellen mit dem Feld "IBAN", was ein wenig Unglücklich hinsichtlich des Themas Redundanz ist. Du könntest du das Feld in "senderreceiver" entfernen, da du es über senderreceiver -> users -> bankaccounts bekommst.

Passwörter IMMER hashen! Niemals als Klartext abspeichern...

Möge man mich korrigieren, aber mMn müsste die "categorie"-Geschichte folgender Maßen sein:

Tabelle "maincategories" = ID, UserID, Name
Tabelle "categories" = ID, BookType, Costtype, MainCatID
Tabelle "subcategories" = ID, UserID, Name, CatgID, MainCatID

Du hast es ja hierarchisch aufgebaut.

Dann nochmal Namensgebung: Wenn du FK-Felder hast, dann kürze sie nicht ab. Aus MainCatID wird dann maincategoriesID beispielsweise. Aber auch Punkte wie Singular - Plural... Ich tendiere da immer zu Singular, auf jeden Fall einheitlich.

Braucht "bookings" keine User-Referenz? Es wäre zudem auch mal hilfreich, wenn man die Beziehungen abgebildet werden, daraus lässt sich auch immmer auf die Sinnhaftigkeit eines DB-Modells schließen. ;-)

Das sind erstmal meine Gedanken dazu.

LG

[Codehunter]

Zitat:

Zitat von mjustin (Beitrag 1399042)

Für Tabellennamen bevorzuge ich Singular statt Plural. Zum Beispiel "Status" anstatt "Statuses", Category anstatt Categories, unabhängig davon ob die Tabelle einen oder viele Datensätze enthalten kann.

Moah wie wahr! Das habe ich bei xtcommerce immer gehasst. Da gibt es Tabellen wie "categories", "products" usw. Und um dem ganzen dann noch die Krone auf zu setzen, gab es Felder wie "categories_id", "products_id" usw.

Bzgl. IBAN: Ich kenne das von diversen WaWi eigentlich genau so, wie hier im DB-Modell auch gelöst: Man hat eine Bankkonten-Referenztabelle, wo die Konten der Kunden hinterlegt sind. Am konkreten Beleg kann man dann aber die IBAN übersteuern. Heißt, das Eingabe-Feld wird aus der Bankkontentabelle vorbelegt, Änderungen des Anwenders aber dann in einem zweiten IBAN-Feld in der Belegtabelle gespeichert. Vielleicht war das ja hier auch so gedacht?

Bzgl. Kategorien: Dafür würde ich nur EINE Tabelle vorsehen und hierarchische Strukturen über zwei Felder "id" und "parent_id" abbilden. Das wiederum ist bei xtcommerce sehr schön gelöst.

[StepByStep]

Zitat:

Vielleicht war das ja hier auch so gedacht?

>> Stimmt, könnte man so natürlich denken. Bei unserem WaWi-Programm, gäbe es dann aber ein Stammdatenformular für Bankverbindungen. Hast du eine andere IBAN wäre das dann ein neuer Satz. Die IBAN ist ja immer eindeutig...

Zitat:

Dafür würde ich nur EINE Tabelle vorsehen und hierarchische Strukturen über zwei Felder "id" und "parent_id" abbilden. Das wiederum ist bei xtcommerce sehr schön gelöst.

>> Ich sage da nur ein Stichwort: Normalisierung.

LG

[mkinzler]

Und bei 10 Hierarchie-Ebenen dann 10 Tabellen?
Ich würde es auch mit einet Tabelle lösen.

[StepByStep]

Ja, bei 10 Hierarchie-Ebenen dann 10 Tabellen. Es ist doch auch in Bezug auf Abfragen viel effizienter/performanter schmalere Tabellen zu haben, statt einer riesigen, mal davon ab, dass man somit keine Normalisierung erreicht. Aber eben diese sollte man doch anstreben oder irre ich mich?

Die Berufsschule ist knapp ein Jahr her, aber ich bin ziemlich sicher, dass das dort vermittelt wird und überall sonst auch angestrebt wird.

LG

[Codehunter]

Zitat:

Zitat von mkinzler (Beitrag 1399067)

Und bei 10 Hierarchie-Ebenen dann 10 Tabellen?
Ich würde es auch mit einet Tabelle lösen.

Kommt ja immer auf den konkreten Fall an. Mir sagt halt meine praktische Erfahrung, dass starre hierarchische Strukturen von den meisten Anwendern als negativ empfunden werden. Man stelle sich einen Webshop vor, der eine starre Verzweigungstiefe hätte. In manchen Kategorien lägen dann Berge von Artikeln, in anderen nur einer oder zwei. Wenn die Kategorien funktional identisch und ihre Unterschiede über Attribute darstellbar sind, würde ich sie in einer Tabelle unterbringen, wie vormals geschrieben. Unterscheiden sie sich jedoch funktional stark und gibt es keine sinnvolle abweichende Verzweigungstiefe, dann kann man das auch mit drei Tabellen lösen.

EDIT/Nachtrag:

Zitat:

Zitat von StepByStep (Beitrag 1399070)

Ja, bei 10 Hierarchie-Ebenen dann 10 Tabellen. Es ist doch auch in Bezug auf Abfragen viel effizienter/performanter schmalere Tabellen zu haben, statt einer riesigen, mal davon ab, dass man somit keine Normalisierung erreicht. Aber eben diese sollte man doch anstreben oder irre ich mich?

Die Berufsschule ist knapp ein Jahr her, aber ich bin ziemlich sicher, dass das dort vermittelt wird und überall sonst auch angestrebt wird.

Theorie und Praxis eben. Kann der Anwender Kategoriestrukturen dynamisch selbst erstellen, deshalb mein Beispiel Webshop, dann müsstest du auch die Tabellen dynamisch erstellen. Das wird IMHO recht aufwendig und fehleranfällig, spätestens bei Programmupdates.

[mkinzler]

Oder in einer. Da ja die Hierarchie Teil der Tabelle ist. Im Nornallfall unterscheiden sich die Metadaten der Haupt-/Unter-/Unter-Unterkategorien ja nicht. Die oberste Ebene hat dann halt keine Parent.

[StepByStep]

Zitat:

Die oberste Ebene hat dann halt keine Parent.

>> Dann hast du eine Spalte die nur in 2 von 3 Fällen gefüllt ist? Ist das konsistent?

EDIT:

Zitat:

deshalb mein Beispiel Webshop

Aber in deinem Beispiel wäre es sowieso sinnvoller eine Artikeltabelle zu erstellen und darin eine Referenzspalte zu Kategorien einzubauen.

[Codehunter]

Zumal im Bereich von Buchhaltung und Warenwirtschaften die GoBD sowieso die Normalisierung ein Stück weit gekillt hat :roll:

@StepByStep: Bzgl. Normalisierung und Performance, da kann der Schuss auch nach hinten los gehen. Ich empfehle die letzten beiden Absätze auf dieser Seite.

EDIT:

Zitat:

Zitat von StepByStep (Beitrag 1399078)

Zitat:

deshalb mein Beispiel Webshop

Aber in deinem Beispiel wäre es sowieso sinnvoller eine Artikeltabelle zu erstellen und darin eine Referenzspalte zu Kategorien einzubauen.

Also bitte.... Wo ist denn da die dritte Normalform? 8-) Da wird bei den Artikeln eine Artikelnummer, bei den Kategorien eine Kategorienummer und dann in einer Verknüpfungstabelle beides zusammen geführt. Nur so kannst du einen Artikel in mehrere Kategorien legen.

[mkinzler]

Warum nicht. Ist bei den anderen Tabellen gibt es ja auch hin und wieder Felder die nicht gefüllt sind.
So wäre es auch einfacher aus einer Haupt- eine Subkategorie zu machen oder umgekehrt oder die übergeordnete zu ändern.

[mkinzler]

Ich sehe auch nicht, warum dies der Normalisierung widersprechen sollte. Diese fordert ja nur eine Abhängigkeit von den Nichtschlüsselfeldern vom (Primär)Schlüssel. ParentID ist ja aber ein (Fremd-)schlüssel.

[StepByStep]

Zitat:

Also bitte.... Wo ist denn da die dritte Normalform? Da wird bei den Artikeln eine Artikelnummer, bei den Kategorien eine Kategorienummer und dann in einer Verknüpfungstabelle beides zusammen geführt. Nur so kannst du einen Artikel in mehrere Kategorien legen.

>> Verzeih, da hast du natürlich vollkommen Recht! Mein Fehler. :oops:

Zitat:

Zudem verlangsamt es die Abfragegeschwindigkeit, da die Tabellen erst mithilfe von Joins verknüpft werden müssen

>> Also ich möchte meinen, dass Joins über Tabellen schneller gehen, als ein Select über eine Tabelle mit etlichen Massendaten. Vor allem wenn du dann noch sinnvolle Indizes angelegt hast.

Zitat:

Warum nicht. Ist bei den anderen Tabellen gibt es ja auch hin und wieder Felder die nicht gefüllt sind.
So wäre es auch einfacher aus einer Haupt- eine Subkategorie zu machen oder umgekehrt oder die übergeordnete zu ändern.

>> Mag sein, aber du hättest dann eine riesige Tabelle mit zig Daten. Das kann doch nicht gut sein. Und durch eine Tabelle trennst du ja nicht Nicht-Schlüsselfelder. Dann hättest du Name für Subkategorien und Name für Hauptkategorien...

LG

[mkinzler]

Zitat:

>> Also ich möchte meinen, dass Joins über Tabellen schneller gehen, als ein Select über eine Tabelle mit etlichen Massendaten. Vor allem wenn du dann noch sinnvolle Indizes angelegt hast.

Joins ist Joins, ob nun verschiedene Tabellen oder mehfach die selbe gejoint wird. Ausserdem ist ja die Frage, warum überhaupt gejoint werden muss.

Zitat:

>> Mag sein, aber du hättest dann eine riesige Tabelle mit zig Daten. Das kann doch nicht gut sein. Und durch eine Tabelle trennst du ja nicht Nicht-Schlüsselfelder. Dann hättest du Name für Subkategorien und Name für Hauptkategorien...

Ist das bei einer Adressen- oder Rechnungspositionentabelle anders? Da hat man auch viele verschiedene Daten beinhalten.

[StepByStep]

Das ist wohl richtig, aber das sind im Regelfall doch auch Daten, die sich eben nicht weiter Normalisieren lassen.

[mkinzler]

Wenn Du mehrere Tabellen für das gleiche anlegst würde ich auch nicht von Normalisierung reden. Kaetegorien sind Kategorien, ob sie nun Haupt- oder Unterkategorien sind.

[StepByStep]

Ich hatte auch mehr etwas im Kopf wie: Auftrag (Hauptkategorie), Auftragsposition (Kategorie), Auftragsunterposition (Unterkategorie). So wäre es nach seinem Beispiel, zumindest für mich.

[mkinzler]

Auftragspositionen und Auftragsunterpositionen sind eigentlich das gleiche, der Fremdschlüssel steuert dies ja.
Aufträge sind natürlich etwas komplett anderes.

Ich würde eher eine Tabelle für Aufträge, Lieferscheine, Rechnungen usw. verwenden und eine für die Positionen.

[StepByStep]

Hm... ich finde den Ansatz wirklich interessant. Nun kenne ich auch noch nicht so viele... Bei uns haben wir das alles ausgelagert in eigene Tabellen, um eben alles zu trennen. Käme alles in eine Tabelle würdest du dann einen Typen einfügen? Muss ja, sonst kann man das nicht unterscheiden, um was für einen Belegtypen es sich handelt. Und darauf dann einen Index... Klar geht das, aber habe noch nicht so ganz verstanden warum? Was macht das "besser" als es zu trennen, bzw. zu normalisieren?

Aber wir driften auch weiter vom Ursprungsthema ab.

LG

[jobo]

Zitat:

Zitat von StepByStep (Beitrag 1399101)

Aber wir driften auch weiter vom Ursprungsthema ab.

Bei einer Modellierungsfrage finde ich die Diskussion hier nicht wirklich abgedriftet.
Und das Modell des TE finde ich bezüglich der Kategorien nicht sehr klar.

Ich sehe das so wie mkinzler und codehunter, ein Parentverweis für eine hierarchische Kategorisierung ist idR naheliegend und kein Normalformverstoß. Selbst wenn er das wäre, sowas wäre auch nicht selten und m.E. nicht per se strafbar. Frage wäre immer, welche Vor und Nachteile aus bestimmten Verfahren entstehen.
10 Tabellen für verschiedene Ebenen halte ich dagegen schon für fragwürdig.
Wer oder was auch immer einen solchen Kategorieverweis bei sich trägt, ist per Model darauf festgenagelt. Also quasi wie in einem Kastensystem, frühstens nach Tod und Wiedergeburt gibt's einen anderen Level. Nicht sehr flexibel.

Was die Performanceaspekte angeht:
Performanceprobleme kann es immer geben, natürlich gern wenn Tabellen sehr groß werden. In solchen Fällen kann man über Denormalisierung nachdenken, aber immer zuletzt. Gute Indizierung, geeignete Datenbanken mit smarter Implementierung und intelligenter Abfragesyntax wären da für mich naheliegender.

[StepByStep]

Zitat:

Und das Modell des TE finde ich bezüglich der Kategorien nicht sehr klar.

>> Das finde ich auch, je mehr ich darüber nachdenke.

Ich stehe momentan wirklich auf dem Schlauch... Es ist mir erklärlich, weshalb ich alles in eine Tabelle packen sollte. Die würde dann ja irgendwie so aussehen:

Kategorie

ID

BookType

Costtype

Sub_Name

Main_Name

Parent

Child

Sowohl Parent als auch Child würden dann NULL-Werte enthalten, was für Abfragen doch absolut unsinnig wäre. Man bräuchte dann ja mindestens noch einen Typen um festzulegen ob es eine Main-, Kategorie oder Subkategorie ist. Dann würde es wieder gehen... Aber hübsch ist das doch niemals.

LG

[mkinzler]

Zitat:

Käme alles in eine Tabelle würdest du dann einen Typen einfügen? Muss ja, sonst kann man das nicht unterscheiden, um was für einen Belegtypen es sich handelt.

Eigene Tabelle und FK in Tabelle für die Belege.

Zitat:

Was macht das "besser" als es zu trennen, bzw. zu normalisieren?

Es ist flexibler.

Und Warum sollte eine System mit den Tabellen
'Order', 'DeliveryNote', 'Invoice', ..., 'OrderPosition', 'DeliveryPosition', 'InvoicePosition', ...

normalisierter sein als ein System mit den Tabellen 'ReceiptType', 'Receipe', 'Position'?

Wenn jetzt später ein neuer Belegtyp z.B. Bearbeitungslaufzettel benötigt wird musst du im 1. Fall das komplette Modell erweitern und auch das Programm anpassen; im 2. Fall wird einfach ein neuer Datensatz in 'ReceiptType' eingefügt.

[mkinzler]

Zitat:

Zitat von StepByStep (Beitrag 1399109)

Zitat:

Und das Modell des TE finde ich bezüglich der Kategorien nicht sehr klar.

Kategorie

ID

BookType

Costtype

Sub_Name

Main_Name

Parent

Child

Sowohl Parent als auch Child würden dann NULL-Werte enthalten, was für Abfragen doch absolut unsinnig wäre. Man bräuchte dann ja mindestens noch einen Typen um festzulegen ob es eine Main-, Kategorie oder Subkategorie ist. Dann würde es wieder gehen... Aber hübsch ist das doch niemals.

LG

"Main_Name" und "Child" sind in diesem Fall überhaupt nicht notwendig, da redundant. "Sub_name" besser "Name".

[StepByStep]

Zitat:

Wenn jetzt später ein neuer Belegtyp z.B. Bearbeitungslaufzettel benötigt wird musst du im 1. Fall das komplette Modell erweitern und auch das Programm anpassen; im 2. Fall wird einfach ein neuer Datensatz in 'ReceiptType' eingefügt.

>> Das ist mir schon klar. Beide Varianten gehen, die Wartbarkeit der Ersten ist natürlich höher, aber dafür hat man keine aufgeblähten Tabellen. Ich glaube das ist eine persönlich Ansicht darauf: Entweder höherer Wartungsaufwand und schlankere Tabellen oder eben andersrum. Kann das sein? Einen anderen signifikanten Unterschied gibt es ja nicht, bis auf eventuell noch Performance.

Zitat:

"Main_Name" und "Child" sind in diesem Fall überhaupt nicht notwendig, da redundant. "Sub_name" besser "Name".

>> Aber ich lege doch alle drei Kategorietabellen übereinander und da es einen Namen in Sub und Main gibt, brauche ich beide doch wieder. Andernfalls würde es ja bedeuten, dass eine der beiden Tabellen entfällt. Und warum will ich kein Child? Innerhalb dieser drei Ebenen muss ich doch auch zurück referenzieren können.

LG

[mkinzler]

Der Main_Name ist ja der Name des Parent. Natürlich kann man beides doppelt führen, damit schafft man sich mehr Probleme.

[StepByStep]

Zitat:

Der Main_Name ist ja der Name des Parent. Natürlich kann man beides doppelt führen, damit schafft man sich mehr Probleme.

>> Damit hast du natürlich vollkommen recht... Ich glaube so langsam verstehe ich euch. :)

[Jumpy]

Was man evtl. überlegen könnte hinzuzunehmen wäre dann ein Feld für den Typ oder den Level (im Sinne der Tiefe in einer Baumstruktur). Dies ist nicht zwingend nötig, über die Parents läßt sich das auch ermitteln, aber es erleichtert einem ggf. die Abfragen.

[mkinzler]

Kann aber wieder zu Inkonsistenzen führen.

[Jumpy]

Das ist halt das ewige Dilemma (nicht nur in der IT). Komfort, Bequemlichkeit auf der einen Seite führt zu Risiken, Gefahren auf der anderen Seite. Wenn man so will die Unschärfe-Relation des normalen Lebens gewürzt mit einer Prise Murphy :-D.

[mkinzler]

Deshalb gibt es in diesem Punkt kein richtig oder falsch.

[jobo]

Zitat:

Zitat von mkinzler (Beitrag 1399125)

Kann aber wieder zu Inkonsistenzen führen.

Zitat:

Zitat von Jumpy (Beitrag 1399130)

Das ist halt das ewige Dilemma

Zitat:

Zitat von mkinzler (Beitrag 1399131)

Deshalb gibt es in diesem Punkt kein richtig oder falsch.

Ich würde da sanft widersprechen. Es ist ein Dilemma, ja, besonders für Entwickler, die haarklein die Detailprobleme in den Griff kriegen müssen. Aber es ist auch eine Frage der Prios und letztlich der Entwicklungskosten/Budget.
Inkonsistenzen sind aber kein Schicksal. Man muss darauf achten, dass keine entstehen (haha). Ja klingt banal doof, aber mit Hilfe moderner Datenbanktechnik, Constraints, Triggern, .. kann man das machen. Bei der (bewussten) Entscheidung, etwas denormalisiert zu speichern, muss man die entstehenden Redundanzen eben auch bewusst absichern mit den geeigneten DB Hilfsmitteln. Soviel Zeit (und Geld) muss sein, ist sicher gut investiert.

[Codehunter]

Ich glaube wir haben den/die Threadersteller/in irgendwie erschlagen. Hat sich nicht einmal mehr zu Wort gemeldet :shock:

[MyRealName]

Ich kenne mich mit deutschem accounting nicht aus, aber hier in Kolumbien ist das mit dem Bank-Accounts nur ein Teil der accounts, die man hat. Hier gibt es den PUC (Plan Unico de Cuentas), wo man zu 8-stelligen Account-Nummern Sachen zuordnet, zum Bsp. MwSt noch zu zahlen. Oder offene Rechnungen. Das sind nicht direkt Bank-Accounts, sondern nur identifikatoren um es in Deinem System auseinander zu halten.

Das sieht eher so aus.
Da gibt es dann diverse Vorgaben wie 1 im Title ist immer Activos wie Waren im Lager. 13 in Grupo (Gruppe) sind Schulden, 11 sind Bankkonten. 14 ist das Inventar. Etc.

[Codehunter]

Das würde hier jetzt jeden Rahmen sprengen, die deutsche Buchhaltung zu erklären ^^ Sagen wir mal so: Wo bei euch eine Schraube eingedreht wird, da wird bei uns erstmal eine Maschinenkonstruktionszeichnung für die Maschine zur Schraubenherstellung angefertigt :oops: