Modélisation de relations stratigraphique

**Tom_37** · 07/04/2013, 17h28

Bonjour,

Je suis assez nouveau dans le monde d'Access mais j'ai eu la chance d'avoir des cours à la fac qui me sont resté du coup, j'ai monté une base de donnée sans avoir trop de souci (et puis en cherchant un peu, on trouve générale la réponse a ses soucis

)

La, j'ai un peit souci qui dépasse largement mes compétences et je vais essayer de l'exposer le plus clairement possible.

En tant qu'archéologue, je mets au jour des vestiges qui se trouvent sous des couches de terre qu'on individualise par un numéro arbitraire au fur et a mesure qu'on les trouve. Parfois, certaine couches sont identifiées après coup, tout ça n'est pas linéaire.

Quoi qu'il en soit, j'ai une table dans ma base de donnée avec les champs matricule_operation (identifiant de la couche strati) et les champs "anterieur_a" (identifiant de la ou des couche située au-dessus) et "postérieur_a" (identifiant de la ou des couche située en-dessous).

pour l'instant, quand je rentre les données, il s'agit d'une simple saisie comme on pourrait le faire sur une feuille de papier. ce que je voudrais, c'est :

1. Exercer un contrôle sur la saisie. En gros, si j'ai enregistré que la couche 1 est sur la couche 2, il faut que lorsque j'enregistre la couche 2 que je ne puisse pas entrer qu'elle est sur la couche 1 (je la fait simple pour l'exemple car quand on a 500 couche, impossible de se rappeler de tout..)
2. Cumuler les enregistrements. c'est-a-dire que si je lui ai dit que la couche 1 était sur la couche 2 et que la couche 2 est sur la couche 3 alors, la base doit pouvoir me restituer que la couche 1 est sur la couche 3.
3. gérer l'égalité car 2 couches fouillée en 2 endroits différents peuvent correspondre a 2 partie d'un même vestige mais, pour des raison de compréhension, on leur a donné 2 numéro différents.

Voila, c'est tout pour le moment, j'espère avoir été assez clair sinon, je peux éclaircir certains points si vous voulez...

**mumen** · 08/04/2013, 11h53

Bonjour Tom

Quand tu dis :

3. gérer l'égalité car 2 couches fouillée en 2 endroits différents peuvent correspondre a 2 partie d'un même vestige mais, pour des raison de compréhension, on leur a donné 2 numéro différents.

Cela signifie t'il qu'une même couche peut être nommée de deux façons différentes et par conséquent, qu'il peut y avoir deux enregistrements dans la table des couches pour la même couche fouillée à deux endroits différents ?

**Tom_37** · 08/04/2013, 12h00

