Antworten auf deine Fragen:
Neues Thema erstellen

Hilfe bei Normalisierung

scater93

Wissen´s Suchender

Hi,
Ich hoffe ich bin hier im Richtigen Forenabschnitt, an sonsten bitte in den Richtigen verschieben ;)

Also ich habe Folgendes Problem:
Ich Arbeite momentan, an einem kleinen Projekt zum Speichern von Patienten daten.

Zum Hintergund:
Meine Mutter arbeitet als Krankenschwester und 1 mal im Jahr haben die den Sogennanten PSA tag, wo jeder Hinkommen kann um sich über Prostata Krebs zu Informieren und um kostenfrei eine Vorsorgeuntersuchung machen zu lassen. Bis jetzt Haben die aber alles immer nur per Excel Tabelle eingetragen bzw. es lagen Formulare aus, die von Hand ausgefüllt wurden und dann Später umständlich per hand in Excel übertragen wurden. Das Problem war vorallem teilweise die Handschrift und das aufgrund dieser manchmal z.B. im Nachhinein nochmal per telefonat die Addresse erfragt werden musste. Da ich letztes mal selber beim eintragen der Daten noch gehollfen habe, weiß ich das es eine Menge arbeit war und deshalb hab ich Ihr vorgeschlagen das, ich ihr eine Komfortablere Lösung(ein Web Formular) machen würde, damit es nächstes mal einfacher wird. Die Ärtzte die den Tag veranstallten(auch Niedergelassene Ärtzte) haben gesagt, ist in Ordnung also hab ich mich mal direkt Drangegeben.

Das Problem:
Das Formular an sich zu schreiben ist für mich kein Problem, allerdings komm ich mit der Datenbank an sich nicht zurecht, weil ich die Normalisierung nicht so wirklich hinbekomme. 1. und 2. Form sind kein problem, aber ab der 3. wird´s bei mir kritisch.

Die Ursprungs Tabelle:


Ich weiß das ist eine ziemlich Egoistische Bitte, aber ich hoffe hierbei kann mir vllt. jemand helfen, da ich nicht damit zurecht komme. Ich habe zwar schon mehrere Tutorials zum Thema Normalisierung gelesen aber es klappt immer noch nicht so richtig.

Wenn ihr mehr Infos zum Aufbau braucht, oder Beziehungen wissen müsst, einfach Fragen. Dann werde ich die Infos noch Ergänzen.

Ich Hoffe wirklich das ihr mir Helfen könnt.

mfg
Scater93


PS: Es handelt sich hier um ein "Privates Projekt", d.h. zu 99% werde ich dafür kein Geld bekommen. Solltet ihr mir helfen, werde Ich euch auf wunsch aber gerne in die Credits mit Reinschreiben.
 

Robbyn-

PHP / Flex Programmierer

AW: Hilfe bei Normalisierung

Was verstehst du unter Normalisieren? Ich kann damit nicht viel Anfangen. Du hast deine Formulare, wo die Ärzte ihre Daten eintragen und diese Eingetragenen Daten werden dann von dir in die DB geschrieben?
 

scater93

Wissen´s Suchender

AW: Hilfe bei Normalisierung

Genau, allerindgs wird diese Datenbank dann auch mit weitergegeben an das Labor, das die Blutuntersuchung macht und die PSA werte davon ermittelt. Daher auch die Spalte Barcode, da diese nähmlich vom Labor selbst kommen. Jeder patient bekommt also einen Individuellen Barcode dem dann die PSA Werte zugeordnet werden können.


Hier mal eine genauere Erläuterung zu Normalisierung:

Durch die Normalisierung und die strengen Regeln soll eine korrekte, relationale Datenbank aufgebaut werden bzw. diese erhalten bleiben. Dabei ist wichtig, dass Redundanzen vermieden werden, da diese sonst schnell bei Änderungen von Inhalten zu Inkonsistenzen führen.

Dabei bedeutet Redundanz (lateinisch redundare „im Überfluss vorhanden sein“) auf Deutsch Doppelung bzw. Überschneidungen.

Inkonsistenzen
bedeutet: Widersprüchlichkeit oder Unbeständigkeit der eingegebenen Daten.

