Classes to Tables

BLOG VIII.

In this post, i will talk about how to convert class designs into a database tables, we can call this process as Unified Modeling Language, as i mentioned in my last blog https://wordpress.com/read/feeds/99170391/posts/2428155733. So UML helps us to sketch up a little diagrams that describe how elements of a system are connected, and in UML, classes are tables.

The way to do this is not always simple as just naming the class or table, because name of classes has to be neither too specific nor too general, first letter should be uppercase, singular noun and if you want to use multiple words you have to start with an uppercase every time you start with another word such as EatLunch. Let’s see an example:

if you have a UML class for all things that you might eat in the morning, you could call it  Cereal .

If that is all you eat in the morning, then it could be a fine name.

But if you start having poached eggs for breakfast and put that in the  Cereal  table, it could lead to some scrambled logic about what should be put in this table. 

On the other hand, if you choose a name that is too general, like  Food , and if there is already another table named  Lunch , then your schema is confused. 

Somehow the word  Breakfast  comes to mind as the right name choice.

Now let’s talk about diagram, it is a box that features a word, at the top of the box. This is the name of the class. There is a line and below the line, there is a list of attributes. In the  Restaurant  class, the attributes are things that we want to collect about each restaurant. If we were to turn the class diagram into a table, the attributes become the column titles:

We use the tabular scheme for relational database, and for non-relational database: we do not use the tabular schema of rows and columns found in most traditional database systems. Instead, non-relational databases use a storage model that is optimized for the specific requirements of the type of data being stored. For example, data may be stored as simple key/value pairs, as JSON documents, or as a graph consisting of edges and vertices.

• Document data store: manages a set of named string fields and object data values in an entity referred to as a document.

• Columnar data store: organizes data into columns and rows. In its simplest form, a column-family data store can appear very similar to a relational database, at least conceptually.

• Key/Value data store: associates each data value with a unique key, and the key/value store uses this key to store the data by using an appropriate hashing function.

• Graph data store: manages two types of information, nodes and edges. Nodes represent entities, and edges specify the relationships between these entities.

For more information you can visit to this link:

https://docs.microsoft.com/en-us/azure/architecture/data-guide/big-data/non-relational-data