Voilà, je dois modéliser un outil de gestion de configuration.
On y trouve des ordinateurs. A ces ordinateurs, on peut y associer d'autres items de configuration genre HDDs, RAMs, CPUs, fichiers de conf (ex : paramètres réseaux), logiciels installés. Pour chacun de ces items, les attributs varient (un hdd n'est pas caractérisé par les mêmes infos qu'un CPU).
Il faut aussi garder un historique des changements de valeurs des attributs, des associations ordis-items de conf (et tracer la raison de ce changement de valeur et la date et l'heure du changement) afin de pouvoir retrouver la conf qu'avait un ordi à une date donnée.
 
Mon pb concerne la modélisation de cet historisation.
 
Ce que je fais :  

 
Entité = ordi ou item de conf modélisée sous forme d'arborescence -> un ordi est une arbo d'items de conf qui ont un certain nb d'attributs de différents types.
 
Sauf q'avec ce modèle, je ne gère pas les changements d'associations entre les entités (ex : un hdd est enlevé d'un ordi et est mis sur un autre).
 
Auriez vous des idées à me proposer? Merci par avance

Personne n'a d'idée?

je pense que ce genre de changement ne devrait pas apparaitre dans le modèle directement.
Le record devrait plutot être placé dans une table d'historique grâce à un trigger par exemple.  
 
Si le record existe dans une table. On effectue un changement. La ligne serait d'abord insérée (avec une date) dans la table d'historique et ensuite supprimée dans la table contenant les valeurs actuelles.  
 
Peut être existe-il une meilleure solution... à voir.

Ton MCD est à mon avis plutôt mauvais.

Euh... Je crois que ya confondance là: tu parles de la description conceptuelle de ton SI et des considérations applicatives?
Attention à ne pas mélanger, soit tu fais du conceptuel (MCD) pour DECRIRE ton SI, soit tu fais un MPD qui sera lié à ton modèle de traitements etc.
MCD != MPD
Je pense qu'il faut d'abord se reconcentrer sur la formulation de problème, du genre: le système doit permettre de retrouver la configuration d'un ordinateur, le système doit conserver l'historique des changements de configurations etc.
Ainsi tu peux finir sur un MCD super simple (genre ordi<->conf.), et pour la gestion des historiques, des recherches etc. tu vois ça ensuite au niveau traitement (MPD, MOT): quelles solutions techniques choisir?

Globalement d'accord.
 
MCD : modélisation du réel orientée métier.
La recherche par mot-clé est typiquement au niveau physique. Le mot-clé n'est pas un concept métier très pertinent.
Les concepts pertinents dans ton petit cas d'étude sont très simples :
1. Les ordinateurs
2. Leurs composants et paramètres
3. L'historique des composants et paramètres de tes ordinateurs.
 
Tu as donc deux classes : Ordinateur et Composant
Tu as ensuite deux associations.
L'une entre Ordinateur et Composant avec une date de début et date de fin.
L'autre, réflexive sur Composant avec, à étudier les attributs date de début et date de fin si c'est vraiment pertinent d'historiser aussi finement la configuration (ce qui est à argumenter)
La détermination du parc informatique à périmère courant ou à une date donnée se fera de manière applicative et n'entre donc pas dans le MCD. (éventuellement dans le modèle physique des données si optimisations)

Tout d'abord, merci pour vos réponses. Je pense que ça va me faire avancer. Pour l'historique, je vois mieux comment gérer ça.
MPD = Modèle Physique des Données, ça correspond à la manière dont le MCD est implémenté au final dans la base de données?
 
Pour résumé, j'ai une table Ordinateur, une table composant, avec entre les 2 une table qui historise les liens entre ordinateur et composant.
Ensuite, j'ai une autre table qui historise les changements de valeurs des attributs d'un composant. Ces attributs sont aussi dans une table. Voilà ma nouvelle question : comme je souhaite voir un composant au sens large du terme, il faut que ma table soit la plus générique possible.
ex :  
un composant "HDD" -> attributs "nom du disque" (string), n° de série (string), nb de cylindres (int, c'est pour l'exemple ici)...
un composant "cpu" -> attributs "fréquence" (int ou float), "nom" (string)...
un composant "fichier" -> attribut "nom" (string), "chemin d'accès" (string), "drois d'accès" (string)...
 
A l'implémentation de ma table "attribut", comme je fais pour prendre en compte les différents types de stockages de données (les int, float, string...)? Est-ce-que j'ai une table "attribut" qui stocke l'id de l'attribut, son "nom" , son "type",... et je déporte dans d'autres tables (une pour chaque type de données) sa valeur? Après, grâce à la valeur du "type", je sais dans quelle table il faut aller chercher la valeur de l'attribut. Ou est-ce-qu'il y a mieux? Merci par avance...

Non
MCD = conceptuel
MPD = traitement
Il peut très bien arriver que les 2 n'aient rien à voir.
 
La partie conceptuelle de ton analyse sert juste à "décrire" ton SI.
Genre: une maison c'est fait de pièces, séparées par des murs etc.
 
Puis dans la partie traitement tu décides de comment, en termes de traitement, en termes techniques, tu implémentes ta solution.
Pour l'exemple de la maison, tu vas décider si tu choisis du parpaing ou de la brique, quelle taille d'armature d'acier etc.
 
Dans le MCD on parle d'entité.
Dans le MPD on parle de table.

mais MPD, c'est bien modèle physique des données, non?

Oui, mais rien à voir avec le MCD: le MPD est lié au MOT.
 
Dans l'ordre:
- Tu définis fonctionnellement ton SI
- Tu le décris conceptuellement: MCD
- Tu le conçois en termes de traitements: MOT
- Tu décides de la meilleure structuration des données utilisées par le MOT: MPD

D'un point de vue physique on peux imaginer n'avoir qu'une seule table pour à la fois les ordinateurs, les composants et les attributs.
En terme de perf, c'est zéro, à moins de faire du partitioning.
Ensuite, l'informatique de gestion, c'est pas fait pour modéliser tout l'Univers. C'est bon pour les chercheurs, pas pour les ingénieurs.
Ta table super générique, euh, c'est quoi l'intérêt ? Faire de la zoologie appliquée aux puces d'ordinateurs ?
Si tu veux vraiment stocker tout et n'importe quoi, contente-toi du type string pour les valeurs d'attributs que tu casteras en nombre ou autre chose dans la partie applicative.
 
Le MLD (et non MCD et ni MPD quoi que proche) pourrait resembler à ceci :
 
table computer (cpr_id, ...)
table component (cpo_id, cpo_type, cpo_label...)
table attribute (attr_id, attr_label, attr_value)
 
table cpr_cpo (cpr_id, cpo_id, date_begin, date_end)
table cpo_attr (cpo_id, attr_id)
table cpo_cpo (cpo_id1, cpo_id2, date_begin, date_end)
 
Dans le MPD, on pourra dénormaliser pour mettre par exemple les trois principaux attributs d'un composant dans la table componant.
Si un composant revient quasi-systématiquement (eg. le processeur), il sera même judicieux d'en faire des colonnes dans la table computer où ce sera le processeur actuellement sur l'ordinateur, en général, l'information qui nous intéresse dans 99% des cas.

 
L'intérêt, c'est que l'on peut prendre en compte n'importe quel composant (fichier de conf, périphérique, point de montage,...) qui n'aurait pas été prévu au départ. Ceux qui font les spécs ont du mal à se mettre d'accord sur les composants d'un ordinateur qu'il faut mettre en gestion de conf. Donc, plutôt que de figer le nombre de composants gérables par l'appli, je me suis dit que faire un composant dont le nombre et el nom des attributs pouvait varié me paraissait une bonne idée... Ca permet de faire une appli très évolutive.
 
Pour la valeur, utilsier le type string, c'est ce que je m'étais dit aussi. Là où ça risque de coincer, c'est qu'il est possible que je sois amené à stocker de grosses quantités de données. Donc, dans ce cas, le type serait "mediumtext" (type dans MySQl, une sorte de blob au format texte et non binaire). Sauf que je ne vais pas utiliser un champ "mediumtext" pour stocker toutes les valeurs, ça prendrait bien trop de palce et ça ramerait au bout de peu de temps D'où l'idée d'avoir des tables pour chaque type de donnée. Où alors, uniquement dans le cas des gros champs textes, je déporte le stockage dans une autre table à 3 valeurs : l'id de la valeur, la valeur et la clé étrangère id_attr. dasn ce cas là, le champ "valeur" de type string de la table attr serait à null.
 

 
Juste une question : à quoi sert date_end? une simple date pour dire à partir de quand on a établie la relation cpr_cpo ou cpo_attr me semble suffir, non?
 

 
Alors là, pas du tout. Cette info n'est pas ce qui intéresse le plus les futurs utilisateurs de l'outil de gestion de conf. Eux, ce serait plutôt les versions de packages installés, les paramètres réseaux (genre le host), le nb de cartes réseau et leur type (X25, ethernet, FDDI...), le nb de disques et leur capacité...
 
En tout cas, merci pour toute l'aide que tu m'as apportée

 
Attention danger ici!
Donner trop de libertés risque de t'emmener rapidement vers un système inexploitable si tu n'imposes pas un thésaurus à tes utilisateurs (surtout si tu veux faire de la recherche sur tes données par la suite).

 
Non, pas de soucis, ce ne sont pas les utilisateurs qui pourront rajouter un nouveau composant. Il n'y aura que le gestionnaire de conf qui pourra le faire. Les utilisateurs ne pourront modifier que les valeurs des attributs et les liaisons ordi-composant après approbation par le gestionnaire de conf d'une FDM (fiche de modification).

pains-aux-raisins, j'aurais voulu avoir ton avis sur les qq remarques que j'ai formulées sur ton MLD précédemment. Merci beaucoup

1. date_end : pense aux cas où tu as deux disques durs dans ton PC. Ils ont la même date de début (date_begin) associé au PC en question. Maintenant, imagine qu'aujourd'hui, l'un des deux disques durs plante. Ben, dans ce cas, tu l'enlève du PC (normal quoi) et tu renseigne dans ta base que la date_end associé au disque défecteur vaut maintenant 03/08/2006.
 
2. Il fallait comprendre que les utilisateurs sont toujours plus intéressés par l'instant présent que par l'historique (on se place dans un contexte d'appli transactionnelle). Dans ta table computer, si les utilisateurs sont surtout curieux de leur HD, ben n'hésite pas à dénormaliser ton modèle et à ajouter des colonnes relatives au composant HD.

Pour moi, ce sont 2 composants distincts avec une date de mise en relation avec le composant de niveau supérieur ou le calculateur. Si l'un de ses composants est remplacé alors :
- une nouvelle entrée dans l'historique de la relation avec son composant parent est ajoutée à la date courante et pointe sur NULL (on brise la relation)
- on ajoute d'un nouveau composant de type hdd
- une nouvelle entrée dans l'historique de la relation avec son composant parent est ajoutée à la date courante.
De ce fait, une seule date suffit. Pour chaque composant, on prend à chaque foit, la dernière entrée dans l'historique dont la relation avec le parent est <> de NULL.
 

Je vois ce que tu veux dire. Le hic, c'est que suivant la conf, ce ne sont pas les mêmes composants qui vont intéresser les utilisateurs.
 
Ce projet est assez complexe du fait que ceux qui font les specs ne sauront ce qu'ils veulent vraiment qu'une fois l'appli en main. C'est un projet qui date de 3 ans, une appli a déjà été développée et respectait leurs spécs. Sauf qu'ils se sont rendus compte que c'était trop lourd à utiliser, qu'il manquait des données dans certains cas et en avait trop dans d'autres. Donc, on est parti pour faire une appli maison la plus souple possible (et comme à chaque fois, il la faut pour demain) et c'est sur moi que ça tombe

J'ai déjà passé suffisamment de temps à t'expliquer ce qu'il fallait faire, maintenant, si ça te plait pas hein...
 
edit : en plus, en googlant un peu je suis sûr que vous découvriez que vous êtes en train de réinventer la poudre.

J'ajouterai aussi que faire une appli sans specs, c'est même plus se tirer une balle dans le pied à ce niveau là.

 
Le cas de figure que tu soulevais était intéressant. Il m'a permis de voir si mon modèle allait bien le gérer ou pas. Après, y'a pas qu'une solution. En simulant d'autres exemples, je vais peut-être me rendre compte que ce sera plus facile de les résoudre avec ton modèle qu'avec le miens (notamment au niveau du nb de requêtes à effectuer pour avoir la réponse).
En tout cas, je te remercie de ton aide et d'avoir consacré du temps à mon pb de manière constructive. ca m'a bien fait avancer.
 
Pour ce qui est de réinventer la roue, moi et mes prédécesseurs, on a fait beaucoup de recherches sans trouver le produit miracle. Du reste, il existe peu d'outils de gestion de conf (au contraire de gestion de parc). Avec ITIL, on va surement en voir à l'avenir, mais aujourd'hui, y'en a pas. En +, on s'oriente plutôt du côté des applis en GPL, ce qui réduit encore les possibilités...
 

si, il va y avoir une spec mais par sécurité, on va essayer d'avoir une appli très souple en ce qui concerne les données qu'elle va devoir gérer.