Différences entre versions de « Expertise EA »
m (1 version) |
|||
Ligne 1 : | Ligne 1 : | ||
+ | =[[FAQ EA]]= | ||
==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. |
Version du 30 mars 2012 à 16:32
FAQ EA
Le meta modèle de EA
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
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"