BE1024144B1 - Verbeterde constructie van databaseschemamodellen voor databasesystemen en rest api’s - Google Patents

Abstract

De onderhavige uitvinding heeft betrekking op een werkwijze voor het bouwen van een databaseschemamodel door een gebruiker door middel van een computer, omvattende de volgende stappen: het voorzien van een reeks verzamelingen en/of optioneel een of meerdere relaties die ten minste twee van de genoemde reeks verzamelingen verbinden; het bewerken van een of meerdere van de genoemde reeks verzamelingen, die elk zijn geassocieerd met een schemadefinitie die is getoond door een enkele tabel op een entiteitrelatiediagram op een grafische interface op de genoemde computer en omvattende ten minste één object en/of één veld, waarbij de genoemde schemadefinitie kan worden bewerkt via een boomstructuur op de genoemde grafische gebruikersinterface op de genoemde computer; het automatisch genereren door middel van de genoemde computer van het genoemde databaseschemamodel voor een databasesysteem of een REST API; met het kenmerk dat de genoemde reeks verzamelingen ten minste één verzameling omvat omvattende een genest object dat kan worden bewerkt via de genoemde boomstructuur met twee niveaus of meer.

Description

VERBETERDE CONSTRUCTIE VAN DATABASESCHEMAMODELLEN VOOR DATABASESYSTEMEN EN REST API'S

TECHNISCH GEBIED

De uitvinding heeft betrekking op het technische gebied van databasesystemen, in het bijzonder op de constructie van databaseschemamodellen voor databasesystemen en REST API's.

ACHTERGROND

Hoewel veel hedendaagse gegevensopslag- en gegevensbeheersystemen nog steeds exclusief gebaseerd zijn op relationele databasesystemen en de gerelateerde specifieke programmeertaal SQL (Structured Query Language), stappen veel toepassingsontwikkelaars over naar databasesystemen die "Not Only SQL" zijn, d.w.z. NoSQL (oorspronkelijk: "Non SQL") databasesystemen zoals MongoDB, Couchbase, CouchDB, Amazon DynamoDB, RavenDB, Microsoft Azure DocumentDB, MarkLogic, en EnterpriseDB. NoSQL-databases bieden namelijk grote voordelen voor toepassingsontwikkelaars: flexibiliteit, snelle en gemakkelijke evolutie, evenals het vermogen om gegevens op te slaan en te openen met minimale inspanning en instelling. Dit geld eveneens voor op SQON gebaseerde database voor het opslaan van documenten, een klasse NoSQL-data bases met betrekking tot de onderhavige uitvinding die georganiseerd is als documentopslagplaats (in tegenstelling tot relationele database) en gebaseerd is op JSON (JavaScript Object Notation), een formaat dat ook vaak wordt gebruikt bij de implementatie van REST API's (Application Programming Interfaces) en webservices (waarbij REST staat voor Representational State Transfer, en een systeem dat voldoet aan de zogenaamde beperkingen van REST wordt RESTful genoemd).

Net zoals voor traditionele databases heeft de planning en opstelling van een NoSQL-database een databasemodel (of map) nodig om te helpen ontwerpopties te evalueren voorafgaand aan de werkelijke implementatie. Het genoemde databasemodel helpt na te denken over de implicaties van verschillende alternatieven, mogelijke problemen te herkennen alvorens te starten met aanzienlijke hoeveelheden ontwikkelingen en op voorhand te plannen om te minimaliseren dat werk later opnieuw gedaan moet worden. Uiteindelijk versnelt een modelingproces geholpen door een goed databasemodel de ontwikkelingen, verhoogt het de kwaliteit van de toepassing en vermindert het uitvoeringsrisico's.

Verder is het genoemde databasemodel in het bijzonder belangrijk in het geval van een NoSQL-database, aangezien het kan omgaan met de verhoogde complexiteit die geassocieerd wordt met de gegevens en de (gewoonlijk, erg grote) schaal van NoSQL-databases. Verder omzeilt het het NoSQL-gerelateerde probleem dat gegevensstructuren enkel geïmpliceerd beschreven worden in de toepassingscode, waardoor iedereen die bezig is met databasebeheer de code moet onderzoeken, hetgeen uiteraard niet de meest productieve manier is voor een vruchtbare dialoog tussen analisten, architecten, ontwerpers, ontwikkelaars en DBA's.

Ondanks de populariteit van NoSQL-databases blijft er in de stand der techniek nood aan een goed databasemodel voor dit type databases. De bestaande traditionele methodes en instrumenten van klassieke relationele databases kunnen niet worden toegepast op NoSQL en REST API's. Dit argument is eigenlijk soms gebruikt als een rechtvaardiging tegen het gebruik en de implementatie van NoSQL-oplossingen.

Een eerder uitgeprobeerde oplossing heeft geprobeerd om een model te maken van een JSON-gegevensopslagplaats, maar bood geen grafische manier om de schema's van de verzamelingen voor te stellen. Een andere uitgeprobeerde oplossing bood een boomachtig gestructureerd diagram voor een enkele verzameling, maar bood geen manier om een grafisch model te maken van de verschillende verzamelingen die een database uitmaken. Een andere uitgeprobeerde oplossing definieert'visueel ontwerp' van een REST API als 'beschreven in een voor de mens leesbaar formaat -met andere woorden, gewone tekst' en slaagde er bijgevolg niet in een diagram te bieden. EP 0 910 024 beschrijft een werkwijze, en geassocieerd systeem, voor het omzetten van objectgeoriënteerde modellen in een echte bruikbare database. De werkwijze en het systeem zetten objectgeoriënteerde modellen automatisch om in ingangen die compatibel zijn met een beoogd productgegevensbeheerplatform. Een probleem met EP 0 910 024 is dat het beperkt is tot relationele databaseschemamodellen, zonder middelen om om te gaan met typische kenmerken van NoSQL-omgevingen, zoals geneste objecten. US 5.596.746 beschrijft een algoritme voor het transformeren van databaseschema-informatie in objectmodelnotatie met behulp van respectievelijk metamodellen van de databasetabellen en doelobjectmodelnotatie voor het overbruggen van de kloof tussen de databaseschemavoorstelling en de objectmodelvoorstelling. Gelijkaardig aan EP 0 910 024 is US 5.596.746 beperkt tot relationele databaseschemamodellen, en heeft het daarom geen mechanismen om om te gaan met No-SQL-gerelateerde kenmerken zoals geneste objecten.

De onderhavige uitvinding heeft als doel het oplossen van ten minste sommige van de bovengenoemde problemen. De uitvinding heeft daarom als doel een werkwijze en systeem te bieden voor het grafisch maken van een model van schema's voor NoSQL-documentdatabases en REST API's die zowel functioneel als duidelijk zijn, waardoor het werk van, en de dialoog tussen analisten, architecten, ontwerpers, ontwikkelaars, testers en operators van systemen die gebaseerd zijn op dergelijke technologieën wordt vergemakkelijkt.

SAMENVATTING VAN DE UITVINDING

