Datenbankmodellierung

**p80286**

Zu der "dynamischen" Struktur:
stell Dir vor Du sitzt im Einkauf eines Autoherstellers. neben Schrauben,Windschutzscheiben usw. bestellst Du auch Räder. Dau auf jede Felgengröße 2 Reifengrößen passen baust Du zwei Tabellen Hauptbauteil, Unterbauteil.
Ob Felge oder Rad in das Hauptbauteil kommen lassen wir mal offen, Reifen kommt in das Unterbauteil. Jetzt kommt jemand auf die Idee die Felge bei einem Lieferanten zu bestellen und den Reifen beim anderen. Ist der Reifen jetzt Hauptbauteil und gleichzeitig Unterbauteil?

Gruß
K-H

**Asura**

Zitat von Codehunter:

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

So ungefähr !

Ich wollte mir Zeit nehmen, um alles mir durchzulesen und zu kommentieren! Aber mit der Diskussion bin ich eindeutig überfordert

Ich mach mich mal an die Arbeit und versuche mal die Hilfen zu Kommentieren bzw. mit weiteren Fragen zu füttern!

Zitat von TigerLilly:

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

Das hatte ich tatsächlich vor, ich wollte über MD5 oder SHA1 nach der Erstellung des Benutzerkontos den Hash im Programm selber erstellen und diesen dann auf der Datenbank abspeichern lassen. Beim Login würde ich dann wieder das Passwort als Hash erstellen und diesen mit dem hinterlegten Hash vergleichen.

Zitat von TigerLilly:

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.

Was wäre anhand dessen der Vorteil? Gut ich sehe sowieso ein für mein Vorhaben ist die IBAN nicht notwendig. Meine Intention war dahinter, dass ich eine Art Adressbuch erstelle anhand dessen man später die Buchungen an Personen zuweisen kann. Also die IBAN wäre für die Funktion nicht notwendig.

Zitat von TigerLilly:

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.

In den Kategorien sehe ich selber auch noch das größte Problem in der Modellierung.
Ich versuche mal meine Intention hinter dem aktuellen Aufbau zu erläutern:

Attribut Costtype ist für mich die Unterscheidung von Fixen und variablen Kosten.
Diese werden dann in der Tabelle Bookings zugewiesen. Die Tabelle fixed (Fixe Kosten) sollte für das Programm eine Hilfestellung sein, um die Fixe Kosten immer wieder neu in der Tabelle Bookings zu verbuchen und gleichzeitig dem Benutzer eine Möglichkeit zu bieten hier einen Überblick über die Fixe Kosten zu haben und diese leicht abändern zu können.
Attribut Booktype ist dafür da einfach über ein Boolean Wert festzustellen: Ist dies eine Minusbuchung oder Plusbuchung. Gut ich könnte das auch einfach anhand der Zahl (Amount aus Tabelle Booking) ermitteln, die ja entweder ein Minus oder kein Minus hat. Wäre eventuell auch eine bessere Lösung.

Zitat von TigerLilly:

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).

Nur damit ich das verstanden habe als Beispiel:
In der Tabelle bankaccounts wäre dann mit deinem Verfahren es nicht UserID sondern Users.ID bzw. UsersID?
Sprich der FK hat immer den Namen der referenzierten Tabelle als (ich nenne es mal) Pre Klausel?

Zitat von TigerLilly:

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.

Gut, das werde ich ändern, damit kommen wir wohl auch zu einem Großen Thema: Mehrzahl oder Nicht:

Es wird vllt hier ein paar schmerzen, aber ich finde zum Teil ist der Plural für mich Sinnhaft. Ich kann die Argumentation absolut nachvollziehen. Ich kann aber anhand des Plurals für mich schon direkt festlegen: Das ist eine Tabelle und kein Attribut und es liest und schreibt sich für mich später bei der Erstellung einfach besser, wenn ich den Plural benutze. Kann dies schwer erklären wieso das der Fall ist.

Zitat von StepByStep:

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.

Ja da hast du Recht. Meine Intention war dahinter als Beispiel:
Maincategorie: Verpflegung das umschließt die Subcategorien: Nahrung, Getränke, Tabak etc.
Sprich ich kann später bei der statistischen Auswertung meiner Kontodaten mir anhand von Masken/Filter Eingaben die Ergebnisse anzeigen, die mich wirklich interessieren. Beispiel: Wie viel gebe ich im Monat nur für Nahrung aus, wie viel für Getränke etc.

Zitat von StepByStep:

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.

Habe ich deswegen nicht gemacht, da ein User mehrere Bankaccounts haben kann und ein Bankaccount mehrere Buchungen. Sprich in der Buchung an sich ist ja schon die UserID anhand der BankAccountID hinterlegt. So dachte ich mir das.

