Deploying predefined data warehouse process models

[0001] 1. Field of the Invention

[0002] The field of the invention is data processing, or, more specifically, methods, systems, and products for deploying predefined data warehouse process models.

[0003] 2. Description of Related Art

[0004] To deploy predefined warehouse models to installation sites other than their development sites, such as customer sites, data warehouse systems in prior art often export a set of predefined warehouse models in an interchangeable format such as a file formatted by use of a tag language. IBM's DB2 Data Warehouse Center (“DWC”), for example, exports a set of predefined warehouse models in an interchangeable format file formatted by such a tag language. In the example of the DWC, the tag language is the IBM Information Catalog tag language, an example of which is set forth in Appendix I. Another example of an interchangeable file format implemented in a tag language is the format of the Common Warehouse Model (“CWM”), an example of which is set forth in Appendix II. The exported interchangeable format file, which is generally referred to in this specification as an “interchange metadata file,” is imported in prior art more or less directly into a new warehouse control database in a new site such as a customer site. If the new site has the same environment as the computer which used to build the exported warehouse models, the new system can be set up and run with few problems.

[0005] The conventional approach to deployment of predefined warehouse models, however, does not work very well when elements of the models to be deployed are site dependent, that is, when some elements must vary from development site to a new site such as a customer site. Data warehouse applications usually define a set of data sources from which to extract data and a set of data targets for receiving data. These data sources and targets are usually sets of tables defined in different databases. The warehouse metadata generally captures or models the formats of the data sources and targets including the environment parameters of the development environment, whereas the data warehouse extraction processes were built in the development environment itself. When warehouse metadata is exported to an interchange metadata file, the information describing the transformation needed from the source to the target is captured or modeled there along with the default values of the development environment parameters.

[0006] Even in a deployment in which the same sets of tables exist in both data source and data target databases, these set of tables can be created with different users. In addition, the tables in source and target databases may be created using default table schema different from the development environment. Warehouse queries usually contain a full name for the database tables (i.e., schema.table_name) and database column names (i.e., schema.table_name.column_name). The interchange metadata file will retain the same representation of queries as they were generated in the development environment. For the customer site with different table schema, the predefined warehouse queries will not work in the new environment.

[0007] Customer databases may use database names different from the database names in the development environment, and the customer database maybe managed by different users. These kinds of information are embedded in the metadata and therefore in the interchange metadata file. Interchange metadata files bearing such incompatibilities will not be directly importable into the customer's environment.

[0008] In addition to the site dependent data elements mentioned, customer sites often use languages different from the language in which a data warehouse model was developed. For deploying the predefined warehouse process model to a customer site using a different language environment, warehouse products such as DB2 Data Warehouse Center translate certain default names such as ‘Default DWC User’ & ‘Default Security Group’ into different languages in the corresponding language version of the product. A predefined warehouse script in the default development environment, such as en_US, for example, cannot be imported properly into a warehouse control database in another language environment. In addition, in deploying a warehouse process model to an environment with a different language, the entries displayed to the customers need to be translated to the second language, such as, the process name, process step names, and so on. However, most translation tools do not support typical prior art interchange metadata file formats such as the tag file arrangement used in the DB2 Data Warehouse Center. In addition to all the other deployment problems in prior art, it is also true that the size of typical metadata interchange files is very large and therefore challenging to conversion and translation. There is an ongoing need in the art, therefore, for improved methods and means for converting and translating site dependent data elements and language dependent data elements in interchange metadata files for deployment of data warehouse process models.

[0009] Exemplary embodiments of the invention include methods of deploying a predefined data warehouse process model from a development system, the development system having a development environment to a customer system, the customer system having a customer environment, and the customer environment being different from the development environment. Embodiments of the invention typically include exporting metadata from the predefined warehouse process model to an interchange metadata file, in which the metadata includes data elements describing a development environment, in which the metadata includes at least some data elements having values that are site dependent. Some embodiments typically include copying, from the interchange metadata file to an interchange resource file, site dependent data elements, and identifying site dependent data values of the customer system. Other embodiments typically include converting, in the interchange metadata file, the site dependent data element values to the site dependent data values of the customer system, and importing the interchange metadata file into the customer system.

[0010] Exemplary embodiments of the invention include identifying site dependent data elements in which the site dependent data elements typically include language dependent data elements, and identifying site dependent data elements includes identifying language dependent data elements. Embodiments typically include building the predefined warehouse process model with unique names for site dependent data elements and with unique names for databases, database users, and table schemas. In some embodiments, copying, from the interchange metadata file to an interchange resource file, site dependent data elements typically includes copying, from the interchange metadata file into a translation resource file, language dependent data elements. Exemplary embodiments include translating the language dependent data elements into one or more customer languages and recording the translations in related fields in the translation resource file. In exemplary embodiments, identifying site dependent data values of the customer system typically includes identifying a customer language of the customer system, and converting, in the interchange metadata file, the site dependent data element values to the site dependent data values of the customer system includes converting language dependent data elements to the customer language of the customer site.

