Datenbankmodellierung

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

[mkinzler]

Deshalb gibt es in diesem Punkt kein richtig oder falsch.

[jobo]

Zitat von mkinzler:

Kann aber wieder zu Inkonsistenzen führen.

Zitat von Jumpy:

Das ist halt das ewige Dilemma

Zitat von mkinzler:

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

[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

[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