Discussion :

[Amel_B]

Bonjour
veuillez m'expliquer les régles des cardinalités de création des relations entre les tables.c'est a dire quand la clé passe d'une table a l'autre , et sur quel critere.

1.1.......1.1
1.1.......1.n
1.n......1.1
1.n........1.n
0.1........1.n et d'autres s'il existent
je ne sais pas s'ils existent ce ke j'ai ecri ou non .
je veux des ptit exemples de tables pour comprendre les regles qui existent.
Merci

[divot]

Bonjour

Quelques informations qui découle des principes de modélisation entité/relation

Pour un objet on peut trouver 4 cas :

0,1 : présence 0 ou 1 fois maximum
0,n : présence de 0 à n fois
1,1 : présence obligatoire et seulement 1 fois
1,n : présence obligatoire et n fois

Cela peut se comprendre ainsi entre l'objet personne et l'objet adresse :

0,1 : chaque personne n'a pas obligatoirement une adresse et elle ne peut en avoir qu'une seule
0,n : chaque personne n'a pas obligatoirement une adresse et elle peut en avoir plusieurs
1,1 : chaque personne a obligatoirement une adresse et seulement une
1,n : chaque personne a obligatoirement une adresse mais elle peut en avoir plusieurs

Si on prend la relation en sens inverse (d'adresse vers personne)

0,1 : chaque adresse est associée à zéro personne ou à une seule
0,n : chaque adresse est associée à zéro personne ou à plusieurs
1,1 : chaque adresse est associée obligatoirement à une personne et une seule
1,n : chaque adresse est associée obligatoirement à une personne au moins

Cette combinatoire qui se lit donc dans les deux sens va permettre de définir les règles d'intégrité de la base de données.
Par exemple dans le cas ou l'objet personne à la cardinalité 1,1, cela aura pour conséquences qu'il sera impossible de créer un enregistrement dans la table personne si on ne l'a pas associé à un enregistrement de la table adresse, et cette personne ne pourra avoir qu'une seule adresse (donc pas d'historisation possible).

Il est donc impératif de ne pas se tromper lors de la conception.

[Amel_B]

merci ça m'a un peu eclairci les choses mais comment les clés etrangeres se crés et quand la relation elle-meme devien une table

[divot]

La base de données va gérer cela à la condition de faire les bonnes déclarations

Voici un exemple entre la table "rubrique" et la table "type rubrique" :

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
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
-- Table: rubrique
 
-- DROP TABLE rubrique;
 
CREATE TABLE rubrique
(
  code_rubrique character(14) NOT NULL,
  code_type_rubrique character(3),
  libelle_rubrique character(50) NOT NULL,
  CONSTRAINT pk_rubrique PRIMARY KEY (code_rubrique),
  CONSTRAINT fk_rubrique_relation__type_rub FOREIGN KEY (code_type_rubrique)
      REFERENCES type_rubrique (code_type_rubrique) MATCH SIMPLE
      ON UPDATE RESTRICT ON DELETE RESTRICT
)
WITH OIDS;
ALTER TABLE rubrique OWNER TO postgres;
GRANT ALL ON TABLE rubrique TO postgres WITH GRANT OPTION;
 
-- Index: relation_2_fk
 
-- DROP INDEX relation_2_fk;
 
CREATE INDEX relation_2_fk
  ON rubrique
  USING btree
  (code_type_rubrique);
 
-- Index: rubrique_pk
 
-- DROP INDEX rubrique_pk;
 
CREATE UNIQUE INDEX rubrique_pk
  ON rubrique
  USING btree
  (code_rubrique);

Cet ensemble de ligne de commande contient en particulier les lignes :

Code sql :
CONSTRAINT fk_rubrique_relation__type_rub FOREIGN KEY (code_type_rubrique) REFERENCES type_rubrique (code_type_rubrique) MATCH SIMPLE ON UPDATE RESTRICT ON DELETE RESTRICT


qui permet d'indiquer qu'il y a dans la table "rubrique" une relation avec la table "type rubrique".

Pour ce qui est du mode de fonctionnement d'une base de données relationnelle je ne saurais plus répondre.
Les outils de conception et de génération de base de données font cela trés bien.

[CinePhil]

Je vais compléter la réponse de Divot...

1) En cas de cardinalité 0,1 ou 1,1, l'entité qui a cette cardinalité devient une table qui accueille en clé étrangère la clé primaire de l'autre table entrant en jeu dans l'association.

Exemples :
"Une adresse appartient au plus à une personne" donnera le MCD suivant :
Adresse -0,1----Appartenir----0,n- Personne

"Une adresse appartient à une et une seule personne " donnera le MCD suivant :
Adresse -1,1----Appartenir----0,n- Personne

Dans les deux cas, nous aurons les tables :
T_Personne_P(P_Id, P_Nom, P_Prénom...)
T_Adresse_A(A_Id, A_IdPersonne, A_Rue...)

Dans les deux cas, A_IdPersonne est la clé étrangère qui accueille une valeur de P_Id. La différence est que dans le premier cas (0,1), A_IdPersonne peut être NULL mais pas dans le second. Ceci implique dans le second cas que la personne doit être créée avant son adresse

2) En cas de cardinalité 0,n ou 1,n de chaque côté de l'association, celle-ci devient une "table associative" dont la clé primaire est composée des clés primaires des n tables entrant en jeu dans l'association (il peut y en avoir plus de deux).