In de databasegemeenschap is er steeds meer nood aan databasebeheersystemen (DMBS's) die een combinatie van gegevensmodellen, relationele en niet-relationele, ondersteunen in een enkel DBMS-platform. Een convergentie tussen RDBMSes en andere gegevensmodellen (bijv. Een NoSQL-documentdatabase) vindt bijgevolg plaats, waardoor de nood wordt gecreëerd aan multi-model databaseschemamodellen, en nieuwe werkwijzen die geschikt zijn voor de constructie van een breed gamma databaseschemamodellen, inclusief klassieke en multi-model databaseschemamodellen. De onderhavige uitvinding is gericht op dergelijke werkwijzen en systemen voor het bouwen van een databaseschemamodel. De onderhavige uitvinding heeft in het bijzonder betrekking op een GUI-ondersteunde constructiewerkwijze van databaseschemamodellen die de typische, tabelachtige voorstelling van verzamelen uitbreidt, bekend bijv. van zowel RDBMSes als NoSQL-documentdatabases, met het concept van het nesten van een of meerdere objecten binnen een enkele verzameling met tabelachtige voorstelling, wat niet mogelijk is met werkwijzen volgens de stand der techniek. Bewerking van de genoemde enkele verzameling wordt ingeschakeld door een gerelateerde boomstructuur, die de schemadefinitie van de genoemde enkele verzameling voorstelt. In dit opzicht biedt de onderhavige uitvinding een erg algemene oplossing voor een bekend probleem, zoals het voorbeeld van het basisprobleem dat hieronder is voorgesteld in het deel "Gedetailleerde beschrijving" (Voorbeeld 2), wat een duidelijke en toegankelijke inleiding geeft tot het algemene concept.

In een eerste aspect heeft de onderhavige uitvinding betrekking op een werkwijze voor het bouwen van een databaseschemamodel door een gebruiker door middel van een computer, omvattende de volgende stappen: (a) het voorzien van een reeks verzamelingen en optioneel een of meerdere relaties die ten minste twee van de genoemde reeks verzamelingen verbindt; (b) het bewerken van een of meerdere van de genoemde reeks verzamelingen, die elk zijn geassocieerd met een schemadefinitie weergegeven door een enkele tabel op een entiteitrelatiediagram op een grafische interface op de genoemde computer en omvattende ten minste één object en/of één veld, waarbij de genoemde schemadefinitie kan worden bewerkt via een boomstructuur op de genoemde grafische gebruikersinterface op de genoemde computer; (c) het automatisch genereren door middel van de genoemde computer van het genoemde databaseschemamodel voor een databasesysteem of een REST API; met het kenmerk dat de genoemde reeks verzamelingen ten minste één verzameling omvat omvattende een genest object dat kan worden bewerkt via de genoemde boomstructuur met twee niveaus of meer.

De genoemde "reeks" kan hierbij een of meerdere verzamelingen omvatten. In een voorkeur dragende uitvoeringsvorm van de werkwijze volgens de onderhavige uitvinding omvat de genoemde reeks verzamelingen ten minste twee verzamelingen en omvat stap (b) het genereren en/of bewerken van een of meerdere relaties die ten minste twee verzamelingen verbinden die behoren tot de genoemde reeks verzamelingen via het genoemde entiteitrelatiediagram op de genoemde gebruikersinterface op de genoemde computer; en ten minste één van de genoemde een of meerdere relaties een eerste veld dat behoort tot een reeks verzameling die behoort tot de genoemde reeks verzameling verbindt met een tweede veld dat behoort tot een tweede verzameling die behoort tot de genoemde reeks verzamelingen.

In de context van de onderhavige uitvinding omvat de term "verzameling" enige tabelachtige voorstelling van gegevens binnen de context van databases en databasebeheersystemen (DBMSes), zoals een verzameling in een NoSQL-documentdatabase, een REST API-object, of een "klassieke" tabel in een relationeel databasebeheersysteem (RDBMS). Ongeacht of de genoemde verzamelingen gegenereerd zijn door de gebruiker via de genoemde grafische gebruikersinterface of dat de genoemde verzamelingen geïmporteerd zijn vanuit een ander formaat met betrekking tot bijv. een NoSQL-documentdatabase, is een REST API of een RDBMS, de grafische interactieve voorstelling op een grafische gebruikersinterface van de genoemde verzamelingen en de onderlinge relaties daarvan, een integraal deel van de onderhavige uitvinding.

Voor de genoemde grafische interactieve voorstelling van de genoemde verzamelingen wordt er een boomstructuur gebruikt. De term "boomstructuur" omvat hier een boomachtig gestructureerd diagram, waarbij het genoemde diagram knooppunten en vertakkingen omvat. Hierbij is één van de genoemde knooppunten een hoofdknooppunt dat zich op het zogenaamde hoogste niveau bevindt, verbonden met verschillende knooppunten op een lager niveau door vertakkingen, dewelke knooppunten, op hun beurt, verbonden kunnen zijn met vertakkingen op nog lagere niveaus. Hier wordt het aantal niveaus getest exclusief het bovenste niveau. Een knooppunt dat niet verbonden is met knooppunten op een lager niveau, wordt een bladknooppunt genoemd. Elk knooppunt kan een veld of een object omvatten, waarbij een object op een bepaald niveau verschillende knooppunten omvat op een niveau dat lager is dan het genoemde bepaalde niveau. Een genest object is daarom een object dat is ingesloten als knooppunt binnen een grotere verzameling, waarbij de aanwezigheid van het genoemde geneste object resulteert in twee niveaus of meer voor de boomstructuur van de genoemde grotere verzameling. In werkwijzen volgens de stand der techniek wordt het genoemde geneste object niet gevonden in RDBMSes, aangezien ze uitgaan van "flat tables", beperkt tot een tabeltitel op het bovenste niveau, en een of meerdere attributen op het eerste niveau. Dit is een resultaat van het feit dat de genoemde knooppunten in de genoemde boomstructuur, in RDBMSes, allemaal betrekking hbben op velden en niet objecten, waarbij velden standaard bladknooppunten zijn. Zo ook wordt de genoemde boomstructuur met de genoemde twee niveaus gevonden in NoSQL document DBMSes.

De interactie van de gebruiker met de genoemde grafische interactieve voorstelling van de genoemde verzamelingen laat een verscheidenheid van interactieve manipulaties toe, zoals de bewerking van eigenschappen van elk knooppunt, de herschikking van knooppunten binnen een verzameling, en de verplaatsing van knooppunten van de ene verzameling naar een andere verzameling.

Voor de genoemde grafische interactieve voorstelling van de genoemde relaties wordt er een entiteitrelatiediagram gebruikt. Hierbij moet de term "entiteitrelatiediagram" geïnterpreteerd worden in de context van databases van DBMSes, met entiteiten overeenkomstig verzamelingen, en relaties tussen een eerste veld in een eerste verzameling en een tweede veld in een tweede verzameling. Dit type grafische interactieve voorstelling wordt gedeeltelijk gevonden in RDBMS en NoSQL werkwijzen volgesn de stand der techniek. Een gerelateerde grafische voorstelling wordt gevonden in veel RDBMSes, waarbij elke verzameling (een 'flat table') een enkele entiteit is die betrekking heeft op een of meerdere andere verzamelingen door een vreemde-sleutel relatie, omvattende de concepten van een vreemde sleutel en een primaire sleutel die bekend zijn bij de vakman. In een voorkeur dragende uitvoeringsvorm volgens de onderhavige uitvinding kunnen twee verzamelingen gelinkt worden door meer dan één relatie. Hierbij kunnen de genoemde relaties betrekking hebben op vreemde-sleutel relaties, maar kunnen ze ook betrekking hebben op vreemde-master relaties. Het linken van verzamelingen door meer dan één relatie is wenselijk met het oog op de aanwezigheid van geneste objecten, die gewoonlijk een veelvoud van relaties vertonen, bijvoorbeeld omwille van de toepassing van zogenaamde denormalisatie zoals in dit document wordt beschreven. Aangezien RDBMSes nesten van objecten niet toelaat, is er minder nood aan meer dan één relatie tussen twee verzamelingen. Bovendien is de reden dat de genoemde grafische interactieve voorstelling van de genoemde relaties niet gevonden wordt in NoSQL werkwijzen volgens de stand der techniek in het feit dat NoSQL-modellen inherent geen schema hebben, waarbij verzamelingen hoofdzakelijk als geïsoleerde entiteiten worden geadresseerd, zonder een nuttige manier voor het definiëren van relaties tussen een eerste veld van een eerste verzameling en een tweede veld van een tweede verzameling.

De interactie van de gebruiker met de genoemde grafische interactieve voorstelling van de genoemde relaties laat ook een verscheidenheid van interactieve manipulaties toe, zoals de bewerking van eigenschappen van elk relatie en de herschikking van verzamelingen voor het genereren van nieuwe relaties of voor het bewerken van bestaande relaties.

In het algemeen heeft de onderhavige uitvinding als voordeel dat een erg algemene structuur kan worden gehandhaafd, zoals een JSON-structuur, door verbeterde structuur (minder verzamelingen, enkel "echte" relaties) (in het bijzonder in de ERD), sequentiebehoud (zowel in de ERD en de boomstructuur), interactie (zoals in de ERD als de boomstructuur), en indentatie (hetgeen nesting weergeeft) (in het bijzonder in de ERD), terwijl werkwijzen volgens de stand der techniek dit niet doen. Het resultaat van de onderhavige werkwijze is niet enkel meer trouw aan de overeenkomstige algemene structuur, zoals een JSON-documentdefinitie, maar is ook compacter in termen van ERD, waardoor een duidelijker en algemeen beter overzicht mogelijk is. Daarnaast is de interactieve bewerking van het databaseschemamodel ook flexibeler, met rijkere interactie dankzij de keuze tussen de ERD en de boomstructuur. Dit wordt meer in detail besproken in voorbeeld 2. Een gerelateerd voordeel is het vermogen om beter te kunnen omgaan met polymorfismen, zoals meer in detail wordt besproken in voorbeeld 4.

Een belangrijk voordeel van een uitvoeringsvorm van de onderhavige uitvinding is dat de gebruiker niet langer beperkt is door de beperkingen van NoSQL en RDMBS werkwijzen volgens de stand der techniek, waardoor zowel nesting van objecten als de generatie van veelzijdige relaties mogelijk is. In een voorkeur dragende uitvoeringsvorm kunnen individuele verzamelingen (die betrekking kunnen hebben op NoSQL-verzamelingen, maar ook betrekking kunnen hebben op REST-API-objecten) worden bewerkt in JSON-schemadefinitie via een boomstructuur, terwijl de relaties tussen verzamelingen tegelijkertijd kan worden bewerkt via het genoemde entiteitrelatiediagram. In een verdere voorkeur dragende uitvoeringsvorm leidt dit tot een enkele geïntegreerde interactieve voorstelling zoals is geïllustreerd, bijv. door fig. 60, 61, 63, 65, 66 en 68, hetgeen de doeltreffendheid in grote mate verbetert waarmee het genoemde databaseschemamodel kan worden gebouwd en bewerkt. Door het voorzien van een dergelijke expliciete voorstelling lost de onderhavige uitvinding ook het probleem op met bekende NoSQL-werkwijzen, waarbij gegevensstructuren enkel stilzwijgend worden beschreven in de toepassingscode.

Een gerelateerd voordeel van de onderhavige uitvinding is het vermogen om een model te kunnen maken van relaties. Zoals hierboven is vermeld, hebben NoSQL-modellen inherent geen schema, waardoor verzamelingen hoofdzakelijk geadresseerd worden als geïsoleerde entiteiten, zonder de mogelijkheid om relaties te definiëren tussen een eerste veld van een eerste verzameling en een tweede veld van een tweede verzameling. Dit laatste is in het bijzonder problematisch wanneer een gebruiker een relationeel databaseschemamodel in een NoSQL-omgeving wil importeren, of, om welke reden dan ook, een RDBMS-achtige benadering wil volgen door verzamelingen te linken. Terwijl de vreemde-sleutel relaties die zijn opgenomen in het relationele databaseschema gewoonlijk een belangrijke rol spelen in de organisatie van gegevens, is er geen concept beschikbaar in NoSQL om een model te maken voor deze of andere relaties. In een voorkeur dragende uitvoeringsvorm van de onderhavige uitvinding laat het databaseschemamodel toe vreemde-sleutel relaties te genereren en te bewerken, en, gerelateerd, vreemde-sleutel relaties intact te laten wanneer relationele databaseschemamodellen worden geïmporteerd.

In een verdere voorkeur dragende uitvoeringsvorm van de werkwijze volgens de onderhavige uitvinding omvatten de genoemde een of meerdere objecten een array en/of een subdocument. Dit laat toe structuren op te nemen die bekend zijn uit NoSQL. Dit speelt ook een belangrijke rol in de hieronder beschreven denormalisatie.

In een verdere voorkeur dragende uitvoeringsvorm is het genoemde databaseschemamodel geformatteerd volgens enige of enige combinatie van de volgende formaten: JSON-Schema, YAML, Mongoose, RAML, Swagger, Apache AVRO of Parquet. Dit heeft het voordeel dat het gebruiker een formaat biedt dat overeenstemt met zijn of haar specifieke behoeften.

Volgens een andere voorkeur dragende uitvoeringsvorm genereert de genoemde automatische generatie in stap (d) automatisch een voor de mens leesbare handleiding voor het genoemde databaseschemamodel ten minste gedeeltelijk gebaseerd op een logische link die is gedefinieerd door de genoemde een of meerdere relaties. Dit heeft als voordeel dat het de automatische generatie van handleidingen vergemakkelijkt, door het opnemen van de informatie die inherent is aan de relaties in de gegenereerde handleiding.

In een andere voorkeur dragende uitvoeringsvorm zijn de genoemde eerste verzameling en de genoemde tweede verzameling gelinkt door meer dan één relatie die is gegenereerd en/of bewerkt in stap (c). Dit heeft als voordeel dat beperkingen die zijn opgelegd door traditionele werkwijzen volgens de stand der techniek verder kunnen worden opgeheven. In tegenstelling tot NoSQL DBMSes ondersteunt het databaseschemamodel volgens de onderhavige uitvinding expliciet relaties tussen verzamelingen; in tegenstelling tot RDBMSes kunnen twee verzamelingen door meer dan één relatie gerelateerd zijn. In een gerelateerde verdere uitvoeringsvorm is het genoemde eerste veld dat behoort tot de genoemde eerste verzameling gelinkt met zowel het genoemde tweede veld als een derde veld dat behoort tot respectievelijk de genoemde tweede verzameling door een eerste en tweede relatie. Door meerdere relaties toe te laten die zijn geassocieerd met een enkel veld, die bij voorkeur zijn getoond in een enkele geïntegreerde grafische interactieve voorstelling, wordt de flexibiliteit voor de eindgebruiker verhoogd.

In een verdere voorkeur dragende uitvoeringsvorm omvat het genoemd voorzien in stap (a) het genereren van een of meerdere van de genoemde reeks verzamelingen op de genoemde grafische gebruikersinterface op de genoemde computer. De gebruiker kan dus kiezen om een of meerdere verzamelingen rechtstreeks op het scherm te genereren, en een databaseschemamodel bouwen op basis daarvan. Dit heeft als voordeel dat de gebruiker manueel tussenbeide kan komen in de genoemde constructie, of zelfs een databaseschemamodel van het begin af kan bouwen.

Volgens een verdere uitvoeringsvorm omvat het genoemd voorzien in stap (a) het denormaliseren van een relationeel databaseschemamodel dat is voorzien door de gebruiker, waarbij het genoemd denormaliseren het extraheren omvat van de genoemde reeks verzamelingen uit een reeks tabellen die behoren tot het genoemde relationele databaseschemamodel, evenals enige vreemde-sleutel relaties die behoren tot het genoemde relationele databaseschemamodel, voor opname in het genoemde databaseschemamodel. Dit heeft als praktisch voordeel dat een gebruiker die een database wil bouwen met NoSQL-functies zoals het genoemde databaseschemamodel, een bestaand beschikbaar relationeel databaseschemamodel kan nemen als een startpunt, zoals vaak wenselijk is in de praktijk. Door zowel de verzamelingen als de vreemde-sleutel relaties te "importeren", worden alle vitale aspecten van de relationele database overgedragen naar het genoemde databaseschemamodel dat moet worden gebouwd. Volgens een gerelateerde verdere uitvoeringsvorm omvat het genoemd denormaliseren in stap (a) verder het verwerken van een vreemde-sleutel relatie tussen een bovenliggende verzameling omvattende een primaire sleutel en een onderliggende verzameling omvattende een vreemde sleutel, waarbij de genoemde verwerking enige of enige combinatie van de volgende omvt: het opnemen van een genest subdocument in de genoemde onderliggende verzameling, waarbij het genoemde geneste subdocument een of meerdere relaties omvat in de genoemde bovenliggende verzameling; het opnemen van een geneste array in de genoemde bovenliggende verzameling, waarbij de genoemde geneste array een of meerdere relaties omvat in de genoemde onderliggende verzameling. Dit heeft als voordeel dat de functies van de relationele database "zonder verlies" vertaald worden naar een context met geneste objecten, hetgeen niet mogelijk is in een RDBMS. Dit kan gebeuren volgens verschillende strategieën die hierboven zijn opgenomen en die in de onderstaande beschrijving verder uitgelegd worden. In een zin omvat deze vertaling een "upgrade" van het oorspronkelijke relationele databaseschemamodel, omdat de oorspronkelijke verzamelingen en relaties behouden worden, terwijl de mogelijkheden van het interageren met de genoemde database uitgebreid zijn om NoSQL-functionaliteit te omvatten. In een verdere gerelateerde uitvoeringsvorm omvat de genoemde verwerking van een vreemde-sleutel relatie het selecteren van een of meerdere denormalisatievoorkeuren op de genoemde grafische gebruikersinterface op de genoemde computer, waarbij de genoemde denormalisatievoorkeuren enige of enige combinatie van de volgende omvatten: een tabelselectie; een inbeddingsvoorkeur met betrekking tot het genoemd opnemen van het genoemd geneste subdocument in de genoemde onderliggende verzameling en/of de genoemde geneste array in de genoemde bovenliggende verzameling; een maximum aantal gestapelde niveaus; een maximum aantal recursieniveaus. Dit heeft als voordeel dat de gebruiker de manier kan aanpassen waarop de oorspronkelijke relationele database wordt vertaald naar het genoemde databaseschemamodel, met het oog op een beknopter resultaat (bijv. Minder tabellen, minder nesting, minder recursies) of een uitgebreider resultaat (meer tabellen, meer nesting, meer recursies).

In een tweede aspect biedt de onderhavige uitvinding een door de computer geïmplementeerde werkwijze voor het bouwen van een databaseschemamodel bij ingave van een gebruiker volgens een werkwijze volgens de onderhavige uitvinding, omvattende de volgende stappen: (i) het ontvangen van een reeks verzamelingen en/of optioneel een of meerdere relaties die ten minste twee van de genoemde reeks verzamelingen linken, optioneel bij ingave van de genoemde gebruiker via een grafische gebruikersinterface; (ii) het ontvangen van bewerkingsinstructies voor elk van de genoemde reeks verzamelingen met betrekking tot een schemadefinitie bij ingave van de genoemde gebruiker via een boomstructuur op de genoemde grafische interface; (iii) het genereren op verzoek van de genoemde gebruiker van het genoemde databaseschemamodel voor een databasesysteem of een REST API; met het kenmerk dat de genoemde reeks verzamelingen ten minste één verzameling omvat omvattende een genest object dat kan worden bewerkt via de genoemde boomstructuur met twee niveaus of meer.

In een voorkeur dragende uitvoeringsvorm van de genoemde door de computer geïmplementeerde werkwijze omvat de genoemde reeks verzamelingen ten minste twee verzamelingen, en omvat stap (ii) het ontvangen van generatie- en/of bewerkingsinstructies met betrekking tot een of meerdere relaties die ten minste twee verzamelingen linken die behoren tot de genoemde reeks verzamelingen bij ingave van de genoemde gebruiker via het genoemde entiteitrelatiediagram op de genoemde grafische gebruikersinterface. Verder linkt ten minste één van de genoemde een of meerdere relaties een eerste veld dat behoort tot een eerste verzameling die behoort tot de genoemde reeks verzamelingen met een tweede veld dat behoort tot een tweede verzameling die behoort tot de genoemde reeks verzamelingen.

In een derde aspect voorziet de onderhavige uitvinding het gebruik van een databaseschemamodel dat is gebouwd met een werkwijze volgens enige van de onderhavige uitvinding in een databasesysteem of een REST API. In een voorkeur dragende uitvoeringsvorm daarvan is het genoemde databasesysteem enige of enige combinatie van de volgende: MongoDB, Couchbase, CouchDB, Amazon DynamoDB, RavenDB, Microsoft Azure DocumentDB, MarkLogic, EnterpriseDB, Oracle SQL, MySQL, PostgreSQL, Microsoft SQL, Oracle for NoSQL, ElasticSearch, Snowflake, FinchDB, MariaDB, IBM Cloudant, Google Cloud Datastore, Cassandra, BerkeleyDB, RethinkDB, Mapr. Dit heeft als voordeel dat het een superieure gebruikerservaring biedt omwille van de integratie van de onderhavige uitvinding in de werkomgevingen waarop het van toepassing is, hetgeen een beter gebruikerscomfort oplevert voor de gebruiker.

In een vierde aspect biedt de onderhavige uitvinding een computersysteem voor het bouwen van een databaseschemamodel bij ingave van een gebruiker, waarbij het genoemde computersysteem een processor, een niet-vluchtig geheugen, programmacode op het genoemde geheugen voor uitvoering op de genoemde processor, een grafische interface omvat, waarbij de genoemde computer is geconfigureerd voor het uitvoeren van een door de computer geïmplementeerde werkwijze volgens de onderhavige uitvinding. De voordelen van een dergelijke computer zijn gelijkaardig aan deze van de gerelateerde door de computer geïmplementeerde werkwijze.

BESCHRIJVING VAN DE FIGUREN

De onderhavige uitvinding kan gemakkelijk beschreven worden met verwijzing naar de bijbehorende figuren, waarbij:

Figuur 1 trends in de opkomst van JSON illustreert.

Figuur 2 het domeinmodel illustreert.

Figuur 3 de grafische gebruikersinterface illustreert.

Figuur 4 de menubalk illustreert.

Figuur 5 het bestandsmenu toont (item: Export).

Figuur 6 het bestandsmenu toont (item: Reverse Engineer).

Figuur 7 de Objectbrowser illustreert.

Figuur 8 een eerste zicht van een middelste vak toont, waarin een voorbeeld van een entiteitrelatiediagram wordt getoond.

Figuur 9 een tweede zicht van een middelste vak toont, waarin een voorbeeld van een boomachtig gestructureerd diagram wordt getoond.

Figuur 10 een derde zicht van een middelste vak toont, waarin een voorbeeld van een roosterzicht getoond.

Figuur 11 een vierde zicht van een middelste vak toont, waarin een voorbeeld van een JSON preview getoond.

Figuur 12 een vijfde zicht van een middelste vak toont, waarin een voorbeeld van een databaseaanmaakscript wordt getoond.

Figuur 13 een zesde zicht van een middelste vak toont, waarin een voorbeeld van een databasedocumentatie wordt getoond.

Figuur 14 voorbeelden van bovenste tabbladen van het middelste vak toont. Figuur 15 de eerste reeks van onderste tabbladen van het middelste vak toont (overeenkomstig het bovenste databasetabblad).

Figuur 16 de tweede reeks van onderste tabbladen van het middelste vak toont (overeenkomstig de bovenste verzamelingtabbladen).

Figuur 17 de contextuele menu's toont (item: Uitlijnen).

Figuur 18 de contextuele menu's toont (item: Onderliggend niveau toevoegen). Figuur 19 de contextuele menu's toont (item: Referentie).

Figuur 20 een eerste zicht van de eigenschappen op databaseniveau toont.

Figuur 21 een tweede zicht van de eigenschappen op databaseniveau toont. Figuur 22 een derde zicht van de eigenschappen op databaseniveau toont.

Figuur 23 een eerste zicht van de eigenschappen op verzamelingniveau toont. Figuur 24 een tweede zicht van de eigenschappen op verzamelingniveau toont. Figuur 25 een derde zicht van de eigenschappen op verzamelingniveau toont. Figuur 26 een eerste zicht van de eigenschappen op veldniveau toont.

Figuur 27 een tweede zicht van de eigenschappen op veldniveau toont.

Figuur 28 een derde zicht van de eigenschappen op veldniveau toont.

Figuur 29 een eerste stap bij het aanmaken van een model illustreert.

Figuur 30 een tweede stap bij het aanmaken van een model illustreert.

Figuur 31 het tabblad 'Details' van de eigenschappen van een database toont. Figuur 32 het tabblad 'Relaties' van de eigenschappen van een database toont. Figuur 33 het tabblad 'Gebruikers' van de eigenschappen van een database toont. Figuur 34 een eerste stap bij het aanmaken en bewerken van een model toont. Figuur 35 een tweede stap bij het aanmaken en bewerken van een model toont. Figuur 36 een derde stap bij het aanmaken en bewerken van een model toont.

Figuur 37 het tabblad 'Details' van de eigenschappen van een verzameling toont. Figuur 38 het tabblad 'Gebruikers' van de eigenschappen van een verzameling toont.

Figuur 39 het tabblad 'Indices' van de eigenschappen van een verzameling toont. Figuur 40 het aanmaken van velden voor een verzameling illustreert.

Figuur 41 de non-root elementen illustreert die kunnen worden aangemaakt. Figuur 42 de eigenschappen van een veld toont.

Figuur 43 een eerste stap toont bij het toevoegen van entry's met een 'plus'-pictogram in de veldeigenschappen.

Figuur 44 een tweede stap toont bij het toevoegen van entry's met een 'plus'-pictogram in de veldeigenschappen.

Figuur 45 het geval toont van meerdere types in de veldeigenschappen.

Figuur 46 de referentieoptie in het contextuele menu toont.

Figuur 47 een grafisch zicht van de definities op verzamelingniveau toont.

Figuur 48 een grafisch zicht van de definities op databaseniveau toont.

Figuur 49 een voorbeeld van een roosterzicht toont.

Figuur 50 een voorbeeld van een JSON preview toont.

Figuur 51 een voorbeeld van documentatie toont.

Figuur 52 een voorbeeld van een databasescript toont.

Figuur 53 de exportfunctie illustreert.

Figuur 54 het dialoogvenster Afdrukken toont.

Figuur 55 het dialoogvenster Afdrukken instellen toont.

Figuur 56 de optiesinterface toont.

Figuur 57 de JSON-schemaweergaveconfiguratie toont.

Figuur 58 twee 'flat tables' toont in een bronmodel.

Figuur 59 een vreemde-sleutel relatie illustreert.

Figuur 60 een denormalisatieresultaat toont.

Figuur 61 een denormalisatieresultaat toont.

Figuur 62 een vreemde-sleutel relatie illustreert.

Figuur 63 een denormalisatieresultaat toont.

Figuur 64 drie 'flat tables' toont in een bronmodel.

Figuur 65 een normalisatieresultaat toont.

Figuur 66 een denormalisatieresultaat toont.

Figuur 67 een 'flat table' toont in een bronmodel.

Figuur 68 twee denormalisatieresultaten toont.

Figuur 69 drie 'flat tables' toont in een bronmodel.

Figuur 70 de menutoegang illustreert.

Figuur 71 een waarschuwing toont met betrekking tot besparing van het huidige model.

Figuur 72 een parameterinterface toont met betrekking tot het denormalisatieproces.

Figuur 73 een voorbeeldprobleem toont met een oplossing volgens de onderhavige uitvinding.

Figuur 74 het "JSON document tot model" van het voorbeeldprobleem toont. Figuur 75 het "Modeling met traditionele ER-software" van het voorbeeldprobleem toont.

Figuur 76 de "Modeling volgens de onderhavige uitvinding" (deel 1 van 2) van het voorbeeldprobleem toont.

Figuur 77 de "Modeling volgens de onderhavige uitvinding" (deel 2 van 2) van het voorbeeldprobleem toont.

Figuur 78 een voorbeeldinterface toont met betrekking tot verwijzing en denormalisatie.

Figuur 79 een voorbeeld toont met betrekking tot verwijzing en denormalisatie. Figuur 80 een voorbeeld-ERD toont.

Figuur 81 een voorbeeld van een boomschema toont.

GEDETAILLEERDE BESCHRIJVING VAN DE UITVINDING

In het onderhavige document heeft de term "document" betrekking op een verzameling; in het bijzonder worden gegevens die behoren tot een verzameling gewoonlijk opgeslagen in een of meerdere documenten, bij voorkeur JSON-documenten. In dit document vallen zowel "vreemde-master relaties" als "vreemde-sleutel relaties" onder de klasse van "relaties", waarbij vreemde-master relaties betrekking hebben op relaties die geen vreemde-sleutel relaties zijn. Verder staat het acroniem "GUI" voor grafische gebruikersinterface (Graphical User Interface).

Een belangrijke doelstelling van de onderhavige uitvinding is het bieden aan programmeurs, toepassingsontwikkelaars en databasebeheerders van een krachtige nieuwe werkwijze voor het bouwen van databasemodellen. Daartoe combineert de onderhavige uitvinding de grafische interactieve voorstelling van verzamelingen in een boomstructuur met de grafische interactieve voorstelling van relaties tussen verzamelingen in een entiteitrelatiediagram. Samen bieden deze grafische voorstellingen zowel het schemamodel als de documentatie van dat model. De onderhavige uitvinding vergemakkelijkt het werk van, en de dialoog tussen verscheidene gebruikers zoals analisten, architecten, ontwerpers, ontwikkelaars, testers en operatoren van systemen die op dergelijke technologieën zijn gebaseerd. In een voorkeur dragende uitvoeringsvorm van de onderhavige uitvinding kunnen schema's en documentatie worden gegenereerd in verscheidene op machine gebaseerde formaten zoals JSON Schema, Mongoose, verzamelingsdefinitiescripts, RAML, Swagger, YAML, Apache AVRO of Parquet, of door de mens leesbare formaten. In een verdere voorkeur dragende uitvoeringsvorm wordt de gebruiker geholpen bij het importeren van een relationeel databaseschemamodel, en de vertaling ervan in een databaseschemamodel volgens de onderhavige uitvinding.

Volgens een ander aspect van de huidige uitvinding, die niet bedoeld is om het bereik op enige manier te beperken, biedt de onderhavige uitvinding een wekwijze en systeem voor het maken van een grafisch model van een databaseschemamodel voor NoSQL-documentdatabases en REST API's. Het biedt in het bijzonder een werkwijze en systeem voor het combineren van 1) de grafische voorstelling van verzamelingen (in NoSQL-Documentdatabases) of objecten (in REST API's) door een Entiteitrelatiediagram, met 2) de grafische voorstelling van de JSON-Schemadefinitie van de genoemde verzamelingen of objecten door een boomachtig gestructureerd diagram. Samen bieden deze grafische voorstellingen het schemamodel van een NoSQL-documentdatabase of REST API, en de documentatie van dat model. De uitvinding wordt verder beschreven door het volgende niet-beperkende voorbeeld dat de uitvinding verder illustreert, en is niet bedoeld voor, of mag niet geïnterpreteerd worden als, het beperken van het bereik van de uitvinding.

