1 / 44

7. Object-oriented databases

This article explores the evolution of object-oriented databases and their specific needs in various application areas. It discusses traditional database needs, object data management needs, and different approaches to object data management.

pmays
Télécharger la présentation

7. Object-oriented databases

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 7. Object-oriented databases • Based on an object data model: • Structured (hierarchical) objects • Class hierarchies • Attached functions and procedures(‘encapsulation’) • Comes close to object-oriented (OO) programming. • Used in special application areas. AdvDB-7 J. Teuhola 2015

  2. Evolution of database systems 1) Data management: • Simple data structures and operations 2) Object management • Complex data structures and operations 3) Knowledge management • Complex rule bases and inference systems • More ’intelligence’ AdvDB-7 J. Teuhola 2015

  3. New database applications(needing object management) • Computer-aided design (CAD) and manufacturing (CAM) • Computer-aided software engineering (CASE) • Office automation • Computer-aided publishing (CAP) • Graphics • Scientific and medical applications • Geographic information systems (GIS) • etc. AdvDB-7 J. Teuhola 2015

  4. Traditional database needs • Large storage for persistent (small) records • Query language (simple; ad hoc queries) • Application development support • Distribution • Triggers (procedure invocation on special conditions) • Concurrency (short locks; small locking units) AdvDB-7 J. Teuhola 2015

  5. Traditional database needs (cont.) • Recovery from failures (needed of course in all applications) • Data independence (internal structure can be modified without the user noticing it). • Security from unauthorized use • High transaction throughput, large number of users AdvDB-7 J. Teuhola 2015

  6. Object Data Management Needs • Composite (complex) objects • Unique and stable object identifiers • Efficient references and integrity • Object type hierarchy • Associated procedures • Object encapsulation(hiding implementation details) • Ordered sets (e.g. lists) AdvDB-7 J. Teuhola 2015

  7. Object Data Management Needs (cont.) • Long fields (text, image, audio, video) • Efficient remote access (check-out / check-in) • Long transactions (implying long locks) • Single-user performance • Versioning • Support for schema changes • Programming language interface (C++, Java) AdvDB-7 J. Teuhola 2015

  8. Approaches to object data management (1) Extended relational database systems • Easy migration from existing systems, taking advantage of their benefits(relational datamodel and query language) • Extensions: • Procedures • Object identity • Type hierarchy • Long fields AdvDB-7 J. Teuhola 2015

  9. Extended features in PostgreSQL • User-defined datatypes: • CREATE TYPE typename(...) • User-defined functions • CREATE FUNCTIONfname(params) RETURNSreturntypeAS . . . LANGUAGE progr.language • Array-valued attributes, e.g. • integer[ ], text[ ] [ ] • Geometric datatypes and operations: • Point, line, box, circle, polygon, etc. • intersection, overlap, center, area, etc. AdvDB-7 J. Teuhola 2015

  10. Extended features in PostgreSQL (cont.) • Inheritance: Subclass is defined as a table inheriting attributes from the parent table and adding some new attibutes, e.g. CREATE TABLE person( pid int, name text, address text);CREATE TABLE student( major_subject text, study_points int) INHERITS (person); AdvDB-7 J. Teuhola 2015

  11. Approaches to object data management (2) OO database programming languages • Extension of e.g. C++, Java, or Smalltalk, to provide persistence, concurrency control, etc. • Programming and query language execute in the same environment, share the same type system and workspace. • No big distinction between (persistent) db objects and (transient) program objects. AdvDB-7 J. Teuhola 2015

  12. Approaches to object data management (3) Object-relational mapping • An auxiliary package for performing the mapping from the object model to a relational schema (and back). • Solves the so called impedance mismatch between the models. • May suffer from performance problems • Example systems: • Entity Framework (Microsoft) • Hibernate (open source) AdvDB-7 J. Teuhola 2015

  13. Java and persistence • JDO (Java Data Objects) • Specification of object persistence in Java • Ordinary objects can be made persistent(exist between program invocations) • Persistent classes need not implement any special interfaces nor extend some inherited classes • Object persistence specified in external XML metafiles • Vendor-written enhancers modify the compiled Java class files to make them persistent. • Platforms offered by vendors to realize persistence: simple files, RDBMS, ODBMS • Many implementations exist (also open-source) • Query language JDOQL neutral to the underlying db AdvDB-7 J. Teuhola 2015

  14. Java and persistence (cont.) • JPA (Java Persistence API) • Developed for Enterprise Java Beans (EJB),works also with Java Standard Edition (SE) • Tools: javax.persistence package • Based on an object-relational mapping • Entity classes correspond to relations. • Object-relational metadata specified either by using annotations, or a separate XML descriptor file • JPQL: Java Persistence Query Language,resembles SQL AdvDB-7 J. Teuhola 2015

  15. Java and persistence (cont.) • Db4o • A true OODBMS engine • Simple interface • Query language = Java itself AdvDB-7 J. Teuhola 2015

  16. Object-oriented abstractions • Structural abstractions: • Classification/instantiation • Aggregation • Generalization/specialization • Association • Behavioral abstraction: • Encapsulated procedures AdvDB-7 J. Teuhola 2015

  17. Object identifiers • Motivation: Shortcomings of value-based primary keys in the relational model. • System-generated, short, stable. • No logical meaning, not shown to users. • Used as references (‘handles’) between objects • Implementation alternatives: • Object address as id (efficient; stability problems) • Location-independent surrogate (less efficient, stable) AdvDB-7 J. Teuhola 2015

  18. Attributes (properties, features) = instance variables in OO languages (a) Simple attributes: • Literal values (numbers, characters) • Not considered ‘objects’ (b) Complex attributes: • References to represent relationships • Collections of simple/reference/collection attributes • Derived attributes, defined by procedures AdvDB-7 J. Teuhola 2015

  19. Binary relationships • Reference attribute points to one-valued side • Reference set attribute points to many-valued side (pointer array / list) • References appear as pairs, called inverse attributes; they must be maintained intact.Note the redundancy! • Physical implementation alternatives:Collocation, links, indexing AdvDB-7 J. Teuhola 2015

  20. N-ary relationships • A separate relationship object type must be created. • Also binary M:M relationships having a relationship attribute require a separateobject type. • Creates an extra step in the ‘navigation’through relationships. AdvDB-7 J. Teuhola 2015

  21. Composite objects • Objects consisting of components, subcomponents, etc.(IS-PART-OF relationships). • Aggregation: • Grouping of attributes to (simple) objects • Grouping of objects to composite objects • Components may be existence-dependent on the composite object. AdvDB-7 J. Teuhola 2015

  22. Composite objects as nested relations DEPARTMENTS DNO MGR PROJECTS PNO PNAME EMPLOYEES ENO ENAME SALARY 11 ABC 111 Smith 20001 Ford 112 Brown 3000 12 XYZ 122 Blake 2500 211 Taylor 40002 Rose 21 PQR 212 Young 2000 213 Baker 3000 AdvDB-7 J. Teuhola 2015

  23. Recursive structures • Components are from the same class as the parent object. • The depth of the structure is variable and not restricted. • E.g. parts assembly (‘bill-of-materials’) • Processing requires some form of recursion also in the query language (e.g. for the computation of transitive closure);UNION ALL in SQL:2003 AdvDB-7 J. Teuhola 2015

  24. Procedures • ‘Behavioral’ object-orientation • ODMSs usually provide a computationallycomplete language for database accessing. • Encapsulation: Information hiding principle(public/private procedures). • Types of procedures: constructors, destructors, accessors, transformers. • Active data: Derived data, rules, triggers, agents. AdvDB-7 J. Teuhola 2015

  25. Types  classes • Intent: Structure and behavior of similar objects described in the class. • Extent: Instances of the class. • Class object: Meta-object with schema-level properties (attribute names, member creation, default values, etc.) • Literal types: Predefined (numbers, strings, Boolean, etc.) AdvDB-7 J. Teuhola 2015

  26. Bases for class hierarchies • Generalization/specialization:Additional attributes/methods for subclass. • Specification:Subset satisfying a predicate. • Classification:List of subsets (same structure and methods). • Implementation: Different implementationfor the subclass. AdvDB-7 J. Teuhola 2015

  27. Class hierarchy concepts • Inheritance: Attributes and methods of the superclass apply to the subclass. • Overriding: Subclass redefines inherited features of the superclass. • Multiple inheritance: • Several parent classes • Difficult to implement; possible ambiguities • Rare in practice AdvDB-7 J. Teuhola 2015

  28. Clustering of objects • Objects needed together should be stored physically close together. • Ways of clustering: • Composite objects as units • Objects connected by relationships • Instances of an object class • Objects sorted by an attribute (+ clustering index) • Custom: At object creation, define another object, close to which the new one should be put. AdvDB-7 J. Teuhola 2015

  29. Object db standardization • Purposes: • Portability • Interoperability • Object Data Management Group (ODMG): • Object model • Object definition language (ODL) • Object query language (OQL) • Bindings to C++, Java and Smalltalk AdvDB-7 J. Teuhola 2015

  30. Object Definition Language (ODL) example class Student extends Person(extent students) { attribute int matr_number;relationship Subject majors_ininverse Subject::has_majors;relationship set<Grade> passed_coursesinverse Grade::student;float grade_point_average();void change_major(in string subject_name)raises(invalid_subject_name); } AdvDB-7 J. Teuhola 2015

  31. OQL examples • students; • comp_science_dept.chair.rank; • select s.matr_nofrom s in students; • select distinct s.majors_in.namefrom s in studentswhere s.grade_point_average > 2; AdvDB-7 J. Teuhola 2015

  32. OQL examples (cont.) • select struct (name: struct (last_name: s.name.lname, first_name: s.name.fname), grades: select c.gradepointsfrom c in s.passed_courses)from s in studentswhere s.majors_in.name = ‘Comp. science’ • (select s.namefrom s in studentsorder by s.grade_point_average desc) [0:2] AdvDB-7 J. Teuhola 2015

  33. OQL examples (cont.) • select subject_name, avg_gpa:avg (select p.s.grade_point_averagefrom p in partition)from s in studentsgroup by subject_name: s.majors_in.namehaving count(partition) > 100; Note: Keyword ’partition’ represents one group at a time. AdvDB-7 J. Teuhola 2015

  34. Object-relational databases • Extensions of traditional relational databases to better support new application areas. • Main goals: to support custom data types and methods (not complete object-orientation). • Most big vendors (Oracle, IBM/DB2, Microsoft/ SQL Server) have included object extensions, but implementations differ. • SQL has been extended in several steps:1986, 1989, 1992, 1999, 2003, 2006, 2008;object-relational features included since 1999. AdvDB-7 J. Teuhola 2015

  35. SQL:2003 parts Part 1: SQL/Framework: A non-technical description Part 2: SQL/Foundation: Core ADT specification Part 3: SQL/CLI: Call Level Interface Part 4: SQL/PSM: Persistent stored modules Part 9: SQL/MED: Management of External Data Part 10: SQL/OLB: Object Language Bindings Part 11: SQL/Schemata: Information and Definition Schemas Part 13: SQL/JRT: Java Routines and Types Part 14: SQL/XML: XML-related specifications Note: Parts 5, 6, 7, 8, and 12 do not exist. AdvDB-7 J. Teuhola 2015

  36. Example of UDT (user-defined type) in SQL:2003 CREATE TYPE PersonType AS (ssn CHAR(11),name VARCHAR(40),address VARCHAR(50),bdate DATE)INSTANTIABLE /* Instances can be created */NOT FINAL /* Subtypes can be created */REF IS SYSTEM GENERATED /* Object ID */INSTANCE METHOD age() RETURNS INTEGER;CREATE INSTANCE METHOD age() RETURNS INTEGER FOR PersonType BEGIN ... RETURN ... END; AdvDB-7 J. Teuhola 2015

  37. Example of type hierarchy in SQL:2003 CREATE TYPE TeacherType UNDER PersonType AS ( grade VARCHAR(10),salary DECIMAL(8, 2),taxPercent DECIMAL(5,2))INSTANTIABLENOT FINALINSTANCE METHOD netSalary() RETURNS DECIMAL(8, 2);CREATE INSTANCE METHOD netSalary () ...; AdvDB-7 J. Teuhola 2015

  38. Ways of creating tables in SQL:2003 (a) On the basis of a UDT: CREATE TABLE People OF PersonType ( ... REF IS pid SYSTEM GENERATED); (b) A list of columns; column type can be a UDT (other additional columns can be defined): CREATE TABLE People ( person PersonType, education VARCHAR(100), experience VARCHAR(200) ... ) (c) A subtable based on a subtype (no additional columns allowed): CREATE TABLE Teachers OF TeacherType UNDER People; AdvDB-7 J. Teuhola 2015

  39. Reference types in SQL:2003 • A column as a reference to another table:CREATE TABLE Dept ( ... managerID REF(PersonType) SCOPE People REFERENCES ARE CHECKED ON DELETE CASCADE; ) • Using references in path expressions (called ‘dereferencing’; operator ‘->’; replaces a join)SELECT d.managerID -> name AS managerNameFROM Dept dWHERE d.dName = ’Marketing’ AdvDB-7 J. Teuhola 2015

  40. Row types in SQL:2003 • Sequence of <field name & type> pairs • Represents table rows, or subsets of columnsin a row:CREATE TABLE People ( ssn CHAR(11), addr ROW (street VARCHAR(30), no VARCHAR(10), post ROW (zip NUMERIC(5), district VARCHAR(20)))) AdvDB-7 J. Teuhola 2015

  41. Collection types in SQL:2003 • Enable the representation of nested tables. • Type constructors for collections of other types: • ARRAY = 1-dim. array, given number of elements • LIST = ordered collection, allows duplicates • MULTISET = unordered collection, allows duplicates • SET = unordered collection, no duplicates • The element type may be a predefined type, UDT, row type, or another collection, but it must not be a REF nor contain a REF. • Several operators are defined for collections. AdvDB-7 J. Teuhola 2015

  42. Persistent stored modules in SQL:2003 • SQL:2003 is computationally complete. • Routines can be stored and executed from the database. Some provided statements: • Assignment (=) • IF ... THEN ... ELSE ... END IF; • CASE ... WHEN ... WHEN ... END CASE; • FOR ... AS SELECT ... FROM ... WHERE ... DO ... END FOR; • WHILE ... DO ... END WHILE AdvDB-7 J. Teuhola 2015

  43. Triggers in SQL:2003 • Tool to implement active features in databases • Automatic execution (’firing’) when a giventable update takes place. Otherwise like an SQL routine without arguments. • Syntax:CREATE TRIGGER <name> BEFORE | AFTER <event> ON <table> ... WHEN (<condition>) <body> AdvDB-7 J. Teuhola 2015

  44. QUERIES Simple Complex D Simple File Relational A systemdatabaseT A Complex Object Object-relational database database Rough recommendation AdvDB-7 J. Teuhola 2015

More Related