We brie y present OMD, a model of multidimensional data that uses ontologies written in Datalog , an extension of the classical declarative language Datalog for relational databases. We present the Ontological Multidimensional Data Model (OMD) as an ontological, Datalog -based [3] extension of the Hurtado-Mendelzon (HM) model for multidimensional data [5]. elements of an OMD model.
Institution
Unit Ward 2 WorkSchedules Unit Day
Nurse Specialization Ward
W4 W1 W2
Shifts
Day Sep/5/2016 Sep/6/2016 Nurse Shift Cathy
Noon Helen Morning 1 W3 Nov/12/2016 W3 Aug/21/2016 Sep/6/2016 Alan Sara Helen
Evening Noon ?
Year Month Day Time
An OMD model has a database schema RM = H[Rc, where H is a relational schema with multiple dimensions, with sets K of unary category predicates, and sets L of binary, child-parent predicates; and Rc is a set of categorical predicates.
RHS. K contains predicates Ward ( ), Unit ( ), Institution( ), etc.
Ward = fW1; W2; W3; W4g. L contains, e.g.
WardUnit = f(W1; standard); (W2; standard); (W3; intensive); (W4; terminal)g. In the middle of to dimension categories.
AllHospital
allHospital Institution
H 1
H
2 Unit
standard intensive terminal Ward
W1
W2
W3
W4
Attributes of categorical predicates are either categorical, whose values are members of dimension categories, or non-categorical, taking values from arbitrary domains. Categorical predicate are represented in the form R(C1; : : : ; Cm; N1; : : : ; Nn), with categorical attributes before \;" and non-categorical after.
The extensional data, i.e the instance for the schema RM, is IM = DH [ Ic, where DH is a complete instance for dimensional subschema H containing the category and child-parent predicates; and sub-instance Ic contains possibly c partial, incomplete extensions for the categorical predicates, i.e. those in R .
Schema RM comes with basic, application-independent semantic constraints, listed below. 1. Dimensional child-parent predicates must take their values from categories. Accordingly, if child-parent predicate P 2 L is associated to category predicates K; K0 2 K, in this order, we introduce inclusion dependencies (IDs) as Datalog negative constraints (ncs): P (x; x0); :K(x) ! ?; and P (x; x0); :K0(x0) ! ?. (The ? symbol denotes an always false propositional atom.) We do not represent them as Datalog 's tuple-generating dependencies (tgds) P (x; x0) ! K(x), etc., because we reserve tgds for possibly incomplete predicates (in their RHSs). 2. Key constraints on dimensional child-parent predicates P 2 K, as equalitygenerating dependencies (egds): P (x; x1); P (x; x2) ! x1 = x2. 3. The connections between categorical attributes and the category predicates are speci ed by means of ncs. For categorical predicate R, the nc R(x; y); :K(x) ! ?, where x 2 x takes values in category K.
Example: The categorical attributes Unit and Day of categorical predicate
WorkingSchedules (Unit ;Day ;Nurse; Speciality ) in Rc are connected to the
Hospital and Temporal dimensions, resp., as captured by the IDs WorkingSchedules [
The OMD model allows us to build multidimensional ontologies, OM. In addition to an instance IM for a schema RM, they include the set M of basic constraints as in 1.-3. above, a set M of dimensional rules (those in 4. below), and a set M of dimensional constraints (in 5. below); all of them applicationdependent and expressed in the Datalog+ language associated to schema RM. 4. Dimensional rules as Datalog+ tgds: R1(x1; y1); :::; Rn(xn; yn); P1(x1; x01); :::; Pm(xm; x0m) ! 9y0 Rk(xk; y). Here, the Ri(xi; yi)) are categorical predicates, the Pi are child-parent predicates, y0 y, xk x1[:::[xn[fx1; :::; xm; x01; :::; x0mg, y r y0 y1 [ ::: [ yn; repeated variables in bodies (join variables) appear only categorical positions in categorical relations and in child-parent predicates. Existential variables appear only in non-categorical attributes. 5. Dimensional constraints, as egds or ncs: R1(x1; y1); :::; Rn(xn; yn); P1(x1; x01); :::; Pm(xm; x0m) ! z = z0, and R1(x1; y1); :::; Rn(xn; yn); P1(x1; x01); :::; Pm(xm; x0m) ! ?. Here, Ri 2 Rc, Pj 2 L, and z; z0 2 S xi [ S yj . Some of the lists in the bodies may be empty, i.e. n = 0 or m = 0, which allows to represent also classical constraints on categorical relations, e.g. keys or FDs. Example: The left-hand-side of Figure 1 shows dimensional constraint on categorical relation WorkingSchedules, which is linked to the Temporal dimension via the Day category. It says: \No personnel was working in the Intensive care unit in January", i.e. : WorkingSchedules (intensive; d; n; s); DayMonth(d; jan) ! ?.
Dimensional tgd 1 in Figure 1, given by Shifts(w; d; n; s); WardUnit (w; u) ! 9t WorkingSchedules (u; d; n; t), says that \If a nurse has shifts in a ward on a speci c day, he/she has a working schedule in the unit of that ward on the same day". The use of 1 generates, from the Shifts relation, new tuples for relation WorkingSchedules, with null values for the Specialization attribute, due to the existential variable. Existential rules like this (and also egds and ncs) make us depart from classic Datalog, taking us into Datalog . Relation Working Schedules may be incomplete, and new -possibly virtual- entries can be produced for it, e.g. the shaded ones showing Helen and Sara working for the Standard and Intensive units, resp. This is done by upward-navigation and data propagation through the dimension hierarchy. Constraint is expected to be satis ed both by the initial extensional tuples for WorkingSchedules and its tuples generated through 1, i.e. by its non-shaded tuples and shaded tuples in Figure 1, resp. In this example, is satis ed.
Notice that WorkingSchedules refers to the Day attribute of the Temporal dimensions, whereas involves the Month attribute. Then, checking requires upward-navigation through the Temporal dimension. Also the Hospital dimension is involved in the satisfaction of : The tgd 1 may generate new tuples for WorkingSchedules, by upward-navigation from Ward to Unit.
Furthermore, we have an additional tgd 2 that can be used with WorkingSchedules to generate data for categorical relation Shifts (the shaded tuple in it is one of them): 2 : WorkingSchedules (u; d; n; t); WardUnit (w; u) ! 9s Shifts(w; d; n; s). It re ects the institutional guideline stating that \If a nurse works in a unit on a speci c day, he/she has shifts in every ward of that unit on the same day". Accordingly, 2 relies on downward-navigation for tuple generation, from the Unit category level down to the Ward category level.
If we have a categorical relation Therm(Ward ; Thertype; Nurse), with Ward and Thertype categorical attributes (the latter for an Instrument dimension), the following is an egd saying that \All thermometers in a unit are of the same type": Therm(w ; t ; n); Therm(w 0; t 0; n0);WardUnit (w ; u);WardUnit (w 0; u) ! t = t0.
Notice that our ontological language allows us to impose a condition at the Unit level without having it as an attribute in the categorical relation. The existential variables in dimensional rules, such as t and s as in 1 and 2, resp., make up for the missing, non-categorical attributes Speciality and Shift in WorkingSchedules and Shifts, resp.
Dimensional tgds can be used for upward- or downward-navigation (or data generation) depending on the joins in the body. A one-step direction is determined by the di erence of levels of the dimension categories appearing (as attributes) in the joins. Multi-step navigation, between a category and an ancestor or descendant category, can be captured through a chain of joins with adjacent child-parent dimensional predicates in the body of a tgd, e.g. propagating doctors at the unit level all the way up to the hospital level: WardDoc(ward ; na; sp); WardUnit (ward ; unit ); UnitInst (unit ; ins) ! HospDoc(ins; na; sp). Example: Rule 2 supports downward tuple-generation. When enforcing it on a tuple WorkingSchedules (u; d; n; t), via category member u (for Unit), a tuple for Shifts is generated for each child w of u in the Ward category for which the body of 2 is true. For example, chasing 2 with the third tuple in WorkingSchedules generates two new tuples in Shifts: Shifts (W2; sep=6=2016; helen; ) and Shifts (W1; sep=6=2016; helen; 0), with fresh nulls, and 0. The latter tuple is not shown in Figure 1 (it is dominated by the third tuple, Shifts (W1; sep=6=2016; helen; morning), in Shifts). With the old and new tuples we obtain the answers to the query about Helen's wards on Sep/6/2016: Q0(w) : 9s Shifts (w; sep=6=2016; helen; s). They are W1 and W2.
In contrast, the join between Shifts and WardUnit in 1 enables upwardnavigation; and the generation of only one tuple for WorkingSchedules from each tuple in Shifts, because each Ward member has at most one Unit parent.
We can see that the OMD data model is an ontological model that goes far
beyond classical multidimensional data models. For example, the HM model [
Furthermore, the constraints considered in the HM model are speci c for
the dimensional structure of data, most prominently, to guarantee
summarizability (i.e. correct aggregation, avoiding double-counting). Speci cally, we nd
constraints enforcing strictness and homogeneity [
The OMD model enables ontology-based data access (OBDA) [
The ontologies of the OMD model have good computational properties [
Acknowledgements: Research supported by NSERC Discovery Grant #06148.