Discussion :

[altair8080]

Bonjour,

Au sein des entités est-il préférable d'avoir le même nom d'un champ ou faut-il différencier.


Ex
Table1
idTable1
Table1id

Table2
idTable2
Table2id


car quand je vais vouloir insérer un lien vers l'autre table je dois mettre Table2_lienidtable1 ??

[ego]

Rien ne t'empêche de mettre id dans Table1 et Table2 et ensuite d'avoir une clé étrangère fk_table1 dans Table2

[fsmrel]

Bonjour,

Je confirme. Si on examine la contrainte NOMENCLATURE_PARENT_FK ci-dessous : la colonne PieceParenteId de la table NOMENCLATURE fait référence à la colonne PieceId de la table PIECE :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
CREATE TABLE PIECE (
       PieceId            INT                  NOT NULL
     , pieceLibelle       VARCHAR(64)          NOT NULL
   , CONSTRAINT PIECE_PK PRIMARY KEY  (PieceId)
) ;
 
CREATE TABLE NOMENCLATURE (
       PieceId           INT       NOT NULL     
     , PieceParenteId    INT       NOT NULL     
   , CONSTRAINT NOMENCLATURE_PK PRIMARY KEY (PieceId)  
   , CONSTRAINT NOMENCLATURE_IS_PIECE_ENFANT_FK FOREIGN KEY (PieceId)
                REFERENCES PIECE (PieceId) ON DELETE CASCADE
   , CONSTRAINT NOMENCLATURE_PARENT_FK FOREIGN KEY (PieceParenteId)
                REFERENCES PIECE (PieceId) ON DELETE NO ACTION  
) ;

Bref, si on veut faire participer des colonnes à une opération de jointure, il n’y a aucune contrainte de nommage.

[CinePhil]

D'abord, les champs sont à la campagne ou dans les formulaires, pas des entités d'un MCD ni dans les tables SQL !

Ensuite, il y a deux écoles :
1) Ceux qui considèrent qu'une chose doit avoir un nom unique et que donc une colonne porteuse d'une clé étrangère doit avoir le même nom que la colonne référencée.

2) Ceux qui considèrent que deux objets e la BDD ne peuvent avoir le même nom.

Avant de décider, juste une remarque aux partisans du premier groupe :
Si une table B référence deux fois la table A, on se retrouverait avec deux colonnes ayant le même nom, ce qui est impossible !

Vous l'aurez compris, je fais partie du second groupe !
En fait, je ne me pose même pas la question car j'ai une norme de nommage qui est inspirée de celle de SQLPro (lequel ferait plutôt partie du premier groupe si j'ai bien lu certains de ses écrits) et qui interdit naturellement d'avoir deux objets portant le même nom.

Exemple de MCD :
personne -0,n----diriger----1,1- projet
|---------------0,n----travailler----0,n---|

Tables qui en découlent :
te_personne_prs (prs_id, prs_nom, prs_prenom...)
te_projet_prj (prj_id, prj_id_chef, prj_nom, prj_date_debut...)
tj_prs_travailler_prj_ptp (ptp_id_personne, ptp_id_projet)

[fsmrel]

il y a deux écoles :
1) Ceux qui considèrent qu'une chose doit avoir un nom unique et que donc une colonne porteuse d'une clé étrangère doit avoir le même nom que la colonne référencée.
2) Ceux qui considèrent que deux objets e la BDD ne peuvent avoir le même nom.

Euh... Il y a au moins une 3e école, dont je fais partie et selon laquelle il n’y a pas ... d’école en ce qui concerne le nom des attributs (colonnes, propriétés, ...) Ainsi, dans le Relationland où je vis, chacun est libre de faire comme il l’entend s'il estime que des règles de nommage des attributs méritent d'être érigées. La seule contrainte y est que dans les opérations relationnelles telles que la jointure et l’union, les opérandes aient même nom, d’où l’existence de l’opérateur RENAME inconnu dans le SQLland, le Meriseland, etc.

[CinePhil]

Si je comprends bien la relationlang, en ajoutant à mon MCD l'association "vendre" suivante :
personne -0,n----diriger----1,1- projet
|---------------0,n----travailler----0,n---|
|---------------0,n----vendre----1,1------|

Il deviendrait obligatoire de faire un RENAME pour produire une relation joignant personne et projet selon les associations diriger et vendre ?

En SQL, ma table des projets deviendrait :
te_projet_prj (prj_id, prj_id_chef, prj_id_vendeur, prj_nom, prj_date_debut...)

J'ai renommé prs_id en prj_id_chef et en prj_id_vendeur

Et pour donner la liste des projets avec le nom du vendeur et le nom du chef de projet, j'aurais cette requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
SELECT j.prj_nom AS nom_projet,
	p1.prs_nom AS nom_chef_de_projet,
	p1.prs_prenom AS prenom_chef_de_projet,
	p2.prs_nom AS nom_vendeur,
	p2.prs_prenom AS prenom_vendeur
FROM te_projet_prj j
INNER JOIN te_personne_prs p1 ON p1.prs_id = j.prj_id_chef
INNER JOIN te_personne_prs p2 ON p2.prs_id = j.prj_id_vendeur

