@Metadata@

Metadata

Introduction

This document establishes standards and a plan for the centralized storage of metadata for Administrative Computing. Presently, when metadata is created, it is often stored in the developer's tool of choice. This may be a Word or Excel document, a specially created database, the Designer tool recently purchased by MI, or handwritten notes in a developer's personal notebook. The effects of this approach are that developers and/or end-users often cannot find the metadata they need, cannot understand the metadata, cannot access the metadata, or have difficulty creating their own metadata.

An additional obstacle erected by this approach is the absence of synchronization of the varying pieces of metadata. Our production data does not exist in a vacuum, but our metadata often does! When multiple databases must "communicate" with each other, or when a developer leaves their area of expertise, locating information about the data or the database becomes very difficult. The result is increased development time, increased frustration, and a decrease in product quality.

This document seeks to integrate our metadata resources and apply formal documentation standards to our data efforts. Specifically, this document establishes:

how we will define metadata,
what our goal for metadata should be
the business case/justification for building and maintaining a metadata repository,
what the criteria are for a successful metadata repository,
the scope of this particular metadata repository,
the intended audience of this document,
the categories that make up our metadata, and
how we may go about implementing and maintaining our centralized metadata repository.

Definition

Metadata is loosely defined as "data about data." This general definition allows virtually any information about a database or its contents to be classified as "metadata." This is not a bad thing. What we must avoid is ruling out information as metadata because it does not fit within someone's personal, restrictive view of metadata. The categories described in the next section of this document will further document what is considered as metadata.

Goal

The goal of the metadata repository is to provide a central, easily accessible, and easily updateable repository of complete and accurate production database metadata. The metadata will provide both developers and end-users with full documentation and support for all Administrative Computing databases which allow updating and reading of core university data. In addition, it is anticipated that thorough metadata will be reflected in higher overall data quality and data completeness in the production databases.

In addition, it is the goal of these standards to establish Information Technology's Data Administration area as the one ultimately responsible for all metadata, although authority for individual pieces of metadata will be delegated. It is desired that maintenance of and access to the metadata repository will largely be a service of Data Administration. While Data Administration does not have the knowledge resources to fully populate the metadata repository, it is in the vision of this document that Data Administration would be of active assistance in populating and maintaining the information stored in the metadata repository.

Justification

Since the effort to create and maintain a high quality metadata repository is significant, the risks and benefits of such an effort must be analyzed. To understand the risks associated with not having a sound metadata repository, we need only review a few of the current trends in our data environment.

Online Transaction Processing Databases, Operational Data Stores, Data Warehouses

We are looking at an architecture involving frequent, rapid, and potentially large movements of data. An individual piece of data may be represented in multiple types of databases. In addition, one data element may have as its source multiple data elements from one or more databases. Some of these sources of data will be more reliable than others. The failure to have current metadata will make it difficult, if not impossible, to track where a piece of data has been propagated or what the source of a piece of data is. This will result in being unable to easily effect a change or to identify an authoritative source in the event of a problem.

Internet, Intranet, Web, BRIO, SAS

As we become more "user friendly" and present data through a number of different mediums, it becomes more important to know who has access to what from where. Failure to know this will make propagating changes difficult. In addition, with data easily available, tracking data security becomes much more important. Without a complete metadata repository, tracking security information for each data element is impossible.

E-Commerce

As we move toward E-Commerce, accurate metadata becomes even more important. Failure to have complete security and access information in this arena will prevent us from adequately tracking and protecting critical financial information.

Less Employee Stability, Skill Shortage

As employee's leave a project, a department, or the University, their knowledge often goes with them. In today's technical environment, these moves happen more frequently. If a metadata repository is not maintained, the knowledge of those employees is lost. In addition, failure to have a complete repository adds additional strain and learning times to new or transferred employees who are still developing their skills as they must learn not only their skill area but also research and comprehend the data environment.

Complex Data Types, Object Orientation

The database world is continually increasing its complexity. As we make use of new data types or new database designs, the need to document increases. The absence of the metadata repository severely hinders the developer's ability to grasp the complex environment.

Increased Rate And Magnitude Of Change

Not only is complexity increasing, but the rate at which it is increasing is getting faster and faster, and the order of magnitude of the changes seems to be getting larger and larger. Again, developers without the benefit of a repository will be fighting an uphill battle to keep up with the changes.

Demand Up, Resources Down