Des Weiteren wundere ich mich, dass du nach den Beziehungen fragst, da die doch in der Grafik abgebildet sind anhand den Verbindungen. Der Senkrechte Strich bedeutet eine 1 und der umgedrehte Pfeil das n. Sprich: 1:n Beziehungen habe ich dort gekennzeichnet.

Zu der fortgefolgten Diskussion kann ich mich nicht zu äußern, da ich wirklich nur ein Anfänger in Sachen Datenbanken bin. Also wenn hier, vor dem Hintergrund meiner Erklärung zu den Kategorien (siehe erste Kommentierung zu der Antwort von StepByStep), mir ein passendere Modelllösung vorgeschlagen wird mit einer kleinen Erklärung weshalb, dann würde mir das sehr viel mehr helfen.
Ich denke weitere Kategorisierungsmaßnahmen würden auch nicht hinzukommen da zwei Kategorien zur Gliederung eines Buchungseintrages ausreichen, um seine Funktion wiederzuspiegeln.

Ich bitte vllt auch noch mal die Lösung mit Evalution näher zu begutachten.
Mein Vorhaben ist hier, dass pro Bankaccount ein Bewertungssystem vergeben wird (Sprich ein Benutzer kann mehrere besitzen). Bewertungssystem sehe ich mit einer persönlichen Einschätzung über die Notwendigkeit der Buchung. Das lässt später wieder in statistischen Auswertungen heran ziehen, indem mir das Programm sagt: 25% deiner Kosten sind nach deinem Bewertungsschema wirklich notwendig (zum Beispiel 1 = sehr notwendig, 6 = unnötig / Luxus).

So lässt sich leicht herausstellen: Wo habe hohe Ausgaben und wie werden diese bewertet. Im vorangegangen Beispiel: Wie notwendig sind diese Ausgaben.

//Edit

Ergänzend zu dem Kategorien will ich diese natürlich dem Nutzer überlassen, diese frei einzustellen und zu bearbeiten.
In Verbindung mit dem Bewertungssystem kann man darüber auch nachdenken statt die Buchung als einzelnes zu bewerten mit dem Benotungssystem, eher vllt die Kategorien zu bewerten.
Ein Problem sehe ich auch noch, was passiert wenn Kategorien gelöscht oder ersetzt werden. Da die Buchung ja Kategorien zugeordnet ist.

**Codehunter**

Zitat von Asura:

Ein Problem sehe ich auch noch, was passiert wenn Kategorien gelöscht oder ersetzt werden. Da die Buchung ja Kategorien zugeordnet ist.

Die löscht du nicht im Sinne von DELETE FROM ... sondern indem du ein Markerfeld setzt das eine Kategorie als gelöscht markiert. Auswählbar/sichtbar ist sie dann nicht mehr für neue Datensätze, wird aber noch (üblicherweise ausgegraut) in bestehenden Datensätzen angezeigt.

**p80286**

Zitat von Asura:

Ich bitte vllt auch noch mal die Lösung mit Evalution näher zu begutachten.
Mein Vorhaben ist hier, dass pro Bankaccount ein Bewertungssystem vergeben wird (Sprich ein Benutzer kann mehrere besitzen). Bewertungssystem sehe ich mit einer persönlichen Einschätzung über die Notwendigkeit der Buchung. Das lässt später wieder in statistischen Auswertungen heran ziehen, indem mir das Programm sagt: 25% deiner Kosten sind nach deinem Bewertungsschema wirklich notwendig (zum Beispiel 1 = sehr notwendig, 6 = unnötig / Luxus).

So lässt sich leicht herausstellen: Wo habe hohe Ausgaben und wie werden diese bewertet. Im vorangegangen Beispiel: Wie notwendig sind diese Ausgaben.

Ein System in dem Buchungen gespeichert werden ist das Eine, etwas ganz anderes ist es gleichzeitig eine "Bewertung" einzutragen. Wer soll denn dazu Berechtigt sein?

Im Allgemeinen hat ein Angestellter eines Unternehmens die Berechtigung bis zu einer bestimmten Summe einen Auftrag zu zeichnen. Dieser Auftrag wird im Allg. auch nicht aus einer Laune heraus erteilt sondern steht im Normalfall im Kontext der Unternehmenspolitik. Wenn die Unternehmensführung der Meinung ist, daß Aufträge die ein Angestellter nicht unbedingt notwendig für das Unternehmen sind, wird sie dies vllt. mit Hilfe der vorhandenen Buchungsdaten belegen, aber eine Bewertung wohl nicht unbedingt in der Buchungsdatenbank ablegen.

