Hjem › Navigatører › 1c få hierarkinivået i forespørselen. Operatoren "i hierarki" i en spørring. Ytelsespåvirkning

1c få hierarkinivået i forespørselen. Operatoren "i hierarki" i en spørring. Ytelsespåvirkning

Ildarovich 6489 16.11.12 18:24 Aktuelt på temaet

() Vladimir! Jeg er glad for at du tok hensyn til artikkelen, spesielt siden du var en av de første som så (og satte pris på) denne teknikken i diskusjonen for to år siden "Det er realistisk å skrive en vanskelig spørring." Jeg kom ikke med et interessant spørsmål på egen hånd, men så det på forumet. Forfatteren av spørsmålet er Stanislav Sheptalov. Neste - den 10/24/12 stilte den samme (har nettopp lagt merke til dette, siden kallenavnet er annerledes) forumdeltakeren et lignende spørsmål, men i søknaden til hierarkiet. Det viser seg at det PRAKTISKE problemet er løst. Videre, i samsvar med den "vitenskapelige" tilnærmingen, så jeg på praktiske problemer der denne teknikken kunne brukes. Fant 7 problemer til. 5 - i denne artikkelen. Blant dem er problemet med sykluser i spesifikasjoner, som jeg tidligere lovet å løse Ish_2 med en spørring. Jeg tror Ish_2 vil være i stand til å overbevise deg om relevansen av denne oppgaven – han brukte mye tid på den. Løsningen er kort - noen få linjer, derfor ekstremt klare, formulert i en ikke-prosessuell stil, gjennom et krav til resultatet. Vel, andre problemer ble møtt i artikler og på forumet, og mer tungvinte løsninger ble foreslått for dem. Så la oss vente en stund for å se hvor ofte dette vil bli brukt. Det er akkurat sånne tilbakemeldinger jeg forventer – fra de som skal prøve.
Forresten, det faktum at denne grenen av matematikk ikke er langt fra praksis og er nødvendig av regnskapsførere, er bevist av den generelle modulen "Kostnadsjustering" i BP2, som vi for tiden fikser med (ustabil drift av standardforespørselen). Der snakker vi om å bryte syklusene til objektbevegelsesgrafen og bygge et spenntre.
Nå om strukturen til databasen "for en bestemt oppgave". Spørsmålet ble stilt om implementeringen av oppgaven i 1C, og derfor ble oppgaven løst i 1C. Hvis du ble spurt "hvilken buss kan du ta for å komme til biblioteket," og du svarte at det er bedre å fly på et luftskip, ville du rett og slett ikke bli forstått (kanskje bortsett fra de som sitter fast i en trafikkork i Moskva ). Til å begynne med fungerte metoden på et helt annet språk.
Generelt vil jeg ikke være i stand til å overbevise deg hvis du mener at arkitekturen til 1C-plattformen ikke er bra. Jeg kan bare si min mening. Å utvikle et databaseskjema fra bunnen av for en spesifikk oppgave er dyrt. Hvis vi sammenligner det med konstruksjon: 1C er panel høyhus - billig bolig - et middel for masseautomatisering - i trange forhold, men ingen lovbrudd. Individuelle organisasjoner kan ansette Norman Foster for å implementere kravene deres nøyaktig. Resten må bruke billige masseproduserte prosjekter – relasjonelle DBMS-er med en rigid objektmodell. I tillegg er jeg kjent med den triste opplevelsen av å bruke Cashe i flere prosjekter. Gjennom øynene til en utvikler ser ikke alt så rosenrødt ut som det gjør i teorien. 1C-objektmodellen tåler tidens tann - "store territorier bygges opp og bebos." Dessuten er det i utvikling. Nylig har teknologien til eksterne datakilder dukket opp. Og hvis en oppgave krever høyere reaktivitet (for eksempel faktureringssystemer), kan du nå sømløst koble 1C med et annet DBMS. Det er for eksempel slik vi bytter med importert ERP.
Men likevel vil jeg ikke avlede samtalen fra hovedemnet - arbeidet med de foreslåtte teknikkene i detaljerte PRAKTISKE oppgaver.

Denne delen viser eksempler på å løse typiske problemer når du arbeider med hierarkiske kataloger.

Innhenting av elementer i en hierarkisk katalog som er underordnet en gitt gruppe

