Einfaches Datenbankmodell

[Delbor]

Hi TigerLilly
Danke für deine Antwort! Sehr umfassend!

Zitat von TigerLilly:

Vielleicht zurück zum Anliegen des TE. Ergänzend zu noch nicht Gesagtem:

Allgemein:
* Die Tabellen alle mit TBL_ beginnen zu lassen ist überflüssig.
* Ich bevorzuge es, die IDs (=PKs) mit dem Tabellennamen zu benennen. So wie du es bei Tbl_User gemacht hast (Tbl_USer -> UserID), aber bei den anderen nicht (Tbl_Konto -> ID)
* Die IDs einmal mit und einmal ohne _ zu bennen ist nicht gut. Adress_ID und UserID ist eine ziemliche Fehlerquelle.
* Ich würde nicht mit den Standarddatentypen arbeiten, sondern UDDT, also selbst definierte Typen, verwenden + allen Feldern, die gleichen Typ haben, diesen zuordnen. Also statt FLOAT bei Beträgen würde ich einen UDDT "Betrag" vom Typ Float zwischenschalten. Diesen ev. mit Default oder not null etc aufpeppen. Das macht es dann zB leichter alle Telefonnummern zu verlängern, weil du nur einmal den UDDT ändern musst.
* Mach dich über den Unterschied zwischen VARCHAR und NVARCHAR schlau.
* INT INTEGER DEC FLOAT ist ein ziemliches Typgemisch - siehe vorher UDDT.
* "Text" als Feldname ist unglücklich, da a) nichtssagend + b) oft ein reserviertes Wort.
* Tabellennamen sollten einheitlich entweder alle Einzahl oder alle Mehrzahl sein. Jetzt gibt es die Tbl_Firma, aber auch die Tbl_Adressen.


Tbl_Konto
* Wenn Saldo die Differenz/Summe aus Gutschrift und Belastung ist, lass es. Das kannst du als Abfrage ausrechnen. Außer du musst Rundungseffekte berücksichtigen, dann kann das sinnvoll sein.
* Vertrag_ID verweist wohin? Ist das nicht redundant, denn über die Rechnung kommst du ja auch zum Vertrag?

Tbl_Adressen
* Mir fehlt da Land+PLZ+eine zweite Adresszeile
* 45 zeichen für die Straße können knapp werden
* Das Design ist da etwas komisch - es gibt Adressen + User+Firmen bekommen welche zugeordnet?

Tbl_User
* da gibt es drei Verweise in die Tbl_Adressen. Warum?

Ich lass es mal gut sein - da gibt es schon Dinge zum Bessermachen

Zu Allgemein:

1. In der Bilddatenbanh hatte ich ursprüngich Namen wie 'Bildtabelle' oder 'KategorienTabelle verwendert. Workbench generierte daraus im Falle von Interselektionstabellen Feldname wie 'Bildtabelle_to_KategorienTabelle' oder 'BildtabelleFeldname_to_KategorienTabelleFeldname' . Irgendwann hab ich das dann geändert und möglichst kurze Namen verwendet, wobei ich das'Tbl_' einführte - das soll mir vor allem im Code klar aufzeigen, dass ich mit einer Tabelle arbeite.
2. Das ist sicher übersichtlicher
3. Werd ich korrigieren
4. ??
5. Werd ich korrigieren. Wenn ich das richtig verstehe (was ich im Moment eher bezweifle), ergibt das einen Datentyp, der aus mehren Feldern besteht - wobei: Nur einmal den UDDT ändern zu müssen, klingt schomal gut.. Zu UDDT hab ich bisher dies und das gefunden. Noch nicht viel, wie ich finde.

Das überarbeitete Modell steht soweit, ich muss es allerdings nochmal durchsehen.

Gruss
Delbor

[TigerLilly]

Sorry, ich hab nicht gesehen, dass SQLite dein target ist. UDDTs gehen da gar nicht + VARCHAR/NVARCHAR auch nicht.

[Delbor]

Hi zusammen

@ TigerLilly:
Ich werde wohl noch andere Datentypen von Hand anppassen müssen, wenn es mir nicht gelingt, das Workbench-Plugin für SQLite-Export neu zu installieren. Wobei das wohl alles nuur halb so wild ist, wie es sich anhört: ich habe auch noch das Tool SQLIte Expert auf der Platte - leider nur in der Personal-Edition. Die Professional hätte einen grafischen Designer ála Workbench mit an Board. Leider sehe ich keine Möglichkeit, das Ding Online zu kaufen - preislich würde es sich durchaus in einem vertretbaren Rahmen halten.
Anrerseits liessen sich die Tabellen auch mit der Personal aufgrund des Workbench-Modells erstellen - zwar mehr oder weniger 'von Hand. Egal, irgendwie krieg ich das schon hin.

Inzwischen habe ich das Modell überarbeitet:
17_18_18-PDFOfficerData.jpg

