Ich habe ein Problem bei meiner Chemikalien(verwaltungs)-Datenbank.
Es gibt folgende Tabellen:
Chemikalienverwaltung
Entsorgung
Bestellung
Experimenteverwaltung
Chemikalien
Lieferanten
Sachbearbeiter
Zeichnungsberechtigte
H-Sätze
P-Sätze
EUH-Sätze
Gestis
UN-Nummern
DSSTOX
Strukturformeln
Es gibt für jeden chemischen Stoff eine sog. CAS-Nummer (Chemical Abstracts Service).
Über diese CAS-Nr. werden durch Relationen Daten zusammengeführt.
Nun wollte ich, dass in der Gestis-Tabelle über die CAS-Nr. automatisch die DSSTOX-ID aus der DSSTOX-Tabelle geholt werden.
Das Problem besteht nun darin, dass die Verknüpfung der Datensätze nicht automatisch erfolgt. Die Datensätze gab es in den entsprechenden Tabellen schon vor der Relation. Ich müsste jeden Datensatz in der Gestis-Tabelle öffnen und aktiv mit dem entsprechenden Datensatz in der DSSTOX-Tabelle verknüpfen.
Bei 100–200 Datensätzen würde ich das auch genauso machen, die Gestis-Tabelle hat allerdings 8121 Datensätze mit CAS-Nr.
Gibt es eine Möglichkeit in Papyrus Base, die Relationen in einem Durchgang wiederherzustellen?
PS: Man muss ein Problem auch immer positiv betrachten! Ich bin daher froh, dass die Gestis-Tabelle nicht die DSSTOX-Tabelle ist. Die hätte nämlich 738765 Datensätze mit CAS-Nr…
Wie hast Du die Relation angelegt? Als Papyrus-internen Zeiger auf den Quelldatensatz oder als sichtbares , explizites Schlüsselfeld? Siehe Feldeigenschaften > Relationen > Ändern
Bei explizitem Schlüsselfeld könnte es funktionieren (hab’s aber nie probiert), bei internem Zeiger könnte man die Verknüpfung nur mit einem Texteditor oder einem Textwerkzeug wie sed oder awk schaffen, weil man an die internen Zeigernummern rankommen muss.
Die Relation habe ich als interner Zeiger angelegt. Ich probiere es die Tage mal als Schlüsselfeld.
Mit einem Texteditor (Notepad ++) habe ich mal die Reihenfolge der Tabellen geändert, da Papyrus dies (noch) nicht kann. Hat wunderbar funktioniert. Man muss nur wissen, welche IDs was bedeuten.
Es ist schade, dass es dazu keine Dokumentation gibt. rage:Ulli
Papyrus hätte im naturwissenschaftlichen Bereich einiges an Potential.
Ich denke nicht, dass es die Aufgabe der Papyrus-Dokumentation ist, uns die Grundlagen des Datenbank-Designs zu vermitteln.
Relationen müssen IMMER über ein Schlüsselfeld (Kandidat-Key) angelegt werden und auf einen anderen Schlüssel (Primary-Key) verweisen. Das heißt, die Verknüpfung wird beim Datenbank-Design angelegt. Lange bevor Daten in die Tabellen kommen. Das nachträgliche Hinzufügen der logischen Integritätsregeln scheitert häufig an einzelnen Datensätzen, die nicht den Regeln entsprechen. Liegt ein einziger solcher defekten Datensätze vor, wird die ganze Aktion (Verknüpfung hinzufügen) abgelehnt!
Wenn aber die logische Verknüpfung vor dem Dateninput erfolgt ist, dann werden nur die Datensätze abgelehnt, die den Integritätsregeln nicht entsprechen.
Dabei ist die Reihenfolge, in der die Daten (-tabellen) eingefügt werden, absolut entscheidend!
Diese Reihenfolge wird beim Datenbank-Entwurf durch die Logik der Verknüpfung und Abhängigkeiten festgelegt.
In SQL kann ich Dir das noch heute weitgehend auswendig “runterbeten” nachdem ich Datenbank-Design und SQL einige Jahre unterrichtet habe. Ich müsste mir nur die konkrete Syntax der modernen SQL-Befehle nochmal anschauen
Du kannst Dein Problem vermutlich dadurch lösen, indem Du die Daten einmal komplett exportierst, die DB leerst. Die DB-Konstruktion sauber aufsetzt und die Daten in der korrekten Reihenfolge wieder einfügst. Dann müßte alles klappen.
In SQL habe ich mir immer die entsprechenden komplett-Scripte zum Erzeugen der Basis-DB mit allen Basis-Daten erstellt und abgespeichert. Dann konnte ich die Daten bei Design-Änderungen immer wieder sortiert “hochziehen”
Es wäre aber nicht schlecht, wenn die Dokumentation etwas zum Design und Vorgehen sagen würde, muss ja kein Base/SQL-intensiv-Kurs sein.
Die Planung ist mir bekannt und ich mach das eigentlich auch so, wie von dir beschrieben.
Nur habe ich nicht die alleinige Entscheidungskompetenz, was in diese Datenbank einfließen soll. In den letzten vier Jahren hatten wir drei Wechsel unserer Fachkraft für Arbeitssicherheit (FaSi) → Jedes Mal mit nachträglichen Änderungen in der Datenbank.
Da kann ich nicht viel planen, jede FaSi möchte es anders haben.
Dann gibt es noch Vorgesetzte bei denen man froh sein kann, wenn die sich nicht mit der Computer-Maus selbst verletzen.
Es gibt dieses “eindeutige Schlüsselfeld (CAS-Nr)” in der Gestis-Tabelle und auch in der DSSTOX-Tabelle. Diese CAS-Nr kommt in den Tabellen Gestis und DSSTOX jeweils nur einmal vor. Deshalb dürfte es keine Probleme mit der Integrität geben.
Gröhl - ja davon habe ich auch gehört
Nein, im Ernst: Eine alte Bekannte hat in einem UNI-Institut bei einem Professor gearbeitet und ich habe ihr per Telefon und später auch mit Datenaustausch geholfen, ihre Formulare EXAKT zu formatieren, damit die vorgeschriebenen Faltmarken vorhanden sind. “Ihr Professor” hatte öfter Probleme mit dem Rechner, aber beiden mußte ich erst beibringen zwischen Anwendung (Word) und dem Betriebssystem (Windows) zu unterscheiden. Damals gab es noch kein Team-View, sondern nur das Telefon oder Disketten zum Datenaustausch …
Ich plane einen EDV-Kurs für Leute, die auf Kriegsfuß mit der EDV stehen, denn das Problem gibt es heute immer noch!
Mal sehen, was die VHS-Wesel dazu sagt
Es ist noch etwas seltsames passiert.
Die CAS-Nr. in der Gestis-Tabelle wurden in feste Einträge gewandelt (rötliche Schrift, weißer Hintergrund), die DSSTOX-ID ist als Relation angelegt (blaue Schrift, grauer Hintergrund) worden.
In der Chemikalien-Tabelle sind bei 25 Datensätzen die CAS-, EG-Nr. etc. rausgeflogen. Bei allen weiteren 662 Datensätzen ist das nicht passiert. Obwohl alle Registriernummern aus der Gestis-Tabelle kommen.
Vermutlich macht es durchaus Sinn, die Verknüpfung schon beim Erzeugen der DB anzulegen.
Das müßte ich in dem Fall ausprobieren. Aber das reizt mich jetzt so ganz und gar nicht
rage:Ulli
