Discussion :

[essence-ciel]

Bonjour,
Merci pour toutes ces réponses, je vais me pencher dessus pour tester les différentes options PK, NN...

Pour les fichiers, malgré un ZIP, cela ne passe pas... le sablier tourne sans fin... j'ai transmis le ZIP à SergioMaster.

Je pars au boulot mais j'envoie les fichiers format SQL comme demandé.

[essence-ciel]

Bonjour,

Voici les descripteurs de fichiers :

NOTA : n'étant pas familier du SQL, les types et longueur de champs des tables sont identiques à celles tournant sous Paradox/BDE.

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
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
CREATE TABLE AFFECTIONS (
    Num       INTEGER      PRIMARY KEY ASC AUTOINCREMENT,
    AFFECTION VARCHAR (75) 
);
 
CREATE INDEX AFFECTIONS_NDX1 ON AFFECTIONS (
    AFFECTION ASC
);
 
CREATE TABLE HEINDIC (
    NUM    INTEGER,
    NUMM   NUMERIC     REFERENCES PRODUITS (NUMM) ON DELETE CASCADE
                                                  ON UPDATE CASCADE,
    INDIC  STRING (75),
    REM    STRING (25),
    ORGANE STRING (25),
    CT     STRING (40),
    VVT    STRING (5),
    EFF    CHAR (1),
    COMPL  STRING (25) 
);
 
Merci de vos observations.
 
CREATE INDEX HEINDIC_NDX1 ON HEINDIC (
    NUMM ASC
);
 
CREATE INDEX HEINDIC_NDX2 ON HEINDIC (
    NUMM ASC,
    INDIC ASC,
    REM ASC,
    ORGANE ASC,
    COMPL ASC
);
 
CREATE TABLE PRODUITS (
    Num         INTEGER     PRIMARY KEY ASC AUTOINCREMENT,
    NOM         STRING (75),
    NUMM        INTEGER,
    AY          STRING (5),
    EN          STRING (5),
    EF          STRING (5),
    HA          STRING (5),
    HE          STRING (5),
    HV          STRING (5),
    GE          STRING (5),
    PL          STRING (5),
    TM          STRING (5),
    LIEU        STRING (70),
    PARTIE      STRING (70),
    ENDEMIC     STRING (5),
    VT          STRING (5),
    TOXIC       STRING (5),
    PARTIETOXIC STRING (75),
    IRRIT       STRING (5),
    [FEM-ENC]   STRING (5),
    [BB-ENF]    STRING (5),
    EPIL        STRING (5),
    [CONT-TH]   STRING (5),
    CANCER      STRING (5),
    PSOLAIRE    STRING (5),
    HSECHE      STRING (5),
    CHEMO       STRING (5) 
);
 
CREATE INDEX PRODUITS_NDX ON PRODUITS (
    NOM ASC
);
 
CREATE INDEX PRODUITS_NDX1 ON PRODUITS (
    NUMM ASC
);

[SergioMaster]

Bonjour,

Pour les fichiers, malgré un ZIP, cela ne passe pas... le sablier tourne sans fin... j'ai transmis le ZIP à SergioMaster.

Je pourrais faire de l'humour graveleux , j'en resterai à c'est un problème de taille (721 ko le zip)

Première constatation : c'est un problème de données (au cours de la migration), oui je sais c'est cliché ,d'ailleurs en voici un



Tu nous a indiqué que la relation se faisait dans les deux tables en fonction de la colonne NUMM, si j'ai bien compris la demande, le SQL doit correspondre à la recherche.
J'ai l'impression que la relation est plutôt HEINDIC.NUMM - PRODUIT.NUM

