Conceptual modeling: ER and beyondquerzoni/corsi_assets/1213/... · 2013-06-27 · Introduction to...

Conceptual modeling: ER and beyondGreat Ideas in Computer Science & Engineering (2013)

Domenico Lembo, Antonella Poggi

Sapienza Universita di Roma

Great Ideas in Computer Science & Engineering (2013)Rome, Sapienza Universita di Roma – June 27th, 2013

Structure of the lecture

1 Conceptual modeling and ER1 Introduction to conceptual modeling2 The ER model3 ER limits

2 Description Logics as conceptual modeling languages1 A gentle introduction to DLs2 DLs as conceptual modeling languages

3 Reasoning1 Reasoning over ER diagrams2 Reasoning over DL ontologies

4 DL for efficient reasoning1 The lightweight DL DL-LiteA

5 Conclusions

D. Lembo, A. Poggi Conceptual modeling: ER and beyond June. 27, 2013 (2/137)

Introduction to conceptual modeling The ER model ER limits

Part 1: Conceptual Modeling and ER

Part I

Conceptual Modeling and ER




Outline

1 Introduction to conceptual modeling

2 The ER model

3 ER limits




Outline

1 Introduction to conceptual modelingWhat is conceptual model?Schemas vs instances

2 The ER model

3 ER limits



What is conceptual model? Part 1: Conceptual Modeling and ER

What is conceptual model (in computer science)?

Conceptual model

An abstract high-level representation of a domain of interest of a formalmodel (description)

By definition, a conceptual model is independent of design orimplementation concerns

The aim of a conceptual model is to express the meaning of termsused by domain experts

Important: Once for all, in this lecture we are interested on conceptualdata models, as opposed to other kind of conceptual models aiming atmodeling processes, etc.



Schemas vs instances Part 1: Conceptual Modeling and ER

Schemas vs instances

Typically, a conceptual modeling language allows to describe thestructure of the domain, i.e. its intensional aspects. This is the so-calledschema.The semantics of a schema is given in terms of a set of instances, whichrepresent the domain extensional aspects. However, at each instant,only one instance is meaningful, which corresponds to the actual world.



Schemas vs instances Part 1: Conceptual Modeling and ER

Conceptual modeling language elements

A conceptual modeling language is characterized by the elements itallows to express.In order to define a conceptual modeling language, it is necessary tospecify, for each element:

its intended meaning, which determines the element usage(pragmatics)

its shape within the schema (syntax)

its impact at the extensional level(semantics)




Outline


2 The ER modelIntroduction to ER modelBasic elements of the ER model

3 ER limits



Introduction to ER model Part 1: Conceptual Modeling and ER

The Entity-Relationship model

The Entity-relationship model (ER model) is a conceptual modelaiming at describing the data of interest in a certain domain, i.e. adatabase

In ER, the domain is described graphically (i.e., as a diagram) interms of concepts and relationships among them

Typically used, within a database design, in order to produce thedatabase logical and physical schemas, according to userrequirements

The ER model was first proposed in Peter Chen’s 1976 paper [Che76].Since then several works have proposed extensions, e.g.,[Abr74, BCN92]. Here we refer to the ER model version that, to thebest of our knowledge, is the most widely used.




Overview of an ER schema:syntax

An ER schema consists of a set of elements, that can be eitherentities, denoting classes of objects, attributes, denoting elementaryproperties, or relationships, denoting associations among objects.Additionally an ER schema allows to express constraints torepresent inclusion assertions among entities or other kind ofrestrictions on entity properties or relationships.




Overview of ER schema: semantics

The semantics of an ER schema can be given by specifying whichdatabase states are consistent with the information structurerepresented by the schema.

Formally, a database state B corresponding to an ER schema S is astructure 〈∆B, •B〉, such that:

∆B is a nonempty set and •B is a function that maps every elementof S to tuples of elements of ∆B;B satisfies the constraints of S.

Hence, in order to define the semantics of an ER schema S, foreach element E of S we have to define how E is mapped through•B, and for each constraint C we have to define what it means thatB satisfies a C.



Basic elements of the ER model Part 1: Conceptual Modeling and ER

ER basic constructs

Entity

Entity attributes

Relationship

Relationship attributes




Entity and entity attributes

An entity denotes a set of objects, called its instances, that havecommon properties

Entities are graphically represented as boxesEach entity has a name that uniquely identifies it within the schema

An entity attribute models an elementary property of an entity,whose value belongs to one among predefined basic domain ofvalues, e.g.,integers, strings

An entity attribute is graphically represented as a circle attached tothe entity for which it is defined.Each entity attribute has a name that uniquely identifies it withinthe entity.The domain of an attribute can be specified by a label, but istypically omitted and specified within the database data dictionary.




Semantics of entity

Given a schema S, an entity E, and a database state B = 〈∆B, •B〉corresponding to S, •B maps E to a set of objects in ∆B as follows

EB = {e1, e2, e3, . . .}

which are called the instances of E within the instance B of S.




Semantics of entity attributes

Given a schema S, an attribute A of an entity E on a domain D,and a database state B = 〈∆B, •B〉 corresponding to S, •B maps Ato a set of couples

AB = {(e1, a1), (e2, a2), (e3, a3), . . .}

which are called the instances of A within the instance B of S,where {ei|i = 1, ...} is the set of instances of E and ai belong to D.




Entity and entity attributes (example)

Enrolled(Student( Course(

GradStudent( Course(

GradStudent( AdvCourse(

degree/string(

The instances of GradStudent are the objects denoting graduatestudents. The instances of the attribute degree are the couples (s, d)that associate to each graduate student s the string d denoting themost recent degree that the student has obtained.




Relationship

A relationship is defined between two or more entities and denotesa set of tuples, also called its instances, each of which represents anassociation among a different combination of instances of theentities that participate in the relationship. The arity of arelationship is the number of the entities participating to therelationship.

Relationships are graphically represented as diamonds and roles aregraphically depicted by connecting the relationship to theparticipating entities and labeling the connection with the role nameEach relationship has a name that uniquely identifies it within theschema




Relationship attribute

A relationship attribute models an elementary property of arelationship, whose value belongs to one among the predefinedbasic domains (as for entity attributes)

A relationship attribute is graphically represented as a circleattached to the relationships for which it is definedEach relationship attribute has a name that uniquely identifies itwithin the relationship




Semantics of relationship

Given a schema S, a relationship R of arity n, between the entitiesE1, E2, ...En, and a database state B = 〈∆B, •B〉 corresponding toS, •B maps R to a set of n-tuples

RB = {(e11, e12, . . . , e1n), (e21, e22, . . . , e2n), . . .}

which are called the instances of R within the instance B of S,where eij are instances of Ej , for j = 1...n.




Semantics of relationship attributes

Given a schema S, an attribute A of a relationship R on a domainD, and a database state B = 〈∆B, •B〉 corresponding to S, •Bmaps A to a set of couples

AB = {(r1, a1), (r2, a2), (r3, a3), . . .}

which are called the instances of A within the instance B of S,where ri’s are instances of R and ai’s belong to D.




Relationship and relationship attributes (example)Enrollment)Student) Course)

GradStudent) Course)

GradStudent) AdvCourse)

degree/string)

degree/string)

Enrollment)Student) Course)

dof/date)

dof/date)

The instances of Enrollment are the couples (s, c) denoting that thestudent s is enrolled in the course c. The instances of the attribute dof

are the couples (r, d) that associate to each association r = (s, c) thestring d denoting the date of enrollment of the student s in the course c.




Basic ER constraints

IS-A and generalizations among entities

IS-A and generalizations among relationships