Ich hab auch eine Kontobeschreibungs-Tabelle eingebaut, analog zur Empfehlung von hstreicher, eine Kontokopf-Tabelle einzuführen - ich seh mich schon, wie ich mir an den Kopf greife angesichts einer Bildschirmseite voller gleichlautender Kontonamen...
Beim ersten Entwurf der Tabellen hatte ich die erfordrlichen Fremdschlüssel-Felder mit eingefügt, und als ich die Beziehungen einzeichnete, tat Workbench nochmals dasselbe - ich hoffe nur, ich hab jetzt alle "Bösewichte" erwischt.

Gruss
Delbor

[mkinzler]

Alternativ die Community Edition von DBeaver

https://dbeaver.io/

[Delphi.Narium]

Schau Dir bitte nochmal die ganzen Fremdschlüssel an, da scheint einiges mehrfach zu sein.

Warum hat TblAdressen einen Fremdschlüssel auf Tbl_User_UserID? Müsste das nicht umgekehrt sein? Ein User verweist auf eine der Adressen und nicht eine Adresse verweist auf einen User?
Was ist denn, wenn zwei User die gleiche Adresse haben? Wird die Adresse dann doppelt abgelegt, weil sie nur auf einen User verweisen kann?
Oder müssten nicht die beiden User auf die gleiche Adresse verweisen, um eine doppelte Speicherung einer Adresse zu vermeiden?

Warum ist die Kontonr vom Typ Int? Gibt es keine Kontonummern mit führenden Nullen?
Warum ist die KontoNr auch als Konto-Nr in der Tbl_Kontobeschreibung enthalten? Sind damit unterschiedliche Kontonummern gemeint?

Warum heißt die Tabelle TblUser TblUser, aber die Fremdschlüssel, die auf sie verweisen, Tbl_User_UserID.

Warum gibt es in der Tabelle TblRechnungen einen Fremdschlüssel Tbl_Vertrag_Tbl_Firma_ID.
'ne Rechnung gehört zu einem Vertrag, ein Vertrag zu einer Firma, aber deshalb muss die Rechnung noch lange keinen Fremdschlüssel auf den Vertrag haben. Das ist eine zusätzlich zu pflegende Redundanz (die man allenfalls bei 'ner (z. B. aus Performanzgründen erforderlichen) Denormalisierung einführen kann.

Ähnliches kommt wiederholt vor.

[Delbor]

Hi Delphi.Narium

Zitat:

Warum hat TblAdressen einen Fremdschlüssel auf Tbl_User_UserID?

Ich habe da eine 1.1-Beziehung eingerichtet, da ich davon ausgegangen bin, dass es genau einen User an genau einer Adresse gibt. Aber das ist falsch, da ja auch die Ehefrau des Users Einkommen haben kann und/oder Rechnungen bezahlen muss. Und das Taschengeld der Kinder, bezw. was die damit machen, will/soll auch verwaltet werden/werden können.
Und natürlich können zwei User an der selben Adresse zuhause sein, aber verschiedenen Familien angehören.

Zitat:

Warum ist die Kontonr vom Typ Int? Gibt es keine Kontonummern mit führenden Nullen?

Dass ist schlicht ein Flüchtigkeitsfehler. Ohne wirklich zu wissen, dass es so ist, könnten Kontonummmern wohl auch Alphanummerische Zeichen enthalten.

Zitat:

Warum ist die KontoNr auch als Konto-Nr in der Tbl_Kontobeschreibung enthalten? Sind damit unterschiedliche Kontonummern gemeint?

Auch das ist ein Flüchtigkeitsfehler: ich habe schlicht vergessen, die Kontonummer aus der Kontotabelle zu löschen.

Zitat:

Warum heißt die Tabelle TblUser TblUser, aber die Fremdschlüssel, die auf sie verweisen, Tbl_User_UserID.

Die Fremdschlüssel werden jeweils von Workbench angelegt, aber, wenn ich das richtig gesehen habe, nicht unbedingt angepasst, wenn ich die Beziehung löschen und sie neu anlege.

Zitat:

Warum gibt es in der Tabelle TblRechnungen einen Fremdschlüssel Tbl_Vertrag_Tbl_Firma_ID.

Wie ich oben schon gesagt habe, legt Workbench die Fremdschlüssel an. Und das hat damit zu tun:

09_09_01-ForeignKeys.jpg

Wenn hier Restrict festgelegt wird, kann gar nichts gelöscht werden. Bei allen anderen Möglichkeiten müsste ich mich erst schlau machen.

Und nun möchte ich mich endlich ganz herzlich bei mkinzler bedanken. Ab nun werde ich das Modell mit dbeaver neu erstellen.

Gruss
Delbor

[TigerLilly]

Das ist gut zu lesen:
https://www.talend.com/blog/2017/05/...ctices-part-1/

Auch gut ist das Stichwort "Konzeptionelles Datenmodell".
Es gibt viele Tools, die das unterstützen + damit klebt man nicht von beginn an schon an den Möglichkeiten der target-DB.