Lier deux groupes de tables issus de deux bases distinctes

**ClayStone** · 20/10/2020, 13h38

Bonjour,

Je dispose d’une base de donnée comportant deux groupes de tables distincts (en fait, il s’agissait historiquement de deux bases indépendantes association et bibliographie)
Le premier groupe de tables (association) assure la gestion interne d’une association, et contient une table t_membre (id_membre, nom, prenom, etc1.).
Le second groupe de tables (bibliographie) gère une bibliographie et contient une table t_auteur (id_auteur, nom, prenom, etc2.)
Les auteurs peuvent être, ou non, membres de l’association, mais ce n’est renseigné nulle part dans ce groupe de table.

Aujourd’hui, il nous devient nécessaire de pouvoir accéder aux informations contenues dans le groupe de tables association depuis le groupe bibliographie et vice versa.
Par exemple,
- accéder aux informations internes à l’association (cotisation, adresses...) d’un auteur (si il est membre) à partir d’une recherche de ce qu’il a écrit,
ou inversement,
- accéder aux publications d’un membre à partir d’une recherche dans les infos présentes coté association.

L’idée serait de
- créer une liaison/relation entre les deux groupes de tables via ces deux tables t_membre et t_auteur
- éviter les redondances et les aberrations : actuellement, l’identité d’un membre auteur est renseignée sous deux id différentes dans chacune des deux tables (id_membre et id_auteur)

Une solution envisagée serait de créer une table de relation t_individu entre t_membre et t_auteur, après avoir supprimé de la table t_auteur toutes les lignes dont l’auteur est aussi membre de l’association. Cette table serait alimentée à chaque nouvelle saisie d’un auteur, qu’il soit membre ou non.

t_individu
id_individu (pk, auto incrementée)
id_membre (fk t-membre, NULL si is_membre est FALSE)
id_auteur (fk t_auteur, NULL si is_membre est TRUE)
is_membre (booléen)

Cette solution est-elle optimale ?
Y-a-t-il mieux à faire ? (passer par CREATE VIEW par exemple ?)

Merci d’alimenter ma réflexion !

P.s.
Je travaille avec MariaDB / mysql php
Pour des raisons sur lesquelles je ne m’entendrai pas, il n’est pas question de toucher à la table t_membre
Hormis les informations des deux tables d’identité t_membre et t_auteur, aucune information issue des deux groupes de tables n’est redondante.
Ma connaissance en matière de base de donnée est empirique et ma méthodologie est issue de celle du bon professeur "Al. Harasch"

**escartefigue** · 20/10/2020, 14h51

Bonjour,

La description est succincte, mais quoi qu'il en soit, je préfère une solution consistant à identifier les vrais doublons fonctionnels (en rapprochant les membres et les auteurs)
Ensuite, créez une table "individu" pour les attributs communs aux membres et aux auteurs, puis, si nécessaire, un sous-type "auteur" et/ou un sous-type "membre" pour les attributs spécifiques

Une difficulté est d'identifier les vrais doublons fonctionnels, le trio nom/prénom/date de naissance n'est pas suffisamment fiable et des valeurs légèrement différentes sur ces critères peuvent parfois porter sur un même individu (ex : erreur d'orthographe, trait d'union...)

**ClayStone** · 20/10/2020, 18h52

Merci Escartefigue,

La description est succincte

En effet. Pour l'être un peu moins, voici un shéma très simplifié de la base actuelle :
Nom : Etat actuel.png
Affichages : 345
Taille : 26,0 Ko

Une difficulté est d'identifier les vrais doublons fonctionnels

Je pars de l'hypothèse que c'est fait et que les auteurs qui sont membres ont été supprimés de la table t_auteur, qui s’appellera désormais t_non_membre.

créez une table "individu" pour les attributs communs aux membres et aux auteurs