[0011] The foregoing and other objects, features and advantages of the invention will be apparent from the following more particular descriptions of exemplary embodiments of the invention as illustrated in the accompanying drawings wherein like reference numbers generally represent like parts of exemplary embodiments of the invention.

[0014] The present invention is described to a large extent in this specification in terms of methods for deploying predefined data warehouse process models. Persons skilled in the art, however, will recognize that any computer system that includes suitable programming means for operating in accordance with the disclosed methods also falls well within the scope of the present invention.

[0015] Suitable programming means include any means for directing a computer system to execute the steps of the method of the invention, including for example, systems comprised of processing units and arithmetic-logic circuits coupled to computer memory, which systems have the capability of storing in computer memory, which computer memory includes electronic circuits configured to store data and program instructions, programmed steps of the method of the invention for execution by a processing unit. The invention also may be embodied in a computer program product, such as a diskette or other recording medium, for use with any suitable data processing system.

[0016] Embodiments of a computer program product may be implemented by use of any recording medium for machine-readable information, including magnetic media, optical media, or other suitable media. Persons skilled in the art will immediately recognize that any computer system having suitable programming means will be capable of executing the steps of the method of the invention as embodied in a program product. Persons skilled in the art will recognize immediately that, although most of the exemplary embodiments described in this specification are oriented to software installed and executing on computer hardware, nevertheless, alternative embodiments implemented as firmware or as hardware are well within the scope of the present invention.

[0017] In this specification, the following terms are used as defined here. Other terms are defined elsewhere in the specification and used as defined.

[0018] In this specification, the terms “field,” “data element,” and “attribute” are used as synonyms, referring to individual elements of digital data. Aggregates of data elements are referred to as “records” or “data structures.” Aggregates of records are referred to as “tables” or “files.” Aggregates of tables or files are referred to as “databases.” Definitions of complex data structures that include member methods, functions, or software routines in addition to data elements are referred to as “classes.” Instances of complex data structures are referred to as “objects” or “class objects.”

[0019] “Data warehouse process model” is a metadata system which contains definitions of warehouse sources and targets, user defined transformations for tables and fields, a set of warehouse processes for data transformation and movement, and the flow and schedule of process execution. A warehouse process comprises a series of steps for data transformation and movement.

[0020] “Environment,” in this specification, refers to the state of a data warehouse process model as indicated by data elements, environment parameters, whose values fulfill that purpose. Environment parameters include database names, authorized login user names, table schema, and so on. In this sense, the term “environment” is used slightly differently in this specification than in computer technology generally. In this specification, “environment” refers to an environment of a data warehouse process model rather than to the environment of a computer system generally. “Environment,” as the term is used generally in computer technology, refers to the state of a computer as such rather than a data warehouse model. The state of a computer is usually determined, for example, by which programs are running on it and by the computer's basic hardware and software characteristics. For example, when one speaks of running a program in a UNIX environment, it means running a program on a computer that has the UNIX operating system. Many operating systems support choices of command prompt or a default command path. Such parameters taken together are said to constitute an environment. Similarly, in this specification, the set of data warehouse environment parameters taken together are said to comprise an “environment.” In this sense, a development system has, for a data warehouse model defined upon it, a development environment, and a customer system has a customer environment. It is a principal technical subject of this specification that a development environment and a target customer environment are different.

[0021] A “schema” is a grouping or collection identifier for a set of database objects, including, for example, tables, views, user-defined functions, stored-procedures, sequences, synonyms, indexes, clusters, database links, snapshots, and packages, and so on. A schema is a collection of database objects. Schema typically are owned by individuals, and an owner controls access to data and objects within a schema. A schema is also a database object. Schemas in some circumstances are created automatically, such as when a first object in a schema is created. Such a first object is anything qualified by a schema name, such as a table, index, view, package, distinct type, function, trigger, and so on.

[0022] In many embodiments, a “schema name” is used as the first part of a two-part object name. When an object is created, it can be assigned to a specific schema. If no schema is expressly assigned for a new object, the new object is typically assigned to a default schema, which is typically the user ID of the person who created the object. The second part of the two part object name is the name of the object itself. For example, a user named Smith might have a table named SMITH.PAYROLL.

[0023] “Data format” as the term in used in this specification refers to the structure of a database system. Data formats typically are in a formal language or in metadata supported by a database management system. Data formats typically define tables, fields in tables, and relationships between fields and tables. Data formats typically are stored in data dictionaries. Although data formats often are defined in text database language, the term is often used also to refer to graphical depictions of database structures. In this specification, we distinguish data formats and data schema. Schema are collections of database objects. Data formats are definitions of database objects and descriptions of relations among database objects.

[0024] In this disclosure, improved means and methods of warehouse model deployment are presented. The improved approach successfully deploys pre-build warehouse models to multiple operations sites with different site and language environments. Although many of the examples in this disclosure are given in terms of IBM's DB2 Data Warehouse Center and Data Warehouse Manager, in fact, the means and methods disclosed are useful in the environments of many warehouse management and deployment systems, including particularly those that use interchange metadata formats like tag files or other metadata exchange files in text format.