Cardinality constraints

Identification constraints




IS-A among entities

An IS-A constraint can be specified between two entities C and P ,in order to specify that C, named the child, denotes a subsets ofthe objects denoted by P , named the parent.

The IS-A constraint is graphically represented by an arrow from themore specific entity to the more general entity.




Semantics of IS-A constraint among entities

Given a schema S and an IS-A constraint between an entity childC and an entity parent P , a database state B corresponding to S issuch that

CB ⊆ PB,

i.e. all the instances of C are also instances of B within B.




IS-A constraint among entities(example)

Student)

GradStudent) degree/string)

The instances of GradStudent denote graduate students that are arestudents, i.e. are also instances of Student.




Generalization among entities

A generalization constraint can be specified between an entityparent P and two or more entities children in order to specify thatP generalizes the entity children according to a specific criterion.Hence, the entities children denote pairwise disjoint sets of objects.

A generalization is said to be complete if the set of the instances ofthe parent entity is exactly the disjoint union of the set of instancesof the entities children.

The generalization constraint is graphically represented by an arrowfrom the more specific entities, which first join them all, and thenpoints to the more general entity. If the generalization is complete,then the arrow is blackened.




Semantics of generalization among entities

Given a schema S and a generalization constraint between anentity parent P and n entities children C1, C2, ..., Cn, a databasestate B corresponding to S is such that

CBi ⊆ PB and CBi ∩ CBj = ∅, ∀i, j ∈ {1, ...n}, i 6= j

i.e. all the instances of Ci are also instances of PB within B andthe instances of the entities children are pairwise disjoint.

If the generalization is complete, then B is such that

CBi ∪ CBj = PB,∀i, j ∈ {1, ...n}, i 6= j

i.e. the union of the instances of all Ci’s is equal to the set ofinstances of PB within B.




IS-A generalization among entities (example)

Phone)

CellPhone) FixedPhone)

Phones are either cell phones or fixed phones, but cannot be both.




IS-A and generalization among relationships

ISA and generalization constraints can be defined among tworelationships, provided that they have the same arity.

The graphical representation as well as the semantics of the IS-Aconstraint among relationships (resp. generalization constraintamong relationships) is analogous to that of the IS-A constraint(resp. generalization) among entities.




Cardinality constraints

A cardinality constraint can be attached to the participation of anentity E to a relationships R in order to restrict the number oftimes each instance of E is allowed to participate to the instancesof R.

A cardinality constraint consists of a couple (x, y) where x is theminimum cardinality, with x ≥ 0, and y is the maximumcardinality, with y ≥ x or y =“n” (where n denotes ∞).

A cardinality constraint is graphically represented by labeling theparticipation of the entity to the relationship with the couple (x, y).




Semantics of a cardinality constraint

Given a schema S and a cardinality constraint (x, y), a databasestate B corresponding to S is such that for each e in EB, thenumber of instances of R that have e as component within B is:

greater or equal to x, andless or equal to y, if y 6=“n”




Cardinality constraint (example)


dof/date)

BelongsTo)

StudyProgram)

(1,1))

(1,n)) (0,30))

A student has to be enrolled at least a course, a course can have atmost 30 students enrolled at it, and a course belongs to exactly oneprogram of study.




Identification constraints

An identification constraint of an entity E allows to define a set ofproperties (attributes or relationships), called the identifier whichallow to identify the instances of E. This is equivalent to say thatthere cannot exist two instances of E that coincide on all theproperties forming the identifier.

An identifier of E can only comprise attributes and relationships towhich E participates with cardinality (1, 1).An identifier of an entity E can be either internal, if it comprisesonly attributes of E, or external if it comprises at least arelationship to which E participates.

An identification constraint is graphically represented as follows:if the identifier is composed by a single attribute, the correspondingcircle is blackened;if the identifier is composed by more than one attribute orrelationships, all the properties forming the identifier are joinedthrough a line that terminates with a black circle.




Semantics of an identification constraint

Given a schema S and an identification constraint specifying thatthe identifier of E is composed of

the attributes A1, A2, ..., Ak

the relationships R1, R2, ..., Rh

a database state B corresponding to S is such that given twodistinct instances e1 and e2 of E they differ for the value of at leastone Ai or for the participation to at least one relationship Rj

within B.




Identification constraint (example)

Student)

GradStudent) degree/string)

Course) BelongsTo) StudyProgram)

name)

(1,1))

There are not two courses with the same name that belong to the sameprogram of study.




Outline


2 The ER model

3 ER limitsLimits in terms of expressibilityLimits in terms of effective usage



Limits in terms of expressibility Part 1: Conceptual Modeling and ER

ER limits in terms of expressibility

The ER model does not provide several features and modeling primitiveswhich would prove useful to represent complex dependencies betweenobjects and values of the domain.Example of ER expressibility limits are the following:

1 Inability of defining sets of objects by means of complex properties.

2 Inability to refine properties along an IS-A hierarchy.

3 Inability of defining polymorphic relationships, i.e. n-aryrelationships that can relate distinct n-tuples of entities.




First ER limit: Inability of defining sets of objects bymeans of complex properties

Extending the alphabet of a schema is not always the best practice(e.g, it requires to provide documentation for the new symbol, itcomplicates the ER translation procedure to logical models, etc.); one may add new symbols only if the set of objects to denote isreally relevant per se.

However, in ER, the only way one can express properties of sets ofobjects is by introducing a new symbol and asserting properties ofit.




Example illustrating the first ER limit

Suppose that the concept AdvCourse denotes courses such that thereexists at least one graduate student enrolled at them. We may want toexpress this by defining a constraint over the following schema.



degree)

dof)

GradStudent) Course)degree/string)




Example illustrating the first ER limit (Cont’d)

However, the only possibility to express the previous constraint is tointroduce a new relationship and cardinality constraints as follows:



degree)

dof)

AdvEnrollment)

(1,n)) (0,30))

(1,30))




Second ER limit: Inability to refine properties along anIS-A hierarchy

One may require for specific instances of an entity that the objectsthey are related to via a certain relationship belong to a morespecific entity than the one directly associated. ⇒ adding a symbolto the alphabet does not even suffice to express this kind ofconstraint!




Example illustrating the second ER limit

Suppose that AdvCourse denotes courses such that all students enrolledat them are graduate students. Adding the relationship AdvEnrollment

does not allow to express this, because nothing prevents a student thatis not a graduate student to enroll at an advanced course!



degree)

dof)

AdvEnrollment)

(1,n)) (0,30))

(1,30))




Third ER limit: Inability of defining polymorphicrelationships

Several relationships denote associations that relate distinct sets ofobjects, such as the relationship that denote the associationbetween a person and the location where the person is born, or ananimal and the location where the animal is born. This kind ofrelationships are called polymorphic.

However, in ER, relationships are defined among two or moreentities and their name is unique within a schema; the only possibility is to specify two distinct relationships and,possibly, an additional relationship that generalizes both of them⇒ clearly, this solution is in contrast with the desideratum ofkeeping the schema alphabet as restricted as possible!



Limits in terms of effective usage Part 1: Conceptual Modeling and ER

Limits in terms of effective usage

The ER model has been designed to allow to represent a singledatabase state⇒ It does not foresee to use any automatic tool that reasons overthe schema, in order, for example, to:

verify the correctness of the specification, e.g., by detecting elementsthat, according to the schema, cannot have any instance, or alsorepair possible constraints violations within the database state, i.e.,by adding an instance e of an entity child E to the entity parent P .

This kind of limitations will be discussed further in Part III.


A gentle introduction to DLs DLs as conceptual modeling languages

