Computable.nl
  • Thema’s
    • Carrière
    • Innovatie & Transformatie
    • Cloud & Infrastructuur
    • Data & AI
    • Governance & Privacy
    • Security & Awareness
    • Software & Development
    • Werkplek & Beheer
  • Sectoren
    • Channel
    • Financiële dienstverlening
    • Logistiek
    • Onderwijs
    • Overheid
    • Zorg
  • Computable Awards
    • Overzicht
    • Nieuws
    • Winnaars
    • Partner worden
  • Vacatures
    • Vacatures bekijken
    • Vacatures plaatsen
  • Bedrijven
    • Profielen
    • Producten & Diensten
  • Kennisbank
  • Nieuwsbrief

Begin met Logisch databaseontwerp

16 januari 2003 - 23:005 minuten leestijdOpinieData & AI
Frans Faase Beugelhoek
Frans Faase Beugelhoek

Prestatieproblemen moeten opgelost worden op het niveau van de fysieke dataopslag, en hebben niets van doen met logische datamodellering. Frans Faase Beugelhoek mengt zich in de discussie over relationele databases.

Het einde van relationeel?
Zelden heeft een verhaal zoveel discussie opgeroepen als de bijdrage over relationele databases van Peter Teeuwen. De auteur ventileert daarin zijn ernstige twijfel of dergelijke databases nog wel een plaats verdienen in deze veranderde tijden. De lezers lopen hiertegen te hoop.
  • Relationele databases: het einde van een tijdperk?
  • Relationele databases: ook in 2003
  • Zoveelste einde van een tijdperk
  • Begin met Logisch database ontwerp
  • De voordelen van elementaire database management systemen
  • Ongestructureerd opslaan
  • Spelregels voor metadata moeten vastliggen
  • Gebruik vooral relationele databases
  • Stap vooruit op basis van relationeel
  • Koester transacties
  • Relationeel, maar zonder samenhang
  • Spijtig voor Teeuwen
Zie ook:
https://www.computable.nl/relationeel
In het artikel ‘Relationele databases: einde van een tijdperk?’ (Computable, 13 december) trekt Peter Teeuwen een aantal vreemde conclusies doordat logische datamodellering en fysieke gegevensopslag met elkaar verward worden. Het is inderdaad zo dat computergeheugen minder schaars is, maar computers worden ook steeds sneller. De bewering echter dat prestatieproblemen te maken hebben met de logische datamodellering, getuigt niet echt van veel kennis van zaken. Prestatieproblemen dienen opgelost te worden op het niveau van de fysieke dataopslag. Dit kan door het aanmaken van extra indexen of het clusteren van gegevens. Dit laatste is het fysiek bij elkaar opslaan van gegevens uit gerelateerde tabellen. Dit heeft dan uiteindelijk het zelfde effect als de tabel in figuur 1 bij het artikel van Teeuwen.
Mocht dit niet voldoen, dan kan er ook gekozen worden voor een gedenormaliseerde gegevensopslag. (Ja, een relationele database kan ook niet-genormaliseerde gegevens opslaan!) Helaas ken ik nog geen databasemanagementsystemen die zo’n automatische denormalisatie van het logische databaseontwerp in de fysieke gegevensopslag ondersteunen met behoud van consistentie. Er zijn mij dan ook geen systemen bekend die ‘zo geavanceerd (zijn) dat inconsistenties automatisch vermeden worden’. Om deze reden wordt er vaak weinig aandacht besteed aan de normalisatie van het logisch databaseontwerp, hetgeen tot veel fouten in de implementatie van informatiesystemen leidt. De praktijk van alle dag leert ook dat er nog genoeg grote instellingen zijn die klantgegevens meerdere malen in gescheiden systemen opslaan.

Logisch modelleren

Verder verkondigt het artikel de tegenwoordig veelgehoorde, maar helaas incorrecte mening dat het mogelijk is om ongestructueerde gegevens automatisch te verwerken. De meeste huidige relationele databasesystemen bieden al jaren de mogelijkheid voor het opslaan van ‘binary large objects’ (blob’s). Hiermee zijn plaatjes, geluidsfragmenten en/of documenten op te slaan. Helaas is het dan niet mogelijk om op een eenvoudige manier een ‘query’ uit te voeren op de inhoud van deze blob’s. Het is echter wel goed denkbaar dat er een index aangelegd kan worden van woorden die voorkomen in een text die als blob is opgeslagen. Een relationele database leent zich erg goed voor het aanleggen van zulke indexen. Het zou me niets verbazen als verschillende internet-zoekmachines gebaseerd zijn op relationele databases. Je kunt echter alleen iets met gegevens doen als de structuur en de semantiek van deze gegevens bekend zijn.
Het is inderdaad zo dat huidige implementaties van relationele databases niet echt goed zijn in het opslaan van gegevens met een complexe structuur in een enkele tabel en dat complexe data meestal weergegeven moeten worden in een verzameling van gerelateerde tabellen. (Iedere datastructuur kan afgebeeld worden op het logische relationele datamodel!)
Dit leidt ook vaak tot complexe ‘queries’. Tegenwoordig wordt regelmatig gesuggereerd dat het gebruik van XML voor het opslaan van complexe data in een enkele tabel de oplossing is. Er is inmiddels al een aantal databases die dit ondersteunt.
XML beoogt data met zijn structuur als platte tekst weer te geven. Het biedt echter weinig mogelijkheden om data logisch te modelleren, het ondersteunt namelijk alleen de boomstructuur. (XML sucks!, maar dat is een ander verhaal.)
Het is inderdaad mogelijk om gegevens uit figuur 1 bij het artikel op te slaan in een tabel met twee kolommen: de naam van het boek en een XML-string met alle gegevens uit dat boek. Hiermee zijn dan snel alle gegevens van een boek te vinden. Als je dan echter wilt weten welke boeken een schrijver geschreven heeft, moet de volledige tabel doorgelezen worden en alle XML-strings gelezen en geanalyseerd worden. In een traditionele database zou voor deze vraagstelling maar één record via één index uit één tabel gelezen hoeven te worden.

