Classes to tables

In the previous entries we talked about how useful can UML be, this time we are going to focus in something a little different, we are focusing on database systems and how does we can represent it using tables.

When using a database system there is a situatin that happens everytime, and that is that variables and information shared in the system are not easy to read or easy to get, the comunication between the system and what does the system storages are information needed by the users, hard to get without using an organization system.

In order to map the objects in the system first you must start with the data atribute of the class, it is important to define how manny attributes of the system will be mapped, it can be from zero to any number.

Some of these elements in the system are used just for temporal calculations and are actually not necesarry to have on the database, this allows the user to decide wheter or not to include those elements in the tables.

Tables
This a picture of a table by Jurgen, L

The simples way to map elements of the sistem is to assign each attribute with a single column, in this way the data model and the physical model are very similar, the only diference is the key dependendiec between the two models.

Inheritance

Inheritance works as a tool when you are trying to organize a table into different inherited atributes of the system, basically the system must share a single aspect between the objects.

This a picture of an example of a inheritance table

In order to implement inheritance in the system there are three diferent ways in which a diagram can be represented by using inheritance division whose are:

Using one data entity for an entire class hierarchy

In this way you describe a single class into one diagram that contains all the atributes of the element, with the respective primary key, this because with this diagram all the information must be revealed in one table.

This is a picture of a one data table

Using one data entity per concrete class

With this way you can describe the data entity with the inherited atributed needed for the entity in order to get completely functional, the good part about this method is that all the infor is storaged in a single table, the problem is that if the data is modified all the children must be modified as well.

This is a picture of the diagram distributed in the inherited atributes

Using one data entity per class

In this way you create a table per class, every table includes a foreign key that is related to the superclass, this is a good option because it describes object oriented systems very well, and when you modify a class you don’t have to modify any other class, the only problem is that there are way too many tables.

This a picture of a model with three diferent classes

My experience

As you see when talking about a big project it is almost 100% of probability you should shot how does the data of the system comunicates, and how are the classes stuctured, it has happened to me in previous projects and with this type of diagrams the system becames easier to understand not only to the developerts but to every reader of the system, a must try way to describe how is the structure of the system.

References

Deja un comentario