effectivement, il arrive qu'on fouille une même couche (ou ce qu'on suppose être une même couche) et qu'on lui donne 2 numéro car elles se différencient par leur localisation sur le site ce qui est important pour nous pour la localisation des artéfacts qu'elle contient (en gros, si on fouille une rue sur 2 km de long, on sait que c'ets la même rue mais il est important de savoir d'ou viennent les monnaie qu'on a trouvé lors de la fouille de chaque tronçon pour voir s'il y a une évolution, si on ne donne qu'un numéro, on perd cette info importante pour nous).

Merci de ton intérêt pour la chose

**mumen** · 08/04/2013, 12h15

En dehors du premier problème qui indiquera si tu as une ou deux entités pour saisir tes couches, en considérant donc que tu as une table des couches physiques, la modélisation devrait être quelque chose comme :

Un couche connaît sa couche précédente, la première n'en ayant pas.

Code :

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

1
2
3
4
Couche
    IdCouche  : clé primaire autoincrémentée
    NomCouche : Texte
    IdCouchePrécédente : champ de même type que IdCouche

Pour le champ IdCouchePrécédente, tu déclares une liste de choix sur la table Couche.

Une couche ne peut avoir qu'une et une seule couche suivante, donc la relation définie par IdCouchePrécédente est de type 1 à 1. Pour déclarer ceci, IdCouchePrécédente doit être unique.

Tu auras un problème pour l'insertion d'une couche entre deux autres, que tu devras régler dans un deuxième temps au moment de la création de ton formulaire.

**mumen** · 08/04/2013, 12h22

Envoyé par Tom_37

effectivement, il arrive qu'on fouille une même couche (ou ce qu'on suppose être une même couche) et qu'on lui donne 2 numéro car elles se différencient par leur localisation sur le site ce qui est important pour nous pour la localisation des artéfacts qu'elle contient (en gros, si on fouille une rue sur 2 km de long, on sait que c'ets la même rue mais il est important de savoir d'ou viennent les monnaie qu'on a trouvé lors de la fouille de chaque tronçon pour voir s'il y a une évolution, si on ne donne qu'un numéro, on perd cette info importante pour nous).

Merci de ton intérêt pour la chose

J'ai d'inoubliables souvenirs de fouilles archéologiques dans mon jeune temps !

Donc, si tu veux bosser proprement, tu vas avoir deux entités, que je nomme vite fait Couche physique et Couche locale. Ta couche physique sera en relation avec la couche locale de façon qu'une couche physique puisse avoir 0 à n couches locales. En sachant que le tri que tu cherches à réaliser a lieu sur la couche physique.

Se lève un problème pour toi, c'est que tu ne distingue pas encore ces deux entités et que tu ne nomme pour l'instant que la couche locale...

**Tom_37** · 08/04/2013, 12h25

Merci pour ces premières idées

Dans mon explication, j'ai essayé d'être le plus clair possible mais j'ai peut-etre trop simplifié le problème :

1. cas simple : une couche se trouve sur une et une seule meme couchouche
2. cas médian : une couche se trouve sur plusieurs couches
3. cas complexe : une couche se trouve d'un coté sur une couche et de l'autre sur plusieurs.

Pour être plus explicite sur notre manière d'enregistrer les choses, voici un lien vers la matrice de Harris avec des graphique plus clair que mon charabia... http://en.wikipedia.org/wiki/Harris_matrix

**Tom_37** · 08/04/2013, 12h29

je crois comprendre ton argumentation sur les couche locale et couche physique. En fait, on fait ça dans un deuxième temps, on crée des agrégations de toute les couches qui corresponde a un même événement (construction d'une route, d'un batiment, etc..) et ce qui m'interesse, c'est, d'abord, les relation entre ces différentes couches, puis leur agrégation.

**mumen** · 08/04/2013, 12h52

Ca change tout.

Couche (layer) n'est le terme consacré pour ton problème... C'est contexte (context) et cela change tout, donc ta relation, c'est du n à n entre contextes.

Code :

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

1
2
3
4
5
6
7
Contexte
   IdContexte
   Nom
 
RelationContexte
   IdContexte1
   IdContexte2

Certains éléments du contexte peuvent être des couches, que tu peux peut être gérer comme je te l'ai indiqué.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
Contexte
   IdContexte
   Nom
   IdCouche : non requis
 
RelationContexte
   IdContexte1
   IdContexte2
 
Couche
    IdCouche
    NomCouche
    IdCouchePrécédente : non requis, unique

**Philippe PONS** · 08/04/2013, 13h13

Bonjour,

J'ai trouvé ces 2 liens sur les matrices de Harris:

http://arbela.uoa.gr/index.php?optio...mid=41&lang=en

http://www.iadb.org.uk/

Mais j'ai pas le temps d'investiguer plus!!

Cordialement,

**Tom_37** · 08/04/2013, 15h10

@Philippe PONS : merci pour les liens que je ne connaissais pas. j'ai donné le lien vers la matrice de harris pour illustrer une partie de mon travail qui correspond a mon problème. La base de donnée dépasse largement ce cadre puiqu'elle prend en compte les batiment, les photographies, la documentation graphique, les artefact, etc...

@numen : j'avoue ne plus te suivre quand tu parle de relationContexte

**mumen** · 08/04/2013, 15h31

j'avoue ne plus te suivre quand tu parle de relationContexte

C'est une tentative, finalement non pertinente, de structurer ton problème. Enlève la relationContexte et vois ce que tu as.

**Robert1957** · 09/04/2013, 16h12

Bonjour,
Juste une petite remarque,

Code :

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

3. cas complexe : une couche se trouve d'un coté sur une couche et de l'autre sur plusieurs.

Implique qu'il faut identifier un coté et l'autre pour pouvoir faire association donc c'est dire qu'une couche peut avoir plusieurs noms. ex couche 1 est, couche 1 ouest.
Bonne journée

**f-leb** · 09/04/2013, 22h29

Yo,

on en apprend tous les jours sur ce forum et pas seulement sur Access. Aujourd'hui la stratigraphie et les matrices de Harris

Alors j'ai trouvé un truc du style matrice de Harris pour les nuls.

A bien regarder, je me demande si on ne pourrait pas modéliser un tableau avec les numéros de couche à l'intersection ligne/colonne du tableau.

Modéliser une matrice quoi

quoique pas simple d'après cet article à creuser

**fsmrel** · 11/04/2013, 15h49

Envoyé par f-leb

Modéliser une matrice quoi

Ce sont des choses qui se pratiquent, voir par exemple ici...

**fsmrel** · 12/04/2013, 03h58

Bonsoir,

A partir du diagramme proposé dans l’article (ouch !) auquel f-leb fait référence :

Une 1re traduction sous forme de MCD

Où l’attribut NatureLien de l’association GRAPHE prend par exemple soit la valeur '' (vide), soit la valeur '=' pour noter l’équivalence (cas des cases 7 et 8 ci-dessus).

Version SQL :

Table COUCHE

Code SQL :

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

1
2
3
4
5
6
7
CREATE TABLE COUCHE 
(
   CoucheId             Int                  NOT NULL,
   CoucheNom            Varchar(64)          NOT NULL,
   CoucheObservations   Varchar(64)          NOT NULL   DEFAULT ''
   CONSTRAINT COUCHE_PK PRIMARY KEY (CoucheId)
) ;

Table GRAPHE

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE TABLE GRAPHE 
(
   CoucheId             Int                  NOT NULL,
   CoucheParenteId      Int                  NOT NULL,
   NatureLien           Char(1)              NOT NULL DEFAULT '',
   Observations         Varchar(64)          NOT NULL DEFAULT '',
   CONSTRAINT GRAPHE_PK PRIMARY KEY (CoucheId, CoucheParenteId),
   CONSTRAINT GRAPHE_COUCHE_FK1 FOREIGN KEY (CoucheId)
      REFERENCES Couche,
   CONSTRAINT GRAPHE_COUCHE_FK2 FOREIGN KEY (CoucheParenteId)
      REFERENCES Couche,
   CONSTRAINT GRAPHE_TYPE_CHK CHECK (NatureLien IN ('=', ''))
) ;

Contenu injecté :

Table COUCHE

CoucheId    CoucheNom    CoucheObservations
       1    couche 1
       2    couche 2
       3    couche 3 
       4    couche 4 
       5    couche 5 
       6    couche 6 
       7    couche 7 
       8    couche 8 
       9    couche 9

Table GRAPHE

CoucheId    CoucheParenteId    NatureLien    Observations
       2                  1 
       3                  1 
       4                  1 
       5                  2 
       5                  3 
       5                  4 
       6                  5 
       7                  6 
       8                  7    =  
       9                  8

La paire <8, 6> n’est pas présente dans la table car inférable des paires <8, 7> et <7, 6>.

Mais probablement le MCD proposé est-il à aménager au motif de besoins supplémentaires ?

**chrtophe** · 12/04/2013, 10h36

Si j'ai bien compris, ta base doit permettre de repérer la position d'un objet dans le sol (voire d'autres infos ).

Le point de repère d'un objet est sa strate. Je présumes que les recherches se se font pas de façon linéaire.

Je proposes d'utiliser un système qu'en programmation on appelle liste chainée.

je m'expliques :

N'ayant aucune connaissance en géologie ni en archéologie,je présumes q'une strate correspond à une couche du sol de profondeur x à y .

Je présumes que tu te repère par quadrillage.
Imaginons les recherches dans le sol par un système xyz.
la 1ere couche a pour coordonnées z 0,la couche e ndessous1 etc..
au fur et à mesure que tu descent le numéro augmente,la couche 5 est inferieur à 3,4 donc au dessus 7,9 supérieur donc en dessous.

ensuite pour les coordonnées x,y même système de repère dans le "cube" virtuel

Tu peux "calculer" dans quel cube tu te trouve via les mesures fournies par les géomètres, algorithme à adapter selon le format des mesures

Tu peux aussi faire un assemblage de "sous-cubes" sur les 3 axes

Si 1strate contient aussi des données x,y et pas seulement profondeur, à partir des coordonnées,tu peux savoir si une position est à cheval sur plusieurs strates.

**f-leb** · 12/04/2013, 20h56

Bonjour à tous,

@fsmrel

Je ne suis pas sûr que cette modélisation soit suffisante mais comme vous dîtes, ouch !

Code :

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

1
2
3
4
CoucheId    CoucheParenteId    NatureLien    Observations
     2               1 
     3               1 
     4               1

Le modèle montre en effet que les couches 2, 3 et 4 ont la même couche parente 1 mais dans le graphe exemple que vous proposez, les couches 3 et 4 sont représentées "au même niveau" ce qui semble signifier que ces deux couches soient liées à un même évènement géologique (et que peut-être elles constituent une seule et même couche). La couche 2 étant représentée graphiquement "au-dessus" des couches 3 et 4, l'évènement géologique serait survenu après la formation des couches 3 et 4.

Je vous raconte ça, mais vous savez, entre moi et la stratigraphie il y a des kilomètres de couches...

**fsmrel** · 13/04/2013, 03h14

Bonsoir,

Envoyé par f-leb

Entre moi et la stratigraphie il y a des kilomètres de couches...

Pampers, bien sûr...

Pour en revenir aux couches 3 et 4, si elles étaient synchrones, la valeur de la table serait la suivante :

Table GRAPHE

CoucheId    CoucheParenteId    NatureLien    Observations
       2                  1 
       3                  1 
       4                  3    =  
       5                  2 
       5                  3 
       5                  4 
       6                  5 
       7                  6 
       8                  7    =  
       9                  8

A noter que la paire <5, 3> giclerait (comme aurait dit Guillaume d’Ockham) puisqu’inférable de <5, 4> et <4, 3>.

Maintenant, de ce que j’ai compris du diagramme du gars Harris (fort bien expliqué ici, la numérotation correspond à l’ordre des découvertes des US (unités stratigraphiques), les traits verticaux aux relations d’antéro-postériorité de ces US et les traits horizontaux à leur synchronisme ; la position surélevée de 2 par rapport à 3 et 4 dans le schéma n’est pas à interpréter, il n'a pas été établi (oubli ou volonté) de relation d’antériorité entre 2 et 3 (ou 4). Le graphe final n’est jamais que la synthèse non redondante, débarrassée de toute transitivité de différents graphes dans lesquels l’US 2 n’est jamais mise en relation avec les US 3 et 4 :

Mais peut-être me suis-je planté sur toute la ligne, à Tom de se prononcer...

**fsmrel** · 14/04/2013, 23h55

Bonsoir,

Reprenons l’exemple :

Le diagramme de droite est la synthèse des diagrammes de gauche. On peut penser que le but de manœuvre est de ne pas procéder manuellement à cette synthèse, surtout si le nombre d’unités stratigraphiques est élevé, une poule n’y retrouverait pas ses poussins... On va donc essayer d’automatiser cela au moyen de SQL...

Supposons que les pièces du puzzle, les sous-ensembles à tricoter soient les suivants :

E1 :

E2 :

E3 :

E4 :

E5 :

E6 :

E7 :

E8 :

A chaque sous-ensemble, on peut affecter une table SQL sur le modèle de la table GRAPHE (aux erreurs de copier/coller près) :

Table E1

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 E1
(
        CoucheId             Int           Not Null 
      , CoucheParenteId      Int           Not Null
      , NatureLien           Char(1)       Not Null DEFAULT ''
   , PRIMARY KEY (CoucheId, CoucheParenteId) 
) ;
INSERT INTO E1 (CoucheId, CoucheParenteId) VALUES (2, 1) ;
INSERT INTO E1 (CoucheId, CoucheParenteId) VALUES (3, 1) ;
INSERT INTO E1 (CoucheId, CoucheParenteId) VALUES (4, 1) ;
INSERT INTO E1 (CoucheId, CoucheParenteId) VALUES (5, 1) ;
INSERT INTO E1 (CoucheId, CoucheParenteId) VALUES (6, 1) ;
INSERT INTO E1 (CoucheId, CoucheParenteId) VALUES (7, 1) ;
INSERT INTO E1 (CoucheId, CoucheParenteId) VALUES (8, 1) ;

Table E2

Code SQL :

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

1
2
3
4
5
6
7
8
CREATE TABLE E2
(
        CoucheId             Int           Not Null 
      , CoucheParenteId      Int           Not Null
      , NatureLien           Char(1)       Not Null DEFAULT ''
   , PRIMARY KEY (CoucheId, CoucheParenteId) 
) ;
INSERT INTO E2 (CoucheId, CoucheParenteId) VALUES (5, 2) ;

Table E3

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
CREATE TABLE E3
(
        CoucheId             Int           Not Null 
      , CoucheParenteId      Int           Not Null
      , NatureLien           Char(1)       Not Null DEFAULT ''
   , PRIMARY KEY (CoucheId, CoucheParenteId) 
) ;
INSERT INTO E3 (CoucheId, CoucheParenteId) VALUES (5, 3) ;
INSERT INTO E3 (CoucheId, CoucheParenteId) VALUES (6, 3) ;
INSERT INTO E3 (CoucheId, CoucheParenteId) VALUES (7, 3) ;
INSERT INTO E3 (CoucheId, CoucheParenteId) VALUES (9, 3) ;

Table E4

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
CREATE TABLE E4
(
        CoucheId             Int           Not Null 
      , CoucheParenteId      Int           Not Null
      , NatureLien           Char(1)       Not Null DEFAULT ''
   , PRIMARY KEY (CoucheId, CoucheParenteId) 
) ;
INSERT INTO E4 (CoucheId, CoucheParenteId) VALUES (5, 4) ;
INSERT INTO E4 (CoucheId, CoucheParenteId) VALUES (6, 4) ;
INSERT INTO E4 (CoucheId, CoucheParenteId) VALUES (8, 4) ;
INSERT INTO E4 (CoucheId, CoucheParenteId) VALUES (9, 4) ;

Table E5

Code SQL :

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

1
2
3
4
5
6
7
8
9
CREATE TABLE E5
(
        CoucheId             Int           Not Null 
      , CoucheParenteId      Int           Not Null
      , NatureLien           Char(1)       Not Null DEFAULT ''
   , PRIMARY KEY (CoucheId, CoucheParenteId) 
) ;
INSERT INTO E5 (CoucheId, CoucheParenteId) VALUES (6, 5) ;
INSERT INTO E5 (CoucheId, CoucheParenteId) VALUES (9, 5) ;

Table E6

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
CREATE TABLE E6
(
        CoucheId             Int           Not Null 
      , CoucheParenteId      Int           Not Null
      , NatureLien           Char(1)       Not Null DEFAULT ''
   , PRIMARY KEY (CoucheId, CoucheParenteId) 
) ;
INSERT INTO E6 (CoucheId, CoucheParenteId) VALUES (7, 6) ;
INSERT INTO E6 (CoucheId, CoucheParenteId) VALUES (8, 6) ;
INSERT INTO E6 (CoucheId, CoucheParenteId) VALUES (9, 6) ;

Table E7

Code SQL :

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

1
2
3
4
5
6
7
8
9
CREATE TABLE E7
(
        CoucheId             Int           Not Null 
      , CoucheParenteId      Int           Not Null
      , NatureLien           Char(1)       Not Null DEFAULT ''
   , PRIMARY KEY (CoucheId, CoucheParenteId) 
) ;
INSERT INTO E7 (CoucheId, CoucheParenteId, NatureLien) VALUES (8, 7, '=') ;
INSERT INTO E7 (CoucheId, CoucheParenteId) VALUES (9, 8) ;

Table E8

Code SQL :

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

1
2
3
4
5
6
7
8
9
CREATE TABLE E8
(
        CoucheId             Int           Not Null 
      , CoucheParenteId      Int           Not Null
      , NatureLien           Char(1)       Not Null DEFAULT ''
   , PRIMARY KEY (CoucheId, CoucheParenteId) 
) ;
INSERT INTO E8 (CoucheId, CoucheParenteId, NatureLien) VALUES (7, 8, '=') ;
INSERT INTO E8 (CoucheId, CoucheParenteId) VALUES (9, 7) ;

A l’aide de l’entonnoir ad-hoc (l’opérateur UNION), collectons tout cela dans un seau :

Code SQL :

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

1
2
3
4
5
6
7
CREATE TABLE SEAU
(
        CoucheId             Int           Not Null 
      , CoucheParenteId      Int           Not Null
      , NatureLien           Char(1)       Not Null DEFAULT ''
   , PRIMARY KEY (CoucheId, CoucheParenteId) 
) ;

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
INSERT INTO SEAU
    SELECT * FROM E1
   UNION
    SELECT * FROM E2
   UNION
    SELECT * FROM E3
   UNION
    SELECT * FROM E4
   UNION
    SELECT * FROM E5
   UNION
    SELECT * FROM E6
   UNION
    SELECT * FROM E7
   UNION
    SELECT * FROM E8

S’il y en a, les doublons les plus simples auront disparu. On peut aussi faire le ménage dans ceux qui correspondent aux unités stratigraphiques synchrones :

SEAU

    CoucheId    CoucheParenteId    NatureLien
         ...                ...    ... 
           7                  8    =
           8                  7    =
         ...                ...    ...

Une requête possible pour y parvenir :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
DELETE FROM SEAU
       WHERE CoucheId = 
          (SELECT x.CoucheId
           FROM   SEAU AS x JOIN SEAU AS y 
               ON x.CoucheId = y.CoucheParenteId
               AND x.CoucheParenteId = y.CoucheId
               AND x.CoucheId < y.CoucheId)    
       AND  CoucheParenteId = 
          (SELECT x.CoucheParenteId
           FROM   SEAU AS x JOIN SEAU AS y 
               ON x.CoucheId = y.CoucheParenteId
               AND x.CoucheParenteId = y.CoucheId
               AND x.CoucheId < y.CoucheId) ;

Le contenu du seau devient le suivant (la paire <7, 8> a été supprimée) :

SEAU

    CoucheId    CoucheParenteId    NatureLien
           2                  1 
           3                  1 
           4                  1 
           5                  1 
           5                  2 
           5                  3 
           5                  4 
           6                  1 
           6                  3 
           6                  4 
           6                  5 
           7                  1 
           7                  3 
           7                  6 
           8                  1 
           8                  4 
           8                  6 
           8                  7    =
           9                  3 
           9                  4 
           9                  5 
           9                  6 
           9                  7 
           9                  8

Il y aurait d’autres contrôles à effectuer, par exemple rechercher les boucles infinies :

Code SQL :

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

1
2
3
4
SELECT *
FROM   SEAU AS x JOIN SEAU AS y
           ON x.CoucheId = y.CoucheParenteId
           AND x.CoucheParenteId = y.CoucheId ;

Etc.

Une fois éliminées les anomalies, on peut s’intéresser aux redondances « normales », c'est-à-dire les liens transitifs présents dans le seau, dus à la pluralité des sous-ensembles initiaux :

Code SQL :

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

1
2
3
4
5
6
7
CREATE TABLE REDONDANCE
(
        CoucheId             Int           Not Null 
      , CoucheParenteId      Int           Not Null
      , NatureLien           Char(1)       Not Null DEFAULT ''
   , PRIMARY KEY (CoucheId, CoucheParenteId) 
) ;

Code SQL :

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

1
2
3
4
5
6
7
8
9
INSERT INTO REDONDANCE (CoucheId, CoucheParenteId)
    SELECT DISTINCT x.CoucheId, z.CoucheParenteId   
    FROM   SEAU AS x JOIN SEAU AS y ON x.CoucheId = y.CoucheId 
                      JOIN SEAU AS z ON x.CoucheParenteId = z.CoucheId
                                     AND y.CoucheParenteId = z.CoucheParenteId
    WHERE x.NatureLien = ''
      AND y.NatureLien = ''
      AND z.NatureLien = ''
;

On peut enfin produire la table GRAPHE dont le contenu reflètera le diagramme :

Code SQL :

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

1
2
3
4
5
6
7
CREATE TABLE GRAPHE
(
        CoucheId             Int           Not Null 
      , CoucheParenteId      Int           Not Null
      , NatureLien           Char(1)       Not Null DEFAULT ''
   , PRIMARY KEY (CoucheId, CoucheParenteId) 
) ;

Code SQL :

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

1
2
3
4
INSERT INTO GRAPHE
    SELECT * FROM SEAU
   EXCEPT 
    SELECT * FROM REDONDANCE ;

GRAPHE

    CoucheId    CoucheParenteId    NatureLien
           2    1                  
           3    1 
           4    1 
           5    2 
           5    3 
           5    4 
           6    5 
           7    6 
           8    6 
           8    7                 =
           9    7 
           9    8

Pour en revenir aux problèmes exposés initialement par Tom :

Envoyé par Tom_37

1. Exercer un contrôle sur la saisie. En gros, si j'ai enregistré que la couche 1 est sur la couche 2, il faut que lorsque j'enregistre la couche 2 que je ne puisse pas entrer qu'elle est sur la couche 1 (je la fait simple pour l'exemple car quand on a 500 couche, impossible de se rappeler de tout..)

Je pense qu’avec les contrôles proposés, il y a des éléments de réponse.

Envoyé par Tom_37

2. Cumuler les enregistrements. c'est-a-dire que si je lui ai dit que la couche 1 était sur la couche 2 et que la couche 2 est sur la couche 3 alors, la base doit pouvoir me restituer que la couche 1 est sur la couche 3.

On peut par exemple en passer par une CTE (Common Table Expression) avec jointure récursive (Mikedavem a certainement mieux avec un « FOR XML PATH »).

Avec SQL Server (avec ACCESS je ne sais pas, passer par appels récursifs de modules ?) :

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
WITH DESCENDANCE (CoucheId, CoucheParenteId, Niveau, Chemin) AS
   ((SELECT CoucheId, CoucheParenteId, 1
         , CASE NatureLien 
               WHEN '' THEN CAST(CoucheParenteId AS Varchar(MAX)) + '>' + CAST(CoucheId AS Varchar(MAX))
               ELSE CAST(CoucheParenteId AS Varchar(MAX)) + '=' + CAST(CoucheId AS Varchar(MAX))  
           END   
     FROM   GRAPHE
     WHERE  CoucheParenteId = 1)
  UNION ALL
   (SELECT y.CoucheId, y.CoucheParenteId, Niveau + 1
         , CASE NatureLien 
               WHEN '' THEN CAST(Chemin + '>' + CAST(y.CoucheId AS Varchar(MAX)) AS Varchar(MAX))  
               ELSE CAST(Chemin + '=' + CAST(y.CoucheId AS Varchar(MAX)) AS Varchar(MAX))
           END
    FROM   DESCENDANCE AS x JOIN GRAPHE AS y
              ON x.CoucheId = y.CoucheParenteId
              AND x.CoucheParenteId <> y.CoucheId))   
SELECT Chemin
FROM   DESCENDANCE
-- Facultativement, pour réduire le nombre de lignes :
WHERE  NOT EXISTS 
                 (SELECT ''
                  FROM   DESCENDANCE AS y
                  WHERE  LEN(DESCENDANCE.Chemin) <  LEN(y.Chemin)
                  AND    DESCENDANCE.Chemin = SUBSTRING(y.Chemin, 1,LEN(DESCENDANCE.Chemin))
                 )
ORDER BY Chemin ;

=>

Chemin
1>2>5>6>7=8>9
1>2>5>6>7>9
1>2>5>6>8>9
1>3>5>6>7=8>9
1>3>5>6>7>9
1>3>5>6>8>9
1>4>5>6>7=8>9
1>4>5>6>7>9
1>4>5>6>8>9

Envoyé par Tom_37

3. gérer l'égalité car 2 couches fouillée en 2 endroits différents peuvent correspondre a 2 partie d'un même vestige mais, pour des raison de compréhension, on leur a donné 2 numéro différents.

Ceci a été traité avec le cas des couches 7 et 8.

Allo Tom ? commence-t-on à répondre à vos interrogations ?

**fsmrel** · 16/04/2013, 16h43

Hello,

No news? Je pense pourtant qu'il y a matière à causer...

Modélisation de relations stratigraphique

Modélisation

Discussions similaires

Partager

Partager