Discussion :

[vimanas]

Bonjour,


J'aurais aimé savoir si l'on peut sans problème mettre une primary key à deux colonnes dans une entité. Dans mon cas cette deuxieme colonne est une date, car je veux avoir une occurence de l'entité par mois.

DECLARATION
iddec(pk)
date(pk)
autredonnées...

Accesoirement dans le MLD la pk sera à trois colonnes à cause d'un lien identifiant ...

voilà

merci pour votre aide je debute

au revoir

[Soutou]

Oui bien sûr, l'identifiant d'une entité peut être composé de +sieurs attributs ce qui évite d'utiliser un lien de type "identifiant relatif" (Merise).
Bye

[Le Pharaon]

J'aurais aimé savoir si l'on peut sans problème mettre une primary key à deux colonnes dans une entité. Dans mon cas cette deuxieme colonne est une date, car je veux avoir une occurence de l'entité par mois.

L'identifiant (ou primary key dans ton langage) est l'élément qui permet (comme son nom l'indique) d'identifier un enregistrement de manière unique. Inutil alors d'en créer plusieurs dans le seul but d'empêcher les doublons. Il y'a déjà une manière d'interdir celà, selon les SGBD

[vimanas]

Bonjour

Merci pour vos reponses, je vais avoir l'air bête mais comment interdire cela dans le SGBD lui même ?
A toute fin utile voici mon modele

Declaration
iddec (pk)
date (pk)
autresdonnées...
|
1,1
|
FAIRE
|
0,n
|
Personne
idpersonne (pk)
autresdonnées...



au revoir

[Le Pharaon]

TU as quoi comme SGBD ?

[vimanas]

Bonjour

C'est pour oracle et peut etre plus tard mysql.

au revoir

[fsmrel]

A Vimanas,

N'hésitez surtout pas à utiliser des clés multicolonnes. Il y a 30 ans que les inventeurs de Merise ont exigé que les identifiants des entités soient des singletons (une seule colonne ou propriété). Cette position, qui relève plutôt de critères psychologiques, ne tient pas le choc face à la théorie relationnelle (qu'ils ne connaissaient malheureusement pas à l'époque), qui demande seulement qu'une variable de relation (ou table) ait au moins une clé candidate (la notion de clé primaire est conservée aujourd'hui par habitude). Pour une table, on peut donc avoir plus d'une clé candidate, chacune comportant un nombre quelconque de colonnes. Au delà de la description des données, le SGBD relationnel a en charge leur manipulation (algèbre ou calcul relationnel), leur intégrité (clés candidates, intégrité référentielle, contraintes de types, de tables, de bases de données).
La détermination des clés ne se fait donc pas sur des critères dogmatiques, mais sur la détermination de la couverture minimale des dépendances fonctionnelles, à l'aide des axiomes d'Armstrong. Il est possible que la phrase que je viens de formuler vous parlerait autant si je la traduisais en islandais, mais il existe des ouvrages fort accessibles qui en parlent très clairement (il y en aussi d'exécrables et faux de A à Z !)

En outre, n'hésitez pas à utiliser l'identification relative, car la performance des requêtes SQL en est terriblement dépendante, sujet qui bien sûr ne peut qu'échapper à ceux qui sont peu au fait des SGBDR, du tuning des pools de buffers et autres joyeusetés (merisiens ou ulémiens purs et durs).

Bon courage !

[Nanci]

Quand arrêtera-t-on de raconter de contreverités sur Merise ?
Il ya 30 ans, les inventeurs de Merise (dont je suis...) n'étaient pas des théoriciens ou des psychos-rigides.
L'identifiant d'une entité était unique certes, mais pouvait être composé de plusieurs propriétés dont l'ensemble, insécable, assure l'indentification d'une occurrence de l'objet.
Dans les publications de l'époque, ainsi que dans un bouquin de 79, figure l'exemple de Personne identifiée par nom+prénom+date et lieu de naissance !
Je rassurre fsmrel, nous connaissions fort bien toute la théorie relationnelle. Quand à la technique de recherche des identifiants par les algorithmes de couverture minimale, la première fois où j'en ai fait connaissance, c'est en 1975 et nous en avons fait une communication critique dans un congrès en 1976.
Les inventeurs de Merise sont certes maintenant vieux (ça va quand même, on se maintient) mais pas cons !

En outre, n'hésitez pas à utiliser l'identification relative, car la performance des requêtes SQL en est terriblement dépendante, sujet qui bien sûr ne peut qu'échapper à ceux qui sont peu au fait des SGBDR, du tuning des pools de buffers et autres joyeusetés (merisiens ou ulémiens purs et durs).

L'identification relative est apparue un peu plus tard dans Merise et est parfaitement positionnée dans son utilisation, mais n'a rien a voir avec des problèmes de performance.

Maintenant dans la question initiale, il ya une différence fondamentale entre:
- une entité identifié par plusieurs propriétés
dans ce cas, l'identification est réalisée par la composition de plusieurs propriétés intrinsèques à l'entité. Au niveau logique, la clé primaire sera composée des n attributs qui ne seront pas clés étrangères.
- une entité identifiée relativement.
dans ce cas, l'identification de l'entité s'effectue par rapport à une autre entité. Au niveau logique, l'ex identifiant de l'autre entité participera à la clé primaire (nécesssairement composée) mais sera également clé étrangère.

Les deux cas peuvent d'ailleurs coexister ! et c'est apparemment le cas si une déclaration est identifiée:
- relativement à une personne,
- par un n° de déclaration et une date.
Il faut toutefois s'assurer de la manière de numéroter les déclarations. En effet, suivant la modélisation, le n° de déclaration n'est pas unique dans l'absolu. Il a de plus besoin de la date pour être discriminant.
C'est certes possible mais je demande à voir....

[fsmrel]

Bonjour vimanas,
La discussion va au-delà de votre question initiale. Cela dit, j'espère que certains éléments de la discussion vous seront profitables.
Supposons que votre entité Déclaration soit identifiée relativement à une entité P (identifiée par P_Id). Au niveau tabulaire, la table Déclaration comportera P_Id comme première colonne de la clé primaire (je l’appellerai colonne racine). Maintenant, si vous souhaitez n’avoir qu’une déclaration par P_Id et par mois, alors prenez le mois comme deuxième colonne de la clé : Primary Key (P_Id, Mois) et conservez si nécessaire le jour et l’année comme propriétés non clés. Si la colonne iddec n’a qu’un rôle technique, on peut l’évacuer. Si elle joue un rôle descriptif (colonne authentique), on en reparle.

Maintenant, je cite nanci :

Il ya 30 ans, les inventeurs de Merise (dont je suis...) n'étaient pas des théoriciens ou des psychos-rigides

Soit. Sans doute vous êtes-vous senti visé, mais sachez que je vous compte parmi ceux qui écrivent de manière pertinente, ainsi par exemple qu'Yves Tabourier ou ceux qui à l'AFCET (groupe 135) ont participé à l’élaboration de Merise 2. Je pensais à d'autres auteurs bien connus, qui ont eu une approche parfois trop simple concernant des éléments fondamentaux tel que l'identifiant, avec des conséquences funestes sur les bases de données relationnelles. Je vous renvoie à ce sujet au paragraphe "Identification des occurrences" de l'ouvrage d'Yves Tabourier "De l'autre côté de Merise" (aux éditions d'organisation, 1986). Tabourier y met en cause « de nombreux auteurs », sans toutefois les nommer. Je ne vous raconte pas le nombre de bases de données relationnelles qu'en tant que DBA j'ai eues à remettre d'équerre. Une des missions du DBA est de garantir l’intégrité des données et la performance des requêtes (disons SQL) en production, il est en première ligne.

Concernant toujours l'identifiant selon Merise, je cite encore nanci :

L'identifiant d'une entité était unique certes, mais pouvait être composé de plusieurs propriétés dont l'ensemble, insécable, assure l'indentification d'une occurrence de l'objet.

Tout à fait d'accord. Cela dit, j'ai sous la main le fascicule 4 "Guide pratique pour l'élaboration des modèles de données et de traitements" du document "Méthode de définition d'un système d'informations" publié en juin1979 par le CTI (Centre Technique Informatique), sous la responsabilité du Ministère de l'Industrie (René Monory). Document officiel s'il en est, réalisé par R. Colletti, F. Nicolas, J.C. Ponce, G. Vahée, à partir d'une étude à laquelle ont participé notamment H. Tardieu, A. Rochfeld, B. Chapot, H. Heckenroth, etc. Bref, dans ce document de référence, l'identifiant est ainsi défini page 9 :

Parmi l'ensemble des propriétés qui caractérisent un objet, une propriété particulière est choisie comme identifiant; pour cela elle doit être telle qu'à chaque valeur prise par cette propriété ne corresponde qu'une et une seule occurrence de cet objet.

On ne peut pas être plus clair.
Dans l’ouvrage de référence de H. Tardieu, A Rochfeld et R. Colletti "La Méthode Merise Tome 1" (nouvelle édition, 1989) on retrouve cette définition et, les concepteurs de terrain que j’ai fréquentés respectaient cette contrainte à la lettre. Depuis quelques années, ils ont évolué et utilisent volontiers des identifiants multi-propriétés. Les travaux du groupe 135 de l’AFCET sur Merise 2 concernant les identifiants composés et relatifs, ou vos propres travaux (je fais référence à votre ouvrage "Ingénierie des Systèmes d'Information, Merise, Deuxième génération", 3e édition, 1996), on concouru à la mise en œuvre de tels identifiants.

Je cite à nouveau nanci

Quand à la technique de recherche des identifiants par les algorithmes de couverture minimale, la première fois où j'en ai fait connaissance, c'est en 1975 et nous en avons fait une communication critique dans un congrès en 1976.

Je lirais avec plaisir votre communication. Pour ma part, je me suis appuyé sur la couverture minimale et la fermeture des dépendances fonctionnelles, pour m’assurer des clés candidates et de la normalisation des tables (BCNF). Il est évident que ce travail prend énormément de temps, ad nauseam, mais grâce à Merise, on peut sans risque éclater une relation universelle en une foultitude d’entités-types au nombre réduit de propriétés, ce qui fait qu’on parvient à une validation honorable (je ne jure pas que toutes les tables que j’ai validées sont en BCNF, quand telle ou telle base de données dépasse 1000 tables...)

L'identification relative est apparue un peu plus tard dans Merise et est parfaitement positionnée dans son utilisation, mais n'a rien à voir avec des problèmes de performance.

Je peux vous garantir que lorsqu’on manipule par jointure des tables comportant des dizaines de millions de lignes, la présence d’une clé "racine" est déterminante. Imaginez un ensemble de tables : Commande, Ligne de commande, Engagement sur ligne de commande, Partie de commande livrable, en sorte que chaque table corresponde à une propriété multivaluée d’une autre (entité forte / entité faible). Si je propage en cascade le n° de commande (ou plutôt l'identifiant non significatif de la commande), alors je ne connaîtrai pas l’angoisse de "l’I/O bound" (processeur au chômage technique pour cause d’attente de fin de lecture/écriture sur disque). Les lignes de commande se trouveront physiquement dans une même page (ou des pages contigües), même chose pour les engagements et les parties livrables. En une seule entrée/sortie, on récupère un maximum de données et les temps de traitement (batch ou TP lourd) sont divisés par 10 (pour fixer un ordre de grandeur moyen). Évidemment pouvoir agir ainsi dépend du SGBD, mais pour le plus puissant d’entre eux, DB2, les résultats sont spectaculaires et donc j’use sans modération de l’identification relative au niveau conceptuel pour que l’AGL propage la clé racine (celle de la table commande) jusqu’au tréfonds de la plus petite des poupées russes (Partie de commande livrable). En l’occurrence, je n’ai jamais été déçu par l’identification relative quant à son impact sur la rapidité d’exécution des requêtes.

[vimanas]

Bonjour,

Merci pour toutes vos interventions trés interessantes (même si je n'ai parfois pas tout suivis),
J'aimerai effectivement beaucoup avoir un numéro de déclaration unique pour une déclaration, mais comme de toute façons avec le lien identifiant la pk est été à plusieurs colonnes ... . Mais effectivement au niveau conceptuel rien ne garantis l'unicité du numéro de déclaration ...
je vais devoir investir dans quelques bouquins je crois

au revoir

[fsmrel]

Faut pas désespérer vimanas ! On y arrivera un jour...

Si une personne fait au plus une déclaration par mois et que l'on n'a pas besoin de gérer un Numéro de déclaration :

CREATE TABLE Personne (
P_Id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT,
Blabla TEXT NOT NULL,
PRIMARY KEY(P_Id)
);

CREATE TABLE Declaration (
P_Id INTEGER UNSIGNED NOT NULL,
Mois INTEGER UNSIGNED NOT NULL,
Annee INTEGER UNSIGNED NOT NULL,
Jour INTEGER UNSIGNED NOT NULL,
Donnee_truc TEXT NOT NULL,
Etc TEXT NOT NULL,
CONSTRAINT C1 PRIMARY KEY (P_Id, Mois),
FOREIGN KEY(P_Id)
REFERENCES Personne(P_Id)
ON DELETE NO ACTION
ON UPDATE NO ACTION
);

/* Si l'on gère un numéro de déclaration (unique pour la table) et que l'on conserve le lien identifiant, on utilise la clause UNIQUE */

CREATE TABLE Declaration (
P_Id INTEGER UNSIGNED NOT NULL,
Mois INTEGER UNSIGNED NOT NULL,
Annee INTEGER UNSIGNED NOT NULL,
Jour INTEGER UNSIGNED NOT NULL,
Donnee_truc TEXT NOT NULL,
Numero_Declaration INTEGER UNSIGNED NOT NULL,
Etc TEXT NOT NULL,
CONSTRAINT C1 PRIMARY KEY (P_Id, Mois),
CONSTRAINT C2 UNIQUE (Numero_Declaration),
FOREIGN KEY(P_Id)
REFERENCES Personne(P_Id)
ON DELETE NO ACTION
ON UPDATE NO ACTION
);

/* Si l'on gère un numéro de déclaration (unique pour la table) et que l'on ne conserve pas le lien identifiant (association lambda) */

CREATE TABLE Declaration (
P_Id INTEGER UNSIGNED NOT NULL,
Mois INTEGER UNSIGNED NOT NULL,
Annee INTEGER UNSIGNED NOT NULL,
Jour INTEGER UNSIGNED NOT NULL,
Donnee_truc TEXT NOT NULL,
Numero_Declaration INTEGER UNSIGNED NOT NULL,
Etc TEXT NOT NULL,
CONSTRAINT C1 PRIMARY KEY (Numero_Declaration),
CONSTRAINT C2 UNIQUE (P_Id, Mois),
FOREIGN KEY(P_Id)
REFERENCES Personne(P_Id)
ON DELETE NO ACTION
ON UPDATE NO ACTION
);

[vimanas]

Bonour,

Merci bcp pour le script

au revoir

[nponzo]

Bonjour,

j'espère qu'il n'est pas trop tard pour poser une question relative à cette discussion. j'arrives un peu deux ans après, mais sait-on jamais.

je suis cartographe et je me suis mis à MERISE il y a peu et à postgresql encore plus récemment. Je réalise un projet dans une entreprise agricole et je dois mettre en place une base de données géographique.

j'ai quelques questions concernant les identifiant relatifs et plus particulièrement les associations réflexives.

voilà mon problème :

j'utilise merise et j'ai quasiment fini mon modèle. cependant, lorsque je construit les tables et que j'insère les données j'ai quelques petits problèmes.
j'ai utilisé des identifiants relatifs pour mes tables.

j'ai créé une table "commune" :

Code :

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
36
37
38
39
40
41
CREATE TABLE commune
(
  num_insee character varying(5) NOT NULL,
  nom_com character varying(32),
  code_pra integer NOT NULL,
  num_dep integer,
  the_geom geometry,
  CONSTRAINT pk_com PRIMARY KEY (num_insee),
  CONSTRAINT fk_dep FOREIGN KEY (num_dep)
      REFERENCES departement (num_dep) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT fk_pra FOREIGN KEY (code_pra)
      REFERENCES pra (code_pra) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT enforce_dims_the_geom CHECK (ndims(the_geom) = 2),
  CONSTRAINT enforce_geotype_the_geom CHECK (geometrytype(the_geom) = 'MULTIPOLYGON'::text OR the_geom IS NULL),
  CONSTRAINT enforce_srid_the_geom CHECK (srid(the_geom) = 27572)
)
WITH (OIDS=FALSE);
ALTER TABLE commune OWNER TO postgres;

-- Index: fki_dep

CREATE INDEX fki_dep
  ON commune
  USING btree
  (num_dep);

-- Index: fki_pra

CREATE INDEX fki_pra
  ON commune
  USING btree
  (code_pra);

-- Index: idx_com_geom_gist

CREATE INDEX idx_com_geom_gist
  ON commune
  USING gist
  (the_geom);

une table "section" :

Code :

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
CREATE TABLE section
(
  num_insee character varying(5) NOT NULL,
  num_section character varying(5) NOT NULL,
  the_geom geometry,
  CONSTRAINT cle_sec PRIMARY KEY (num_insee, num_section),
  CONSTRAINT fk_section_com FOREIGN KEY (num_insee)
      REFERENCES commune (num_insee) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT enforce_dims_the_geom CHECK (ndims(the_geom) = 2),
  CONSTRAINT enforce_geotype_the_geom CHECK (geometrytype(the_geom) = 'MULTIPOLYGON'::text OR the_geom IS NULL),
  CONSTRAINT enforce_srid_the_geom CHECK (srid(the_geom) = 27572)
)
WITH (OIDS=FALSE);
ALTER TABLE section OWNER TO postgres;

-- Index: idx_fk_section_com

CREATE INDEX idx_fk_section_com
  ON section
  USING btree
  (num_insee);

-- Index: idx_section_the_geom_gist

CREATE INDEX idx_section_the_geom_gist
  ON section
  USING gist
  (the_geom);

et une table "parcelle" :

Code :

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
CREATE TABLE parcelle
(
  num_insee character varying(5) NOT NULL,
  num_section character varying(5) NOT NULL,
  num_parcelle character varying(4) NOT NULL,
  num_parcelle_mere character varying(4),
  num_prodcom character varying(15),
  statut character varying(10),
  nature_cadastrale character varying(50),
  surface double precision,
  the_geom geometry,
  CONSTRAINT cle_parcelle PRIMARY KEY (num_insee, num_section, num_parcelle),
  CONSTRAINT fkey_sect FOREIGN KEY (num_insee, num_section)
      REFERENCES section (num_insee, num_section) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT enforce_dims_the_geom CHECK (ndims(the_geom) = 2),
  CONSTRAINT enforce_geotype_the_geom CHECK (geometrytype(the_geom) = 'MULTIPOLYGON'::text OR the_geom IS NULL),
  CONSTRAINT enforce_srid_the_geom CHECK (srid(the_geom) = 27572)
)
WITH (OIDS=FALSE);
ALTER TABLE parcelle OWNER TO postgres;

-- Index: fkidx_section

CREATE INDEX fkidx_section
  ON parcelle
  USING btree
  (num_insee, num_section);

-- Index: parcelle_the_geom_gist

CREATE INDEX parcelle_the_geom_gist
  ON parcelle
  USING gist
  (the_geom);

ça marche entre commune, section et parcelle, certains champs sont à la fois clés primaires et clé secondaires.

nous seront amenés à faire des découpages de parcelles d'où la création d'un champs "num_parcelle_mere"

cependant, je voulais que "num_parcelle_mere" fasse référence a "num_parcelle", mais je n'arrive pas à le faire car il n'y a pas le même nombre d'occurrence (le champs parcelle_mere fait référence à une seule partie de mon identifiant : "num_parcelle" alors que mon identifiant à 3 champs).

suis-je obligé de répéter "num_insee" et "num_section" dans parcelle afin de faire une clé étrangère de chaque champs vers sa référence ou peut-on faire en sorte que "num_parcelle_mere" fasse référence à "num_parcelle" alors que ce champs n'est pas unique ?

si vous avez besoins de précision, je me tiens à votre disposition.

merci.

[fsmrel]

Bonsoir,

nous seront amenés à faire des découpages de parcelles d'où la création d'un champs "num_parcelle_mere"

Voulez-vous dire que le résultat d'u découpage d’une parcelle est encore une parcelle ? Si oui, vous pouvez mettre en place une contrainte d’auto-référence pour la table parcelle :

CONSTRAINT fkey_parcelle_mere FOREIGN KEY (num_insee, num_section, num_parcelle_mere)
REFERENCES parcelle (num_insee, num_section, num_parcelle)

Exemple :

les parcelles <1,1,2> et <1,1,3> ont pour parentes la parcelle <1,1,1> :

Code :

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

1
2
3
4
num_insee   num_section   num_parcelle   num_parcelle_mere ...
   1           1             1               NULL          ...
   1           1             2                1            ...
   1           1             3                1            ...

Vous pouvez aussi éviter de polluer la table Parcelle avec ces sous-parcelles (on ne touche pas à l’existant, ça évite les nulls et s’il y a relativement peu de sous-parcelles, c’est plus économique). Vous n'ajoutez pas d’attribut num_parcelle_mere dans la table parcelle, et vous créez une table dédiée pour les sous-parcelles :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
CREATE TABLE parcelle_fille
(
  num_insee character varying(5) NOT NULL,
  num_section character varying(5) NOT NULL,
  num_parcelle_fille character varying(4) NOT NULL,
  num_parcelle_mere character varying(4) NOT NULL
  CONSTRAINT cle_parcelle PRIMARY KEY (num_insee, num_section, num_parcelle_fille),
  CONSTRAINT fkey_parcelle_fille FOREIGN KEY (num_insee, num_section, num_parcelle_fille)
      REFERENCES parcelle (num_insee, num_section, num_parcelle),
      ON UPDATE NO ACTION ON DELETE CASCADE,
  CONSTRAINT fkey_parcelle_mere FOREIGN KEY (num_insee, num_section, num_parcelle_mere)
      REFERENCES parcelle (num_insee, num_section, num_parcelle)
      ON UPDATE NO ACTION ON DELETE NO ACTION 
)

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
Table parcelle :

num_insee   num_section   num_parcelle  ...
   1           1             1          ...
   1           1             2          ...
   1           1             3          ... 


Table parcelle_fille :

num_insee   num_section   num_parcelle_fille   num_parcelle_mere
   1           1             2                      1
   1           1             3                      1

[CinePhil]

Imaginez un ensemble de tables : Commande, Ligne de commande, Engagement sur ligne de commande, Partie de commande livrable, en sorte que chaque table corresponde à une propriété multivaluée d’une autre (entité forte / entité faible). Si je propage en cascade le n° de commande, alors je ne connaîtrai pas l’angoisse de "l’I/O bound" (processeur au chômage technique pour cause d’attente de fin de lecture/écriture sur disque).

Je ne suis pas sûr de bien interpréter cette partie...
Cela veut-il dire que, sur une grande base de données, il vaut mieux prendre pour clé primaire (puis clé étrangère dans les autres tables) un numéro de commande réel (lequel peut être composé de lettres et de chiffres) plutôt que créer une clé primaire auto-incrémentée ?

Pour être concret, je suis amené actuellement à travailler avec des données sur les bovins. Nous mangeons beaucoup de viande et nous buvons beaucoup de lait donc les lignes des tables se comptent en millions et même parfois en dizaines de millions.
Les bovins sont identifiés par un numéro national d'identité de 12 caractères alphanumériques. Trouvant ceci bien lourd, j'ai créé dans mon modèle un identifiant entier autoincrémenté. Ai-je eu tort ?

CREATE TABLE commune
(
num_insee character varying(5) NOT NULL,
nom_com character varying(32),
code_pra integer NOT NULL,
num_dep integer,

Mauvaise idée le num_dep en integer !
Corse = 2A + 2B
Ariège = 09 et pas 9
Un numéro de département est un VARCHAR(3)

PS : Bravo à Nanci pour l'invention de la méthode Merise ! UML j'ai du mal, Merise est plus facile à lire selon moi.

[fsmrel]

Imaginez un ensemble de tables : Commande, Ligne de commande, Engagement sur ligne de commande, Partie de commande livrable, en sorte que chaque table corresponde à une propriété multivaluée d’une autre (entité forte / entité faible). Si je propage en cascade le n° de commande, alors je ne connaîtrai pas l’angoisse de "l’I/O bound" (processeur au chômage technique pour cause d’attente de fin de lecture/écriture sur disque).

Je ne suis pas sûr de bien interpréter cette partie...
Cela veut-il dire que, sur une grande base de données, il vaut mieux prendre pour clé primaire (puis clé étrangère dans les autres tables) un numéro de commande réel (lequel peut être composé de lettres et de chiffres) plutôt que créer une clé primaire auto-incrémentée ?

Ciel ! J’aurais dû écrire " Si je propage en cascade l’identifiant de la commande". (Identifiant non significatif, que vous maîtrisez).

En effet, il est hors de question de propager le vrai numéro de commande, puisqu’il est significatif, non maîtrisé par le système mais par l’utilisateur, etc. Ce numéro de commande fait l’objet d’une clé alternative (clé candidate), mais ne peut absolument pas faire l’objet de la clé primaire...

Voyez à ce sujet la discussion avec ctobini, au sujet de l'attribution du N° siren des entreprises par l'INSEE...

http://www.developpez.net/forums/m2036715-13/


Et de ce pas je vais modifier ce que j'ai écrit à l'époque...

[CinePhil]

Merci. C'est bien ce qu'il me semblait, je suis rassuré.
D'autant plus que, concernant mes bovins, j'ai cru déceler des cas ou l'identification du bovin change légèrement si celui-ci change de pays, les deux premiers caractères du numéro d'identité du bovin étant le code du pays. Mais cette supposition demande à être confirmée par des gens plus spécialistes que moi sur la nature réelle des données.

[SQLpro]

Pour répondre sur deux points et soulever un autre :

1) le n° de commune INSEE est bien à 5 caractères et incorpore une référence au département qui sont les 2 ou 3 premiers car (exemple 33 gironde, mais 971 : guadeloupe...)

2) clef auto incrémentée (donc artifice ajouté) ou clef naturelle, sémantique (une ou plusieurs caractéristiques) sont un vieux débat. Mais la clef auto incrémentée ne doit pas faire oublier que la plupart du temps il faudra probablement ajouter une contrainte d'unicité sur la clef sémantique. Effectivement les performances peuvent être liées à la clef, suivant les systèmes et comment est interprété la notion d'index cluster en particulier.

3) le modèle donné par nponzo est très intéressant, et je n'ai pas trop le temps d'y répondre, mais c'est celui que je donne en tant que premier TP à mes étudiants de 5e année à L'ISEN ou aux Arts et Métier (informatisation d'une géomètre ayant à effectuer des mesures de parcelles, mais aussi à découper ou réunir d'autres parcelles et bin sur avec gestion des codes INSEE des communes, départements...). Un jour il faudra que je mette en ligne tous ces TP avec leurs solutions... Elles ne sont pas très simple en effet car il existe de nombreuses contraintes dans ce modèle comme celle-là : une parcelle doit au moins être constituée par le relevé de 3 points !
Néanmoins un point que nponzo doit avoir à l'esprit et qui risque de casser son modèle est l'évolution historique des parcelles. En effet que se passe t-il si une commune fusionne avec une autre... Donc permettre l'évolution historiques des données dans le temps !

A +

[nponzo]

Bonjour, je suis content que cette discussion soit autant suivie.
merci à tout le monde pour vos réponses.

1) pour répondre à SQL pro, effectivement, dans les DOM mais aussi les TOM et les POM, il y a des codages à 3 chiffres. j'en suis conscient mais je travail actuellement au niveau régional et dans l'analyse des besoins, nul besoins de plus de deux chiffres. cependant, je garde cela en tête. et je vais aussi mettre le code de departement en character varying (3). même si j'en ai pas besoins.

mais sait-on jamais si un tremblement de terre sépare un bout de la France, on aura peut-être un DOM. avec le réchauffement climatique on peut devenir insulaire assez vite, on est jamais trop prudent.

2) Autre chose, concernant la fusion de deux communes. nous avons pensés à ça , car c'est déjà arrivé dans le territoire sur lequel je travail.

les communes sont composées de sections cadastrales codées sur un ou deux caractères en général (A,B...ZA,ZB...). lorsque qu'une commune en absorbe une autre, elle récupère le code commune (3 derniers chiffres du numero insee --> exemple 76 655 ou 76 est le département et 655 le code commune).
donc si 76655 absorbe 76375 alors 76375 disparait. mais les sections cadastrales de 76375 ne disparaissent pas, elles figurent dans 76655. il y a donc un risque de doublons des numéros de sections dans 76655. Ainsi 76655 contient les sections A,B, C... et récupère A,B,C de 76375. dans ce cas, le numéro de section est en fait codé sur 5 caractères. Pour la commune 76655, on à 0000A, 0000B ... et 3750A, 3750B ou les trois premiers caractères du numéro de section récupèrent la commune d'origine des sections. les numéros de parcelles ne changent pas dans ce cas là.

ainsi nous avons un numéro de parcelle cadastrale codé sur 14 caractères :

76655 3750A 0027, pour la parcelle 27 de la section 'A' issue de la commune 76375 absorbée par 76655.

cela respecte bien les identifiants relatifs proposés par Fsmrel. les sections ne sont que dans une commune avec un numero insee unique et les parcelle dans une section unique rappelant la commune d'origine. c'est pour le découpage des parcelles que ça se gère différemment car lorsqu'une parcelle est découpé en deux sous parties, il faut attendre le document d'arpentage pour donner deux nouveaux numéros de parcelles. en attendant, nous gérons ça cartographiquement en codant la parcelle sur 6 caractères. les deux derniers sont F1,F2 (pour Fictif 1 et 2) avec le même numéro de parcelle mère pour identifier leur origine.

voilà, j'espère que j'ai été clair. mais si vous décelez des anomalies, n'hésitez pas, je ne souhaite qu'améliorer le modèle.


à bientôt,

nicolas

[SQLpro]

Vous comprenez donc l'importance de travailler avec des clef primaire indépendante de toute sémantique, car en cas de mutation division, ou réunion, cela devient un cauchemar !

A +