Je ne me suis pas plongé (vu l'heure) dans la structure des tables un autre truc me saute quand même aux yeux quand je regarde la colonne PRODUIT.NUMM affichée avec un format différent (séparation de milliers)

j'ai fait un autre test

j'y vois d'affreux staphylocoques mais surtout d'affreuses redondances
Désolé si le pré diagnostic est rude.

[fsmrel]

Bonjour les enfants,

Vu le script de création des tables.

Pour le moment :

La colonne NUMM de table HEINDIC est du type NUMERIC et la colonne NUMM de la table PRODUIT est du type INTEGER. Ces deux colonnes n’étant pas du même type, selon la norme SQL on ne peut donc pas mettre en oeuvre de clé étrangère telle que HEINDIC fasse référence à PRODUIT. En outre, la référence n’est théoriquement possible que si la colonne NUMM de table PRODUIT est clé alternative (contrainte UNIQUE) à défaut d’être clé primaire.

La table HEINDIC n’a pas de clé primaire, elle n’est donc qu’un sac à tuples, il faut impérativement corriger le tir.

Utiliser NOT NULL pour chaque colonne de chaque table (selon la norme SQL, en sont dispensées les colonnes composant les clés primaires, car NOT NULL est alors implicite).

[SergioMaster]

Bonjour pépé

sur ce que m'a fourni essence-ciel j'ai

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
42
43
44
45
46
47
48
49
50
51
 
CREATE TABLE AFFECTIONS (
    Num       INTEGER      PRIMARY KEY ASC AUTOINCREMENT,
    AFFECTION VARCHAR (75) 
);
 
CREATE TABLE PRODUITS (
    Num         INTEGER     PRIMARY KEY ASC AUTOINCREMENT
                            NOT NULL,
    NOM         STRING (75) NOT NULL,
    NUMM        INTEGER     NOT NULL,
    AY          STRING (5),
    EN          STRING (5),
    EF          STRING (5),
    HA          STRING (5),
    HE          STRING (5),
    HV          STRING (5),
    GE          STRING (5),
    PL          STRING (5),
    TM          STRING (5),
    LIEU        STRING (70),
    PARTIE      STRING (70),
    ENDEMIC     STRING (5),
    VT          STRING (5),
    TOXIC       STRING (5),
    PARTIETOXIC STRING (75),
    IRRIT       STRING (5),
    [FEM-ENC]   STRING (5),
    [BB-ENF]    STRING (5),
    EPIL        STRING (5),
    [CONT-TH]   STRING (5),
    CANCER      STRING (5),
    PSOLAIRE    STRING (5),
    HSECHE      STRING (5),
    CHEMO       STRING (5) 
);
 
CREATE TABLE HEINDIC (
    NUM    INTEGER     NOT NULL
                       PRIMARY KEY ASC AUTOINCREMENT,
    NUMM   NUMERIC  REFERENCES PRODUITS (NUMM) ON DELETE CASCADE
                                                  ON UPDATE CASCADE
                       NOT NULL,
    INDIC  STRING (75),
    REM    STRING (25),
    ORGANE STRING (25),
    CT     STRING (40),
    VVT    STRING (5),
    EFF    CHAR (1),
    COMPL  STRING (25) 
);

sans vouloir le vexer, j'ai donc un doute sur "les descripteurs" fournis dans le post #22

La colonne NUMM de table HEINDIC est du type NUMERIC et la colonne NUMM de la table PRODUIT est du type INTEGER.

bien vu c'est pour cela que m'apparaissait un format différent, bien que je m'en doutasse, je ne me suis pas encore vraiment penché sur la structure, juste le problème de données.


Totalement à part, je constaste que le LIKE de SQLite est case insensitive
select * from affections where affection like 'STAPHY%' = select * from affections where affection like 'staphy%'ce qui m'a un peu surpris (pas habitué à ça) jusqu'à ce que je lise la doc. Est-ce bien "SQL compliant" ?

[fsmrel]

J'ai l'impression que la relation est plutôt HEINDIC.NUMM - PRODUIT.NUM

C’est ce que voudrait la logique. En effet, dans 99% des cas de figure, une clé étrangère fait référence à une clé primaire, rares sont les références à une clé alternative.

Si ton impression doit devenir certitude, il va falloir que le camarade essence-ciel trouve le moyen de savoir quelle est la valeur affectée par le SGBD à tel produit référencé par tel et tel heindic. L’auto-incrémentation pose alors un problème, car l’affectation des valeurs se passe sous le capot et suite à des réorganisations, restaurations et autres médications et impedimenta subis par la table PRODUIT, ça peut vite devenir incohérent, le bazar, bref le cauchemar, et les messages dans les forums SGBD devraient en témoigner.
C’est un problème délicat, et pour ma part je préfère ne pas avoir à connaître les valeurs affectées par le SGBD aux clés primaires auto-incrémentées, je ne me sers que des valeurs que j’ai moi-même affectées.

Exemple simplifié pour illustrer (avec SQL Server, où AUTOINCREMENT est à remplacer par IDENTITY)


Les CREATE TABLE :

CREATE TABLE PRODUIT 
(
    Num         INTEGER IDENTITY,
    NUMM        INTEGER NOT NULL,
    NOM         VARCHAR(75) NOT NULL,
 PRIMARY KEY (Num)
) ;

CREATE TABLE HEINDIC 
(
    NUM    INTEGER NOT NULL,
    NUMM   INTEGER NOT NULL,
    INDIC  VARCHAR (75) NOT NULL,
    REM    VARCHAR (75) NOT NULL,
FOREIGN KEY (NUMM) REFERENCES PRODUIT (NUM)
) ; 

Un début de jeu d’essai

INSERT INTO PRODUIT (NUMM, NOM)
VALUES
    (45, 'produit x')
  , (12, 'produit y')
  , (95, 'produit z')
;
SELECT * FROM PRODUIT ; 

=>

Num         NUMM        NOM
1           45          produit x
2           12          produit y
3           95          produit z

INSERT INTO HEINDIC(NUM, NUMM, INDIC, REM)
VALUES
    (987, (SELECT Num FROM PRODUIT WHERE NUMM = 45), 'indic i', 'rem a')
  , (314, (SELECT Num FROM PRODUIT WHERE NUMM = 12), 'indic j', 'rem b')
  , (123, (SELECT Num FROM PRODUIT WHERE NUMM = 95), 'indic k', 'rem c')
;
SELECT * FROM HEINDIC
;

=>

 
NUM         NUMM        INDIC           REM
987         1           indic i         rem a
314         2           indic j         rem b
123         3           indic k         rem c

Les valeurs affectées par le SGBD à la colonne Num de la table PRODUIT sont restées cachées pour les inserts dans la table HEINDIC.

[fsmrel]

Est-ce bien "SQL compliant" ?

Papy, la réponse se trouve vraisemblablement chez Gulutzan, à défaut poser directement la question au jeunot à la mémoire de cheval, SQLpro.

[essence-ciel]

Bonjour,
Résultat sans appel effectivement ! Gros manque de logique et de cohérence ! Sans compter une ignorance crasse du SQL...

Je prends note de toutes ces observations et modifie les tables en conséquences. Je me plonge dans la doc SQLite pour approfondir les pistes indiquées.

Merci de vos observations.

[fsmrel]

essence-ciel,

A l’instar de Naf-Naf, il faut effectivement préférer construire une maison en briques plutôt qu’en paille ou en bois, car le loup n’est pas loin !

Mais il est bon aussi de dresser les plans de la maison. En l’espèce, il s’agit du MCD (modèle conceptuel des données). A ce propos, je vous recommande l’excellent Looping, gracieusement proposé par le professeur Patrick Bergougnoux (merci Paprick !). Vous pourriez fouiller dans le forum Schéma pour trouver des exemples de MCD réalisés avec Looping, accompagnés des CREATE TABLE produits par cet AGL. Je vous recommande aussi la lecture du chapitre 7 « Modélisation conceptuelle des données » de l’ouvrage remarquable de D. Nanci (RIP) et B Espinasse Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001), c’est l’ouvrage de référence des architectes de données. Au besoin on sera là pour vous aider.