For å få underordnede elementer i en hierarkisk katalog, gir spørringsspråket IN HIERARCHY-konstruksjonen. Eksempel på bruk I HIERARKI:

VELGE
Nomenclature.Code,
Nomenklatur.Kjøpspris
FRA

I dette eksemplet vil alle postene i nomenklaturkatalogen som ligger i &Gruppe-gruppen hentes, inkludert seg selv, dens underordnede grupper og elementer som tilhører underordnede grupper.

Hvis vi kun er interessert i elementer og grupper som ligger direkte i en gitt gruppe, kan vi få slike elementer ved å sette en betingelse i feltet Overordnet. Eksempel:

VELGE
Nomenclature.Code,
Nomenklatur Navn AS Navn,.
Nomenklatur.Kjøpspris
FRA
Directory.Nomenclature AS Nomenclature

HVOR
Nomenklatur.Foreldre = &Gruppe

Denne spørringen vil velge grupper og elementer som er underordnet gruppen med koblingen &Gruppe.

Kontrollere tilstedeværelsen av underordnede elementer i et katalogelement

For å sjekke tilstedeværelsen av underordnede poster for et katalogelement, kan du bruke en spørring som ligner på den som er presentert:

I dette eksemplet skrives referansen til elementet du vil sjekke for underordnede, til Parent-spørringsparameteren. Etter å ha utført en slik spørring, må du sjekke resultatet for tomhet. Hvis resultatet ikke er tomt, er det underordnede poster. Ellers - nei. Eksempel:

Hvis Request.Execute().Empty() Deretter
Rapport("Ingen oppføringer");
Noe annet
Report ("Records available");
endIf;

Å få alle foreldre til et element

Spørringsspråket gir ingen spesielle midler for å hente alle foreldre til et element. Du kan bruke hierarkiske totaler for å fullføre oppgaven, men innhenting av hierarkiske totaler er optimalisert for å bygge totaler for et stort antall poster, og er ikke helt effektivt for å skaffe foreldrene til et enkelt element. For mer effektivt å hente alle overordnede poster for et element, anbefales det å gå gjennom foreldrene i små porsjoner. Eksempel:

CurrentItemItem = ItemItem;

Mens sannhetssyklusen
Request.SetParameter("CurrentItemItem", CurrentItemItem);
Resultat = Query.Run();
Hvis Result.Empty() Da
Avbryt;
endIf;
Utvalg = Result.Select();
Utvalg.Neste();
For ColumnNumber = 0 Etter Result.Columns.Quantity() - 1 sløyfe
CurrentItemItem = Selection[ColumnNumber];
Avbryt;
Noe annet
Rapport(CurrentItemItem);
endIf;
EndCycle;

Hvis CurrentItemItem = Directories.Nomenclature.EmptyLink() Da
Avbryt;
endIf;
EndCycle;

I dette eksemplet vises alle foreldre for koblingen som er registrert i ElementNomenclature-variabelen i tjenestemeldingsvinduet. I syklusen velges 5 lenkeforeldre.

Hvis antall nivåer i katalogen er begrenset og lite, er det mulig å få alle foreldre med én forespørsel uten en løkke.

Vise en hierarkisk katalog i en rapport

For å vise en hierarkisk katalog i en rapport mens hierarkiet bevares, må du bruke en spørring som ligner på følgende:

VELGE
Nomenclature.Code,
Nomenklatur Navn AS Navn,.
Nomenklatur.Kjøpspris
FRA
Directory.Nomenclature AS Nomenclature
BESTILL PÅ
Navn HIERARKI

Denne spørringen velger alle poster fra katalogen og ordner dem i et hierarki. Resultatet vil bli sortert etter navn, med hensyn til hierarkiet.

For at kataloggrupper skal plasseres over elementene, er det nødvendig å erstatte ORDER BY-klausulen i denne forespørselen med følgende:

BESTILL PÅ
Nomenklatur. Dette er gruppehierarki,
Navn

Resultatet vil fortsatt være rangert hierarkisk, men gruppene vil vises over elementene.

Det er også mulig å erstatte ORDER BY-tilbudet med alternativet AUTO ORDER. I dette tilfellet vil resultatet bli bestilt i samsvar med innstillingene til katalogen, dvs. hvis katalogen sier at grupper skal være plassert over elementene, vil de være plassert over.

Det er også mulig å få den hierarkiske strukturen til katalogen ved å bruke resultatene.

