FOR DATABASE SYSTEM S AN D REST API 'S

TECH N I CAL Fl ELD The invention pertains to the technical field of database systems, in particular to the construction of database schema models for database systems and REST APIs.

BACKGROU N D

While many present day data storage and data management systems still rely exclusively on relational database systems and the related special-purpose programming language SQL (Structured Query Language), many application developers are moving to database systems that are "Not Only SQL", i.e. NoSQL (originally: "Non SQL") database systems such as MongoDB, Couchbase, CouchDB, Amazon DynamoDB, RavenDB, Microsoft Azure DocumentDB, MarkLogic, and EnterpriseDB. Indeed, NoSQL databases offer important advantages for application developers: flexibility, fast and easy evolution, as well as the ability to start storing and accessing data with minimal effort and setup. This is equally true for JSON- based document-store databases, a class of NoSQL databases relating to the present invention that is organized as document store (as opposed to relational database) and relying on JSON (JavaScript Object Notation), a format also commonly used in implementing REST APIs (Application Programming Interfaces) and web services (where REST stands for Representational State Transfer, and a system complying to the so-called constraints of REST is called RESTful).

Just as for traditional databases, the planning and set-up of a NoSQL database is in need of a database model (or map) to help evaluate design options before the actual implementation. Said database model helps to think through the implications of different alternatives, to recognize potential hurdles before committing sizable amounts of development effort, and to plan ahead in order to minimize later rework. In the end, a modeling process aided by a good database model accelerates development, increases the quality of the application, and reduces execution risks. Further, said database model is particularly important in the case of a NoSQL database, since it is able to handle the increased complexity associated with the data and the (typically, very large) scale of NoSQL databases. Additionally, it circumvents the NoSQL-related problem that data structures are only tacitly described in the application code, forcing anyone involved in the database management to examine the code, which is obviously not the most productive way to engage in a fruitful dialog between analysts, architects, designers, developers, and DBAs.

Despite the popularity of NoSQL databases, there remains a need in the art for a good database model for this type of databases. The existing traditional methods and tools of classic relational databases cannot be applied to NoSQL and REST APIs. As a matter of fact, this argument has sometimes been used as a justification against the adoption and implementation of NoSQL solutions.

An earlier attempted solution tried to model a JSON data store, but did not provide a graphical way to represent the collections' schemas. Another attempted solution provided a tree-like structured diagram for a single collection, but did not offer a way to graphically model the multiple collections that make up a database. Another attempted solution defines 'visual design' of a REST API as 'described in a human readable format - in other words, plain text' and hence fails to provide a diagram.

EP 0 910 024 discloses a method, and associated system, for converting object oriented models into an actual operable database. The method and system automatically convert object oriented models into inputs that are compatible with a target product data manager platform. A problem with EP 0 910 024 is that it is limited to relational database schema models, lacking means to handle typical features of NoSQL environments, such as nested objects. US 5,596,746 discloses an algorithm for transforming data base schema information to object modeling notation utilizing meta models of the data base tables and the target object modeling notation respectively to bridge the gap between the data base schema representation and the object model representation. Similar to EP 0 910 024, US 5,596,746 is limited to relational database schema models, and hence lacks mechanisms to handle NoSQL-related features such as nested objects.

The present invention aims to resolve at least some of the problems mentioned above. The invention thereto aims to provide a method and system to graphically model schemas for NoSQL document databases and REST API's which is both functional and clear, thereby facilitating the work of, and the dialog between analysts, architects, designers, developers, testers, and operators of systems that are based on such technologies.

SU M MARY OF TH E I N VEN TI ON

In the database community, there is an increasing need for database management systems (DMBSs) that support a combination of data models, relational and non- relational, in a single DBMS platform. Hence, a convergence between RDBMSes and other data models (e.g., a NoSQL document database) takes place, creating the need for multi-model database schema models, and new methods suitable for the construction of a broad range of database schema models, including classical as well as multi-model database schema models. The present invention is directed at such methods and systems for constructing a database schema model. Specifically, this invention relates to a GUI-supported construction method of database schema models that extends the typical, table-like representation of collections, known, e.g., from both RDBMSes and NoSQL document databases, with the concept of nesting of one or more objects within a single collection with table-like representation, which is not possible with state of the art methods. Editing of said single collection is enabled by a related tree diagram, representing the schema definition of said single collection. In this regard, the present invention provides a very general solution to a known problem, such as the basic example problem discussed below in the section "Detailed description" (Example 2), which provides a clear and accessible introduction to the overall concept.

In a first aspect, the present invention concerns a method for constructing a database schema model by a user by means of a computer, comprising the steps of:

(a) providing a set of collections and optionally one or more relationships linking at least two of said set of collections;

(b) editing one or more of said set of collections, each of which associated with a schema definition displayed by a single table on an entity relationship diagram on a graphical interface on said computer and comprising at least one object and/or one field, said schema definition editable via a tree diagram on said graphical user interface on said computer;

(c) automatically generating by means of said computer said database schema model for a database system or a REST API; characterized in that, said set of collections comprises at least one collection comprising a nested object editable via said tree diagram with two levels or more. Hereby, said "set" may comprise one or more collections. In a preferred embodiment of the method according to the present invention, said set of collections comprises at least two collections, and step (b) comprises generating and/or editing one or more relationships linking at least two collections belonging to said set of collections via said entity relationship diagram on said graphical user interface on said computer; and at least one of said one or more relationships links a first field belonging to a first collection belonging to said set of collections to a second field belonging to a second collection belonging to said set of collections.

In the context of the present invention, the term "collection" comprises any tablelike representation of data within the context of databases and database management systems (DBMSes), such as a collection in a NoSQL document database, a REST-API-object, or a "classical" table in a relational database management system (RDBMS). Regardless of whether said collections are generated by the user via said graphical user interface or whether said collections have been imported from another format relating to, e.g., a NoSQL document database, a REST API or a RDBMS, the graphical interactive representation on a graphical user interface of said collections and their interrelationship is an integral part of the present invention.

For said graphical interactive representation of said collections, a tree diagram is used. Hereby, the term "tree diagram" comprises any tree-like structured diagram, said diagram comprising nodes and branches. Hereby, one of said nodes is a root node situated at a so-called top level, connected to different nodes at a lower level by branches, which nodes, in their turn, may be connected to branches at further lower levels. Hereby, the number of levels is counted excluding the top level. A node which is not connected to nodes at lower level is called a leaf node. Each node may comprise a field or an object, whereby an object at a given level comprises various nodes at a level lower than said given level. A nested object is therefore an object that is contained as node within a larger collection, whereby the presence of said nested object results in two levels or more for the tree diagram of said larger collection. In prior art methods, said nested object is not found in RDBMSes, since these assume "flat tables", limited to a table title at top level, and one or more attributes at the first level. This is a result of the fact that in RDBMSes, said nodes in said tree diagram all concern fields and not objects, whereby fields are by default leaf nodes. Likewise, said tree diagram with said two levels or more is found in NoSQL document DBMSes. The interaction of the user with said graphical interactive representation of said collections allows for a variety of interactive manipulations, such as the editing of properties of each node, the rearranging of nodes within a collection, and the moving of nodes from one collection to another collection.

For said graphical interactive representation of said relationships, an entity relationship diagram is used. Hereby, the term "entity relationship diagram" is to be interpreted in the context of databases and DBMSes, with entities corresponding to collections, and relationships between a first field in a first collection and a second field in a second collection. This type of graphical interactive representation is partially found in RDBMS and NoSQL prior art methods. A related graphical representation is found in many RDBMSes, whereby each collection (a flat table) is a single entity that relates to one or more other collections through a foreign key relationship, involving the concepts of a foreign key and a primary key familiar to the skilled person. In a preferred embodiment of the present invention, two collections can be linked by more than one relationship. Hereby, said relationships may concern foreign key relationships but may also concern foreign master relationships. Linking collections by more than one relationship is desirable in view of the presence of nested objects, which typically exhibit a multitude of relationships, for instance due to the application of so-called denormalization as described in this document. Since RDBMSes do not allow nesting objects, the need for more than one relationship between two collections is much less felt. Furthermore, the reason that said graphical interactive representation of said relationships is not found in NoSQL prior art methods lies in the fact that NoSQL models are inherently schema-less, addressing collections mainly as isolated entities, without a useful way of defining relationships between a first field of a first collection and a second field of a second collection.

