MONDRIAN is an open source ROLAP server that develops Java. It implements XMLA and JOLAP specifications and customize a client interface using MDX languages. MONDRIAN is an OLAP server, not a data warehouse server, so Mondrian's metadata mainly includes metadata of the OLAP modeling, which does not include metadata from external data to the database conversion. That is to say, MONDRIA's metadata includes only multidimensional logic models, from the information of mapping, access rights such as relational databases to multi-dimensional logic models. In terms of function, Mondrian supports shared dimension and members to support star models and snowflake models.
???? Mondrian uses physical XML file storage metadata, which specifies the format of the XML file. The following brief introduces how it stores metadata.
ELEMENT ???? Description
Root element
???? Collection of Cubes, Virtual Cubes, Shared Dimensions, And Roles.
Logical element
???? a Collection of Dimensions and measures, all centered on a factory.
???? a cube defined by combining the dimensions and measures of one or more cubes.
????
???? USAGE OF A Shared Dimension by a Cube.
????
????
????
????
Physical element
???? Defines a 'table' Using A SQL Query, Which CAN Have Different Variants for Different underlying Databases.
???? DEFINES A 'TABLE' by Joining a Set of Queries.
Access control
???? AN Access-Control Profile.
???? a set of rights to a schema.
???? a set of rights to a cube.
???? a set of rights to a hierarchy and levels forin That hierarchy.
???? a set of rights to a member and its children.
other
????
???? Fact- or Dimension Table.
????
??
????
???? A mode defines a multi-dimensional database that includes a logical model, consisting of a cube, hierarchy, member, and logic model to a physical model. A logical model is queried by MDX language. Mondrain model is described by an XML file. The only way to create a mode now is to edit the XML file with the text editing A device. XML's syntax is not too complicated, so there is no difficulty imagination. A programming program is currently being developed to create and modify the mode. ???? The most important part of a model is cube, metrics, and dimension: cubes in a subject domain are the collection of peacekeeping metrics. A metric is a measurable value, such as the number of products sales or a detailed list of a dimension is a property or a collection of properties, through dimension you can divide metrics into the word class. For example: You want to divide the sales product into eight parts by color, customer gender, and sold in the store, such as color, gender, and stores are dimension. ???? The following is an example of a simple model definition:
??????
????????
????
??????
????
????
??????
????????
????????
???????????? uniquemembers = "true" /> ????????
???????????? uniquemembers = "false" />
????????
???????????? uniquemembers = "false" />
??????
????
????
???????? aggregator = "SUM" formatstring = "#, ###" />
????
???????? aggregator = "SUM" formatstring = "#, ###. ##" />
????
This model contains a sales Cube, which has two dimension, time and gender dimension; two metrics, sales quantity and total sales.
We can write a MDX query on this model:
Select {[MeasureS]. [Unit Sales], [MEASURES]. [store sales]} on columns,
?? {[Time]. [1997]. [Q1] .descendants} on rows
From [Sales]
Where [associa]. [f]
This query involves selling cubes, each dimension [MeasureS], [Time], [Gnder], these dimensional members. The result is as follows:
[Time] ???? [MeasureS]. [Unit sales] ???? [measures]. [Store sales]
[1997] ????? 0 ???? 0
[1997]. [Jan] ???? 0 ???? 0
[1997]. [Feb] ???? 0 ???? 0
[1997]. [Mar] ???? 0 ???? 0
Let's introduce the pattern definition in detail below:
A cube is a collection of multiple dimension and metrics, usually a fact table, here is' sales_fact_1997. "The fact table holds the column that needs to be calculated and contains the reference table.
??
????????
?? ... here
Elements define the fact table. If the fact table is not in the default mode, you can specify a clear mode with the "Schema" property, for example:
with
Structure to create more complex SQL.
measure
Sales cubes define two dimensional "Unit Sales" and "Store Sales".
???? aggregator = "SUM" formatstring = "#, ###" />
???? aggregator = "SUM" formatstring = "#, ###. 00" />
Each metric has a name, a column in the fact table, using a gathering function (Usually "SUM").
An optional format string specifies how the value is printed. Here we choose the sales quantity without the decimal output (because the sales quantity is integer), the total sales are 2 decimal. Symbol ',' and '.' Is the region Sensitive, so if it is running in Italy, the total sales may appear "48.123,45". You can use Advanced Format Strings to achieve a stricter effect. The metric is not from the column, but from the unit of cubes. Come
dimension
Gender dimension consists of a single level, only one layer.
??
????
You can also use
??
For any given sales, gender dimension refers to the gender of customers who purchase changes to the product. It is through the connection fact table "Sales_FACT_1997.CUSTOMER_ID" and the statter "Customer.customer_ID"
To represent . "Gender" includes two values, 'f' and 'm', so the gender dimension contains members: [Gnder]. [f] and [gender]. [M]. Because Hasall = "True", the system generates a special The 'all' layer includes only one member [all genders]. One dimension can contain multiple levels:
??
????
????
???????? uniquemembers = "true" />
????
???????? uniquemembers = "false" />
????
???????? uniquemembers = "false" />
??
??
????
????
???????? uniquemembers = "true" />
????
???????? uniquemembers = "false" />
????
???????? uniquemembers = "false" />
??
The first level did not specify a name. By default, a hierarchy has the same name as its dimension. Therefore, the first level becomes "time". These levels do not have much common, and they don't even have the same table unless they are connected to the same column "Time_ID" in the implementation table. This is useful for two hierarchies in a dimension to do this. If there is two levels in a dimension, MDX will not allow them to be used in a query.
A Dimension Can Live In The Fact Table:
??
????
????
??????
????
??
.such as:
?? ...
??
????
??????
????????
?? ... ?? Each dimension contains a hierarchy of multiple layers, most dimensions have only one level, but sometimes there is multiple levels. For example: you may want to gather from the sky to the month, quarterly and year from day and aggregate; or gathered from the sky to week. These two levels are from the days to the year, but the paths of aggregates are different. Most levels have full members, all members include all members of the hierarchy, so they can represent their total. It is usually named 'all something', such as: 'all stores'. Star model and snowflake pattern Mondrian support star model and snowflake pattern. Let's introduce the modeling of the snowflake mode, it needs to use the operator
??????????
????????
??????????
Element cycle nested,
With two operation objects; operational objects may be tables, connections or queries.
According to the number of operation object lines, the number of rows of "Product" is the largest, so it first appears the connection fact table; then "Product_Class" and "Product_Type", the number of rows of rows in the end of the snow.
Pay attention to external elements
There is an attribute Rightalias. This is necessary because Join's right side (is internal element)
) It is possible to make a number of tables. In this case, you don't need attribute Leftalias because column LeftKey is clear from table "product".
Shared dimension
When generating SQL is generated for a connection, Mondrian needs to know which column is connected. If one is connected to a multi-table connection, you need to tell it which table in these tables, which one column.
Because shared dimensions don't belong to a Cube, you must give them a clear table (or data source). When you use them in a special Cube, you want to specify foreign key foreign key. The following example shows Store Type The dimension is connected to Sales Cube, with foreign key Sales_FACT_1997.Store_ID, and is connected to Warehouse Cube, with foreign key warehouse.warehouse_store_id: ??
????
????????????????????? ... ?????? Here, a "product" is configured by three tables. The fact table connection table "product" By foreign key "product_id", table "product" connection table "product_class", table "product_class" connection table "product_Type" ("Product_Type_ID"), "by foreign key" product_type_id "). We use
??
??
????
??
??
?? ...??
Virtual Cubes
Father and child level
A convenient hierarchy has a collection of strict layers, a close contact with a layer. For example, in the Product hierarchy, the member of any product name layer has a father on the trademark layer, the member on the trademark layer in the product The catalog layer also has a father. This structure is sometimes too strict for data in the real world.
A father and child hierarchy have only one layer (no 'all' layer), but any member can have a father member on the same layer. A typical example is an Employees level:
??
????
?? ...??
???????? column = "employee_id" NameColumn = "full_name"
???????? parentcolumn = "supervisor_id" nullparentValue = "0">
??????
??????
??????
??????
??????
??????
????
Child element
It is the same role as attribute ParentColumn, but the element allows the definition of any SQL expression, like elements.
ParentColumn (or elements
) It is the dimriend that said Mondrian pointed out that there is a parent-child structure.
Attribute nullparentValue is the value indicating that the member does not have a parent member. By default, nullparentValue = "null", but because many databases do not support NULL, other values are used instead of null values, 0 and -1.
Physical structure
MEMBER READE
Member Reader is a way to access members. The hierarchical usually established in a dimensional table, so you have to construct with SQL. But even your data is not existing in RDBMS, you can access the hierarchy by a Java class. (Customized MEMBER READER)
Here Are A Couple of Examples:
Datesource (To Be Written) Generates a time level. Press regularly, the data warehouse tool generates a table and contains a row every day. But the problem is that this table needs to be loaded, and more rows can be added over time. Datesource generates a date member in memory.
FileSystemSource (To BE Written) File System according to the list of directories and files. Like the time hierarchy created by DateSource, this is a virtual hierarchy: the member for a particular file is only created when, and if, that file's parent directory expanded.ExpressionMemberReader (to be written) creates a hierarchical expression-based is.
Custom Member Reader must implement interface Mondrian.Rolap.Membersource. If you need to implement a larger member operation collection, you need to implement interface interface mondrian.rolap.memberreader; otherwise, Mondrian is encapsulated in Mondrian.Rolap.cachememberReader to encapsulate your Reader class Your Member Reader must have a public constructor that has a parameter (hierarchy, proties), throws unchecked errors.
MEMBER Readers with elements
Attributes MEMBERREADERCLASS to declare; any
The child element passes through the attribute constructor.
This is an example:
??
????
????
??
Cell Readers
Class "COM.FOO.MYCELLREADER" implements interface interface mondrian.olap.cellreader.
Access control
Attributes (roles) of access control can be defined, as part of the mode, and can set the role when the connection is established.
Define role
Role can pass the elements
To set, it is an element
Direct child elements.
Here is an example of a role:
??
????
??????
????????
????????
??????
??????
????????
????????
??????
??????
????
??
element
Define the default objects for the model. The access attribute can be "all" or "none"; this property can be inherited by the specific permissions. In this example, because access = "none", users can only browse "Sales" cube, which is clearly given this permission.
element
Define access to cubes. Just like
The attribute Access can be "all" or "none", and can be inherited by the specific sub-objects in CUBE.
element
Define levels of access. Properties access can be "all", meaning all Members is visible; "none", meaning hierarchy is hidden; "Custom", you can use the property TopLevel definition The visible highest layer (prevents the user from being able to perform the on-volume operation, such as browsing the tax to the Store Country layer); or use the attribute bottomlease to define the visible bottom (here the user will view the customer's personal details); or control the user to view Which member collection is set by nested elements
.
You can also define elements
If the pattern
There is attribute Access = "Custom". Member GRANTS gives (or cancel) access to a given member, and all of its subcommittees.
?????? Here ParentColumn and NullParentValue are important properties: Properties ParentColumn is a member of a member to connect to the column name of its father. In this case, it is the foreign key to the employee manager. element