N.B. J’ai un peu regardé la doc SQLite, et trouve ce « SGBD » un peu trop éloigné de la norme SQL. Vous tenez vraiment à lui ?

[essence-ciel]

Bonjour,
Merci pour les réponses et les suggestions de lecture. Pour l'heure, je suis devant "SQL pour les nuls" et, en parallèle, je mets à plat toutes les tables, j'aurai dû commencer par là...

Disposant d'un peu de temps à mon cabinet, j'avais commencer à établir un graphique sur papier répertoriant toutes les tables, les descripteurs de fichiers et, avec un jeu de couleurs, les différentes liaisons, index, not null et unicité de clé afin d'avoir une vue d'ensemble mais cela devient vite illisible même sur 4 feuilles A3;

Après téléchargement, Looping me paraît plus clair que mon PC (papier/crayon)...

Quant à SQLite, bien qu'éloigné de la norme SQL, c'est celui qui me paraît le plus simple à mettre en œuvre pour ce que j'envisage.

Quant aux différentes tables, en 20 années d'existence sous Paradox/BDE, elles ont connu bien des vicissitudes, d'où les numéros qui ne suivent pas ou le commencement de PRODUITS à 1856... est-ce un problème avec une clé unique de type INTEGER PRIMARY KEY ?

[SergioMaster]

