Physical Schema Design Discussion

I am redesigning how logical objects (cubes, levels, measures) map onto physical objects (tables arranged into a star schema), and introducing a PhysicalSchema element to allow the star schema to be defined once per schema.

This feature may or may not be delivered in mondrian-3.1.

Example

TODO

Internal changes

As well as a change to the XML schema format, this change also involves a refactoring of mondrian's internals. In particular, a new set of classes PhysTable, PhysColumn, PhysExpr etc. represent expressions internally, where currently XML classes MondrianDef.Table and MondrianDef.Column are used.

Backwards compatible

The changes to the XML schema format will be backwards compatible. If a schema does not have a PhysicalSchema element at the start, mondrian will create one internally, and transform each cube and virtual cube to map onto it.

• To use new features, you will need to write a new-style schema with a PhysicalSchema element

A few constructs will not be automatically compatible. If you use columns in free-text expressions, you will have to convert them to XML. For example,

<SQL>first_name || last_name</SQL>

becomes

<SQL><Column table="customer" name="first_name"/> || <Column table="customer" name="last_name"/></SQL>

Schema error-handling

This change also improves error-handling for schema errors. There are now three classes of schema errors: warning, error, fatal. Schema validation can continue through warnings and errors, so a tool such as the Workbench could present a list of several errors, similar to how a Java IDE presents many Java errors. Also like a Java IDE, each error is tagged with the location of the XML element which is in error.