Classes/Tables – Mapping/Relations

When a developer has a complex software engineering case, or a big project with different kinds of teams, it is optimal to make the design pattern of the software which will be developed. There are many kinds of tools for making a great software design representation, and that is because of the impact that it can make to a project when these kinds of tools are being used. The main approach of these designs is that classes can be instantiated as a relational model in a concept which many individuals can understand.

For instance, the UML is one of the most used tools in designing classes and relations of a software in the process of development. The main purpose of them is to adequate the classes into databases tables. The relations between these classes make a big difference in the understanding of the concept because of the big picture that one can analyze from the designs.

The translation of class designs to database tables starts with the representation of a class as an entity of a database, from which the relations are made and communication between entities happen. This translation or conversion into tables databases require a certain level of logic to resolve the relations and order between the classes or entities in the databases. There are some particular steps, or kind of a guide to have success when transforming classes designs into tables databases which are the following.

Steps of mapping

1. Mapping stable classes to tables
2. Mapping attributes of dependency from a stable class to the relevant column
3. Mapping dependencies and preliminary attributes of unstable classes to the columns generated in the tables out if reference stable class
4. Mapping main class attribute inheriting from another class to a column equivalent to the main class

The steps of successfully mapping a table is a great guide and tool to complement with the UML designs for a successful and efficient software development. If you want to have a more in-depth view of each step you can go here.

The flow of the transformation states that first, a class diagram must be made. This class diagram, based in UML or other tool, includes the main classes, inheritance of them, attributes divided by classes attributes and primitive attributes, and all the other relations to make the diagram easy to understand and in order.

Then, the relational database is made, and this table made by columns, has identifiers for each column. Primary and foreign keys are assigned, dependencies are made with these keys and the whole diagrams is converted into tables of organized columns and keys for relations. But what if a non-relational database is being made?

Non-relational Databases

As the name says. There are no relations between tables in these types of databases, so the class diagrams need to adapt differently into these other types of databases. The solution to this case is to make NoSQL Databases, these are stored in many different ways so the non-relational model can be achieved.

• Document databases: Structured like a document, data is stored with an identifying key.
• Key-value stores: Segment of data stored according to a key.
• Graph stores: Focused on storing data networks information.

You can rise up from anything.

You can completely recreate yourself.

Nothing is permanent.