Relational Notation explained for RDBMS

Relational notation is a way of representing relationships between entities in a data model using mathematical symbols and operators. The purpose of relational notation during the data modeling process is to provide a clear and precise way of describing the relationships between entities, which helps to ensure that the resulting database is well-designed and can effectively meet the needs of the users. In a data model, entities represent objects, concepts, or events that are relevant to the organization or system being modeled. Relationships between entities describe how the entities are related to each other. For example, in a university data model, the entities might include students, courses, and instructors, and the relationships might include "enrolls in", "teaches", and "prerequisite for".
Relational notation uses mathematical symbols and operators such as sets, Cartesian products, and joins to represent the relationships between entities. For example, the notation "student ∩ enrolls in ∩ course" represents the set of all students who are currently enrolled in at least one course.
Using relational notation during the data modeling process helps to ensure that the relationships between entities are clearly defined and can be implemented effectively in a relational database management system. This can help to prevent data inconsistencies and improve the accuracy and efficiency of data retrieval and analysis.

1. CD: This is the entity
2. Items in the parentheses: These are the attributes of the CD entity

For the scaling of values the distances should be relevant and not absolute.
One of the reasons you use data mining is to figure out targeting.

Relational notation is a process of transforming an Entity Relationship Diagram into a more friendly and usable type of diagram that is easily readable. This can be done by taking the names of each table and its attributes and ordering them in a specific order. You always start with the primary key(s), which are commonly notated with the underscore, then all other attributes are added. The only rule for attributes is if it happens to be a foreign key it needs to be underscored with a dotted line.

The final step in the database modeling evolution is applications and how they affect a database model design. An application is a computer program with a user-friendly interface. The user interface could be an Android App communicating with Firebase or a web client which uses HTML, CSS and JavaScript to communicate with MySQL. The end-users use interfaces or screens to access data in a database. Different types of applications use a database in different ways and this can affect how a database model should be designed. Before you set off to figure out a design strategy, you must have a general idea of the kind of applications your database will serve. Different types of database models underpin different types of applications and you must understand where different types of database models apply.
It is essential to understand that a well-organized design process is critical to success. In addition, a goal to drive the design process is equally as important as the design itself. There is no sense designing or even building an application and its corresponding database unless it is clear exactly what is you are doing to design.