170 likes | 316 Views
Object-Relational Databases. The Evolutionary Approach to Closing the Gap between Relational Tables and Object Models SQL3 – SQL:99. ORDB?. Or in a picture…. Stonebraker’s Matrix. The Problem . 1NF: All data as simple values in tables This means: No structure allowed. Approachs.
E N D
Object-Relational Databases The Evolutionary Approach to Closing the Gap between Relational Tables and Object Models SQL3 – SQL:99 NOEA/IT - Databases/ORDB
ORDB? Or in a picture… NOEA/IT - Databases/ORDB
Stonebraker’s Matrix NOEA/IT - Databases/ORDB
The Problem • 1NF: • All data as simple values in tables • This means: • No structure allowed NOEA/IT - Databases/ORDB
Approachs • Not First Normal Form Databases (NFNF == NF2 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) NOEA/IT - Databases/ORDB
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 NOEA/IT - Databases/ORDB
Type Constructors • Row type: CREATE TYPE <Row-Type-Name> AS [ ROW ] (<ComponentDeclarations>); • Ex: CREATE TYPE AddrType AS ( Street VARCHAR(45), City VARCHAR(25), Zip CHAR(5)); NOEA/IT - Databases/ORDB
Type Constructors • Array type: Fixed size arrays: • Ex: CREATE TYPE CompanyType AS ( CompName VARCHAR(20), Locations VARCHAR(20) ARRAY[10] ); NOEA/IT - Databases/ORDB
Type Constructors • A User Defined Type may be used to define new USDs: CREATE TYPE EmployeeType AS ( Name VARCHAR(35), Addr AddrType, Age INT ); • or as type for attributes in definition of tables: CREATE TABLE COMPANY OF CompanyType ( PRIMARY KEY(CompName) ); NOEA/IT - Databases/ORDB
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 NOEA/IT - Databases/ORDB
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 NOEA/IT - Databases/ORDB
OIDs and References • Using references in path expressions: SELECT E.Employee -> Name FROM EMPLOYMENT E WHERE E.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 NOEA/IT - Databases/ORDB
What are the two others? 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 <TypeName> ( <Component-list>, <declaration of EQUAL and LESS THAN>, <declaration of other methods>, ); USDs and references may be used NOEA/IT - Databases/ORDB
Encapsulation Given some algorithm to retrieve apartment number from address • Ex: CREATE TYPE AddrType AS ( Street VARCHAR(45), City VARCHAR(25), Zip CHAR(5),) METHOD apartmentNo() RETURNS CHAR(8); METHOD CREATE FUNCTION apartmentNo() RETURNS CHAR(8) FOR AddrType AS EXTERNAL NAME ‘/x/y/AppartmentNo.class’ LANGUAGE ‘java’ Methods are implemented by FUNCTIONs NOEA/IT - Databases/ORDB
Inheritance and Polymorphism Here they are: The two other pillars of OO • 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 NOEA/IT - Databases/ORDB
Further Studies • See for instance: • Elmasri chapter 22.4 and • http://www.oracle.com/technology/software/index.html NOEA/IT - Databases/ORDB