http://www.spiegel.de/forum/karriere...-208608-7.html

Gruß
K-H

**Asura**

Zitat von p80286:

Ein System in dem Buchungen gespeichert werden ist das Eine, etwas ganz anderes ist es gleichzeitig eine "Bewertung" einzutragen. Wer soll denn dazu Berechtigt sein?

[...]

Gut, das ist wohl meine Schuld, dass ich keine nähere Erläuterung zu meinem Programm gegeben habe.
Das Programm wird nicht in dieser Form, wie du es beschrieben hast genutzt.
Mein Vorhaben ist es, dass der Nutzer seine Buchungen (Bankkontoaktivitäten) manuell einträgt oder nach weiterer Entwicklungszeit automatisch die neuesten Buchungen aus dem Online Bankkonto herunterzieht auswertet, mit den vorhanden Informationen einen Vorschlag zur Speicherung ausgibt (In Form eines ausgefüllten Formulares) und der Nutzer nur noch kleinere Einstellung (In dem Fall Bewertung und Fein-Kategorisierung) vornimmt und bestätigt.

Man könnte das System als überschaubarere Bankkontoaktivitäten ansehen. Also ich speichere schlichtweg meine Buchungen auf meinen Bankkonten in eine Datenbank ab.
Diese Möglichkeit öffnet mir dann die statistischen Auswertungend die sehr weit spannbar sind und von den meisten Onlinebanksystem nicht mal ansatzweise berücksichtigt werden (Stichwort: (Multi)lineares Regressionsmodell für Prognosen) bessere grafische Darstellung usw.

**Ghostwalker**

Zitat von 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

Öhm..also die Grundlagen der Buchhaltung (wir reden hier doch von der Doppelten ?) sind doch recht einfach. Wenn ich da ans deutsche Steuerrecht denke.....

Aber zurück zum Thema. Einige allgemeine Tips aus der Praxis:

1. Die Normalform ist zwar schön und gut, und sollte durchaus auch angestrebt werden. Aber in der Praxis gibts
Situationen und Anforderungen, die Redundazen nicht nur angenehm sonder sogar notwendig machen.

2. Joins...sie sind angenehm für den Programmierer. Aber sie erzeugen auch u.U. sehr hohe Lasten auf der DB (und ggf. auf dem Rechner für die DB). Deshalb versuch ich sie grundsäzlich zu vermeiden.

3. Die Strukturen immer so einfach wie möglich halten. Je einfacher das Datenmodell desto leichter ist es,
sie in einem Programm zu handhaben (xtCommerce ist da nicht gerade Vorreiter).

**jobo**

Zitat von Ghostwalker:

1. Die Normalform ist zwar schön und gut, und sollte durchaus auch angestrebt werden. Aber in der Praxis gibts
Situationen und Anforderungen, die Redundazen nicht nur angenehm sonder sogar notwendig machen.

2. Joins...sie sind angenehm für den Programmierer. Aber sie erzeugen auch u.U. sehr hohe Lasten auf der DB (und ggf. auf dem Rechner für die DB). Deshalb versuch ich sie grundsäzlich zu vermeiden.

zu 1:
"Angenehm" an der Redundanz ist ja höchstens, dass "man" "es" als Programmierer (scheinbar) einfacher hat. Gerade im Sinne von Punkt 3. Wirklich "notwendig" sind sie wohl eher selten.

zu 2:
Joins sind kein Hexenwerk. Man kann in den allermeisten Fällen durch Indexierung und meist sinnvolle Einschränkungen der betrachteten Menge auf sehr "kleine" und schnelle Selectergebnisse kommen. Ich empfehle bei dem Modellentwurf nicht auf Anzahl von Joins abzuzielen, sondern auf ein stimmiges Modell. Gerade hier in dem Thread geht es ja offensichtlich um sehr gut beherrschbare Datenmengen.

3 ist sowieso empfehlenswert. In der Praxis macht man bei der Abbildung der Wirklichkeit immer irgendwo einen Cut, ein Kompromis aus Entwicklungsaufwand und gewünschten Ergebnissen, aber auch aus dem Eingabeaufwand, den das erstellte Modell erzwingt.
Wieviel Eingabemasken und Tabellen hat man schon gesehen, die aufwendig befüllt werden müssten, aber am Nutzen und Aufwand (Praktikabilität, Faulheit, Zeitdruck, ..) scheitern.

**Ghostwalker**

Zitat von jobo:

zu 1:
"Angenehm" an der Redundanz ist ja höchstens, dass "man" "es" als Programmierer (scheinbar) einfacher hat. Gerade im Sinne von Punkt 3. Wirklich "notwendig" sind sie wohl eher selten.

