pb de spécialisation table (héritage ou autre)

Bonjour,

J'ai un problème pour représenter des données.
Voila le problème : J'ai un ensemble d'activités mais chaque activité a un type différent (il y en a 4), et seulement pour un type d'activité il y a plus d'informations.

Donc je ne sais pas comment faire, soit créer une table "activité" et une table "type activité" mais il me reste le problème que pour un type il y a de infos en plus.
Soit je fais un héritage, la table mère "activité" et les classes filles les 4 types "projet", "opération",...

ou autre mais je ne vois pas.

Bonjour Fanette,

Considérer qu'à l'entité Activité peut être attachée une entité Complément d'activité à l'usage de l'activité qui en a besoin.

cf. Pièces jointes

dans mon cas je metterai donc table "type activité" et une table "projet" avec la liaison "compléter

ce qui signifie que si j'ai une activité de type projet j'irai remplir dans la base cette table
MAIS comment montrer que c une relation obligatoire ????

Bonsoir Fanette,

Citation:

---

Fanette a écrit :
ce qui signifie que si j'ai une activité de type projet j'irai remplir dans la base cette table
MAIS comment montrer que c une relation obligatoire ????

---

Déjà, vous devez prévoir une colonne Type_Activite permettant d'annoncer la couleur, à savoir si l'activité est de type projet ou non. Ensuite, si vous vous calez sur le standard SQL:1999, vous prévoyez une assertion du genre :

CREATE ASSERTION Assert01 (
___Check Exists (Select 'vrai'
_______________From Activité A, Projet P
_______________Where A.Type_Activite = 'Projet'
_______________And A.Activite_Id = P.Activite_Id)
___DEFERRABLE INITIALY DEFERRED ;

et une assertion symétrique :

CREATE ASSERTION Assert02 (
___Check Not Exists (Select 'vrai'
_______________From Activité A, Projet P
_______________Where A.Type_Activite <> 'Projet'
_______________And A.Activite_Id = P.Activite_Id)
___DEFERRABLE INITIALY DEFERRED ;

"DEFERRABLE INITIALY DEFERRED" indiquant que les contrôles ne sont pas à effectuer à l'exécution d'une mise à jour, mais plutôt en fin de tâche, situation commune dès que deux tables sont concernées.

Quant à la façon de déclarer la chose en Merise de manière formelle, je ne sais pas.

Concernant votre SGBD, voyez ce qu'il propose qui soit équivalent à l'instruction CREATE ASSERTION s'il ne la propose pas. Attention, si vous regardez du côté des triggers, n'oubliez pas que ceux-ci ne sont pas "DEFERRABLE", mais qu'une contrainte de clé étrangère peut l'être (au moins du point de vue du standard), c'est un peu la jungle des cas particuliers avec SQL (Sorry Query Language...) A défaut, vérifiez les assertions a posteriori...

Bon courage...