Also the interaction of the user with said graphical interactive representation of said relationships allows for a variety of interactive manipulations, such as the editing of properties of each relationship and the rearranging of collections in order to generate new relationships or to edit existing relationships.

Overall, the present invention has the advantage of enabling to handle a very general structure, such as a JSON structure, through improved structure (less collections, only "true" relationships) (particularly in the ERD), sequence preservation (both in the ERD and the tree diagram), interaction (both in the ERD and the tree diagram), and indentation (reflecting nesting) (particularly in the ERD), while state of the art methods fail to do so. The result of the present method is not only more true to the corresponding general structure, such as a JSON document definition, but is also more compact in terms of ERD, allowing for a clearer and overall better overview. Additionally, also the interactive editing of the database schema model is more flexible, with richer interaction thanks to the choice between the ERD and the tree diagram. This is discussed in more detail in Example 2. A related advantage is the ability to better handle polymorphism, as discussed in more detail in Example 4. A key advantage of an embodiment according to the present invention is that the user is no longer constrained by the limitations of NoSQL and RDBMS prior art methods, allowing both object nesting and versatile relationship generation. In a preferred embodiment, individual collections (which may concern NoSQL collections but may also concern REST-API-objects) are editable in JSON schema definition via a tree diagram, while the relationships between collections are simultaneously editable via said entity relationship diagram. In a further preferred embodiment, this leads a single integrated interactive representation as illustrated, e.g., by Fig. 60, 61, 63, 65, 66 and 68, greatly improving the efficiency with which said database schema model can be constructed and edited. Also, by providing such an explicit representation, the present invention overcomes the problem with known NoSQL methods, wherein data structures are only tacitly described in the application code.

A related advantage of the present invention is the ability to model relationships. As mentioned above, NoSQL models are inherently schema-less, addressing collections mainly as isolated entities, without possibility of defining relationships between a first field of a first collection and a second field of a second collection. The latter is particularly problematic when a user wants to import a relational database schema model in a NoSQL environment, or, for any reason, desires to follow a RDBMS-like approach by linking collections. While the foreign key relationships comprised in the relational database schema typically play a key role in the organization of data, there is no concept available in NoSQL to model these or other relationships. In a preferred embodiment of the present invention, the database schema model allows to generate and edit foreign key relationships, and, related, leave foreign key relationships intact when importing relational database schema models.

In a further preferred embodiment of the method according to the present invention, said one or more objects comprise an array and/or a sub-document. This allows to incorporate structures known from NoSQL. Also, this plays an important role in the denormalization detailed below.

In a further preferred embodiment, said database schema model is formatted according to any or any combination of the following formats: JSON Schema, YAML, Mongoose, RAML, Swagger, Apache AVRO or Parquet. This has the advantage of providing the user with a format matching his/her specific needs.

According to another preferred embodiment, said automatic generation in step (d) automatically generates a human-readable manual for said database schema model based at least partly on a logical link defined by said one or more relationships. This has the advantage of improving the automated generation of manuals, by incorporating the information that is inherent to the relationships in the generated manual. In another preferred embodiment, said first collection and said second collection are linked by more than one relationship generated and/or edited in step (c). This has the advantage of further alleviating restrictions imposed by traditional prior art methods. As opposed to NoSQL DBMSes, the database schema model according to the present invention explicitly supports relationships between collections; as opposed to RDBMSes, two collections can be related by more than one relation. In a related further embodiment, on top of that, said first field belonging to said first collection is linked to both said second field and a third field belonging to said second collection by a first and second relationship, respectively. By allowing multiple relationships associated with a single field, which are preferably shown in a single integrated graphical interactive representation, flexibility for the end user is increased.

In a further preferred embodiment, said providing in step (a) comprises generating one or more of said set of collections on said graphical user interface on said computer. The user may thus choose to generate one or more collections directly on screen, and construct a database schema model from there. This has the advantage that the user can manually intervene in said construction, or even construct a database schema model from scratch.

According to a further embodiment, said providing in step (a) comprises denormalizing a relational database schema model provided by the user, said denormalizing comprising extracting said set of collections from a set of tables belonging to said relational database schema model, as well as any foreign key relationships belonging to said relational database schema model, for inclusion in said database schema model. This has the practical advantage that a user desiring to construct a database with NoSQL features such as said database schema model may take an existing available relational database schema model as a starting point, as is often desirable in practice. By "importing" both the collections and the foreign key relationships, all vital aspects of the relational database are carried over to said database schema model to be constructed. According to a related further embodiment, said denormalizing in step (a) further comprises processing a foreign key relationship between a parent collection comprising a primary key and a child collection comprising a foreign key, said processing comprising any or any combination of the following : including a nested sub-document in said child collection, said nested sub-document comprising one or more relationships to said parent collection; including a nested array in said parent collection, said nested array comprising one or more relationships to said child collection. This has the advantage that the features of the relational database are translated "without loss" to a context with nested objects, which is not possible in a RDBMS. This can be done according to different strategies listed above and commented in the detailed description below. In a sense, this translation comprises an "upgrade" of the original relational database schema model, in that the original collections and relationships are preserved, while the possibilities of interacting with said database have been extended to include NoSQL functionality. In a further related embodiment, said processing of a foreign key relationship comprises selecting one or more denormalization preferences on said graphical user interface on said computer, said denormalization preferences comprising any or any combination of the following : a table selection; an embedding preference with respect to said including of said nested sub-document in said child collection and/or of said nested array in said parent collection; a maximum number of cascading levels, a maximum number of recursion levels. This has the advantage that the user may customize the way in which the original relational database is translated into said database schema model, aiming either for a more concise result (e.g. with less tables, less nesting, less recursions) or a more extensive result (more tables, more nesting, more recursions).

In a second aspect, the present invention provides a computer-implemented method for constructing a database schema model upon input of a user according to a method according to the present invention, comprising the steps of: (i) receiving a set of collections and/or optionally one or more relationships linking at least two of said set of collections, optionally upon input of said user via a graphical user interface;

(ii) receiving edit instructions for each of said set of collections with respect to a schema definition upon input of said user via a tree diagram on said graphical user interface;

(iii) generating upon request of said user said database schema model for a database system or a REST API; characterized in that, said set of collections comprises at least one collection comprising a nested object editable via said tree diagram with two levels or more. In a preferred embodiment of said computer-implemented method, said set of collections comprises at least two collections, and step (ii) comprises receiving generate and/or edit instructions with respect to one or more relationships linking at least two collections belonging to said set of collections upon input of said user via said entity relationship diagram on said graphical user interface. Furthermore, at least one of said one or more relationships links a first field belonging to a first collection belonging to said set of collections to a second field belonging to a second collection belonging to said set of collections.

In a third aspect, the present invention provides a use of a database schema model constructed with a method according to any of the presented invention in a database system or a REST API. In a preferred embodiment thereof, said database system is any or any combination of the following : 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. This has the advantage of providing a superior user experience due to the integration of the present invention in the working environment to which it applies, yielding improved convenience for the user.

In a fourth aspect, the present invention provides a computer system for constructing a database schema model upon input of a user, said computer system comprising a processor, non-volatile memory, program code present on said memory for execution on said processor, a graphical interface, wherein said computer is configured to carry out a computer-implemented method according to the present invention. The advantages of such a computer system are similar to those of the related computer- implemented method . D ESCRI PTI ON OF Fl GU RES

The present invention may be more readily described by reference to the accompanying drawings in which :

Figu re 1 illustrates trends in the rise of JSON .

