Semantic Data Modeling Concepts

1. Semantic Data Modeling Concepts • Background: • Semantic modeling research started in ‘70s(mainly late ‘70s) • Originally as schema design aids/tools for traditional record-based models (eg, ER) • Emphasis: to accurately model data relationships => more complex inherently, and encourage a more navigational view • Results: Semantically more expressive and powerful modeling concepts <embodied by a set of semantic data models>

2. Semantic Data Modeling Concepts • Background (cont’d): • Later trends: 1) to build full-fledged DBMSs based on semantic models directly 2) merge into the “object” database family • Continue to evolve: up till late ‘80s / early ‘90s • Central Components of Semantic Modeling: • Objects / Entities • Attributes / Properties • Abstraction relationships (semantic primitives)

3. Semantic Data Modeling Concepts • On Semantic Primitives (“data abstractions”): • Classification and Instantiation • the former involves classifying similar objects into classes • the latter refers to the generation and specific examination of distinct objects of a class • inverse of each other • Related issues • class vs. type • class properties vs. type properties • classes as instances of meta-classes

4. Semantic Data Modeling Concepts • On Semantic Primitives (cont’d) • Identification • refers to the abstraction process whereby all abstract concepts and concrete objects are made uniquely identifiable by means of identifiers • needed at two levels 1) to distinghish among DB objects & classes 2) to identify DB objects and relate them to real-world counterparts “identifiers”vs.“keys”

5. Semantic Data Modeling Concepts • On Semantic Primitives (cont’d) • Specification and Generalization (“is-a”) • the former is the process of further classifying a class of objects into more specialized subclasses (“conceptual refinement”) • the latter is the inverse of the former, where several classes are generalized into a higher-level abstract class (“conceptual synthesis”) • Related concepts • attribute inheritance () • instance subsumption ()

6. Semantic Data Modeling Concepts • On Semantic Primitives (cont’d) • Aggregation (“is-part-of”) • an abstraction concept for building composite/ complex objects from their component objects •  three cases: • we aggregate attribute values of an object to form the whole object • represent an aggregation relationship as an ordinary relationship • combine related objects into a higher-level aggregate object (with attributes whose value ranges are non-atomic objects)

7. Semantic Data Modeling Concepts • On Semantic Primitives (cont’d) • Association (“is-associated-with”) • an abstraction concept for associating objects from several independent classes • similar to the 3rd case of aggregation, with a distinction: • when an association instance is deleted, the participating objects continue to exisit (not the case for aggregation!)

8. Semantic Data Modeling Concepts • Related Work in AI • Knowledge Representation (KR) • Semantic networks • frame-based ones • Similarities & Differences • both use an abstraction process to identify common properties & important aspects of objects, while attempting to surpress insignificant detailed differences • both provide concepts, constraints, operations, and languages for the object definition & representation • scope of KR is broader (can answer queries involving inference and deduction over objects) • KR tools are in-memory ones, could not scale up.

9. The Extended ER Model • Introduction • Numerous extensions to the ER model (since ‘79) • collectively referred as EER model • Aiming at incorporating existing semantic concepts and primitives into the original ER model • EER Model Concepts & Primitives • sub-/super-class (specialization/generalization) • attribute inheritance • superclass/subclass as an explicitly defined and supported relationships

10. The Extended ER Model • EER Diagram Notation Class 1 Class 2 • Constraints on specialization/generalization: • predicate-defined constraint <attribute-defined: a special case> • user-defined constraint • disjointness constraint: <disjoint vs. overlapping> • completeness constraint: <total vs. partial> 

11. The Extended ER Model

12. The Extended ER Model

13. The Extended ER Model • Sub-/super-class (cont’d) • the disjointness and completeness constraints are independent, hence we can have: a) disjoint, total b) disjoint, partial c) overlapping, total d) overlapping, partial • a generalization superclass usually is total, hence only a) and c) apply to generalization • specialization can have all above 4 kinds!

14. The Extended ER Model • Sub-/super-class (cont’d) • insertion and deletion rules: • deleting an entity from a superclass => deleting it from all the subclasses • inserting an entity in a superclass => inserting it to all predicate-defined subclasses if the entity satisfies the predicate • inserting an entity in a superclass of a total specialization => it is inserted in at least one of the subclasses of the specialization • specialization lattice & shared subclasses • a shared subclass: the result of intersection!

15. The Extended ER Model

16. The Extended ER Model • Categories and Categorization • for modeling a single superclass/subclass relationship with more than one superclass • to derive a class (an entity set) that is of heterogeneous instances (entities) a category: a subset of union of its superclasses * inheritance for categories: selective inheritance only!! * constraints for categories: completeness constraint (ie, total vs. partial)

17. The Extended ER Model • Categories and Categorization (cont’d) • partial categorization Company Person U  Account-holder Has-acct Bank

18. The Extended ER Model • Categories and Categorization (cont’d) • total categorization Building Lot Property d =?= U    Building Lot Property

19. An example EER schema

20. Representative Semantic Models • “Semantic” model continuum: RM/T: Enhanced integrity (extended relational model) Funtional Model: relationships as functions SAM* special-purpose types Event Model: dynamic modeling SHM+: static and dynamic modeling ER Model: explicit relationships SDM: entity classes and groupings EER extended ER modeling IFO Model: formalization … ‘78 ‘88 ...

21. Representative Semantic Models • SDM: a Semantic Database Model • proposed by McLeod + Hammer (‘78, ‘81) 1) attempted to provide a full set of modeling facilities 2) provided a rich set of semantic primitives, inheritance, constraints, and derivation options • one of the most referenced semantic models • SDM Modeling Constructs: • Class / Type (unified) • Instance / entity • attributes (member attributes & class attributes) • inter-class connections: sub-/super-type; grouping