[0025] This disclosure views the deployment problem generally as involving three main development and installation periods: (1) Development of the Predefined Warehouse Process Models (2) Prepare for Deployment, and, (3) Customized Setup. Developing the predefined warehouse process model is viewed as including identifying site dependent information, Identifying language dependent information, and Building a predefined warehouse process model with particular attention to the format of data elements that tend to be site dependent.

[0026] Preparing for deployment is viewed as including Exporting metadata to an Interchange metadata file and Extracting language related information for translation.

[0027] Customized setup is viewed as including detecting site related information in the customer site, converting the interchange metadata file to conform to the requirements of the customer site, and importing the converted interchange metadata file into the customer system.

[0028] Turning now to FIG. 1, an exemplary embodiment of the invention is shown as a method of deploying a predefined data warehouse process model from a development system to a customer system. The example development system has a development environment, and the customer system has a customer environment. The customer environment is different from the development environment. Exemplary embodiments typically include exporting (114) metadata from the predefined warehouse process model to an interchange metadata file (124), where the metadata includes data elements describing a development environment, and the metadata includes at least some data elements with values that are site dependent.

[0029] Exporting (114) metadata from the predefined warehouse process model to an interchange metadata file (124), in the example of IBM's DB2 Data Warehouse Center, includes exporting the metadata into an interchange metadata file format implemented in a tag language. The tag language of IBM's DB2 Data Warehouse Center (“the DWC tag language”), examples of which are set forth in Appendix I, like some other export functions, makes no particular provision for identifying site dependent data elements in exported metadata. Another example of an interchangeable file format implemented in a tag language, making no particular provision for identifying site dependent data elements in exported metadata as such, is the format of the Common Warehouse Model (“CWM”), implemented by use of the eXtended Markup Language (“XML”), an example of which is set forth in Appendix II. In this kind of embodiment, where the export function and the tag language formatting the interchange data file make no particular provision for identifying site dependent data elements, site dependent data elements including language dependent data elements often are identified and copied out of the interchange metadata file by viewing the interchange metadata file in an application, such as a word processor, and exercising copy and paste operations to copy site dependent data elements into a resource file.

[0030] Still other embodiments utilize other tag languages, tag languages capable of indicating site dependent or language dependent data elements, such as for example, other embodiments based on XML, to identify site dependent elements, as illustrated by the following tag language pseudocode:

[0031]

<table>

tablename=“table 1”

<data element>

dataElementName=“Field One”

dataElementValue=“XYZ”

dataElementSiteDependent=“True”

</data element>

<data element>

dataElementName=“Field Two”

dataElementValue=“123”

dataElementLanguageDependent=“True”

</data element>

</table>

[0032] Some embodiments that use tag languages capable of indicating site dependent or language dependent data elements include software routines that scan the interchange, metadata file for data elements indicated as site dependent or language dependent and copy those data elements to a resource file such as an interchange resource file or a translation resource file. Such embodiments typically have the advantage of being more amenable to full automation than embodiments that have no provision within the interchange metadata file itself for identifying site dependent or language dependent data elements.

[0033] Deploying predefined warehouse models to multiple customer sites having site dependent variations in metadata models, including language dependent variations in metadata models, typically includes particular planning, including for example, identifying site dependent information. In the example of the DB2 Data Warehouse Center, examples of site dependent information include, for the extraction source database, the database name, the database login user name, and the database table schema. For the extraction target database, examples of site dependent information include the database name, the database login user name, and the database table schema. Other example site dependent data elements include, for example, system environment variables.

[0034] Embodiments typically include copying (126), from the interchange metadata file to an interchange resource file (128), site dependent data elements, identifying (122) site dependent data values of the customer system, and converting (130), in the interchange metadata file (132), the site dependent data element values to the site dependent data values of the customer system.

[0035] More specifically, in addition to identifying and copying to an interchange resource file the site dependent data elements, typical embodiments include the actual values from the customer environment of the site dependent elements or site dependent parameters. In addition, the pre-identified site dependent parameter values in typical embodiments generally are allocated from the customer site before the tag file is loaded into the customer site warehouse control database. More specifically, it is typical in embodiments of the present invention to convert to customer environment values the site dependent parameters in the interchange resource file.

[0036] The language environment information, the language of the customer site, also is obtained at this time in typical embodiments, to determine which language version of the translation resource file is to be used to convert the language dependent data elements of the interchange metadata file.

[0037] Embodiments of the kind illustrated typically include converting (130), in the interchange metadata file (132), the site dependent data element values to the site dependent data values of the customer system. More specifically, exemplary embodiments carry out the conversion of the site dependent data element values as illustrated in the following example pseudocode:

[0038]

Define array old_str[i] for storing development site information
Set development site dependent strings into old_str[i]
Defined array new_str[i] for storing customer site information
Set corresponding customer site strings into new_str[i]
If customer site has different language environment
Set language specific information to both old_str[i] and new_str[i]
Open default Tag File for read (file_in)
Open a new file for writing the converted file (file_out)
For each line in file_in (a_line)
	If a_line is a comment line or empty line
	Write a_line back to file_out
	Else
	If a_line contains any string in old_str[i]
	For each string in old_str[i]
	If old_str[i] exists in a_line
	Replace all old_str[i] with new_str[i]
	End if
	End for
	Write replaced a_line back to file_out
	Else
	Write a_line back to file_out
	Endif
	Endif
