main page

MiningMart Approach Part I


Mining Mart Approach


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”.