1 Reference Scheme Reduction on Subtypes in ORM Andy Carver and Terry Halpin INTI International University, Malaysia

2 Contents Introduction Subtype Referential Irrelevance Due to Redundancy Subtype Referential Irrelevance Due to Derivability Referential Irrelevance Due to Inapplicability Conclusion

3 Introduction In an object-reference within an ORM conceptual database, the inclusion of referential components that are actually irrelevant to unique identification of the object, may result in Rmap-generation of a relational database schema that allows data redundancy in some object references. In some cases, this could even allow fact redundancy, and hence lead to a table scheme that is not fully normalized.

4 Reference-scheme reduction transformations aim to remove from the composite reference scheme of a given entity type, a component whose values are irrelevant for the unique identification of entities of that type. The cases in which such a transformation theorem (and not merely an adjustment of the reference scheme) is pertinent to removal of such components, are those in which an entity type “inherits” in some way, the (valid and proper) composite reference scheme of some other entity type, but because of some rule in the context, requires for its own object-references not all of the components in that inherited reference scheme.

5 There are three ways in which an entity type can “inherit” (broadly speaking) a composite reference scheme: 1.by including some compidot (compositely identified object type), or nested binary/n-ary, as a component within its own reference scheme 2.by nesting a binary/n-ary fact type (which fact type’s included roles determine the components that are in the nesting entity type’s virtual, composite reference scheme) 3.by being a subtype -- explicit or implied -- that inherits the composite reference scheme of (one of) its supertypes A previous paper touched on referential irrelevance arising in either of the first two ways. The current paper discusses referential irrelevance in cases involving: (a) subtyping, and/or (b) exclusion constraints and disjunctive reference.

6 Mapping a subtype graph from an ORM schema to a relational schema may involve absorption, separation, or partition. A subtype’s non-functional roles (those without a simple uniqueness constraint) always map to a table separate from the supertype’s table. A subtype’s functional roles may be absorbed into the supertable, or placed into a separate table, depending on the designer’s choice.

7 There are three kinds of referential-component “irrelevance”, resulting from three different kinds of contextual rule (either explicit or implied): 1.irrelevance due to simple “redundancy” of the component’s values (resulting from a contextual Uniqueness constraint) 2.irrelevance due to the derivability of the component’s values (resulting from a contextual Derivation rule) 3.irrelevance due to the inapplicability of the component’s values (resulting from a contextual Exclusion constraint)

8 Subtype Referential Irrelevance Due to Redundancy Here’s an example of simple “redundancy” calling for reference-scheme reduction: This Rmaps as follows:

9 The “AdditionalColor” table scheme is N2NF (Non-Second Normal Form). In general, a table scheme that is Non-Third Normal Form can also result, if a fact type (or another entity type) has at least one non-key role hosted by an entity type that has a redundant component in its reference scheme. This Rmaps as follows:

10 The nested supertype here objectifies a binary, not an n -ary; in such cases, a role-redirection transform can resolve the problem: This Rmaps to a 5NF scheme, as follows:

11 Here is an abstract pattern for this simple kind of transformation:

12 A more complicated role redirection transform, to remove referential redundancy involving an n -ary fact, is shown abstractly for the case n = 3: (For convenience, we have added some non-standard ORM graphics on top of the subtype shapes: the ternary fact-type shapes added there depict the restricted uniqueness constraint (spanning only two roles) graphically.)

13 Subtype Referential Irrelevance Due to Derivability Rmap using subtype absorption

14 Embedded FD from a non-key attribute, so the table scheme is not in 3NF. Similar denormalization problems occur if Rmap uses subtype separation.

15 The simplest way to avoid the problem is to introduce a simple identifier for Oscar.

16 Another solution is to use a simple, derived, context-dependent reference scheme for the subtype. This requires Rmap to choose subtype separation.

17 The Rmap result can be further optimized by preprocessing with a role elimination reduction transform.

18

19 Referential Irrelevance Due to Inapplicability A far more complex solution for the previous case might be to use disjunctive reference for Oscar, and a special kind of context-dependent reference for BestPictureOscar that implicitly identifies simply by the Oscar ceremony. Without context-dependent reference, the Movie table would contain both an embedded FD and a column full of nulls (award category is inapplicable).

20 Such all-null columns due to inapplicability can also arise if a fact type that maps to a separate table shares an exclusion constraint (explicit or implied) with an optional component of a disjunctive reference scheme. E.g. in these cases R maps to a denormalized table scheme The simplest solution is to introduce a simple identifier for A.

21 Conclusion This presentation identified further cases where reference scheme reduction transforms are required to avoid denormalized table schemes that would otherwise result from relational mapping. To avoid such denormalization without transforming the conceptual schema, we extend Step 4 of the Rmap procedure thus: For each role that is hosted by an explicit subtype or an implicit subtype 1 and maps to a table other than that for any functional, non- referential roles of the supertype, unpack that role into just its relevant referential components 2. 1 An “implicit subtype” has an explicit or implicit exclusion constraint with an optional component of a disjunctive reference scheme (e.g. see previous slide). 2 i.e. its applicable, non-derivable and non-redundant components.

22 Future plans include extending the NORMA tool to detect such patterns in the conceptual schema and offer to transform the conceptual schema itself to a form that will Rmap properly without the Step 4 extension (e.g. perform a reduction transform or introduce a simple identifier); if the user wishes to retain the original conceptual schema, the Rmap Step 4 extension will be invoked. We also plan to investigate further cases of disjunctive reference in which supertypes that are partitioned into subtypes with different reference schemes are allowed to abstract references schemes from their subtypes.