Papyrus-Base: Relationen automatisch wiederherstellen

Hallo!

Ich habe ein Problem bei meiner Chemikalien(verwaltungs)-Datenbank.

Es gibt folgende Tabellen:

  1. Chemikalienverwaltung
  2. Entsorgung
  3. Bestellung
  4. Experimenteverwaltung
  5. Chemikalien
  6. Lieferanten
  7. Sachbearbeiter
  8. Zeichnungsberechtigte
  9. H-Sätze
  10. P-Sätze
  11. EUH-Sätze
  12. Gestis
  13. UN-Nummern
  14. DSSTOX
  15. 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… :wink:

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.

2 „Gefällt mir“

Hallo glucose!

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. :face_with_spiral_eyes:rage:Ulli

Papyrus hätte im naturwissenschaftlichen Bereich einiges an Potential.

LG Manfred

4 „Gefällt mir“

Ich denke nicht, dass es die Aufgabe der Papyrus-Dokumentation ist, uns die Grundlagen des Datenbank-Designs zu vermitteln. :smiley: :wink:

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 :wink:

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”

2 „Gefällt mir“

Hallo glucose!

Das hat funktioniert!
Nur die, die ich schon mit internem Zeiger verknüpft habe, hat es zerlegt (CAS-Nr. gelöscht).

1 „Gefällt mir“

Naja - das ist klar, dass es da Probleme gibt, wenn unterschiedliche Verknüpfungen kollidieren.

1 „Gefällt mir“

Hallo Stephan!

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.

2 „Gefällt mir“

War auch einfach mal ein Versuch was passiert, beim Wechsel der Relationsart.
Wenn man es vorher in „feste Einträge“ umwandelt passiert das nicht. :smirk:

Gröhl - ja davon habe ich auch gehört :wink:
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 :slight_smile:

2 „Gefällt mir“

Hallo @glucose & @Stephan Zoellner!

Es hat geklappt!

Ich habe die Relation auf „explizites Schlüsselfeld“ geändert. Papyrus hat dann eine »Pause« von ca. 20 Minuten eingelegt (i7 4 x 2,1 GHz & 8 GB RAM).

Das Ergebnis war eine im Schneckentempo arbeitende Datenbank.

Scrollen in der Gestis-Tabelle war mit viel Geduld verbunden.

Als experimentierfreudiger Chemielaborant habe ich dann die Relation wieder auf „interner Zeiger“ geändert.

Nach einer weiteren »Denkpause« (ca. 20 Minuten) war es vollbracht.

Die Relation blieb, nach der erneuten Umwandlung, erhalten – Gestis- und DSSTOX-Tabelle sind nun verknüpft, es läuft alles wieder zügig.

Ich bedanke mich für die Hilfe!

PS: Nicht vergessen –> Backup, Backup…

3 „Gefällt mir“

Cool! Aber irgendwas läuft bei der Wandlung nicht optimal. Zum Glück braucht man das nicht oft.

3 „Gefällt mir“

Ja, die Wandlung ist wirklich nicht optimal.

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.

1 „Gefällt mir“

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 :wink:

1 „Gefällt mir“