End for
Close file file_out
Close file fine_in

[0039] Exemplary embodiments also include importing (120) the interchange metadata file into the customer system. The import function is typically a software routine provided as part of the data warehouse management system in the customer environment.

[0040] As mentioned, typical example embodiments include identifying (134) site dependent data elements (136), more specifically, for example, site dependent data elements in the development environment. The site dependent data elements so identified typically comprise the site dependent data elements to be extracted or copied into an interchange resource file. Some data warehouse metadata schema make no provision for identifying site dependent data elements. Inn such systems, where the metadata schema itself does not identify site dependent data elements, site dependent data elements including language dependent data elements often are identified simply by inspecting the system parameters of the source and target databases and observing the ones that change from environment to environment. Thereafter, as mentioned above, in such embodiments it is typical to copy such data elements out of the interchange metadata file by viewing the interchange metadata file in an application, such as a word processor, and exercising copy and paste operations to copy site dependent data elements into a resource file.

[0041] In exemplary embodiments of the kind illustrated in FIG. 2, the site dependent data elements include language dependent data elements, and identifying (134) site dependent data elements (136) includes identifying language dependent data elements (138). In many embodiments, the language dependent information is copied into a translation resource file. The translation resource file in some embodiments, for example, uses a so-called ‘Java property file format,’ because most translation tools recognize this Java property file format. In such embodiments, the translation resource file typically is sent to a translation center, an automated language translation service, and translated into the different languages the product is planned to support. It is usual in such example embodiments, after the data elements for translation are identified and copied to the translation resource file to translate the language dependent data elements into several languages at the same time and store the several languages back in the translation resource file. In this way, when the language for a customer site is identified, the translation for the language dependent data elements is already available in the translation resource file. In such embodiments, the actual process of converting the language dependent elements in the interchange metadata file is to scan the interchange metadata file for lines containing language dependent data elements, substituting a translation from the translation resource file for the language dependent data element in the interchange metadata file.

[0042] It is useful in typical embodiments to take certain precautions in building predefined warehouse process models for deployment among customer sites having site dependent data elements. Exemplary embodiments typically include building (142) the predefined warehouse process model (140) with unique names for site dependent data elements and with unique names for databases, database users, and table schemas. It is also useful in various embodiments to select table schema names that are likely to be unique with respect to customer database table schema names.

[0043] In some embodiments, copying (126), from the interchange metadata file to an interchange resource file, site dependent data elements typically includes copying (116) language dependent data elements from the interchange metadata file into a translation resource file (110). Embodiments typically include translating (112) the language dependent data elements into one or more customer languages and recording the translations in related fields in the translation resource file (110). In exemplary embodiments, identifying (122) site dependent data values of the customer system typically includes identifying a customer language of the customer system, and converting (130), in the interchange metadata file, the site dependent data element values to the site dependent data values of the customer system typically includes converting language dependent data elements to the customer language of the customer site.

[0044] To support internationalization of a product, data warehouse information typically is displayed to end users translated into the customer language environment, and the product is typically able to operate in several supported language environments. For the warehouse processes models, developed the development language environment, the language specific information is converted to different languages. For the warehouse system models built with DB2 Data Warehouse Center (“DWC”), for example, the language specific information typically includes the names of a set of default DWC objects, which includes ‘Default DWC User’, ‘Default Security Group’, and ‘Default DWC AgentSite’. In various embodiments, language specific data elements include, for example, warehouse process names, process step names, and warehouse subject names. An “AgentSite” object carries connection information to a machine where a warehouse agent deamon is running. The ‘Default DWC AgentSite’ is a system predefined AgentSite which runs on the warehouse server machine on the NT/W2K system only. A “warehouse subject” is a group of warehouse process with similar means. A warehouse typically has multiple warehouse subjects defined. Warehouse subjects typically contain multiple warehouse processes. Warehouse process typically contain multiple process steps.

[0045] FIG. 2 is now used as the basis for the discussion of a use case for a deployment in which site dependent data elements include language dependent data elements. As illustrated in FIG. 2, typical embodiments of the invention include methods of deploying a predefined data warehouse process model (140) from a development system (102, 104) to a customer system (106, 108). The development system (102, 104) has a development environment, and the customer system (106, 108) has a customer environment. The customer environment is different from the development environment.

[0046] The illustrated exemplary embodiment includes identifying (134) data elements having values that are site dependent (136), identifying (134) data elements having values that are language dependent (138), and building (142) the predefined warehouse process model with unique names for site dependent data elements and with unique names for databases, database users, and table schemas. Embodiments of the kind illustrated typically include exporting (114) metadata from the predefined warehouse process model to an interchange metadata file (124), in which the metadata includes data elements describing a development environment, in which the metadata includes at least some data elements having values that are site dependent.

