Différences entre versions de « Expertise EA »
m (1 version) |
m (1 révision importée) |
||
(2 versions intermédiaires par un autre utilisateur non affichées) | |||
Ligne 1 : | Ligne 1 : | ||
+ | =[[FAQ EA]]= | ||
+ | =[[L'outil de documentation]]= | ||
==Le meta modèle de EA== | ==Le meta modèle de EA== | ||
EA enregistre les informations que nous manipulons quand nous modélisons dans une base de données. | EA enregistre les informations que nous manipulons quand nous modélisons dans une base de données. | ||
Ligne 32 : | Ligne 34 : | ||
---- | ---- | ||
− | [[ | + | [[Expertise_EA|Retour]] |
Version actuelle datée du 6 mai 2016 à 12:58
FAQ EA[modifier | modifier le wikicode]
L'outil de documentation[modifier | modifier le wikicode]
Le meta modèle de EA[modifier | modifier le wikicode]
EA enregistre les informations que nous manipulons quand nous modélisons dans une base de données.
Lorsque l'on travaille en local, le fichier dans lequel le modèle est stocké porte le suffixe ".eap" mais ce n'est ni plus ni moins qu'un fichier de base de données Microsoft Access.
Lorsque l'on travaille avec un serveur, les modèles sont enregistrés dans le SGBD choisi par l'équipe, nous avons l'expérience d'installation avec SQL Server et MySQL, nous n'avons observé aucune différence de comportement entre les deux installations.
Dans tous les cas, il est très facile d'extraire les données dans Excel ou de faire du reporting sur les données, ceci ouvre la voie à de nombreux travaux dans le domaine de l'automatisation, des KPI, ...
Pour faire de bonnes analyses sur les modèles, il est nécessaire de comprendre le modèle de la base de données utilisée par EA, que nous appellerons le meta modèle de EA. Heureusement l'outil EA de reverse des bases de données fonctionne parfaitement sur le meta modèle de EA; ainsi nous pouvons documenter le meta modèle en utilisant EA.
Je ne suis pas expert de SQL Server, mais il me semble qu'il y assez peu de choses codées au niveau du meta modèle, en particulier les clés étrangères ne sont pas codées. Ceci nous oblige à faire de conjectures sur les liens entre les tables, mais les colonnes sont nommées de manière rigoureuse et le modèle est assez pure, il y a peu de risque de contre sens grave.
Une structure très récurrente dans les tables comporte les colonnes suivantes :
- <Object_ID> la clé primaire de la table
- <Object_name> Le nom de l'objet
- Parent_ID : la clé du père.
Les arbres et les bases de données[modifier | modifier le wikicode]
Les outils tels que les outils de modélisation utilisent massivement des structures de répertoires arborescentes calquées sur l'explorer de Windows. La représentation des arbres dans une base de données relationnelle n'est pas naturelle. Dans EA, de nombreuses tables comportent une colonne nommée "Parent_ID" pour représenter l'appartenance d'un objet à un répertoire, les répertoires étant eux mêmes des objets ( de type package). On a souvent besoin de connaitre le nom du père d'un objet (le plus souvent c'est le répertoire dans lequel il se trouve) dans Excel on ajoute une colonne avec une formule "vlookup" et en SQL on écrite quelque chose comme :
SELECT a.Object_ID, a.Name, a.ParentID, b.Name as ParentName FROM matable a, matable b WHERE a.ParentID = b.ParentID
Cette requête ne rapporte pas les lignes qui n'ont pas de Parent. Sinon on doit pouvoir faire un truc genre remplacer "matable b" par "(matable UNION (0,NULL)) b"