Hilfe bei Normalisierung

[scater93]

AW: Hilfe bei Normalisierung

Es währe eine Nette funktion, sie währe aber eigentlich nicht notwendig, da die Addresse nur gebraucht wird um den Brief zu schicken.
Wenn es das verkompliziert kann es ruhig drausen bleiben.

 

[Duddle]

AW: Hilfe bei Normalisierung

Okay, das minimalst angepasste ERM sieht dann so aus: ... hmmm, das ist der gleiche Link wie vorher, das überschreibt creately wohl automatisch. Hinzugefügt wurde nur der Barcode.

Meine zuvor geänderte Meinung bzgl. der Adressen-Zuordnung habe ich erneut geändert (ich könnte fast U.S.-Präsidentschaftskandidat sein) mit folgender Begründung: ein Mensch kann mehrere Adressen haben, aber eine Adresse als Datum ist exakt einem Menschen zugeordnet. Es ist dabei völlig egal, wenn zufällig zwei Leute die selbe Adresse haben - die Anschriften müssen dennoch eindeutig unterscheidbar bleiben.

Als Beispiel wohnt A an Adresse X, B wohnt an Adresse X. Also verweise ich bei A und B auf X per Fremdschlüssel. Will ich jetzt die Adresse von A ändern (Hausnummer hat sich geändert), hole ich sie mir über den JOIN und ändere den Eintrag - leider ändere ich damit auch unwissend den zu B zugewiesenen Eintrag, weil der ja nur auf X verweist.
Offensichtlich darf das nicht passieren. Und es sollte nicht die Aufgabe der Business-Logik sein, soetwas im Hintergrund ausschließen zu müssen. Ergo: jede Adresse gehört zu exakt einem Menschen.

Auch das Argument, zwei mal X getrennt abzuspeichern wäre unnötig redundant, funktioniert nicht. Schließlich werden zwei unterschiedliche Patienten mit zufällig gleichem Namen auch doppelt gespeichert, weil sie dennoch getrennt voneinander betrachtet werden müssen. Das gleiche gilt für die Adresse.

Das obige ERM (falls nicht noch starke Einwürfe kommen) kannst du, scater93, sehr einfach in ein relationales Modell überführen. Ansonsten müsstest du bis morgen warten, dann skizziere ich das fix in creately.

Edit: na gut, das ging doch schneller als erwartet: https://creately.com/diagram/h7aqsioo1/tQOEuHjiiT5SAi05EpkXic1YLwk
Ja, das sieht sehr simpel aus (besonders nach den vielen Fragen und längeren Diskussionen), aber dein Problem ist auch ein sehr einfaches. Zum Beispiel die Sache mit den nachvollziehbaren Adressen würde zu einer zusätzlichen Tabelle führen. Oder eine feingranularere Behandlung von Kontaktinformationen. Oder ein paar Änderungen in der Behandlung von PSA-Werten. So wie du die Fragen beantwortet hast kommt aber dieses sehr simple Ergebnis raus.

In dem Diagramm steht PK für primary key, FK für foreign key. Die Zuweisung sollte eindeutig sein. Du könntest statt dem Anschrift-Feld auch mehrere Zeilen einführen (ich habe mehrfach von einem internationalen Standard gelesen, der 4 getrennt abzuspeichernde Zeilen vorschreibt). Du kannst auch statt dem einfachen Name-Feld Vor- und Nachname unterscheiden - ich hatte aber weiter oben beschrieben warum das eher schlecht als recht ist. Die Datentypen sollten überall passen, aber das musst du dann selbst entscheiden.

Normalisiert ist es so jedenfalls. Darauf würde ich zwar nicht mein Leben, aber zumindest eine potenzielle Ohrfeige von meinem ehem. Datenbank-Professor verwetten.


Duddle

 

[Isometric]

AW: Hilfe bei Normalisierung

Auch wenn das in Deutschland traditionell ein ausreichendes Muster ist, so gibt es genügend Einwohner denen in diesem Schema nicht genüge getan wird. Besonders für ausländische Namen ist es oft schwer, diese klare Unterscheidung zu treffen.
Nur ein Feld ("Name") zu haben widerspricht auch der ersten Normalform nicht, da es keine immer sinnvolle Aufsplittung eines Namens gibt.

Ist es nicht von Nachteil, wenn es nur ein Namenfeld gibt und der eine dann "Liese Müller" und der nächste "Müller Liese" reinschreiben kann?
Sortieren nach dem Namen stelle ich mir da schwierig vor.

 

[Duddle]

AW: Hilfe bei Normalisierung

Bezüglich der Sortierung zitiere ich mal von

This presents the question I should have asked much sooner, “What’s so special about a last name?” Or better yet, “Why sort names at all?”

These days, in the digital data realm, we don’t return our data sets sorted so much as we return them filtered and grouped. A list is sorted by name as an aid to our eye as we scan through a long data set. A filtered data set returns only the items we were looking for in the first place, and the importance of having that data sorted on a field with arbitrary data (like “name”) is lessened. It makes much more sense to be sorting chronologically or grouping by category.

und

In spanish speaking cultures, a name has four parts: First name, second first name, father’s last name, mother’s last name. There can also be middle names, and married names can be added to the end. First name, last name database fields begin to seem rather feeble for dealing with names like this.

(meine Hervorhebungen)

Wie der Nutzer die Eingabe formatiert ist Aufgabe der Oberfläche. Diese muss ihm klar machen, dass in dieses Feld der eigene Name wie in einer Anschrift / auf einem Brief eingetragen werden sollte.
Im Idealfall sollte es sowieso keine Formulare mit Name, Strasse, PLZ, Ort usw. geben. Im Idealfall sollte es ein großes Feld geben und der das Formular verarbeitende Algorithmus erkennt die entsprechenden Daten. Zur Not kann man dem Nutzer auch noch eine Rückfrage geben alá "Bitte bestätigen: Sie sind [Name] wohnen in [Stadt] (PLZ: [PLZ])" etc.


Duddle

 

[SchneewittchenX]

AW: Hilfe bei Normalisierung

Was hat denn eine Musikdatenbank mit einer Adressdatenbank zu tun? Da gelten völlig andere Kriterien und man braucht ein vollständig anderes Datenbankschema.

Bei den Patienten handelt es sich ausschließlich um "natürliche Personen" (im rechtlichen Sinne).
Die haben einen Nachnamen und mindestens einen Vornamen. Und die sollten in getrennten Feldern gespeichert werden, um die Suche und Sortierung zu erleichtern. Ob der 2. oder weitere Vornamen gespeichert werden sollen, kann nur der TE entscheiden.
Bei Straße und Hausnummer lasse ich es mir ja noch gefallen, beides in ein Feld zu stecken, obwohl dann der Vorteil mit den Nachschlagetabellen verloren geht. Ort und PLZ sind ja getrennt und weitere Adresszusätze sind bei natürlichen Personen nicht unbedingt erforderlich.

Insgesamt würde ich streng darauf achten, dass der Feldaufbau mit dem Aufbau der schon existierenden Datenbanken der Praxissoftware zusammenpasst, damit später ein Abgleich möglich ist, deshalb ja möglichst die Versichertennummer mit erfassen.
Manchmal ist es besser, das Geschlecht anstatt der Anrede zu erfassen, allerdings fallen dann in der Anrede Titel weg. Wenn die Versichertennummer gespeichert ist, dann ist das Geschlecht aber auch daraus ermittelbar.
Ich möchte nur Denkanstöße geben, dass Modell sollte der TE schon selbst erstellen.