Je ne suis pas sûr d'avoir le bon vocabulaire...
A priori, le seul attribut commun (ici) serait avoir rédigé un article.
Est-ce que quelque chose comme ça pourrait fonctionner ? Et si oui, est-ce qu'il existe un moyen pour forcer id_membre ou (exclusif) id_non_membre à être null (selon si il s'agit d'un membre ou d'un non-membre) dans t_individu pour gérer le cas où id_membre et id_non_membre auraient la même valeur?
Nom : envisagé.png
Affichages : 342
Taille : 33,3 Ko

Nom : envisagé.png
Affichages : 342
Taille : 33,3 Ko

Sinon, pourrais-je envisager ça (et is_membre est-il utile, toujours pour distinguer un membre d'un non-membre qui auraient un id de même valeur) ?
Nom : envisagé2.png
Affichages : 329
Taille : 33,0 Ko

Nom : envisagé2.png
Affichages : 329
Taille : 33,0 Ko

**escartefigue** · 20/10/2020, 21h10

Votre modèle logique implique les règles de gestion suivantes :

R001a : un même membre peut avoir plusieurs fonctions
R001b : une même fonction peut être attribuée à plusieurs membres

R002a : un même auteur peut écrire plusieurs articles
R002b : un même article peut avoir plusieurs auteurs

R003a : un article ne fait l'objet que d'une seule édition (voire aucune édition, non décelable sur votre schéma)
R003b : une édition peut concerner un à plusieurs articles

est-ce correct ? sinon le MLD est à revoir

À préciser :
- les fonctions exercées par un membre sont elles immuables ou variables dans le temps ?
- un membre peut il n'avoir aucune fonction (comme dans le MCD proposé ci-dessous) ou obligatoirement au moins une ?

Par ailleurs, vu que t_membre comporte les attributs nom, prenom et matricule et que t_auteur comporte les attributs nom, prenom et remarque, alors nom et prenom sont des attributs communs aux deux tables.
C'est ici que la modélisation par héritage peut être utilisée

Voici un exemple de modèle

Au niveau conceptuel (réalisé avec Looping)

Pièce jointe 581848

Si un individu peut être à la fois membre et auteur, alors la contrainte n'est pas de type XT mais de type T (à adapter selon votre cas)

Ce qui donne le script suivant :

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
CREATE TABLE IN_individu(
   IN_ident COUNTER,
   IN_nom VARCHAR(50) NOT NULL,
   IN_prenom VARCHAR(50) NOT NULL,
   PRIMARY KEY(IN_ident)
);

CREATE TABLE AU_auteur(
   IN_ident INT,
   AU_remarque VARCHAR(255),
   PRIMARY KEY(IN_ident),
   FOREIGN KEY(IN_ident) REFERENCES IN_individu(IN_ident)
);

CREATE TABLE MB_membre(
   IN_ident INT,
   MB_matricule DECIMAL(7,0) NOT NULL,
   PRIMARY KEY(IN_ident),
   UNIQUE(MB_matricule),
   FOREIGN KEY(IN_ident) REFERENCES IN_individu(IN_ident)
);

CREATE TABLE FO_fonction(
   FO_ident COUNTER,
   FO_code CHAR(4) NOT NULL,
   FO_libelle VARCHAR(128) NOT NULL,
   PRIMARY KEY(FO_ident)
);

CREATE TABLE exercer(
   IN_ident INT,
   FO_ident INT,
   PRIMARY KEY(IN_ident, FO_ident),
   FOREIGN KEY(IN_ident) REFERENCES MB_membre(IN_ident),
   FOREIGN KEY(FO_ident) REFERENCES FO_fonction(FO_ident)
);

**ClayStone** · 21/10/2020, 08h54

Merci, Je n'en attendais pas tant !
Les règles de gestion sont correctes, et un article doit faire l'objet d'une édition et une seule.

- les fonctions exercées par un membre sont elles immuables ou variables dans le temps

variables

- un membre peut il n'avoir aucune fonction

oui

Ceci dit, je n'avais pas dû être très clair dans mon premier post, il n'est pas envisagé (pour ne pas dire inenvisageable) de modifier la table t_membre, tant en structure qu'en données.

Je comprends mieux l'expression "attributs communs" et hélas, malgré les attributs nom et prenom communs aux deux tables membre et non-membre, il me faut garder ces deux tables distinctes.

Une précision, il s'agit d'une association familiale, et la base contient la généalogie.
La partie association comprend la gestion des membres de l'association ET la gestion de la base généalogique. Cette partie est déjà créée, elle est en service, et elle fonctionne correctement. Il est interdit d'y toucher

On peut en revanche modifier la partie bibliographie si besoin est.

Je commence à comprendre que ma question se heurte aux bonnes pratiques.

Si la théorie s'y oppose, le terrain impose que l'insertion de personnes externes à la famille (pour la bibliographie par exemple) dans la base ne se fasse que par une nouvelle table.
D'où mon insistance à avoir une table des non-membres. (peut-etre sur le modèle d'une base commerciale contenant une table client et une table fournisseur, où un fournisseur ne serait jamais client et un client jamais fournisseur, mais où clients et fournisseurs pourraient être chacun invités à un un même evenement...?)
[AJOUT]Du coup :