VELGE
Nomenclature.Code,
Nomenklatur Navn AS Navn,.
Nomenklatur.Kjøpspris

FRA Directory.Nomenclature AS Nomenclature

HVOR
(Nomenclature.ThisGroup = FALSE)

BESTILL etter navn

Få totaler etter hierarki

For å få totaler etter hierarki i en spørring, må du spesifisere nøkkelordet HIERARKI i SOFTWARE TOTAL-leddet etter å ha spesifisert feltet som totalene skal beregnes med. Et eksempel på en rapport "Vareomsetning" med innhenting av totaler etter hierarki:

VELGE

FRA

Nomenklatur HIERARKI

Som et resultat av denne forespørselen vil totaler ikke bare beregnes for hver vare, men også for gruppene som denne eller den varen tilhører.

I tilfellet hvor vi ikke trenger totaler for elementer, men kun trenger totaler for grupper, må vi bruke KUN HIERARKIET i totalene. Eksempel:

VELGE
Regnskap for NomenclatureTurnover.Nomenclature AS Nomenclature,
Regnskap for nomenklaturTurnover.Nomenclature.Presentation,
Regnskap for NomenklaturTurnover.QuantityTurnover AS QuantityTurnover
FRA
Akkumuleringsregister.Nomenklatur Regnskap.Omsetning HVORDAN Nomenklatur RegnskapOmsetning
RESULTATBELØP (Antall Omsetning) PO
BARE nomenklaturhierarki

Resultatet av denne spørringen vil være totale poster bare for varegrupper.

"IN HIERARCHY"-designet i 1C:Enterprise 8.x-spørringer lar deg hente underordnede elementer av et hierarkisk konfigurasjonsobjekt i henhold til et gitt utvalg. I dag i artikkelen vil vi se på et eksempel på bruken, så vel som handlingene til plattformen på DBMS-siden og dens innvirkning på ytelsen.

Bruk

La oss se på et enkelt eksempel på bruk av «IN HIERARKIET»-konstruksjonen. Når du utfører følgende forespørsel, vil de underordnede elementene i den hierarkiske katalogen "Produkter" fås for den beståtte verdien av "Link"-variabelen.

Spørringstekst = " SELECT | Produkter . Link,| Varer |. Artikkel FRA | Katalog . Produkter AS Produkter"

|HVOR |

Bildet viser selvfølgelig ikke alle katalogoppføringer. Skjermbildet viser bare datalagringsstrukturen i den hierarkiske katalogen. Katalogtabellen lagrer 10 grupper på toppnivå, som hver inneholder 5 nestede grupper med 200 elementer hver.

La oss gå tilbake til testforespørselen. La oss sende lenken til gruppen "Gruppe - 1" til parameteren "&Link" (se skjermbilde ovenfor). Da vil resultatet av spørringen se slik ut:

Som vi kan se, returnerte forespørselen en lenke til selve toppgruppen (vedtatt som en parameter), samt nestede grupper med elementene i dem. Ved å bruke "IN HIERARCHY"-konstruksjonen lar du deg enkelt skaffe hierarkisk underordnede data.

Syntaks for spørringsspråket 1C:Enterprise klassisk SQL veldig lik på noen måter. Men for uttrykket "IN HIERARCHY" er det ingen analog i SQL-spørringsspråket, som for eksempel for uttrykket til plattformen "B" spørrespråk er det en lignende SQL-operator "IN". Derfor er arbeidet til plattformen med DBMS når du bruker denne operatøren interessant.

Bak kulissene

Så la oss komme i gang. For eksempel vil vi bruke den tidligere skrevne spørringen for "Produkter"-katalogen. Vi vil analysere handlingene til plattformen for to situasjoner:

Vi vil sende toppnivågruppen "Gruppe 1" som parameteren "&Link" (som vi gjorde tidligere).
I parameteren sender vi en lenke til gruppen "Gruppe 1 - 1", nestet i toppnivågruppen "Gruppe 1".

Nå, i rekkefølge. I det første tilfellet vil plattformen utføre følgende handlinger på SQL-serveren:

1. Først utføres en SQL-spørring for å få en kobling til kataloggruppen som sendes som en parameter og alle dens underordnede grupper. Resultatet plasseres i den midlertidige tabellen "#tt1".

2. I det andre trinnet utføres den samme spørringen to ganger:

