PSD-Tutorials.de
Forum für Design, Fotografie & Bildbearbeitung
Tutkit
Agentur
Hilfe
Kontakt
Start
Forum
Aktuelles
Besonderer Inhalt
Foren durchsuchen
Tutorials
News
Anmelden
Kostenlos registrieren
Aktuelles
Suche
Suche
Nur Titel durchsuchen
Von:
Menü
Anmelden
Kostenlos registrieren
App installieren
Installieren
JavaScript ist deaktiviert. Für eine bessere Darstellung aktiviere bitte JavaScript in deinem Browser, bevor du fortfährst.
Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden.
Du solltest ein Upgrade durchführen oder einen
alternativen Browser
verwenden.
Antworten auf deine Fragen:
Neues Thema erstellen
Start
Forum
Sonstiges
Webdesign, Webentwicklung & Programmierung
PHP, Javascript, jQuery, Ajax, nodeJS, MySQL...
Hilfe bei Normalisierung
Beitrag
<blockquote data-quote="SchneewittchenX" data-source="post: 2044074" data-attributes="member: 168344"><p><strong>AW: Hilfe bei Normalisierung</strong></p><p></p><p>Zwei Dinge fallen mir auf:</p><p>Unsinn, schon bei einem Ehepaar stimmt das nicht, außerdem gibt es in Deutschland ja nicht nur Einfamilienhäuser <img src="/styles/default/xenforo/smilies/zwinker.gif" class="smilie" loading="lazy" alt=";)" title="Wink ;)" data-shortname=";)" /></p><p>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.</p><p>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.</p><p></p><p>Wie könnte es dann aussehen:</p><p></p><p><strong>1. Tabelle (beschreibt den Patienten): </strong></p><p>pat_id(also der wievielte patient) ;</p><p>pat_vorname ;</p><p>pat_nachname ;</p><p>pat_Geburtsjahr;</p><p>pat_straße ;</p><p>pat_hn(Hausnummer) ;</p><p>pat_plz ;</p><p>pat_ort;</p><p>pat_Telefon;</p><p>pat_Handy;</p><p></p><p>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.</p><p></p><p><strong>2.Tabelle </strong>(Untersuchungsdaten), wenn psa_b und c an anderen Tagen ermittelt werden, dann ebenfalls Datum erfassen, wobei dann hier noch mal normalisiert werden könnte.</p><p>pat_id;</p><p>pat_barcode ;</p><p>pat_untersuchungsdatum;</p><p>pat_psa_a ;</p><p>pat_psa_b ;</p><p>pat_psa_c ; </p><p></p><p>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.</p><p></p><p>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:</p><p>plz ;</p><p>ort ;</p><p>strasse;</p><p>hausnummer; (bei einigen PLZ's wichtig)</p><p>weitere Felder sind bei solchen Nachschlagetabellen vorhanden</p><p></p><p>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. </p><p>Allerdings zeigt sich der Vorteil bei Straßen- und Ortsumbenennungen: In der Patiententabelle bräuchte dann nichts aktualisiert zu werden.</p><p>Schau mal hier: und </p><p><a href="http://opengeodb.org/wiki/OpenGeoDB_Downloads" target="_blank">http://opengeodb.org/wiki/OpenGeoDB_Downloads</a></p><p>(Quelle: )</p><p></p><p>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. <img src="/styles/default/xenforo/smilies/zwinker.gif" class="smilie" loading="lazy" alt=";)" title="Wink ;)" data-shortname=";)" /></p><p>Man kann einfach nicht alle Schreibfehler abfangen, wenn freie Texteingabe erlaubt ist. Nachschlaglisten bei der Eingabe (und der Suche) sind da die bessere Wahl</p><p></p><p></p><p>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.</p><p>Warum soll jetzt alles noch mal erfasst werden? Erfolgt die Leistung nur für Nicht-Patienten der Praxis?</p><p>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.</p></blockquote><p></p>
[QUOTE="SchneewittchenX, post: 2044074, member: 168344"] [b]AW: Hilfe bei Normalisierung[/b] Zwei Dinge fallen mir auf: 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: [B]1. Tabelle (beschreibt den Patienten): [/B] 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. [B]2.Tabelle [/B](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 [URL]http://opengeodb.org/wiki/OpenGeoDB_Downloads[/URL] (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. [/QUOTE]
Bilder bitte
hier hochladen
und danach über das Bild-Icon (Direktlink vorher kopieren) platzieren.
Zitate einfügen…
Authentifizierung
Wenn ★ = 12, ◇ = 4 und die Hälfte von ★ zu ◇ addiert wird, was ist das Ergebnis?
Antworten
Start
Forum
Sonstiges
Webdesign, Webentwicklung & Programmierung
PHP, Javascript, jQuery, Ajax, nodeJS, MySQL...
Hilfe bei Normalisierung
Oben