Part 2: Description Logics as conceptual modeling languages

Part II

Description Logics as conceptual modeling

languages




Outline

4 A gentle introduction to Description Logics

5 DLs as conceptual modeling languages




Outline

4 A gentle introduction to Description LogicsIngredients of Description LogicsDescription language

5 DLs as conceptual modeling languages



Ingredients of Description Logics Part 2: Description Logics as conceptual modeling languages

What are Description Logics?

Description Logics [BCM+03] are logics specifically designed torepresent and reason on structured knowledge:

The domain is composed of objects and is structured into:

concepts, which correspond to classes, and denote sets of objects

roles, which correspond to (binary) relationships, and denote binaryrelations on objects

The knowledge is asserted through so-called assertions, i.e., logicalaxioms.



Ingredients of Description Logics Part 2: Description Logics as conceptual modeling languages

Origins of Description Logics

Description Logics stem from early days Knowledge Representationformalisms (late ’70s, early ’80s):

Semantic Networks: graph-based formalism, used to represent themeaning of sentences

Frame Systems: frames used to represent prototypical situations,antecedents of object-oriented formalisms

Problems: no clear semantics, reasoning not well understood

Description Logics (a.k.a. Concept Languages, TerminologicalLanguages) developed starting in the mid ’80s, with the aim of providingsemantics and inference techniques to knowledge representation systems.



Description language Part 2: Description Logics as conceptual modeling languages

Description language

A description language is characterized by a set of constructs forbuilding complex concepts and roles starting from atomic ones:

concepts correspond to classes: interpreted as sets of objects

roles corr. to relationships: interpreted as binary relations on objects

Formal semantics is given in terms of interpretations.

An interpretation I = (∆I , ·I) consists of:

a nonempty set ∆I , the domain of Ian interpretation function ·I , which maps

each atomic concept A to a subset AI of ∆I

each atomic role P to a subset P I of ∆I ×∆I

The interpretation function is extended to complex concepts and rolesaccording to their syntactic structure.




Concept constructors

Construct Syntax Example Semantics

atomic concept A Doctor AI ⊆ ∆I

atomic role P hasChild P I ⊆ ∆I ×∆I

atomic negation ¬A ¬Doctor ∆I \AI

conjunction C uD Hum uMale CI ∩DI

(unqual.) exist. res. ∃R ∃hasChild { a | ∃b. (a, b) ∈ RI }value restriction ∀R.C ∀hasChild.Male {a | ∀b. (a, b) ∈ RI → b ∈ CI}bottom ⊥ ∅

(C, D denote arbitrary concepts and R an arbitrary role)

The above constructs form the basic language AL of the family of ALlanguages.




Additional concept and role constructors

Construct AL· Syntax Semantics

disjunction U C tD CI ∪DI

top > ∆I

qual. exist. res. E ∃R.C { a | ∃b. (a, b) ∈ RI ∧ b ∈ CI }(full) negation C ¬C ∆I \ CI

number N (≥ k R) { a | #{b | (a, b) ∈ RI} ≥ k }restrictions (≤ k R) { a | #{b | (a, b) ∈ RI} ≤ k }qual. number Q (≥ k R.C) { a | #{b | (a, b) ∈ RI ∧ b ∈ CI} ≥ k }restrictions (≤ k R.C) { a | #{b | (a, b) ∈ RI ∧ b ∈ CI} ≤ k }inverse role I R− { (a, b) | (b, a) ∈ RI }role closure reg R∗ (RI)∗

Many different DL constructs and their combinations have been investigated.




Further examples of DL constructs

Disjunction: ∀hasChild.(Doctor t Lawyer)

Qualified existential restriction: ∃hasChild.Doctor

Full negation: ¬(Doctor t Lawyer)

Number restrictions: (≥ 2 hasChild) u (≤ 1 sibling)

Qualified number restrictions: (≥ 2 hasChild. Doctor)

Inverse role: ∀hasChild−.Doctor

Reflexive-transitive role closure: ∃hasChild∗.Doctor




Outline

4 A gentle introduction to Description Logics

5 DLs as conceptual modeling languagesDescription Logics TBoxComparing DLs and ER in terms of expressibility



Description Logics TBox Part 2: Description Logics as conceptual modeling languages

DLs as conceptual modeling languages

As we already stated, a conceptual modeling language typicallyrepresent the intensional level of a domain of interest.As it comes to DLs, the intensional level of a domain can be describedby means of a DL TBox.

Description Logics TBox

Consists of a set of assertions on concepts and roles:

Inclusion assertions on concepts: C1 v C2

Inclusion assertions on roles: R1 v R2

Property assertions on (atomic) roles:(transitive P ) (symmetric P ) (domain P C)(functional P ) (reflexive P ) (range P C) · · ·




Description Logics TBox – Example

Note: We use C1 ≡ C2 as an abbreviation for C1 v C2, C2 v C1.

TBox assertions:

Inclusion assertions on concepts:Father ≡ Human uMale u ∃hasChild

HappyFather v Father u ∀hasChild.(Doctor t Lawyer t HappyPerson)HappyAnc v ∀descendant.HappyFather

Teacher v ¬Doctor u ¬Lawyer

Inclusion assertions on roles:hasChild v descendant hasFather v hasChild−

Property assertions on roles:(transitive descendant), (reflexive descendant),(functional hasFather)




Semantics of a Description Logics TBox

The semantics is given by specifying when an interpretation I satisfies aTBox assertion:

C1 v C2 is satisfied by I if CI1 ⊆ CI2 .

R1 v R2 is satisfied by I if RI1 ⊆ RI2 .

A property assertion (prop P ) is satisfied by I if P I is a relationthat has the property prop.(Note: domain and range assertions can be expressed by means ofconcept inclusion assertions.)




Models of a Description Logics TBox

Model of a DL TBox

An interpretation I is a model of a TBox T if it satisfies all assertions inT .

T is said to be satisfiable if it admits a model.



Comparing DLs and ER in terms of expressibility Part 2: Description Logics as conceptual modeling languages

DLs vs. ER

There is a tight correspondence between variants of DLs and the ERmodel:

as for the elements of both:

Entities correspond to atomic concepts.Attributes and binary associations correspond to roles.Constraints correspond to suitable assertions.

as for the formal semantics of both:

an interpretation I corresponds to what we called a database stateand denoted by B,the domain of interpretation ∆I corresponds to ∆B, andthe interpretation function corresponds to the function •B.




Does any DL encode ER?

Given an expressive enough DL, yes!Indeed, the only problem is the inability of DLs to express n-aryrelationships (or, equivalently, relationship attributes). However, toovercome this inability, it is possible to reify the relationship, i.e., torepresent it as a concept connected to its components by roles.




Encoding ER schemas in DLs – Example

EnrollmentBy)Student)

Course)AdvCourse)

dof)

(1,n)) (1,1))

EnrollmentAt)

Enrollment)

(1,1))

AdvCourse v CourseEnrollment v ∃dof∃dof− v Date

∃EnrollmentBy v Enrollment∃EnrollmentBy− v Student

Enrollment v ∃EnrollmentByStudent v ∃EnrollmentBy−

(funct EnrollmentBy)· · ·

Note: The participation of entities to rela-tionships are expressed by means of conceptinclusions.




How DLs allow to overcome ER limits in terms ofexpressibility?

Examples of ER expressibility limits:

1 Inability of defining sets of objects by means of complex properties; with DLs one can specify set of objects through constructs

2 Inability to refine properties along an IS-A hierarchy; this can be achieved by appropriate assertions on subconceptsproperties