Volgens een ander aspect van de huidige uitvinding, die niet bedoeld is om het bereik om welke manier dan ook te beperken, biedt de onderhavige uitvinding een werkwijze voor het maken van een grafisch model van schema's voor NoSQL-documentdatabases en REST API's, omvattende het bieden van een grafische voorstelling van een of meerdere verzamelingen of een of meerdere objecten, en het tegelijkertijd bieden van een grafische voorstelling van een JSON-Schemadefinitie van de genoemde verzamelingen of objecten door een boomachtig gestructureerd diagram.

Volgens een ander aspect van de huidige uitvinding, die niet bedoeld is om het bereik om welke manier dan ook te beperken, biedt de onderhavige uitvinding een systeem voor het maken van een grafisch model van schema's voor NoSQL-documentdatabases en REST API's, waarbij het genoemde systeem is geconfigureerd voor het bieden van een grafische voorstelling van een of meerdere verzamelingen of een of meerdere objecten, en voor het tegelijkertijd bieden van een grafische voorstelling van een JSON-Schemadefinitie van de genoemde verzamelingen of objecten dooreen boomachtig gestructureerd diagram.

De onderhavige uitvinding is gericht op de constructie van databaseschemamodellen, waarbij het databaseschemamodel een eenvoudige bekende voorstelling kan zijn zoals een enkel JSON-document, maar ook een "multi-model" databaseschemamodel, zolang het databaseschemamodel de genoemde nesting vertoont overeenkomstig een boomstructuur met twee niveaus of meer. De term "multi-model" verwijst hierbij naar een databaseschemamodel dat kenmerken omvat van zowel relationele databases als NoSQL-databases, en kan bijgevolg niet toegewezen worden aan slechts één van deze categorieën, zoals momenteel opkomt in de databasegemeenschap.

De onderhavige uitvinding heeft betrekking op databaseschemamodellen zoals deze beschouwd door MongoDB en andere NoSQL-systemen zoals DynamoDB. Hierbij zijn verschillende specifieke termen ontleend uit de context van bestaande systemen, in het bijzonder MongoDB. Het is echter belangrijk op te merken dat de termen die in de onderhavige uitvinding worden gebruikt, zijn gekozen in overeenstemming met MongoDB louter omwille van de duidelijkheid, en dat ze niet mogen worden geïnterpreteerd als een beperking op welke manier dan ook van de uitvinding. De term "verzameling" (Eng.: collection), "document", "veld", "subdocument" en "array" zijn bijgevolg gelijkaardig, maar niet noodzakelijk identiek aan de equivalente termen met dezelfde naam in MongoDB en veel landere NoSQL-systemen en/of RDBMSes. Bovendien gebruiken sommige NoSQL-systemen andere termen; DynamoDB gebruikt in het bijzonder een andere overeenkomst inzake namen. Couchbase en Cassandro gebruiken ook een iets andere terminologie. De volgende lijst van equivalente termen is opgenomen voor de duidelijkheid, zonder de onderhavige uitvinding op welke manier dan ook te willen beperken.