Figu re 2 illustrates the domain model .

Figu re 3 illustrates the graphical user interface.

Figu re 4 shows the menu bar.

Figu re 5 shows the file menu (item : Export) .

Figu re 6 shows the file menu (item : Reverse Engineer) .

Figu re 7 shows the Object browser.

Figu re 8 shows a first view of the central pane, displaying an example entity relationship diagram .

Figu re 9 shows a second view of the central pane, displaying an example tree-like structured diagram .

Figu re 1 0 shows a third view of the central pane, displaying an example grid view. Figu re 1 1 shows a fourth view of the central pane, displaying an example JSON preview.

Figu re 1 2 shows a fifth view of the central pane, displaying an example database creation script.

Figu re 1 3 shows a sixth view of the central pane, displaying an example database documentation.

Figu re 1 4 shows example top tabs of the central pane.

Figu re 1 5 shows the first set of bottom tabs of the central pane (corresponding to the database top tab).

Figu re 1 6 shows the second set of bottom tabs of the central pane (corresponding to the collection top tabs).

Figu re 1 7 shows the contextual menus (item : Align).

Figu re 1 8 shows the contextual menus (item : Add child).

Figu re 1 9 shows the contextual menus (item : Reference).

Figu re 20 shows a first view of the properties at database level.

Figu re 21 shows a second view of the properties at database level.

Figu re 22 shows a third view of the properties at database level.

Figu re 23 shows a first view of the properties at collection level.

Figu re 24 shows a second view of the properties at collection level.

Figu re 25 shows a third view of the properties at collection level.

Figu re 26 shows a first view of the properties at field level.

Figu re 27 shows a second view of the properties at field level.

Figu re 28 shows a third view of the properties at field level.

Figu re 29 illustrates a first step in the creation of a model.

Figu re 30 illustrates a second step in the creation of a model.

Figu re 31 shows the 'Details' tab of the properties of a database.

Figu re 32 shows the 'Relationships' tab of the properties of a database.

Figu re 33 shows the 'Users' tab of the properties of a database.

Figu re 34 shows a first step in the creation and editing of a collection.

Figu re 35 shows a second step in the creation and editing of a collection.

Figu re 36 shows a third step in the creation and editing of a collection.

Figu re 37 shows the 'Details' tab of the properties of a collection.

Figu re 38 shows the 'Users' tab of the properties of a collection.

Figu re 39 shows the 'Indexes' tab of the properties of a collection.

Figu re 40 illustrates the creation of fields for a collection.

Figu re 41 illustrates the non-root elements that can be created.

Figu re 42 shows the properties of a field. Figu re 43 shows a first step in the addition of entries with a 'plus' icon in the field properties.

Figu re 44 shows a second step in the addition of entries with a 'plus' icon in the field properties.

Figu re 45 shows the case of multiple types in the field properties.

Figu re 46 shows the reference option in the contextual menu.

Figu re 47 shows a graphical view of the definitions at collection level.

Figu re 48 shows a graphical view of the definitions at database level.

Figu re 49 shows an example grid view.

Figu re 50 shows an example JSON preview.

Figu re 51 shows an example documentation.

Figu re 52 shows an example database script.

Figu re 53 illustrates the export feature.

Figu re 54 shows the Print dialog.

Figu re 55 shows the Print Setup dialog.

Figu re 56 shows the options interface.

Figu re 57 shows the JSON Schema display configuration.

Figu re 58 shows two flat tables in a source model.

Figu re 59 illustrates a foreign key relationship.

Figu re 60 shows a denormalization result.

Figu re 61 shows a denormalization result.

Figu re 62 illustrates a foreign key relationship.

Figu re 63 shows a denormalization result.

Figu re 64 shows three flat tables in a source model.

Figu re 65 shows a normalization result.

Figu re 66 shows a denormalization result.

Figu re 67 shows a flat table in a source model.

Figu re 68 shows two denormalization results.

Figu re 69 shows three flat tables in a source model.

Figu re 70 illustrates the menu access.

Figu re 71 shows a warning relating to saving of the current model.

Figu re 72 shows a parameter interface relating to the denormalization process.

Figu re 73 shows an example problem with solution according the present invention.

Figu re 74 shows the "JSON document to model" of the example problem.

Figu re 75 shows the "Modeling with traditional ER software" of the example problem.

Figu re 76 shows the "Modeling according to present invention" (part 1 of 2) of the example problem.

Figu re 77 shows the "Modeling according to present invention" (part 2 of 2) of the example problem.

Figu re 78 shows an example interface relating to referencing and denormalization. Figu re 79 shows an example relating to referencing and denormalization.

Figu re 80 shows an example ERD.

Figu re 81 shows an example tree diagram.

D ETAI LED DESCRI PTI ON OF TH E I NVENTI ON

In this document, the term "document" relates to a collection; particularly, data belonging to a collection is typically stored in one or more documents, preferably JSON documents. In this document, both "foreign master relationships" and "foreign key relationships" fall under the class of "relationships", whereby foreign master relationships concern relationships that are not foreign key relationships. Furthermore, the acronym "GUI" stands for Graphical User Interface. A key aim of the present invention is to provide programmers, application developers and database managers with a powerful new method to construct database models. To this end, the present invention combines the graphical interactive representation of collections in a tree diagram with the graphical interactive representation of relationships between collections in an entity relationship diagram. Together, these graphical representations provide both the schema model and the documentation of that model. The present invention facilitates the work of, and the dialog between a variety of users such as analysts, architects, designers, developers, testers, and operators of systems that are based on such technologies. In a preferred embodiment of the present invention, schemas and documentation can be generated in a variety of machine-based formats such as JSON Schema, Mongoose, collection definition scripts, RAML, Swagger, YAML, Apache AVRO or Parquet, or human- readable formats. In a further preferred embodiment, the user is facilitated in the importing of a relational database schema model and its translation into a database schema model according to the present invention. According to another aspect of the current invention, which is not intended to limit the scope in any way, the present invention provides a method and system to graphically model a database schema model for NoSQL document databases and REST APIs. Specifically, it provides a method and system to combine 1) the graphical representation of collections (in NoSQL Document Databases) or objects (in REST APIs) through an Entity Relationship diagram, with 2) the graphical representation of the JSON Schema definition of said collections or objects through a Tree-like structured diagram. Together, these graphical representations provide the schema model of a NoSQL document database or REST API, and the documentation of that model. The invention is further described by the following non-limiting example which further illustrates the invention, and is not intended to, nor should it be interpreted to, limit the scope of the invention.

According to another aspect of the current invention, not intended to limit the scope in any way, the present invention provides a method for graphically modeling schemas for NoSQL document databases and REST APIs, comprising providing a graphical representation of one or more collections or one or more objects, and simultaneously providing a graphical representation of a JSON Schema definition of said collections or objects through a tree-like structured diagram.

According to another aspect of the current invention, not intended to limit the scope in any way, the present invention provides a system for graphically modeling schemas for NoSQL document databases and REST APIs, said system configured to provide a graphical representation of one or more collections or one or more objects, and to simultaneously provide a graphical representation of a JSON Schema definition of said collections or objects through a tree-like structured diagram.

The present invention is directed to the construction of database schema models, whereby the database schema model may be a simple known representations such as a single JSON document, but also a "multi-model" database schema model, as long as the database schema model exhibits said nesting corresponding to a tree diagram with two levels or more. Hereby, the term "multi-model" refers to a database schema model that comprises features of both relational databases and NoSQL databases, and hence cannot be assigned to only one of these categories, as is currently emerging in the database community.

The present invention relates to database schema models such as the ones considered by MongoDB and other NoSQL systems such as DynamoDB. Hereby, several specific terms are borrowed from the context of existing systems, in particular MongoDB. However, it is important to note that the terms used in the present invention are chosen in correspondence to MongoDB merely for clarity's sake, and are not to be interpreted as limiting the invention in any way. Hence, the terms "collection", "document", "field", "sub-document" and "array" are similar yet not necessarily identical to the counterpart terms of the same name in MongoDB and many other NoSQL systems and/or RDBMSes. Moreover, some NoSQL systems use different terms; particularly DynamoDB adopts a different naming convention. Also Couchbase and Cassandra adopt a slightly different terminology. The following list of counterpart terms is included for clarity's sake, without limiting the present invention in any sense.

