Analyse BML 3.0.1: Bohrungsausbau - Kardinalität InstallationDetails.casingString & Constraint auf CasingString.casingStringNumber
Die Taskforce 1 Optimierung - BML 3.1 hat bei ihrer Analyse des bestehenden Schemas BoreholeML 3.0.1 einen Befund zu folgenden Elementen (Klasse.Attributname):
- InstallationDetails.casingString (Datentyp: CasingString) und
- CasingString.casingStringNumber (Datentyp: Integer)
Die Beschreibung des Befundes fängt etwas ausholend beim übergeordneten Attribut Borehole.installationDetail an.
Die Klasse Borehole enthält im <<voidable>>
-Block das Attribut installationDetail (Datentyp: InstallationDetails, Beschreibung "Aktuelle Ausbaudaten"), das ist im Modell sozusagen der Absprungpunkt für alle Daten zum aktuellen Ausbau einer Bohrung.
Dieses Attribut ist ohne explizite Kardinalität und mit nillable="true"
modelliert, es muss bei einer Bohrung im WFS oder einer BML-Datei also stets genau eine Instanz der Klasse InstallationDetails angegeben werden, oder das Attribut installationDetail wird mit xsi:nil="true"
belegt.
Das ist fachlich OK, denn
- eine Bohrung ist ausgebaut, dann müssen auch Daten zum Ausbau angegeben werden, oder
- eine Bohrung ist nicht ausgebaut, dann wird das durch Setzen des nil-Wertes dokumentiert, oder
- die Daten zum Ausbau einer ausgebauten Bohrung liegen nicht vor, dann wird das auch durch Setzen des nil-Wertes dokumentiert.
Das Attribut casingString ist das einzige verpflichtende Attribut der Klasse InstallationDetails. Es ist mit der Kardinalität [1..*] modelliert und enthält gemäß Beschreibung die "Verrohrung (Rohrtour) als Teil des Gesamtausbaus eines Bohrlochs" als Instanzen der Klasse CasingString.
Das bedeutet, dass bei ausgebauten Bohrungen neben den allgemeinen Daten zum Ausbau (in übergeordneter Klasse InstallationDetails) auch immer die Daten zu mindestens einer Verrohrung/Rohrtour in CasingString sowie (in dazu untergeordneter Klasse CasingStringSegment) den dabei eingebauten Rohrtourabschnitten (Ausbauelementen) angegeben werden müssen.
Das ist soweit erstmal alles richtig modelliert.
Die Klasse CasingString enthält nur verpflichtende Attribute, und zwar:
- casingStringNumber (Datentyp: Integer): Rohrtour-Nummer
- casingStringType (KeyList: CasingStringTypeList): Ausbauart (Art der Verrohrung)
- casingStringSegment(Datentyp: CasingStringSegment; Kardinalität [0..1]): Rohrtourabschnitte
Mit dem Attribut casingStringNumber ist der Constraint casingStringNumber_values verbunden, er ist definiert als inv: casingStringNumber >= 1 and casingStringNumber <= 9
, d.h. "Der Wert von casingStringNumber muss mindestens 1 und maximal 9 betragen".
Jetzt stellt sich die Frage, warum der Constraint auf casingStringNumber eine Obergrenze definiert, während die Kardinalität der Klasse CasingString beliebig viele Instanzen zulässt.
Aus Sicht der Taskforce 1 gibt es zwei Möglichkeiten, wie mit der dargelegten Abweichung umgegangen werden kann:
- Änderung des Constraint auf casingStringNumber dahingehend, dass keine Obergrenze in der Rohrtournummerierung definiert wird,
- Einschränkung der Kardinalität des Attributs InstallationDetails.casingString bzw. der Klasse CasingString von [1..*] auf [1..9], passend zur Definition des Constraint auf casingStringNumber.
Empfehlung der Taskforce 1:
Option 1., Änderung des Constraint auf casingStringNumber mit Entfernung der Obergrenze. So werden keine neuen Limitierungen eingeführt. Es könnten theoretisch beliebig viele Rohrtouren in BML geliefert werden (was in der Realität wohl nicht vorkommen wird), und bei mehr als 9 Rohrtouren müssten nicht Rohrtournummern mehrfach bei unterschiedlichen Rohrtouren verwendet werden.