[0047] Embodiments of this kind typically include copying (116), from the interchange metadata file (124) into a translation resource file (110), the language dependent data elements (138), and copying (126), from the interchange metadata file (124) to an interchange resource file (128), the site dependent data elements (136). Such embodiments include translating (112) the language dependent data elements into one or more customer languages and recording the translations in related fields in the translation resource file (110). Such embodiments include identifying (122) a customer language of the customer system, and identifying (122) site dependent data values of the customer system. Such embodiments typically include converting (130) language dependent data elements to the customer language of the customer site, that is, converting, in the interchange metadata file, in dependence upon the contents of the translation resource file, the customer language, and the contents of the interchange resource file, the site dependent data element values, including the language dependent data elements, to the site dependent data values of the customer system, and importing (120) the interchange metadata file into the customer system.

[0048] The improved approach extends the portability of predefined warehouse processes model to multiple site and multiple language environments. Only a single copy of the predefined process model is needed for distribution. The model can be dynamically modified while installed to the new site before it is imported to the warehouse control database in the new site. The improved approach extends the application area for warehouse related systems from system specific applications to a development tool which can build portable warehouse processes across different systems with different languages. This approach can be applied to any interchangeable warehouse metadata represented in tag language or other formats where the related site dependent and language dependent data elements or parameters can be identified and replaced.

[0049] It will be understood from the foregoing description that various modifications and changes may be made in the exemplary embodiments of the present invention without departing from its true spirit. The descriptions in this specification are for purposes of illustration only and should not be construed in a limiting sense. The scope of the present invention should be limited only by the language of the following claims.

[0050] This Appendix I sets forth an example of IBM Information Catalog Tag Language, an exemplary tag language for use in interchange metadata files.

• [0051] :DISHCNTL.SEQUENCE(1,-)
• [0052] :COMMENT.SYSTEM(V7.2.0)
• [0053] :COMMENT.
• [0054] :COMMENT. DB2 Universal Database 7.2
• [0055] :COMMENT. Source Database name: wcactrl
• [0056] :COMMENT. Output File name: H:\wcatest\export\expxl\TestMartt.tag
• [0057] :COMMENT. Time Nov. 20, 2001 17:21:19
• [0058] :COMMENT.
• [0059] :COMMENT. Start Process export
• [0060] :COMMENT. Exporting Process Test Process
• [0061] :COMMENT.
• [0062] :COMMENT. Begin INFOGRPS Instance
• [0063] :COMMENT.
• [0064] :ACTION.OBJINST(MERGE)
• [0065] :OBJECT.TYPE(INFOGRPS)
• [0066] :INSTANCE.
  • [0067] NAME(New Subject area)
  • [0068] CONTACT(Default DWC User)
• [0069] :COMMENT.
• [0070] :COMMENT. End INFOGRPS Instance
• [0071] :COMMENT.
• [0072] :COMMIT.CHKPID(10)
• [0073] :COMMENT.
• [0074] :COMMENT. Begin IWHSCGRP Instance
• [0075] :COMMENT.
• [0076] :ACTION.OBJINST(MERGE)
• [0077] :OBJECT.TYPE(IWHSCGRP)
• [0078] :INSTANCE.
  • [0079] NAME(Default Security Group)
  • [0080] SHRTDESC(This is the default Data Warehouse Center Security Group created by the Data Warehouse Center product.)
• [0081] :COMMENT.
• [0082] :COMMENT. End IWHSCGRP Instance
• [0083] :COMMENT.
• [0084] :COMMENT.
• [0085] :COMMENT. Begin IWHUFUNC Instance
• [0086] :COMMENT.
• [0087] :ACTION.OBJINST(MERGE)
• [0088] :OBJECT.TYPE(IWHUFUNC)
• [0089] :INSTANCE.
  • [0090] NAME(UFAdministration)
  • [0091] SHRTDESC(Administration)
• [0092] :COMMENT.
• [0093] :COMMENT. End IWHUFUNC Instance
• [0094] :COMMENT.
• [0095] :COMMENT.
• [0096] :COMMENT. Relation: IWHSCGRP to IWHUFUNC
• [0097] :COMMENT.
• [0098] :ACTION.RELATION(ADD)
• [0099] :RELTYPE.TYPE(CONTAIN) SOURCETYPE(IWHSCGRP) TARGETYPE(IWHUFUNC)
• [0100] :INSTANCE.
  • [0101] SOURCEKEY(NAME(Default Security Group))
  • [0102] TARGETKEY(NAME(UFAdministration))
• [0103] :COMMENT.
• [0104] :COMMENT.
• [0105] :COMMENT. Begin IWHUFUNC Instance
• [0106] :COMMENT.
• [0107] :ACTION.OBJINST(MERGE)
• [0108] :OBJECT.TYPE(IWHUFUNC)
• [0109] :INSTANCE.
  • [0110] NAME(UFOperations)
  • [0111] SHRTDESC(Operations)
