Discussion :

[chcheibani]

Bonjour tout le monde

Je suis entrain de réaliser une base de données pour une Entreprise, cette base de donné concerne en générale les ilots qui existe en Bretagne. Et j'ai une table que je l'ai nommée Aspects Anthropiques qui contient deux champs id, Catégorie), où catégorie peut prendre des valeurs comme Activité de visiteurs, Infrastructures, Peuplement ....

et pour chacun de ces catégories j'ai une liste de valeurs possible (par exemple pour Activité de visiteurs on peut avoir : chasse, Pêche à la ligne,........etc. et pour peuplement on peut avoir : Population occasionnelle, Population permanente, Population temporaire....etc)

est ce que c'est mieux de remplacer la table Aspects Anthropiques par trois tables : Activité de visiteurs, Infrastructures, Peuplement



Pouvez vous m'apporter une clarification ?


Regarder les deux schéma dans les pièces jointes pour bien comprendre la question .

Merccii

[fsmrel]

Bonjour chcheibani,


Votre 1er MCD présente quelques inconvénients : si de nouvelles catégories se font jour, il faudra à chaque fois définir les tables ad-hoc. Par ailleurs, si l’on veut gérer les données sur les personnes (ce qui me paraît assez évident), il est nécessaire de mettre en œuvre une entité-type PERSONNE : dans ces conditions, pour chaque association il faudra établir ne association avec cette entité-type...

Le 2e MCD est plus replié, mais plus apte à résoudre les points qui viennent d’être évoqués. Supposons maintenant qu’une observation ne concerne qu’un îlot, une catégorie et ne soit faite que par une personne, à une date donnée, alors le MCD peut évoluer ainsi :




Maintenant, quelles sont exactement les règles de gestion ?

[chcheibani]

Bonjour chcheibani,


Votre 1er MCD présente quelques inconvénients : si de nouvelles catégories se font jour, il faudra à chaque fois définir les tables ad-hoc. Par ailleurs, si l’on veut gérer les données sur les personnes (ce qui me paraît assez évident), il est nécessaire de mettre en œuvre une entité-type PERSONNE : dans ces conditions, pour chaque association il faudra établir ne association avec cette entité-type...

Le 2e MCD est plus replié, mais plus apte à résoudre les points qui viennent d’être évoqués. Supposons maintenant qu’une observation ne concerne qu’un îlot, une catégorie et ne soit faite que par une personne, à une date donnée, alors le MCD peut évoluer ainsi :


Maintenant, quelles sont exactement les règles de gestion ?

Merci bien pour votre réponse
je pense come vous dites le 1er MCD n'est pas évolutif si il y aura des nouvelles catégories.

mais pour le 2e MCD
En ce qui concerne personne : une observation peut être faite par plusieurs personnes dans une date donnée


pour le bien comprendre vous pouvez voir les images que j'ai pris de les deux tables(Aspects anthropique , Releves_Aspects anthropique) du model relationnel pour le 2e MCD

[fsmrel]

Bonjour chcheibani,


Selon votre représentation tabulaire, il apparaît qu’effectivement au moins deux personnes peuvent participer à une même observation, où plutôt à un même type d’observation, concept que vous n’avez pas formellement précisé dans votre message. Vous avez énuméré les différents types d’observation (Population occasionnelle, Population permanente, Population temporaire, etc.), mais sans donner de nom à cette énumération, laquelle devra donc faire l’objet d’une entité-type dans le MCD. Pour ma part, j’ai interprété le terme « observation » comme synonyme de compte-rendu, disons de 3 pages : on est donc dans série de quiproquos du genre : qu’est-ce qu’un titre ? Chez un libraire on vous citera comme exemples : « Vingt mille lieues sous les mers », « Voyage au centre de la terre », chez un trader on vous parlera du cours du titre « Alstom », « Microsoft » (et passer le cas échéant à la titrisation), chez un chimiste on parlera du titre des différents alcools, dans le service public de l’état civil on évoquera plutôt les titres de civilité (Monsieur, Madame, Mademoiselle, Docteur, « Maître », etc.)