Following are four examples relating to embodiments of the present invention. While Example 1 is directed to a multitude of aspects of the invention, Example 2 considers the simple case of a single JSON document with nesting, for which the invention equally applies. Example 3 relates to referencing in denormalization. Example 4 considers an example ERD and associated tree diagram according to an embodiment of the present invention. EXAMPLE 1

1. Project drivers

The project relates to the activities of IntegrIT (doing business as Hackolade). 1.1 References

The following reading may be useful to inform the reader of the context: - JSON and BSON specifications: http://json.org/ and http://bsonspec.org/ JSON Schema specification : http://json-schema.org/

Trends in the rise of JSON, cfr Fig 1

1.2 The user problem and context of the project

1.2.1 Schema-less NoSQL databases JSON-based document-store NoSQL databases (MongoDB, Couchbase, CouchDB, Amazon DynomoDB, MarkLogic, OrientDB, RavenDB, Microsoft Azure DocumentDB, EnterpriseDB, etc., cfr. http://db-engines.com/en/ranking/document+store) promote the concept of a "schema-less" approach with many advantages, such as the flexibility for the schema to easily evolve over time, or the ability to start storing and accessing data without first defining a schema.

The data transformations and data characteristics in NoSQL systems are not often mapped in models. The tools for such modeling haven't existed. The data isn't often captured in models; it's tacit in the code. To understand how the data is stored and read, the code has to be examined. The model is essentially "implicit" to the programmers and developers working on the system : it is in their brains and then is manifested in the code of the system.

The advantage of a schema-less DBMS is that one can start storing and accessing data without first defining a formal schema. While this sounds great, and certainly facilitates a speedy start to a data project, experience shows that a lack of forethought is usually followed by a lot of afterthought. As data volumes grow and access times become significant, thought needs to be given to re-organizing data in order to speed up access and update, and sometimes to change tradeoffs between the speed, consistency, and atomicity of various styles of access. It is also commonly the case that patterns emerge in the data's structure, and the realization grows that, although the DBMS demands no particular data schema, much of the data being stored has some significant schema in common.

1.2.2 Use of Schema Definitions

A data model of some kind is vital : definitions, elements, transformations, and relationships still need to be understood and documented. There is no way for an organization to gain a 360° view of their entire business at all data, system, application, decision process, transaction, and customer levels without some sort of models or maps to explain them. A database model gives the opportunity to play with database design options on paper, on a whiteboard, or in a drawing tool, before one has to worry about the syntax of data definitions, data already stored, or application logic. It's a great way to think through the implications of data organization, and/or to recognize in advance important patterns in the data, before committing to any particular design. It's a lot easier to redraw part of a model than to recreate a database schema, move significant quantities of data around, and change application code.

A schema is a vehicle for describing content to determine compliance. It is often used under the covers as part of vetting content for entry into a program by a validation process.

It can also be effectively used as a tool for creating correct content and accelerating the correction process. This is especially true for content created by people or generated through interactive systems, where dynamic processes are part of the content definition. Sometimes using a schema or other data definition capability is viewed as "locking down" a system, or making it inflexible. However, with the expressiveness of JSON Schema, the purpose of the schema is not to limit flexibility, but rather to correctly express only what is required from the data content, create useful notices of corrections required, and leave the remaining content to the programs to interpret. 1.2.3 Benefits of using a schema

Validation can be done with program logic. In fact, a significant portion of many programs is used to validate inputs to be processed by the program. This includes start-up command processing, reading configuration files, reading data files, receiving messages, and accepting user input. In each case, the goal of the validation process is to determine whether the input content is correct and complete before invoking further processing. The use of a schema, and a corresponding validation function to apply the schema to the content, allows the validation function to be processed by a purpose-built function rather than bespoke coding. The schema definition, being in the domain of the data definition, is more expressive and easier to understand than program logic.

With simplified definition and maintenance, it is more likely that the validation will be: • More complete, since the time to produce schema content can be less than the time to write program logic to perform this task.

• More readable. Reading program logic for validation often requires reading a mix of stream processing, type checking, and expression checking logic. Reading a schema focuses on the data representation, without the other processing logic mixed in.

• Used correctly by others producing content. Often program logic is a black box, or the documentation limited, making determining all valid inputs for particular elements, or whether elements are required or optional, difficult to ascertain without excellent documentation being provided. Providing a schema to other parties makes the task of creating correct content to provide to the program much easier. Not all content benefits equally from using a schema. A program that only has one or two configuration options doesn't have a significant amount of validation code, and a program that expects free form content may not have enough definition to be very useful. Selecting the programs, and places in the program, where schema definitions can be of benefit is a design choice.

1.2.4 JSON Schema

In the message exchange space, JSON is commonly used in implementing REST web services. Its broad use reflects the flexibility of JSON-formatted content to support iterative definition for message exchanges between systems, coexistence with a range of technologies, and ease of understanding.

In addition to configuration files, many programs also have data management requirements. While some programs have requirements suitable for using databases, others have more modest needs and are better suited to the flexibility of using JSON files. However, for JSON-suited programs, as the content expands (both in the structure of the data model as well as the amount of data stored), there is greater risk of data consistency errors. Also, as is the case with many configuration files, updates to the data may be made with text editing tools and are subject to errors - often minor. Finding these errors is often more work than correcting them - a missing comma, misplaced closing } or ], or a typo in a keyword. Fortunately, there are two tools that address this well :

• JSON syntax checkers, which find syntax errors.

• JSON Schema, and its affiliated validation tools, which find content errors. As JSON has gained support across a broad array of programming languages / runtime platforms, the use of JSON formatted files for configuration files and similar uses is now an available option for many projects.

JSON and JSON Schema are strong foundational technologies, with many avenues for building interesting and useful capabilities around them.

1.3 Goals

The present invention allows analysts, solution designers, architects, developers, and database administrators to visually design, model, define, and create documentation for the schemas of JSON Document-based NoSQL databases and REST APIs. The related application enables users to do with JSON documents what has been possible respectively for relational databases and for XML documents.