• [0112] :COMMENT.
• [0113] :COMMENT. End IWHUFUNC Instance
• [0114] :COMMENT.
• [0115] :COMMENT.
• [0116] :COMMENT. Relation: IWHSCGRP to IWHUFUNC
• [0117] :COMMENT.
• [0118] :ACTION.RELATION(ADD)
• [0119] :RELTYPE.TYPE(CONTAIN) SOURCETYPE(IWHSCGRP) TARGETYPE(IWHUFUNC)
• [0120] :INSTANCE.
  • [0121] SOURCEKEY(NAME(Default Security Group))
  • [0122] TARGETKEY(NAME(UFAdministration))
• [0123] :COMMIT.CHKPID(20)
• [0124] :COMMENT.
• [0125] :COMMENT. Begin PROCESS Instance
• [0126] :COMMENT.
• [0127] :ACTION.OBJINST(MERGE)
• [0128] :OBJECT.TYPE(PROCESS)
• [0129] :INSTANCE.
  • [0130] NAME(Test Process)
  • [0131] CONTACT(Default DWC User)
  • [0132] PRCTYPE(1)
• [0133] :COMMENT.
• [0134] :COMMENT. End PROCESS Instance
• [0135] :COMMENT.
• [0136] :COMMENT.
• [0137] :COMMENT. Relation: INFOGRPS to PROCESS
• [0138] :COMMENT.
• [0139] :ACTION.RELATION(ADD)
• [0140] :RELTYPE.TYPE(CONTAIN) SOURCETYPE(INFOGRPS) TARGETYPE(PROCESS)
• [0141] :INSTANCE.
  • [0142] SOURCEKEY(NAME(New Subject area))
  • [0143] TARGETKEY(NAME(Test Process))
• [0144] :COMMENT.
• [0145] :COMMENT.
• [0146] :COMMENT. Relation: PROCESS to IWHSCGRP
• [0147] :COMMENT.
• [0148] :ACTION.RELATION(ADD)
• [0149] :RELTYPE.TYPE(LINK) SOURCETYPE(PROCESS) TARGETYPE(IWHSCGRP)
• [0150] :INSTANCE.
  • [0151] SOURCEKEY(NAME(Test Process))
  • [0152] TARGETKEY(NAME(Default Security Group))
• [0153] :COMMENT.
• [0154] :COMMENT.
• [0155] :COMMENT. Begin IWHAGENT Instance
• [0156] :COMMENT.
• [0157] :ACTION.OBJINST(MERGE)
• [0158] :OBJECT.TYPE(IWHAGENT)
• [0159] :INSTANCE.
  • [0160] NAME(Default DWC AgentSite)
  • [0161] SHRTDESC(Default AgentSite created by the Data Warehouse Center product to represent the Data Warehouse Center Server.)
  • [0162] AGTOSTY(1)
  • [0163] AGTMODNM(IWH2AGNT)
• [0164] :COMMENT.
• [0165] :COMMENT. End IWHAGENT Instance
• [0166] :COMMENT.
• [0167] :COMMIT.CHKPID(30)
• [0168] :COMMENT.
• [0169] :COMMENT. Begin DATABASE Instance
• [0170] :COMMENT.
• [0171] :ACTION.OBJINST(MERGE)
• [0172] :OBJECT.TYPE(DATABASE)
• [0173] :INSTANCE.
  • [0174] NAME(New Target)
  • [0175] DBNAME(wcamart)
  • [0176] DBTYPE(1)
  • [0177] DBETYPE(11)
  • [0178] ISWH(Y)
  • [0179] USERID(martuser)
  • [0180] CONTACT(Default DWC User)
  • [0181] USEODBC(N)
  • [0182] CODEPAGE(437)
  • [0183] VERSION(07.02.0002)
  • [0184] DBMSSERV(DB2)
  • [0185] DFLTDEL(″)
  • [0186] WEBDBTYP(−1)
• [0187] :COMMENT.
• [0188] :COMMENT. End DATABASE Instance
• [0189] :COMMENT.
• [0190] :COMMENT.
• [0191] :COMMENT. Relation: DATABASE to IWHAGENT
• [0192] :COMMENT.

[0193] This Appendix II sets forth an example of Common Warehouse Model Tag Language, an exemplary tag language for use in interchange metadata files.