Exemples :
"Une adresse peut ou pas appartenir à plusieurs personnes" donnera le MCD suivant :
Adresse -0,n----Appartenir----0,n- Personne

"Une adresse appartient à 1 ou plusieurs personnes" donnera le MCD suivant :
Adresse -1,n----Appartenir----0,n- Personne

Dans les deux cas, nous aurons les tables :
T_Personne_P(P_Id, P_Nom, P_Prénom...)
T_Adresse_A(A_Id, A_Rue...)
TJ_AdressePersonne_AP(AP_IdAdresse, AP_IdPersonne, ...)

Cette fois, dans les deux cas, comme les identifiants de l'adresse et de la personne constituent la clé primaire, ils ne peuvent pas être NULL.
Dans le second cas, la création d'une adresse devra être associée obligatoirement à au moins une personne, donc à au moins une ligne de la table associative (ou table de jointure, d'où le préfixe TJ). Par contre, je n'ai pas encore vu le mécanisme qui permet de formaliser et de faire contrôler cela directement par la base de données.

[fsmrel]

Bonsoir,

la création d'une adresse devra être associée obligatoirement à au moins une personne, donc à au moins une ligne de la table associative (ou table de jointure, d'où le préfixe TJ). Par contre, je n'ai pas encore vu le mécanisme qui permet de formaliser et de faire contrôler cela directement par la base de données.

Le mécanisme est possible avec le standard SQL (norme SQL pour faire plaisir à SQLpro) :

Code SQL :

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

1
2
3
4
5
6
7
8
Create Assertion Check 
    (Not Exists (Select  *    
                 From    Adresse As x 
                 Where   Not Exists  
                            (Select  *   
                             From    AdressePersonne As y
                             Where   x.A_Id = y.AP_IdAdresse))) 
  Deferrable  Initially Deferred ;

Maintenant, au stade des SGBD SQL du marché, il faudra peut être attendre encore un moment.

Un conseil en passant : évitez d’exporter vos propres conventions de dénomination des tables. Dans mon cas, des milliers de programmes sont concernés par deux mille tables telles que T_Personne_P. Si un jour les normes de l’entreprise évoluent et imposent par exemple que les programmes mentionnent des noms de vues, faudra-t-il remplacer T_xxx par V_xxx et tout recompiler ? "T_xxx" deviendra-t-il plutôt un nom de vue ? Quelle est la valeur ajoutée du suffixe "TJ" ? En plus, tout cela fait double emploi avec le catalogue : si l'on veut savoir si un objet est une table, une vue ou autre, s'il s'agit d'une table de relation (jointure), il suffit d'interroger les tables du catalogue. En revanche, pour lui faciliter la vie, on se met d’accord avec la Production en ce qui concerne le nom des objets physiques (table spaces, index) : cela est possible parce que les utilisateurs et les programmes ne sont pas concernés par ces types d’objets. Certes, un minimum de discipline et de normalisation s’impose dans la dénomination des tables et des vues, mais d'expérience, moins on encode d’information significative, mieux on se porte. Et n’oubliez pas le principe du rasoir d’Ockham.

[CinePhil]

J'essaie d'adopter sur le forum (et d'adapter car je n'aime pas écrire tout en lettres capitales) le format de nommage proposé par SQLPro, même si je ne l'ai pas encore mis véritablement en œuvre moi-même.

J'ai toujours tendance à faire plus simple que ce standard qui est un peu lourd à écrire dans les requêtes SQL :
- un nom de table simple issu directement du nom de l'entité du MCD (Personnes, Organismes, Commandes, Factures...)
- un préfixage des colonnes qui permet de deviner assez facilement à quelle table elles appartiennent (P_Nom, C_Numero, O_RaisonSociale...)
- un préfixage double pour les tables associatives (PO_IdPersonne, PO_IdOrganisme...)
- Si plusieurs tables commencent par la même lettre, les colonnes des suivantes créées ont deux ou trois lettres de préfixage (Table Projet --> PrjNom)

En gros je n'ai pas encore trouvé le standard qui me convient véritablement. Et comme je ne suis pour le moment soumis à aucun, je fais ce que je veux. Na !

[fsmrel]

Bonsoir,

J'essaie d'adopter sur le forum (et d'adapter car je n'aime pas écrire tout en lettres capitales) le format de nommage proposé par SQLPro, même si je ne l'ai pas encore mis véritablement en œuvre moi-même.
J'ai toujours tendance à faire plus simple que ce standard [...]