Si un individu peut être à la fois membre et auteur

avec mes deux tables t_membre et t_non_membre et la table de relation t_article_auteur:
- un membre peut être un auteur d'un article
- un non membre peut être un auteur d'un article
- un membre ne peut pas être un non-membre (et vice versa)
[/AJOUT]

D'où aussi ma difficulté à créer une (ma première option) ou deux (ma deuxième option) tables intermédiaires de relation:
Attribuer 1 ou plusieurs auteurs (membre ou non-membre) à un article
Attribuer 1 ou plusieurs articles à un auteur (membre ou non-membre)

L'une ou l'autre de mes suggestions précédentes peuvent-elles faire l'objet d'un "bricolage" qui fonctionnerait, même sans être orthodoxe ?

**ClayStone** · 21/10/2020, 21h37

Bonsoir,
Après un peu de lecture, j'ai commis ceci :

Règles de gestion :

Contenu
un contenu est défini par

un seul titre obligatoire
un seul sous-titre optionnel
une seule remarque optionnelle
une seule édition optionnelle (obligatoire si type*: revue complete, article ou livre)
un seul format obligatoire

un contenu doit correspondre à un ou plusieurs types
un contenu doit avoir été créé par un ou plusieurs auteurs (individu, anonyme ou inconnu possible)
un contenu peut mentionner une ou plusieurs personnalités (individu)
un contenu peut appartenir à un ou plusieurs propriétaires (individu)
un contenu doit aborder un ou plusieurs thèmes

Edition
une édition est définie par

une date (de parution, de création) optionnelle (obligatoire si type livre, revue complète, article de revue, archive administrative)
un numero de parution optionnelle (obligatoire si type revue complète, article de revue)
un numéro de page optionnel (obligatoire si article de revue)

Une édition doit porter sur un ou plusieurs contenus

Format
un format est défini par

un libellé obligatoire (image .jpg .png..., texte .pdf .doc, feuille de calcul .xls)

un format peut être attribué un ou à plusieurs contenus (un format peut être «*orphelin*» le temps qu’un contenu compatible soit entré dans la table contenu)

Type
Un type est défini par

un libellé obligatoire (portrait, paysage, archive administrative, revue, article, livre)

un type doit correspondre à un ou plusieurs contenus

Thème
un theme est définit par

un libellé de theme général
un code de theme général
un libelle de theme détaillé
un code de theme détaillé

Un thème peut être abordé par un ou plusieurs contenus (un theme peut être «*orphelin*» le temps qu’un contenu compatible soit entré dans la table contenu)

Individu