Et j'ai encore fait du rename pour distinguer les différents noms.

[fsmrel]

Bonsoir,

En détaillant les opérations, la requête SQL proposée s’écrit ainsi en relationlang (j’ajoute ce terme à mon dictionnaire de slang ) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
WITH te_personne_prs RENAME (prs_id AS prj_id_chef, 
                             prs_nom AS nom_chef_projet, 
                             prs_prenom AS prenom_chef_projet) AS CHEF, 
     te_personne_prs RENAME (prs_id AS prj_id_vendeur, 
                             prs_nom AS nom_vendeur,
                             prs_prenom AS prenom_vendeur) AS VENDEUR,
     JOIN {te_projet_prj, CHEF, VENDEUR} AS J, 
     J RENAME (prj_nom AS nom_projet) AS R :
     R { nom_projet, nom_chef_projet, prenom_chef_projet, nom_vendeur, prenom_vendeur } ;

« WITH » permet d’aérer les instructions : il s’agit d’une construction syntaxique permettant de donner un nom aux sous-expressions : CHEF, VENDEUR, J, R.

Lignes 1-3 : on nomme la variable te_personne_prs en CHEF (tout en renommant certains attributs) ;

Lignes 4-6 : on nomme la variable te_personne_prs en VENDEUR (tout en renommant certains attributs) ;

Ligne 7 : double jointure (le Modèle Relationnel de Données permet de mettre entre les accolades autant d’expressions que l’on veut, c’est la jointure n-adique) ;

Ligne 8 : on finit de renommer les attributs.

Ligne 9 : opération de projection finale : liste entre accolades des noms d’attributs.


J'ai détaillé, mais on peut s'amuser à remboîter les expressions. Par exemple, à la ligne 9, à la place de R on peut utiliser une expression. Ainsi les lignes 8 et 9 peuvent être remplacées par :

J RENAME (prj_nom AS nom_projet) { nom_projet, nom_chef_projet, prenom_chef_projet, nom_vendeur, prenom_vendeur }

En y intégrant la jointure à la place de J :

JOIN {te_projet_prj, CHEF, VENDEUR} RENAME (prj_nom AS nom_projet) { nom_projet, nom_chef_projet, prenom_chef_projet, nom_vendeur, prenom_vendeur }

Etc., mais ça devient vite illisible, comme une requête SQL en une ligne.

[Richard_35]

Bonjour Altair8080, Ego, Fsmrel et CinePhil,

Très intéressante discussion, c'est pourquoi je me permets de m'immiscer ...

Ensuite, effectivement, dans les faits, il y a deux écoles :
1) Ceux qui considèrent qu'une chose doit avoir un nom unique et que donc une colonne porteuse d'une clé étrangère doit avoir le même nom que la colonne référencée , sauf quand c'est impossible ;

2) Ceux qui considèrent que deux objets de la BDD ne peuvent avoir le même nom.

==> précision "dans les faits" car, les adeptes de la 3ème école se rangent, plus ou moins, dans l'une des deux écoles.

La 1ère école modifiée ne paraît pas si mauvaise. En effet, le cas

Si une table B référence deux fois la table A .../...

arrive, bien entendu, mais n'est pas si fréquent. Du moins, pas au point de se priver du confort d'utilisation des mêmes noms.

Si cela arrive, le suffixe du nom de la colonne par "_" puis la fonctionnalité correspondante assure l'unicité. Exemple :
produit(id_produit, nom, ...) ;
nomenclature(id_produit_composé, id_produit_composant, quantité, ...).

[fsmrel]

les adeptes de la 3ème école se rangent, plus ou moins, dans l'une des deux écoles.

Je répète sur tous les tons et tous les modes que la 3e école n’est pas concernée par la façon de nommer les colonnes : seul l'intéresse le respect du Modèle Relationnel de Données (structure, algèbre, intégrité), le reste est littérature. Le débat est orthogonal à la modélisation des bases de données. Pour plus d’information, je vous renvoie à Databases, Types and The Relational Model: The Third Manifesto : dans sa BNF, le Modèle Relationnel de Données est totalement muet sur le sujet. Si de son côté le chef de projet se revendique d’une école, on fera comme il le veut (c'est lui qui paye), point barre. S’il s’est planté, il ne pourra s'en prendre qu'à lui-même. Que dire d’autre ?

[Richard_35]

Bonjour Fsmrel,

Si de son côté le chef de projet se revendique d’une école, on fera comme il le veut (c'est lui qui paye), point barre. S’il s’est planté, il ne pourra s'en prendre qu'à lui-même. Que dire d’autre ?

==> c'est vrai.

Je voulais simplement dire que, en final (donc quand, réellement, il faut affecter un nom aux champs), ce nommage est plus ou moins effectué selon une des deux écoles évoquées. Mais c'est un détail, c'est vrai. Il n'empêche que, si l'on admet cela, bien qu'il n'existe pas de norme, un usage se met en place (que le chef de projet s'appropriera, comme le fait CinePhil qui préfixe/suffixe le nom de ses tables et de ses champs).