Download
1 / 12
120 likes | 198 Views
Flache Datenstrukturen in der Operationsdokumentation. Definition. Eine Datenbank ist eine Gruppe von Tabellen, die durch Relationen verknüpft sind. Eine Tabelle besteht aus Feldern (Spalten) und Datensätzen (Zeilen).
E N D
Definition • Eine Datenbank ist eine Gruppe von Tabellen, die durch Relationen verknüpft sind. • Eine Tabelle besteht aus Feldern (Spalten) und Datensätzen (Zeilen). • Flache Datenstrukturen zeichnen sich durch eine hohe Anzahl von Feldern und eine vergleichsweise geringe Anzahl von Datensätzen aus, die nicht weiter normalisiert werden können. • Typischerweise enthalten FDS große Redundanzen an nicht benutzten Feldern pro Datensatz.
Wo gibt es flache Datenstrukturen? • FDS trifft man vor allem in der medizinischen Dokumentation bzw. Operationsdokumentation. • Die hohe Anzahl der Merkmale (Felder) ergibt sich aus der Komplexität der medizinischen Fachgebiete. • Die Notwendigkeit eine strukturierten Datenerfassung ergibt sich aus dem Wunsch nach statistischen Auswertungen sowie nach hierarchisch strukturierter und validierter Dateneingabe. • Die 1:1 Beziehung zwischen Merkmal und Patient bedingt das Fehlen relationaler Strukturen. • Redundanzen folgen daraus, daß jeder Patient nur einen bestimmten Teilaspekt des Gesamtsystems abdeckt. Ca. 95% der Felder werden im Einzelfall nicht gebraucht.
Welche spezifischen Aufgaben ergeben sich aus FDS? • Fachwissen • Systemanalyse • Aufgabenverteilung • Datenbank • Datenerfassung • Auswertung
Fachwissen • Das medizinische Fachwissen ist immens und für den EDV-Fachmann kaum erlernbar, ebenso ist die Kompetenzanforderung an den Programmierer hoch und nicht durch einen Arzt im Schnellgang aufzuholen. • Am Markt werden Lösungen von EDV-kompetenten Fachmedizinern oder im Team erarbeitete Lösungen angeboten. • Lösungen sollten die Kompetenzverteilung berücksichtigen und an Ort und Stelle belassen.
Systemanalyse • Bereits in der Systemanalyse ist der EDV-Fachmann regelmäßig überfordert. • Budgets werden nur geschätzt, da die Kompetenzen fehlen um realitätsnah und zuverlässig zu budgetieren. • Die klassische Reihenfolge: Systemanalyse, Budgetierung, Umsetzung ist nicht machbar. • Die Systemanalyse muss in die Umsetzung integriert werden, das System muss also von vornherein ‚offen‘ für Veränderungen programmiert werden.
FDS – Datenbank • Die Anzahl der Felder einer Tabelle ist im Normalfall auf 255 beschränkt. Tausende von Feldern erfordern demnach dutzende von Tabellen, die durch Relationen verknüpft sind. • Alternativ können die Merkmale in einer einzigen Tabelle gespeichert werden. Daten werden umgebrochen, vgl. Tabellendesigner VFP. Die Beziehung zwischen Feldern und Datensätzen wird ‚auf den Kopf gestellt‘.
Datenerfassung • Wie bekomme ich tausende von Feldern auf eine Bildschirmseite? • Dynamischer Bildschirmaufbau statt fester Programmierung. • Dynamische Objekte haben drei Anzeige-Modi zur effektiven Nutzung der Bildschirmfläche. • Hierarchische Strukturen, Datenobjektbäume, Eltern-Kind Beziehungen. • Validierung im Datenobjektbaum. • Kopieren von Standardobjekten und ihren ‚Familien‘.
Datenerfassung/Programmierung • Wo ist denn hier die controlsource? • Arrays als Datenpuffer. • Container und Objekte. • Modi umschalten. • Offenes Datenmodell. • Validierung.
Der OP-Bericht • Daten vom Kopf auf die Füße stellen. • Spaltenlayout. • Wer gestaltet den OP-Bericht? Aufgabenverteilung und Programmierung. • Patienten-Stammdaten.
Abfragen • Das Zurückführen der FDS in normalisierte Tabellen. • Relationen ade? • Einfache Abfragen. • Komplexe Abfragen. • Aufteilen komplexer Abfragen. • Aufgabenverteilung.
Zeichnen mit VFP? • VFP ist kein Zeichenprogramm, aber... • Schemen (Folien) und Symbole. • Zeichnungen ‚speichern‘. • Bitmaps herstellen und drucken. • Datensensitives Zeichnen, hier wird der Fuchs wieder stark. • Grenzen des Zeichnens mit VFP.