Als Beispiel:
Mitarbeiter pflegen die Daten der Kundendatenbank. Dazu kann bei jedem Kunden die PLZ und der Ort unabhängig voneinander eingetragen werden.
Der erste Mitarbeiter trägt nun einmal als PLZ „72070“ und als Ort „Tübingen“ ein. Der zweite Mitarbeiter als PLZ „72070“ und als Ort „Tübingen am Neckar“ ein – es liegt schon eine Inkonsistenz vor. Der nächste Mitarbeiter trägt für den nächsten Kunden als PLZ wieder „72070“ ein und als Ort dann „Tuebingen“. Und der vierte Mitarbeiter trägt (weil er eine Großschreiballergie hat, dann als Ort „tübingen“ ein.
Am Abend kommt der Chef und lässt sich einer Statistik ausgeben, wie viele Kunden aus „Tübingen“ eingetragen wurden – er bekommt nur einen. Hätte er mit der PLZ „72070“ die Statistik erstellt, hätte er 4 Kunden angezeigt bekommen.
Dieses Beispiel zeigt, wie schnell eine Datenbank (bedingt durch Ihren Aufbau) zu unbeständigen Daten (sprich Inkonsistenzen) und den entsprechenden Folgeproblemen führen kann. Wäre hier die Redundanz (Eingabe von PLZ und zusätzlich Ort) unterbunden worden, wären Folgeprobleme vermieden worden.

Es gibt sechs Schritte, wobei in der Praxis die ersten drei umgesetzt werden.
Da die einzelnen Stufen der Normalisierung aufeinander aufbauen, muss die Reihenfolge der Anwendung der Normalisierung eingehalten werden. Es kann die 2. Normalisierung erst angewendet werden, wenn die 1. Normalisierung erfüllt ist.

Zweck der Normalisierung


Durch Anwendung der Normalisierung soll die Integrität der Daten sichergestellt werden.

  • Redundanzen unterbinden
  • Inkonsistenzen vermeiden
Die Wartung der Daten wird i.d.R. vereinfacht, die Programmierung allerdings aufwendiger.
 
Zuletzt bearbeitet:

Robbyn-

PHP / Flex Programmierer

AW: Hilfe bei Normalisierung

Die Wartung der Daten wird i.d.R. vereinfacht, die Programmierung allerdings aufwendiger.

Wie dieser Satz schon sagt ist es Aufwendig, eine Normalisierung einzubringen, aber nicht unmöglich. Du wirst es aber glaube nicht so hinbekommen. Wenn du wirklich sagst gib mir alle Leute aus Tübingen, dann nimmst du alle Datensätze und dann Fischt du den Ort raus, diesen lässt du durch folgende Funktionen laufen:

PHP:
$ort	=	"Thübingen";
// Umlaute entfernen
$umlaute = Array("/ä/","/ö/","/ü/","/Ä/","/Ö/","/Ü/","/ß/");
$replace = Array("ae","oe","ue","Ae","Oe","Ue","ss");
$ort = preg_replace($umlaute, $replace, $ort);

// Ortsname wird erstellt
$ort = strtolower($ort);

echo $ort //thuebingen
Dadurch wird der Ort immer kleingeschrieben, alle Umlaute werden umgewandelt. Dadurch is man schon fast Save, klar wenn sich jemand verschreibt hat man das Problem wieder, aber dann würde nur eine Lösung in Frage kommen und zwar das du vorgibst was für Orte es gibt, man dies mit einer Select Box auswählen kann und dann haste feste Datensätze.
 
Zuletzt bearbeitet:

Mereel

Aktives Mitglied

AW: Hilfe bei Normalisierung

Ich habe nur ein Semester Informatik-Grundlagen genossen und das mit der Normalisierung auch nie hundertprozentig verstanden. Aber hier trotzdem meine Laienhaften Überlegungen dazu:

Bei der PLZ/Ort Problematik sehe ich das auch so, dass du am besten eine eigene Tabelle mit Orten (PLZ + Name) erstellst und dann zum Beispiel anhand dieser Tabelle eine Dropdownliste machst. Problem: Neue Orte können bei der Registrierung nicht ausgewählt werden.
Eine Alternative wäre, bei der Patientenregistrierung nur die PLZ zu berücksichtigen und diese in die Patiententabelle zu schreiben. Der Ortname wird dann aus der Orte-Tabelle bei Bedarf ausgelesen, fehlende Datensätze müssen hier per Hand durch einen Mitarbeiter eingetragen werden (auch nicht optimal, aber das Nachtragen kann dann z.B. am Abend auf einen Schlag erfolgen und es muss sich nicht jeder neue Patient einzeln melden, wenn sein Ort nicht in der Liste steht).

EDIT: Allerdings sehe ich auch noch ein ganz anderes Problem bzw. Ursache für Redundanz und Inkonsistenz: Ich gehe mal davon aus, jeder Patient kann öfters (in aufeinanderfolgenden Jahren) zur Untersuchung kommen. In deine Datenbank lässt sich allerdings nur eine Untersuchung pro Patient eintragen bzw. bei Folgeuntersuchungen muss ein komplett neuer Datensatz angelegt werden. Ich würde auf jeden Fall die Untersuchungen in eine extra Tabelle auslagern.
 
Zuletzt bearbeitet:

scater93

Wissen´s Suchender

AW: Hilfe bei Normalisierung

Ok, werd ich schonmal Berücksichtigen.

Meine Bisherige Planung sieht momentan so aus:

1. Tabelle:
pat_id(also der wievielte patient) ;
pat_vorname ;
pat_nachname ;
pat_alter ;
pat_ barcode ;

2.Tabelle:
pat_id ;
pat_straße ;
pat_hn(Hausnummer) ;
pat_plz ;

3.Tabelle:
pat_plz ;
pat_ort ;

4.Tabelle:
pat_barcode ;
pat_psa_a ;
pat_psa_b ;
pat_ psa_c ;
Mal sehen in wie weit ich die nun noch verändern muss
 

Robbyn-

PHP / Flex Programmierer

AW: Hilfe bei Normalisierung

Mach es lieber so:

1. Tabelle:
pat_id(also der wievielte patient) ;
pat_id_table_4
pat_vorname ;
pat_nachname ;
pat_alter ;

2.Tabelle:
pat_id ;
pat_id_table_3
pat_straße ;
pat_hn(Hausnummer) ;

3.Tabelle:
pat_id_table_3
pat_plz ;
pat_ort ;

4.Tabelle:
pat_id_table_4
pat_barcode ;
pat_psa_a ;
pat_psa_b ;
pat_ psa_c ;
Ist ordentlicher und vorallem übersichtlicher, außerdem hast du nicht soviele Daten doppelt drin stehen.
 

Robbyn-

PHP / Flex Programmierer

AW: Hilfe bei Normalisierung

Ist auch einfach ein Zähler der pro Eintrag nach oben geht, mit diesen Zählern sprichst du dann die Tabelle an anstatt mit dessen Inhalt. So wie du es mit Tabelle 1 und Tabelle 2 gemacht hast (pat_id)
 

Mereel

Aktives Mitglied

AW: Hilfe bei Normalisierung

Also irgendwie stimmt das noch nicht ganz.
Mein Vorschlag wäre:
1. Tabelle:
pat_id(also der wievielte patient) ;
pat_vorname ;
pat_nachname ;
pat_alter ;
adr_id ;

2.Tabelle:
adr_id ;
ort_id ;
adr_straße ;
adr_hn(Hausnummer) ;

3.Tabelle:
ort_id
ort_plz ;
ort_name ;

4.Tabelle:
pat_id
unt_barcode ;
unt_psa_a ;
unt_psa_b ;
unt_ psa_c ;
Edit: Soweit es nicht mehrere Patienten mit der selben Adresse geben (wovon in diesem Fall wohl nicht auszugehen ist), würde ich aus praktischen und Performance- Gründen (man spart sich einen Join bei der Ausgabe der Patientendaten) die Adress-Tabelle mit der Patiententabelle zusammenlegen.

Edit 2: Mir ist gerade aufgefallen, nach eurem Modell wären mehrere Adressen pro Patient möglich, nach meinem nicht. Und nach meinem Schema käme es zu einem Problem, wenn ein Patient umzieht. Also entweder pat_id wieder in die Adressen-Tabelle, wenn wirklich mehrere Adressen je Patient nötig sind, ansonsten die Adresse in die Patiententabelle.

Und was bestimmt auch gegen irgendeine Normalisierungsregel verstößt: Speichere nicht das Alter sondern unbedingt das Geburtsdatum des Patienten! (Grund sollte klar sein ;-))
 