The graphical interface will let the user visualize and maintain a diagram of the model collections and their relationships, as well as the content of the collections. The outputs of the model will be: JSON documents and JSON-Schema v4-compliant JSON (http://json-schema.org/documentation.html), scripts (MongoDB, Mongoose, etc.), and a detailed documentation of the model in HTML (as well as Markdown, PDF and RTF formats) as well as RAML and Swagger.

The application will store in a local or central repository the properties of one or more documents defined by the user, as well as their relationships, if any. 2. Requirements

2.1 Business requirements

2.1.1 Domain

Cfr Fig 2. The application lets a user create a Model. The model is made of one Diagram for one Database (for MongoDB and other NoSQL systems) or Application (for REST APIs.) A Database is made of one or more Collections (or Documents) and possibly of logical Relationships between them. A Collection is made of Fields and Objects. It is possible for Relationships to exist between certain Fields of different Collections. The Database and each of its Collection, and each of the Collection's Fields and Objects, as well as Relationships, all have Properties. Collections and Relationships are represented in a Diagram. Diagram and properties lead to outputs in the form of Schemas, Samples, Scripts, and Documentation files.

2.1.2 Business use cases • Storage/retrieval of models

o User creates a new model from scratch

o User retrieves a previously stored model

o User saves or cancel changes since last save

o User saves a model under a new name as a new stored version of the previously saved model

• Modeling

o User defines a database and its properties

^■ Graphically adapts layout of entities

o User creates Collections, their content and related properties

^■ Graphically

^■ With a grid

■ Through the text-based editing of JSON Schema

o User creates Relationships and their properties

o User can visualize and print different outputs:

■ Model Entity Relationship (ER) diagram

■ Collection Document Type Definition (DTD) diagram

■ JSON document sample

^■ JSON Schema

■ HTML/Markdown/PDF/RTF documentation

MongoDB Script

^■ Mongoose Schema

^■ Scripts for other database vendors

• Utilities

o Where-used capability

o JSON validator

o JSON Schema validator

o Model comparison

o Reverse engineer a database schema

o Reverse engineer JSON documents and JSON Schema files o Repository

o License key management

o Check for and install updates to the application

Regarding said Model Entity Relationship (ER) diagram, note that strictly speaking the concept of ER is generally related to relational databases, and not JSON or NoSQL databases. For ease of communication however, the concept is adopted in this document, but the vocabulary will not transpire in the application. Regarding said Collection Document Type Definition (DTD) diagram, note that strictly speaking, the concept of DTD is related to XML and not JSON. For ease of communication however, the concept is adopted in this document, but the vocabulary will not transpire in the application. 2.2 Functional requirements

2.2.1 User interface

2.2.1.1 Application sections

The application screen is divided in several sections, cfr. Fig 3.

The different sections are described below. 2.2.1.1.1 Menu bar

Cfr Fig 4. These menus are configured in JSON documents to allow easy changes in relevant properties without programming impact. Options are greyed out if unavailable to the user in the application context.

Each menu option is described in further detail below. 2.2.1.1.1.1 File menu

Cfr Fig 5 & 6.

New Model Create a new model. If current model has unsaved changes, user is prompted to Save (or Save As if current model has never been saved.) In a later phase, user may be prompted to choose a model type (MongoDB, other NoSQL, REST API, basic JSON, ■■■)

Open... Retrieve an existing model.

Open Recent Show sub-menu of last 5 model names opened.

Close Close model.

Save Save all changes to model.

Save As... Save the model to a different repository name.

Reverse Select a JSON Document file, JSON Schema file, or Mongoose Engineer... Schema on the file system, so the application can derive some collection properties.

Specify access to a database, so the application can derive some collection properties. Export Export, for the current collection or for the entire database, the JSON Sample, JSON Schema, MongoDB Script, Mongoose schema, other NoSQL database, or documentation.

Print... Print the current diagram.

Exit Quit the application.

2.2.1.1.2 Object browser

Cfr Fig 7. This pane is dynamically constructed based on entities created in the Central and Properties panes. It provides a structured outline view of the model, and a quick access to elements of the model. This pane also includes a search bar as well as a 'where used' view of the elements.

If the data does not fit in the pane, vertical and horizontal scroll bars appear.

When elements in the pane are clicked, the central and the properties pane display more information. Thanks to a toggle in the View menu, the user may choose to make the pane disappear (in order to provide more space for the central pane), or to make it reappear.

2.2.1.1.3 Central pane

The Central pane serves several purposes: - Graphical view of the database entity relationship diagram, cfr Fig 8

Graphical view of the field hierarchy diagram for a collection, cfr Fig 9 Graphical view of database and collection definitions, cfr Fig 8

Grid view of the fields of a collection, cfr Fig 10

JSON preview of a sample document for a collection and corresponding schema, cfr Fig 11

Preview of database creation script for a collection, cfr Fig 12

Database and collection documentation, cfr Fig 13

The pane has 2 sets of dependent tabs: top and bottom.

The top set has one fixed tab, the tab for the model database, and one tab for each collection created or consulted, cfr Fig 14. Collection can be closed, re-opened, and moved around, whereas the database tab remains fixed. If too many tabs are opened to fit in the width of the pane, depending on the library used, tabs will keep their size (full length of Collection name) with arrows left/right will let the user scroll (Firefox- style), or the tabs will shrink with a tooltip (Chrome-style.)

There are 2 bottom sets of fixed tabs, one set of bottom tab for the database top tab, cfr Fig 15, and one set of bottom tab for the collection top tabs, cfr Fig 16. The bottom tabs cannot be closed or moved.

The central pane has both a vertical and a horizontal scroll bar if the data or diagram do not fit in the pane, particularly in responsive mode.

The central pane can display graphics (database and collection), a grid, JSON (sample / schema), documentation, or database script. These tabs are functionally linked together, and changes in one may have effects on the other, and vice-versa. They need to be dynamically updated.

The pane is permanent (cannot appear or disappear like the Object Browser or the Properties Pane.) However, its size may vary with the appearance or disappearance of the Object Browser and/or the Properties Pane. The user may manually modify the width distribution of the 3 panes.

The Central Pane supports contextual menus (right mouse click), cfr Fig 17-19.

These contextual menus are configured in JSON documents to allow easy changes in relevant properties without programming impact. Options are greyed out if unavailable to the user in the application context. Arrow keys direct the following behavior:

In the ER diagram when a collection is selected : move it around

In the DTD diagram : move from one element to the other:

o Left and right arrow keys: move shallower or deeper in the tree o Up and down arrow keys: move along the elements of the current level in the tree

2.2.1.1.4 Properties pane

This pane is where most of the data entry is performed. It can have different configurations depending on the element being edited/displayed.

There are 3 levels of properties panes: database (including relationships), collection, and field. The appropriate properties pane is displayed depending on the element being selected in the Central Pane or the Object Browser. The properties panes for database and for collections have fixed bottom tabs.

Properties at database level, cfr Fig 20 through 22

Properties at collection level, cfr Fig 23 through 25

- Properties at field level, cfr Fig 26 through 28

Properties are controlled by a JSON schema to allow easy changes in relevant properties without programming impact, and property entries are stored in each Collection's definition in a JSON document.

Fields are editable directly (no edit/cancel/save buttons). If the data does not fit in the pane, vertical and horizontal scroll bars appear.

2.2.2 Core functions

2.2.2.1 Creation of a model

A model is made of diagram and relationships representing a database of collections made of fields. When a new model is created from scratch, typically for a database underlying an application or API, the user gets an empty screen, cfr Fig 29.

The unnamed top tab of the Central pane is active, as well as the bottom Diagram tab.

At this point, the user starts by filling-in the properties for the database, cfr Fig 30. Creating the name in the Properties pane dynamically updates the name in the fixed tab of the Central pane, in the Object Browser, and in the application Title bar (all the way at the top left).

2.2.2.2 Properties of a database

2.2.2.2.1 Details Most of the information maintained here is just for documentation purposes, or metadata for internal use by the application, cfr Fig 31. Some may be used in script creation.

2.2.2.2.2 Relationships

Relationships are links between different Collections of a Database. As a reminder, contrary to an RDBMS, relationships are not explicit in a schema-less NoSQL database, but well in the application code. They can however (and should) be documented here, and serve as a basis for design and troubleshooting discussions, cfr Fig 32.

Until 2 or more Collections are created documented in the database, this tab is not enabled. There are 2 kinds of relationships: foreign key, and foreign master.

Just as in an RDBMS, a foreign key relationship makes reference to the unique identifier of a document in another Collection in the database. Particularly with the release of MongoDB v3.2 and the introduction of the $lookup functionality and the BI Connector, the documentation of foreign keys becomes a lot more relevant. A foreign master relationship documents a denormalization, or the repetition of the content of a field in another collection. The source is considered the master (or parent) and the child is where the data is duplicated. Particular care should be given to making sure that children are updated when data in the master changes.

Important note: there can be more than one relationship between 2 tables. There can even be several relationships pointing to one field in a parent table, coming from different fields in a child table.

2.2.2.2.3 Users

The only information useful to a database (besides the name in the details section) is user credentials. Additional credentials can be maintained at Collection level, cfr Fig 33.

Note that security rights tend to change from version to version, and should therefore be tied to a version number.

2.2.2.3 Creation of a Collection

The next step is to create a Collection. This can be done in 2 ways: - By clicking on the Add Collection button in the toolbar,

By doing a right-click of the mouse anywhere in the Central pane to get a contextual menu, and choosing the option "Add Collection", cfr Fig 34.

A new empty collection now appears in the Central pane, cfr Fig 35 A tab appears at the top of the Central pane, but is not activated. An entry is created in the Object Browser hierarchy. Now, in order for the user to start editing the new collection, 3 possibilities are offered :

Double-click on the Collection box in the Central pane diagram,

Single-click on the Collection line in the Object browser, - or single-click on the Collection tab at top of the Central pane.

The Collection top tab is active, with the bottom Schema tab active, and the Central Pane displays a single fixed element: the root of the Collection schema, cfr Fig 36.

As the user enters the Collection name in the properties, the name gets updated in the Central pane tab, and in the Object Browser. The user fills in additional properties.

2.2.2.4 Properties of a collection 2.2.2.4.1 Details

The user can record here some data useful for the database creation script, as well as some info useful for the application, cfr Fig 37. 2.2.2.4.2 Users

Collection-level security credentials, cfr Fig 38. Note that security rights tend to change from version to version, and should therefore be tied to a version number.

2.2.2.4.3 Indexes

The information is useful for documentation purposes as well as for the database creation script, cfr Fig 39.

2.2.2.4.4 Sharding (To be determined)

2.2.2.5 Creation of fields in graphical view

Next, the user is ready to create fields for the Collection, in a variety of ways: - Click on the Add Child button in the toolbar, which pops up the contextual menu,

Or right-click on the Schema root to display a contextual menu, then click on Add Child, then Field, then the appropriate Field type By clicking on the 'plus sign' of the schema box (also for complex objects such as documents and arrays.)

The options accessible in the contextual menu, cfr Fig 40 depend on the type of element selected prior to invoking the contextual menu. 2.2.2.5.1 Root element

There is only one root possible per document. For the purpose of a NoSQL database schema, the root element can only be of type: document. Properties can be filled for the root element. One or more children can be created. The Insert, Append and Reference options are greyed-out since the functions are not possible for a root element.

2.2.2.5.2 Non-root elements

For any other element than the root element, the 4 options (Add Child, Insert, Append, and Reference) are possible, cfr Fig 41. The options of the sub-menu depend on the nature of the element selected. Let's first define the different elements that can be created.

2.2.2.5.2.1 Field

This is the most common element in a schema. It defines the name-value pair that will be found in the JSON data. The properties define the details and constraints of both the name and the value in the pair. As defined by the JSON Schema specification, the available types for a field value are: string, numeric, boolean, object (document), array, and null. For the purpose of MongoDB, additional BSON types are available: objectID, binary, date, timestamp, regex, JavaScript, JavaScript with scope, symbol, minKey, and maxKey.

The nominal case is for an element to have only one type. The JSON specification however allows a field to be of multiple types. The application UI is able to define and maintain multiple types for a field, cfr Fig 42 through 45.

The name of a standard field is a fixed string.

The nature of children is different for document, array, or other elements. Documents are allowed to have one or more Fields, Pattern Fields, and/or Choices as children. Arrays are allowed to have one or more Array Items and/or Choices as children. As for all other types of fields, the only possible child is 'Choice'. As a result, for all elements, a 'plus sign' ('+') appears at the right edge of the element box with label 'Schema' and the 'Add Child' option in the contextual menu is enabled. However, if the 'plus sign' is clicked and :

The element is a document, array, or Choice, then the contextual sub-menu is opened below Add Child level;

The element is of any other type, then a Choice element is created.

For all elements, the options in the sub-menu of 'Add Child' appear as follows: If the element is a document, then the options Field, Pattern Field, and Choices are enabled ;

- If the element is an array, then the options Array Item and Choices are enabled;

If the element is a Choice, then the options Choices and Subschema are enabled; If the element if of any other type, then only the option Choices is enabled.

Since it is possible for an element to have multiple types, the available options are the sum of the options of each type of an element. The Insert and Append functions in the contextual menu work in a similar way, except that while an element is selected, the Insert and Append behaviors are tied to the type of the parent element.

The properties of each field type are configured in a JSON Schema file.

2.2.2.5.2.2 Pattern field Pattern fields function in exactly the same way as standard fields, with only one exception : the name (in the name-value pair) is not a fixed string, but a regex pattern. This is particularly useful in MongoDB in combination with 'dot notation'.

2.2.2.5.2.3 Choice

In JSON Schema, there are 4 possible choices: "allOf", "one of", "anyOf", and "not". Each of these elements contains an array, with each element of the array representing content that will be matched against. The choice of "allOf", "one of", "anyOf", or "not" determines how the validation processor will treat the results of the matches: allOf requires that all elements in the array are matched successfully. - oneOf requires one, and only one, of the elements in the array to match successfully. anyOf requires one or more of the elements in the array to be matched successfully. not requires that no element in the array is matched successfully.

Schema definitions can use "allOf", "oneOf", "anyOf", and "not" individually or in combination, providing significant flexibility for defining elements that have complex definitions or contextual relationships. These choices apply both to fields and to field properties.

In both cases, the only possible child of Choice is a Subschema or another Choice. When clicking on the 'plus sign' of a Choice element, a Subschema element is created. Similarly, in the contextual submenu when a Choice element is selected, only the Subschema and Choices options are enabled. And when the child of Choice is selected, then the Subschema and Choices options are the only enabled options in the submenu of Insert and Append.

2.2.2.5.2.4 Array item This is the only possible child type of an Array field. Different types of array items are possible for a same parent element. Each can have from 0 to n occurences, but can be limited by the minltems and maxltems properties of the Array. It has a behavior quite similar to that of a standard field, except that the field properties are limited in comparison. This is controlled in the Field Prop JSON Schema in Appendix. 2.2.2.5.2.5 Subschema

If the choice applies to a field, then the subschema is a document with all the schema possibilities of a JSON object.

The choice may also apply to an individual field property, in which case it is a simplified schema with the just the appropriate property of a field type. Example, a string field could have a format of ipv4 or ipv6.

2.2.2.6 Properties of a field

2.2.2.6.1 Details

The field properties are located on the right-hand side in a dedicated pane. Depending on the field type selected in the previous step, the appropriate properties schema appears in the properties pane. The field properties are controlled by a Field Properties JSON Schema file found in appendix. Vertical and horizontal scroll bars appear when content spills over the displayed pane size (variable according the responsiveness nature of the application.) Different types of input are possible in the properties pane:

Text field - Checkbox

Drop-down box: a list of values controlled either by the Field Properties JSON Schema (e.g. ; possible string formats) or by entries in the DB or Collection (e.g. : foreign keys, references or field dependencies.)

Additionally, the properties pane allows the addition of other entries with a 'plus sign' icon. For example with enumerations, the user may fill one entry, then click the 'plus sign' icon so more entries are allowed underneath.

Multiple entries are also possible with drop-down boxes, such as dependencies.

A bit more complicated is the case of multiple types. In such case, some fields are common, and others are specific. 2.2.2.6.2 References

JSON Schema allows the creation of reusable definitions, so they don't need to be duplicated in multiple places. The definitions can cover a single field or a more complex structure like a document. A definition may exist at 3 levels:

Internal to a Collection (and therefore not available for referencing elsewhere than in its own collection),

Database model workspace, in which case it is available to any collection of the database,

External, i.e. in a public location on the Internet

Definitions are not possible for Choices or Array Items. Only for Fields, Pattern Fields, and Subschemas. Therefore, the Reference option in the contextual menu is only enabled for these last 3 elements.

The Reference option in the contextual menu leads to the following actions, cfr Fig 46.

2.2.2.6.2.1 Convert to Internal Definition When this option is selected, the system takes the element properties, copies them to the Definitions section of the same Collection JSON Schema, and replaces the element properties with a Reference to the newly created definition.

2.2.2.6.2.2 Convert to DB Definition When this option is selected, the system takes the element properties, copies them to the Definitions section of the database model workspace JSON Schema, and replaces the element properties with a Reference to the newly created definition.

2.2.2.6.2.3 Convert to External Definition

The system takes the element properties, copies them to the Definitions section of JSON Schema to be stored in a central repository, and replaces the element properties with a Reference to the newly created definition.

2.2.2.6.2.4 Convert definition to Local Properties

Once an element references a definition, the user may want to convert the reusable definition into a local instance, typically to diverge from the reusable definition. With this action, the Reference is removed from the element properties, and replaced by a full copy of the Definition previously referenced. The definition remains in place, as it may be used elsewhere in the DB or collection.

2.2.2.6.2.5 Go to Definition

When an element references a Definition, choosing this option will let the user view the properties and details of the Definition.

2.2.2.7 Definitions

External definitions cannot be maintained in the application. Definitions appear in the Object Browser in a separate section.

2.2.2.7.1 At collection level Definitions at collection level are maintained in a graphical view similar to that of a complete collection schema, cfr Fig 47.

2.2.2.7.2 At database level

Definitions at database level are maintained in a graphical view similar to that of a complete collection schema, cfr Fig 48. 2.2.2.8 Field where-used and search

In the Object Browser, there will be a dynamic tree view of where a field is referenced : collection and sub-objects, if any), and definitions.