3 Inability of defining polymorphic relationships, i.e. n-aryrelationships that can relate distinct n-tuples of entities; this comes “for free” given that in DLs roles are not nativelytyped.


Reasoning over ER diagrams Reasoning over DL ontologies

Part 3: Reasoning

Part III

Reasoning



Part 3: Reasoning

Outline

6 Reasoning over ER diagrams

7 Reasoning over DL ontologies



Part 3: Reasoning

Outline

6 Reasoning over ER diagramsWhy reasoning over ER diagramsER diagrams vs. DL ontologiesQuery data through ER diagrams

7 Reasoning over DL ontologies



Why reasoning over ER diagrams Part 3: Reasoning

Reasoning over ER diagrams

Consistency of the whole ER diagram: does the diagram admitan instantiation, i.e., can its entities be populated without violatingany of the requirements imposed by the diagram?Entity consistency∗: does the diagram admit an instantiation inwhich the entity has a nonempty set of instances?Entity subsumption∗: does entity E1 subsume entity E2, in everypossible instantiation of the diagram?Entity equivalence∗: Do entities E1 and E2 denote the same setof instances, in every possible instantiation of the diagram?Refinement of properties: Can we yield stricter multiplicities ortypings than those explicitly specified in the diagram?Implicit consequences: Do properties exist that hold whenever allrequirements imposed by the diagram are satisfied?

∗ Consistency, Subsumption and Equivalence can also be verified forRelationships and Attributes.




Reasoning over ER diagrams: Example

Origin&PhoneCall& Phone&

MobileCall& MobileOrigin&

(1,1)

CellPhone& FixedPhone&

place

(1,n)

By reasoning on such a diagram one can deduce that

MobileCall participates to relationship MobileOrigin withmultiplicity 1..1. This is an example of refinement of a multiplicity.

Each instance of MobileOrigin as an associated place.

Each MobileCall has origin by a CellPhone.

Question: Do CellPhones originate only MobileCalls?D. Lembo, A. Poggi Conceptual modeling: ER and beyond June. 27, 2013 (68/137)



Reasoning over ER diagrams: Example

Origin&PhoneCall& Phone&

MobileCall& MobileOrigin&

(1,1)

CellPhone& FixedPhone&

place

(1,n)

By reasoning on such a diagram, one can deduce that

CellPhone is inconsistent, i.e., it has no instances.

Phone and FixedPhone are equivalent, since Phone is the union ofCellPhone and FixedPhone, and since CellPhone is inconsistent.

MobileOrigin is inconsistent.

MobileCall is inconsistent.

Obviously, some errors are present in the diagramD. Lembo, A. Poggi Conceptual modeling: ER and beyond June. 27, 2013 (69/137)



Reasoning over ER diagrams: Feasibility

How much does it cost to reason over ER diagrams?

Is it feasible?

Are there implemented tools that can be exploited for this?

Description Logic theory and tools allow us to answer these questions!



ER diagrams vs. DL ontologies Part 3: Reasoning

Relationship between DLs and conceptual modelingformalisms

DLs are ideally suited to capture the fundamental features ofconceptual modeling formalism used in information systems design:

Entity-Relationship diagrams, used in database conceptual modeling(which we focus on in this lecture).UML Class Diagrams, used in the design phase of softwareapplications.

Conceptual schemas can be seen as special DL ontologies, i.e.,logical theories.

They are however tailored for conceptualizing a single logical model(database).

Note: DLs provide the foundations for ontology languages.Different versions of OWL, the W3C standard for ontology specification,have been defined as syntactic variants of certain Description Logics.




DLs vs. ER Diagrams

There is a tight correspondence between variants of DLs and ERDiagrams [BCDG05]∗.

In [BCDG05] two transformations are devised:

one that associates to each ER diagram D a DL TBox TD specifiedin ALCQI.one that associates to each ALC TBox T an ER Diagram DT .

The transformations are not model-preserving, but are based on acorrespondence between instantiations of the ER Diagram andmodels of the associated ontology.

The transformations are satisfiability-preserving, i.e., an entity E isconsistent in D iff the corresponding concept is satisfiable in T .

∗In fact that paper refers to UML class diagrams, but all results apply toER diagrams as well.




Encoding ER Diagrams in DLs

The ideas behind the encoding of an ER Diagram D in terms of anALCQI TBox TD are quite natural (we here slightly simplify theencoding of [BCDG05]):

Each Entity is represented by an atomic concept.Each ER-attribute is represented by a role, and each data type isrepresented as a concept∗.Each binary relationship is represented by a role.Each non-binary relationship is reified, i.e., represented as aconcept connected to its components by roles.Each relationship with attributes is reified, and attributesassociated to the reified concept.Each part of the diagram is encoded by suitable assertions.

∗ It is in fact possible to extend such encoding to a DL allowing forattributes, thus transforming ER-attributes into DL-attributes.

We illustrate the encoding by means of an example.D. Lembo, A. Poggi Conceptual modeling: ER and beyond June. 27, 2013 (73/137)



Encoding ER Diagrams in DLs – Example

PhoneCall) Phone)(1,1)

CellPhone) FixedPhone)

place/String

Origin)hasOrigin)(1,1)

isOrigin)(1,1)

(1,n) MobOrigin)hasMOrigin)

(1,1) isMOrigin)

(1,1) MobileCall)

PhoneCall v ∃hasOrgin PhoneCall v ≤ 1hasOrgin∃hasOrigin v PhoneCall ∃hasOrigin− v Origin∃isOrigin v Phone ∃isOrigin− v Origin

Origin v ∃hasOrgin− Origin v ≤ 1hasOrgin−

Origin v ∃isOrgin− Origin v ≤ 1isOrgin−

Origin v ∃place Origin v ≤ 1placePhone v CellPhone t FixedPhone CellPhone v ¬FixedPhone

CellPhone v Phone FixedPhone v Phone · · ·The above encoding can be completed with the identification assertion(id Origin hasOrigin−, isOrigin−), not allowed in ALCQI.




Encoding ER Diagrams in DLs

The encoding of an ER diagram into an ALCQI TBox is used in[BCDG05] to show the following complexity upper bound for entityconsistency and entity subsumption

Theorem

Reasoning (entity consistency and entity subsumption) over ERDiagrams is in ExpTime.




Encoding DL TBoxes in ER Diagrams

[BCDG05] provides an encoding of an ALC TBox T (in fact a fragmentthereof) in terms of an ER diagram.Reasoning in the encoded ALC-fragment is already ExpTime-hard.From this, we obtain:

Theorem

Reasoning (entity consistency and entity subsumption) over ERDiagrams is ExpTime-hard.




Reasoning over ER Diagrams using DLs

The two encodings show that DL TBoxes and ER Diagramsessentially have the same expressive power.

Hence, reasoning over ER Diagrams has the same complexity asreasoning over ontologies in expressive DLs, i.e.,ExpTime-complete.

The high complexity is caused by:1 the possibility to use disjunction (covering constraints)2 the interaction between role inclusions and functionality constraints

(maximum 1 cardinality)

Without (1) and restricting (2), reasoning becomes simpler [ACK+07]......More on this last aspects shown later on.



Query data through ER diagrams Part 3: Reasoning

What about data?

So far we have considered only intensional reasoning, i.e., reasoninginvolving only the schema level of an ER diagram, or, equivalently, a DLTBox.

When also the extensional level come into play, other reasoning servicesare of interest.

Above all, query answering!

Note: Normally, the instance of an ER diagram is not nativelymaintained, but it is stored in terms of a relational database whichinstantiates a relational schema obtained from the ER diagram.

In the following, we however refer directly to the instance of the ERdiagram (in fact of the DL TBox representing it). Notice that suchinstance is always constructible starting from the underlying database.