Zuletzt bearbeitet:

Duddle

Posting-Frequenz: 14µHz

AW: Hilfe bei Normalisierung

Bitte, bitte, bitte lies dir den Wiki-Artikel zum ERM durch, bevor du dein Design in die Datenbank überträgst. Eine schlecht modellierte Datenbank wirft dir später unglaublich viele Hürden in den Weg.

Ich werde mir den Thread nochmal genauer durchlesen und meinen Vorschlag posten / hier rein editieren.

Edit: Die Frage kam vorher schon auf: kann ein Patient mehrere Untersuchungen machen? Zweitens, sind diese PSA-Werte getrennt voneinander zu verstehen? Also ist PSA-A ein anderes Jahr als PSA-C oder sowas? Oder werden bei einer Untersuchung immer PSA-A, -B und -C ermittelt?

Edit 2: Ist das Datum irgendwann wichtig? Also soll nachvollzogen werden, wie sich bestimmte Werte über die Jahre bei einem Patienten ändern?

Edit 3: Bekommt ihr nur das Alter von einem Patienten oder deren Geburtsdatum? Es gibt eine (weiche) Regel im DB-Design, niemals errechenbare Werte zu speichern. Das Alter lässt sich aus dem Geburtsdatum berechnen.

Edit 4: Können sich Adressen ändern? Soll nachvollzogen werden, wer welches Jahr wo gewohnt hat?


