Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Relational Model Extensions: Simplifying Data Modeling and Enhancing Expressive Power, Slides of Introduction to Database Management Systems

Various extensions to the relational model, including object-oriented (oo) models, complex object models, and more expressive query languages. The extensions aim to simplify data modeling by allowing non-atomic objects as values of attributes and sets as attribute values. They also enhance expressive power by enabling transitive closure, iteration and recursion, and second-order quantification. Topics such as oo/complex object/n1nf model, reification, records, sets, transitive closure, nesting and unnesting, and constraint extensions.

Typology: Slides

2011/2012

Uploaded on 02/12/2012

richiey
richiey 🇨🇦

32 documents

1 / 17

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Extensions of the Relational Model
David Toman
School of Computer Science
University of Waterloo
Introduction to Databases CS348
David Toman (University of Waterloo) Relational Model Extensions 1 / 17
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff

Partial preview of the text

Download Relational Model Extensions: Simplifying Data Modeling and Enhancing Expressive Power and more Slides Introduction to Database Management Systems in PDF only on Docsity!

Extensions of the Relational Model

David Toman School of Computer ScienceUniversity of Waterloo Introduction to Databases CS

Why?

1 To simplify • Data Modeling representing complex values conveniently )records/sets/... as first-class citizens

  • (^) avoiding need for (foreign) key invention 2 To enhance • Expressive Power enabling transitive closure, etc.

OO/Complex Object/N1NF Model

Idea

Allow non-atomic objects as values of attributes. Records

  • • allow attribute values to be (other) records preferably w/o pointers Sets
  • allow attribute values to be sets of (other) objects

Classes of Objects (and language extensions)

Structure Data: Classes C = fA 1 : C 1 ; : : : ; Ak : Ck g

Example

Emp = { name: String, salary: Int, dept: Dept } Dept = { name: String, boss: Emp } Query Extensions:

  • (^) variables range over “objects”
  • attributes can form path expressions

Example

SELECT e.name, e.dept.boss.name FROMWHERE Empe.dept = d, e.salary > e.dept.boss.salary e, Dept d

Records

Are Tuples Objects themselves?

  • if so, what is their “id”? Problems with “oid” invention
  • (^) when are two tuples equal?
  • structural equality may not work (cycles!) ... in general, we can do without.

Sets

how are sets created?

  • • as subsets of the universe/active domain as groups what can we do with them in queries?
  • • (^) variables range over objects of particularadditional operations for/between such values: structure
  • • (^) xf (^) x (^2) j' yg for set membershipfor set-value construction
  • quantifiers can also range over sets

Nesting and Unnesting

What’s the problem with Powerset? ) too many new objects! Nesting/Unnesting

Idea

Only allow construction of sets for which we can create a name fromvalues we already have in the database. ) just like the GROUP BY clause.

Theorem

Queries over flat databases are equivalent to flat queries.

Adding Recursion & Datalog

Can we have some middle ground (PTIME)?

Idea

Allow inductive definitions of relations of the form

  • (^) certain base tuples are in the relation
  • if a tuple is in the relation then another is too
  • (^) nothing else is in the relation Transitive closure revisited:

Example

tc tc((xx ;; yy)) EE ((xx ;; yz )); tc(z ; y)

What Happened to Negation?

Note

The inductive definition must provide a monotone functional We cannot use general negation

  • (^) restrict to positive queries
  • • restrict tomore complex definition of even number of negations minimal model
    • • well-founded semanticsstable-model semantics

Caveat Emptor in SQL

Note

The framework only works for set semantics. In SQL it breaks when:

  • (^) you use duplicate semantics
  • you use arithmetic/string functions/...
  • • you use EXCEPT ...

Constraint Queries

  • (^) for R(x ; y) a set of points; do all the points lie on a straight line? 9 a; b: 8 x ; y:R(x ; y)  y = a  x + b ) is this “safe”? How can we find out a and b?
  • (^) do relations R(x ; y) and S (x ; y) intersect in the plane? 9 x ; y:R(x ; y) ^ S (x ; y) ) imagine R stores “objects” rather than points...

Summary

Extensions allow:

  • (^) (more) convenient modeling of data
  • • (more) expressive queries (more) compact representation

Note

Understanding why things work depends on understanding LOGICAL FOUNDATIONS Also helps with understanding properties,...