Bonsoir aux néocalédoniens, Bonjour aux autres

Quant aux différentes tables, en 20 années d'existence sous Paradox/BDE, elles ont connu bien des vicissitudes, d'où les numéros qui ne suivent pas ou le commencement de PRODUITS à 1856... est-ce un problème avec une clé unique de type INTEGER PRIMARY KEY ?

Que les numéros ne se suivent pas ou commencent à partir d'une valeur différente de 1 n'a strictement aucune importance. 1856 c'est pas mal, encore plus si tu y ajoutes 100, cela deviendrait une cuvée exceptionnelle (point de vue totalement personnel, je ne parle pas du Saint Emilion)
Il faut plutôt chasser les redondances ie. AFFECTIONS.Affection et HEINDIC.INDIC, on ne devrait pas voir cette derniére colonne mais juste l'ID de l'affection qu'une bonne relation (foreign key) rendra béton, remplacer la colonne INDIC par une colonne AFF_NUM integer not null (réalisable en deux coups de baguette SQL sans perte de données)

N.B. J’ai un peu regardé la doc SQLite, et trouve ce « SGBD » un peu trop éloigné de la norme SQL.

Nobody's perfect sauf peut-être MS SQL cher à SQLPro . Il y a du pour et du contre, en tout cas "migrant" de Paradox, si la cible reste du mono-utilisateur léger au déploiement facile, ça se tient même si cela réduit considérablemnt la voilure.
Comme Delphi (D7 si on en croit quelques images écrans) il y a, pas mal de solutions sont envisageables (dépendant des couches d'accés composant)

[SergioMaster]

Bonjour,

voilà ce que j'ai fait avec SQLiteStudio (ajout de la colonne ID_AFFECTION) ce qui donne cette structure une fois le script passé

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
 
CREATE TABLE HEINDIC (
    NUM          INTEGER     NOT NULL
                             PRIMARY KEY ASC AUTOINCREMENT,
    NUMM         NUMERIC     REFERENCES PRODUITS (NUMM) ON DELETE CASCADE
                                                        ON UPDATE CASCADE
                             NOT NULL,
    ID_AFFECTION INTEGER     REFERENCES AFFECTIONS (Num) ON DELETE SET NULL
                                                         ON UPDATE CASCADE,
    INDIC        STRING (75),
    REM          STRING (25),
    ORGANE       STRING (25),
    CT           STRING (40),
    VVT          STRING (5),
    EFF          CHAR (1),
    COMPL        STRING (25) 
);

Ensuite un petit SQL

Code :

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

UPDATE HEINDIC SET ID_AFFECTION=(SELECT NUM FROM AFFECTIONS WHERE affection=HEINDIC.INDIC)

Enfin il ne reste plus qu'à supprimer la colonne INDIC

NOTA en direction du pépé de la bande, j'ai préféré ne pas mettre NOT NULL à la colonne ID_AFFECTION considérant une relation [0,n]* plutôt que [1,n]*
(* j'ai toujours été un peu dyslexique pour les sens surtout dans un schéma type Merise).
Disons, si j'ai bien compris, que ma "relation [0,n]" se traduit pour un profane en : une affection peut être répertoriée et n'avoir aucune indication de traitement (0) alors qu'une autre peut en avoir plusieurs (dépendant d'autres critères que le nom) .

[Paprick]

Bonjour,

NOTA en direction du pépé de la bande, j'ai préféré ne pas mettre NOT NULL à la colonne ID_AFFECTION considérant une relation [0,n]* plutôt que [1,n]*
(* j'ai toujours été un peu dyslexique pour les sens surtout dans un schéma type Merise).
Disons, si j'ai bien compris, que ma "relation [0,n]" se traduit pour un profane en : une affection peut être répertoriée et n'avoir aucune indication de traitement (0) alors qu'une autre peut en avoir plusieurs (dépendant d'autres critères que le nom) .

Je pense qu'il y a une confusion quant au rapport entre une cardinalité [0,n] et l'adoption du NOT NULL...
D'après le code SQL de création de la table HEINDIC, ID_AFFECTION est une clé étrangère faisant référence à la clé NUM de la table AFFECTIONS.
Dans ce cas, le [0,n] signifie simplement qu'une affection peut ne concerner aucune entité de HEINDIC.
Pour prévoir que certaines entités ne font pas référence à une affection, on utilise une cardinalité [0,1] qui se traduit, au niveau MCD, de la manière suivante (et qui ne génèrera pas de NOT NULL au niveau MLD) :

De façon générale, pour revenir sur les recommandations de François, la seule façon d'obtenir à terme un schéma relationnel bien propre, c'est de passer par la phase de modélisation conceptuelle (avec Looping ou un autre logiciel de modélisation, même si le choix de François me paraît être de loin le meilleur ! )
Le passage par l'étape MCD éviterait par ailleurs ce que je considère comme un gros problème au niveau relationnel : en effet, il est souhaitable pour une meilleure utilisation de la BD que les noms des clés primaires et étrangères soient les mêmes ; mais pour cela, il faut que chaque clé primaire ait un nom unique pour tout le schéma relationnel et que ce nom soit significatif quand il se trouve dans une autre table en tant que clé étrangère (et éviter de se retrouver avec "NUM" partout !). Dans l'exemple ci-dessus, ID_HEINDIC et ID_AFFECTION seraient de bons nom d'identifiants.
A suivre !

[SergioMaster]

Bonjour,
J'avoue, je n'ai jamais vraiment accroché le wagon Merise et mon premier reflexe (utiliser ma formation de base, quand je veux quelque chose de rapide c'est toujours celle qui ressort) est d'écrire une notation Warnier j'aurai même certainement du écrire AFFECTIONS { HEINDIC (0,n) d'où la contraction [0,n] utilisée.
Rien à voir donc avec Merise.

Pour ce qui est des noms de colonnes, j'en avais déjà fait la remarque dans une autre discussion. J'avais même, dans un premier temps, dans mon dernier POST, envisagé de proposer une table
INDICATIONS(ID_INDIC,ID_AFFECTION,ID_HEINDIC) avant de supprimer cette partie par manque de comprehension des colonnes de la table HEINDIC

[essence-ciel]

Bonsoir et merci pour vos réponses,
Waouh ! Ca va vite ! J'ai pas encore terminé d'intégrer le chapitre 7 de l'ingénierie des systèmes d'information, ni SQL pour les nuls. A mon avis, il me faudra quelques temps pour intégrer Merise...

En parallèle, je réalise, enfin j'essaie, le MCD (merci à l'auteur de Looping). J'ai un peu plus de mal pour modéliser car toutes les relations me sont familières mais les formaliser sous la forme 0:n 0:1 ou 1:n ne m'est vraiment pas instinctif...

SergioMaster, merci pour le SQL et les observations, je le garde dans un coin pour l'utiliser plus tard.

Ce week end a été consacré à la récolte de plantes endémiques médicinales dans la chaîne centrale, sans PC, ni livre, ni téléphone portable. On portait ce qu'il fallait pour deux jours et demi de collecte, j'avoue avoir voyager léger et laissé livre, pc et smartphone à la maison au profit d'une tente, des vivres et de l'eau... donc pas de lecture au coin du feu...

[fsmrel]

Bonsoir les contemporains,

Ce week end a été consacré à la récolte de plantes endémiques médicinales dans la chaîne centrale, sans PC [...]  

Ça tombe bien. Quittons la technique pour remonter au niveau de la maîtrise d’ouvrage, sans tenir compte des méthodes (Merise, NIAM, LCP Warnier, Corig et autres). Autrement dit, je souhaiterais pour ma part voir se dégager les règles d’organisation, de structuration des données.  

En repartant à zéro, je crois comprendre qu’il y a des produits (des remèdes à base de plantes) pouvant être utilisés pour soigner des affections. Un produit donné P a telle et telle caractéristiques singulières (monovaluées), chacune qualifiée par un nom histoire de fixer les idées (AY, EN, EF, HA, etc.). Ce produit P a en outre des caractéristiques plurielles (multivaluées) regroupées en indications (sous les appellations INDIC, REM, ORGANE, CT, VVT, EFF, COMPL).

Pour passer à l’abstraction, disons qu’un produit, une indication, une affection sont des entités, et pour utiliser le langage de Paprick, les produits font l’objet d’une classe d’entités PRODUIT, les indications font l’objet d’une classe d’entités HEINDIC, les affections font l’objet d’une classe d’entités AFFECTION.

A ce stade, suis-je en phase ?

Si oui, je poursuis en disant que les classes d’entités ont forcément leur côté associatif. Dans ces conditions, merci ce confirmer/corriger les règles qui suivent (à l’occasion intentionnellement contradictoires avec celles qu’on rencontre dans la discussion) :

(R1) Un produit a au moins une et au plus plusieurs indications et une indication appartient a au moins un et au plus un produit (il y a surjection au sens de la théorie des ensembles).

(R2) Pour une affection on se sert d’au moins une et au plus plusieurs indications et une indication sert pour au moins une et au plus plusieurs affections.

Ces règles sont plus ou moins formelles (rédaction en français oblige), c’est pourquoi il faut redescendre au stade de la maîtrise d’oeuvre et les formaliser dans un MCD merisien ou un diagramme de classes UML, ou un modèle NIAM, etc.) En tout cas, on en reste au QUOI sans dériver vers le COMMENT.