Duddle
 
Zuletzt bearbeitet:

scater93

Wissen´s Suchender

AW: Hilfe bei Normalisierung

1.Es besteht die möglichkeit das ein Patient im nächsten Jahr wieder kommt

2.Im Normalfall wird immer nur der PSA-A ermittelt, PSA-B und C werden nur ermittelt wenn der A etwas zu hoch ist. PSA-B und C werden dann ermittelt um Konkreter zu werden.

3.Das Datum ist im Endeffekt nur da um nachzuvollziehen, 1.Wann war der Patient schonmal da(wenn er schonmal da war) und 2. wie von dir erwähnt die Veränderung.

4. Das Alter steht mir vollkommen offen. Da kann ich selbst entscheien ob ich das Konkrete Alter Abfragen soll oder das Geburtsdatum.
 

Duddle

Posting-Frequenz: 14µHz

AW: Hilfe bei Normalisierung

2.Im Normalfall wird immer nur der PSA-A ermittelt, PSA-B und C werden nur ermittelt wenn der A etwas zu hoch ist. PSA-B und C werden dann ermittelt um Konkreter zu werden.

Also könnte ein Untersuchungsergebnis für einen Patienten auch sein "PSA-A: 10, PSA-B: nicht ermittelt, PSA-C: nicht ermittelt"? Oder sind das getrennte Labor-Vorgänge die nachvollziehbar sein sollen? D.h. soll ich ablesen können wann der PSA-A-Wert verfügbar war und dann zwei Tage später der PSA-B-Wert?

Falls du meinen letzten Edit nicht gesehen hast: Können sich Adressen ändern? Soll nachvollzogen werden, wer welches Jahr wo gewohnt hat?

Und ja, solche Fragen sind wichtig. Wenn du das Problem nicht ausreichend beschreibst, modellierst du falsch. Wenn du falsch modellierst, integrierst du falsch. Wenn du falsch integrierst verfluchst du irgendwann den Tag an dem vergessen hast das Problem ausreichend zu beschreiben.


Duddle
 

scater93

Wissen´s Suchender

AW: Hilfe bei Normalisierung

Also könnte ein Untersuchungsergebnis für einen Patienten auch sein "PSA-A: 10, PSA-B: nicht ermittelt, PSA-C: nicht ermittelt"?
Ja, dass kann auch sein. Wie gesagt B und C werden nur ermittelt wenn A zu hoch ist, damit man dann genauer sein kann.

Können sich Adressen ändern? Soll nachvollzogen werden, wer welches Jahr wo gewohnt hat?
Ja, Addressen können geändert werden. Ob aber auch nachvollzogen werden können soll wer wann wo gewohnt hat, kann ich dir leider nichts zu sagen, da muss ich dann mal nachfragen. Denke aber schon das es so ein sollte weil ja sonst wieder Inkonsistenz auftritt, oder nicht?
 

