Database Reference
In-Depth Information
maintained. In this section we discuss, motiva-
tion of maintaining metadata, identify metadata
to be stored and a meta-model for storage of
metadata.
The data dictionaries available with database
management systems cannot store metadata about
multiversion data warehouse due to its complex
nature. Metadata is complex because it includes
metadata about dimensional schemas, data in-
stances, evolution operations, data sharing scheme
as well as metadata about versioning relationships.
The reasons to that are as follows:
i.e. dimension tables, fact tables, relationship
between them, possible operations on the data
warehouse and so on; b) Versioning metadata,
the metadata about data warehouse versions e.g.
evolution operations applied on data warehouse
schema, new fact tables produced, new dimension
tables produced; c) Dynamic metadata, the data
that could change all the time and is not related
to versioning (e.g. information about integrated
schema). Details about integrated schema are
given in section 6.2.
Before presenting the metaschema for storing
data multiversion data warehouse, let us enlist the
metadata produced in multiversion data warehouse
lifecycle (Wrembel, 2005): i) Schema description
includes metadata about fact tables, dimensions,
dimension levels, attributes and relationships; ii)
Integrity constraints include information about
the constraints applied on the data warehouse for
maintaining data consistency; iii) Basic version-
ing metadata includes information about version
identifier, version status, version label; iv) Schema
and data sharing metadata includes information
about tables that are shared between schemas
and contents that are shared between versions; v)
Versioning relationship; vi) Schema integration
information; vii) Content of every DW instance
version; viii) Sharing fact and dimension data
between DW versions.
Figure 9 shows a simplified metaschema for
storing metadata given above. In the metaschema,
information about version at the basic level is
stored. Operations that are possible on a data
warehouse schema are stored in a separate table.
Metadata about the operations applied on data
warehouse versions is maintained separately in a
metaschema table. The dimension and fact tables
that are attached with versions are maintained
separately. The tables in version can be dimension
or fact tables, therefore we have created separate
tables for both types of tables. Fact_table has all
metadata about fact tables and BasicFAttribute
has metadata about its attributes, whereas versions
are maintained separately. Similarly, information
•
Basic
versioning metadata includes version
identification, version validity time and
version creation time etc. In the absence
of versioning metadata, versions cannot be
identified and no operation on versions is
possible;
Versioning relationship
•
metadata includes
label of parent version, child version,
shared dimensions and facts etc. In the
absence of version relationship metadata,
shared dimensions cannot be identified and
history of versions cannot be used.
Metadata about data sharing includes the
•
information about binding of dimensional
schemas and data instances. In the absence
of data sharing metadata, separate instanc-
es are required for each version of the data
warehouse, which increases redundancy.
Metadata about
•
evolution operations is the
information about operations that results
in creation of new versions of the data
warehouse. In the absence of evolution
operations metadata, history of changes in
business cannot be tracked and evolution
operations cannot be maintained.
We have classified data into three groups. a)
Static metadata, the metadata that remains static
throughout the life cycle of the data warehouse.
It is the basic information about data warehouse,
e.g. the information about root version is fixed
Search WWH ::
Custom Search