Announcement

Collapse
No announcement yet.

Versicherung Datenmodell

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Versicherung Datenmodell

    Hallo liebe Datenbank Community!
    Ich benötige unbedingt Hilfe mit einen Thema. Gefragt ist ein Datenmodell für eine Versicherung:
    Ihre Aufgabe ist es ein Datenmodell zu entwickeln. Dazu werden Ihnen folgende Design-Vorgaben zur Verfügung gestellt:
    • Verida hat verschiedene folgende Versicherungsarten im Angebot: Auto, Hausrat, Rechtsschutz, Wohngebäude, Leben. Diese Liste kann jederzeit erweitert werden. Details zu den Versicherungsarten ganz unten.
    • Die Bezahlung der Versicherungsprämie kann jährlich, halbjährlich oder monatlich erfolgen und wird bei Vertragsabschluss festgelegt. Eine Änderung ist aber jederzeit möglich. Der Eingang der Bezahlung muss entsprechend vermerkt werden.
    • Einige Kunden haben nur eine Versicherung, andere haben aber auch mehrere abgeschlossen. • Alle Versicherung können klassisch über einen Versicherungsvertreter abgeschlossen werden.
    • Über den Online-Vertrieb können Auto, Hausrat, Rechtsschutz und Wohngebäude abgeschlossen werden. Dazu notwendige Dokumente müssen hochgeladen werden und sollen auch in der Datenbank gespeichert werden.
    • Im Online-Vertrieb wird dem Kunden automatisiert eine Ansprechperson zugeordnet.
    • Online abgeschlossen Verträge werden stichprobenartig überprüft. Dies soll mitvermerkt werden.
    • Gelegentlich wendet sich ein Kunde auch direkt an die Hauptverwaltung, wodurch ein Vertrag ohne Beteiligung eines Vertreters zustande kommen kann.
    • Vertreter und Ansprechpersonen können durch die Kunden bewertet werden.
    • Die einzelnen Vertreter haben – je nach Erfolg – Faktoren, mit denen festgelegt wird, wie viel Prozent der Jahresprämie eines neuen Vertrages sie als Provision erhalten.
    • Ein Kunde kann mehrere Verträge einer Sparte haben – wie z.B. bei mehreren Fahrzeugen oder auch bei mehreren Wohngebäuden.
    • Bei der Rechtsschutz-Versicherung sind mehrere Verträge nicht möglich. • Versicherungsverträge haben immer einen Versicherungsbeginn und ggf. auch ein Versicherungsende.
    • Jeder Anlassfall (z.B. Wasserrohrbruch bei einer Hausratversicherung, Autounfall, usw.) zu einem Versicherungsvertrag muss gespeichert werden.
    • Es sollen sowohl Interessenten als auch ehemalige Kunden, deren Versicherungsverträge gekündigt wurden, in der Datenbank gespeichert werden. Beides dient dazu, diese Personen zwecks Werbung kontaktieren zu können.
    Ich brauche insbesondere Hilfe mit dem Punkt:
    Jeder Anlassfall (z.B. Wasserrohrbruch bei einer Hausratversicherung, Autounfall, usw.) zu einem Versicherungsvertrag muss gespeichert werden.
    Mein derzeitiges Modell:
    https://imgur.com/l13o1P7
    Es wurde bereits bewertet und Anlässe ist falsch. (Es sind mehr Fehler enthalten, aber unbedingt ist Anlässe zu verbessern)
    Zudem wurde mir gesagt, dass ich folgendes beachten muss:
    Schadensfälle
    Zuweisung zu der Person, die das Geld kriegt
    Ich wäre sehr sehr dankbar für jede Art von Hilfe!
    Zuletzt editiert von Christian Marquardt; 24.06.2020, 06:28.

  • #2
    Was mir an deinem Model auffällt.

    a.) Kunde <-> Vertrag referenzieren sich gegenseitig das macht so für mich keinen Sinn. Ein Kunde kann mehrere Verträge haben. Also gehört die ID des Kunden in die Vertrag Tabelle aber nicht auch noch umgekehrt.
    b.) Dokumente gehören für mich zu Verträgen nicht zu Kunden.
    c.) Anlass und Vertrag haben keine Beziehung zueinander in deinem Model. Der Anlass muß ja einem Vertrag zugeordnet sein. Entweder muß in Anlass die ID des Vertrags oder wenn ein Vertrag aus mehere Versicherungsarten enthalten kann (so wie das hier auch aussieht) dann gehört die ID der VersArtVertrag Mappingtabelle in Anlass.

    Allgemein

    - Ich würde dir empfehlen jeder Tabelle immer einen einspaltigen Primärschlüssel zu geben. Zum Beispiel VersArtVertrag hat keinen. In Punkt c.) mußt du diese Tabelle aber aus Anlass referenzieren. Das wird schwierig ohne einen einzelnen Primärschlüssel.
    - Dein Naming ist durcheinander mal ID vor dem Bezeichner mal danach.
    - Auch das Namensschema "Tabelle_Primärschlüssel" für die Fremdschlüssel ist nicht übermäßig hilfreich bzw. schwer lesbar. Wenn deine Primärschlüssel jeder Tabelle immer TabelleID ist dann kannst du den als Fremdschlüssel mit diesem Namen einfach in der anderen Tabelle benutzten ohne die Tabelle nochmal zu nennen wo die herkommt. Eine Spalte KundeID im Vertrag ist deutlich genug um zu zeigen das die aus der Kunde Tabelle kommt. Denn ID als Postfix ffür Primärschlüssel reserviert du solltest dann halt ID für nichts anderes verwenden.
    - Für alle anderen Spalten jenseits des Primärschlüssels solltest du den Tabellen Namen aus dem Spaltennamen raushalten das hält die Bezeichner kurz. Wenn du später via SQL mit dem Modell arbeitest würde man eh dazu greifen den Tabellennamen (oder eher einen Alias) mit zum Spaltennamen hinzuzufügen. Das der Tabellenname mit im Spaltennamen ist macht es also nicht lesbarer. Beispiel Tabelle Versicherngsart. Die Spalten sollten VersicherungsartID, Bezeichnung, Beginn, und Ende lauten.Kurz aber erklärend genug und damit im Model übersichtlicher.

    Wenn du dein Model ein wenig auf Lesbarkeit trimmst wirst du dich auch leichter tun hier Hilfe zu bekommen. Das Modell ist schon so mittelprächtig komplex und wir tun uns da leichter uns das anzusehen wenn es leicht lesbar ist(und jeder andere der sich das Model ansehen soll natürlich auch)

    Comment

    Working...
    X