Does any one represent the storage requirements of the DB?

The squares are entities (tables) and the diamonds are relations. Therefore, in both cases the design of the database is the same . As a reference:

Source: association_basics.html # the-has-many-through-association

Or also:

Source: Loopback: HasManyThrough-relations

So both diagrams are equivalent in database . Both model with three entities: medico , paciente and consulta .

At its most basic level

doctor

id_medico | nombre       | especialidad
----------------------------------
 1        | Dr Seisdedos | Urología
 2        | Dr Espinilla | Dermatología

I only really put the specialty because it seemed fun, you can skip that field.

patient

 id_paciente | nombre    
-------------------------
 1           | Juan
 2           | María

query

 id_consulta | id_medico | id_paciente
 -------------------------------------
     1       |     1     |      1
     2       |     2     |      1
     3       |     2     |      2
     4       |     1     |      2

For purposes of the database, the query is an entity where it is clear that a doctor and a patient met at a moment of time. It can have extra attributes such as time and date, place, amount paid, duration, etc.

The query table has a foreign key in id_medico referencing the table medico . And it has a foreign key in id_paciente referencing the patient table. Then:

• see belongsTo doctor (via medical_id)
• medical hasMany query (via medical_id)
• query belongsTo patient (via patient_id)
• patient hasMany query (via patient_id)

And even

• patient ManytoMany doctor (via table query)

For what matters:

In a flow diagram, UML or whatever you want, you can say that the process or action that connects the entities or actors is semantically different. The database does not care in the least. They are foreign keys and hasOne, hasMany, belongsTo, manyToOne, oneToMany, ManyToMany etc etc.

Indicate if both are equivalent to model this problem

On reflection, they are not equivalent. Diagram A indicates that every inquiry leads to attention. This is not true, because the doctor may not be available, the patient may not show up or the consultation may be canceled.

Here is a bit of semantics involved. If it is considered that a query is scheduled in advance and may not be carried out if the process "attends" the consultation entity continues to exist, only that it has a status indicating that it was not carried out.

Alternative B is more faithful to the model in BBDD, mainly because it shows explicitly that there is no direct relationship between doctor and patient except through the entity consulted.

It also shows that the consultation only takes place if the doctor gives it and the patient attends. However, diagram B is not a ternary relationship. It is a conversion of a ternary into two binaries.