22. Representative Semantic Models • Data Abstractions Supported by SDM • Generalization (DAG) • Aggregation (simulated by attribute values) • Classification • Association (via grouping) • SDM Additional Sementic Integrity Constraints: • attribute cardinarlity (eg, single-valued, multi-valued) • Inverse mapping • value range constraints (eg, disjoint, overlapping) • null value constraints (eg, mandatory, optional) • others: exhaustive, duplicate, etc.

23. Representative Semantic Models • Other Unique Features of SDM • Support of Derived Schema Components => permit “data relativism” • attribute derivation (eg, inverse) • subtype derivation: a) attribute defined b) set operations c) value ranges d) user specified • uniformity of information objects • relationships as types • types as objects

24. Representative Semantic Models • Problems of SDM • Too complex for certain applications and their users => trade-off! • No well-defined design methodology and tools • No complete implementation system (only subset of SDM features chosen by later systems) • Lack of behavioral / dynamic modeling

25. Representative Semantic Models • SHM+ : Extended Semantic Hierarchy Model • proposed by Brodie and Ridjanovic (‘84) • address the problem of modeling both the static and dynamic portions of an application • offers a companion design methodology (ACM/PCM) • Structure Modeling of SHM+ • adopted previous semantic models’ concepts and data abstractions e.g., objects, aggregation, generalization, classification, association • a structure specification language (called Beta) • 2-step modeling process: (1) gross structure properties, and (2) fine details of these properties

26. Representative Semantic Models • Behavior Modeling of SHM+ • 2 forms of procedural abstraction a) actions b) transactions • 3 forms of control abstraction a) sequence ~> aggregation b) choice ~> generalization c) repetition ~> association • Behavior Schemes and Behavior Specifications • the former is used for the design of gross behavioral properties • the latter is to specify those properties precisely (based on predicates)

27. Representative Semantic Models • Other unique features of SHM+ • “inheritance” through relationships, too => what does this correspond to EER’s concept? • functional specifications as formal specification & verification techniques • ACM/PCM: the associated/resultant design methodology • a unified methodology for both static and dynamic aspects of the application • Status: • no commercial system developed • overtaken by OODBs later on

28. Representative Semantic Models • Functional Data Models • research started as early as in ‘76 (by Kerschberg) • main idea: to use the concept of mathematical function as the fundamental modeling construct => any request for information is viewed as a function call with certain arguments • several proposals for the models and query languages • the DAPLEX functional model and language are the best known

29. Representative Semantic Models • The (DAPLEX) Functional Data Model (FDM) • Modeling primitives • entities: a) printable entity types: string, integer, char, real, … b) abstract entity type: Entity • functional relationships: eg, Person() => Entity; Student() => Entity Course() => Entity; Section() => Entity; Dept() => Entity • attribute: also a function whose result (range) is a printable entity eg., SSN(Person) => string; Sex(Person) => char;

30. Representative Semantic Models • FDM Modeling primitives (cont’d) • composite attribute: eg, Name() => Entity Name(Person) => Name Fname(Name) => string Lname(Name) => string • relationship type: eg., Major(Student) => Dept; Minor(Student) => Dept • inverse mapping: eg., Major-in(Dept) =>> Student (Inverse of Major) Minor-in(Dept) =>> Student (Inverse of Minor) 1:M

31. Representative Semantic Models • FDM Modeling primitives (cont’d) • M:N relationship type: eg, Course-Completed(Student) =>> Section Student-Attended(Section) =>> Student (Inverse of Course-Completed) • functions with more than one argument: eg., Grade(Student, Section) => char • FDM Diagram Notations: Entity function f 1:M function f ’ (multivalued function f ’) f f ’

32. Representative Semantic Models • FDM Diagram Example

33. Representative Semantic Models • FDM Function Composition => derived functions a) derived attributes eg.,Fname(Person) => Fname(Name(Person)) Lname(Person) => Lname(Name(Person)) b) inherited attributes suppose we declare: IS-A-Person(Student) => Person then we can declare: SSN(Student) => SSN(IS-A-Person(Student)) SSN(Student) => Sex(IS-A-Person(Student)) Fname(Student) => Fname(IS-A-Person(Student)) Hence, generalization can be simulated and supported

34. Representative Semantic Models • FDM Derived Data => also based on function composition Eg.,Define Instructor(Student) =>> Instructor(Section(Student)) Define GradePointAverage(Student) => AVERAGE(Grade(Student,Section)OVER(Section(Student)) Define Brighter(S1 IN Student, S2 IN Student) => GradePointAverage(S1) > GradePointAverage(S2) • FDM Functional Query Language Eg, “which instructors earn over twice the average salary for instructors in their departments?” Define InstAvgSal(Dept) => AVERAGE(Salary(Instructor) OVER Instructor(Dept))

35. Representative Semantic Models • Functional Query Language (cont’d) FOR EACH Instructor SUCH THAT Salary(Instructor) > 2 * InstAvgSal(Dept(Instructor)) PRINT Name(Instructor) • FDM Other Features • Constraints • eg, Define CONSTRAINT NativeHead(Dept) => Has-Dept(Head(Dept)) = Head • Triggers • Derived data update • ...

36. Representative Semantic Models • Discussions 1) Why do we need semantic data models? What advantages are offered by semantic models? 2) What trade-offs can we draw from the various semantic data models? 3) Where to go from here? - handful implementation prototype systems appeared - a (then) trend: => to merge with object-oriented paradigm, so as to bring forth the next generation database technology?!