Subtypes/Supertypes

the data modeler's most important construct

You may have thought that entities, attributes, relationships, identifiers, and foreign keys were the only important modeling constructs for the data modeler. Well, they are important, particularly for relational database design (and most DBMS's today are relational). However, subtypes and supertypes (S/Stypes) are even more important, particularly at the highest levels of logical or conceptual modeling. Most data modeling CASE tools include provision for S/Stypes, so data modelers need to understand how to properly use these constructs.

We don't always hear or learn about S/Stypes. In fact, they are not even mentioned in many introductory database textbooks or courses. Graeme Simsion got it right when he made it chapter 4, right up front in his book, Data Modeling Essentials, 3e, Morgan Kaufmann, 2005. S/Stypes are truly essential for the data modeler. They allow the database designer to defer choosing what objects to materialize or what (relational) tables to build until later in the development process. In the meantime, S/Stypes offer a means to formally represent overlapping entity/object populations at the very beginning of the logical/conceptual design process.

This presentation covers:

* situations which motivate the need for another modeling construct

* definition of subtypes and supertypes - one of several abstraction mechanisms

* characteristics of a subtype-supertype "relationship"

* specialization vs. generalization

* attribute vs. entity abstraction (generalization) - some examples

* required conditions when using S/Stypes

* various notational conventions for diagraming S/Stype relationships

* the "universal relation" (vs. no entity types at all!)

* single vs. multiple inheritance, or the type hierarchy vs. a type lattice

* distinguishing attribute(s) on the supertype: intensional vs. extensional sets

* declaring constraints on a subtype-supertype relationship

* how to design relational tables to represent a S/Stype relationship - mappings to a relational model

* three kinds of inheritance; inheritance vs. reuse

* inheritance in data models vs. inheritance in object-oriented design (they are not the same)

* inheritance priority, blocking, and overriding - how these concepts apply (or not)

SHORTENED ABSTRACT

Entities, attributes, relationships, identifiers, and foreign keys are important data modeling constructs, particularly for relational databases, but subtypes and supertypes (S/Stypes) are even more important. Relational DBMSs do not handle S/Stypes. However, many data modeling CASE tools do include provision for S/Stypes, so data modelers need to understand how to properly use these constructs. S/Stypes are truly essential for the data modeler (Graeme Simsion covered it early in his book, Data Modeling Essentials). They allow the database designer to defer choosing what objects to materialize or what (relational) tables to build until later in the database development process. In the meantime, S/Stypes offer a means to formally represent overlapping entity/object populations at the very beginning of the design process. If you are not using S/Stypes in your data modeling, or want to deepen your understanding of these constructs, this session is for you. Knowledge and use of subtypes/supertypes should be in every data modeler's toolkit.

* situations which motivate the need for another data modeling construct

* definition of subtypes and supertypes - characteristics of a subtype-supertype "relationship"

* abstraction mechanisms: specialization vs. generalization; attribute vs. entity abstraction

* required conditions when using S/Stypes

* the "universal relation" (vs. no entity types at all!)

* single vs. multiple inheritance, or the type hierarchy vs. a type lattice

* distinguishing attribute(s) on the supertype: intensional vs. extensional sets

* declaring constraints on a subtype-supertype relationship

* how to design relational tables to represent a S/Stype relationship - mappings to a relational model

* inheritance in data models vs. inheritance and reuse in object-oriented design (they are not the same)

* inheritance priority, blocking, and overriding - how these concepts apply (or not)