tmin/tmax systeemtijden. Verder om
vat het model het formele tijds-
attribuut object-dt (of valid-tmin)het
tijdstip waarop het object werd onder
zocht. Misschien kunnen in de toe
komst tevens de attributen last-verifi-
cation-dt en valid-tmax worden toe
gevoegd, zodat een bi-temporeel mo
del ontstaat; dat wil zeggen, zowel
systeemtijd als formele tijd worden
ondersteund. Een temporele uitbrei
ding van SQL is beschreven in [22]. In
[26] wordt een querytaal voor een
object-database voor ruimtelijke ge
gevens gepresenteerd.
Wanneer een nieuw object wordt toe
gevoegd, wordt het huidige tijdstip als
waarde voor tmin gebruikt en krijgt
tmax een bijzondere waarde: MAX-
TIME. Als een attribuutwaarde van
een bestaand object verandert, dan
wordt dit attribuut niet bijgewerkt
maar wordt het complete record, in
clusief de oid, gekopieerd met de
nieuwe waarde van dit attribuut. Het
huidige tijdstip wordt voor tmax ge
bruikt in het oude record en ook voor
tmin in het nieuwe record. Dit is
noodzakelijk om een reconstructie van
de juiste situatie mogelijk te maken op
elk tijdstip in het verleden. Elk object
heeft een unieke identificatie in ruim
te en tijd via de combinatie van de
attributen oid, tmax.
Voor een topologische verwijzing naar
een ander object wordt alleen de oid
gebruikt en niet tmax. Deze verwijzing
verandert niet als het gerelateerde ob
ject wordt bijgewerkt, terwijl het zijn
oid behoudt. Hierdoor heeft een wijzi
ging in het ene object geen effect op
andere nabijgelegen objecten. In het
geval dat de oid van een gerelateerd
object is veranderd (het wordt een
ander object), wordt het object dat
hiernaar verwijst ook bijgewerkt en
wordt er dus een nieuwe versie van dit
object gecreëerd.
Fig. 4 toont de inhoud van een data
base die op „12 jan" een lijn met oid
1023 bevatte. Op „20 leb" werd deze
lijn in twee delen gesplitst: 1023 en
1268. Tenslotte werd het attribuut
quality van één van de lijnen veran
derd op „14 apr". De SQL-bevra-
gingen verderop in het artikel laten
zien hoe gemakkelijk het is mutatie
bestanden te produceren met nieuwe, veranderde en ver
wijderde objecten die gerelateerd zijn aan een specifiek
tijds-interval.
Een bevraging die alle historische versies van een bepaald
object kan produceren, vereist alleen het specificeren van
de oid en het weglaten van de tijdattributen. Dit werkt
goed voor eenvoudige objectveranderingen, maar niet voor
splitsingen, samenvoegingen of meer gecompliceerde ruim
telijke manipulaties. Echter, deze informatie kan altijd
worden berekend door toepassing van een ruimtelijke over-
lap-bevraging voor het vlak van het gegeven object door de
tijd terug zonder dat wordt gekeken naar tmin/tmax.
Fig. 3.
Schermafdruk
met een voorbeeld
record van een
boundary.
Locking, check-out, en check-in
Een GIS verschilt van vele andere databasetoepassingen,
omdat de topologische edit operaties complex kunnen zijn
door relaties tussen vele oude en nieuwe objecten. Dit
resulteert in lange transacties. Gedurende deze periode is
het aan andere gebruikers niet toegestaan te manipuleren
met gegevens van hetzelfde thema binnen een rechthoekig
werkgebied. Wel mogen ze eventueel andere thema's in
hetzelfde gebied bewerken. Ze moeten ook in staat worden
gesteld om de gegevens ter referentie op te vragen. Een
alternatief voor locking is versioning [5], maar het is on
mogelijk tegenstrijdige versies te combineren zonder inter
ventie van de gebruiker. Daarom wordt de edit locking
strategie gebruikt en deze is met behulp van de tabel lock
geïmplementeerd.
Omdat de database altijd in een consistente toestand moet
verkeren, mag het niet worden vervuild met „tijdelijke"
veranderingen die ontstaan tijdens de topologische edit
operaties. Dit is de reden voor de introductie van een tijde
lijk werkbestand voor het GIS-edit programma zoals X-
Fingis [10] [11] [13]. Het werkbestand wordt aangemaakt
gedurende de check-out (selectie) en wordt geregistreerd in
265
GEODESIA
'997-6
Voorgangers en opvolgers
194428
118455 ij
Irjinèvid
|l 844641
|l 84462|
1184537|
1Ü4535J
|194426|
11S4530
|1845401
|l 844671
