Database Reference
In-Depth Information
this, meetings with data producers are carried out where the set of data
sources, the quality of their data, and their availability must be documented.
At the end of the whole requirements specification process, ideally we will
have for each data element the best data source for obtaining it.
Apply Derivation Process
There are many techniques to derive multidimensional elements from opera-
tional databases. All these techniques require that the operational databases
are represented using either the entity-relationship or the relational model.
Facts and their associated measures are determined by analyzing the
existing documentation or the structure of the databases. Facts and measures
are associated with elements that are frequently updated. If the operational
databases are relational, they may correspond to tables and attributes,
respectively. If the operational databases are represented using the entity-
relationship model, facts could be entity or relationship types, while measures
may be attributes of these elements. An alternative option is to involve users
who understand the operational systems and can help to determine what data
can be considered as measures. Identifying facts and measures is the most
important aspect of this approach since these form the basis for constructing
multidimensional schemas.
Various procedures can be applied to derive dimensions and hierarchies.
These procedures may be automatic, semiautomatic, or manual. The former
two require knowledge about the specific conceptual models that are used
for the initial schema and its subsequent transformations. The process of
discovering a dimension or a leaf level of a hierarchy usually starts from
identifying the static (not frequently updated) elements that are related to
the facts. Then, a search for other hierarchy levels is conducted. For this
purpose, starting with a leaf level of a hierarchy, every relationship in which
it participates is revised. Unlike automatic or semiautomatic procedures,
manual procedures allow designers to find hierarchies embedded within the
same entity or table, for example, to find city and province attributes in a
customer or employee entity type. However, either the presence of system
experts who understand the data in the operational databases is required or
the designer must have good knowledge about the business domain and the
underlying systems.
Document Requirements Specification
Like in the analysis-driven approach, the requirements specification phase
should be documented. The documentation should describe those elements
of the source systems that can be considered as facts, measures, dimensions,
and hierarchies. This will be contained in the technical metadata .Further,
Search WWH ::




Custom Search