Use of the Meta Model
 |
- The meta model is stored in a database.
- The database manager delivers the relational model.
- The data analyst delivers the conceptual model.
- The KDD expert delivers or adjusts a case model. First cases
are delivered by the Mining Mart project.
- The system compiles meta data into SQL statements and calls
to external tools to execute the case model on the data.
|
The Meta-Model of Meta-Data M4
The form in which meta-data are to be written is specified in the MiningMart
Meta Model, M4. It is structured along two dimensions, topic and abstraction.
The topic is either the business data or the case. The business data are
the ones to be analysed. The case is a sequence of (preprocessing) steps.
The abstraction is either conceptual or relational. Where the conceptual
level is expected to be the same for various applications, the relational
level actually refers to the particular database at hand. The meta-data
written in the form as specified by M4 are stored in a relational database
themselves.
 |
- The Relational Model describes the database
- The Execution Model generates SQL statements
or calls to external tools
- The Conceptual Model describes the individuals
and classes of the domain with their relations
- The Case Model describes chains of preprocessing operators
|
Editing the Conceptual Data Model
As depicted in figure 1, there are different kinds of experts working
at different ends of a knowledge discovery process. First of all a domain
expert will define a conceptual data model, using a concept editor. The
entities involved in data mining are made explicit by this expert. The
conceptual model of M4 is about concepts having features and relationships
between these concepts. Concepts and Relationships may be organized hierarchically
by means of inheritance. Examples for concepts are “Customer”
and “Product”, a relationship between these two could be “Buys”.
The conceptual data model is also used when displaying MiningMart cases in the
Case-Base.
Editing the Relational Model
Given a conceptual data model, a database administrator maps the involved
entities to the corresponding database objects. The relational data model
of M4 is capable of representing all the relevant properties of a relational
database. The most simple mapping from the conceptual to the relational
level is given, if concepts directly correspond to database tables or
views. This can always be achieved manually by inspecting the database
and creating a view for each concept. However, more sophisticated ways
of graphically selecting attributes (or “features”) and aggregating
them to concepts, increase the acceptance by end users. In the project,
the relational editor is intended to support this kind of activity. In
general it should be possible to map all reasonable representations of
entities to reasonable conceptual definitions. A simple mapping of the
concept “Customer”, containing the features “Customer ID”,
“Name”, “Address” to the database would be to state
that the table “CUSTOMER” holds all the necessary attributes,
e.g. “CUSTOM ID”, “CUST NAME” and “CUST ADDR”.
An example for more complex mappings occurs if the information about name
and address needs to be joined first, e.g. using the shared key attribute
“CUSTOM ID”.
