Discussion :

[jejeman]

Bonjour,
J'aurai aimé votre avis sur une question de conception... J'ai bien ma petite idée, mais je pense qu'un autre avis serait pas mal...

J'ai une table PROFIL(id, nom, prenom, age) et mon profil peut-être soit acheteur, soit vendeur. J'ai donc 2 tables :
- PROFIL_VENDEUR(id, prix_moyen, mode_paiement)
- PROFIL_ACHETEUR(id, habitudes, points)

Du coup j'ai une relation 1-1 entre PROFIL_VENDEUR et PROFIL : 1 PROFIL_VENDEUR peut avoir 1 et 1 seul PROFIL
J'ai la même relation entre PROFIL_ACHETEUR et PROFIL.

Par contre à l'inverse, j'ai une relation 0-1 entre PROFIL et mes PROFIL_VENDEUR et PROFIL_ACHETEUR : 1 PROFIL peut avoir soit un PROFIL_VENDEUR, soit un PROFIL_ACHETEUR. Dans mon cas c'est exclusif, on est soit vendeur, soit acheteur !

Du coup il va ma falloir des clés étrangères pour lier tous ça... Et voici ma question :
1- Est-ce que je mets une clé PROFIL dans mes tables vendeur et acheteur ?
2- Est-ce que je mets 2 clés, une vendeur et une acheteur, dans ma table PROFIL ?

Merci de votre avis.

[aieeeuuuuu]

Bonjour,

Puisque visiblement vous en êtes à la conception, une première remarque : Votre table PROFIL ne respecte pas la première forme normale : la colonne age n'est pas constante dans le temps : dans un an vos données seront incorrectes ! stockez plutôt une date de naissance, vous pourrez facilement en déduire l'age.

Pour vos questions maintenant

1- Est-ce que je mets une clé PROFIL dans mes tables vendeur et acheteur ?

Oui. elles seront pas ailleurs la clef primaire de ces tables.

2- Est-ce que je mets 2 clés, une vendeur et une acheteur, dans ma table PROFIL ?

Non, une unique colonne ID_PROFIL de la table mère servira de clef primaire pour les tables filles, et vous gérez votre exclusion par le biais de déclencheurs

Pour plus de détails : http://sqlpro.developpez.com/cours/m...n/heritage/#L5

[jejeman]

Merci de votre réponse.
Pour l'age je savais, mais c'était pour donner l'idée du smilblick...
Donc c'est ce que je pensais, il faut prendre la solution 1.
Merci beaucoup !

[fsmrel]

Bonsoir,

Bonjour,
Puisque visiblement vous en êtes à la conception, une première remarque : Votre table PROFIL ne respecte pas la première forme normale : la colonne age n'est pas constante dans le temps : dans un an vos données seront incorrectes ! stockez plutôt une date de naissance, vous pourrez facilement en déduire l'age.

Le conseil que vous donnez de préférer une colonne de type Date plutôt que de type Âge est le bon. En revanche, la première forme normale est parfaitement étrangère à cette histoire. Prenons la définition qui en est donnée par C.J. Date — la référence mondiale incontestée sur ce sujet — dans Database Design & Relational Theory, je cite et traduis :

Définition : Soit une relation r ayant pour attributs A1, ..., An, respectivement de type T1, ..., Tn. Alors r est en première forme normale (1NF) si et seulement si pour tous les tuples t appartenant à r, la valeur de l’attribut Ai dans t est du type Ti (i = 1, ..., n).

En d’autres termes, par définition chaque relation est en 1NF ! Pour dire les choses autrement, la 1NF signifie seulement que chaque tuple de la relation contient exactement une valeur du type approprié, pour chaque attribut.

Maintenant, une valeur de table SQL n’est pas forcément une relation et pour en être une et donc respecter la 1NF, elle doit respecter les contraintes suivantes :

1. Pas d’ordre de rangement quel qu’il soit pour les lignes de la table.
2. Pas d’ordre de rangement quel qu’il soit pour les colonnes de la table.
3. Pas de lignes en double.
4. Chaque intersection d’une ligne et d’une colonne contient exactement une valeur du type applicable, et rien d’autre.
5. Toutes les colonnes sont régulières.

En particulier, le point 4 signifie qu’une colonne donnée ne peut pas contenir une liste ou un tableau de valeurs, c'est-à-dire un groupe répétitif de valeurs. De même, NULL n’est pas une valeur et provoque donc un viol de la 1NF.

Pour sa part, le point 5 signifie que chaque colonne a un nom et ce nom est unique dans l’en-tête de la table (sont évidemment visés les résultats des requêtes SQL, au nom du principe de fermeture : le mariage d’une table et d’une table est aussi une table et pas un machin ne ressemblant ni à son père ni à sa mère). Par ailleurs, une table ne peut pas héberger de colonne cachée, du genre Object ID, timestamp, etc.


Une dernière remarque :

Au niveau sémantique (MCD Merise, diagramme de classes UML), la structure présentée par Jejeman est caractéristique de la généralisation/spécialisation :


MCD Merise (avec Power AMC)




MLD dérivé




Avec MySQL Workbench (gratuit, pourvu que ça dure...)

[aieeeuuuuu]

Merci fsmrel pour ces précisions

J'ai en effet trop tendance à croire ce que l'on raconte ci et là plutot que de me fier aux fondamentaux dont la qualité n'est plus à démontrer.

Database Design & Relational Theory

278 pages, pfiou... quand je vois le temps qu'il m'a fallu pour comprendre le titre

[fsmrel]

Bonjour aieeeuuuuu,


Il est un fait que ce qui est écrit dans Wiki est affligeant, mais c’est Wiki. Quant au 2e lien, je n’ai pas pu l’ouvrir, mais je me doute que ça ne doit pas être triste là non plus. Merci pour les fondamentaux, lesquels ne sont du reste pas à l’abri d’erreurs...

J’essaierai de faire un peu de bac à sable Wiki, puis de faire le ménage, mais j'avoue que je ne sais pas quand.