FEN NOEA/IT - Databases/ORDB1 Object-Relational Databases The Evolutionary Approach to Closing the Gap between Relational Tables and Object Models SQL3 – SQL:99
FEN NOEA/IT - Databases/ORDB2 Or in a picture… ORDB?
FEN NOEA/IT - Databases/ORDB3 Stonebraker’s Matrix COMPLEX QUERY Relational DBMS Object-Relational DBMS NOT COMPLEX QUERY File SystemObject-Oriented DBMS SIMPLE DATACOMPLEX DATA
FEN NOEA/IT - Databases/ORDB4 The Problem 1NF: –All data as simple values in tables This means: –No structure allowed
FEN NOEA/IT - Databases/ORDB5 Approachs Not First Normal Form Databases (NFNF == NF 2 databases): –Fields in tables may be tables –Not implemented in commercial DBMSs SQL:99: –The concept of domains is enhanced allowing attributes to be defined over user defined domains (UDT: User Defined Data Type)
FEN NOEA/IT - Databases/ORDB6 SQL/Object (part of SQL:99) Additions to SQL-92: –Type constructors (User Defined Types: UDT) : ROW type (a tuple or a record) Array type (fixed size, 1 dimensional) –REF type (like OIDs) –Encapsulation (adding operations or methods to types) –Inheritance
FEN NOEA/IT - Databases/ORDB7 Type Constructors Row type: CREATE TYPE AS [ ROW ] ( ); Ex: CREATE TYPE AddrType AS ( StreetVARCHAR(45), CityVARCHAR(25), ZipCHAR(5) );
FEN NOEA/IT - Databases/ORDB8 Type Constructors Array type: Fixed size arrays: Ex: CREATE TYPE CompanyType AS ( CompNameVARCHAR(20), LocationsVARCHAR(20) ARRAY[10] );
FEN NOEA/IT - Databases/ORDB9 Type Constructors A User Defined Type may be used to define new USDs: CREATE TYPE EmployeeType AS ( NameVARCHAR(35), Addr AddrType, AgeINT ); or as type for attributes in definition of tables: CREATE TABLE COMPANY OF CompanyType ( PRIMARY KEY(CompName) );
FEN NOEA/IT - Databases/ORDB10 OIDs and References OIDs are supported: CREATE TABLE COMPANY OF CompanyType ( REF IS CompID SYSTEM GENERATED, PRIMARY KEY(CompName) ); CREATE TABLE EMPLOYEE OF EmployeeType REF IS EmpID SYSTEM GENERATED; Primary key could be used instead
FEN NOEA/IT - Databases/ORDB11 OIDs and References References may used implementing relations (in the ER-sense of the word): CREATE TYPE EmploymentType AS ( Employee REF(EmployeeeType) SCOPE(EMPLOYEE), Company REF(CompanyType) SCOPE(COMPANY), ); CREATE TABLE EMPLOYMENT OF EmploymentType; SCOPE defines the table which may be referenced by the reference attribute
FEN NOEA/IT - Databases/ORDB12 OIDs and References Using references in path expressions: SELECTE.Employee -> Name FROMEMPLOYMENT E WHEREE.Company -> CompName = ‘NOEA’ Usually SQL uses the dot notation to build path expressions: EMPLOYEE.AddrType.Street, but for reference types ‘->’ is used Actual, this is C++ notation
FEN NOEA/IT - Databases/ORDB13 Encapsulation One of three pillars of object-orientation is encapsulation, i.e.: hiding data behind operations or methods Encapsulation is supported by SQL3: CREATE TYPE (, ); What are the two others? USDs and references may be used
FEN NOEA/IT - Databases/ORDB14 Encapsulation Ex: CREATE TYPE AddrType AS ( StreetVARCHAR(45), CityVARCHAR(25), ZipCHAR(5), ) METHOD apartmentNo() RETURNS CHAR(8); METHOD CREATE FUNCTION apartmentNo() RETURNS CHAR(8) FOR AddrType AS EXTERNAL NAME ‘/x/y/AppartmentNo.class’ LANGUAGE ‘java’ Given some algorithm to retrieve apartment number from address Methods are implemented by FUNCTIONs
FEN NOEA/IT - Databases/ORDB15 Inheritance and Polymorphism Are also supported: –All attributes are inherited –An instance of a subtype can be used wherever an instance of the supertype may be used. –Methods may be redefined in subtypes –Dynamic linking is used Here they are: The two other pillars of OO
FEN NOEA/IT - Databases/ORDB16 Further Studies See for instance: –Elmasri chapter 22.4 and –