Discussion :

[lefju cabro]

Bonjour,

J'ai un problème de conception que je ne sais pas comment résoudre: je souhaite relier 3 tables T01, T02 et T03 à 1 même table TCommune.





Sauf que dans mon cas, un record de TCommune sera lié uniquement à un élément de T01, T02 ou T03. J'avais prévu de placer 3 clés étrangères non nulles issues de T01, T02 et T03 dans TCommune mais le fonctionnement que je souhaite ferait planter l'intégrité de la base car 2 clés étrangères sur 3 seraient à Null.

Avez-vous une idée pour faire ceci ? Passer par une table intermédiaire ?

Merci pour vos conseils.

[escartefigue]

Bonjour

S'agit-il d'un héritage par spécialisation ou d'associations exclusives (ce serait plus clair avec un modèle conceptuel, j'avoue que cette représentation inhabituelle n'est pas très parlante) ?

Dans le premier cas, si l'insertion du sur-type et du sous-type sont concomitantes alors pas besoin de s'embêter avec un TRIGGER, c'est le traitement (par exemple une PS) qui insère dans le sur-type qui choisira le bon sous-type concerné et comitera l'ensemble

Dans les autres cas, il faudra soit créer un TRIGGER, soit une contrainte CHECK associée à une UDF qui vérifiera que l'identifiant n'est pas déjà présent dans l'une des autres tables

[lefju cabro]

Merci Escartefigue pour ton commentaire.

Désolé mais je ne maitrise aucun concept que tu m'as cité

Je migre un projet qui a ses données stockées sur fichiers vers une bdd mySQL.

Dans ce projet initial:

• TCommune, T01, T02 et T03 sont 4 classes
• TCommune est utilisée par T01, T02 et T03.
• T01, T02 et T03 n'ont pas grand chose en commun à part utiliser des objets de TCommune.

Par un exemple, j'ai essayé d'expliciter les classes pour une meilleure compréhension:
TCommune (VoieMesure = type_capteur, sensibilité...)
T01 (AppareilMesure= marque, num_serie, ...)
T02 (UtilisationVoieMesure= temperature, vibration...)
T03 (FiabilitéVoieMesure= indice, erreur, ...)
--> des objets VoieMesure de TCommune appartient à une seule classe T01, T02 ou T03.

Naïvement, je pensais migrer ces 4 tables telles quelles en ajoutant 3 clés étrangères dans la table TCommune mais ça ne peut pas marcher:
T01 est relié à un TCommune qui lui est propre et qui ne peut pas être relié à T02 et T03.



J'espère qua ça pourra vous éclairer pour comprendre.
Merci

[escartefigue]

Si je comprends bien, il s'agit de stocker des données relatives à des instruments de mesure

Ces instruments sont de différents types (micro, caméra...)
Ils effectuent différentes mesures (température, vibrations)
Ils ont une certaine fiabilité
Ils possèdent un n° de série et une marque


Est-ce qu'un même instrument (une même sonde) peut effectuer plusieurs types de mesure (par exemple à la fois la température et les vibrations) ou bien un seul
A-t-on à gérer la notion de station ou d'appareil qui combine plusieurs instruments de mesure, comme en météorologie où une station (caractérisée par un lieu géographique) relève la température, la vitesse du vent, l'hygrométrie...

[lefju cabro]

Merci Escartefigue pour tenter de comprendre ma demande.

En détaillant mon exemple je vois qu'il est faux et ne reflète pas la réalité de mon projet: les tables sont trop identiques et te font poser d'autres bonnes questions.

Dans l'exemple ci-dessous, je souhaite afficher différentes informations (commentaire utilisateur pour T01, marque voiture pour T02 et nom société pour T03) avec des fontes spécifiques définies dans TCommun.

• les 3 tables T01, T02 et T03 sont totalement différentes; aucun lien entre elles.
• pour un record d'une de ces 3 tables, il utilise un record de TCommun pour afficher le texte (commentaire utilisateur, marque voiture, nom société)
• TCommun peut avoir plusieurs records avec les mêmes valeurs mais ces records sont reliés à un seul record de T01, T02 ou T03.

Le fait de mettre une clé étrangère pour T01, T02 et T03 dans TCommun ne peut pas fonctionner car 1 seule clé étrangère sera non nulle sur les 3.

J'espère que mon exemple est plus clair

[pier.antoine]

Bonjour

Mon expérience amateur fait que tenter de transcrire une "base/application tableur" (quelle horreur !) dans une vraie base de données relationnelle est vouée la plupart du temps à l'échec.
L'étape d'analyse et de conceptualisation de la base est indispensable.

Donc reprendre au début : pour quoi faire ? Les différentes entités, leurs relations...

À vous lire je pense qu'une piste serait de faire une table associant TCommun à T01 par exemple.
Mais à confirmer avec le résultat de la conceptualisation.

Bon courage.

Pierre

[escartefigue]

Tout ceci est bien confus.

La bonne démarche pour construire une base de données c'est de commencer par rédiger les règles de gestion.
Voyez dans ce fil de discussion, la réponse n° 8 qui explique comment les formaliser

Quand c'est fait, on crée ensuite un Modèle Conceptuel des Données (MCD) en utilisant un logiciel fait pour ça, par exemple Looping qui en plus d'être excellent est aussi gratuit
Vous pouvez le télécharger ICI.

À partir de là, vous choisissez votre SGBD et la génération du script de création des tables (DDL) est automatique.

Il ne faut pas créer votre BDD en réfléchissant aux tables : les tables et notamment les FK ne sont que la conséquence des règles de gestion formalisées en MCD.