4. Conceptual database model

The conceptual model is a reflection of the subject area for which the database is being developed. Without going into theory, we note that this is a kind of diagram with the accepted notation of elements. So, all objects denoting things are denoted as a rectangle. The attributes that characterize the object are in the form of an oval, and the connections between the objects are rhombuses. The coupling power is indicated by arrows (in the direction where the power is equal to many, the double arrow, and from the side where it is equal to one, it is single).

Let's take an online store as an example. The store has products that are supplied by suppliers and buyers are bought. This can be represented by three objects and two links:



But how does the supplier deliver the goods? He makes the delivery, which is confirmed by the document. Similarly, the buyer makes a purchase, which can also be confirmed by a document. Thus, the delivery and purchase can be considered as independent objects:



Now we have five objects and four connections. Two one-to-many connections (one supplier can make several deliveries, but each delivery is made only by one supplier, the same goes for the Buyer-Purchase connection) and two many-to-many connections (each delivery can contain several goods, and one the same product may be contained in several deliveries, similarly for communication Purchase - Goods).

But the many-to-many links are not allowed in the relational model, so each such link must be replaced by two one-to-many links. This is done by adding an intermediate object:



Thus, we have two more objects - a purchase log and a supply log, with one-to-many connections (one supply log can include several deliveries, but each supply can be included in only one magazine, similarly for the others).

Each object of our store has its own attributes:



In fact, we created a conceptual model of the store database, or rather parts of it, because the store still has employees, warehouses, goods delivery, etc.

In general, if the subject area is extensive, then it is useful to split it into several local subject areas (our conceptual model reflects the local subject area). The volume of the local area is chosen so that it includes no more than 6-7 objects. After creating models of each selected subject area, local conceptual models are combined into one general, as a rule, rather complicated scheme.

For our training purposes, we will limit ourselves to the model created. Now our conceptual model should be transformed into a relational data model, i.e. to tables, fields, keys, etc. already known to us This we will do in the next lesson.