Discussion :

[Oberown]

<modéré par Cian>
Tag rajouté pour vous
Titre modifié pour plus de clareté
</modéré par Cian>

J'ai une table évenement qui contient différent type d'évenements. Mais pour chaque évenement de ma base, elles ne contiennents pas les mêmes types d'information. Comment le modéliser ?

Dois-je créer une table évenement avec pleins d'autres tables avec des relations 0,1 ?
Autres ?

Merci beaucoup

[slim]

ok,
tu pourrais donc proceder de la sorte :

Evenements ----- 1,n ------- Association -------- 1,1* ------ Informations

* 1,1 : ca depend du nombre d'ocurences de l'entité evenement correspondant aux occurences de l'entité Infos. Avec la cardinalité 1,1, ca voudrait dire qu'une information concerne un et un seul evenement.
Dans l'autre sens : 1 evenement possede une ou plusieurs informations (ca rejoint ce que t'a dis)

Pour l'entité Personne, idem ! c'est le meme principe.

[Médiat]

Je suppose que dans la réponse de slim "Association" est le nom de l'association entre Evenements et Informations (comme dans un modèle Merise).

Il y a un point que tu ne soulèves pas : à quoi sert cette table Evenements ? On ne peut pas modéliser sans connaître le but de la modélisation (un client pour une grande surface n'a rien à voir avec le client pour un assureur, ou le client pour un hôpital).
En prenant deux cas éloignés comme exemples, les réponses ne sont pas identiques :
1) Tu veux faire un journal (type log) très simplifié : dans ce cas on peut supposer que la date et heure de l'évènement, un type d'événement, un user et du texte non structuré décrivant l’événement est suffisant
2) Tu veux faire un système d’alimentation automatique d’un entrepôt de données : dans ce cas chaque type d’événement peut nécessiter un traitement spécifique ; la solution de slim avec une table Evenements n’enregistrant que la date et heure de l'évènement, un type d'événement, un user (et toutes les informations génériques que tu voudras) plus une ou des tables d’informations me paraît judicieuse.

[Oberown]

Voici un exemple concret:
J'ai une table type: Qui contient ado, Adulte, Anim...
Mais dans le cas où j'ai ado, il faut que je donne des infos supplémentaires.

[Médiat]

Puisque tu sembles avoir des difficultés à exposer ton problème, je vais essayer de comprendre :
Tu as
une table Machin (IdMachin(pk), IdStatut (fk)....)
une table Statut (IdStatut (pk), Type,...)

lorsque tu insères un enregistrement dans la table machin, sit le statut de cette ligne a un type"ado", il faut ajouter à Machin des informations supplémentaires.
Si c'est bien cela
Solution 1 : tu ajoutes à Machin toutes les information nécessaires aux ado en faisant attention à les déclarer "nullable". Cette solution est relatvement simple et peu évolutive.
Solution 2 : tu crées une table ComplementAdo(IdMachin(pk), ...). Cette solution est un peu moins simple, un peu plus facilement évolutive.
Solution 3 : tu crées une gestion dynamique des informations complémentaires, ce qui peut aboutir à une structure relativement compliquée, mais très évolutive !

Si depuis le début tu nous avais communiqué la finalité de cette modélisation, nous ne serions pas obligé d'imaginer plusieurs solutions ; c'est assez difficile de te rendre service.

[Oberown]

Je veux la solution la plus propre et la plus dynamique possible.
Le problème si j'expliquais tout le contexte, il serait trop long et trop dur à expliquer.

Pourrais-je avoir plus de détails pour la solution 3 s'il vous plait ?

Merci beaucoup de votre aide

[Médiat]

Pourrais-je avoir plus de détails pour la solution 3 s'il vous plait ?

N'ayant toujours pas d'information complémentaire, je ne peux que rester dans le théorique : tu crées une table qui va servir de structure d'accueil pour des informations non structurées (puisque tu n'en connais pas la structure), et tu gères tes propres métadonnées (google).

[Nanci]

La problématique posée est celle dite de la liste variable de propriétés, décrite dans la littérature merisienne depuis une quinzaine d'années...
Selon le degré de variabilité, différentes solutions existent. Deux peuvent à mon avis répondre à la question.

1/ L'héritage (ou sous-typage)
Ex:



A utiliser si les différentes catégories sont limitées et si leur contenu (propriétés) est stable. Cette solution est figée.

2/ La méta-modélisation
Il s'agit de rendre complètement variable la liste des propriétés d'une entité (dont les propriétés intrisèques sont limitées aux stables).
La notion de propriété est explictement modélisé par une entité, et les valeurs sont reportées dns une relation.
On peut "cadrer" un peu cette modélisation en définissant des typologies avec leur liste de propriétés.

Ex


J'ai mis en oeuvre cette solution de très nombreuses fois; elle marche bien. Seule difficulté, la gestion des valeurs en fonction du type (on peut se limiter à alpha et num)

[Médiat]

J'ai mis en oeuvre cette solution de très nombreuses fois; elle marche bien. Seule difficulté, la gestion des valeurs en fonction du type (on peut se limiter à alpha et num)

Pour être complet (je ne parle pas du typage, ni des listes de propriétés par type) il faudrait aussi ajouter la possibilité de définir des listes (ou des intervalles, ou...) de valeurs associées aux types d'évènements (par propriété). C'est à dire une gestion plus ou moins complète des métadonnées.
Mais pour répondre complètement il faudrait en connaître un peu plus sur les besoins, question posée plusieurs fois et toujours sans réponse...

[Oberown]

Nanci, merci beaucoup de ta réponse.
Je n'avais jamais vu en cour ni l'héritage ni la méta-modélisation.
Comment le MCD de l'héritage ce transforme en MLD ?

[Nanci]

Comment le MCD de l'héritage ce transforme en MLD ?

A partir, par exemple, du MCD suivant


Il existe 4 possibilités de transformation.
1) Duplication de la clé primaire


2) Duplication complète du contenu du sur-type dans les sous-types


3) Suppression du sur-type et migration complète dans les sous-types


4) Suppression des sous-types et migration complète dans le sur-type


Chacune des solutions a des avantages et des inconvéniernts dépendant
- de l'existence d'autres relations sur le sur-type ou les sous-types
- du nombre de propriétés dans le sur-type ou les sous-types
- de l'activité en mise à jour / consultation