Modélisation de relations stratigraphique

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:mouarf:)

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...

Bonjour Tom

Quand tu dis :

Citation:

---

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 ?

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:)

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:

---

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.

Citation:

---

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 ! :roll:


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...

Merci pour ces premières idées:ccool:

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

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.

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:

---

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:

---

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

---

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,

@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:oops:

Citation:

---

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.

Bonjour,
Juste une petite remarque,

Code:

---

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

Yo,

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

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:aie::aie:

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

Citation:

---

Envoyé par f-leb

Modéliser une matrice quoi:aie::aie:

---

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

Bonsoir,


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

http://www.fsmwarden.com/developpez_...e_Harris_2.png


Une 1re traduction sous forme de MCD

http://www.fsmwarden.com/developpez_...ie)_MCD_V1.png

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:

---

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:

---

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 ?

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.

Bonjour à tous,

@fsmrel

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

Code:

---

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...:mouarf:

Bonsoir,

Citation:

---

Envoyé par f-leb

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

---

Pampers, bien sûr... :mouarf:

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 :

http://www.fsmwarden.com/developpez_...e_Harris_3.png

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

Bonsoir,


Reprenons l’exemple :

http://www.fsmwarden.com/developpez_...e_Harris_3.png

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 :

http://www.fsmwarden.com/developpez_...Harris_3_1.png

E2 :

http://www.fsmwarden.com/developpez_...Harris_3_2.png

E3 :

http://www.fsmwarden.com/developpez_...Harris_3_3.png

E4 :

http://www.fsmwarden.com/developpez_...Harris_3_4.png

E5 :

http://www.fsmwarden.com/developpez_...Harris_3_5.png

E6 :

http://www.fsmwarden.com/developpez_...Harris_3_6.png

E7 :

http://www.fsmwarden.com/developpez_...Harris_3_7.png

E8 :

http://www.fsmwarden.com/developpez_...Harris_3_8.png


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:

---

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:

---

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:

---

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:

---

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:

---

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:

---

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:

---

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:

---

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:

---

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:

---

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:

---

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:

---

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:

---

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:

---

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 :

http://www.fsmwarden.com/developpez_...s_3_graphe.png

Code:

---

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:

---

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 :

Citation:

---

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.

Citation:

---

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:

---

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 

Citation:

---

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.


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

Hello,


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