[essence-ciel]

Bonjour et merci pour ces précisions,

Je me permets d'apporter quelques précisions car, à l'évidence, je n'ai pas été assez précis. Pour résumer, comme l'écrivait fsmREL:

Soit la table P (Produits) qui liste x plantes. Chaque plante possède une ou plusieurs indications thérapeutiques dans la table H (HEIndic, pour huile essentielle), d'où liaison (REFERENCES) HEINDIC->PRODUITS.

NOTA : l'applicatif ayant évolué en 20 ans, au départ, sous PARADOX/BDE, je n'avais pas besoin, ni fait, d'intégrité référentielle car l'applicatif monotable PRODUIT avait un champ HUILE ESSENTIELLE. Par la suite, j'ai ajouté des précisions puis séparé les tables pour gagner en finesse dans les préparations et la connaissance des produits utilisés. Enfin, les diverses difficultés rencontrées avec Paradox/BDE (ajout/suppression, doublons, plantages, coupure de courant, index corrompus...) ont créé des "trous" dans la numérotation m'interdisant l'intégrité référentielle.

Soit la table A (AFFECTIONS) qui récapitule toutes les affections répertoriées dans l'applicatif. La table A sert de référence (par l'intermédiaire d'un champ référence) à la table H.

Toutes les données de la table A apparaissent au moins dans l'une, ou plusieurs, des tables (HEINDIC, PLINDIC, TMINDIC, GEINDIC, HYINDIC, HVINDIC, MTCINDIC) répertoriant les AFFECTIONS/INDICATIONS par forme galénique (dérivé de Galien ou Galienus, médecin/pharmacien de l'antiquité). Ces tables ne peuvent donc pas avoir d'indication qui ne soit pas répertoriée dans AFFECTIONS. D'où la liaison HEiNDIC->AFFECTIONS sous forme de champ référence dans l'applicatif.