Skjermbildet inneholder detaljerte kommentarer til teksten til SQL-spørringen. Kort sagt lar spørringen deg velge underordnede elementer for grupper som er referert til i en midlertidig tabell. Spørsmålet gjenstår: "Hvorfor utføres spørringen to ganger?" Svaret her er enkelt: For det første henter spørringen de underordnede elementene for grupper på første nivå som allerede finnes i den midlertidige tabellen (se punkt 1). Den andre spørringen henter deretter underelementene for undergruppene på andre nivå. Siden ingen kataloggruppe er til stede på det tredje nivået i hierarkiet, utføres ikke denne spørringen lenger.

I vårt tilfelle vil den andre spørringen returnere et tomt resultat, siden det ikke er noen underordnede elementer for poster som ligger på 3. nivå i hierarkiet (det er ingen grupper der).

3. For å få det endelige resultatet av spørringen, genererer plattformen følgende SQL-spørring:

Resultatet av denne forespørselen kan viderebehandles av algoritmer i det innebygde språket til plattformen. Dermed blir oppføringer i den midlertidige tabellen "#tt1" brukt til å sette samplingsbetingelsen fra referansetabellen "_Reference41".

4. På siste trinn sletter 1C:Enterprise 8.x-plattformen den midlertidige tabellen "#tt1", siden den ikke lenger vil bli brukt i fremtiden.

Dette fullfører prosessen med å utføre "IN HIERARKIET"-operatoren. La meg minne deg på at den vurderte sekvensen av handlinger på SQL-serveren ble utført da vi sendte en kobling til toppnivågruppen "Gruppe - 1" til en forespørsel på plattformsiden. Men hvordan vil plattformen oppføre seg hvis vi sender en kobling til andrenivågruppen "Gruppe - 1 - 1" som "&Link"-parameteren? Alt vil skje på samme måte, bortsett fra følgende punkt: ovenfor, i den andre fasen av å utføre SQL-spørringer av plattformen, ble det skrevet at spørringen for å skaffe underordnede elementer ble utført to ganger - i tilfellet med å skaffe underordnede elementer for gruppen "Gruppe - 1 - 1" dette er ikke slik . Forespørselen vil kun bli utført én gang.

Faktum er at antall forespørsler om å få underordnede elementer avhenger av antall grupper i hierarkiet. Med andre ord, hvis elementhierarkinivået inneholder minst én gruppe, så forespørsel fra punkt 2.

Ytelsespåvirkning

Feil bruk av en operatør i en spørring kan resultere i suboptimal systemytelse. Operatøren under vurdering "IN HIERARKIET" er intet unntak. Den må brukes med forsiktighet, siden den i stor grad kompliserer algoritmen for å utføre SQL-spørringer til databasen og dermed øker belastningen på DBMS-serveren.

La meg gi deg et eksempel på et suboptimalt søk som kan føre til de triste konsekvensene nevnt ovenfor:

VELG produkter. Link FRA Katalog. Produkter AS Produkter HVOR (Produkter. Link I HIERARKIET (& Link) ELLER Produkter. Link I HIERARKIET (& Link1) ELLER Produkter. Link I HIERARKIET (& Link2) )

Som du kanskje gjetter, vil forespørselen føre til generering av mange SQL-spørringer, noe som vil resultere i en reduksjon i ytelsen til informasjonssystemet.

Trekk dine konklusjoner!

Det er opp til deg å trekke konklusjoner. La meg bare si at operatøren "IN HIERARKIET" brukes av plattformen for datasammensetningssystemet når valgbetingelsene inkluderer "IN GRUPPE", "IN GRUPPE FRA LISTEN" og andre. Jeg tror det ikke er nødvendig å forklare at med feil manipulasjoner kan brukere sette opp svært komplekse valg og øke belastningen på 1C-serveren og DBMS flere ganger. La oss endre innstillingene kun for erfarne brukere.

Og selvfølgelig, når du skriver dine egne mekanismer, vær oppmerksom på "IN HIERARCHY" -operatøren. Veldig praktisk på den ene siden, og farlig på den andre.

1C-kataloger er et spesialisert metadatatreobjekt som tjener til å lagre statisk referanseinformasjon. For eksempel, i typiske konfigurasjoner kan du se følgende visninger: , Nomenklatur, Ansatte, Anleggsmidler, etc. Informasjon i kataloger endres som regel ikke ofte. Kataloger brukes deretter i nesten alle regnskapsobjekter som en regnskapsseksjon eller referanseinformasjon.

