Laatst maakte iemand een grapje dat hij met een collega een datamorgana had gezien. Zonder toelichting begreep ik de clou achter dit concept direct. Datamorgana's komen veel voor en kunnen net zo veel verwarring bieden als homoniemen doen bij het ontwerpen van datamodellen. Datamorgan's komen vooral voor bij het gebruik van data binnen informatiesystemen en -portalen.

Een mooi voorbeeld had ik enige tijd geleden toen ik aan een projectleider het logisch datamodel van een CRM toepassing vroeg. Enige tijd later stuurde hij mij een functioneel ontwerp op van de schermen van deze applicatie op. Mijn reactie was dat ik daar niets aan had. Er ontstond vervolgens een discussie over of de gegevens zoals op het scherm getoond werden ook opgeslagen werden als data in de relationele database. De verleiding is al gauw om dat te veronderstellen. Maar het is het zelfde als bij een fatamorgana. Als je heel erg dorst hebt dan is een weerspiegeling al snel de waarheid.

Zijn datamorgana een probleem? In heel veel gevallen is dat niet het geval. Wordt de data alleen gebruikt via de interfaces die allemaal dezelfde datamorgana of transformaties van de opgeslagen gegevens bieden dan is er niets aan de hand. Problemen gaan pas optreden zodra er integratie oplossingen nodig zijn om op basis van de opgeslagen gegevens gegevens uit te wisselen met diverse andere toepassingen. Dan wordt het zaak om te kijken of datamorgana's nodig zijn voor de nieuwe (integratie) interfaces. Op dat moment wordt het beschrijven van deze datamorgana's belangrijk om verwarring nu en in de toekomst te voorkomen