Example of query

supervisedBy+

Manager+

AreaManager+

Project+

worksFor+

TopManager+ manages+

empCode salary

Employee+

q(ce, cm, se, sm) ← worksFor(e, p) ∧manages(m, p) ∧ supervisedBy(e,m)∧empCode(e, ce) ∧ empCode(m, cm) ∧salary(e, se) ∧ salary(m, sm) ∧ se ≥ sm




Query answering under different assumptions

There are fundamentally different assumptions when addressing queryanswering in different settings:

traditional database assumption

knowledge representation assumption




Query answering under the database assumption

Data are completely specified (CWA), and typically large.

Schema/intensional information used in the design phase.

At runtime, the data is assumed to satisfy the schema, andtherefore the schema is not used.

Queries allow for complex navigation paths in the data (cf. SQL).

; Query answering amounts to query evaluation, which iscomputationally easy.




Query answering under the database assumption (cont’d)

DataSource

LogicalSchema

Schema /Ontology





ResultQuery

DataSource

LogicalSchema

Schema /Ontology





Reasoning

ResultQuery

DataSource

LogicalSchema

Schema /Ontology




Query answering under the database assumption – Example

WorksFor'Employee' Project'

Manager'

For each concept/relationship we have a (complete) table in the DB.DB: Employee = { john, mary, nick }

Manager = { john, nick }Project = { prA, prB }worksFor = { (john,prA), (mary,prB) }

Query: q(x) ← Manager(x),Project(p),worksFor(x, p)

Answer: ???

