family, if sub, if main

[Thomas Berger]

Sibylle Koczian wrote:
> 
> Lieber Herr Berger,
> 
> At 13:15 08.04.02 +0300, you wrote:
> >Liebe Frau Koczian,
> >
> > > bei Aufnahmen, die ueber #09 verknuepft sind, scheint bei mehr als zwei
> > > Stufen folgendes zu passieren:
> >
> >Es ist nicht ganz klar, was Sie meinen, weil #09 in
> >unterschiedlichen Bedeutungen benutzt werden kann:
> ><<<
> >   D-1.APR     970721
> >   1. a) ...
> >      b) Verknüpfungen per #09 IdNr+xxx  (1stufig aufwärts, Pica)
> >      c) Verknüpfungen per #00 IdNr+xxx+xxx+...  (mehrstufig)
> > >>>
> 
> Gemeint ist 1. b). In 1 c) kommt #09 doch gar nicht vor???

Oops. Stimmt. Gemeint hatte ich die Definition von #09
im allegro-Format '99:

[1d)] #09 Identnummer des übergeordneten Hauptsatzes [für
          konvertierte Pica-Daten wichtig] 
          ...
          Form: HauptNr+SBNr[+STNr=VBNr] (Identnummer der übergeordn.
          HauptAufn, Sortierbare BandNr., Sortierbare TeilNr (für
          Verknüpfung über Index); die Vorlageform der BandNr ist
          für Anzeige und Druck bestimmt.)


> > > Soweit nachvollziehbar und wie erwartet. Nicht ganz wie erwartet:
> > >
> > > - von einer Aufnahme der mittleren Stufe bekommt man die Hauptaufnahme und
> > > die Aufnahmen der mittleren Stufe, aber nicht die der Ausgangsaufnahme
> > > untergeordneten. Abfragen "if main", "if sub" ergeben das gleiche: die
> > > Aufnahme wird als verknuepfte Unteraufnahme betrachtet, dass sie ihrerseits
> > > auch Hauptaufnahme zu anderen Unteraufnahmen ist, wird nicht
> > beruecksichtigt.
> >
> >Und das weist fuer mich eigentlich darauf hin, dass es sich
> >um nach Methode 1c jeweils mit der obersten Hauptaufnahme
> >verknuepfte Saetze der untersten Stufen handelt.
> >
> >Diese widerspruechlichen Hinweise loesen sich auf, wenn man
> >bedenkt, dass diese "Schluesse" nach folgender Logik zustande
> >kamen, in PRESTO uebersetzt: Einelementige Ergebnismenge aus
> >dem aktuellen Satz bilden, dann "&" um mit Schiller-Raeuber
> >die Verknuepfungen herbeizuholen.
> 
> Mir war bisher ueberhaupt nicht klar, wie die "Familie" gebildet wird. Aber
> wenn einerseits zur Hauptaufnahme die naechsten Unteraufnahmen und zur
> Unteraufnahme die direkt uebergeordnete Hauptaufnahme und die "Geschwister"
> gefunden werden - dann ist es doch eigentlich allemal folgerichtig, bei
> einer mittleren Ebene zu erwarten, dass sowohl die uebergeordnete als auch
> die direkt untergeordnete Ebene erwischt wird. Auch ohne Wissen ueber den
> benutzten Algorithmus - oder nicht?

eigentlich ist zu erwarten ("family" ist von der WinIBW abgekupfert),
dass alle Urgrosseltern, Cousins etc. geliefert werden, d.h. alle
untergeordneten Aufnahmen zur abstraktesten findbaren uebergeordneten
Aufnahme, also auch durchaus 5fach indirekt bei komplizierten Werken
(zwo hoch, drei runter)


> >Dies allerdings, wenn Sie wie in der cat.api #09 als
> >staerkeren, ersten Primaerschluessel einsetzen. Wird
> >#00 als erster Primaerschluessel benutzt, sollte man
> >besser direkt auf die explizite Form der Familienbildung
> >durch Vorbesetzung der iV durch "|n<Schluesselanfang>"
> >ausweichen.
> >
> 
> #00 ist Primaerschluessel (weil garantiert eindeutig, bei #09 gibt's bei
> DDB-Daten gelegentlich Ausreisser). #09 ergibt einen weiteren Eintrag. Und
> deshalb scheint mir Ihre Erklaerung meine Beobachtungen gerade nicht zu
> erklaeren. Beispiel:
> 
> 1.
> #00 123
> #20 Gesammeltes Allegro
> 
> 2.
> #00 234
> #09 123+1
> ...
> 
> 3.
> #00 235
> #09 234+1
> 
> Da muesste die von 2. aus gebildete Familie aus 2. und 3. bestehen (alle
> Schluessel mit 234.. im Primaerschluesselregister), und 1. fiele unter den
> Tisch. Aber tatsaechlich fehlt 3. und 1. wird gefunden. Die #09 muss also
> herangezogen werden, obwohl sie nicht Primaerschluessel ist. Dafuer werden
> anscheinend, wenn #09 belegt, die mit dem Inhalt von #00 beginnenden
> Eintraege nicht mehr gesucht ???

Zur Kontrolle: Diese drei Saetze in die Demodatenbank eingegeben,
den mittleren (2.) in die Anzeige geholt und "x Fam" eingegeben:
Die gebildete Ergebnismenge besteht aus Satz 1. und 2., sowie 
aus den Saetzen mit den Identnummern 123056225 und 123638.
D.h. ich kann Ihre Beobachtung bestaetigen.
Ich behaupte aber immer noch, dass dies in der Demodatenbank daran
liegt, dass der erste bei #-@ gebildete Primaerschluessel aus #09
aufgebaut wird. 

Beweis: drehe ich bei #-@ in der cat.api die beiden Zeilen
(mutatis mutandem) um, d.h. mache #00 zum ersten Primaerschluessel,
so ergibt "x Fam" ausgehend von Satz 2. die Ergebnismenge aus 2.
und 3. sowie aus den Saetzen mit den Identnummern 234175370 und
234485616.

viele Gruesse
Thomas Berger