Wakanda Datastore Model

Built into Wakanda is a data management system that lets you easily manipulate information. The Wakanda datastore model uses a datastore class paradigm rather than a relational database methodology. Instead of representing information as tables, records, and fields, Wakanda uses a new approach that more accurately maps data to real-world items and concepts.


Relational Databases, Normalization vs. Denormalization

Relational databases are an efficient way to store and retrieve information. They achieve efficiency by storing information in lists called tables and linking tables together through values in specific fields. The highest level of efficiency is achieved by following a discipline called normalization in which information only appears in one location but is referenced wherever needed. This approach removes the need to update data in multiple places whenever a value is changed. However, normalization can add complexity to the development process and often results in a relational structure that obscures the real world concepts of the information it contains.


Take for example the following partial relational database structure:


This structure describes Invoices, each of which can have many InvoiceItems. Each InvoiceItem refers to one Part that holds the name and individual cost. An Invoice total might be calculated by summing the product of InvoiceItems.Item_Quantity and Parts.Cost for all InvoiceItems for a given Invoice. Of course, each time the Invoice total is calculated, the relationships between all three tables must be understood and traversed correctly. This approach adds complexity to the development process. Often database designers will avoid this kind of complexity by incorporating some degree of “denormalization” in their data’s structure. For example, in the above structure, one might be tempted to add a Cost field to InvoiceItems copied from the corresponding part or an InvoiceTotal field to the Invoices table where the sum of all its InvoiceItems is stored. Adding these two fields would certainly be more convenient and in some cases increase performance to one portion of the development process, but increase complexity in another. With a Cost field in InvoiceItems or an InvoiceTotal field in Invoices, developers must take care to recalculate and store these fields whenever a cost or quantity is changed. This perpetual battle between the need for efficiency via normalization and the need for convenience via denormalization is one of the issues that the Wakanda datastore model addresses.

SQL Queries Return Row Sets not Records

Another struggle in relational databases is the difference between the records stored in tables and the rows returned by a query. Take for example the following query used with the relational structure above:

SELECT i.Post_Date, p.Name, p.Cost, ii.Item_Quantity, p.Cost * ii.Item_Quantity as Extended From InvoiceItems ii

Join Parts p on p.ID = ii.Part_ID Join Invoices i on i.ID = ii.Invoice_ID

Where i.Post_Date between ‘1/1/10’ and ‘12/31/10’

The result of this query would be a list of post dates, part names, costs, quantities and extended costs for all invoice items on all invoices in the year 2010. Notice that the resulting rows are a collection of columns from all three tables and include a calculation. Each row in the resulting row set is neither an invoice, nor a part, nor an invoice item. In addition, each row is independent from the data where it is stored and does not “remember” to which record(s) it belongs.


Enter the Datastore Model Paradigm

Imagine the ability to denormalize a relational structure yet not affect efficiency. Imagine describing everything about the business objects in your application in such a way that using the data becomes simple and straightforward and removes the need for a complete understanding of the relational structure. Imagine that the result of queries is an object that “knows” where it is stored and its relationship to other objects. These are some of the goals of the Wakanda datastore model.

In the Wakanda datastore model, a single datastore class can incorporate all the elements that make up a traditional relational database table but can also include calculated values, values from related parent entities, and direct references to related entities and entity collections.

When a Wakanda datastore model is complete, a query returns a list of entities called an Entity Collection, which fulfills the role of a SQL query’s row set. The difference is that each entity “knows” where it belongs in the data model and “understands” its relationships to all other entities. This means that a developer does not need to explain in a query how to relate the various pieces of information nor in an update how to write modified values back to the relational structure.


So, in Wakanda, the structure can become:


Notice that each datastore class (Invoice, InvoiceItem, and Part) has been “filled out” with every logical property and that each one reflects a complete picture of the entity and all its related entities. Invoice now contains an attribute (invoiceItems) that represents all the related InvoiceItems. InvoiceItem now contains an attribute (itemPart) that represents the corresponding part as well as all the attributes from the parent Part entity along with a calculated attribute (extended) that determines the extended cost.

Now, for example, how do you get all the invoice items for the invoice ID = 1?

Just use the object notation:


That is all!

As a result, you will have a JavaScript Object with all the information available in the dataclass InvoiceItem for the Invoice ID= 1!

Now, how do I get the cost of all these invoiceItems (which is located in the dataclass Part)?


The Wakanda server will follow the objects and it will return all the cost information of the InvoiceItems !

Are you ready to say goodbye to complex joins and queries in SQL?


Ok, that is great for the Wakanda database, but, what happens if my database is MySQL or MSSQL or Oracle?

You will use the same object notation and the Wakanda server will do the work for you. That is right! You will get the best of all worlds.


Last but not least … Singular and Plural

In a traditional database, a table has only one name. Many times developers name a table in the plural. For example, a typical name for a table might be “Cities” or “Companies”. Later during development, it often becomes necessary to refer to a single record in a table, particularly in association with relationships between tables. Sometimes developers name tables in the singular. For example, “City” or “Company” but then later it becomes necessary to refer to multiple records by some name. Wakanda addresses this need by providing a singular name for each datastore class and a plural name for entity collections of that class.

For example, a class might be named “City” or “Company” while a collection of entities in those classes would be “Cities” or “Companies”. This duality helps clarify the relationships between datastore classes and provides a more natural set of expressions when referencing an entity and an entity collection. In the above diagram (Fig 2) note the itemInvoice attribute in the InvoiceItem class. This attribute is of type “Invoice” (note the singular) and makes it clear that it references a single entity of the Invoice class.


Need help understanding these concepts?

If you have any doubts, you can book a one-on-one time with me here.

In the video call, I will answer all your questions and help you with all the details from this post

PS. booking takes less than 1 minute!