2. An introduction to the XOE

From Tables to Objects

The most basic object model is a model with only the root object. This model basically corresponds to a flat table, or, with attributes attached, to a star schema (if we stick to Business Intelligence terms). For such a simple model, the term “ObjectAnalytics” wouldn’t be justified. The only thing we need to do is define where the data for the root object come from. I.e. we need to define which table in the source database corresponds to the root object, and which fields of the table are mapped to which member fields (dimensions) of the root object.

It is getting more interesting only as soon as the root object has sub-objects (or arrays of sub-objects). You likely worked with objects in other domains. An object has member fields, some of them may be objects themselves, arrays or arrays of objects. Only with that the term “Object” is becoming justified, as data like this no longer map to a flat table.

The figure below shows an example.

Here the root object is the “Patient”, which has member fields such as “Age”, “Gender” and “City”. Each individual patient may have had a number of hospital cases (“Hospitalizations”), i.e. the entity “Patient” is in an 1 to N relationship to “Hospitalizations”. Each hospital case in itself may be a complex data object, i.e. each case in turn has member fields (“Date” and “Length Of Stay” of the hospital case) and further sub-objects (“Hosp.-Prescriptions” and “Hosp.-Diagnoses” in the example in the figure).

The root object corresponds to a table in the database whereby this table needs to have a key which is the ID for the entity represented by the root object (i.e. the patient ID). Further fields of that table map to the member fields or dimensions of the root object. Likewise, further objects in the object hierarchy map to corresponding tables in the database. The Hospitalizations sub-object of the root-object, for example, corresponds to a table, where each line represents one hospital case - i.e. this table needs to have a key field representing individual hospital cases. Furthermore, this table requires a foreign key which corresponds to the root entity. I.e. the table for the hospital cases requires the patient ID as a foreign key.