View Definition in DMAV sehr kompliziert formuliert - Warum?

Sprache INTERLIS
1

Hallo zusammen

mich würde interessieren aus welchem Grund die VIEW Definition in den DMAV 1.1 Modellen so „kompliziert“ definiert sind. Es ginge doch auch viel lesbarer.

Ein Beispiel aus DMAV_Grundstuecke_V1_1

VIEW Grundstueck_Gueltig
      PROJECTION OF Grundstueck;
      WHERE DEFINED(Grundstueck->Entstehung) AND DEFINED(Grundstueck->Entstehung->Grundbucheintrag) AND (NOT(DEFINED(Grundstueck->Untergang)) OR NOT(DEFINED(Grundstueck->Untergang->Grundbucheintrag)));
      =
      ALL OF Grundstueck;
     UNIQUE CH041101: NBIdent, Nummer;
     UNIQUE CH041102: EGRID;
    END Grundstueck_Gueltig;

besser lesbar:

VIEW Grundstueck_Gueltig
      PROJECTION OF Grundstueck;
      WHERE DEFINED(Grundstueck->Entstehung->Grundbucheintrag) AND NOT(DEFINED(Grundstueck->Untergang->Grundbucheintrag));
      =
      ALL OF Grundstueck;
     UNIQUE CH041101: NBIdent, Nummer;
     UNIQUE CH041102: EGRID;
    END Grundstueck_Gueltig;

Grüssle

2

Gegeben sind die Klassen Grundstueck und GSNachfuehrung. Diese sind durch zwei Beziehungen miteinander verbunden: Entstehung_Grundstueck und Untergang_Grundstueck:

grafik
grafik1200×630 69.5 KB

In der WHERE-Bedingung der View wird sichergestellt, dass nur Grundstueck-Objekte betrachtet werden, bei denen ausschliesslich eine der beiden Beziehungen (links) realisiert ist, und nicht beide. Es darf also nur der Link Grundstueck->Entstehung existieren; würde der andere Link Grundstrueck->Untergang auch bestehen, so wäre das ein Zeichen dafür, dass das Grundstueck-Objekt bereits untergegangen ist. Solche Grundstueck-Objekte haben aber in der View mit dem Namen Grundstueck_Gueltig nichts verloren.

Die beiden Ausdrücke DEFINED(Grundstueck->Entstehung) resp. NOT(DEFINED(Grundstueck->Untergang)), die du in deinem Vorschlag weglässt, sind also deshalb wichtig, weil sie beschreiben, welche der beiden Link-Möglichkeiten zwischen den beiden Klassen Grundstueck und GSNachfuehrung erlaubt sind und welche nicht.

LG, Stefan

3

aber ist es nicht so, dass meine abgespeckte Version dies auch beschreibt? Sorry ich stehe noch etwas auf dem Schlauch

DEFINED(Grundstueck->Entstehung) ist doch in allen Fällen auch bei DEFINED(Grundstueck->Entstehung->Grundbucheintrag) erfüllt, somit überflüssig extra zu testen weil mit AND verknüpft.

ebenso ist doch (DEFINED(Grundstueck->Untergang)) noch ein gültiges Grundstück erst mit (DEFINED(Grundstueck->Untergang->Grundbucheintrag))nicht mehr, somit würde es doch ausreichen nur den zweiten Teil zu testen und dann mit NOT umzudrehen?

4

(Leider) nein. Mit dem Pfad Grundstueck->Entstehung->Grundbucheintrag fragst du nur das Attribut Grundbucheintrag ab, aber nicht den Link zwischen Grundstueck und GSNachfuehrung. Du musst separat prüfen, ob dieser Link existiert.

5

Fall A: Link Entstehung existiert nicht:

DEFINED(Grundstueck->Entstehung) = false
DEFINED(Grundstueck->Entstehung->Grundbucheintrag) = false

Fall B: Link Entstehung existiert, aber Grundbucheintrag ist leer:

DEFINED(Grundstueck->Entstehung) = true
DEFINED(Grundstueck->Entstehung->Grundbucheintrag) = false

Fall C: Link existiert und Grundbucheintrag ist gesetzt:

DEFINED(Grundstueck->Entstehung) = true
DEFINED(Grundstueck->Entstehung->Grundbucheintrag) = true

Wozu braucht es dann das erste DEFINED?

6

Danke für die Aufstellung. Ich glaube du hast recht und ich habe mich geirrt. Sorry @sunny :face_with_peeking_eye:

Gemäss RefHB gilt:

Besteht ein Faktor nicht nur aus dem unmittelbaren Gegenstand sondern auch aus dem Pfad, der zu diesem führt, gilt der Gegenstand immer als undefiniert, wenn irgendein Attribut des Pfades nicht definiert ist.
INTERLIS 2.4 Referenzhandbuch

Damit reicht wohl der eine DEFINED-Ausdruck, um festzustellen, ob das Attribut Grundbucheintrag leer ist oder nicht. In Ausdrücken, die ich verwende, muss ich erst oft auf „Leer“ (= DEFINED) prüfen und anschliessend auf einen konkreten Wert. Aber die „doppelte“ DEFINED-Prüfung ist wohl hier nicht nötig.