Nedenfor vil vi se på å sette opp og designe en katalog fra konfiguratoren ved å bruke katalogen "Nomenklatur" som et eksempel.

Grunnleggende fane

"Grunnleggende"-fanen spesifiserer navn, synonym, objektrepresentasjon og beskrivelse av formålet.

"Kataloghierarki"-fanen

Her er hierarkiet til katalogen etablert.

Hierarki i 1C 8.3 er av to typer - " grupper og elementer"Og" elementer". Det skiller seg ved at i det første tilfellet kan bare en mappe (gruppe) være en overordnet (mappe), og i det andre tilfellet kan et element også være en forelder.

"Plasser grupper på toppen" - flagget er ansvarlig for å vise grupper i listeform.

Også i innstillingene kan du begrense antall grupper i kataloghierarkiet ved å bruke riktig innstilling.

Fanen Eiere

En katalog kan underordnes en annen katalog. Fra synspunktet til å konfigurere 1C 8.3 betyr dette at "Eier"-attributtet blir obligatorisk for det underordnede elementet. Et eksempel på en slik forbindelse mellom kataloger i standardkonfigurasjoner "Nomenklatur - Måleenheter", "Motparter - Kontrakter med kontraktører".

Katalogeieren kan også være følgende metadataobjekter: , .

Datafanen

Få 267 videotimer på 1C gratis:

Den viktigste kategorien fra en programmerers synspunkt. Den inneholder katalogdetaljer.

Katalogen har et sett med standarddetaljer som ikke er redigert av 1C 8.2-programmereren en liste over dem kan sees ved å klikke på "Standarddetaljer"-knappen:

Jeg vil dvele ved hver enkelt mer detaljert:

Dette er en gruppe– et attributt med en boolsk type, som indikerer om det er en gruppe eller et element. Bare tilgjengelig i den hierarkiske katalogen. Vennligst merk verdien av dette attributtet kan ikke endres i 1C: Enterprise-modus.
Kode— rekvisitter, typenummer eller streng (vanligvis en streng). Et nummer som tildeles automatisk av systemet. Vanligvis beregnet som (forrige kode + 1). Jeg anbefaler å bruke strengtypen, fordi sortering av numeriske verdier ikke fungerer som forventet. Kan brukes som katalogrepresentasjon i en liste og i inndatafelt. Brukes vanligvis til å søke etter et element når du skriver inn en streng. Hvis du trenger å fjerne Kode-feltet, skriv inn null i linjelengden.
Navn— obligatoriske detaljer, strengtype. Maksimal linjelengde er 150 tegn. Kan brukes som katalogrepresentasjon i en liste og i inndatafelt. Brukes vanligvis til å søke etter et element når du skriver inn en streng. Hvis du trenger å fjerne feltet Navn, skriv inn null i linjelengden.
Foreldre— et attributt av DirectoryLink-typen.<ИмяТекущегоСправочника>. Bare tilgjengelig i den hierarkiske katalogen. Peker på den overordnede forelderen i hierarkiet. Hvis elementet eller gruppen er i roten av katalogen, angis verdien Directory.<ИмяТекущегоСправочника>.EmptyLink.
Eier— lenke til eierelementet til gjeldende katalogelement (gruppe). Tilgjengelig bare i den underordnede 1C-katalogen.
Flaggsletting— rekvisitter av typen Boolean. Ansvarlig for å vise "slettemerket" i systemet. Et element merket for sletting anses som ubrukelig, men gamle dokumentbevegelser kan forbli på det.
Link— felt av strengtype. Dette attributtet lagrer en unik objektidentifikator - GUID. Det vi ser i systemet i en visuell visning kalt "link" er bare en representasjon av et objekt. Kan ikke endres.
Forhåndsdefinert— boolsk type, viser om elementet er forhåndsdefinert, mer om det senere. Kan ikke endres.

"Data"-fanen indikerer også representasjonen av katalogen i systemet før versjon 8.2.16, representasjonen kunne bare være kode eller navn. I nyere versjoner av plattformen (fra og med 8.3) kan visningen beskrives uavhengig i administratormodulen ved å bruke "ViewReceivingProcessing"-behandleren.

Nummereringsfane