2.2.2.9 Grid view This view provides exactly the same functions as the graphical view, but with a different layout and visualization, cfr Fig 49.

2.2.2. 10 JSON preview

One difficulty with JSON Schema is to easily visualize a JSON document complying with the schema defined . To that effect, the Properties pane provides for each field a Sample entry box so the user can record an example to be used in a JSON document. This view shows, side by side, the JSON data document, and the corresponding JSON Schema as defined in the Diagram or Grid views, cfr Fig 50.

Modifications are allowed in the JSON Schema pane, and validation of these changes is made on-the-fly so as to give immediate feedback to the user. Changes made in this preview are immediately visible in the Diagram and Grid views, and vice-versa . This should be insured by the way entries are persisted . The JSON data is also editable.

2.2.2. 11 Documentation

The goal with this tab is to generate a human-readable documentation of the JSON Schema created, as an equivalent implementation for JSON to something that is fairly common for XSD, cfr Fig 51.

The documentation can be exported to RTF, PDF, Markdown, and (X)HTML formats, as well as RAM L and Swagger. It is available for an individual Collection, or for the entire DB. 2.2.2. 12 Database script

With MongoDB 3.2, a document validator was introduced . The system will provide mapping between JSON Schema syntax and MongoDB validator syntax, cfr Fig 52. Similar functionality will be made available for other vendors, where applicable.