As our users become accustomed to "data-on-demand," their expectations and needs go up. They demand more services and expect them to be delivered more quickly. This is complicated by our difficulties in bringing in experienced personnel resources. The absence of a metadata repository increases the effort required by our limited resources as they must seek out and/or create their own metadata in support of the projects.

The benefits of a centralized repository, in addition to avoiding the aforementioned risks, include, but are not limited to the following:

Business Rules

The business rules which govern the meaning, transformations, storage and usage of data would be captured and documented as part of the metadata.

Data Quality

By thoroughly documenting the business rules which apply to a particular data element, we are more likely to fully enforce and confirm adherence to these business rules. Thereby, we can expect the overall quality of data in Administrative Computing to rise.

Integrated Data Source

By having an integrated, centralized metadata repository, all persons needing access to metadata will know where to go to look for it. In addition, entry and retrieval of the information will be standardized allowing end-users to more easily work with the information.

Establish Common Data Structure

Usage of a common metadata repository should lead to similar structures for new database efforts. This will improve data consistency between databases and make the development of database interfaces easier, faster, and more reliable.

Meet Future Needs

As data needs expand and grow in the future, a well-established metadata repository will provide for easier, more accurate migration to new models, data types, and strategies.

Criteria

A fundamental premise behind the implementation is that if quality metadata is not maintained and if those who need the data do not have easy access to it, the metadata repository will be a failure. The following criteria are required for a successful, useful metadata repository:

The repository must be populated from all production subject databases
The repository must contain quality and complete data
The repository must be easily maintainable via a usable front-end
The repository must be kept up to date on all subject databases
The repository must be easily accessible for reporting purposes
The repository must be adaptable to new database architictures

Scope

The scope for this collection of metadata is all Administrative Computing databases which allow updating and reporting of core university data by individuals from multiple departments. All administrative databases residing in Oracle, and perhaps some of the databases on the mainframe, are included in this scope.

Audience

The primary audience for this document is Data Stewards and developers and maintainers of administrative databases.

Categories

For the purposes of these standards, metadata is subdivided into three categories: business, relational, and technical.