Her kan du spesifisere innstillingene til telefonboken angående nummerering. Det anbefales å bruke autonummerering. Uniqueness control er et flagg som hjelper, om nødvendig, til å gjøre koden unik. Hvis du, med flagget satt, prøver å skrive et katalogelement med en ikke-unik kode, vil du i 1C motta meldingen "Katalogkoden har blitt uunik."

Kodeserie - bestemmer hvordan katalogen skal nummereres, du kan angi nummereringen av katalogen etter eier. For eksempel vil motparten "Horns and Hooves" ha sin egen nummerering av kontrakter - "1, 2, 3", etc.

Skjemaer-fanen

Skjemaene for katalogen er beskrevet her. Hvis konfigurasjonen startes i både normal og administrert modus, vil det være to faner med skjemaer som standard: "hoved" og "avansert" - forskjellige for de vanlige og administrerte applikasjonene.

Denne siden har en viktig funksjon i katalogen - "". Dette er en veldig praktisk funksjon til 1C 8, som lar deg, når du fyller ut data i inndatafeltet, ikke gå inn i katalogen, men skrive inn navnet, koden osv. og velg ønsket element fra rullegardinlisten. Det ser slik ut:

Annet fane

På fanen kan du få rask tilgang til hovedmodulene i katalogen - objektmodulen og ledermodulen.

Du kan også definere en liste over forhåndsdefinerte katalogelementer på siden. Dette er elementer som ikke kan slettes i Enterprise Mode. Forhåndsdefinerte elementer kan nås direkte i konfiguratoren ved navn, for eksempel: Directories.Nomenclature.Service.

Denne kategorien bestemmer også blokkeringsmodus - automatisk eller kontrollert. Bruk av fulltekstsøk, samt referanseinformasjon om katalogen, tilgjengelig i 1C: Enterprise-modus.

Hva er en 1C-katalog og hvorfor er den nødvendig? Katalogen lagrer betinget permanent informasjon, dvs. informasjon som forblir nesten uendret over lang tid. For eksempel inneholder "Nomenklatur"-katalogen en liste over varer som selges eller produseres. En katalog kan også inneholde mange egenskaper som beskriver et katalogelement.

Hvis vi tar kjønnet til en person for sammenligning, så er listen begrenset og ikke endret, så en oppregning er bedre egnet for det.

Etter å ha opprettet en ny katalog, vil vi se følgende bilde.

La oss se på alle bokmerkene hans.

Grunnleggende

Her er navn (identifikator i databasen) og synonym (brukernavn til katalogen) angitt. En valgfri kommentar er en som kan forklare formålet med katalogen eller beskrive funksjonene.

Hierarki

På denne fanen kan du konfigurere dybden på nesting av katalogelementer. Ved å bruke denne innstillingen er det praktisk å differensiere og detaljere elementer i henhold til noen kriterier. For eksempel er produktene "Skap" i en gruppe, og produktene "Bord" er i en annen. Som standard, når opprettet, representerer katalogen liste over elementer. Hvis du merker av for Hierarkisk katalog, kan hvert element være underordnet et annet element (gruppe). Nedenfor finner du alternativer for å tilpasse dette bokmerket og endre visningen i egendefinert modus.

Hierarkitype:

Hierarki av grupper og elementer

Med denne innstillingen kan elementer bare nestes i grupper (mapper).

Her, som du kan se, har alle elementer og grupper de samme ikonene, og alle elementer kan nestes.

Plasser grupper på toppen

Når denne avmerkingsboksen er merket vil gruppene alltid være øverst, ellers vil de bli ordnet i sorteringsrekkefølge, for eksempel slik:

Begrensning av antall hierarkinivåer

Hvis avmerkingsboksen ikke er merket her, er hekking ubegrenset.

Hvis avmerkingsboksen er merket, kan du spesifisere antall nivåer nedenfor.

Eiere

På bokmerket eiere andre kataloger kan være indikert i forhold til hvilke denne er underordnet. Relasjonsdiagrammet til underordnede kataloger ligner relasjonsdiagrammet til en hierarkisk katalog, bare her fungerer en annen katalog som overordnet og kalles eieren. I typiske konfigurasjoner er et godt eksempel at katalogen "Avtaler" er underordnet katalogen "Motparter", fordi Det kan ikke foreligge en avtale som ikke tilhører noen motpart.