|
Metadata Data Dependency
Metadata is fairly inter-related. Any change in an object can lead to changes in other objects. For example you are changing the semantic layer, whereby you are changing the mapping between the field (customer_id) and the name used by the user (from 'customer Code' to 'Customer Service Code'). On a side note, semantic layer is to enable users to attach user-friendly tags to the technical names. A good metadata system should be able to list out all the places where customer_id field exists, so that you can change the semantic mapping for all the locations of customer_id. This impact analysis should also be able to point out the changes needed in Metadata Extraction and Transformation
Metadata Lineage Analysis
A metadata tool should be able to have the audit trail for the source from where the metadata has come. As mentioned in ETL for Metadata, it is easy to have this audit trail as Metadata does not go through a major transformation, as it is pulled out of its source systems and placed in a central metadata repository. Doability is high for automated technical meta-data. For example, as you automatically extract the metadata from a CASE tool, the source can be placed in the table header or in the table records itself.
Access Management
- Control multi-user access to metadata: Metadata tool should be able to manage multiple users accessing the metadata in terms of write operations. It should be able to provide the standard locking mechanism so that only one user can update a metadata at one point of time.
- While metadata is being changed, there should be no restrictions on the read operation.
- Maintain audit trail on the access and updation of the metadata. In other words, maintain change and access history.
Searching
This is similar to browsing service of a data warehouse. A user should be able to:
- Explore through metadata objects like you do in windows explorer.
- Search through metadata by name, category, keyword or for some other parameter
Open API provides access
Metadata tool should be able to provide open API access from a variety of environments including Java, COM/DCOM and XML. This allows the metadata objects to be called for updation, addition or querying as your source systems or systems which are using metadata to work in an integrated fashion with your repository.
Import and Export
- Support standards: Metadata exchange standards have recently evolved. A tool should be able support standards like CWM (common warehouse meta-model) or/and XML.
- Should be able to import metadata from a variety of sources using available plug-ins.
- An import wizard can guide you through the import set-up where you can provide schedule, the rules for import and location for imported metadata.
- Export wizard should be able to enable you to provide the destination location of the exported metadata, the parts of the metadata that needs to be exported, the schedule for export etc.
- Exported metadata should contain all header information like source, schema, date of creation & modification, description etc.
Optional bridges Availability
Refer which Metadata architecture to use when? to understand the bridged approach. Bridged approach essentially works on point to point solution (instead of an open single metadata export-import method) across repositories with different technologies. A metadata tool, should be able to have 'bridges' available to link with most of the popular repository tools. |