Duddle

Posting-Frequenz: 14µHz

AW: Hilfe bei Normalisierung

Genau deshalb frage ich. Manche Anwendungen müssen möglicherweise erfassen können, welche Anschrift vor 2 Jahren aktuell war, manche brauchen nur die aktuellste.

Ich habe mal ein Online-Diagramm-Tool gesucht und ein nettes gefunden in dem ich eine erste Version von einem ERM abgebildet habe. Falls du dir den Artikel durchgelesen hast, weißt du dass daraus sehr leicht das eigentliche Design abgeleitet werden kann; das würde ich machen sobald du die Frage mit den Adressen geklärt hast.

Für die Version mit stets aktueller Adresse sähe es so aus: .
Leider kann ich bei dem Tool keine numerischen Kardinalitäten einstellen, daher diese seltsamen Verbindungspfeile zwischen den Entitäten. Du kannst es aber so lesen:
  • eine PSA-Messung gehört zu exakt einem Patienten
  • ein Patient kann mehrere PSA-Messungen machen
  • eine PSA-Messung hat exakt ein PSA-Ergebnis
  • ein PSA-Ergebnis gehört zu exakt einer PSA-Messung
  • ein Patient hat exakt eine Adresse (hier müsste man ggf. modifizieren)
  • eine Adresse gehört zu exakt einem Patienten
  • eine Adresse hat exakt eine Stadt
  • eine Stadt kann mehrere Adressen haben
Die Attribute sind jeweils natürlich erweiterbar. Streng genommen könnte man noch solche Dinge wie HandyNr und TelefonNr in eine Entität "Kontaktinformation" abkapseln, die dann wieder verschieden Typen haben kann (E-Mail, HandyNr, HausNr, BüroNr, etc), aber ich wollte nicht übertreiben.

Edit: alle 1-zu-1-Beziehungen zieht man am Ende sowieso in eine Tabelle zusammen, lass dich deshalb also nicht von der Unterscheidung PSA-Messung und PSA-Ergebnis irritieren.


Duddle
 
Zuletzt bearbeitet:

SchneewittchenX

Aktives Mitglied

AW: Hilfe bei Normalisierung

Zwei Dinge fallen mir auf:
eine Adresse gehört zu exakt einem Patienten
Unsinn, schon bei einem Ehepaar stimmt das nicht, außerdem gibt es in Deutschland ja nicht nur Einfamilienhäuser ;)
Das Alter sollte, wie schon erwähnt, in keinem Fall in der Datenbank gespeichert werden. Nicht nur, weil es errechenbar ist, sondern zeitabhängig veränderlich.
Also immer das komplette Geburtsdatum oder das Geburtsjahr, denn die DB wird doch nicht nur ein einziges Jahr benutzt, Oder? Damit ändert sich das Alter, aber nicht das Geburtsdatum.

Wie könnte es dann aussehen:

1. Tabelle (beschreibt den Patienten):
pat_id(also der wievielte patient) ;
pat_vorname ;
pat_nachname ;
pat_Geburtsjahr;
pat_straße ;
pat_hn(Hausnummer) ;
pat_plz ;
pat_ort;
pat_Telefon;
pat_Handy;

Ein Patient hat nur eine Adresse und wenn er umzieht, ist die alte hier wahrscheinlich nicht von Belang, gilt auch für die Telefonnummern, sonst jeweils extra-Tabelle mit pat_id und zusätzlicher Tabellen_id für die Eindeutigkeit des DS. Bei Telefonen könnten dann auch weitere erfasst werde. Bei Privatpersonen reichen aber meist diese 2. (pat_it; tel_id, tel_art vom Typ Set oder pro Patient durchnummerieren, Telefonnummer) für unendlich viele Telefon- und Faxnumern pro Patient.

2.Tabelle (Untersuchungsdaten), wenn psa_b und c an anderen Tagen ermittelt werden, dann ebenfalls Datum erfassen, wobei dann hier noch mal normalisiert werden könnte.
pat_id;
pat_barcode ;
pat_untersuchungsdatum;
pat_psa_a ;
pat_psa_b ;
pat_psa_c ;

