1. Data models Relational, object, and semistructured

2. Types of database applications Queries No queries Simple data Complex data Word processing Payroll GIS CAD/CAM

3. An example schema EMPLOYEE PERSON ADDRESS COMPANY DEPARTMENT departments EMPLOYEEs head_office ISA address boss ceo office

4. A relational schema zCOMPANY(CID, Name, Street, City, CEO) zDEPARTMENT(CID, DeptName, Street, City, Boss) zPERSON(SS#, Name, Street, City) zEMPLOYEE(SS#, Salary) zEMPLOYMENT(CID, DeptName, Emp) COMPANY.CEO << EMPLOYEE.SS# DEPARTMENT. CID << COMPANY.CID EMPLOYEE.SS# << PERSON.SS# EMPLOYMENT.(CID, DeptName) << DEPARTMENT.(CID, DeptName) EMPLOYMENT.Emp << EMPLOYEE.SS#

5. Problems with the schema  Composite attributes do not exist Head office cannot be described directly but is decomposed into Street, City zSet valued attributes do not exist The fact that people are employed at departments is described in an extra table

6. Problems with the schema  Generalisation does not exist The generalisation relationship between EMPLOYEE and PERSON is not explicit  Artificial identifiers required CID is an artificial identifier for COMPANY

7. An SQL query Are there employees who live at the same address, work at departments in London and earn more than 20000? SELECT A.SS#, B.SS# FROM EMPLOYEE AS A, EMPLOYEE AS B, EMPLOYMENT AS EMPL1, EMPLOYMENT AS EMPL2, PERSON AS P1, PERSON AS P2 DEPARTMENT AS D1, DEPARTMENT AS D2 WHERE A.SS# = P1.SS# AND B.SS# = P2.SS# AND P1.Street = P2.Street AND P1.City = P2.City AND A.Salary > 20000 AND B.Salary > 20000 AND EMPL1.SS# = A.SS# AND EMPL2.SS# = B.SS# AND EMPL1.CID = D1.CID AND EMPL2.CID = D2.CID AND EMPL1.DeptName = D1.DeptName AND EMPL2.DeptName = D2.DeptName AND D1.City = London AND D2.City = London

8. An object database schema ADDRESS Street:String City:String PERSON SS#:String Name:String Address:Address EMPLOYEE ISA PERSON Salary:Integer Boss:Employee Departments:{Department} COMPANY Name: String Head office: Address Departments: {Department} CEO: Employee DEPARTMENT Name:String Office:Address Boss:Employee Employees:{Employee}

9. An OO query SELECT e1.ss#, e2.ss# FROM e1, e2 in EMPLOYEE; d1, d2 in DEPARTMENT WHERE e1 in d1.Employees AND e2 in d2.Employees AND e1.Address = e2.Address AND e1.Salary > 20000 AND e2.Salary > 20000 AND f1.Office.City = London AND f2.Office.City = London Are there employees who live at the same address, work at departments in London and earn more than 20000?

10. OODB models zComplex types zTypes and classes zObject identity zInheritance

11. Complex types zBase types String Integer Boolean zConstructors Tuple Set Bag List Array

12. Complex types - an example zCOORDINATE X:Integer Y:Integer Z:Integer zPARKING SPOT Position:COORDINATE Occupied:Boolean zCAR PARK Spots:ARRAY OF PARKING SPOT Personnel:SET OF EMPLOYEE The type constructors can be applied to any type - cf. the relational model

13. Relation schemes and relations SS# Name Age Salary 650101-2288 Eva Svensson 33 25000 750203-3133 Per Jonsson 23 20000 500107-5532 Sven Olsson 47 25000 800515-0044 Pia Eriksson 17 18000 PERSON Relation scheme Relation

14. Types and classes zA type is a time independent description of a set of (base or complex) values zA class has a time dependent extension that is a set of object identifiers

15. Object identity zEvery object is identified by an object identifier zThe object identifier does not change during the life span of the object zTwo different objects with different object identifiers may have the same values OID: 1088732 Name: Simba Age: 11 Weight: 260 OID: 1293301 Name: Simba Age: 11 Weight: 260

16. Object identity The relational model Lion(Name, Age, Weight) (Simba, 11, 260) OO-model LION Name:String Age: Integer Weight: Integer 1088732 OID: 1088732 Name: Simba Age: 11 Weight: 260

17. Object identity Why object identifiers are better than keys: Key attributes not stable Key values not stable Object sharing Object identifiers can be used in relational databases but must be maintained by the users

18. Inheritance The relational model PERSON(SS#, Name, City) ANSTÄLLD(SS#, Salary) EMPLOYEE.SS3 << PERSON.SS# OO model PERSON SS#: String NamE: String CITY: String EMPLOYEE ISA PERSON Salary: Integer Employees are persons

19. Inheritance in the relational model PERSON(SS#, Name, City) EMPLOYEE(Emp#, SS#, Salary) EMPLOYEE.SS# << PERSON.SS# PERSON EMPLOYEE ISA PERSON(SS#, Name, City) EMPLOYEE(SS#, Spouse#, Salary) EMPLOYEE.Spouse# << PERSON.SS# PERSON EMPLOYEE spouse

20. Inheritance in OO databases PERSON SS#:String Name: String City: String EMPLOYEE ISA PERSON Emp#: String Salary: Integer PERSON SS#:String Name: String City: String EMPLOYEE Emp#: String Salary: Integer Spouse: PERSON PERSON EMPLOYEE ISA PERSON EMPLOYEE spouse

21. Extended base types create table slides ( idint, datedate, captiondocument, picturephoto_CD_image); create table landmarks ( namevarchar(30), locationpoint); Find sunsets within a 20 kilometers radius around Sacramento. select id from slides P, landmarks L S where sunset (P.picture) and contains (P.caption, L.name) and L.location |20| S.location and S.name = 'Sacramento';

22. Types of DBMSs Queries No queries Simple data Complex data File systems Relational OO/OR OO

23. Why do we like types? zTypes facilitate understanding zTypes enable compact representations zTypes enable query optimisation zTypes facilitate consistency enforcement

24. Background assumptions for typed data zData stable over time zOrganisational body to control data zExercise: Give an example of a context where these assumptions do not hold

25. Semistructured data Semistructured data is schemaless and self describing The data and the description of the data are integrated

26. Label-value pairs z{name: “John”, tel: 112233, email: “john@123.edu”} Label Value “John” 112233 “john@123.edu” name tel email

27. Nested label-value pairs {name: {first: “John”, last: “Smith”}, tel: 112233, email: “john@123.edu”} “John” “Smith” 112233 “john@123.edu” name tel email first last

28. Duplicate labels {name: {first: “John”, last: “Smith”}, tel: 112233, tel: 445566, tel: 778899, email: “john@123.edu”}

29. Representing variations {person: {name: “John”, tel: 112233, email: “john@123.edu”}, person: {name: “John”, email: “john@123.edu”}, person: {name: “John”, age: 33, email: “john@123.edu”}, person: {name: “John”, tel: 112233, tel: 332211}}

30. Representing relational data Regno Manuf Weight AA11 Volvo 1100 CC33 Volvo 900 EE55 Saab 1000 Ssno City Weight 1122 London 80 2233 Paris 70 3344 Berlin 80 CAR PERSON {CAR: {row: {Regno: “AA11”, Manuf: “Volvo”, Weight: 1100}, {row: {Regno: “CC33”, Manuf: “Volvo”, Weight: 900}, {row: {Regno: “EE55”, Manuf: “Saab”, Weight: 1000}}, PERSON: {row: {Ssno: “1122”, City: “London”, Weight: 80}, {row: {Ssno: “2233”, City: “Paris”, Weight: 70}, {row: {Ssno: “3344”, City: “Berlin”, Weight: 80}}}

31. An object graph person name age child &o1&o2 “Eva” 40 “Abel” 20 This graph represents two people, Eva and Abel, where Abel is the child of Eva. &o1 and &o2 are object identifiers denoting the people Eva and Abel.

32. Representing objects person name age child &o1&o2 “Eva” 40 “Abel” 20 {person: &o1{name: “Eva”, age: 40, child: &o2}, person: &o2{name: “Abel”, age: 20}} An object identifier, such as &o1, before a structure, binds the object identifier to the identity of that structure. The object identifier can then be used to refer to the structure.

33. An exercise &o1&o2 &o3 a b c “hello” d &o1&o2 a &o3&o4 “hello” d d b c

34. Course goals zThe course will familiarise the student with:  database models and query languages with respect to expressiveness and usability  theory and principles of object data bases  semistructured data and its applications  application areas for object and relational databases  interactive and embedded query languages  non-traditional data types and their management in databases

35. Lectures 1. Introduction to data models 2. Query languages for relational databases 3. Models and query languages for object databases 4. Models and query languages for semistructured data, XML 5. Embedded query languages