Discussion :

[keaton7]

Bonjour,

Ma question concerne l'organisation des informations dans le cadre de l'optimisation/normalisation du stockage des données.

Je me demande laquelle de ces 2 propositions est la plus intéressante dans cet objectif (imaginons cet exemple multiplie par 10) :

1ère proposition :

mesElements(idElement,libelleElement,idTypeElement)
typeElement(idTypeElement,libelleTypeElement)

2ème proposition :

mesElements(idElement,libelleElement)
typeElement(idTypeElement,libelleTypeElement)
correspondanceElementsTypes(idElement,idTypeElement)

NB : Il est vrai qu'a l'école, on s'accorde n'apprendre que la deuxième solution comme optimisée mais qu'en est-il en production ?

D'avance merci.


Matt

[Snipah]

Salut,
Tout dépend des règles, ce que tu n'as pas précisé.
Si un élément ne peut être que d'un type, j'opterai pour la première solution ou l'élément référence directement un type.
Si ton element peut correspondre à plusieurs types, j'opterai pour la seconde avec la table d'association.

[keaton7]

Dans ma tache de developpement actuelle, les exemples suivants se presentent, parmis d'autres bien sur :

no 1 :
Une table ville et une table departmement (on imagine bien l'association possible)

no 2:
Une table départements et une table régions (on imagine bien l'association possible)

no 3 :
Une table appartement et une table type avec : residence etudiante, personnes agees, ...

La subtilité que je ne comprend pas dans ton explication, c'est que si l'élément ne peut être que d'un type, ce n'est même pas la peine de le spécifier dans la bdd ... ?

[Chtulus]

Bonjour,

Ce n'est pas ce que spécifié Snipah....

Un peu de lecture vous aiderez à mieux comprendre !

[keaton7]

Merise fait l'apologie de la 2eme solution. J'ai suivi un peu en cours (un peu ).

Snipah, j'avais mal compris, la remarque de Chtulus m'a force a relire consciencieusement ... autant pour moi. Oui, un element ne peut etre QUE d'un type .

Une ville ne peut (en principe) pas appartenir a plusieurs departements, etc ...

Pourtant en étudiant Merise (puisqu'on en parle), j'avais bien l'impression que même dans ce cas, la table d'association était préférable.

Ma question d'entrée est donc toujours valable "qu'en est-il en production ?" .

Snipah y a apporte sa reponse, d'autres avis seraient les bienvenus, qu'en penses-tu Chtulus ? ...

[Chtulus]

Et bien pour ma part je dirais :

Ville--1,1---------Est située dans---------0,n--Département

Mais on peut suivant le besoin avoir (Mais j'aime moins ^^):

Ville--0,1---------Regrouper---------0,n--Département

[keaton7]

Donc tu preconises la meme chose que Snipah si j'ai bien compris.

[CinePhil]

Il faut faire au plus simple !

Cas 1 :
Entité1 -0,n----Associer----x,1- Entité2

==> les tables :
Entité1(E1_Id, ....)
Entité2(E2_Id, E2_IdEntité1, ....)

Cas 2 :
Entité1 -0,n----Associer----0,n- Entité2

==> les tables :
Entité1(E1_Id, ....)
Entité2(E2_Id, ....)
Associer(A_IdEntité1, A_IdEntité2, ...)

C'est ce que disent tous les cours Merise que j'ai vus jusqu'à présent.

Pour reprendre vos exemples :

no 1 :
Une table ville et une table departmement (on imagine bien l'association possible)

no 2:
Une table départements et une table régions (on imagine bien l'association possible)

On est dans le cas 1 :
Ville -1,1----Situer----1,n- Département -1,1----Inclure----1,n- Région

Regions(R_Id, R_Nom)
Departements(D_Id, D_Numero, D_Nom, D_IdRegion)
Villes(V_Id, V_Nom, V_IdDepartement)

no 3 :
Une table appartement et une table type avec : residence etudiante, personnes agees, ...

Si un appartement ne peut-être que d'un seul type, on est de nouveau dans le cas 1.
Si un appartement peut-être de plusieurs types, alors on est dans le cas 2 et on a l'association :
TypeAppartement -0,n----Typer----1,n- Appartement

TypesAppartements(TA_Id, TA_Libelle, ...)
Appartements (A_Id, A_Adresse, ...)
Typer(Ty_IdAppartement, Ty_IdTypeAppartement, ...)

[keaton7]

Ok, merci. Je comprend bien l'enjeu. Et la nécessite de relire mes cours a l'occasion (c'est pas bien méchant a mon souvenir ^^)

En conclusion (avec des mots) :
un et un seul type -> on stocke l'id directement
plusieurs types possibles -> on cree une table intermediaire pour l'association

Merci pour votre interet.

A bientot.

[CinePhil]

En conclusion (avec des mots) :
un et un seul type -> on stocke l'id directement
plusieurs types possibles -> on cree une table intermediaire pour l'association

Je dirais plutôt :
- Une des cardinalités maxi à 1 ==> Clé étrangère du côté de la cardinalité max à 1
- Les deux cardinalités maxi à n ==> Table associative dont la clé primaire est formée des clés étrangères provenant des clés primaires des deux tables entrant en jeu dans l'association.

Idem pour les associations n-aires.

[keaton7]

ok, merci bien

(Sacre edition du post precedent aussi, merci aussi pour avoir pris le temps pour ca )