Information which describes the function or role of the physical data in the business, using business terminology, is business metadata. Business metadata will be stored in the Metadata database currently being used by DSS.
Information which describes how entities, or business units, relate to one another is classified as relational metadata. This type of information would include Entity Relationship Diagrams (ERD's).
Information relating to the logical and physical composition, structure, storage, indexing, and movement of data, using terminology applicable to developers and database administrators, is technical metadata. Technical metadata will be stored in the Designer database.

Data regarding each of the three categories of metadata described above must be documented in either the Designer repository or in the "Metadata" repository. Business metadata must be documented in the "Metadata" database. The relational and technical metadata must be documented in the Designer tool for each applicable database. All relationships, whether enforced in the physical model or not, must be reflected in the logical model. Information must include degree, optionality, and logical textual descriptions. The following tables indicate the types of metadata which are required to be stored.

Relational Metadata

As has already been stated, relational metadata must be stored for all applicable applications in the Designer tool. The following table indicates the data that must be stored and the type of information that must be included. It is important to note that relational information is based upon the logical model of the database and not upon the physical model. Therefore, relationships or constraints which are not enforced in the database must be included in the metadata.

METADATA ELEMENT	VALUE RESTRICTIONS	DESCRIPTION	AUTHORITY
From Name	Lower case; Alphanumeric	Textual description of the relationship coming from the "sending" entity. Both ends of every relationship must have textual narrative.	DEVELOPER
To Name	Lower case; Alphanumeric	Textual description of the relationships coming from the "receiving" entity. Both ends of every relationship must have textual narrative.	DEVELOPER
Optionality	Mandatory or Optional	Indicates if the relationship is optional or mandatory. Optionality must be indicated for each end of every relationship.	DEVELOPER
Degree	1:1, 1:M, or M:M	Describes if the relationship is 1 to 1, 1 to Many, or Many to Many.	DEVELOPER
Primary UID	Yes or No	Indicates, for the child entity in a relationship, if the relationship with the parent defines part of the child entity's primary identifier.	DEVELOPER

Business Metadata

Business metadata will primarily be accessed by the end-users of an application. It may also be updated by Data Stewards or other information experts related to the database as designated by the appropriate Data Steward. This information describes the necessary business-related elements of each piece of data. This information is stored in the "Metadata" database and will be kept synchronized with the physical description of the database in the Designer repository.

METADATA ELEMENT	VALUE RESTRICTIONS	DESCRIPTION	AUTHORITY
Business Description	Alphanumeric Text.	Required for each data object (i.e. tables and columns) in the database. The narrative describes the data object from the business user's perspective.	DATA STEWARD
Category	CORE, DEPARTMENTAL, or PERSONAL	Indicates how widespread the data is shared around the University.	DATA STEWARD
Classification	PUBLIC, SENSITIVE, or RESTRICTED	While data classifications are still under development, these classifications will inform the user how the data item may be used and how the data must be handled.	DATA STEWARD
Common Name	Alphanumeric	The name of the data element as it is commonly known in the business or university.	DATA STEWARD
Data Steward	Chosen from list of authorized Data Stewards	The name of the Data Steward assigned responsibility for the data object.	DATA STEWARD
Help Description	Alphanumeric	User friendly instructions for the end-user regarding how to populated or use the data object.	DATA STEWARD
Security Level	COLUMN RESTRICTION, RESTRICTED, ROW RESTRICTION, SENSITIVE, UNRESTRICTED	Value indicating the level of sensitivity of the data element and the degree to which access to the data element should be restricted. (These are the values currently in use by DSS.) (These items may be superceded by the classifications mentioned above.)	DATA STEWARD
Security Reason	Alphanumeric	The logic behind the security level. Whether this eventually applies to security levels or classifications, the reason for the classification must be captured.	DATA STEWARD
Source	Alphanumeric	The application, business process, form, application process, etc. that is the originating point for the data stored in the data object. One object may have multiple sources, and the must all be documented.	DATA STEWARD/ DEVELOPER
Subscriptions	Valid database or reporting applications or department or personal names	A listing of any systems, departments, or individuals who have "subscribed" to the database for the purpose of duplicating the data in another environment/database. This is necessary for determining the potential impact of data changes.	DATA STEWARD/ DEVELOPER
Last Update	Date and/or Time	Indicates when data in the object were last updated. This is to be captured where appropriate.	DBA/ DEVELOPER

Technical Metadata

Technical metadata includes information regarding both the logical and physical structure of a database. This information is primarily useful to analysts, developers, and database administrators. It likely has little value to the business users. All of this information is to be stored in the Designer tool. Of the elements listed in the table, information must be stored when such information exists.

This list does not include all of the elements which may be tracked for a database; only those elements which are either mandatory or are "strongly recommended" are listed. Developers and administrators should feel free to make use of additional Designer fields as they deem necessary.

It is planned that Data Administration will assist with the population of all of the elements listed below to ease the burden on the developers.

METADATA ELEMENT	VALUE RESTRICTIONS	DESCRIPTION	AUTHORITY
Application Name	Alphanumeric; Maximum of 14 characters	The name of the database application. Designer limits this title to 14 characters.	DATA STEWARD
Entity Name	Alphanumeric; May be up to 40 characters, but under 30 is recommended. Must be singular and uppercase; Spaces are allowed.	This is the full or long name of an entity. An entity name may not be duplicated within an application. Abbreviations should be avoided.	DEVELOPER
Entity Short Name	Alphanumeric; Maximum of 8 characters	This is an abbreviated name or alias for the entity. A short name may not be duplicated within an application. The Short Name is sometimes used by developers and administrators.	DEVELOPER
Entity Plural Name	Alphanumeric; Maximum of 30 characters	The plural name of the entity. This name cannot be duplicated within an application. The Plural Name usually becomes the table name associated with the entity.	DEVELOPER
Entity Type Of	Super-type entity already entered into the application.	This element is used when needed to define super and sub-type entities. An entity cannot be a sub-type of an entity that has not yet been entered into the Designer repository.	DEVELOPER
Entity Description	Memo	A brief, textual description of the entity.	DEVELOPER
Entity Notes	Memo	Any notes about the entity. Designed for internal use among the analysts and developers.	DEVELOPER
Entity Unique Identifier	Valid attributes within the entity	The attribute(s) which define a unique occurrence for the entity. This attribute(s) will become the primary key for the associated table. Every entity must have a Unique Identifier.	DEVELOPER
Attribute Name	Alphanumeric; Maximum of 30 characters; Must be singular and uppercase; Spaces are allowed.	The name of an attribute within an entity. Abbreviations should be avoided.	DEVELOPER
Attribute Optionality	TRUE if attribute is optional; FALSE if attribute is mandatory.	Indicates whether or not a value is required for the attribute for every instance of the entity.	DEVELOPER
Attribute Format	Acceptable data formats for the host database.	The data type for the attribute. Should be noted that the CHAR data type should never be used for an Oracle database. Fixed and variable length alphanumeric fields should use the VARCHAR2 data type.	DEVELOPER
Attribute Maximum Length	Numeric	The maximum data length that may be required by the attribute.	DEVELOPER
Attribute Decimal Places	Numeric	The number of decimal places for numeric attributes.	DEVELOPER
Attribute Sequence in Entity	Numeric	Mandatory entry indicating the order in which the attribute appears in the entity. The order of attributes is as follows: PRIMARY ATTRIBUTES, UNIQUE ATTRIBUTES, REQUIRED ATTRIBUTES, FOREIGN KEY ATTRIBUTES, REMAINING NON-LOB ATTRIBUTES IN ALPHABETICAL ORDER, LOB ATTRIBUTES IN ALPHABETICAL ORDER.	DEVELOPER
Attribute Derivation	Alphanumeric; Maximum of 240 characters	Any algorithm or expression that describes how the value for a derived attribute is established (e.g., 7 x DAILY TOTAL gives the WEEKLY TOTAL).	DEVELOPER
Attribute Derivation Expression	Memo	A textual expression describing how the attribute is derived by the aforementioned expression.	DEVELOPER
Attribute Description	Memo	A brief, textual description of the attribute.	DEVELOPER
Attribute Notes	Memo	Any notes about the attribute. Designed for internal use among the analysts and developers.	DEVELOPER
Table Name	Alphanumeric; Maximum of 30 characters; Uppercase; Must be in plural form; Underscores must be used in place of spaces between logical breaks in words.	The full name of the database table. Oracle limits table names to 30 characters. Table names may not be duplicated in an application and should not be duplicated between applications, if possible.	DEVELOPER
Table Alias	Alphanumeric; Maximum of 8 characters (Designer allows 10 characters, but 8 is specified due to Novell filename restrictions.)	A unique alias for the table name. The table alias is used when generating candidate indexes for the table. The alias is also useful for qualifying column names in SQL queries where the column prefix is not used.	DEVELOPER
Table Start Rows	Numeric	An estimate of the number of rows for the initial table load. This information is vital for the DBA to be able to do size planning.	DEVELOPER
Table End Rows	Numeric	An estimate of the maximum number of rows that the table will hold. This information is vital for the DBA to be able to plan for database growth.	DEVELOPER
Table Tablespace	Selected from list of available tablespaces.	The name of the tablespace in which the table will be created.	DBA
Table Storage Definition	Select from list of available storage definitions.	Specifies the name of a set of storage parameters used to define future space allocation for the table in the database.	DBA
Table Pct Free	3 digits	Specifies a set amount of room in every block that is allocated to a table for future updates to the data of the table. This amount is expressed as a percentage. The default is 10.	DBA
Table Pct Used	3 digits	Specifies the minimum level of space usage that Oracle maintains for each block.	DBA
Table Description	Memo	A brief, textual description of the table.	DEVELOPER
Table Notes	Memo	Any notes about the table. Designed for internal use among the developers and administrators.	DEVELOPER, DBA
Table User Help Text	Memo	Help information for the end users to be associated with this table. If this table is not yet present in the "Metadata" database, this information will be used to initially populated the Help Description in that repository. It is important to note that the "Metadata" database is the authoritative source for this information! Information for this element will be overwritten with any information from the "Metadata" database!	DEVELOPER, DATA STEWARD
Column Name	Alphanumeric; Maximum of 30 characters; Avoid abbreviations where possible; Underscores must be used in place of spaces between logical breaks in words.	The database name of the column. Column names may not be duplicated within a table. Column names must be consistent in the naming and usage between tables as well as between applications.	DEVELOPER
Column Sequence	Numeric	The order of the column within the table. The ordering of columns is the same as the ordering for attributes (see above).	DEVELOPER
Column Domain	Select from list of available domains	An applicable domain which contains a "set" of business validation rules, format constraints, and other properties that apply to a group of columns. For example, a list of values, a range, a qualified list or range, or any combination of these.	DEVELOPER
Column Datatype	Select from list of available Oracle datatypes.	The Oracle datatype for the column. Note that for alphanumeric fields, the VARCHAR2 datatype should always be used. The CHAR datatype should never be used.	DEVELOPER
Column Maximum Length	5 digits	The maximum length of the data that the column can contain. This data must be provided for datatypes other than DATE.	DEVELOPER
Column Decimal Places	4 digits	The number of decimal places allowed for the column where the datatype is either NUMERIC or DECIMAL.	DEVELOPER
Column Optional	TRUE or FALSE	When set to True, this property indicates that the column can contain null values; i.e. the column is optional. Set this property to False to indicate that the column is mandatory.	DEVELOPER
Column Uppercase	TRUE or FALSE	Indicates whether the column values are to be stored in uppercase.	DEVELOPER
Column Default Value	Alphanumeric; Maximum of 40 characters	A value that is to be placed in the column if no other value is specified during an INSERT operation.	DEVELOPER
Column Oracle Sequence	Select from list of available Oracle sequences.	Specifies the name of a sequence for this column. This creates a unique value that will be inserted in the column.	DEVELOPER
Column Initial Volume	3 digits	The percentage of rows that will have a value in this column when the table is initially created. This value must be 100 if the column is not null. This information will be used by the DBA in determining space allocations for the table and for indexing.	DEVELOPER
Column Final Volume	3 digits	The percentage of rows that will have a value in this column when the table is in use. This value must be 100 if the column is not null. This information will be used by the DBA in determining space allocations for the table and for indexing.	DEVELOPER
Column Description	Memo	A brief, textual description of the column.	DEVELOPER
Column Notes	Memo	Any notes about the column. Designed for internal use among the developers and administrators.
Column User Help Text	Memo	Help information for the end users to be associated with this column. If this column is not yet present in the "Metadata" database, this information will be used to initially populated the Help Description in that repository. It is important to note that the "Metadata" database is the authoritative source for this information! Information for this element will be overwritten with any information from the "Metadata" database!	DEVELOPER, DATA STEWARD
Primary Key Constraint Name	Alphanumeric; Maximum of 30 characters. Avoid abbreviations where possible; Underscores must be used in place of spaces between logical breaks in words.	The brief name of the primary key constraint for the table. The name should be prefixed with the alias of the table and suffixed with "_PK". The name must be unique within the application. Every table developed at the University must have a Primary Key Constraint identified. (Note: Tables which are part of a purchased application may not have Primary Key Constraints.)	DEVELOPER
Primary Key Constraint Pct Free	3 digits	PCTFREE Value for Unique Index which implements this constraint.	DBA
Primary Key Constraint Storage Definition	Select from list of available storage definitions.	Specifies the name of a set of storage parameters used to define future space allocation for the index used in enforcing the Primary Key Constraint.	DBA
Primary Key Constraint Tablespace	Select from list of available tablespaces.	Specifies the name of the tablespace where the index used in enforcing the Primary Key Constraint will be stored.	DBA
Index Name	Alphanumeric; Maximum of 40 characters; Avoid abbreviations where possible; Underscores must be used in place of spaces between logical breaks in words.	The brief name of the index on the table. The name must be unique with the application.	DBA, DEVELOPER
Index Free Space to Allow	3 digits	A percentage of space to allow for growth of the index. The default is 10.	DBA
Index Storage Definition	Select from list of available storage definitions.	Specifies the name of a set of storage parameters used to define future space allocation for the index.	DBA
Index Tablespace	Select from list of available tablespaces.	Specifies the name of the tablespace where the index will be stored.	DBA
Index Text	Memo	A brief, textual description about this index including why it was created.	DBA
Index Notes	Memo	Any additional notes about this index.	DBA
Database Object Grants	TRUE or FALSE per grant type	For each Oracle Role granted access to a table, TRUE or FALSE is entered for each access privilege (Select, Insert, Update, Delete, Index, and Alter).	DBA, DEVELOPER
Sequence Name	Alphanumeric; Maximum of 30 characters	The name of an Oracle sequence used to generate unique numbers.	DEVELOPER
Sequence Start	Numeric; Maximum of 38 digits.	The number at which the sequence will start.	DEVELOPER
Sequence Increment	Numeric; Maximum of 38 digits.	The number by which the sequence is incremented. This number may have either a positive or a negative value. The default is 1.	DEVELOPER
Sequence Cache Value	Numeric; Maximum of 38 digits.	Specifies a pre-allocation of sequence numbers that can be cached in the memory. Such a pre-allocation will result in faster generation of sequence numbers. The default is 20.	DBA
Sequence Description	Memo	A brief, textual description about this sequence.	DEVELOPER
Sequence Notes	Memo	Any additional notes about this sequence.	DEVELOPER, DBA
Storage Definition Label	Alphanumeric; Maximum of 30 characters.	The name of the storage definition. Each definition will provide the characteristics to be used in storing one or more physical Oracle objects. Such objects are most commonly tables and indexes. A storage definition is required for each physical object requiring tablespace.	DBA
Storage Definition Initial Extent	Numeric; Maximum of 38 digits.	The size in bytes of the first extent that will be allocated when the object is created (i.e., the original amount of space allocated to the object).	DBA
Storage Definition Next Extent	Numeric; Maximum of 38 digits.	The size in bytes of every subsequent extent to be allocated.	DBA
Storage Definition Min Extents	Numeric; Maximum of 38 digits.	The initial number of extents to be allocated (i.e., the total number of extents to be allocated when the segment is created).	DBA
Storage Definition Max Extents	Numeric; Maximum of 38 digits.	The total number of extents that can ever be allocated. This total includes the first extent. The default is 9999 extents.	DBA
Storage Definition Percentage Increase	Numeric; Maximum of 38 digits.	The percentage by which each following extent will grow over the last extent allocated.	DBA
Storage Definition Description	Memo	A brief, textual description about this storage definition.	DBA
Storage Definition Notes	Memo	Any additional notes about this index.	DBA
Tablespace Name	Alphanumeric; Maximum of 30 characters	The name of the Oracle tablespace.	DBA
Tablespace Storage Definition	Select from list of available storage definitions.	Specifies the name of a default set of storage parameters used to define future space allocation for objects that are stored in this tablespace.	DBA
Tablespace Description	Memo	A brief, textual description about this storage definition.	DBA
Tablespace Notes	Memo	Any additional notes about this index.	DBA
Group Name	Alphanumeric; Maximum of 30 characters.	The name of the group (or role) of Oracle users.	DBA
Group Description	Memo	A brief, textual description about this group.	DBA
Group Notes	Memo	Any additional notes about this group.	DBA

Implementation

Implementation of this metadata strategy in adherence to the aforementioned criteria will be fairly complex and will require considerable resources. The following areas are seen as necessary in creating this repository.

Loading of technical metadata into Designer

This source of this data is the ADW repository, current development efforts, and DBA's. The ultimate responsibility for the technical documentation of Oracle-based applications will be the DBA's.

Modifications to existing Metadata database

There will be some fields that need to be added/changed to the Metadata repository to capture such items as Data Classification. In addition, for consistency, there are current values which may have to be altered. Data Stewards and WAI Support may have to work together to achieve a consistent usage of terminology.

Import of ADW information into Designer and "Metadata" database

The work that went into the ADW repository must not be lost. I am not an expert on what is in ADW, but I anticipate that both technical and business metadata will be gleaned from this source and entered into both Designer and the Metadata repository.

Creation of synchronize program for Designer and Metadata database

To avoid having duplicate entry of information, an automated synchronization program will have to be developed between Designer and the Metadata database.

Full Web interface

For reporting purposes, a web reporting feature, similar (identical?) to the one being used by DSS should be developed.

To achieve success in these areas, we should pursue the following:

Team to migrate ADW to Designer and "Metadata" database (Kathy Baker, Chad Sanders, Brad Skiles)

In progress. ADW data has been exported and is presently (11/16/1998) being entered into Designer)
This will likely require some PL/SQL programming to load some of the data.

Finalization of Data Classifications

Finalization of listing of core data with descriptions

Support of Project Teams/DBA's to maintain business and technical data.

Support of Project Teams, Data Stewards, WAI Support (?) to maintain business data.

Distribution of Designer for maintenance of technical metadata.

Distributionof ACCESS forms for maintenance of business metadata.

Renaming of "Metadata" database to reflect its planned usage (business metadata for multiple applications)?

PL/SQL programming to create synchronization program.

HTML programming to create full web interfaces

Coordination with Clif and ? to make any necessary modifications to the "Metadata" database and the DSS forms.

Provide Data Administration support to help maintain and to QA all metadata repositories.

IRM Links