2.2.3 Additional functions 2.2.3.1 Open, save, save as, close

These functions will be affected by the type of repository and the way persistence in performed. Other than that, the features should fulfill the functions that one could normally expect. 2.2.3.2 Reverse engineer

This advanced feature takes as input either: a simple JSON document, and generates the schema for that document the current model; a JSON Schema, and fills the properties in the current model; - or connects to a NoSQL database and takes representative documents form the collections present in the database. It generates the schemas for the different collections in a workspace.

The user can then edit the model and save it independently of the source, cfr Fig 6.

2.2.3.3 Export This advanced feature lets the user export parts of the model or the model in full, in a variety of formats, cfr Fig 53.

2.2.3.4 Print

Printing is possible for diagrams, as well as for documentation, JSON documents, and schemas. The controls provided to the users should be as follows: print setup (so the printer and its properties, as well as the paper size can be selected), print preview (so the user can visualize the output prior to actual print), print selection, zoom level, and whether objects can print across page splits, cfr Fig 54 & 55.

2.2.3.5 Compare models

The goal with this advanced feature is to provide a side by side view of 2 models (presumably 2 different versions of the same model), highlighting differences between them.

2.2.3.6 Options Typically, parameters to be user-maintained appear in the course of design and development of an application, and they grow with the application, cfr Fig 56.

For the schema display controls of the DTD diagram, several controls could be included in a JSON Schema display configuration, cfr Fig 57. 3. Application to relational databases and denormalization suggestion requirements

In this section, the concept "denormalization" mentioned earlier in Sect. 2.2.2.2.2 is elaborated upon. In this document, the term "denormalization" refers to any conversion from a source database model to a destination database model wherein nesting takes place.

Specifically, this section discusses an embodiment of the present invention wherein a source relational database model is converted into a destination database model according to the present invention. Hereby the foreign keys present in the source relational database model are used for nesting. Specifically, the destination database model is obtained by nesting joined foreign tables.

The concept of denormalization illustrates the broad range of applicability of the present invention. While above, the applicability was illustrated mainly in case of NoSQL databases and REST APIs, relational databases and RDMS and all related aspects are equally in the scope of the present invention. In a preferred embodiment, this is done through "reverse-engineering", similar to the functionality explained above. In an alternative embodiment, this is done through "forward-engineering". In yet alternative embodiment, this is done by operating directly on a relational database and RDMS.

While denormalization is presented in this document as an embodiment of the present invention, it may also be considered as a stand-alone concept and related invention. Specifically, the graphical user interface used in this section reflects only one embodiment of the concept of denormalization. In an alternative embodiment, denormalization as described in this document enables generating a destination database model from a source database model without necessitating a graphical user interface in any step of the generation method.

3.1 Introduction Assuming that the function 'Reverse-Engineer DDL file' is available, an often requested additional function is to suggest a denormalized model based on an original relational model.

This document describes the process of taking a source relational model (created from scratch or through the reverse-engineering of a DDL file or RDBMS) stored with a method according to the present invention, and generating a new model while nesting joined foreign tables. After that process, the user can further edit and refine the denormalized model.

3.2 Concepts Starting with 2 flat tables in the source model, see Fig. 58, with a foreign key relationship illustrated by Fig. 59, there are at least 2 ways and even 3 ways that denormalization could be seen, given in Sect. 3.2.1-3, respectively.

3.2.1 Sub-document of child table containing foreign parent table structure

As a flat table in a normalized source model is being copied to a collection in a denormalized destination model, if a foreign key relationship is encountered, the structure of the parent table is included as a nested sub-document of the collection.

The expected result of the new function is illustrated by Fig. 60.

Here, the parent table structure has been embedded as a sub-document structure in the child table. Foreign keys and foreign master relationships are automatically created in the embedding process.

3.2.2 Array in parent table containing child table structure

Another way to perform denormalization is to create, in the parent table, an array with the structure of the child table, with the expected result illustrated by Fig. 61.

Remarks: 1) The child field with the original relationship is not repeated in the parent table array, so as to not create circular references

2) The parent-child relationship is inverted. Now the parent of the fields in the newly created array are the fields in the former child table.

3) As a result, the l.. n cardinality is in the parent, see Fig. 62. Note how the field name would benefit from dot. notation to represent nesting. 3.2.3 Combination

If the 2 logics are combined, the following result is generated, illustrated by Fig. 63. Depending on how data is read, all 3 above ways to denormalize are possible.

3.2.4 Cascading When a parent table is itself the child of another (grand-)parent, the result illustrated in Fig. 64 is obtained. It may be desirable to cascade the relationships into multiple levels of nesting, to achieve the result illustrated in Fig. 65. (It will be nice to be able to rearrange relationships to reduce elbowed lines...)

And of course, the mirroring cascading array is possible, with the result illustrated in Fig. 66.

As this could go on and on forever in complex models, it is probably a good idea to limit the number of cascades, and let the user decide the number of cascades between 0 and a maximum of 3 for example. It is of course easier to delete an extraneous cascade than to manually create one. 3.2.5 Recursion

When a relationship exists between fields of the same table, again one can embed a child array into the parent, or embed a parent sub-document into the child. Here however, it is not suggested to do both.

Finally, there is no indication of how many times it would be necessary to cascade, without looking at the actual data.

The relational table shown in Fig. 67 can be modelled in either of the 2 ways illustrated in Fig. 68.

3.2.6 Multiple paths

In the case shown in Fig. 69, the order in which tables are denormalized and converted can be of importance, as taking the route airports > regions > countries will provide richer, but more hierarchical, information.

