Laatst maakte iemand een grapje dat hij met een collega een data morgana had gezien. Zonder toelichting begreep ik de clou achter dit concept direct. Data morgana's komen veel voor en kunnen net zo veel verwarring bieden als homoniemen doen bij het ontwerpen van datamodellen. Data morgan'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 fata morgana. Als je heel erg dorst hebt dan is een weerspiegeling al snel de waarheid.

Zijn data morgana een probleem? In heel veel gevallen is dat niet het geval. Wordt de data alleen gebruikt via de interfaces die allemaal dezelfde data morgana 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 data morgana's nodig zijn voor de nieuwe (integratie) interfaces. Op dat moment wordt het beschrijven van deze data morgana's belangrijk om verwarring nu en in de toekomst te voorkomen