Discussion :

[Bownobo]

Bonjour à tous, nous développons un logiciel opensource pour faire de la retrodocumentation de code source. Dans un premier temps nous voudrions afficher sous formes d'arbres les relations suivantes:

• relations entre l'appel de classes et leurs fichiers source
• relations entre l'appel de fonctions et leurs fichiers source
• relations entre la définition d'une classe et leurs fichiers sources
• relations entre la définition d'une fonction et leurs fichiers source

Si ça parait confus c'est normal car moi-même j'ai du mal à appréhender le concept de la retrodocumentation de code source.
Je fais appel à votre aide, si l'un d'entre vous à déja aborder le problème il serait interessant de partager notre savoir.

On a actuellement une Proof of Concept qui permet à partir d'un projet de récupérer les données interessante (via StrategoXT) et de les incorporer dans une base de données.

Je suis actuellement en train d'essayer de clarifier la modelisation de la db.
J'aimerai avoir votre avis sur le modele très simplifié de la db ci joint.

NB: Ce projet est opensource donc j'ai pour mission de le faire connaitre et de le partager.

Guillaume

[Bownobo]

Bonjour j'ai fait évolué le modèle de données en rajjoutant en vert sur le mcd les relations:

• fichiers appellent fichiers (include)
• functions appellent functions (fonction)
• packages appellent packages (packages)

Ainsi j'ai créer des tables pour représenter un affichage hierarchique.

Pensez vous que cela est viable, mon but étant d'afficher

• un arbre d'appels de fichiers
• un arbre d'appels de fonctions
• un arbre d'appels de package

[CinePhil]

Pour la modélisation des arbres, je te conseille la lecture de l'article de SQLPro.

Mais ce n'est peut-être pas utile dans ton cas car je pense qu'un module peut être appelé par plusieurs modules, de même qu'une fonction...

La représentation en arbre du résultat sera le boulot du logiciel de rétrodocumentation.

Au fait, si ce projet pouvait être un module d'Eclipse, ça serait super !

[Bownobo]

Bonjour,
Pour chacune de mes tables je pense faire le choix d'un clé informatique en auto_increment, j'aimerai savoir vu que d'aprés le modèle merise:

Règle n°2 : Dans le cas d'entités reliées par des associations de type 1:1, les tables doivent avoir la même clef.

De qu'elle manière les nommées.
Est ce qu'une colonne nommée 'id' est suffisante, ou vaut il mieux mettre 'id_nom_dela_table' mais dans ce dernier cas les tables n'auront pas la même clé.

[CinePhil]

Je préfère préfixer les noms de colonnes d'un code mnémotechnique qui me rappelle à quelle table elle se rapporte. Donc chez moi, il n'y a pas deux colonnes portant le même nom. D'ailleurs, certains modeleurs interdisent deux colonnes ayant le même nom dans le dictionaire de données (AnalyseSI par exemple).

Exemples :
Personne (P_Id, P_Nom, P_Prenom...)
Entreprise (E_Id, E_Nom...)

Et les clés étrangères ont chez moi un nom explicite au lieu du nom de la colonne de référence :

Personne -1,1----Travailler----0,n- Entreprise
==> Personne (P_Id, P_IdEntreprise, ...)

A moins que la règle à laquelle vous faites référence concerne en fait la notion d'héritage :

Voiture -1,1----Etre----0,1- Véhicule
==> Vehicule (Vh_Id, Vh_Immatriculation...)
Voiture (Vo_IdVehicule, Vo_NbCV, Vo_NbPlaces...)

Dans ce cas, la clé primaire de la table fille est également clé étrangère faisant référence à la clé primaire de la table mère.

D'où avez-vous extrait cette règle ?

[Bownobo]

Merci pour cette précieuse aide,
Je m'en vais l'appliquer dès que j'aurai compris un peu mieux votre message
La règle que j'ai cité provient de cette source:
http://brouardf.club.fr/SGBDRmerise5...11Relation_1_1

[JPhi33]

Bonjour Bownobo,

Je me permet d'intervenir pour te mettre en garde. Comme tu le sais, on peut trouver le meilleur comme le pire sur Internet.

En ce qui concerne la source (la page) que tu cites, je te conseille de l'oublier bien vite. Même si la solution proposée par l'auteur semble être pratique, il y a plusieurs réserves à formuler.

1) Elle dénature le MCD duquel elle est issue en faisant disparaître le Numéro d'appartement. Dans tous les cas, la suppression d'une information conceptuelle (une propriété) lors de la transformation MCD -> MLD doit être considérée comme une erreur fondamentale.

2) Pour la même raison, le NOTA situé au-dessous des deux premiers schémas est faux. Il propose de faire disparaître le Numéro_secu.

3) la 2e solution citée par l'auteur est fausse elle aussi car nous sommes dans le cas d'une association 1,1--0,1. En effet, pour les appartements vides la valeur de NUMERO_SECU sera NULL dans la table APPARTEM, ce qu'il vaut mieux éviter dans la mesure où il existe une autre solution. L'auteur a probablement confondu avec une association 1,1--1,1 en citant cette solution proposée par "certains systèmes" ; même dans ce cas, elle reste fausse.


La transformation correcte MCD -> MLD dans le cas d'une association 1,1--0,1 est naturelle et évidente. La table côté 1,1 se voit dotée de la clé de la table côté 0,1 (clé étrangère) afin d'y faire référence... et c'est tout : la table côté 0,1 n'a pas de référence vers l'autre table. Donc, ici, la table ETRE_HUM doit être munie de la clé de APPARTEM (NUMERO_APPARTEMENT) en tant que clé étrangère, ce qui est suffisant.

La solution a adopter dans le cas d'une association 1,1--1,1 est la même que celle du cas 1,1--0,1. Il faut juste choisir (judicieusement) quelle table joue le rôle 1,1 et laquelle joue le rôle 0,1.


Ceci ne remet pas en cause le reste des pages du site sur lesquelles je ne me prononce pas (je ne les ai pas lues).

[Bownobo]

Merci bien pour tous ces éclaircissements.
Je clos le sujet car nous allons utiliser un modèle de données antérieur qui a fait ses preuves. Nous avons des objectifs à remplir dans un laps de temps assez court. Ainsi nous préférons nous focaliser sur d'autres priorités. En attendant la création d'un nouveau modèle from scratch je clos le sujet.