Cela dit, votre MCD et votre représentation tabulaire se contredisent. En effet, par conformité à la définition de l’association en E/A (ou en Merise, c’est comme vous voulez), selon ce MCD, pour un îlot I1 et un aspect anthropique A1 donnés, il n’y a qu’un seul type d’observation O1, une seule date D1 et une seule personne P1 : ce n’est pas vraiment ce que dit la représentation tabulaire, selon laquelle pour l’îlot 64 et la catégorie 2, il y a 5 types d’observation et deux personnes. Accessoirement, je note que cette représentation tabulaire est dotée d’un attribut « N° » absent du MCD.

Je pose donc à nouveau la question :

Quelles sont exactement les règles de gestion ?

En effet, si on en a une vague idée à la lecture de la représentation tabulaire, cette dernière ne raconte que quelques faits, et il reste que planent un certain nombre d’incertitudes :

Quel rôle jouent exactement les personnes au sujet des îlots ? Y viennent-elles physiquement ? Travaillent-elles uniquement sur dossier ?

A la date D1, la personne P1 peut-elle « intervenir » sur plusieurs îlots ? (Et quel sens donner au verbe « intervenir » ?)

A la date D1, plus de deux personnes peuvent-elles « intervenir » sur le même îlot I1 ?

Etc., etc.

Suite à une interprétation sémantique que je souhaiterais enfin correcte de ma part, d’un point de vue technique relationnelle cette fois-ci, le but de la manœuvre est aussi (et surtout) de produire l’ensemble des dépendances fonctionnelles inférées des règles de gestion des données caractérisant l’univers des interventions sur les îlots, d’en déduire les tables définitives, leurs clés candidates, de normaliser, bref, de produire une base de données valide. Sans l’intégrale des règles de gestion rigoureusement rédigées, c’est mission impossible.

[chcheibani]

Bonjour François
désolé peut être que je n'ai pas bien expliqué mon problème.

je fait un stage dans une Entreprise qui s'occupe d'espaces Naturels , plus précisément les ilots.