Eerste stap

Bij het ontwerp van iedere database begin je altijd met het maken van een logisch datamodel waarin alle aspecten worden vastgelegd die automatisch bewerkt moeten kunnen worden. (Grote blokken ongestructureerde informatie die men niet door het systeem wil laten bewerken, zijn als een atomaire entiteit te beschouwen.) Pas dan kun je beginnen met het bepalen van de fysieke opslag van de gegevens. Daarbij moet vooral gekeken worden naar de frequentie en het soort bewerkingen en vraagstellingen die erop uitgevoerd moet worden. En pas dan valt te zeggen of gekozen moet worden voor een file-systeem, een traditionele relationele database, een objectgeorienteerde database, een ‘rich-content’ (XML) database of een combinatie van deze.
Het echte probleem is niet zozeer dat we een tekort hebben aan beschikbare technologieën (er zijn vele verschillende databasesystemen met even zoveel sterke en zwakke punten), maar dat er nog steeds geen goede tools bestaan om logische datamodellen af te beelden op fysieke gegevensopslagsystemen. Daardoor begint men vrijwel altijd met het inrichten van de fysieke databasestructuur en slaat men de stap van het logisch modelleren over. Het ultieme gevolg hiervan is dat er veel mensen zijn die het onderscheid tussen het logische en het fysieke niveau niet meer zien en denken dat normalisatie te maken heeft met de fysieke opslag van gegevens. Er bestaan geen goede afbeeldings-tools (van logisch naar fysiek), omdat dat niet in het belang is van databaseleveranciers. Daarmee zou de klantenbinding immers sterk verminderen.

 
Frans Faase Beugelhoek, Enschede

Meer over

ECM

Deel

    Inschrijven nieuwsbrief Computable

    Door te klikken op inschrijven geef je toestemming aan Jaarbeurs B.V. om je naam en e-mailadres te verwerken voor het verzenden van een of meer mailings namens Computable. Je kunt je toestemming te allen tijde intrekken via de af­meld­func­tie in de nieuwsbrief.
    Wil je weten hoe Jaarbeurs B.V. omgaat met jouw per­soons­ge­ge­vens? Klik dan hier voor ons privacy statement.

    Whitepapers

    Computable.nl

    Bouw de AI-organisatie niet op los zand

    Wat is de afweging tussen zelf bouwen of het benutten van cloud?

    Computable.nl

    De weg van dataverzameling naar impact

    Iedere organisatie heeft data, maar niet iedereen weet hoe je het goed gebruikt. Hoe zet je waardevolle informatie om in actie?

    Computable.nl

    In detail: succesvolle AI-implementaties

    Het implementeren van kunstmatige intelligentie (AI) biedt enorme kansen, maar roept ook vragen op. Deze paper beschrijft hoe je als (middel)grote organisatie klein kunt starten met AI en gaandeweg kunnen opschalen.

    Meer lezen

    AchtergrondData & AI

    Fokken met data

    OpinieSecurity & Awareness

    Inzicht in kwetsbaarheden aanvalsoppervlak gaat voor budget

    AchtergrondCloud & Infrastructuur

    Eigen datacenter, colocatie of cloud?

    ciso
    ActueelSecurity & Awareness

    Nova Advisor Agent: gamechanger voor ciso of ai-hype?

    AdvertorialData & AI

    Private AI helpt gemeenten met vertrouwen, veiligheid en efficiëntie

    ActueelSecurity & Awareness

    Belang digitale soevereiniteit in Europese cybersecurity neemt toe

    Geef een reactie Reactie annuleren

    Je moet ingelogd zijn op om een reactie te plaatsen.

    Populaire berichten

    Meer artikelen

    Uitgelicht

    Partnerartikel
    AdvertorialData & AI

    Private AI helpt gemeenten met vertrou...

    In een tijd waarin gemeenten geconfronteerd worden met groeiende verwachtingen van burgers, toenemende wet- en regelgeving en druk op budgetten,...

    Meer persberichten

    Footer

    Direct naar

    • Carrièretests
    • Kennisbank
    • Planning
    • Computable Awards
    • Magazine
    • Abonneren Magazine
    • Cybersec e-Magazine
    • Topics

    Producten

    • Adverteren en meer…
    • Jouw Producten en Bedrijfsprofiel
    • Whitepapers & Leads
    • Vacatures & Employer Branding
    • Persberichten

    Contact

    • Colofon
    • Computable en de AVG
    • Service & contact
    • Inschrijven nieuwsbrief
    • Inlog

    Social

    • Facebook
    • X
    • LinkedIn
    • YouTube
    • Instagram
    © 2025 Jaarbeurs
    • Disclaimer
    • Gebruikersvoorwaarden
    • Privacy statement
    Computable.nl is een product van Jaarbeurs