3.2.7 Circular references

Circular references should be detected and avoided.

3.3. Process 3.3.1 Menu access Menu access is illustrated in Fig. 70.

3.3.2 Save current model

The display shown in Fig. 71 occurs if changes have been made, so the denormalization suggestion can be stored in an empty model. 3.3.3 Selection and parameters

The user can select all tables or specific tables to be denormalized, as well as set some parameters to be used during the model denormalization process. This is illustrated by Fig. 72.

3.3.4 Execution The process will include at least the following steps:

- Copy tables from source (normalized) to destination collection (denormalized)

- Select first relationship in source

o Embed in destination model according to chosen parameters

■ If array in parent collection :

· Append array item with type=document

• Copy child structure into document array item, except relationship field

■ If sub-document in child collection :

• Replace relationship field with

· Collection made of copied parent structure

o Create Foreign Key and Foreign Master relationships

o Iterate according to Cascade and Recursion parameters

o Go to next relationship and loop

EXAMPLE 2 Example 2 is illustrated by Figure 73 to 77. Figure 73 shows an example problem with result according the present invention. Hereby, Figure 74 to 77 show magnified portions of Figure 73. First of all, Figure 74 shows the "JSON document to model". Furthermore, Figure 75 shows the "Modeling with traditional ER software", whereas Figure 76 and 77 together show the "Modeling according to present invention" of the example problem. The problem investigated in this example is how to construct and/or edit the portion of JSON document code provided in Figure 74, thereby supported by a GUI. As clear to the skilled person, said portion of code defines a simple JSON document relating to an individual, comprising both top-level information relating to, i.e. the fields with field names "_id", "username", "contact", "access" and "status", as well as nested information, i.e. two nested objects, relating to the field names "contact" and "access", respectively. A result according to the state of the art is given in Figure 75, with an Entity Relationship Diagram (ERD) comprising three collections. This is opposed to the ERD as obtained with an embodiment of the present invention and shown in Figure 76, complemented with a tree diagram shown in Figure 77.

Overall, the present invention allows to reflect the original JSON document structure through structure (less collections, only "true" relationships) (particularly in the ERD), sequence preservation (both in the ERD and the tree diagram), interaction (both in the ERD and the tree diagram), and indentation (reflecting nesting) (particularly in the ERD), while state of the art methods fail to do so. Hence, the result of the present method is not only more true to the original JSON document definition, but also more compact in terms of ERD, allowing for a clearer and overall better overview. Additionally, also the interactive editing of the database schema model is more flexible, with richer interaction thanks to the choice between the ERD and the tree diagram. This is discussed in more detail below.

First, remark how the database schema model constructed with a state of the art method comprises a first collection for said top-level information, as well as a second and third collection for each of said two objects. This is a first problem with a state of the art method, since the separation of information across three separate objects obfuscates the unity of the underlying information. Indeed, there is no point in removing said two objects from their original context. This may mislead a user of the method into thinking that the information relating to "contact" and "access" is somehow "less closely relating" to said individual, as opposed to, e.g., "username", which seems "more closely relating" to the said individual. This difference is a misconception altogether, since "contact", "access" and, e.g., "username" actually belong to the same top-level in the original JSON document. This misconception may lead to severe errors in the construction and editing of databases. Opposed to this, the present invention preserves the original context, with "contact", "access" and "username" all on the same level, both in the ERD illustrated by Fig. 76 and the tree diagram illustrated by Fig. 77.

A second related point concerns the preservation of hierarchy and the related interaction that is enabled by a result according to the present invention. While the fields belonging to the two objects "contact" and "access" are inevitably visible in Fig. 75 (result according to the state of the art), more flexibility is enabled in Fig. 76 (according to present invention), with collapsible items, indicated with a collapse- related icon, i.e. a square containing a "-" sign when the object content is visible (as shown), and a square containing a "+" sign when the object is collapsed (not shown). This has the advantage of allowing a very compact view, displaying all top-level objects but not the details, which enhances usability. Moreover, it creates an additional way for the user to interact with the database schema model, enabling him/her to gain familiarity with a database schema model and/or explain it to others by clicking/touching the collapse-related icon. Additionally, even in non-interactive views (such as printed documentation) the insight of the end user is enhanced, since the ERD of Fig. 76 is complemented by the tree diagram of Fig. 77. This allows a complementary approach, e.g. by showing a collapsed view for the ERD (i.e., without showing the content of objects), complemented with the tree diagram which indeed shows all detail.

Another advantage of the present invention lies in the preservation of sequence. Both the ERD and the tree diagram show the original sequence among field names on every level, as defined in the JSON document. For the result according to the state of the art this sequence is not preserved : as clear from Fig. 75, it can no longer be determined whether, e.g., "contact" was in first, second, third, fourth or fifth position in the list at top level. This obfuscation of sequence leads to incomplete interaction with the database schema model, another problem that is solved by the present invention.

A further advantage of the present invention is the purposeful use of indentation in the ERD. As visible on Fig. 76, fields belonging to an object are indented with respect to the object name, which serves at least two purposes. On the one hand, it serves to easily confine the object's content in a visual manner. On the other hand, it mimics the typical layout of JSON document code as illustrated in Fig. 74. Therefore, a user with prior experience with JSON is likely to have little difficulty in understanding the ERD according to the present invention, and is hence less inclined to make mistakes in his/her interaction with the database schema model. Furthermore, remark the presence of two "relationships" in the database schema model constructed with a state of the art method, both of which seem relationships in the sense of RDBMSes, but in fact concern "nesting relationships", which further obfuscate the unity of the underlying information. Indeed, by adhering to a "flat- table-only" representation, the user constructing database schema models with a state of the art method is faced with a whale of an entity relationship diagram, lacking any sense of overview. This is particularly true if it concerns a database schema model comprising "true" relationships such as foreign key relationships, such as the foreign key relationship linking two collections in Figure 58. In a method according to the prior art, the denormalization of a relational database schema model as described in this document would lead to a dramatically complicated ERD, with a confusing mix of nesting relationships and "true" relationships. Opposed to this, the method according to the present invention only creates relationships when necessary, i.e. none in the case of the present example, and only a limited number in the case of Fig. 58, illustrated e.g. in Fig. 60 and 61. As a result, the user interacting with a database schema model according to the present invention keeps a better overview of the relevant relationships, making less errors on average as a consequence.

EXAMPLE 3

Fig. 78 and 79 show an example relating to referencing and denormalization. Particularly, Fig. 78 shows an example interface that complements the interface of Fig. 72 introduced in Sect. 3.3.3 of Example 1, allowing the user to select all collections (tables) or specific collections (tables) to be denormalized, now with the additional option to choose two-way referencing. The difference between referencing and embedding is as follows. With embedding, when an array is denormalized in parent (and also for that side when "both" is selected), an array is created made of a sub-document with all the fields of the child. Referencing, on the other hand, answers the need to bring only the keys to the parent, and not all the associated fields. That means that on the parent side, there would only be a simple array of foreign keys referencing the primary key of the child. In the corresponding ERD according to the present invention, only an array of simple fields is shown. This is illustrated in Fig. 79.

EXAMPLE 4

Fig. 80 and 81 show an example ERD and associated tree diagram according to an embodiment of the present invention, respectively. Together these figures illustrate the capability of the present invention to deal with an important and useful feature of JSON as applicable to NoSQL and Big Data, namely polymorphism. Polymorphism relates to the ability to deal with evolving and flexible schemas, both at the level of the general document structure, and at the level of the type of a single field. This is known as 'schema combination', and can be represented in JSON Schema with the use of subschemas and keywords: anyOf, allOf, oneOf, not. Fig. 80 and 81 illustrate an ERD and associated tree diagram comprising a field that evolved from being just a string type, to a sub-document, or with the co-existence of both field types. Prior art methods would have a hard time dealing graphically with such subschemas, whereas the representation in Fig. 80 and 81 is clear and self-evident.