• [0194] <?xml version=“1.0” encoding=“UTF-8”?>
• [0195] <!DOCTYPE XMI SYSTEM “cwm.dtd”[
• [0196] <!ELEMENT ixafs (ixaftv)+>
• [0197] <!ATTLIST ixafs
  • [0198] n CDATA #REQUIRED
• [0199] >
• [0200] <!ELEMENT ixaftv EMPTY>
• [0201] <!ATTLIST ixaftv
  • [0202] t CDATA #REQUIRED
  • [0203] v CDATA #REQUIRED
• [0204] >]>
• [0205] <XMI xmi. version=“1.1” timestamp=“Tue Nov 20 17:19:39 CST 2001”
• [0206] xmlns:CWM=“org.omg.CWM1.0/Foundation” xmlns:UML=“org.omg.UML1.3”
• [0207] xmlns:CWMWHP=“org.omg.CWM1.0/WarehouseProcess”
• [0208] xmlns:CWMTFM=“org.omg.CWM1.0/Transformation”
• [0209] xmlns:CWMRDB=“org.omg.CWM1.0/Relational”>
  • [0210] <XMI.header>
  • [0211] <XMI.documentation>
  • [0212] <XMI.exporter>XMI Application Framework</XMI.exporter>
  • [0213] <XMI.exporterVersion>1.15</XMI.exporterVersion>
  • [0214] <XMI.documentation>
  • [0215] <XMI.header>
  • [0216] <XMI.content>
  • [0217] <CWM:SoftwareSystem xmi id=“_—1” name=“DWC”>
  • [0218] <UML:Namespace.ownedElement>
  • [0219] <UML:Component xmi.id=“_—1.1” name=“IWH2AGNT” namespace=“_—1”/>
  • [0220] </UML:Namespace.ownedElement>
  • [0221] </CWM:SoftwareSystem>
  • [0222] <UML:Class xmi.id=“_—2” name=“Not available”>
  • [0223] <UML:Classifier.feature>
  • [0224] <UML:Attribute xmi.id=“_—2.1” name=“Not available”/>
  • [0225] <UML:Classifier.feature>
  • [0226] </UML:Class>
  • [0227] <UML:DataType xmi.id=“_—3” name=“1”/>
  • [0228] <UML:DataType xmi.id=“_—4” name=“2”/>
  • [0229] <UML:DataType xmi.id=“_—5” name=“3”/>
  • [0230] <CWM:ResponsibleParty xmi.id=“_—6” name=“Default DWC User”
• [0231] modelElement=“_—1”/>
  • [0232] <UML:Package xmi.id=“_—7” name=“New Subject area”>
  • [0233] <UML:Namespace.ownedElement>
  • [0234] <CWMWHP:WarehouseProcess xmi.id=“_—7.1” name=“Test Process”
• [0235] namespace=“_—7” clientDependency=“_—19_—20” transformationActivity=“_—21”>
  • [0236] <UML:ModelElement.taggedValue>
  • [0237] <UML:TaggedValue xmi.id=“_—7.1.1” tag=“PROCESSTYPE” value=“1”
• [0238] modelElement=“_—7.1”/>
  • [0239] </UML:ModelElement.taggedValue>
  • [0240] </CWMWHP:WarehouseProcess>
  • [0241] </Namespace.ownedElement>
  • [0242] </Package>
  • [0243] <CWM:ResponsibleParty xmi.id=“_—8” name=“Default DWC User”
• [0244] modelElement=“_—7.1”/>
  • [0245] CWMRDB:Catalog xmi.id=“_—9” name=“wcamart”>
  • [0246] <UML:ModelElement.taggedValue>
  • [0247] <UML:TaggedValue xmi.id=“_—9.1” tag=“IRNAME” value=“New Target”
• [0248] modelElement=“_—9”/>
  • [0249] <UML:TaggedValue xmi.id=“_—9.2” tag=“ISWH” value=“Y”
• [0250] modleElement=“_—9”/>
  • [0251] <UML:TaggedValue xmi.id=“_—9.3” tag=“USERID” value=“martuser”
• [0252] modelElement=“_—9”/>
  • [0253] <UML:TaggedValue xmi.id=“_—9.4” tag=“USEODBC” value=“N”
• [0254] modelElement=“_—9”/>
  • [0255] <UML:TaggedValue xmi.id=“_—9.5” tag=“CODEPAGE” value=“437”
• [0256] modelElement=“_—9”/>
  • [0257] <UML:TaggedValue xmi.id=“_—9.6” tag=“VERSION”value=“07.02.0002”
• [0258] modelElement=“_—9”/>
  • [0259] <UML:TaggedValue xmi.id=“_—9.7” tag=“DBMDEL” value=“&#34;”
• [0260] modelElement=“_—9”/>
  • [0261] </UML:ModelElement.taggedValue>
  • [0262] <UML:Namespace.ownedElement>
  • [0263] <CWMRDB:Schema xmi.id=“_—9.8” name=“WCAMNG” namespace=“_—9”>
  • [0264] <UML:Namespace.ownedElement>
  • [0265] <CWMRDB:BaseTable xmi.id=“_—9.8.1” name=“RANGE_CTGY”
• [0266] namespace=“_—9.8” supplierDependency=“_—19”>
  • [0267] <UML:ModelElement.taggedValue>
  • [0268] <UML:TaggedValue xmi.id=“_—9.8.1.1” tag=“TBLISBIN” value=“N”
• [0269] modelElement=“_—9.8.1”/>
  • [0270] <UML:TaggedValue xmi.id=“_—9.8.1.2” tag=“CREATYPE” value=“2”
• [0271] modelElement=“_—9.8.1”/>
  • [0272] <UML:TaggedValue xmi.id=“_—9.8.1.3” tag=“TBALLAS” value=“N”
• [0273] modelElement=“_—9.8.1”/>
  • [0274] <UML:TaggedValue xmi.id=“_—9.8.1.4” tag=“IWHDRATN” value=“Y”
• [0275] modelElement=“_—9.8.1”/>
  • [0276] <UML:TaggedValue xmi.id=“_—9.8.1.5” tag=“IWHMAXED” value=“0”