Hieronder vindt u vier voorbeelden met betrekking tot uitvoeringsvormen van de onderhavige uitvinding. Hoewel voorbeeld 1 gericht is op een veelvoud van aspecten van de uitvinding, beschouwt voorbeeld 2 het eenvoudige geval van een enkele JSON-document met nesting, waarvoor de uitvinding eveneens van toepassing is. Voorbeeld 3 heeft betrekking op verwijzing bij denormalisatie. Voorbeeld 4 beschouwt een voorbeeld van ERD met geassocieerde boomstructuur volgens een uitvoeringsvorm van de onderhavige uitvinding. VOORBEELD 1 1. Projectdrivers

Het project heeft betrekking op de activiteiten van IntergrIT (zaken doen als Hackolade). 1.1 Referenties

De hiernavolgende beschrijving kan nuttig zijn voor het informeren van de lezer van de context: JSON- en BSON-specificaties: http://json.org/ en http://bsonspec.org/ JSON-Schemaspecificatie: http://json-schema.org/

Trends in de opkomst van JSON, cfr Fig 1 1.2 Het gebruikersprobleem en context van het project 1.2.1 NoSQL-databases zonder schema JSON-gebaseerde documentopslagplaats NoSQL databases (MongoDB, Couchbase, CouchDB, Amazon DynomoDB, MarkLogic, OrientDB, RavenDB, Microsoft Azure

DocumentDB, EnterpriseDB, enz., cfr. http://db- engines.com/en/ranking/document+store) promoten het concept van een benadering "zonder schema's" met veel voordelen, zoals de flexibiliteit voor het schema om gemakkelijk te evolueren in de loop van de tijd, of het vermogen om het opslaan en openen van gegevens te starten zonder eerst een schema te definiëren.

De datatransformaties en gegevenskenmerken in NoSQL-systemen worden vaak ingedeeld in modellen. De instrumenten voor een dergelijke modeling bestonden niet. De gegevens worden vaak vastgelegd in modellen; het is geïmpliceerd in de code. Om te begrijpen hoe de gegeven worden opgeslagen en gelezen, moet de code worden onderzocht. Het model is in hoofdzaak "impliciet" voor de programmeurs en ontwikkelaars die aan het systeem werken: het zit in hun hersenen en wordt dan gemanifesteerd in de code van het systeem.

Het voordeel van een DBMS zonder schema's is dat men gegevens kan beginnen opslaan en openen zonder eerst een formeel schema te definiëren. Hoewel dit fantastisch klinkt, en vast en zeker een snelle start van een gegevensproject vergemakkelijkt, toont de ervaring dat een gebrek aan op voorhand denken gewoonlijk wordt gevolgd door veel achteraf denken. Aangezien de gegevensvolumes toenemen en de openingstijden significant worden, moet er worden nagedacht voor de reorganisatie van gegevens om het openen en bijwerken te versnellen, en soms de wisselwerking tussen de snelheid, consistentie en atomiciteit van verschillende toegangsstijlen te veranderen. Het komt ook vaak voor dat er patronen ontstaan in de structuur van gegevens, en het besef groeit dat, hoewel de DBMS geen bepaald gegevensschema vraagt, veel van de gegevens die worden opgeslagen, een bepaald significant schema gemeenschappelijk hebben. 1.2.2 Gebruik van schemadefinities

Een gegevensmodel van een bepaalde soort is vitaal: definities, elementen, transformaties en relaties moet nog steeds begrepen en gedocumenteerd worden. Er is geen manier waarop een organisatie een 360° beeld kan krijgen van hun volledige business op alle gegevens-, systeem-, toepassings-, beslissingsprocestransactie- en klantenniveaus zonder een soort modellen of kaarten om ze uit te leggen.

Een databasemodel biedt de gelegenheid te spelen met databaseontwerpopties op papier, op een bord, of in een tekeninstrument, alvorens men zich zorgen moet maken over de syntaxis van gegevensdefinities, gegevens die reeds opgeslagen zijn of toepassingslogica. Het is een fantastische manier om na te denken over de implicaties van gegevensorganisatie en/of op voorhand belangrijke patronen te herkennen in de gegevens, alvorens een bepaald ontwerp te kiezen. Het is veel gemakkelijker een deel van het model opnieuw te tekenen dan een databaseschema opnieuw te creëren, significante hoeveelheden van gegevens te verplaatsen, en toepassingscode te veranderen.

Een schema is een drager voor het beschrijven van inhoud voor het bepalen van compliantie. Het wordt vaak gebruikt onder het mom van een deel van onderzoeksinhoud voor ingave in een programma door een validatieproces.

Het kan ook effectief worden gebruikt als een instrument voor het creëren van inhoud en het versnellen van het correctieproces. Dit geldt in het bijzonder voor inhoud die is aangemaakt door mensen of die is gegenereerd door interactieve systemen, waarbij dynamische processen deel zijn van de inhoudsdefinitie.

Soms wordt het gebruik van een schema of andere gegevensdefinitiecapaciteit gezien als het "vergrendelen" van een systeem, of het onflexibel maken ervan. Met de expressiviteit van JSON-Schema is het doel van het schema echter niet het beperken van de flexibiliteit, maar eerder het correct uitdrukken van enkel wat vereist is uit de gegevensinhoud, het creëren van nuttige mededelingen van correcties die vereist zijn, en het overlaten van de rest van de inhoud om door de programma's te interpreteren. 1.2.3 Voordelen van het gebruik van een schema

Validatie kan gebeuren met programmalogica. Een significant deel van veel programma's wordt namelijk gebruikt voor het valideren van ingaves die moeten worden verwerkt door het programma. Dit omvat de verwerking van opstartcommando's, het lezen van configuratiebestanden, het lezen van gegevensbestanden, het ontvangen van boodschappen en het aanvaarden van de invoer van gebruikers.

In elk geval is het doel van het validatieproces het bepalen of de ingevoerde inhoud correct en volledig is alvorens een verdere verwerking te starten. Het gebruik van een schema, en een overeenkomstige validatiefunctie om het schema op de inhoud ervan toe te passen, laat toe de validatiefunctie te verwerken door een met een doel gebouwde functie eerder dan op maat geschreven code. De schemadefinitie, die in het domein van de gegevensdefinitie ligt, is expressiever en gemakkelijker om te begrijpen dan programmalogica.

Met vereenvoudigde definitie en onderhoud is de kans groter dan te validatie zal zijn: • Vollediger aangezien de tijd om schema-inhoud te produceren korter kan zijn dan de tijd om programmalogica te schrijven om deze taak uit te voeren, • Gemakkelijker om te lezen. Het lezen van programmalogica voor validatie vereist vaak het lezen van een mix van stroomverwerking, controle van het type en controlelogica van de uitdrukkingen. Het lezen van een schema focust op de gegevensvoorstelling, zonder dat de andere verwerkingslogica daarbij betrokken is. • Correct gebruikt door anderen die inhoud produceren. Vaak is programmalogica een zwarte doos, of is de documentatie beperkt, waardoor het bepalen van alle geldige ingaves voor bepaalde elementen, of het feit of elementen verplicht of optioneel zijn, moeilijk is om na te gaan zonder dat uitstekende documentatie wordt gegeven. Het voorzien van een schema voor andere partijen maakt de taak van het creëren van correcte inhoud om te leveren aan het programma, veel gemakkelijker. Niet alle inhoud heeft evenveel baat bij het gebruik van een schema. Een programma dat slechts een of twee configuratieopties heeft, heeft geen significante hoeveelheid validatiecode, en een programma dat inhoud verwacht die vrij is van vorm, heeft mogelijk niet voldoende definitie om erg nuttig te zijn. Het selecteren van de programma's, en plaatsen in het programma, waar schemadefinities nuttig kunnen zijn, is een ontwerpkeuze. 1.2.4 JSON-schema

In de ruimte voor het uitwisselen van berichten wordt JSON vaak gebruikt om REST-webdiensten te implementeren. Het brede gebruik ervan weerspiegelt de flexibiliteit van JSON-geformatteerde inhoud om iteratieve definitie voor uitwisselingen van berichten tussen systemen, het tegelijkertijd bestaan van een gamma technologieën en het gemak om te begrijpen te ondersteunen.

Naast configuratiebestanden hebben veel programma's ook vereisten inzake gegevensbeheer. Terwijl sommige programma's vereisten hebben die geschikt zijn voor het gebruik van databases, hebben andere gematigdere vereisten en zijn ze beter geschikt voor de flexibiliteit van het gebruik van JSON-bestanden. Aangezien de inhoud uitbreidt (zowel in de structuur van het gegevensmodel als de hoeveelheid gegevens die opgeslagen worden) bestaat er, voor JSON-geschikte programma's, een groter risico op consistentiefouten van de gegevens. Zoals het geval is met veel configuratiebestanden kunnen updates van de gegevens ook gedaan worden zonder tekstbewerkingsinstrumenten en zijn ze vaak onderhevig aan fouten - vaak kleine. Het vinden van deze fouten vergt vaak meer werk dan het corrigeren ervan - een ontbrekende komma, verkeerd geplaatste sluitende } of ], of een typfout in een sleutelwoord. Gelukkig zijn er twee instrumenten om dit goed aan te pakken: • JSON syntax checkers, die fouten in de syntaxis vinden. • JSON Schema, en de verbonden validatie-instrumenten, die fouten in de houd vinden.

Hoewel JSON steeds meer bijval vindt in een breed gamma programmeertalen / runtime platforms, is het gebruik van JSON-geformatteerde bestanden voor de configuratie van bestanden en gelijkaardige gebruiken nu een beschikbare optie voor veel projecten. JSON en JSON-schema zijn sterke fundamentele technologieën, met veel mogelijkheden voor het bouwen van interessante en nuttige capaciteiten daarrond. 1.3 Doelstellingen

De onderhavige uitvinding laat aan analisten, oplossingontwerpers, architecten, ontwikkelaars en databasebeheerders toe visueel documentatie te ontwerpen, een model daarrond te vormen, te definiëren en aan te maken voor de schema's van op JSON-document gebaseerde NoSQL-databases en REST API's. De gerelateerde toepassing laat aan gebruikers toe te doen met JSON-documenten wat mogelijk is geweest respectievelijk voor relationele databases en voor XML-documenten.

De grafische interface laat de gebruiker een diagram van de modelverzamelingen en de relaties ervan visualiseren, evenals de inhoud van de verzamelingen. De uitgangen van het model zijn: JSON-documenten en JSON-Schema v4-compliante JSON (http://json-schema.org/documentation.html), scripts (MongoDB, Mongoose, enz.), en een gedetailleerde documentatie van het model in HTML (evenals Markdown-, PDF- en RTF-formaten) evenals RAML en Swagger.

De toepassing zal in een lokale of centrale opslagplaats de eigenschappen van een of meerdere documenten opslaan die zijn gedefinieerd door de gebruiker, evenals de relaties ervan, indien van toepassing. 2. Vereisten 2.1 Bedrijfsvereisten 2.1.1 Domein

Cf Fig 2. De toepassing laat aan een gebruiker toe een Model te creëren. Het model is gemaakt uit één Diagram voor één Database (voor MongoDB en andere NoSQL-systemen) of Toepassing (voor REST API's). Een Database is gemaakt uit één of meerdere Verzamelingen (of Documenten) en mogelijk uit logische Relaties daartussen. Een Verzameling bestaat uit Velden en Objecten. Het is mogelijk voor Relaties om te bestaan uit bepaalde Velden van verschillende Verzamelingen. De Database en elk van de Verzameling ervan, en elk van de Velden en Objecten van de Verzameling, evenals Relaties, hebben allemaal Eigenschappen. Verzamelingen en Relaties zijn voorgesteld in een Diagram. Diagram en eigenschappen leiden tot uitgangen in de vorm van Schema's, Voorbeelden, Scripts en Documentatiebestanden. 2.1.2 Gevallen van gebruik voor bedrijven • Opslaan/ophalen van modellen o Gebruiker maakt een nieuwe model vanaf het begin aan o Gebruiker haalt een eerder opgeslagen model op o Gebruiker slaat wijzigen op sinds het voor het laatst werd opgeslagen of annuleert deze o Gebruiker slaat een model op onder een nieuwe naam als een nieuw opgeslagen versie van het eerder opgeslagen model • Modeling o Gebruiker definieert een database en de eigenschappen ervan

Past de opmaak van entiteiten grafisch aan o Gebruiker maakt Verzamelingen, de inhoud ervan en gerelateerde eigenschappen aan

Grafisch

Zonder raster

Door de op tekst gebaseerde bewerking van JSON-schema o Gebruiker maakt Relaties en de eigenschappen ervan aan o Gebruiker kan verschillende uitgangen visualiseren en afdrukken:

Modelentiteitrelatie (ER)-diagram

Verzamelingsdocumenttypedefinitie (DTD)-diagram JSON-documentvoorbeeld JSON-schema HTML/Markdown/PDF/RTF-documentatie

MongoDB-script

Mongoose-schema

Scripts voor andere databaseverkopers • Hulpprogramma's o Waar-gebruikt capaciteit o JSON-validator o JSON-schemavalidator o Modelvergelijking o Reverse engineering van een databaseschema o Reverse engineering van JSON-documenten en JSON-schemabestanden o Opslagplaats o Beheer van licentiesleutels o Controleren op en installeren van updates voor de toepassing

Met betrekking tot het genoemde Modelentiteitrelatie (Er)-diagram merken we op dat het concept van ER strikt gezien in het algemeen gerelateerd is aan relationele databases, en niet JSON- of NoSQL-databases. Voor het gemak van de communicatie wordt het concept in dit document echter gebruikt, maar de woordenschat zal niet gebruikt worden in de toepassing.

Met betrekking tot het genoemde Verzamelingdocumenttypedefinitie (DTD)-diagram merken we op dat het concept van DTD strikt gezien gerelateerd is aan XML en niet JSON. Voor het gemak van de communicatie wordt het concept in dit document echter gebruikt, maar de woordenschat zal niet gebruikt worden in de toepassing. 2.2 Functionele vereisten 2.2.1 Gebruikersinterface 2.2.1.1 Toepassingssecties

Het toepassingsscherm wordt in verschillende delen verdeeld, cf. fig 3.

De verschillende delen worden hieronder beschreven. 2.2.1.1.1 Menubalk

Cf Fig 4. Deze menu's zijn geconfigureerd in JSON-documenten om gemakkelijke wijzigingen toe te laten in relevante eigenschappen zonder impact op de programmering. Opties staan in grijs als ze niet beschikbaar zijn voor de gebruiker in de context van de toepassing.

Elke menuoptie wordt hieronder meer in detail beschreven. 2.2.1.1.1.1 Bestandsmenu Cf. Fig 5 & 6.

2.2.1.1.2 Objectbrowser

Cf Fig 7. Dit vak wordt dynamisch gebouwd op basis van entiteiten die zijn aangemaakt in de vakken Centraal en Eigenschappen. Het geeft een gestructureerd overzicht van het model, en een snelle toegang tot elementen van het model. Dit vak omvat ook een zoekbalk evenals een beeld 'waar gebruikt' van de elementen.

Als de gegevens niet passen in het vak, verschijnt er een verticale en horizontale scrollbalk.

Wanneer elementen in het vak aangeklikt worden, tonen de vakken centraal en eigenschappen meer informatie.

Dankzij een toggle in het menu Beeld kan de gebruiker kiezen om het vak te verbergen (om meer ruimte te bieden voor het centrale vak), of het opnieuw te laten verschijnen. 2.2.1.1.3 Centraal vak

Het Centrale vak heeft verschillende doeleinden:

Grafisch zicht van het database-entiteitrelatiedigram, cf. fig. 8 Grafisch zicht van het veldhiërarchiediagram voor een verzameling, cf. fig. 9 Grafisch zicht van database- en verzamelingdefinities, cf. fig. 8 Rasterzicht van de velden van een verzameling, cf. fig. 10 JSON-voorbeeld van een voorbeelddocument voor een verzameling en overeenkomstig schema, cf. fig. 11

Voorbeeld van script voor het aanmaken van een database voor een verzameling, cf. fig. 12

Documentatie van database en verzameling, cf. fig. 13

Het vak heeft 2 reeksen van afhankelijke tabbladen: bovenste en onderste.

De bovenste reeks heeft één vast tabblad, het tabblad voor de modeldatabase, en één tabblad voor elke verzameling die is aangemaakt of geraadpleegd, cf. fig. 14. De verzameling kan worden gesloten, opnieuw geopend en verplaatst, terwijl het databasetabblad vast blijft. Als er te veel tabbladen geopend zijn om in de breedte van het vak te passen, afhankelijk van de gebruikte bibliotheek, zullen de tabbladen hun grootte behouden (volledige lengte van Verzamelingnaam) met pijlen naar links/rechts zodat de gebruiker kan scrollen (Firefox-stijl), of zullen de tabbladen kleiner worden met een tooltip (Chrome-stijl).

Er zijn 2 onderste reeksen van vaste tabbladen, één reeks van het onderste tabblad voor het bovenste databasetabblad, cf. 15, en één reeks onderste tabbladen voor de bovenste verzamelingstabbladen, cf. fig. 16.

De onderste tabbladen kunnen niet gesloten of verplaatst worden.

Het centrale vak heeft zowel een verticale als een horizontale scrollbalk als de gegevens of het diagram niet in het vak passen, in het bijzonder in responsieve modus.

Het centrale vak kan grafische gegevens (database en verzameling), een rooster, JSON (voorbeeld / schema), documentatie of databasescript tonen. Deze tabbladen zijn functioneel met elkaar gelinkt, en wijzigingen in één tabblad kan een invloed hebben op de andere, en vice versa. Ze moeten dynamisch bijgewerkt worden.

Het vak is permanent (kan niet verschijnen of verdwijnen zoals de Objectbrowser of het Eigenschappenvak.) De grootte ervan kan echter variëren volgens het verschijnen of verdwijnen van de Objectbrowser en/of het Eigenschappenvak. De gebruiker kan de breedteverdeling van de 3 vakken manueel wijzigen.

Het Centrale Vak ondersteunt contextuele menu's (rechtermuisklik), cf. fig. 17-19.

Deze contextuele menu's zijn geconfigureerd in JSON-documenten om gemakkelijke wijzigingen toe te laten in relevante eigenschappen zonder impact op de programmering. Opties staan in grijs als ze niet beschikbaar zijn voor de gebruiker in de context van de toepassing.

Pijltjestoetsen sturen het volgende gedrag:

In het ER-diagram wanneer een verzameling is geselecteerd: verplaatsen In het DTD-diagram: verplaatsen van het ene element naar het andere: o Linker en rechter pijltjestoetsen: oppervlakkigere of dieper in de boomstructuur verplaatsen o Pijltjestoetsen omhoog en omlaag: de elementen van het huidige niveau in de boomstructuur verplaatsen 2.2.1.1.4 Eigenschappenvak

Dit vak is waar de meeste gegevens ingevoerd worden. Het kan verschillende configuraties hebben afhankelijk van het element dat wordt bewerkt/getoond.

Er zijn 3 niveaus van eigenschapsvakken: database (inclusief relaties), verzameling en veld. Het geschikte eigenschapsvak wordt getoond afhankelijk van het element dat is geselecteerd in het Centrale Vak of de Objectbrowser. De eigenschapsvakken voor database en voor verzamelingen hebben vaste onderste tabbladen.

Eigenschappen op databaseniveau, cf. fig. 20 tot 22 Eigenschappen op verzamelingniveau, cf. fig. 23 tot 25 Eigenschappen op veldniveau, cf. fig. 26 tot 28

Eigenschappen worden gecontroleerd door een JSON-schema en laten gemakkelijke wijzigingen toe in relevante eigenschappen zonder impact op de programmering, en eigenschapsentry's worden opgeslagen in elke definitie van de Verzameling in een JSON-document.

Velden kunnen rechtstreeks worden bewerkt (geen knoppen voor bewerken/annuleren/opslaan).

Als de gegevens niet passen in het vak, verschijnt er een verticale en horizontale scrollbalk. 2.2.2 Kernfuncties 2.2.2.1 Aanmaken van een model

Een model wordt gemaakt van een diagram en relaties die een database van verzamelingen voorstellen die bestaan uit velden.

Wanneer een nieuw model vanaf het begin wordt gemaakt, gewoonlijk voor een database die aan de basis ligt van een toepassing of API, krijgt de gebruiker een leeg scherm te zien, cf. fig. 29.

Het bovenste tabblad zonder naam van het Centrale vak is actief, evenals het onderste Diagramtabblad.

Op dit punt begint de gebruiker door de eigenschappen van de database in te vullen, cf. fig. 30. Het aanmaken van de naam in het Eigenschapsveld werkt de naam in het vaste tabblad van het Centrale vlak, in de Objectbrowser, en in de Titelbalk an de toepassing (helemaal links bovenaan) automatisch bij. 2.2.2.2 Eigenschappen van een database 2.2.2.2.1 Details

De meeste informatie die heir wordt bewaard, is enkel voor documentatiedoeleinden, of metagegevens voor intern gebruik door de toepassing, cf. fig. 31. Sommige kunnen worden gebruikt bij het aanmaken van een script. 2.2.2.2.2 Relaties

Relaties zijn links tussen verschillende Verzamelingen van een Database. Ter herinnering, in tegenstelling tot een RDBMS, zijn relaties niet expliciet in een NoSQL-database zonder schema's, maar wel in de toepassingscode. Ze kunnen echter (en moeten) hier worden gedocumenteerd, en dienen als een basis voor ontwerp en discussies bij het oplossen van problemen, cf. fig. 32.

Tot 2 of meer Verzamelingen zijn aangemaakt gedocumenteerd in de database, wordt dit tabblad niet ingeschakeld. Er zijn 2 soorten relaties: vreemde sleutel en vreemde master.

Net zoals in een RDBMS verwijst een vreemde-sleutel relatie naar de unieke identificeerder van een document in een andere Verzameling in de database. In het bijzonder met de release van MongoDB v3.2 en de introductie van de $lookup-functionaliteit en de BI-Connector wordt de documentatie van vreemde sleutels veel relevanter.

Een vreemde-master relatie documenteert een denormalisatie, of de herhaling van de inhoud van een veld in een andere verzameling. De bron wordt beschouwd als de master (of bovenliggend niveau) en het onderliggende niveau is waar de gegevens gedupliceerd zijn. Bijzondere aandacht moet worden gegeven aan het verzekeren dat de onderliggende niveaus worden bijgewerkt wanneer de gegevens in de master veranderen.

Belangrijke opmerking: er kan meer dan één relatie zijn tussen 2 tabbladen. Er kunnen zelfs verschillende relaties zijn die verwijzen naar één veld in een bovenliggende tabel, afkomstig van verschillende velden in een onderliggende tabel. 2.2.2.2.3 Gebruikers

De enige informatie die nuttig is voor een database (naast de naam in het deel details) zijn gebruikerscertificaten.

Extra certificaten kunnen worden bewaard op Verzamelingsniveau, cf. fig. 33.

Merk op dat de beveiligingsrechten kunnen veranderen van versie tot versie, en daarom gekoppeld moeten worden aan een versienummer. 2.2.2.3 Aanmaken van een Verzameling

De volgende stap is het aanmaken van een Verzameling. Dit kan op 2 manieren gebeuren:

Door te klikken op de knop Verzameling toevoegen in de werkbalk,

Door met de rechtermuisknop eender waar in het Centrale vak te klikken om een contextueel menu te zien te krijgen, en de optie "Verzameling toevoegen" te kiezen, cf. fig. 34.

Er verschijnt nu een lege verzameling in het Centrale vak, cf. fig. 35. Er verschijnt een tabblad bovenaan het Centrale vka, maar het is niet geactiveerd. ER wordt een entry aangemaakt in de Objectbrowser-hiërarchie.

Opdat de gebruiker der nieuwe verzameling zou kunnen beginnen bewerken, worden er nu 3 mogelijkheden aangeboden: - dubbelklikken op het venster Verzameling in het centrale vakdiagram, - één keer klikken op de lijn Verzameling in de Objectbrowser, - of één keer klikken op het tabblad Verzameling bovenaan het centrale vak.

Het bovenste tabblad Verzameling is nu actief, terwijl het onderste tabblad Schema actief is, en het Centrale vak toont een enkel vast element: de root van het Verzamelingsschema, cf. fig. 36.

Naarmate de gebruiker de naam van de Verzameling in de eigenschappen ingeeft, wordt de naam bijgewerkt in het Centrale vak, en in de Objectbrowser. De gebruiker vul de extra eigenschappen in. 2.2.2.4 Eigenschappen van een verzameling 2.2.2.4.1 Details

De gebruiker kan hier bepaalde gegevens ingeven die nuttig zijn voor het script voor het aanmaken van een database, evenals bepaalde info die nuttig is voor de toepassing, cf. fig. 37. 2.2.2.4.2 Gebruikers

Beveiligingscertificaten op verzamelingsniveau, cf. fig. 38. Merk op dat de beveiligingsrechten kunnen veranderen van versie tot versie, en daarom gekoppeld moeten worden aan een versienummer. 2.2.2.4.3 Indices

De informatie is nuttig voor documentatiedoeleinden evenals voor het script voor het aanmaken van databases, cf. fig. 39. 2.2.2.4.4 Sharding (Moet nog worden bepaald) 2.2.2.5 Aanmaken van velden in grafisch zicht

Vervolgens is de gebruiker klaar om velden aan te maken voor de Verzameling, op verschillende manieren:

Klikken op de knop Onderliggende toevoegen in de werkbalk, waardoor het contextuele menu verschijnt,

Of met de rechtermuisknop klikken op de Schemaroot om een contextueel menu te tonen, dan op Onderliggende toevoegen klikken, dan op Veld, en vervolgens op het geschikte Veldtype klikken.

Door te klikken op het 'plus-teken' op het schemavak (ook voor complexe objecten zoals documenten en array's.)

De opties die beschikbaar zijn in het contextuele menu, cf. fig. 40, zijn afhankelijk van het type element dat is geselecteerd voorafgaand aan het oproepen van het contextuele menu. 2.2.2.5.1 Rootelement

Er is slechts één root mogelijk per document. Met het oog op een NoSQL-databaseschema kan het rootelement enkel van het volgende type zijn: document. Eigenschappen kunnen worden ingevuld voor het rootelement. Er kunnen een of meerdere onderliggende niveaus worden aangemaakt. De opties Invoegen, Bijvoegen en Referentie staan in grijs aangezien de functies niet mogelijk zijn voor een rootelement. 2.2.2.5.2 Non-rootelementen

Voor enige andere elementen dan het rootelement zijn er 4 opties mogelijk (Onderliggende toevoegen, Invoegen, Bijvoegen en Referentie), cf. fig. 41. De opties van het submenu zijn afhankelijk van de aard van het geselecteerde element. Laten we eerst de verschillend elementen definiëren die kunnen worden aangemaakt. 2.2.2.5.2.1 Veld

Dit is het meest gebruikelijke element in een schema. Het definieert een naam-waarde paar dat zal worden gevonden in de JSON-gegevens. De eigenschappen definiëren de details en beperkingen van zowel de naam als de waarde in het paar. Zoals gedefinieerd door de JSON-schemaspecificatie zijn de beschikbare types voor een veldwaarde: string, numeriek, booleaans, object (document), array en nul. Met het oog op MonoDB zijn er extra BSON-types beschikbaar: objectlD, binair, datum, tijdstempel, regex, JavaScript, JavaScript met scope, symbool, minKey en maxKey.

Het nominale geval is voor een element met slechts één type. De JSON-specificatie laat echter toe dat een veld meerdere types kan hebben. De toepassing UE kan meerdere types voor een veld definiëren en bewaren, cf. fig. 42 tot 45.

De naam van een standaardveld is een vaste string.

De aard van onderliggende niveaus is verschillend voor document, array of andere elementen. Documenten mogen een of meerdere Velden, Patroonvelden en/of Keuzes als onderliggende niveaus hebben. Arrays mogen een of meerdere Array-items en/of Keuzes als onderliggende niveaus hebben. Voor alle andere types van velden is het enige onderliggende niveau 'Keuze'.

Voor alle elementen verschijnt er bijgevolg een 'plus-teken' ('+') in de rechterhoek van het elementvak met label 'Schema' en is de optie 'Onderliggende toevoegen' in het contextuele menu ingeschakeld. Als het 'plus-teken' echter wordt aangeklikt en:

Het element een document, array of Keuze is, dan wordt het contextuele submenu geopend onder het niveau Onderliggende toevoegen;

Het element van enig ander type is, dan wordt er een Keuze-element aangemaakt.

Voor alle elementen verschijnen de opties in het submenu van 'Onderliggende toevoegen' als volgt:

Als het element een document is, dan zijn de opties Veld, Patroonveld en Keuzes ingeschakeld;

Als het element een array is, dan zijn de opties Array-item en Keuzes ingeschakeld;

Als het element een Keuze is, dan zijn de opties Keuzes en Subschema ingeschakeld;

Het element van enig ander type is, dan is enkel de optie Keuzes ingeschakeld.

Aangezien het mogelijk is dat een element meerdere types heeft, zijn de beschikbare opties de som van de opties van elk type van een element.

De functies Invoegen en Bijvoegen in het contextuele menu werken op een gelijkaardige manier, behalve dat terwijl er een element is geselecteerd, de gedragingen van Invoegen Bijvoegen gekoppeld zijn met het type van het bovenliggende element.

De eigenschappen van elk veldtype zijn geconfigureerd in een JSON-Schema bestand. 2.2.2.5.2.2 Patroonveld

Patroonvelden werken op exact dezelfde manier als standaard velden, met als enige uitzondering: de naam (in het naam-waard paar) is geen vaste string, maar een regex-patroon. Dit is in het bijzonder nuttig in MongoDB in combinatie met 'dot notatie'. 2.2.2.5.2.3 Keuze

In JSON-Schema zijn er 4 mogelijke keuzes: "allOf", "one of", "anyOf" en "not". Elk van deze elementen bevat een array, waarbij elk element van de array inhoud voorstelt die zal worden vergeleken. De keuze van "allOf", "one of", "anyOf" of "not" bepaalt hoe de validatieprocessor de resultaten van de matches zal behandelen: allOf vereist dat alle elementen in de arry met succes worden óvergestemd. oneOf vereist dat één, en slechts één, van de elementen in de array met succes wordt óvergestemd. anyOf vereist dat één of meerdere van de elementen in de array met succes worden óvergestemd. not vereist dat geen element in de array met succes wordt óvergestemd.

Schemadefinities kunnen "allOf", "oneOf", "anyOf" en "not" individueel of in combinatie gebruiken, hetgeen significante flexibiliteit biedt voor het definiëren van elementen die complexe definities of contextuele relaties hebben. Deze keuzes zijn van toepassing zowel op velden als op veldeigenschappen.

In beide gevallen is het enige mogelijk onderliggende niveau van Keuze een Subschema of een andere Keuze. Wanneer op het 'plus-teken' van een Keuze-element wordt gedrukt, wordt er een Subschema-element aangemaakt. Zo ook, in het contextuele submenu wanneer een Keuze-element wordt geselecteerd, zijn enkel de opties Subschema en Keuzes ingeschakeld. En wanneer het onderliggende niveau van Keuze is geselecteerd, dan zijn de opties Subschema en Keuzes de enige ingeschakelde opties in he submenu van Invoegen en Bijvoegen. 2.2.2.5.2.4 Array-item

Dit is het enige mogelijke onderliggende type van een Array-veld. Er zijn verschillende types van array-items mogelijk voor eenzelfde bovenliggend element. Elk kan 0 tot n voorvallen hebben, maar kunnen beperkt zijn door de eigenschappen minitems en maxltems van de Array. Het heeft een gedrag dat vrij gelijkaardig is met dat van een standaardveld, behalve dat de veldeigenschappen in vergelijking beperkt zijn. Dit wordt gecontroleerd in het Field Prop JSON-Schema in Bijlage. 2.2.2.5.2.5 Subschema

Als de keuze van toepassing is op een veld, dan is het subschema een document met alle schemamogelijkheden van een JSON-object.

De keuze kan ook van toepassing zijn op een individuele veldeigenschap, in welk geval het een vereenvoudigd schema is met de geschikte eigenschap van een veldtype. Een stringveld zou bijvoorbeeld een formaat van ipv4 of ipv6 kunnen hebben. 2.2.2.6 Eigenschappen van een veld 2.2.2.6.1 Details

De veldeigenschappen bevinden zich aan de rechterzijde in een speciaal vak. Afhankelijk van het veldtype dat in de vorige stap is geselecteerd, verschijnt het geschikte eigenschappenschema in het eigenschappenvak. De veldeigenschappen worden gecontroleerd door een Veldeigenschappen JSON-Schema gevonden in bijlage.

Verticale en horizontale scrollbalken verschijnen wanneer inhoud groter is dan de grootte van het weergegeven vak (variabel volgens de responsieve aard van de toepassing.) Er zijn verschillende types ingave mogelijk in het eigenschappenvak: - Tekstvak - Afvinkvakje - Keuzelijst: een lijst van waarden gecontroleerd hetzij door het Veldeigenschappen JSON-Schema (bijv. mogelijke stringformaten) of door ingaves in de DB of Verzameling (bijv. vreemde sleutels, referenties of veldafhankelijkheden.)

Daarnaast laat het eigenschappenveld toe andere ingaves toe te voegen met een 'plus-teken'-pictogram. Met opsommingen kan de gebruiker bijvoorbeeld één entry invullen, dan op het 'plus-teken' klikken waardoor er meer entry's toegelaten zijn daaronder.

Meerdere entry's zijn ook mogelijk met keuzelijsten, zoals afhankelijkheden.

Een beetje ingewikkelder is het geval van meerdere types. In een dergelijk geval zijn sommige velden gemeenschappelijk, en zijn andere specifiek. 2.2.2.6.2 Referenties JSON-Schema laat toe herbruikbare definities aan te maken, waardoor ze niet meer gekopieerd moeten worden op meerdere plaatsen. De definities kunnen gaan over een enkel veld of een ingewikkeldere structuur zoals een document. Een definitie kan bestaan op 3 niveaus:

Intern van een Verzameling (en daarom niet beschikbaar voor verwijzing ergens anders dan in de eigen verzameling ervan),

Databasemodelwerkruimte, in welk geval het beschikbaar is voor eender welke verzameling van de database,

Extern, d.w.z. op een publieke locatie op het internet,

Definities zijn niet mogelijk voor Keuzes en Array-items. Enkel voor Velden, Patroonvelden en Subschema's. De optie Referentie in het contextuele menu is daarom enkel ingeschakeld voor deze laatste 3 elementen.

De optie Referentie in het contextuele menu leidt tot de volgende acties, cf. fig. 46. 2.2.2.6.2.1 Omzetten naar interne definitie

Wanneer deze optie geselecteerd is, neemt het systeem de elementeigenschappen, kopieert het ze naar het deel Definities van hetzelfde Verzameling JSON-Schema en vervangt het de elementeigenschappen door een Referentie met de nieuw aangemaakte definitie. 2.2.2.6.2.2 Omzetten naar DB-definitie

Wanneer deze optie geselecteerd is, neemt het systeem de elementeigenschappen, kopieert het ze naar het deel Definities van het databasemodelwerkruimte JSON-Schema en vervangt het de elementeigenschappen door een Referentie met de nieuw aangemaakte definitie. 2.2.2.6.2.3 Omzetten naar externe definitie

Het systeem neemt de elementeigenschappen, kopieert ze naar het deel Definities van het JSON-Schema dat is opgeslagen in een centrale opslagplaats en vervangt de elementeigenschappen door een Referentie met de nieuw aangemaakte definitie. 2.2.2.6.2.4 Omzetten van definitie naar lokale eigenschappen

Zodra een element verwijst naar een definitie, is het mogelijk dat gebruiker de herbruikbare definitie wil omzetten naar een lokale instantie, gewoonlijk voor het divergeren van de herbruikbare definitie. Met deze actie wordt de Referentie verwijderd uit de elementeigenschappen, en vervangen door een volledige kopie van de eerder verwezen Definitie. De definitie blijft staan, aangezien het elders in de DB of verzameling kan worden gebruikt. 2.2.2.6.2.5 Naar definitie gaan

Wanneer een element verwijst naar een Definitie, zal de gebruiker, door de keuze van deze optie, de eigenschappen en details van de Definitie kunnen bekijken. 2.2.2.7 Definities

Externe definities kunnen niet worden bewaard in de toepassing. Definities verschijnen in de Objectbrowser in een afzonderlijk deel. 2.2.2.7.1 Op verzamelingniveau

Definities op verzamelingniveau worden bewaard in een grafisch beeld gelijkaardig aan dat van een volledig verzamelingschema, cf. fig. 47. 2.2.2.7.2 Op databaseniveau

Definities op databaseniveau worden bewaard in een grafisch beeld gelijkaardig aan dat van een volledig verzamelingschema, cf. fig. 48. 2.2.2.8 Veld waar-gebruikt en zoeken

In de Objectbrowser zal er een dynamische boomstructuur zijn van waar naar een veld wordt verwezen: verzameling en subobjecten, indien van toepassing, en definities. 2.2.2.9 Roosterzicht

Dit beeld biedt exact dezelfde functies als het grafische beeld, maar met een andere opmaak en visualisatie, cf. fig. 49. 2.2.2.10 JSON-voorbeeld

Een probleem met JSON-Schema is een JSON-document gemakkelijk te visualiseren dat voldoet aan het gedefinieerde schema. Daartoe biedt het vak Eigenschappen voor elk veld een ingavevak Voorbeeld zodat de gebruiker een voorbeeld kan registreren dat moet worden gebruikt in en JSON-document. Dit beeld toont, zij aan zij, het JSON-gegevensdocument, en het overeenkomstige JSON-Schema zoals gedefinieerd in de beelden Diagram of Rooster, cf. fig; 50.

Wijzigingen zijn toegelaten in het JSON-Schemavak, en validatie van deze wijzigingen gebeurt snel om onmiddellijk feedback te geven aan de gebruiker. Wijzigingen die zijn aangebracht in dit afdrukvoorbeeld zijn onmiddellijk zichtbaar in de beelden Diagram en Rooster, en vice versa. Dit moet gegarandeerd worden door de manier waarop entry's worden gepersisteerd. De JSON-gegevens kunnen ook worden bewerkt. 2.2.2.11 Documentatie

Het doel met dit tabblad is het genereren van een door de mens leesbare documentatie van het aangemaakte JSON-Schema, als een equivalente implementatie voor JSON voor iets dat vrij gebruikelijk is voor XSD, cf. fig; 51.

De documentatie kan worden geëxporteerd naar RTF-, PDF-, Markdown- en (X)HTML-formaten, evenals RAML en Swagger. Het is beschikbaar voor een individuele Verzameling, of voor de volledige DB. 2.2.2.12 Databasescript

Met MongoDB 3.2 werd een documentvalidator ingevoerd. Het systeem zal zorgen voor mapping tussen JSON-Schemasyntaxis en MongoDB-validatorsyntaxis, cf. fig. 52. Gelijkaardige functionaliteit is beschikbaar voor andere verkopers, wanneer van toepassing. 2.2.3 Aanvullende functies 2.2.3.1 Openen, opslaan, opslaan als, sluiten

Deze functies zullen beïnvloed worden door het type opslagplaats en de manier waarop persistentie wordt uitgevoerd. Anders dan dat moeten de kenmerken voldoen aan de functies die men normaal zou verwachten. 2.2.3.2 Reverse engineering

Dit geavanceerde kenmerk neemt als ingang hetzij: een eenvoudig JSON-document, en genereert het schema voor dat document het huidige model; een JSON-Schema, en vult de eigenschappen in het huidige model; of maakt een verbinding met een NoSQL-database en neemt representatieve documenten uit de verzamelingen die aanwezig zijn in de database. Het genereert de schema's voor de verschillende verzamelingen in een werkruimte.

De gebruiker kan het model dan bewerken het opslaan onafhankelijk van de bron, cf. fig. 6. 2.2.3.3 Exporteren

Dit geavanceerde kenmerk laat aan de gebruiker toe delen van het model of het volledige model te exporteren, in verscheidene formaten, cf. fig. 53. 2.2.3.4 Afdrukken

Afdrukken is mogelijk voor diagrammen, evenals voor documentatie, JSON-documenten en schema's. De controles die voorzien zijn voor de gebruikers moeten als volgt zijn: afdrukinstelling (de printer en de eigenschappen ervan, eals de papiergrootte, kunnen dus geselecteerd worden), afdrukvoorbeeld (de gebruiker kan dus zien hoe het eruit zal zien voordat het effectief wordt afgedrukt), afdrukselectie, zoomniveau en of objecten kunnen worden afgedrukt over gesplitste pagina's, cf. fig. 54 & 55. 2.2.3.5 Modellen vergelijken

Het doel van dit geavanceerde kenmerk is het bieden van een zij-aan-zij zicht van 2 modellen (vermoedelijk 2 verschillende versies van hetzelfde model), waarbij verschillende daartussen worden aangegeven. 2.2.3.6 Opties

Parameters die door de gebruiker moeten worden bewaard, verschijnen gewoonlijk in de loop van het ontwerp en de ontwikkeling van een toepassing, en ze nemen toe met de toepassing, cf. fig. 56.

Voor de schemaweergavecontroles van het DTD-diagram zouden verschillende controles kunnen worden opgenomen in een JSON-Schemaweergaveconfiguratie, cf. fig. 57. 3. Toepassing op relationele databases en denormalisatievoorstelvereisten

In dit deel wordt het concept "denormalisatie" dat eerder vernoemd werd in deel 2.2.2.2.2 verder uitgelegd. In dit document verwijst de term "denormalisatie" naar enige conversie van een brondatabasemodel naar een doeldatabasemodel waarbij nesting plaatsvindt.

Dit deel beschrijft in het bijzonder een uitvoeringsvorm van de onderhavige uitvinding waarbij een relationeel brondatabasemodel wordt omgezet in een doeldatabasemodel volgens de onderhavige uitvinding. Hierbij worden de vreemde sleutels die aanwezig zijn in het relationele brondatabasemodel gebruikt voor nesting. Het doeldatabasemodel wordt in het bijzonder verkregen door nesting van verbonden vreemde tabellen.

Het concept van denormalisatie illustreert het brede bereik van de toepasbaarheid van de onderhavige uitvinding. Terwijl de toepasbaarheid hierboven hoofdzakelijk werd geïllustreerd in het geval van NoSQL-databases en REST API's, zijn relationele databases en RDMS en alle gerelateerde aspecten gelijk in het bereik van de onderhavige uitvinding. In een voorkeur dragende uitvoeringsvorm gebeurt dit door "reverse engineering", gelijkaardig aan de functionaliteit die hierboven is uitgelegd.

In een alternatieve uitvoeringsvorm gebeurt dit door "forward engineering". In nog een alternatieve uitvoeringsvorm gebeurt dit door rechtstreeks te werken op een relationele database en RDMS.

Hoewel denormalisatie in dit document voorgesteld wordt als een uitvoeringsvorm van de onderhavige uitvinding ,kan het ook beschouwd worden als een stand-alone concept en gerelateerde uitvinding. De grafische gebruikersinterface die in dit deel wordt gebruikt, geeft in het bijzonder slechts één uitvoeringsvorm van he concept van denormalisatie weer. In een alternatieve uitvoeringsvorm laat denormalisatie zoals beschreven in dit document het genereren toe van een doeldatabasemodel vanuit een brondatabasemodel zonder een grafische gebruikersinterface te vereisen in enige stap van de generatiewerkwijze. 3.1 Inleiding

Aangenomen dat de functie 'Reverse engineering van DDL-bestand' beschikbaar is, is een vak gevraagde aanvullende functie een gedenormaliseerd model voor te stellen op basis van het oorspronkelijke relationele model.

Dit document beschrijft het proces van het nemen van een brondatabasemodel (aangemaakt vanaf het begin of door reverse engineering van een DDL-bestand of RDBMS) dat is opgeslagen met een werkwijze volgens de onderhavige uitvinding, en het genereren van een nieuw model terwijl verbonden vreemde tabellen worden genest. Na dat proces kan de gebruiker het gedenormaliseerde model verder bewerken en verfijnen. 3.2 Concepten

Te beginnen met 2 'flat tables' in het bronmodel, zie fig. 58, met een vreemde-sleutel relatie geïllustreerd op fig. 59, zijn er ten minste twee manier en zelfs 3 manieren waarop denormalisatie kan worden gezien, gegeven in respectievelijk deel 3.2.1-3. 3.2.1 Subdocument van onderliggende tabel bevattende vreemde bovenliggende tabelstructuur

Naarmate een 'flat table' in een genormaliseerd bronmodel wordt gekopieerd naar een verzameling in een gedenormaliseerd doelmodel, als een vreemde-sleutel relatie wordt tegengekomen, wordt de structuur van de bovenliggende tabel opgenomen als een genest subdocument van de verzameling.

Het verwachte resultaat van de nieuwe functie wordt geïllustreerd door fig. 60.

De bovenliggende tabelstructuur is hier ingebed als een subdocumentstructuur in de onderliggende tabel. Vreemde sleutels en vreemde-master relaties worden automatisch aangemaakt in het inbeddingsproces. 3.2.2 Array in bovenliggende tabel bevattende onderliggende tabelstructuur

Een andere manier om denormalisatie uit te voeren is het aanmaken, in de bovenliggende tabel, van een array met de structuur van de onderliggende tabel, met het verwachte resultaat dat is geïllustreerd door fig. 61.

Opmerkingen: 1) Het onderliggende veld met de oorspronkelijke relatie wordt niet herhaald in de bovenliggende tabelarray, om geen kruisverwijzingen te creëren. 2) De bovenliggende-onderliggende relatie wordt omgekeerd. Nu zijn de bovenliggende van de velden in de nieuw aangemaakte array de velden in de vroegere onderliggende tabel. 3) Bijgevolg is de l...n cardinaliteit in de bovenliggende, zie fig. 62. Merk op hoe de veldnaam baat zou hebben bij dot.notatie om nesting voor te stellen. 3.2.3 Combinatie

Als de 2 logica's gecombineerd worden, wordt het volgende resultaat gegenereerd, geïllustreerd door fig. 63. Afhankelijk van hoe gegevens worden gelezen, zijn alle 3 de bovenstaande manieren voor denormalisatie mogelijk. 3.2.4 Cascading

Wanneer een bovenliggende tabel zelf de onderliggende tabel van een andere is, wordt het resultaat geïllustreerd op fig. 64 verkregen. Het kan wenselijk zijn de relaties trapsgewijs voor te stellen in meerdere niveaus van nesting, waardoor het resultaat verkregen op fig. 65 wordt bereikt. (Het zal goed zijn relaties te kunnen herschikken om ellebooglijnen te reduceren...)

En natuurlijk is de spiegelende trapsgewijze array mogelijk, met het resultaat geïllustreerd op fig. 66.

Aangezien dit nog lang zou kunnen verdergaan in complexe modellen, is het waarschijnlijk een goed idee het aantal cascades te beperken, en de gebruiker te laten beslissen over het aantal cascades tussen 0 en een maximum van bijvoorbeeld 3. Het is natuurlijk gemakkelijker een externe cascade te wissen dan manueel één aan te maken. 3.2.5 Recursie

Wanneer er een relatie bestaat tussen velden van dezelfde tabel, kan men opnieuw een onderliggende array inbedden in de bovenliggende, of een bovenliggend subdocument inbedden in het onderliggende. Hier wordt het echter niet voorgesteld dit te doen.

Tot slot is er geen indicatie van hoeveel keer cascade noodzakelijk zou zijn, zonder te kijken naar de werkelijke gegevens.

De relationele tabel die is getoond op fig. 67 kan in een model gegoten worden op enige van de 2 manieren geïllustreerd op fig. 68. 3.2.6 Meerdere paden

In het geval getoond op fig. 69 kan de volgorde waarin tabellen gedenormaliseerd en omgezet worden, belangrijk zijn, aangezien het nemen van het pad luchthavens > gebieden > landen rijkere, maar meer hiërarchische informatie zal bieden. 3.2.7 Kruisverwijzingen

Kruisverwijzingen moeten worden gedetecteerd en vermeden. 3.3. Proces 3.3.1 Menutoegang

Menutoegang wordt geïllustreerd op fig. 70. 3.3.2 Huidig model opslaan

De weergave getoond op fig. 71 wordt getoond als er wijzingen zijn aangebracht, het denormalisatievoorstel kan dus opgeslagen worden in een leeg model. 3.3.3 Selectie en parameters

De gebruiker kan alle tabellen of specifieke tabellen selecteren die moeten worden gedenormaliseerd, evenals bepaalde parameters instellen die moeten worden gebruikt tijdens het denormalisatieproces van het model. Dit wordt geïllustreerd door fig. 72. 3.3.4 Uitvoering

Het proces zal ten minste de volgende stappen omvatten: - Tabellen van bron- (genormaliseerd) naar doelverzameling (gedenormaliseerd) kopiëren - Eerste relatie in bron selecteren o Inbedden in bestemmingsmodel volgens gekozen parameters

Indien array in bovenliggend verzameling: • Array-items bijvoegen met type=document • Onderliggende structuur in documentarray-item kopiëren, behalve relatieveld

Indien subdocument in onderliggende verzameling: • Relatieveld vervangen door • Verzameling gemaakt uit gekopieerde bovenliggende structuur o Vreemde-sleutel en vreemde-master relaties creëren o Itereren volgens Cascade- en Recursieparameters o Naar volgende relatie en lus gaan VOORBEELD 2

Voorbeeld 2 wordt geïllustreerd door figuren 73 tot 77. Figuur 73 toont een voorbeeldprobleem met een resultaat volgens de onderhavige uitvinding. Hierbij tonen figuren 74 tot 77 vergrote delen van figuur 73. Figuur 74 toont eerst het "JSON-document tot model". Verder toont figuur 75 de "Modeling met traditionele Er-software", terwijl figuur 76 en 77 samen de "Modeling volgens de onderhavige uitvinding" van het voorbeeldprobleem tonen. Het probleem dat wordt onderzocht in dit voorbeeld is hoe het deel van de JSON-documentcode hier moet worden gebouwd en/of bewerkt die is gegeven op figuur 74, daarbij ondersteund door een GUI. Zoals het duidelijk zal zijn voor de vakman, definieert het genoemde deel van de code een eenvoudig JSON-document met betrekking tot een individu, omvattende zowel informatie van het bovenste niveau met betrekking tot, d.w.z. de velden met veldnamen "_id", "gebruikersnaam", "contact", "toegang" en "status", als geneste informatie, d.w.z. twee geneste objecten, respectievelijk met betrekking tot de veldnamen "contact", en "toegang". Een resultaat volgens de stand der techniek is gegeven op figuur 75, met een Entiteitrelatiediagram (ERD) omvattende drie verzamelingen. Dit staat tegenover het ERD dat is verkregen met een uitvoeringsvorm volgens de onderhavige uitvinding en getoond op figuur 76, aangevuld met een boomstructuur getoond op figuur 77.

In het algemeen laat de onderhavige uitvinding toe de oorspronkelijke JSON-documentstructuur weer te geven door structuur (minder verzamelingen, enkel "echte" relaties) (in het bijzonder in de ERD), sequentiebehoud (zowel in de ERD en de boomstructuur), interactie (zoals in de ERD als de boomstructuur), en indentatie (hetgeen nesting weergeeft) (in het bijzonder in de ERD), terwijl werkwijzen volgens de stand der techniek dit niet doen. Het resultaat van de onderhavige werkwijze is bijgevolg niet enkel meer trouw aan de overeenkomstige JSON-documentdefinitie, maar is ook compacter in termen van ERD, waardoor een duidelijker en algemeen beter overzicht mogelijk is. Daarnaast is de interactieve bewerking van het databaseschemamodel ook flexibeler, met rijkere interactie dankzij de keuze tussen de ERD en de boomstructuur. Dit wordt hieronder meer in detail besproken.

Merk eerst op hoe het databaseschemamodel dat is gebouwd met een werkwijze volgens de stand der techniek een eerste verzameling voor de genoemde informatie op het bovenste niveau evenals een tweede en derde verzameling voor elk van de genoemde twee objecten omvat. Dit is een eerste probleem met een werkwijze volgens de stand der techniek, aangezien de scheiding van informatie over drie afzonderlijke objecten de eenheid van de onderliggende informatie doet vervagen. Het heeft namelijk geen zin de genoemde twee objecten uit hun oorspronkelijke context te halen. Dit kan een gebruiker van de werkwijze misleiden waardoor hij denkt dat de informatie met betrekking tot "contact" en "toegang" iets "minder dicht gerelateerd" is met het genoemde individu, in tegenstelling tot, bijv. "gebruikersnaam", dat "meer gerelateerd" lijkt met het genoemde individu. Dit verschil is een volledig verkeerde conceptie, aangezien " contact", "toegang", enz. "gebruikersnaam" eigenlijk behoren tot hetzelfde bovenste niveau in het oorspronkelijke JSON-document. Deze verkeerde conceptie kan leiden tot ernstige fouten in de constructie en bewerking van databases. In tegenstelling daarmee behoudt de onderhavige uitvinding de oorspronkelijke context, met "contact", "toegang" en "gebruikersnaam" allemaal op hetzelfde niveau, zowel in de ERD geïllustreerd op fig. 76 als de boomstructuur geïllustreerd op fig. 77.

Een tweede gerelateerd punt heeft betrekking op het behoud van hiërarchie en de gerelateerde interactie die ingeschakeld is door een resultaat volgens de onderhavige uitvinding. Terwijl de velden die behoren tot de twee objecten "contact" en "toegang" onvermijdelijk zichtbaar zijn op fig. 75 (resultaat volgens de stand der techniek) is meer flexibiliteit toegelaten op fig. 76 (volgens de onderhavige uitvinding), met inklapbare items, aangegeven door een pictogram gerelateerd aan inklappen, d.w.z. Een vierkant met een "-" teken in wanneer de objectinhoud zichtbaar is (zoals getoond), en en vierkant met een "+"-teken in wanneer het object ingeklapt is (niet getoond). Dit heeft als voordeel dat het een erg compact weergave toelaat, waarbij alle objecten van het bovenste niveau worden getoond, maar niet de tails, wat de bruikbaarheid bevordert. Bovendien creëert het een extra manier voor de gebruiker om te interageren met het databaseschemamodel, waardoor hij/zij vertrouwd kan worden met een databaseschemamodel en/of het aan anderen kan uitleggen door op het pictogram gerelateerd met inklappen te klikken/dit aan te raken. Zelfs in niet-interactieve weergaves (zoals afgedrukte documentatie) wordt het inzicht van de eindgebruiker bovendien bevorderd aangezien de ERD van fig. 76 wordt aangevuld door de boomstructuur op fig. 77. Dit laat een complementaire benadering toe, bijv. door een ingeklapt beeld te tonen voor de ERD (d.w.z. zonder de inhoud van objecten te tonen), aangevuld met de boomstructuur die namelijk alle details toont.

Een ander voordeel van de onderhavige uitvinding is het behoud van sequentie. Zowel de ERD als de boomstructuur tonen de oorspronkelijke sequentie onder veldnamen op elk niveau, zoals gedefinieerd in het JSON-document. Voor het resultaat volgens de stand der techniek wordt deze sequentie niet behouden: zoals duidelijk zal zijn op fig. 75 kan niet langer bepaald worden of bijv. "contact" in eerste, tweede, derde, vierde of vijfde positie was in de lijst op het bovenste niveau. Deze vervaging van sequentie leidt tot onvolledige interactie met het databaseschemamodel, een ander probleem dat wordt opgelost door de onderhavige uitvinding.

Een ander voordeel van de onderhavige uitvinding is het doelgerichte gebruik van indentatie in de ERD. Zoals te zien is op fig. 76 worden velden die behoren tot een object, ingesprongen ten opzichte van de objectnaam, die ten minste voor twee doeleinden dient. Enerzijds dient het voor het gemakkelijk insluiten van de inhoud van het object op een zichtbare manier. Anderzijds bootst het de typische opmaak van JSON-documentcode na zoals geïllustreerd op fig. 74. Een gebruiker met eerdere ervaring met JSON zal daarom minder problemen hebben om de ERD volgens de onderhavige uitvinding te begrijpen, en is bijgevolg minder geneigd fouten te maken in zijn/haar interactie met het databaseschemamodel.

Merk bovendien de aanwezigheid van twee "relaties" op in het databaseschemamodel dat is maakt met een werkwijze volgens de stand der techniek, die beide relaties lijken in de zin van RDBMSes, maar in feite betrekking hebben op "nestingrelaties", die de eenheid van de onderliggende informatie verder vervagen. Door te blijven bij een "fat-table-only" voorstelling krijgt de gebruiker die databaseschemamodellen maakt met de werkwijze volgens de stand der techniek namelijk te maken met een reusachtig entiteitrelatiediagram, waarin geen overzicht geboden wordt. Dit geldt in het bijzonder als het betrekking heeft op een databaseschemamodel omvattende "echte" relaties zoals vreemde-sleutel relaties, zoals de vreemde-sleutel relatei die twee verzamelingen verbindt op figuur 58. In een werkwijze volgens de stand der techniek zou de denormalisatie van een relationeel databaseschemamodel zoals beschreven in dit document leiden tot een dramatisch ingewikkelde ERD, met een verwarrende mix van nestingrelaties en "echte" relaties. In tegenstelling daarmee creëert de werkwijze volgens de onderhavige uitvinding enkel relaties wanneer dit noodzakelijk is, d.w.z. geen in het geval van het onderhavige voorbeeld, en slechts een beperkt aantal in het geval van fig. 58, geïllustreerd bijv. op fig. 60 en 61. De gebruiker die interageert met een databaseschemamodel volgens de onderhavige uitvinding behoudt bijgevolg een beter overzicht over de relevante relaties, waardoor er bijgevolg gemiddeld minder fouten worden gemaakt. VOORBEELD 3

Fig. 78 en 79 tonen een voorbeeld met betrekking tot verwijzing en denormalisatie. Fig. 78 toont in het bijzonder een voorbeeldinterface die de interface op fig. 72 aanvult die is geïntroduceerd in deel 3.3.3 van voorbeeld 1, waardoor de gebruiker alle verzamelingen (tabellen) of specifieke verzamelingen (tabellen) kan selecteren die moeten worden gedenormaliseerd, nu met de extra optie verwijzing in twee richtingen te kiezen. Het verschil tussen verwijzing en inbedding is als volgt. Met inbedding, wanneer een array wordt gedenormaliseerd in een bovenliggend niveau (en ook voor die zijde wanneer "beide" is geselecteerd), wordt een array aangemaakt die bestaat uit een subdocument met alle velden van het onderliggende niveau. Verwijzing daarentegen komt tegemoet aan de behoefte om enkel de sleutels naar het bovenliggende niveau te brengen, en niet alle geassocieerde velden. Dit betekent dat er aan de bovenliggende zijde slechts een eenvoudige array van vreemde sleutels zou zijn die verwijzen naar de primaire sleutel ven de onderliggende. In de overeenkomstige ERD volgens de onderhavige uitvinding wordt er slechts een array van eenvoudige velden getoond. Dit wordt geïllustreerd door fig. 79. VOORBEELD 4

Fig. 80 en 81 tonen respectievelijk een voorbeeld van ERD met geassocieerde boomstructuur volgens een uitvoeringsvorm van de onderhavige uitvinding. Samen illustreren deze figuren de capaciteit van de onderhavige uitvinding om om te gaan met een belangrijk en nuttig kenmerk van JSON zoals van toepassing op NoSQL en Big Data, namelijk polymorfisme. Polymorfisme heeft betrekking op het vermogen om om te gaan met zich ontwikkelende en flexibele schema's, zowel op het niveau van de algemene documentstructuur als op het niveau van het type van een enkel veld. Dit is bekend als 'schemacombinatie', en kan worden voorgesteld in JSON-Schema met het gebruik van subschema's en sleutelwoordne; anyOf, allOf, oneOf, not. Fig. 80 en 81 illustreren een ERD en geassocieerde boomstructuur omvattende een veld dat evolueert van slechts een stringtype, naar een subdocument, of met het gelijktijdig bestaand van beide veldtypes. Werkwijzen volgens de stand der techniek hebben het moeilijk grafisch om te gaan met dergelijke subschema's, terwijl de voorstelling op fig. 80 en 81 duidelijk en vanzelfsprekend is.

Claims (15)

1. CONCLUSIES

   1. Werkwijze voor het bouwen van een databaseschemamodel door een gebruiker door middel van een computer, omvattende de volgende stappen: (a) het voorzien van een reeks verzamelingen en optioneel een of meerdere relaties die ten minste twee van de genoemde reeks verzamelingen verbindt; (b) het bewerken van een of meerdere van de genoemde reeks verzamelingen, die elk zijn geassocieerd met een schemadefinitie weergegeven door een enkele tabel op een entiteitrelatiediagram op een grafische interface op de genoemde computer en omvattende ten minste één object en/of één veld, waarbij de genoemde schemadefinitie kan worden bewerkt via een boomstructuur op de genoemde grafische gebruikersinterface op de genoemde computer; (c) het automatisch genereren door middel van de genoemde computer van het genoemde databaseschemamodel voor een databasesysteem of een REST API; met het kenmerk dat de genoemde reeks verzamelingen ten minste één verzameling omvat omvattende een genest object dat kan worden bewerkt via de genoemde boomstructuur met twee niveaus of meer.
2. 2. Werkwijze volgens de voorgaande conclusie 1, met het kenmerk dat de genoemde reeks verzamelingen ten minste twee verzamelingen omvat; dat stap (b) het genereren en/of bewerken van een of meerdere relaties omvat die ten minste twee verzamelingen verbinden die behoren tot de genoemde reeks verzamelingen via het genoemde entiteitrelatiediagram op de genoemde gebruikersinterface op de genoemde computer; en dat ten minste één van de genoemde een of meerdere relaties een eerste veld dat behoort tot een reeks verzameling die behoort tot de genoemde reeks verzamelingen verbindt met een tweede veld dat behoort tot een tweede verzameling die behoort tot de genoemde reeks verzamelingen.
3. 3. Werkwijze volgens een der conclusies 1 tot en met 2, met het kenmerk dat de genoemde schemadefinitie een "JavaScript Object Notation" (JSON)-schemadefinitie is.
4. 4. Werkwijze volgens een der conclusies 1 tot en met 3, met het kenmerk dat de genoemde een of meerdere objecten een array en/of een subdocument omvatten.
5. 5. Werkwijze volgens een der conclusies 1 tot 4, met het kenmerk dat, het genoemde databaseschemamodel is geformatteerd volgens enige of enige combinatie van de volgende formaten: JSON-Schema, YAML, Mongoose, RAML, Swagger, Apache AVRO, Parquet.
6. 6. Werkwijze volgens een der conclusies 2 tot 5, met het kenmerk dat, de genoemde ten minst één van de genoemde een of meerdere relaties een vreemde-sleutel relatie is; en/of dat de genoemde eerste verzameling en de genoemde tweede verzameling verbonden zijn door meer dan één relatie die is gegenereerd en/of bewerkt in stap (b); en/of dat het genoemde eerste veld dat behoort tot de genoemde eerste verzameling verbonden is met zowel het genoemde tweede veld en een derde veld dat behoort tot de genoemde tweede verzameling door respectievelijk een eerste en tweede relatie.
7. 7. Werkwijze volgens een der conclusies 2 tot 6, met het kenmerk dat de genoemde automatische generatie in stap (c) automatisch een voor de mens leesbare handleiding genereert voor het genoemde databaseschemamodel welke ten minste gedeeltelijk gebaseerd op een logische link die is gedefinieerd door de genoemde een of meerdere relaties.
8. 8. Werkwijze volgens een der conclusies 1 tot 7, met het kenmerk dat het genoemd voorzien in stap (a) het genereren omvat van een of meerdere van de genoemde reeks verzamelingen op de genoemde grafische gebruikersinterface op de genoemde computer.
9. 9. Werkwijze volgens een der conclusies 1 tot 8, met het kenmerk dat het genoemd voorzien in stap (a) het denormaliseren omvat van een relationeel databaseschemamodel dat is voorzien door de gebruiker, waarbij het genoemd denormaliseren het extraheren omvat van de genoemde reeks verzamelingen uit een reeks tabellen die behoren tot het genoemde relationele databaseschemamodel, evenals enige vreemde-sleutel relaties die behoren tot het genoemde relationele databaseschemamodel, voor opname in het genoemde databaseschemamodel.
10. 10. Werkwijze volgens de voorgaande conclusie 9, met het kenmerk dat het genoemd denormaliseren in stap (a) verder het verwerken omvat van een vreemde-sleutel relatie tussen een bovenliggende verzameling omvattende een primaire sleutel en een onderliggende verzameling omvattende een vreemde sleutel, waarbij de genoemde verwerking enige of enige combinatie van de volgende omvat: het opnemen van een genest subdocument in de genoemde onderliggende verzameling, waarbij het genoemde geneste subdocument een of meerdere relaties omvat in de genoemde bovenliggende verzameling; het opnemen van een geneste array in de genoemde bovenliggende verzameling, waarbij de genoemde geneste array een of meerdere relaties omvat in de genoemde onderliggende verzameling.
11. 11. Werkwijze volgens de voorgaande conclusie 10, met het kenmerk dat de genoemde verwerking van een vreemde-sleutel relatie het selecteren omvat van een of meerdere denormalisatievoorkeuren op de genoemde grafische gebruikersinterface op de genoemde computer, waarbij de genoemde denormalisatievoorkeuren enige of enige combinatie van de volgende omvatten: een tabelselectie; een inbeddingsvoorkeur met betrekking tot het genoemd opnemen van het genoemd geneste subdocument in de genoemde onderliggende verzameling en/of de genoemde geneste array in de genoemde bovenliggende verzameling; een maximum aantal gestapelde niveaus, een maximum aantal recursieniveaus.
12. 12. Door de computer geïmplementeerde werkwijze voor het bouwen van een databaseschemamodel bij ingave van een gebruiker volgens een werkwijze volgens een der voorgaande conclusies 1 tot 11, omvattende de volgende stappen: (i) het ontvangen van een reeks verzamelingen en optioneel een of meerdere relaties die ten minste twee van de genoemde reeks verzamelingen linken, optioneel bij ingave van de genoemde gebruiker via een grafische gebruikersinterface; (ii) het ontvangen van bewerkingsinstructies voor elk van de genoemde reeks verzamelingen met betrekking tot een schemadefinitie bij ingave van de genoemde gebruiker via een boomstructuur op de genoemde grafische interface; (iii) het genereren op verzoek van de genoemde gebruiker van het genoemde databaseschemamodel voor een databasesysteem of een REST API; met het kenmerk dat de genoemde reeks verzamelingen ten minste één verzameling omvat omvattende een genest object dat kan worden bewerkt via de genoemde boomstructuur met twee niveaus of meer.
13. 13. Door de computer geïmplementeerde werkwijze volgens de voorgaande conclusie 12, met het kenmerk dat de genoemde reeks verzamelingen ten minste twee verzamelingen; dat stap (ii) het ontvangen omvat van instructies voor het genereren en/of bewerken van een of meerdere relaties die ten minste twee verzamelingen verbinden die behoren tot de genoemde reeks verzamelingen bij ingave van de genoemde gebruiker via het genoemde entiteitrelatiediagram op de genoemde gebruikersinterface; en dat ten minste één van de genoemde een of meerdere relaties een eerste veld dat behoort tot een reeks verzameling die behoort tot de genoemde reeks verzameling verbindt met een tweede veld dat behoort tot een tweede verzameling die behoort tot de genoemde reeks verzamelingen.
14. 14. Gebruik van een databaseschemamodel gebouwd met een werkwijze volgens een der voorgaande conclusies 1 tot 11 in een databasesysteem of een REST API, waarbij het genoemde databasesysteem bij voorkeur betrekking heeft op enige of enige combinatie van het volgende: MongoDB, Couchbase, CouchDB, Amazon DynamoDB, RavenDB, Microsoft Azure DocumentDB, MarkLogic, EnterpriseDB, Oracle SQL, MySQL, PostgreSQL, Microsoft SQL, Oracle for NoSQL, ElasticSearch, Snowflake, FinchDB, MariaDB, IBM Cloudant, Google Cloud Datastore, Cassandra, BerkeleyDB, RethinkDB, Mapr.
15. 15. Computersysteem voor het bouwen van een databaseschemamodel bij ingave van een gebruiker, waarbij het genoemde computersysteem een processor, een niet-vluchtig geheugen, programmacode op het genoemde geheugen voor uitvoering op de genoemde processor, een grafische interface omvat, waarbij de genoemde computer is geconfigureerd voor het uitvoeren van een werkwijze volgens een der voorgaande conclusies 12 en 13.