{




Query answering under the database assumption – Example


Manager'

For each concept/relationship we have a (complete) table in the DB.DB: Employee = { john, mary, nick }

Manager = { john, nick }Project = { prA, prB }worksFor = { (john,prA), (mary,prB) }

Query: q(x) ← Manager(x),Project(p),worksFor(x, p)

Answer: { john }

{




Query answering under the KR assumption

An ontology (or conceptual schema, or knowledge base) imposesconstraints on the data.

Actual data may be incomplete or inconsistent w.r.t. suchconstraints.

The system has to take into account intensional information duringquery answering, and overcome incompleteness or inconsistency.

Size of the data is not considered critical (comparable to the size ofthe intensional information).

Queries are typically simple, i.e., atomic (the name of a concept).

; Query answering amounts to logical inference, which iscomputationally more costly.




Query answering under the KR assumption (cont’d)

Query Result

Reasoning

DataSource

LogicalSchema

Schema /Ontology




Query answering under the KR assumption – Example


Manager'

Partial DB assumption: we have a (complete) table in the database onlyfor some concepts/relationships.DB: Manager = { john, nick }

Project = { prA, prB }worksFor = { (john,prA), (mary,prB) }

Query: q(x) ← Employee(x)

Answer: ???




Query answering under the KR assumption – Example


Manager'

Partial DB assumption: we have a (complete) table in the database onlyfor some concepts/relationships.DB: Manager = { john, nick }

Project = { prA, prB }worksFor = { (john,prA), (mary,prB) }

Query: q(x) ← Employee(x)

Answer: { john, nick, mary }




Query answering under the KR assumption – Example 2

hasFather(Person((1,1)(

Each person has a father, who is a person

Tables in the DB may be incompletely specified.

DB: Person = { john, nick, toni }hasFather ⊇ { (john,nick), (nick,toni) }

Queries: q1(x, y) ← hasFather(x, y)q2(x) ← hasFather(x, y)q3(x) ← hasFather(x, y1), hasFather(y1, y2), hasFather(y2, y3)q4(x, y3) ← hasFather(x, y1), hasFather(y1, y2), hasFather(y2, y3)

Answers: to q1: ???

{

to q2: ???

{

to q3: ???

{

to q4: ???

{










Answers: to q1: { (john,nick), (nick,toni) }

{

to q2: ???

{

to q3: ???

{

to q4: ???

{











{

to q2: { john, nick, toni }

{

to q3: ???

{

to q4: ???

{











{


{


{

to q4: ???

{











{


{


{

to q4: { }

{




QA under the KR assumption – Andrea’s Example

officeMate(

supervisedBy(

Employee(

Manager(

AreaManager( TopManager(

Tables may be incompletely specified.

Employee = { andrea, paul, mary, john }Manager = { andrea, paul, mary }

AreaManager ⊇ { paul }TopManager ⊇ { mary }supervisedBy = { (john,andrea), (john,mary) }

officeMate = { (mary,andrea), (andrea,paul) }

john

andrea:Manager mary:TopManagerofficeMate

supervisedBy supervisedBy

paul:AreaManager

officeMate




QA under the KR assumption – Andrea’s Example (cont’d)

officeMate(

supervisedBy(

Employee(

Manager(


john



paul:AreaManager

officeMate

q(x) ← supervisedBy(x, y), TopManager(y),officeMate(y, z), AreaManager(z)

Answer: ???

To determine this answer, we need to resort toreasoning by cases.




QA under the KR assumption – Andrea’s Example (cont’d)

officeMate(

supervisedBy(

Employee(

Manager(


john



paul:AreaManager

officeMate

q(x) ← supervisedBy(x, y), TopManager(y),officeMate(y, z), AreaManager(z)

Answer: { john }

To determine this answer, we need to resort toreasoning by cases.



Part 3: Reasoning

Outline

6 Reasoning over ER diagrams

7 Reasoning over DL ontologiesLet’s get formalQueries over Description Logics ontologiesCertain answersComplexity of query answering



Let’s get formal Part 3: Reasoning

Extensional level of a DL

So far we have seen a DL ontology as a TBox.

Besides a mechanism for specifying intensional knowledge andalgorithms to reason over it, DL languages are characterized also by amechanism for specifying properties of objects, i.e.,

that certain individuals (or objects) are in the extension of aconcept,

that certain relationships hold between individuals.

This is realized in terms of an ABox, which is a set of assertion of theform:

HappyFather(john),hasChild(john, mary),

age(john, 35)

where HappyFather is an atomic concept, hasChild is an atomic role,and age is an attribute.




Description Logic ontology (or knowledge base)

A DL ontology is a pair O = 〈T ,A〉, where T is a TBox and A is anABox




Semantics of a Description Logic ontology

To define the semantics of a DL ontology we need to first extend theinterpretation function also to constants.

Given an interpretation I = 〈∆I , ·I〉, I associates each constant c withan object of ∆I , denoted cI .

Then the semantics of an ABox is as follows∗:

A(c) is satisfied by I if cI ∈ AI .

P (c1, c2) is satisfied by I if (cI1 , cI2 ) ∈ P I .

∗ For simplicity, hereafter we no longer distinguish attributes from roles.




Models of a Description Logics ontology

Model of a DL knowledge base

An interpretation I is a model of O = 〈T ,A〉 if it satisfies all assertionsin T and all assertions in A.

O is said to be satisfiable if it admits a model.

The fundamental reasoning service from which all other ones can beeasily derived is . . .

Logical implication

O logically implies and assertion α, written O |= α, if α is satisfied byall models of O.




TBox reasoning

Concept Satisfiability: C is satisfiable wrt T , if there is a model Iof T such that CI is not empty, i.e., T 6|= C ≡ ⊥.

Subsumption: C1 is subsumed by C2 wrt T , if for every model I ofT we have CI1 ⊆ CI2 , i.e., T |= C1 v C2.

Equivalence: C1 and C2 are equivalent wrt T if for every model Iof T we have CI1 = CI2 , i.e., T |= C1 ≡ C2.

Disjointness: C1 and C2 are disjoint wrt T if for every model I ofT we have CI1 ∩ CI2 = ∅, i.e., T |= C1 u C2 ≡ ⊥.

Analogous definitions hold for role satisfiability, subsumption,equivalence, and disjointness.




Reasoning over an ontology

Ontology Satisfiability: Verify whether an ontology O is satisfiable,i.e., whether O admits at least one model.

Concept Instance Checking: Verify whether an individual c is aninstance of a concept C in O, i.e., whether O |= C(c).

Role Instance Checking: Verify whether a pair (c1, c2) of individualsis an instance of a role R in O, i.e., whether O |= R(c1, c2).

Query Answering: see later . . .



Queries over Description Logics ontologies Part 3: Reasoning

Queries over Description Logics ontologies

We need more complex queries than simple concept (or role) expressions.

A conjunctive query q(~x) over an ontology O = 〈T ,A〉 has the form:

q(~x) ← ∃~y. conj (~x, ~y)

where:

~x is a tuple of so-called distinguished variables.The number of variables in ~x is called the arity of q.

~y is a tuple of so-called non-distinguished variables,

q(~x) is called the head of q.

conj (~x, ~y), called the body of q, is a conjunction of atoms, whereeach atom:

has as predicate symbol an atomic concept or role of T ,may use variables in ~x and ~y,may use constants that are individuals of A.



Queries over Description Logics ontologies Part 3: Reasoning

Queries over Description Logics ontologies (cont’d)

Note: we may also use for CQs a simplified notationq(~x) ← body(~x, ~y)

where body(~x, ~y) is a sequence constituted by the atoms in conj (~x, ~y).

Example of conjunctive query

q(x, y)← ∃p. Employee(x) ∧ Employee(y) ∧ Project(p) ∧supervisedBy(y, x) ∧ worksFor(x, p) ∧ worksFor(y, p)

In simplified notation:q(x, y)← Employee(x),Employee(y),Project(p),

supervisedBy(y, x),worksFor(x, p),worksFor(y, p)

Note: a CQ corresponds to a select-project-join SQL query.



Certain answers Part 3: Reasoning

Certain answers to a query

Let O = 〈T ,A〉 be an ontology, I an interpretation for O, andq(~x)← ∃~y. conj (~x, ~y) a CQ.

The answer to q(~x) over I, denoted qI , . . .

is the set of tuples ~c of constants of A such that the formula∃~y. conj (~c, ~y) evaluates to true in I.

We are interested in finding those answers that hold in all models of anontology.

The certain answers to q(~x) over O = 〈T ,A〉, denoted cert(q,O), . . .

are the tuples ~c of constants of A such that ~c ∈ qI , for every model Iof O.




Query answering over ontologies

Query answering over an ontology OIs the problem of computing the certain answers to a query over O.

Computing certain answers is a form of logical implication:

~c ∈ cert(q,O) iff O |= q(~c)

Note: instance checking is a special case of query answering: it amountsto answering the boolean query q()← A(c) (resp., q()← P (c1, c2))over O (in this case ~c is the empty tuple).




Query answering over ontologies – Example


TBox T : ∃hasFather v Person∃hasFather− v Person

Person v ∃hasFather(funct hasFather)

ABox A: Person(john), Person(nick), Person(toni)hasFather(john,nick), hasFather(nick,toni)

Queries:q1(x, y) ← hasFather(x, y)q2(x) ← ∃y. hasFather(x, y)q3(x) ← ∃y1, y2, y3. hasFather(x, y1) ∧ hasFather(y1, y2) ∧ hasFather(y2, y3)q4(x, y3) ← ∃y1, y2. hasFather(x, y1) ∧ hasFather(y1, y2) ∧ hasFather(y2, y3)

Certain answers: cert(q1, 〈T ,A〉) = ???

{

cert(q2, 〈T ,A〉) = ???

{

cert(q3, 〈T ,A〉) = ???

{

cert(q4, 〈T ,A〉) = ???

{










Certain answers: cert(q1, 〈T ,A〉) = { (john,nick), (nick,toni) }

{

cert(q2, 〈T ,A〉) = ???

{

cert(q3, 〈T ,A〉) = ???

{

cert(q4, 〈T ,A〉) = ???

{











{

cert(q2, 〈T ,A〉) = { john, nick, toni }

{

cert(q3, 〈T ,A〉) = ???

{

cert(q4, 〈T ,A〉) = ???

{











{


{


{

cert(q4, 〈T ,A〉) = ???

{











{


{


{

cert(q4, 〈T ,A〉) = { }

{




Unions of conjunctive queries

We consider also unions of CQs.

A union of conjunctive queries (UCQ) has the form:

q(~x) ← ∃~y1. conj (~x, ~y1) ∨ · · · ∨ ∃ ~yk. conj (~x, ~yk)

where each ~yi. conj (~x, ~yi) is the body of a CQ.

Example

q(x)← (Manager(x) ∧ worksFor(x, tones)) ∨(∃y. supervisedBy(y, x) ∧ worksFor(y, tones))

The (certain) answers to a UCQ are defined analogously to those forCQs.



Complexity of query answering Part 3: Reasoning

Data and combined complexity

When measuring the complexity of answering a query q(~x) over anontology O = 〈T ,A〉, various parameters are of importance.

Depending on which parameters we consider, we get differentcomplexity measures:

Data complexity: TBox and query are considered fixed, and onlythe size of the ABox (i.e., the data) matters.

Query complexity: TBox and ABox are considered fixed, and onlythe size of the query matters.

Schema complexity: ABox and query are considered fixed, and onlythe size of the TBox (i.e., the schema) matters.

Combined complexity: no parameter is considered fixed.

There are settings where the size of the data dominates the size of theconceptual layer (and of the query), as in ontology-based data access.; Data complexity is the relevant complexity measure.



Complexity of query answering Part 3: Reasoning

Complexity of query answering in DLs

Answering (U)CQs over DL ontologies has been studied extensively:

Combined complexity:NP-complete for plain databases (i.e., with an empty TBox)ExpTime-complete for ALC [CDGL98, Lut07]2ExpTime-complete for very expressive DLs (with inverse roles)[CDGL98, Lut07]

Data complexity:in AC0 for plain databases (AC0 is strictly contained in LogSpace)coNP-hard with disjunction in the TBox [DLNS94, CDGL+06]coNP-complete for very expressive DLs [LR98, OCE06, GHLS07]

Questions

Can we find interesting families of DLs for which the queryanswering problem can be solved efficiently?

If yes, can we leverage relational database technology for queryanswering?


The lightweight DL DL-LiteA

Part 4: DLs for efficient reasoning

Part IV

DLs for efficient reasoning




Outline

8 The lightweight DL DL-LiteA




Outline

8 The lightweight DL DL-LiteAThe DL-Lite familyDL-LiteAQuery answering in DL-LiteAOntology satisfiabilityComplexity results for DL-LiteA and beyond



The DL-Lite family Part 4: DLs for efficient reasoning

The DL-Lite family

A family of DLs optimized according to the tradeoff betweenexpressive power and complexity of query answering, with emphasison data.

Carefully designed to have nice computational properties foranswering UCQs (i.e., computing certain answers):

The same complexity as relational databases.In fact, query answering can be delegated to a relational DB engine.The DLs of the DL-Lite family are essentially the maximallyexpressive ontology languages enjoying these nice computationalproperties.

We present DL-LiteA, an expressive member of the DL-Lite family.

DL-LiteA captures almost all ER diagrams (but cannot expresscovering!)



DL-LiteA Part 4: DLs for efficient reasoning

DL-LiteA ontologies

TBox assertions:

Class (concept) inclusion assertions: B v C, with:

B −→ A | ∃QC −→ B | ¬B

Property (role) inclusion assertions: Q v R, with:

Q −→ P | P−R −→ Q | ¬Q

Functionality assertions: (funct Q)

Proviso: functional properties cannot be specialized.

ABox assertions: A(c), P (c1, c2), with c1, c2 constants

Note: DL-LiteA distinguishes also between object and data properties(ignored here).




Semantics of DL-LiteAConstruct Syntax Example Semantics

atomic conc. A Doctor AI ⊆ ∆I

exist. restr. ∃Q ∃child− {d | ∃e. (d, e) ∈ QI}at. conc. neg. ¬A ¬Doctor ∆I \AI

conc. neg. ¬∃Q ¬∃child ∆I \ (∃Q)I

atomic role P child P I ⊆ ∆I ×∆I

inverse role P− child− {(o, o′) | (o′, o) ∈ P I}role negation ¬Q ¬manages (∆I ×∆I) \QI

conc. incl. B v C Father v ∃child BI ⊆ CI

role incl. Q v R hasFather v child− QI ⊆ RI

funct. asser. (funct Q) (funct succ) ∀d, e, e′.(d, e) ∈ QI ∧ (d, e′) ∈ QI → e = e′

mem. asser. A(c) Father(bob) cI ∈ AI

mem. asser. P (c1, c2) child(bob, ann) (cI1 , cI2 ) ∈ P I

DL-LiteA (as all DLs of the DL-Lite family) adopts the Unique NameAssumption (UNA), i.e., different individuals denote different objects.




Capturing basic ontology constructs in DL-LiteA

ISA between classes A1 v A2

Disjointness between classes A1 v ¬A2

Domain and range of properties ∃P v A1 ∃P− v A2

Mandatory participation (min card = 1) A1 v ∃P A2 v ∃P−

Functionality of relations (max card = 1) (funct P ) (funct P−)

ISA between properties Q1 v Q2

Disjointness between properties Q1 v ¬Q2




Capturing basic ontology constructs in DL-LiteA

DL-LiteA cannot capture completeness of a hierarchy. This wouldrequire disjunction (i.e., OR)DL-LiteA can be extended to capture also min cardinalityconstraints (A v≤ nQ) and max cardinality constraints(A v≥ nQ) (not considered here for simplicity).It can be extended with expressive forms of identification assertionswhich include, e.g., (id Origin hasOrigin−, isOrigin−).DL-LiteA can be extended also with denial assertions, i.e.constraints imposing that a certain CQ has to be evaluated to falsein every model of the ontology.DL-LiteA can be equipped with more expressive constraints, whichessentially correspond to all FOL boolean queries, under a welldefined semantics that approximate classical DL semantics.

All above extensions preserve the computational characteristics ofDL-LiteA



Query answering in DL-LiteA Part 4: DLs for efficient reasoning

Query answering in DL-LiteA

We study answering of (U)CQs over DL-LiteA ontologies via queryrewriting.

We first consider query answering over satisfiable ontologies, i.e., thatadmit at least one model.

Then, we show how to exploit query answering over satisfiable ontologiesto establish ontology satisfiability.

Remark

we call positive inclusions (PIs) assertions of the form

Cl v A | ∃QQ1 v Q2

whereas we call negative inclusions (NIs) assertions of the form

Cl v ¬A | ¬∃QQ1 v ¬Q2




Query answering in DL-LiteA (cont’d)

Given a CQ q and a satisfiable ontology O = 〈T ,A〉, we computecert(q,O) as follows

1 using T , reformulate q as a union rq,T of CQs.

2 Evaluate rq,T directly over A managed in secondary storage via aRDBMS.

rq,T is called the perfect rewriting of q w.r.t. T .

Correctness of this procedure shows FOL-rewritability of queryanswering in DL-LiteA; Query answering over DL-LiteA ontologies can be done usingRDMBS technology.




Query answering in DL-LiteA: Query rewriting

Intuition: Use the PIs as basic rewriting rules

q(x) ← Professor(x)

AssProfessor v Professoras a logic rule: Professor(z) ← AssProfessor(z)

Basic rewriting step:

when the atom unifies with the head of the rule.substitute the atom with the body of the rule.

Towards the computation of the perfect rewriting, we add to the inputquery above the following query

q(x) ← AssProfessor(x)

We say that the PI AssProfessor v Professor applies to the atomProfessor(x).




Query answering in DL-LiteA: Query rewriting (cont’d)

Consider now the query

q(x) ← teaches(x, y)

Professor v ∃teachesas a logic rule: teaches(z1, z2) ← Professor(z1)

We add to the reformulation the query






Conversely, for the query

q(x) ← teaches(x, databases)


teaches(x, databases) does not unify with teaches(z1, z2), since theexistentially quantified variable z2 in the head of the rule does not unifywith the constant databases.

In this case the PI does not apply to the atom teaches(x, databases).

The same holds for the following query, where y is distinguished

q(x, y) ← teaches(x, y)





An analogous behavior with join variables

q(x) ← teaches(x, y),Course(y)


The PI above does not apply to the atom teaches(x, y).

Conversely, the PI

∃teaches− v Courseas a logic rule: Course(z2) ← teaches(z1, z2)

applies to the atom Course(y).

We add to the perfect rewriting the query

q(x) ← teaches(x, y), teaches(z, y)





We now have the query

q(x) ← teaches(x, y), teaches(z, y)

The PI Professor v ∃teachesas a logic rule: teaches(z1, z2) ← Professor(z1)

does not apply to teaches(x, y) nor teaches(z, y), since y is in join.

However, we can transform the above query by unifying the atomsteaches(x, y), teaches(z1, y). This rewriting step is called reduce, andproduces the following query

q(x) ← teaches(x, y)

We can now apply the PI above, and add to the reformulation the query





Answering by rewriting in DL-LiteA: The algorithm

1 Rewrite the CQ q into a UCQs: apply to q in all possible ways thePIs in the TBox T .

2 This corresponds to exploiting ISAs, role typings, and mandatoryparticipations to obtain new queries that could contribute to theanswer.

3 Unifying atoms can make applicable rules that could not be appliedotherwise.

4 The UCQs resulting from this process is the perfect rewriting rq,T .

5 rq,T is then encoded into SQL and evaluated over A managed insecondary storage via a RDBMS, to return the set cert(q,O).

Notice that NIs play no role in the process above: when the ontology issatisfiable, we can ignore NIs and answer queries as NIs were notspecified in T .




Query answering in DL-LiteA: Example

TBox: Professor v ∃teaches∃teaches− v Course

Query: q(x)← teaches(x, y),Course(y)

Perfect Rewriting: q(x)← teaches(x, y),Course(y)q(x)← teaches(x, y), teaches(z, y)q(x)← teaches(x, z)q(x)← Professor(x)

ABox: teaches(John, databases)Professor(Mary)

It is easy to see that the evaluation of rq,T over A in this case producesthe set {John, Mary}.



Ontology satisfiability Part 4: DLs for efficient reasoning

Satisfiability of ontologies with only PIs

Let us now attack the problem of establishing whether an ontology issatisfiable.

A first notable result says us that PIs alone cannot generate ontologyunsatisfiability.

Theorem

Let O = 〈T ,A〉 be either a DL-LiteA ontology, where T contains onlyPIs. Then, O is satisfiable.




DL-LiteA ontologies

Unsatisfiability in DL-LiteA ontologies can be however caused by NIsand functionality assertions.

We consider below only the case of NIs.

Example: TBox T : Professor v ¬Student∃teaches v Professor

ABox A: teaches(John, databases)Student(John)




Checking satisfiability of DL-LiteA ontologies

Let O = 〈T ,A〉, and TP be the set of PIs in T .

For each NI N between concepts (resp. roles) in T , we ask 〈TP ,A〉 ifthere exists some individual (resp. pair of individuals) that contradicts N ,i.e., we pose over 〈TP ,A〉 a boolean CQ qN such that 〈TP ,A〉 |= qN iff〈TP ∪ {N},A〉 is unsatisfiable.

To verify if 〈TP ,A〉 |= qN we use the query rewriting algorithm for CQsover satisfiable DL-LiteA ontologies, i.e., we compute the perfectrewriting rqN ,TP and evaluate it (in fact its SQL encoding) over A seen asa database.

O is unsatisfiable iff there exists a NI N ∈ T such that the evaluation ofrqN ,TP over A seen as a database returns true.

Satisfiability of a DL-LiteA ontology is reduced to evaluation of a UCQs over

A. ; Ontology satisfiability in DL-LiteA can be done using RDMBS

technology.D. Lembo, A. Poggi Conceptual modeling: ER and beyond June. 27, 2013 (124/137)


Complexity results for DL-LiteA and beyond Part 4: DLs for efficient reasoning

Complexity of reasoning in DL-LiteA

Ontology satisfiability and all classical DL reasoning tasks are:

Efficiently tractable in the size of TBox (i.e., PTime).Very efficiently tractable in the size of the ABox (i.e., AC0).

In fact, reasoning can be done by constructing suitable FOL/SQLqueries and evaluating them over the ABox (FOL-rewritability).

Query answering for CQs and UCQs is:

PTime in the size of TBox.AC0 in the size of the ABox.Exponential in the size of the query (NP-complete).Bad? . . . not really, this is exactly as in relational DBs.

Can we go beyond DL-LiteA?

By adding essentially any other DL construct, e.g., union (t), valuerestriction (∀R.C), etc., without some limitations we lose these nicecomputational properties (see later).

If we ignore proviso, DL-Lite becomes NLOGSPACE-hard.


Summary Exam

Part 5: Conclusions

Part V

Conclusions


Summary Exam

Part 5: Conclusions

Outline

9 Summary

10 Exam


Summary Exam

Part 5: Conclusions

What we have done in this lecture

We have discussed ER diagrams in a formal and semanticallyprecise way;

We have investigated their relation with DLs;

This has been motivated by two “contrastive” needs: (i)Augmenting the expressive power of the language used forconceptual modeling; (ii) making use of automated reasoningmechanisms over the schema/ontology.

Since reasoning is costly even over DL ontology corresponding toER diagrams we have discussed a lightweight DL, called DL-LiteA,allowing for efficient reasoning, which essentially capture ERdiagrams without covering constraints.

Interestingly, complexity of query answering over such DL set thestage for advanced forms of reasoning over conceptual schemas, asin ontology-based data access.


Summary Exam

Part 5: Conclusions

Outline

9 Summary

10 Exam


Summary Exam

Part 5: Conclusions

What can be done to complete this lecture (exam)

Various possibilities (all calling for one-hour seminar by the student)

....complete the investigation on the slides we had to skeep :-(..

Study more in deep intensional reasoning in lightweight DLs (inparticular in the DL-Lite and the EL family), for which intensionalreasoning is polynomial;

Considering other conceptual data modeling languages on a formalperspective (e.g., ORM, SBVR);

Investigating dynamic aspects (i.e., processes): e.g., dynamicmodeling in UML, other conceptual modeling formalisms forprocesses;

Challenging task: make a proposal on how to design a relationaldatabase form a DL ontology!

......


Summary Exam

Part 5: Conclusions

Acknowledgements

Daniela Berardi

Diego Calvanese (univ. of Bozen/Bolzano)

Giuseppe De Giacomo

Enrico Franconi (univ. of Bozen/Bolzano)

Maurizio Lenzerini

Daniele Nardi

Riccardo Rosati


Summary Exam

Part 5: Conclusions

References I

[Abr74] J. R. Abrial.

Data semantics.

In J. W. Klimbie and K. L. Koffeman, editors, Data Base Management,pages 1–59. North-Holland Publ. Co., 1974.

[ACK+07] Alessandro Artale, Diego Calvanese, Roman Kontchakov, VladislavRyzhikov, and Michael Zakharyaschev.

Reasoning over extended ER models.

In Proc. of the 26th Int. Conf. on Conceptual Modeling (ER 2007),volume 4801 of Lecture Notes in Computer Science, pages 277–292.Springer, 2007.

[BCDG05] Daniela Berardi, Diego Calvanese, and Giuseppe De Giacomo.

Reasoning on UML class diagrams.

Artificial Intelligence, 168(1–2):70–118, 2005.


Summary Exam

Part 5: Conclusions

References II

[BCM+03] Franz Baader, Diego Calvanese, Deborah McGuinness, Daniele Nardi,and Peter F. Patel-Schneider, editors.

The Description Logic Handbook: Theory, Implementation andApplications.

Cambridge University Press, 2003.

[BCN92] Carlo Batini, Stefano Ceri, and Shamkant B. Navathe.

Conceptual Database Design, an Entity-Relationship Approach.

Benjamin and Cummings Publ. Co., 1992.

[CDGL98] Diego Calvanese, Giuseppe De Giacomo, and Maurizio Lenzerini.

On the decidability of query containment under constraints.

In Proc. of the 17th ACM SIGACT SIGMOD SIGART Symp. onPrinciples of Database Systems (PODS’98), pages 149–158, 1998.


Summary Exam

Part 5: Conclusions

References III

[CDGL+06] Diego Calvanese, Giuseppe De Giacomo, Domenico Lembo, MaurizioLenzerini, and Riccardo Rosati.

Data complexity of query answering in description logics.

In Proc. of the 10th Int. Conf. on the Principles of KnowledgeRepresentation and Reasoning (KR 2006), pages 260–270, 2006.

[Che76] Peter P. Chen.

The Entity-Relationship model: Toward a unified view of data.

ACM Trans. on Database Systems, 1(1):9–36, March 1976.

[DLNS94] Francesco M. Donini, Maurizio Lenzerini, Daniele Nardi, and AndreaSchaerf.

Deduction in concept languages: From subsumption to instancechecking.

J. of Logic and Computation, 4(4):423–452, 1994.


Summary Exam

Part 5: Conclusions

References IV

[GHLS07] Birte Glimm, Ian Horrocks, Carsten Lutz, and Ulrike Sattler.

Conjunctive query answering for the description logic SHIQ.

In Proc. of the 20th Int. Joint Conf. on Artificial Intelligence(IJCAI 2007), pages 399–404, 2007.

[LR98] Alon Y. Levy and Marie-Christine Rousset.

Combining Horn rules and description logics in CARIN.

Artificial Intelligence, 104(1–2):165–209, 1998.

[Lut07] Carsten Lutz.

Inverse roles make conjunctive queries hard.

In Proc. of the 2007 Description Logic Workshop (DL 2007), 2007.

[OCE06] Maria Magdalena Ortiz, Diego Calvanese, and Thomas Eiter.

Characterizing data complexity for conjunctive query answering inexpressive description logics.

In Proc. of the 21st Nat. Conf. on Artificial Intelligence (AAAI 2006),2006.


Conceptual modeling: ER and beyondquerzoni/corsi_assets/1213/... · 2013-06-27 · Introduction to...

Documents

Transcript of Conceptual modeling: ER and beyondquerzoni/corsi_assets/1213/... · 2013-06-27 · Introduction to...