• [0277] modelElement=“_—9.8.1”/>
  • [0278] <UML:TaggedValue xmi.id=“_—9.8.1.6” tag=“IWHCREGN” value=“Y”
• [0279] modelElement=“_—9.8.1”/>
  • [0280] <UML:TaggedValue xmi.id=“_—9.8.1.7” tag=“IWHCRERU” value=“CREATE TABLE WCAMNG.RANGE_CTGY(RANGE_ID INTEGER NOT NULL, MIN_RANGE INTEGER, MAX_RANGE INTEGER, RANGE_DESC VARCHAR(32))” modelElement=“_—9.8.1”/>
  • [0281] <UML:TaggedValue xmi.id=“_—9.8.1.8” tag=“IWHCRTAR” value=“N”
• [0282] modelElement=“_—9.8.1”/>
  • [0283] <UML:TaggedValue xmi.id=“_—9.8.1.9” tag=“IWHGRANT” value=“Y”
• [0284] modelElement=“_—9.8.1”/>
  • [0285] <UML:TaggedValue xmi.id=“_—9.8.1.10” tag=“IDSDIM” value=“Y”
• [0286] modelElement=“_—9.8.1”/>
  • [0287] <UML:TaggedValue xmi.id=“_—9.8.1.11” tag=“IDSFACT” value=“N”
• [0288] modelElement=“_—9.8.1”/>
  • [0289] <UML:TaggedValue xmi.id=“_—9.8.1.12” tag=“IDSREPL” value=“N”
• [0290] modelElement=“_—9.8.1”/>
  • [0291] <UML:TaggedValue xmi.id=“_—9.8.1.13” tag=“PARTBSP” value=“N”
• [0292] modelElement=“_—9.8.1”/>
  • [0293] </UML:ModelElement.taggedValue>
  • [0294] <UML:Classifier.feature>
  • [0295] <CWMRDB:Column xmi.id=“_—9.8.1.14” name=“RANGE_ID” length=“0”
• [0296] scale=“0” precision=“0” isNullable=“columnNoNulls” owmer=“_—9.8.1” type=“_—17”>
  • [0297] <UML:ModelElement.taggedValue>
  • [0298] <UML:TaggedValue xmi.id=“_—9.8.1.14.1” tag=“ISTEXT” value=“N”
• [0299] modelElement=“_—9.8.1.14”/>
  • [0300] <UML:TaggedValue xmi.id=“_—9.8.1.14.2” tag=“ORDINAL” value=“1”
• [0301] modelElement=“_—9.8.1.14”/>
  • [0302] <UML:TaggedValue xmi.id=“_—9.8.1.14.3” tag=“EDTNCOL” value=“N”
• [0303] modelElement=“_—9.8.1.14”/>
  • [0304] </UML:ModelElement.taggedValue>
  • [0305] </CWMRDB:Column>
  • [0306] <CWMRDB:Column xmi.id=“_—9.8.1.15” name=“MIN_RANGE”
• [0307] length=“0” scale=“0” precision=“0” isNullable=“columnNullable”owner=“_—9.8.1”
• [0308] type=“_—17”>
  • [0309] <UML:ModelElement.taggedValue>
  • [0310] <UML:TaggedValue xmi.id=“_—9.8.1.15.1” tag=“ISTEXT” value=“N”
• [0311] modelElement=“_—9.8.1.15”/>
  • [0312] <UML:TaggedValue xmi.id=“_—9.8.1.15.2” tag=“ORDINAL” value=“2”
• [0313] modelElement=“_—9.8.1.15”/>
  • [0314] <UML:TaggedValue xmi.id=“_—9.8.1.15.3” tag=“EDTNCOL” value=“N”
• [0315] modelElement=“_—9.8.1.15”/>
  • [0316] </UML:ModelElement.taggedValue>
  • [0317] </CWMRDB:Column>
  • [0318] <CWMRDB:Column xmi.id=“_—9.8.1.16” name=“MAX_RANGE”
• [0319] length=“0” scale=“0” precision=“0” isNullable=“columnNullable” owner=“_—9.8.1”
• [0320] type=“_—17”>
  • [0321] <UML:ModelElement.taggedValue>
  • [0322] <UML:TaggedValue xmi.id=“_—9.8.1.16.1” tag=“ISTEXT” value=“N”
• [0323] modelElement=“_—9.8.1.16”/>
  • [0324] <UML:TaggedValue xmi.id=“_—9.8.1.16.2” tag=“ORDINAL” value=“3”
• [0325] modelElement=“_—9.8.1.16”/>
  • [0326] <UML:TaggedValue xmi.id=“_—9.8.1.16.3” tag=“EDTNCOL” value=“N”
• [0327] modelElement=“_—9.8.1.16”/>
  • [0328] </UML:ModelElement.taggedValue>
  • [0329] </CWMRDB:Column>
  • [0330] <CWMRDB:Column xmi.id=“_—9.8.1.17” name=“RANGE_DESC”
• [0331] length=“32” scale=“0” precision=“32” isNullable=“columnNullable” owner=“_—9.8.1”
• [0332] type=“_—18”>
  • [0333] <UML:ModelElement.taggedValue>