Wie ist das eigentlich mit dem Barcode? Hat der Patient für alle Untersuchungen den gleichen Code oder jedes mal einen Neuen? Ich bin von Letzterem ausgegangen.

Nachschlagetabellen für Ort und Straße (Fertige Tabellen für ganz Deutschland im Netz erhältlich, sicher weitere Felder vorhanden), kommen die Patienten nur aus einer Stadt, könnte man auch Tabellen mit Straßennamen verwenden, dann aber eher im Formular als Auswahlliste, wichtiger als das vollständige Vermeiden von Redundanzen ist die Sicherung der Integrität der Daten, eventuell 2 Tabellen:
plz ;
ort ;
strasse;
hausnummer; (bei einigen PLZ's wichtig)
weitere Felder sind bei solchen Nachschlagetabellen vorhanden

Klar könnte man in Tabelle 1 auch nur ID-Nummern für Ort und Straße eintragen, ändert aber nichts an der Redundanz, macht aber die Arbeit aufwendiger.
Allerdings zeigt sich der Vorteil bei Straßen- und Ortsumbenennungen: In der Patiententabelle bräuchte dann nichts aktualisiert zu werden.
Schau mal hier: und
http://opengeodb.org/wiki/OpenGeoDB_Downloads
(Quelle: )

Robby's Vorschlag ist dann überflüssig. Da sich Tübingen ohne H schreibt, würde man die Leute auch mit der angegebenen Funktion nicht finden. ;)
Man kann einfach nicht alle Schreibfehler abfangen, wenn freie Texteingabe erlaubt ist. Nachschlaglisten bei der Eingabe (und der Suche) sind da die bessere Wahl


PS: In der Praxis gibt es doch auf jeden Fall schon ein Patientenerfassungsprogramm, bei dem jeder Patient mit seiner Karte und der Versichertennummer erfasst wird. Damit hätte man doch sofort Zugriff auf die notwendigen Daten.
Warum soll jetzt alles noch mal erfasst werden? Erfolgt die Leistung nur für Nicht-Patienten der Praxis?
Sinnvoller als eigene DB oder Excel ist doch das Anflanschen an die bestehende Software. Wenn das während der Aktion nicht möglich ist, reicht aber das Erfassen der Versichertennummer.
 
Zuletzt bearbeitet:

Duddle

Posting-Frequenz: 14µHz

AW: Hilfe bei Normalisierung

pat_vorname ;
pat_nachname ;
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.

Vergleich das mit einer Adresse: hier haben PLZ, Ort, Hausnr. eindeutig unterscheidbare und wiederkehrende Funktionen. Bei einem Namen ist das nicht mehr möglich.

eine Adresse gehört zu exakt einem Patienten
Unsinn, schon bei einem Ehepaar stimmt das nicht, außerdem gibt es in Deutschland ja nicht nur Einfamilienhäuser
Okay, das stimmt.
Das sollte sich dann aber auch in deiner Tabelle zeigen. Wenn du die Adresse in die Patienten-Tabelle ziehst hast du selbst implizit eine 1:1-Beziehung erzeugt. Ausserdem kannst du dann nicht mehr nachvollziehen, wie sich die Adresse eines Patienten geändert hat, was laut dem Thread-Starter mglw. notwendig ist.


Den Barcode hab ich gestern Abend vergessen. Ich verstehe folgendes
Daher auch die Spalte Barcode, da diese nähmlich vom Labor selbst kommen. Jeder patient bekommt also einen Individuellen Barcode dem dann die PSA Werte zugeordnet werden können.
auch so, dass jeder Patient bei jeder Untersuchung (unabhängig vom Jahr) den gleichen Barcode benutzt.
Falls ja würde ich es trotzdem nicht gern an den Patienten hängen, besonders falls die Patienten-Tabelle in einem anderen Kontext als zur Verwaltung von PSA-Messungen verwendet werden soll. Meiner Meinung nach ist der Barcode ein Attribut der Messung, da sie erst einen Barcode notwendig macht. Falls sich der Barcode ändert, dann sowieso. Naja, da werde ich nochmal drüber nachdenken.

Edit: Meinung geändert. Falls der Barcode pro Patient immer der selbe ist, sollte er auch dem Patienten als Attribut zugewiesen werden, sonst würde die 3te NF verletzt werden (Barcode wäre transitiv abhängig von der Patienten-ID).

Falls der Barcode anders zu verstehen ist müsste scater93 das nochmal genauer spezifizieren.


Duddle
 
Zuletzt bearbeitet:

scater93

Wissen´s Suchender

AW: Hilfe bei Normalisierung

Der barcode wird bei jeder Untersuchung neu ausgegeben d.h. jedes Jahr hat 1 Patient 1 barcode dem die PSA Werte zugeordnet werden.

Der Ablauf is folgender:
1. Patient kommt zu uns und trägt sich ein. Dabei bekommt er einen barcode auf einen Zettel mit seinen Anmeldedaten, und den Selben barcode nochmal, der dann auf die Röhrschen mit den Blutproben kommen.
2. Dann bekommt das Labor die Blutproben mit den Barcodes drauf und ordnet ihnen dann die Psa werte zu.
3. Wir erhalten die Tabelle mit den Psa Werten zurück und erstellen dann einen Brief mit den Daten an den Patient in dem das Ergebniss der Untersuchung steht


Edit:
Nötig währen Teohretisch also nur die Patienten + Addressen + die Werte

Ich hab mir heute aber mal weiter Gedanken gemacht.

Meine Überlegung wäre jetzt, das man die Patienten sozusagen als angelegte Accounts betrachtet. D.h. der Patient kommt, und sagt "Ich möchte gerne Untersucht werden". Dann geht der "Bearbeiter" hin und legt einen "Account" an z.b. mit dem Namen "franz.muster". Dort trägt er (Der Bearbeiter) dann Vorname, Nachname, Geb. Datum, Straße, HN, Plz(Ort läßt sich daraus ableiten).
Dann würde z.B. noch eine Tabelle dazu kommen, in welchen Jahren der Patient schon mal da war.
Dann würde der Patient in jedem Jahr einen Barcode bekommen der dann speziefisch für die Im jeweiligen Jahr genommenen Messungen gellten würde
( also 2011 ist PSA-A 34 und 2012 ist PSA-B 21).

Das müsste es eigentlich gewesen sein, wir haben Name, Addresse, Wir Wissen wann der Patient da war bzw. wann er schonmal da war und wir haben für die Jeweiligen Jahre für die Patienten die zugeordneten werte.

Im Prinzip müsste das doch funktionieren oder?
 
Zuletzt bearbeitet:

Duddle

Posting-Frequenz: 14µHz

AW: Hilfe bei Normalisierung

Im Endeffekt ist es ja egal, wer was wie reinschreibt. Das wichtige ist im Moment das Modell deiner Datenbank, und das ist fast fertig.

Wenn der Barcode jedes Jahr einem Patienten neu erzeugt wird gehört er definitiv in die PSA-Messung, das würde ich im ERM nochmal ergänzen.

Letzte Frage: möchtest du nun geänderte Adressen mitnehmen, d.h. willst du die unterscheiden können, wie sich die Adressen über die Zeit geändert haben?


Duddle
 
Bilder bitte hier hochladen und danach über das Bild-Icon (Direktlink vorher kopieren) platzieren.
Antworten auf deine Fragen:
Neues Thema erstellen

Willkommen auf PSD-Tutorials.de

In unseren Foren vernetzt du dich mit anderen Personen, um dich rund um die Themen Fotografie, Grafik, Gestaltung, Bildbearbeitung und 3D auszutauschen. Außerdem schalten wir für dich regelmäßig kostenlose Inhalte frei. Liebe Grüße senden dir die PSD-Gründer Stefan und Matthias Petri aus Waren an der Müritz. Hier erfährst du mehr über uns.

Stefan und Matthias Petri von PSD-Tutorials.de

Nächster neuer Gratisinhalt

03
Stunden
:
:
25
Minuten
:
:
19
Sekunden

Neueste Themen & Antworten

Flatrate für Tutorials, Assets, Vorlagen

Zurzeit aktive Besucher

Statistik des Forums

Themen
118.619
Beiträge
1.538.363
Mitglieder
67.540
Neuestes Mitglied
Alex Weidner
Oben