La redondance indiquée, à juste titre, par SERGIOMASTER provient donc du champ référence dans H qui, dans le but d'extraire sous forme tabulaire les plantes ayant une indication précise, mais également de faciliter une saisie sans risque d'erreur, reprenait la table A (voir tableau du post #1). Cette redondance me permet par un simple parcours d'HEIndic d'avoir toutes mes informations sans code supplémentaire et en étant sûr que le libellé de l'indication est entré correctement lors de la saisie... En fait, dans le post#1 j'ai joint l'image des vertus mais le principe reste le même...

Il en est de même avec toutes les tables mentionnées xxINDIC ou xxVERTUS. Dans le post #1, la partie gauche répertorie les affections, et à droite, j'ai, pour la forme galénique adaptée pour cette affection, toutes les plantes qui satisfont à cette affection. Je peux donc ainsi composer la préparation la plus efficace pour le consultant en choisissant une ou plusieurs huiles essentielles (HEINDIC), huiles végétales (HVINDIC), teintures-mères (TMINDIC) etc, grâce aux mentions EFF (efficacité) et VT (valeur thérapeutique), voire le chémotype (molécule aromatique ou principe actif ayant le taux le plus élevé dans la forme galénique considérée) en raison de la toxicité de certaines molécules (abortive, neurotoxique, phototoxique, cancérigène pour les cétones par exemple...).

Pour répondre à fsmREL, contrairement à HEINDIC, la table R (REMEDES), non évoquée car plus simple, répertorie différents remèdes (formulations pharmaceutiques) pour un trouble donné. Elle comporte environ 5000 entrées et regroupe également des traitements complets utilisant plusieurs formes galéniques (aromathérapie, phytothérapie, hydrolathérapie, gemmothérapie, oléothérapie, homéopathie, tisanes...) agissant en synergie. Elle est donc indépendante des autres tables (pas de liaison ni de références), les ingrédients des préparations et la formulation sont entrés sous forme de BLOB et il y a indication de quantité, de volume. de concentration, de température, de phase (aqueuse ou huileuse), de processus de réalisation, de flaconnage, de synergie, de contre-indications thérapeutiques, de recommandations, de posologie, d'horaires auxquels utiliser la préparation, etc... voire des éléments chimiques particulier (Zn, Cu, Ag, Au, Ca...) ou des sels de ces éléments chimiques à incorporer ou à prendre certains jour voire à certaines heures... Comme, elle n'a pas de liaison, un simple affichage grâce à SELECT * FROM REMEDES me suffit pour un parcours de la table adapté à mon besoin (composition, préparation, étiquetage, traçabilité, information pour la gestion des stocks, suivi du consultant...).

[SergioMaster]

Juste un truc

Enfin, les diverses difficultés rencontrées avec Paradox/BDE (ajout/suppression, doublons, plantages, coupure de courant, index corrompus...) ont créé des "trous" dans la numérotation m'interdisant l'intégrité référentielle.

Les trous n'interdisent en rien l'intégrité référentielle (selon moi)

[SQLpro]

C’est ce que voudrait la logique. En effet, dans 99% des cas de figure, une clé étrangère fait référence à une clé primaire, rares sont les références à une clé alternative.

Dans mon cours de modélisation, je donne toujours l'exemple suivant :
table de patient d'un cabinet médical avec n° auto des patients + NNI UNIQUE.
Toutes les tables sont liées avec le n° auto, sauf la table des retours de paiement de la sécu qui elle est liée sur le NNI !

A +

[essence-ciel]

Bonjour,

Enfin ! Ca fonctionne !
Merci à tous pour vos conseils, votre patience et les idées.
Cordialement !