Auf Thema antworten 2026

JavaScript ist deaktiviert. Für eine bessere Darstellung aktiviere bitte JavaScript in deinem Browser, bevor du fortfährst.

Beitrag: <blockquote data-quote="Duddle" data-source="post: 2044426" data-attributes="member: 17775">AW: Hilfe bei NormalisierungOkay, 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: <a href="https://creately.com/diagram/h7aqsioo1/tQOEuHjiiT5SAi05EpkXic1YLwk" target="_blank">https://creately.com/diagram/h7aqsioo1/tQOEuHjiiT5SAi05EpkXic1YLwk</a>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</blockquote> Bilder bitte hier hochladen und danach über das Bild-Icon (Direktlink vorher kopieren) platzieren.

Authentifizierung: Wenn ★ = 12, ◇ = 4 und die Hälfte von ★ zu ◇ addiert wird, was ist das Ergebnis?