Format de métadonnées Excel - Import

Spécifications du pont

Fournisseur	Meta Integration Technology, Inc.
Nom de l'outil	Format de métadonnées Excel
Version de l'outil	Excel 2003 à 2010
Site Web de l'outil	Model Bridge (MIMB) Guide
Méthodologie supportée	[Gestion des métadonnées] Multimodèle, ETL (Data stores sources et cibles, Lignage de transformation, Parsage d'expressions) via un fichier Excel 2007 (XLSX)
Profiling de données
Collecte incrémentale
Collecte multi-modèle
Navigation dans le référentiel distant pour sélectionner un modèle

SPÉCIFICATIONS
Outil : Meta Integration Technology, Inc./Format de métadonnées Excel version Excel 2003 à 2010 via un fichier Excel 2007 (XLSX)
Consultez MIMB Known Limitations

Le format Excel Metadata n'est pas recommandé, particulièrement pour la documentation, notamment pour le Nom métier et la Description métier. Le client doit utiliser le format CSV à la place pour l'export, la modification et le réimport, comme expliqué dans le Guide d'utilisation, qui va documenter les data stores et non les définitions de connexions.

1. Toutes les feuilles de calcul de métadonnées sources doivent être définies au format Standard, car c'est le seul format qui est directement supporté. Pour accommoder une activité de migration héritée impliquant un grand nombre de feuilles de calcul existantes, le format attendu par le pont d'import n'est pas codé en dur mais défini par les feuilles de calcul vides spécifiant la manière dont chaque cellule de feuille de calcul est liée à un métamodèle de référentiel neutre. Cette flexibilité n'est disponible qu'avec un pont d'import personnalisé spécifique et qui doit être fourni par des services d'assistance.
2. Bien que les deux fonctions d'import (lecture à partir d'une feuille de calcul) et d'export (écriture dans une feuille de calcul) sont disponibles, elles ne sont pas faites pour supporter des allers-retours de re-traitement. Par exemple, les prérequis de mapping peuvent subir un traitement préalable dans un outil d'intégration de données/ETL mais le but de réexporter depuis cet outil d'intégration de données/ETL dans Excel est de fournir un résumé de lignage de mapping indépendant des diverses transformations internes complexes et de ne pas re-traiter la conception ni de la réimporter.
3. Les modèles d'outil de conception et d'architecture de données supportent des éditions de type aller-retour dans Excel afin d'exploiter les fonctions de correcteur d'orthographe, de copier-coller basé sur les colonnes et lignes et d'autres aspects pratiques inhérents à un environnement de feuille de calcul. Dans ce cas, la feuille de calcul doit être exportée, modifiée, puis réimportée dans l'outil de conception d'origine, tirant ainsi profit des fonctions de comparaison et de fusion fournies par l'outil de "réception".
4. Les nouveaux data stores sources ou cibles peuvent être exportés vers une feuille de calcul existante, mais sans bénéficier des fonctions de fusion ou de mise à jour cette fois. De plus, lors de l'import d'une feuille de calcul Excel dans un outil d'intégration de données/ETL, l'outil "récepteur" est responsable de l'intégration/la fusion des modèles ainsi que des mappings dans ses versions existantes.
5. Des suppositions et limitations sont fournies pour chaque format pré-défini dans le fichier ${MODEL_BRIDGE_HOME}\conf\MIRModelBridgeTemplate\MIRMicrosoftExcel\*-Blank.xlsx approprié.
6. Dans certains cas, l'utilisation d'une feuille de calcul pour gérer des métadonnées peut connaître des limitations. Par exemple, il n'existe pas de limite du nombre d'entités/tables par modèle ou du nombre d'attributs/colonnes par entité/table. Toutefois, il existe des limitations pour toute information représentée comme colonnes pour des raisons de facilité d'utilisation. Par exemple, l'imbrication de packages dans un modèle, le nombre de clés PK/FK/AK dans lesquelles un attribut/une colonne donné(e) est impliqué(e) et, plus important encore, le nombre de propriétés définies par l'utilisateur (UDP) personnalisées associées à une entité/table, un attribut/une colonne ou un type de données.
7. Le type de fichier plat supporte les fichiers plats délimités ou à largeur fixe. Les fichiers à largeur fixe utilisent l'attribut de position pour définir le "nombre absolu de caractères à partir du début de la ligne" pour chaque champ/colonne. Les fichiers délimités utilisent l'attribut de position pour reproduire l'ordre des champs/colonnes.
8. À propos de la différence entre Commentaires et Descriptions :
Un modèle de données physique possède un "Commentaire" sur une table qui au final est généré comme Commentaire SQL dans le DDL.
Un modèle de données logique possède une "Description" sur une entité. Cette entité logique peut être associée à une table physique si le modèle est Logique/physique. En revanche, un modèle Physique uniquement ne peut pas avoir ni de description, ni de commentaire par nature.
Par conséquent, si un ou une entité/table/enregistrement/vue/fichier a le niveau de conception Logique/physique, vous pourrez voir séparément un commentaire (physique) et une description (logique).
Toutefois, si un ou une entité/table/enregistrement/vue/fichier a le niveau de conception Physique uniquement, seule une description peut être prise du commentaire (physique) ou de la description (logique) si elle existe (dans ce cas le commentaire physique est ignoré).

SUPPORT
Fournissez un package de dépannage avec :
- le log de débogage (peut être défini dans l'UI ou dans conf/conf.properties avec MIR_LOG_LEVEL=6)
- la sauvegarde des métadonnées si disponible (peut être configurée dans le paramètre Divers avec l'option -backup, même si cette option commune n'est pas implémentée pour tous les ponts pour des raisons techniques).

Paramètres du pont

Mapping du pont