Pardonnez-moi de vous avoir attribué des techniques qui ne sont pas le vôtres. Redeo Cinephilo quid est Cinephili et SQLpro quid est SQLpri...
Par curiosité, j’ai suivi le lien que vous avez indiqué : c’est assez savoureux. Je lis par exemple :

« On réservera les noms en minuscule aux modèles logiques et les noms en majuscule aux modèles physique »

La raison de ce distinguo subtil m’échappe totalement...

Maintenant, abstraction faite du manque de rigueur orthographique de la phrase, son auteur devrait remplacer l’expression "les noms en majuscule" par les "noms en capitales". Je fais ici référence à l’ouvrage de référence "Le bon usage" de Maurice Grevisse (13e édition, paragraphes 86 et 96). En effet, en français, les majuscules se placent seulement en début de mot. Si on utilise les capitales, on écrit : CLIENT, si on utilise les majuscules, on écrit : Client.

Je lis encore :

« Un domaine doit toujours commencer par le préfixe D_ suivi d'une lettre indiquant la famille du type parmi les éléments suivants »

"doit" a un côté école maternelle stalinienne incitant à jouer les dissidents. Quoi qu’il en soit, cette contrainte-là, il fallait la trouver.

Je lis aussi :

« Les noms des objets d’un modèle ou d'un schéma devront être significatifs »

Tout est relatif ! Disons que c’est localement dépendant, c'est le vocabulaire courant de l’entreprise qui est en cause. Dans telle entreprise, dès que l’on parle de l’entité-type (ou de la table) GA2002, tout le monde sait qu’il s’agit de la table des dossiers des sinistres, il n’y a aucune ambiguïté.
Dans telle autre, tout le monde sait que PEE0016 est le nom de l’entité-type (et aussi de la table) Entreprise. Si j’évoque la table Titre, on me posera la question : « Voulez-vous parler de la table PEI0031 (titre de civilité) ? De la table PR0078 (titre en portefeuille) ? » Quant à nommer ces choses-là et éviter les collisions, vous me direz qu’il suffit de donner des noms tels que Titre_Civilite et Titre_Portefeuille. Soit, mais comment faire quand on n’a au départ qu’une seule table Titre, par exemple celle des titres en portefeuille et qu’un jour il faudra définir la table des titres de civilité, dont on n’avait que faire jusqu’ici ? Encore quelques réunions en perspective pour trouver une solution.

Je poursuis :

« Nom d’une entité
Elle doit commencer par un préfixe :
e_ lorsqu'il s'agit d'entité fonctionnelle
er_ lorsqu'il s'agit d'entité de référence
es_ lorsqu'il s'agit d'entité "système »

J'ai le sentiment de sombrer dans le bizarre et le byzantin, ou alors quelle chose de capital m'échappe.

Etc. Etc.

En gros je n'ai pas encore trouvé le standard qui me convient véritablement. Et comme je ne suis pour le moment soumis à aucun, je fais ce que je veux. Na !

Comme je vous comprends !

A titre indicatif quand même : en ce qui concerne le nom des objets, il y a une douzaine d’années, le responsable de l’administration des données chez un de mes clients avait proposé l’utilisation d’un préfixe pour le nom des entités-types, qui permette de rattacher chacune d’elles à un référentiel. En effet, il y avait plus de mille entités-types et les données avaient fait l’objet d’une urbanisation en grands domaines fonctionnels et transverses donnant lieu à autant de référentiels :

Référentiel Personnes,
Référentiel Produits,
Référentiel Habilitations,
Référentiel Contrats,
Référentiel Cotisations,
Etc. Environ une vingtaine de référentiels.

Par exemple, le domaine Personnes (PEPxxxx) était spécialisé en sous-référentiels : Entreprises et Établissements (PEExxxx), Individus (PEIxxxx), etc., "xxxx" représentant un nombre à simplement incrémenter, relativement au trigramme générique.
Ainsi, l’entité-type (donc la table) Entreprise avait pris pour nom PEE0016, celle des établissements PEE0018, celle des individus PEI0014, etc. Cette codification n’a jamais fait l’objet d’une quelconque critique. Lors des développements, il y avait quand même quelque chose comme trois cents personnes sur le pont, tout le monde s’y retrouvait et il eut été incongru de ne pas connaître "la" PEE0016 ou ses petites soeurs.

Le système continue à fonctionner à la satisfaction de tous, y-compris de la Production qui a piloté le nommage des noms des objets physiques (table spaces et index).

Pardonnez-moi encore de vous avoir attribué des choses qui ne sont pas de votre fait, mais en tout état de cause n’oublions pas Ockham et son rasoir...

fsmrel

[Amel_B]

Bonjour
Je vous remerci bcp Messieurs divot; CinePhil ;CinePhil
j'ai trés bien compri.
MERCI