Notwendig sind sie heufiger als man denkt. Gerade wenn man auch die Performance und die Systemresourcen
im Auge hat.

Zitat von jobo:

zu 2:
Joins sind kein Hexenwerk. Man kann in den allermeisten Fällen durch Indexierung und meist sinnvolle Einschränkungen der betrachteten Menge auf sehr "kleine" und schnelle Selectergebnisse kommen. Ich empfehle bei dem Modellentwurf nicht auf Anzahl von Joins abzuzielen, sondern auf ein stimmiges Modell. Gerade hier in dem Thread geht es ja offensichtlich um sehr gut beherrschbare Datenmengen.

Ich habe nicht gesagt, das Joins Hexenwerk sind. Ein gutes und stimmiges Modell macht auch viele Joins (die in anderen Modellen notwendig sind), überflüssig. Man sollte aber auch daran Denken, das ein Datenmodell, so gut es auch entwickelt wurde, selten die 2. Version überlebt.

Fakt ist aber, das Joins eine DB (bzw. den Server) stark belassten (hinsichtlich Performance und Systemresource). Mit steigernder Nutzerzahl wird das sicher relevant.

Zitat von jobo:

3 ist sowieso empfehlenswert. In der Praxis macht man bei der Abbildung der Wirklichkeit immer irgendwo einen Cut, ein Kompromis aus Entwicklungsaufwand und gewünschten Ergebnissen, aber auch aus dem Eingabeaufwand, den das erstellte Modell erzwingt.
Wieviel Eingabemasken und Tabellen hat man schon gesehen, die aufwendig befüllt werden müssten, aber am Nutzen und Aufwand (Praktikabilität, Faulheit, Zeitdruck, ..) scheitern.

**jobo**

Ich will niemand erschlagen, also nur weiterlesen bei Interesse:

Zitat von Asura:

Also ich speichere schlichtweg meine Buchungen auf meinen Bankkonten in eine Datenbank ab.
Diese Möglichkeit öffnet mir dann die statistischen Auswertungend die sehr weit spannbar sind und von den meisten Onlinebanksystem nicht mal ansatzweise berücksichtigt werden (Stichwort: (Multi)lineares Regressionsmodell für Prognosen) bessere grafische Darstellung usw.

Find ich spannend und würde mir nochmal überlegen, ob Deine geplante Kategorisierung ein adäquates Mittel ist.
Du hast selbst schon das Thema Änderung von Kategorien angesprochen. Das ist immer problematisch, nicht nur aus Modellierungs und Umsetzungsaspekten.
Zu einem Zeitpunkt x definierst Du ein hoffentlich sinnvolles System und alle eingehenden Buchungen erhalten einen entsprechenden Kategorie-Stempel nach Deinem aktuellen Ermessen. Sobald Du die Kategorien aber änderst, ist der Wert der alten Kategorisierungen mehr als fraglich.
Es geht einfach um den Punkt: speichert man eine Interpretation der Fakten und analysiert das dann irgendwie oder speichert man erstmal nur Fakten für die spätere Analyse. Das ist m.E. ein ziemlicher Unterschied.
In Deinem Fall wären es neben den Beträgen m.E. einfach die erworbenen Güter oder Leistungen.
Eine Kategorisierung und eine Bewertung wären durch einen separaten Prozess und Datenspeicher zu bewerkstelligen.
Ist das Problem klar, kann man natürlich hergehen und beides parallel Speichern, Fakten und (subjektive Kategorie. So läuft man jedenfalls nicht Gefahr, eine sagen wir verkürzte Interpretation von Fakten zu speichern, deren Ursprung einem irgendwann (z.B. bei der Neukategorisierung) fehlt. Fakten sind im übrigen viel leichter einzutragen. Nicht im Sinne von Verfügbarkeit (auf der Lastschrift vom Supermarkt findet man natürlich nicht alle Artikel, die man gekauft hat), aber Sinne der Abwägung (Grundbedarf oder Luxus). Das ist sehr subjektiv, schwankt wahrscheinlich mit der Zeit und führt zu einer eher mäßigen Kategorisierungsqualität.

**jobo**

Zitat von Ghostwalker:

Fakt ist aber, das Joins eine DB (bzw. den Server) stark belassten (hinsichtlich Performance und Systemresource). Mit steigernder Nutzerzahl wird das sicher relevant.

Das ist mir etwas zu pauschal (z.B. steigende Nutzerzahl ist per se eine höhere Belastung für jedes Sytem). Für mich gehören JOINS einfach dazu. Aber man muss auch nicht alles zerreden.