Discussion :

[thibouille]

Que pensez-vous de ceci, particulièrement concernant l'héritage?

[fsmrel]

Bonsoir,


Sans la liste des règles de gestion des données, il est impossible de donner un avis.

Toutefois, le MLD comporte une erreur :

La clé primaire de Conduite_Gaz ne peut pas être le couple {id_conduite, id gaz} mais un des deux singletons {id_conduite} ou {id gaz}. Normalement il s’agit de {id_conduite}, auquel cas {id gaz} devient simplement clé alternée (ak).

Même principe évidemment pour l’eau et l’électricité.

[thibouille]

Bonsoir,


Sans la liste des règles de gestion des données, il est impossible de donner un avis.

Toutefois, le MLD comporte une erreur :

La clé primaire de Conduite_Gaz ne peut pas être le couple {id_conduite, id gaz} mais un des deux singletons {id_conduite} ou {id gaz}. Normalement il s’agit de {id_conduite}, auquel cas {id gaz} devient simplement clé alternée (ak).

Même principe évidemment pour l’eau et l’électricité.

Ne serait-ce pas plutôt id_gaz étant donné que id_conduite est la clé primaire de la table "mère" Conduite ?

[fsmrel]

Ne serait-ce pas plutôt id_gaz étant donné que id_conduite est la clé primaire de la table "mère" Conduite ?

Dans votre message Quel système de clé utiliser? vous décrivez la conduite de gaz comme étant fille de sa maman, la conduite. En réalité, au plan sémantique, une conduite de gaz est à une conduite ce qu’une ellipse est à une figure plane et je ne sache pas qu’une figure plane soit sa propre fille quand elle est considérée comme ellipse. Bref, une conduite, qu’elle soit de gaz ou d’eau est une conduite.
Par ailleurs, au niveau relationnel, deux tables comme Conduite et Conduite_Gaz peuvent avoir même clé primaire, sachant que l’une est en même temps clé étrangère : le Modèle Relationnel de Données a toujours considéré les concepts comme libres de toute contrainte ès matière (d’autant plus que le concept de clé primaire est désormais conservé à titre purement historique).
Personnellement, au niveau SQL (où l’on continue à utiliser le concept de clé primaire), j’ai tendance à considérer id_conduite comme clé primaire de Conduite_Gaz et id_gaz comme clé alternative : sous réserve bien entendu de justifier l’existence id_gaz, car si cet attribut n’aucune valeur ajoutée, il doit disparaître, au nom du rasoir d’Ockham (ne rien conserver d'inutile). Maintenant, si son existence est indispensable, personne ne vous dira rien si vous en faites une clé primaire (id_conduite devenant alors clé alternée).

[thibouille]

mm j'aurais aimé lire ou entendre ce genre d'explications étant aux études (oui c'est un compliment )
Et ça me paraît évidemment logique maintenant que vous soulevez la chose.
Les clé alternées sont donc de trop comme vous le faites également remarquer.

Je vais me limiter récupérer une clé "primaire" identique à celle de Conduite.
Maintenant comment indiquer la chose sous Power AMC, je ne sais pas, je suppose qu'une "bête" référence dessus fera l'affaire, comme ci-dessous:

Quoi qu'il en soit, un grand merci

[fsmrel]

Je vais me limiter récupérer une clé "primaire" identique à celle de Conduite.
Maintenant comment indiquer la chose sous Power AMC, je ne sais pas, je suppose qu'une "bête" référence dessus fera l'affaire...

Le MLD présenté a l’air tout à fait correct sur ce point.

Maintenant, il existe deux chemins collatéraux pour accéder aux instances de Tconduite à partir d'une instance de Tcompany :

— Un accès direct.
— Un accès via Tusers.

Une question à 34 centimes d’heuro la minute :

Les valeurs de Tcompany prises par l’attribut id_company de la table Tconduite peuvent elles être différentes de celles que l’on peut obtenir (transitivement) en passant par l’autre chemin ?

j'aurais aimé lire ou entendre ce genre d'explications étant aux études...

Peut-être est-il encore temps de les instruire ? ...

[thibouille]

Le MLD présenté a l’air tout à fait correct sur ce point.

Vous ne pouvez pas savoir à quel point ce commentaire me rempli de joie

Maintenant, il existe deux chemins collatéraux pour accéder aux instances de Tconduite à partir d'une instance de Tcompany :

— Un accès direct.
— Un accès via Tusers.

Une question à 34 centimes d’heuro la minute :

Les valeurs de Tcompany prises par l’attribut id_company de la table Tconduite peuvent elles être différentes de celles que l’on peut obtenir (transitivement) en passant par l’autre chemin ?

Tout dépend de la manière dont je traite les Tusers. Si un User peut être supprimé après qu'il ait ajouté une conduite, alors oui il faut absolument garder l'info quelque part qu'un conduite est gérée par une société en particulier.

Mais je pourrais supprimer la relation entre Tusers et TConduite. Je prends bien sûr l'info du User qui a ajouté la Conduite dans la BD mais je doute que cela soit tellement important. Ou alors garder un log complet des modifs, ça aurait plus de sens.

Si je veux autoriser un User à modifier une conduite il suffit de comparer id_company de Tuser et id_comany de TCompany et vérifier qu'ils concordent (ainsi que vérifier idTypeUser bien sûr pour être sûr qu'il s'agit bien d'un utilisateur qui possède de tels droits).

Ce sera plus clair sans cette relation superflue je pense.

[fsmrel]

Si je veux autoriser un User à modifier une conduite il suffit de comparer id_company de Tuser et id_comany de TCompany et vérifier qu'ils concordent.

Ne s'agit-il pas plutôt de comparer l'attribut id_company de Tuser et l'attribut id_company de Tconduite ?

[thibouille]

Ne s'agit-il pas plutôt de comparer l'attribut id_company de Tuser et l'attribut id_company de Tconduite ?

Oups, oui bien évidemment! Mea culpa.