Pour chaque ilots on s'intéresse aux information suivantes : caractéristiques physiques, inventaires protections , les habitats(les plantes qui cohabites dans l'ilot), faune, archéologie, aspects anthropiques, dégradations ....(Donc il y a encore plusieurs tables que j'ai pas donnée dans le model MCD pou simplifier ma question )
donc on peux dire qu'on fait une inventaire sur les ilots et pour chacun des élément que j'ai mentionné on doit enregistrer la date, et la personne qui a fait l'inventaire et en plus ce qu'on a observé

par exemple dans une date donné une ou plusieurs personne sont parti sur un ilot : et ils on remarqué qu'il y a une population occasionnelle dans cette ilot , est un tel type d'activités pour les visiteurs et une listes de Faune etc.

par exemple l'observation concernant la table Aspects Anthropiques c'est juste de dire on a remarqué que cette ilot a une population occasionnelle, et que dans cette ilot les visiteurs pratique une liste d'activité ...

Quelles sont exactement les règles de gestion ?

Pour les régles :
Pour Une ilot donnée on peut avoir une ou plusieurs observation
On peut trouver deux ilots qui on la même observation (par exemple ilot 1 et ilot 2 ont une population occasionnelle ou Ilot 1 et Ilot 3 ont la même liste d'activité de de visiteurs) .

Une Observation peut être faite par plusieurs personnes dan la même date

A la date D1, la personne P1 peut-elle « intervenir » sur plusieurs îlots ? (Et quel sens donner au verbe « intervenir » ?)

Non , c'est pas possible, il faut qu'il soit dans des dates différent,
inter venir est pour moi aller sur un ilot est évaluer certain point ou sujet: une personne part sur un ilot et il dit j'ai remarqué pour l'aspects Anthropiques qu'il y une population occasionnelle et une telle liste d'activité ....etc.

Quel rôle jouent exactement les personnes au sujet des îlots ? Y viennent-elles physiquement ? Travaillent-elles uniquement sur dossier ?

oui les personnes se déplacent physiquement sur les ilots et on enregistre la date de déplacement et ils ont une liste de sujet par exemple pour l'aspects Anthropiques : il vont dire dans on remarqué que dans cette ilot il y a une population occasionnelles (voilà ce que j'appelle une observation )

Vous avez énuméré les différents types d’observation (Population occasionnelle, Population permanente, Population temporaire, etc.), mais sans donner de nom à cette énumération, laquelle devra donc faire l’objet d’une entité-type dans le MCD

ça j'ai pas vraiment compris

Accessoirement, je note que cette représentation tabulaire est dotée d’un attribut « N° » absent du MCD

ça c'est un clé primaire auto incrémenté que j'ai introduis après le passage au MLD au lieu d'utiliser un clé primaire composé de plusieurs attributs.

[fsmrel]

Bonjour chcheibani,


Repartons de votre tableau :



Au vu des données figurant dans la colonne Catégorie, on peut partir sur la mise en oeuvre d’une entité-type qu’on nommera par exemple CATEGORIE, pouvant prendre les valeurs "peuplement", "Activité des visiteurs", "Infrastructures" (typologie, liste non limitative).

Au vu des données figurant dans la colonne Observation, on peut partir sur la mise en oeuvre d’une entité-type qu’on nommera par exemple TYPE_OBSERVATION et pouvant prendre les valeurs "Sans population", « Population permanente", "Population temporaire", "Escalade", "Activités de plage", "Chasse", "Nautisme de plaisance", "Promenade" (typologie, liste non limitative et à enrichir en fonction des besoins des observateurs).

Un point important : Le nautisme de plaisance n’a rien à voir avec le peuplement, c'est-à-dire que, plus généralement, chaque type d’observation fait référence à une et une seule catégorie (cardinalité 1,1 portée par la patte connectant TYPE_OBSERVATION et TYPE_OBS_CAT) :




Maintenant, à une date donnée, plusieurs personnes peuvent participer à un relevé concernant un îlot :





Emboîtons tout ça :





SQL correspondant :

TABLE CATEGORIE

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
CREATE TABLE CATEGORIE 
(
  CategorieId              INT                NOT NULL,
  CategorieLibelle         VARCHAR(45)        NOT NULL,
  CONSTRAINT CATEGORIE_PK PRIMARY KEY (CategorieId)
) ;
 
INSERT INTO CATEGORIE (CategorieId, CategorieLibelle) VALUES (1, 'Peuplement') ;
INSERT INTO CATEGORIE (CategorieId, CategorieLibelle) VALUES (2, 'Activité des visiteurs') ;
INSERT INTO CATEGORIE (CategorieId, CategorieLibelle) VALUES (3, 'Infrastructures') ;
 
SELECT *, '' AS '<= CATEGORIE' FROM CATEGORIE ;

TABLE TYPE_OBSERVATION

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
CREATE TABLE TYPE_OBSERVATION 
(
  TypeObservationId        INT                NOT NULL,
  CategorieId              INT                NOT NULL,
  TypeObservationLibelle   VARCHAR(45)        NOT NULL,
  CONSTRAINT TYPE_OBSERVATION_PK PRIMARY KEY (TypeObservationId),
  CONSTRAINT OBSERVATION_CATEGORIE_FK FOREIGN KEY (CategorieId)
    REFERENCES CATEGORIE (CategorieId)
) ;
 
INSERT INTO TYPE_OBSERVATION (TypeObservationId, CategorieId, TypeObservationLibelle) VALUES (1,1, 'Sans population') ;
INSERT INTO TYPE_OBSERVATION (TypeObservationId, CategorieId, TypeObservationLibelle) VALUES (2,1, 'Population permanente') ;
INSERT INTO TYPE_OBSERVATION (TypeObservationId, CategorieId, TypeObservationLibelle) VALUES (3,1, 'Population temporaire') ;
INSERT INTO TYPE_OBSERVATION (TypeObservationId, CategorieId, TypeObservationLibelle) VALUES (4,2, 'Escalade') ;
INSERT INTO TYPE_OBSERVATION (TypeObservationId, CategorieId, TypeObservationLibelle) VALUES (5,2, 'Activités de plage') ;
INSERT INTO TYPE_OBSERVATION (TypeObservationId, CategorieId, TypeObservationLibelle) VALUES (6,2, 'Chasse') ;
INSERT INTO TYPE_OBSERVATION (TypeObservationId, CategorieId, TypeObservationLibelle) VALUES (7,2, 'Nautisme de plaisance') ;
INSERT INTO TYPE_OBSERVATION (TypeObservationId, CategorieId, TypeObservationLibelle) VALUES (8,2, 'Promenade') ;
 
SELECT *, '' AS '<= TYPE_OBSERVATION' FROM TYPE_OBSERVATION ;

TABLE ILOT

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 ILOT 
(
  IlotId                   INT                NOT NULL,
  IlotNom                  VARCHAR(45)        NOT NULL,
  Etc                      VARCHAR(45)        NOT NULL DEFAULT 'blabla',
  CONSTRAINT ILOT_PK PRIMARY KEY (IlotId)
) ;
 
INSERT INTO ILOT (IlotId, IlotNom) VALUES (62, 'Îlot 62') ;
INSERT INTO ILOT (IlotId, IlotNom) VALUES (64, 'Îlot 64') ;
INSERT INTO ILOT (IlotId, IlotNom) VALUES (96, 'Îlot 96') ;
INSERT INTO ILOT (IlotId, IlotNom) VALUES (2252, 'Îlot 2252') ;
INSERT INTO ILOT (IlotId, IlotNom) VALUES (3000, 'Îlot 3000') ;
 
SELECT *, '' AS '<= ILOT' FROM ILOT ;

TABLE RELEVE

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
CREATE TABLE RELEVE 
(
  RelevéId                 INT                NOT NULL,
  IlotId                   INT                NOT NULL,
  RelevéDate               DATE               NOT NULL,
  Etc                      VARCHAR(45)        NOT NULL DEFAULT 'blabla',
  PRIMARY KEY (RelevéId),
  CONSTRAINT RELEVE_ILOT_FK FOREIGN KEY (IlotId) REFERENCES ILOT (IlotId) ON DELETE CASCADE
) ;
 
INSERT INTO RELEVE (RelevéId, IlotId, RelevéDate) VALUES (1, 2252, '2008-08-13') ;
INSERT INTO RELEVE (RelevéId, IlotId, RelevéDate) VALUES (2, 62, '2008-06-11') ;
INSERT INTO RELEVE (RelevéId, IlotId, RelevéDate) VALUES (4, 96, '2008-09-01') ;
INSERT INTO RELEVE (RelevéId, IlotId, RelevéDate) VALUES (3, 64, '2008-06-27') ;

TABLE PERSONNE

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
CREATE TABLE PERSONNE 
(
  PersonneId               INT                NOT NULL,
  PersonneNom              VARCHAR(45)        NOT NULL,
  PersonnePrenom           VARCHAR(45)        NOT NULL,
  Etc                      VARCHAR(45)        NOT NULL DEFAULT 'blabla',
  CONSTRAINT PERSONNE_PK PRIMARY KEY (PersonneId)
) ;
 
INSERT INTO PERSONNE (PersonneId, PersonneNom, PersonnePrenom) VALUES (1, 'Dutouquet', 'Louis') ;
INSERT INTO PERSONNE (PersonneId, PersonneNom, PersonnePrenom) VALUES (2, 'Hamon', 'Patrick') ;
INSERT INTO PERSONNE (PersonneId, PersonneNom, PersonnePrenom) VALUES (3, 'Volfoni', 'Raoul') ;
 
SELECT *, '' AS '<= PERSONNE' FROM PERSONNE ;

TABLE PARTICIPATION

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
CREATE TABLE PARTICIPATION 
(
  RelevéId                 INT                NOT NULL,
  PersonneId               INT                NOT NULL,
  Etc                      VARCHAR(45)        NOT NULL DEFAULT 'blabla',
  CONSTRAINT PARTICIPATION_PK PRIMARY KEY (RelevéId, PersonneId),
  CONSTRAINT PARTICIPATION_RELEVE_FK FOREIGN KEY (RelevéId)
    REFERENCES RELEVE (RelevéId)
    ON DELETE CASCADE,
  CONSTRAINT PARTICIPATION_PERSONNE_FK FOREIGN KEY (PersonneId)
    REFERENCES PERSONNE (PersonneId)
) ;
 
INSERT INTO PARTICIPATION (RelevéId, PersonneId) VALUES (1, 1) ;
INSERT INTO PARTICIPATION (RelevéId, PersonneId) VALUES (1, 2) ;
INSERT INTO PARTICIPATION (RelevéId, PersonneId) VALUES (2, 1) ;
INSERT INTO PARTICIPATION (RelevéId, PersonneId) VALUES (2, 2) ;
INSERT INTO PARTICIPATION (RelevéId, PersonneId) VALUES (3, 1) ;
INSERT INTO PARTICIPATION (RelevéId, PersonneId) VALUES (3, 2) ;
INSERT INTO PARTICIPATION (RelevéId, PersonneId) VALUES (4, 1) ;
INSERT INTO PARTICIPATION (RelevéId, PersonneId) VALUES (4, 2) ;
 
SELECT *, '' AS '<= PARTICIPATION' FROM PARTICIPATION ;

TABLE OBSERVATION

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
CREATE TABLE OBSERVATION 
(
  RelevéId                 INT                NOT NULL,
  TypeObservationId        INT                NOT NULL,
  Etc                      VARCHAR(45)        NOT NULL DEFAULT 'blabla',
  CONSTRAINT OBSERVATION_PK PRIMARY KEY (RelevéId, TypeObservationId),
  CONSTRAINT OBSERVATION_RELEVE_FK FOREIGN KEY (RelevéId)
    REFERENCES RELEVE (RelevéId)
    ON DELETE CASCADE
    ON UPDATE CASCADE,
  CONSTRAINT OBSERVATION_TYPE_OBSERVATION_FK
    FOREIGN KEY (TypeObservationId)
    REFERENCES TYPE_OBSERVATION (TypeObservationId)
    ON DELETE CASCADE
) ;
 
INSERT INTO OBSERVATION (RelevéId, TypeObservationId) VALUES (1, 1) ;
INSERT INTO OBSERVATION (RelevéId, TypeObservationId) VALUES (2, 2) ;
INSERT INTO OBSERVATION (RelevéId, TypeObservationId) VALUES (4, 3) ;
INSERT INTO OBSERVATION (RelevéId, TypeObservationId) VALUES (3, 4) ;
INSERT INTO OBSERVATION (RelevéId, TypeObservationId) VALUES (3, 5) ;
INSERT INTO OBSERVATION (RelevéId, TypeObservationId) VALUES (3, 6) ;
INSERT INTO OBSERVATION (RelevéId, TypeObservationId) VALUES (3, 7) ;
INSERT INTO OBSERVATION (RelevéId, TypeObservationId) VALUES (3, 8) ;

On recompose votre tableau au moyen d’une vue, jointure naturelle des tables obtenues par dérivation du MCD en MLD :

Vue RELEVES_ASPECTS_ANTRHOPIQUES

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
CREATE VIEW RELEVES_ASPECTS_ANTRHOPIQUES (RelevéDate, IlotNom, CategorieLibelle, TypeObservationLibelle, PersonnePrenom, PersonneNom) AS
 
SELECT RelevéDate, IlotNom, CategorieLibelle, TypeObservationLibelle, PersonnePrenom, PersonneNom
FROM   RELEVE AS x  JOIN ILOT AS y ON x.IlotId = y.IlotId
                    JOIN OBSERVATION AS z ON x.RelevéId = z.RelevéId 
                    JOIN TYPE_OBSERVATION AS t ON z.TypeObservationId = t.TypeObservationId
                    JOIN CATEGORIE AS u ON t.CategorieId = u.CategorieId
                    JOIN PARTICIPATION AS v ON x.RelevéId = v.RelevéId 
                    JOIN PERSONNE AS w ON v.PersonneId = w.PersonneId  
;
SELECT *, '' AS '<= RELEVES_ASPECTS_ANTRHOPIQUES'  FROM RELEVES_ASPECTS_ANTRHOPIQUES 
order by RelevéDate, IlotNom ;

ça j'ai pas vraiment compris

Il s’agit de l’entité-type que j’ai nommée TYPE_OBSERVATION dans le diagramme ci-dessus (voir aussi la table SQL correspondante).

En fait, comme le titre que vous aviez donné à la discussion est le suivant « Normaliser une table », par décomposition, j’ai donc normalisé votre tableau RELEVES_ASPECTS_ANTRHOPIQUES en forme normale de Boyce-Codd.


En ce qui concerne le contrôle de la bilocation des personnes dans les îlots, il faudra résoudre cela au moyen d’une assertion (ou d’un trigger si votre SGBD méconnaît les assertions).


Tend-on vers un MCD à votre convenance ? A défaut, on efface tout et on recommence !

[MeryemDahan]

Bonjour ,
j ai pu realiser ce MCD .
ai une assoriation Heritge des entites client adherent et beneficiare .
est elle clair sur le MCD ?
Mercii pour vos avis.

[chcheibani]

Bonjour François,
Merci Bien pour votre aide, j'en suis très reconnaissant.

j’ai donc normalisé votre tableau RELEVES_ASPECTS_ANTRHOPIQUES en forme normale de Boyce-Codd.

est ce que c'est toujours obligatoire d'arriver à BCNF pour trouver une Base de données bien normalisée ou 3NF suffit pour les base de données petites ou moyennes ?
et pour les Associations qui donnent des tables dans MLD , est ce que c'est mieux d'utiliser un clé primaire absolu auto-incrémenté au lieu de clé composé de plusieurs attributs ?

Tend-on vers un MCD à votre convenance ? A défaut, on efface tout et on recommence !

j'ai appliqué la même logique sur les autres tables dans ma base qui ressemblent à Aspects Anthropiques , et finalement j'ai eu un très grand nombre de tables :

mais, si les utilisateurs qui vont faire des insertions et modifications dans la base ne sont pas des informaticiens , ça va pas créer un peu de problèmes par ce qu' il y a trop de tables donc il faut faire des mises à jour partout ?!!

[fsmrel]

Bonsoir chcheibani,

Est-ce que c'est toujours obligatoire d'arriver à BCNF pour trouver une Base de données bien normalisée ou 3NF suffit pour les base de données petites ou moyennes ?

Le minimum exigible par les tribunaux relationnels est la 1NF... Cela dit, pour s’assurer de la bonne santé de la base de données, la 3NF est le minimum que je me suis toujours imposé ainsi qu’à mes équipes. Il faut viser la BCNF, mais il y a des situations embarrassantes où l’on peut se contenter de la 3NF, à condition de mettre le paquet sur le contrôle des redondances et le respect des règles de gestion qui sont sources de dépendances fonctionnelles. Que les bases de données soient petites ou moyennes ne joue pas, c’est leur validité qui est en cause : il n’y a pas de petite ou moyenne vérité, il y a seulement la vérité et la fausseté...

pour les Associations qui donnent des tables dans MLD , est ce que c'est mieux d'utiliser un clé primaire absolu auto-incrémenté au lieu de clé composé de plusieurs attributs ?

Si, en plus de la clé composée, vous mettez en œuvre une clé primaire auto-incrémentée (cf. votre tableau RELEVES_ASPECTS_ANTHROPIQUES), vous ne pourrez de toute façon pas faire l’impasse sur la définition de la clé composée (rendue alternative). Après bien des années de travail sur des grandes bases de données (1500 tables, dont certaines pouvant atteindre les cent millions de lignes (voire la dizaine de milliards si j’avais écouté les utilisateurs...) j’ai fait le constat que les clés composées offraient bien des avantages, sur le plan de la performance avec mon SGBD de prédilection, DB2. J’effleure ce point ici, mais on déboule dans le domaine du prototypage de performance et c’est quand même hors sujet... Cela dit, vous trouverez sans doute dans la presse du cœur informatique de soi-disant « experts » qui prétendront qu’il faut n’utiliser que des clés mono-attribut.

j'ai appliqué la même logique sur les autres tables dans ma base qui ressemblent à Aspects Anthropiques , et finalement j'ai eu un très grand nombre de tables.

Ce qui, a priori, est le signe d’une normalisation 3NF... Cela dit, si vous voulez présenter quelques cas, on pourra en discuter.

mais, si les utilisateurs qui vont faire des insertions et modifications dans la base ne sont pas des informaticiens , ça va pas créer un peu de problèmes par ce qu' il y a trop de tables donc il faut faire des mises à jour partout ?!!

7 tables ont été définies :

CATEGORIE, TYPE_OBSERVATION, ILOT, RELEVE, PERSONNE, PARTICIPATION, OBSERVATION.

Que ce soit en consultation ou en mise à jour, l’utilisateur n’a accès qu’aux données naturelles. Il n’a pas accès aux clés « techniques » :

CategorieId, TypeObservationId, ilotId, RelevéId, PersonneId, Participationid.

De même, il n’est pas concerné par les associations non porteuses de données.

De son côté, l'urbanisation du modèle devrait permettre de séparer ce qui ne doit pas être mélangé.

Qui plus est, avec un IHM de course, vous devriez pouvoir lui demander quelles sont les données à mettre à jour, sans qu’il ait besoin de savoir comment ça se passe sous le capot, c’est à vous de dispatcher ces données dans les tables à mettre à jour. Je sais, c’est plus facile à dire qu’à faire, mais quand on développe on développe...

Que feriez-vous si vous aviez les 1500 tables à mettre à jour ?

[chcheibani]

Bonjour François,

Si, en plus de la clé composée, vous mettez en œuvre une clé primaire auto-incrémentée (cf. votre tableau RELEVES_ASPECTS_ANTHROPIQUES), vous ne pourrez de toute façon pas faire l’impasse sur la définition de la clé composée (rendue alternative). Après bien des années de travail sur des grandes bases de données (1500 tables, dont certaines pouvant atteindre les cent millions de lignes (voire la dizaine de milliards si j’avais écouté les utilisateurs...) j’ai fait le constat que les clés composées offraient bien des avantages, sur le plan de la performance avec mon SGBD de prédilection, DB2. J’effleure ce point ici, mais on déboule dans le domaine du prototypage de performance et c’est quand même hors sujet... Cela dit, vous trouverez sans doute dans la presse du cœur informatique de soi-disant « experts » qui prétendront qu’il faut n’utiliser que des clés mono-attribut.

par exemple j'ai les deux tables suivantes :

Ilot(id_Ilot,Nom,surface ..etc) ----0-N------ Relevés Avifaune (date, Méthode de prospection ----------1-N--------------Avifaune(Id_Avifaune,Nom,Classe,Ordre,Famille,)

L'association entre ces deux tables veut dire qu'on a observé un tel oiseau dans telle ilot
Un oiseau peux etre vit dans plusieurs ilots, et une ilot peut contenir plusieurs oiseaux.
On enregistre à chaque fois l'oiseau dans chaque nouvelle date (un Oiseau O1 et vit dans une Ilot I1 avec Une date d1 , et le même oiseau O1 dans la même ilot I1 mais avec une date différente d2)

Cela donne une table Relevés Avifaune dans MLD, a comme clé {Id_Ilot,Id_Avifaune}, donc on ne peut plus combiner (Id_Ilot, Id_Avifaune) plus qu'une seule fois si non ça viole la contrainte de clé primaire ?
Pour résoudre ça j'a ajouté un Clé primaire Id relevés Avifaune (comme ça je peux repeter {d_Ilot, Id_Avifaune} avec chaque nouvelle date
Une autre solution, au lieu d'ajouter un nouveau clé primaire je prend { Id_Ilot, Id_Avifaune, date} comme clé primaire composé de trois attributs ?!!

voilà le code SQL de ces tables :

Code SQL :

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

1
2
3
4
5
6
7
8
create table Releves_Avifaune (
     ID_Releves_Avifaune serial not null,
     ID_Avifaune integer not null,
     ID_Ilot integer not null,
     Methodes_Prospection_Releves_Avifaune text ,
     Date_Releves_Avifaune date ,
     unique(ID_Ilot, ID_Avifaune,Date_Releves_Avifaune)
     constraint ID_Releves_Avifaune primary key (ID_Releves_Avifaune));

Code SQL :

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

1
2
3
4
5
6
7
8
create table Releves_Avifaune (
     ID_Releves_Avifaune serial not null,
     ID_Avifaune integer not null,
     ID_Ilot integer not null,
     Methodes_Prospection_Releves_Avifaune text ,
     Date_Releves_Avifaune date ,
     unique(ID_Ilot, ID_Avifaune,Date_Releves_Avifaune)
     constraint ID_Releves_Avifaune primary key (ID_Releves_Avifaune));

Que ce soit en consultation ou en mise à jour, l’utilisateur n’a accès qu’aux données naturelles. Il n’a pas accès aux clés « techniques » :

CategorieId, TypeObservationId, ilotId, RelevéId, PersonneId, Participationid.

De même, il n’est pas concerné par les associations non porteuses de données.

J'ai pas bien saisi ça , si je réalise la base avec trop de table ça va rendre la tâche un peu plus difficile aux utilisateurs qui vont travailler sur la base Après

Qui plus est, avec un IHM de course, vous devriez pouvoir lui demander quelles sont les données à mettre à jour, sans qu’il ait besoin de savoir comment ça se passe sous le capot, c’est à vous de dispatcher ces données dans les tables à mettre à jour. Je sais, c’est plus facile à dire qu’à faire, mais quand on développe on développe...

Que feriez-vous si vous aviez les 1500 tables à mettre à jour ?

ça va être un peu compliqué

[fsmrel]

Bonsoir chcheibani,

un Oiseau O1 et vit dans une Ilot I1 avec Une date d1 , et le même oiseau O1 dans la même îlot I1 mais avec une date différente d2

Le MCD correspondant est donc :



D’où la structure de la table RELEVE_AVIFAUNE :

Code SQL :

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

1
2
3
4
5
6
7
8
9
CREATE TABLE RELEVE_AVIFAUNE 
(
     IlotId INT NOT NULL,
     AviFauneId INT NOT NULL,
     DateReleve date NOT NULL,
     CONSTRAINT RELEVE_AVIFAUNE_PK PRIMARY KEY (IlotId, AviFauneId, DateReleve),
     CONSTRAINT RELEVE_AVIFAUNE_ILOT_FK FOREIGN KEY (IlotId) REFERENCES ILOT (IlotId),
     CONSTRAINT RELEVE_AVIFAUNE_AVIFAUNE_FK FOREIGN KEY (AviFauneId) REFERENCES AVIFAUNE (AviFauneId)
) ;

A noter l’absence d’un attribut tel que ID_Releves_Avifaune, en effet la clé primaire {IlotId, AviFauneId, DateReleve} suffit.

Que ce soit en consultation ou en mise à jour, l’utilisateur n’a accès qu’aux données naturelles. Il n’a pas accès aux clés « techniques » :

CategorieId, TypeObservationId, ilotId, RelevéId, Participationid.

De même, il n’est pas concerné par les associations non porteuses de données.

J'ai pas bien saisi ça, si je réalise la base avec trop de table ça va rendre la tâche un peu plus difficile aux utilisateurs qui vont travailler sur la base Après.

L’utilisateur accède seulement aux données qui l’intéressent, ça n’est pas à lui d’aller voir dans quelles tables se situent ces données, c’est à l’application de le faire, à partir des données voulues. L’utilisateur n’est pas mécanicien et n’a pas à regarder comment ça se passe sous le capot, qu’il s’agisse d’une Ferrari sophistiquée ou d’une simple voiture à pédales...

[chcheibani]

Bonjour,
Merci bien François pour tout ce temps, et pour tous tes conseils.
Mes respects