Information modeling is the process of describing or building a domain model in a form or format that, on the one hand, is easily perceived by a person, and, on the other hand, can easily be transformed into a set of information storage elements, software components, and other components of application software . Most often, the term information modeling can be seen in the context of the description of the process of building ER diagrams or UML diagrams .
Domain Information Modeling
In software, objects are in certain relationships with each other. There are 3 types of relationships: association , generalization, and aggregation .
Types of relationships between objects
- Association - indicates the presence of a logical connection between objects. Each association is associated with the concept of power , which can take one of the following values: 1: 1 , 1: M and M: N. Power refers to the number of objects of a certain type that will participate in communication.
- Generalization (from general to particular) - this type of relationship is implemented as the relationship of one parent entity class with several child entity classes.
- Aggregation (integer-part) is the relationship of one parent entity class with several child entity classes. In this case, the relationship can be described by relations of two types:
- not necessarily identifying relationships;
- optionally non-identifying bonds.
Detailed Description
1: 1
In a one-to-one relationship, each block of entity A can be associated with one block of entity B.
Consider such entities - Student and Gradebook .
At each moment of time, one student has one record book, at the same time, the same test book belongs to one student.
To represent the 1: 1 relationship , two tables are created in the relational database schema for each of the objects in the domain and the primary key of one of them (optionally) is added to the list of attributes of another object.
1: M
If you have two entities ask yourself:
1) How many objects from B can belong to object A?
2) How many objects from A can relate to an object from B?
If the answer to the first question is many , and the second one (or maybe none), then you are dealing with a one-to-many relationship.
Take as an example the essence of the Department and the Teacher . At each point in time, the department contains many teachers, but each teacher is subordinate to only one department.
To implement the 1: M connection in the relational database scheme, the primary key of the object from the “1” side is added to the list of attributes of the object from the “M” side.
M: N
A many-to-many relationship is a relationship in which multiple records from one table (A) can correspond to multiple records from another (B).
Let us again take as an example the essence of the Student and the essence of Discipline . Each student studies many disciplines, at the same time many students study the same discipline.
To implement the M: N connection in the relational database scheme, it is necessary to create an additional table, the primary key of which will be composite and be a combination of the primary keys of the objects involved in the communication.
Generalization (is-a)
A generalization type relationship is implemented as the relationship of one parent entity class with several child entity classes. It is used if the component of the object belongs to the main object as a class to a subclass.
When using Generics, the primary key of the parent is transferred to the primary key of the child objects. It is curious to note that the Generalization implements the so-called inheritance hierarchy. In this case, the parent object contains attributes that are common to all child objects.
Aggregation (part of)
During aggregation, the parent object (or aggregate) is associated with several child objects (or components). The components of the parent object reference the aggregate through a foreign key that is not part of the primary key. At the same time, aggregate components can exist outside the aggregate (null values of the foreign key are allowed) and may NOT exist outside the aggregate (null values of the foreign key are not allowed).
To represent aggregation, it is necessary to create one table for a top-level object and one table for lower-level objects. The primary key of a top-level object is added as an attribute to all lower-level objects (it becomes a foreign key for lower-level objects).
Database Normalization
Normal forms are recommendations for designing databases. You are not required to adhere to all five normal forms when designing databases. A very small number of databases follow all five normal forms provided in the relational data model. Databases are usually normalized to the second or third normal form. The fourth and fifth forms are rarely used.
First Normal Form
The first normal form says that a database table is a representation of the essence of your system that you are creating. Examples of entities: orders, customers, ordering tickets, hotel, product, etc. Each entry in the database represents one entity instance. For example, in a product table, each entry represents a single product.
- Primary key
Rule: each table has a primary key consisting of the smallest possible number of fields.
- Atomicity
Rule: fields do not have duplicates in each record and each field contains only one value.
- The order of the entries should not matter.
Second Normal Form
In order for the database to be normalized according to the second normal form, it must be normalized according to the first normal form. The second normal form is associated with data redundancy.
- Data redundancy
Rule: fields with a non-primary key must not be dependent on the primary key.
This means that you should only store data in the table that is directly related to it and not related to another entity. Following the second normal form is the question of finding data that is often duplicated in table entries and which may belong to another entity.
See also
- Relational database
- Relations between classes (OOP)
- Relational Database Design Guide
Sources
Types of Table Relationships . Date of treatment May 22, 2017.