Ordbms

overview of design of ordbms

1. ORDBMS - Ramandeep Kaur Brar

2. ORDBMS A n   object-relational database  ( ORD ), or  object-relational database management system  ( ORDBMS ), is a  database management System  (DBMS) similar to a  relational database, but with an  object oriented  database model: objects, classes and inheritance are directly supported in  database schema  and in the query language.

3. … An ORDBMS supports an extended form of SQL called SQL3 that is still in the development stages. The extensions are needed because ORDBMSs have to support ADT's. The ORDBMS has the relational model in it because the data is stored in the form of tables having rows and columns and SQL is used as the query language and the result of a query is also table or tuples (rows).

4. An example schema of a student relation which ORDBMS supports STUDENT( fname,lname,ID,major,address,dname,location,picture ) Notice : extra attributes "location" and "picture" which are not present in the traditional EMPLOYEE relation of RDBMS. The datatype of "location" is "geographic point" and "picture" is "image".

5. A fully relational database must have the four corner stone characteristies : Base type extension Complex objects Inheritance A rule system

6. Base type extension The ability to create a new base type is necessary in many situations, Both simple and complex ADT is very useful. In this way the design of the application will be smarter and easier. The base type extension facility must have the following characteristics:

7. … Dynamic linking: It must be possible to adhere new user defined base types on the fly. Stopping the database for installing new types, is not acceptable. Client or server activation: A user defined function for a new base type must have the ability for being executed on either the server or the client. Security: A user defined function for a new base type must not be able to corrupt the database.

8. … Callback: User defined functions must be able to use other functions/stored procedures/queries in the same way as other applications. User defined access methods: Adding new access methods must be allowed for the designer of a new base type. It must be possible to add function that Is used by the database engine. Not all data types is well suited for B-trees. Arbitrary length data types: It must be possible to have user defined data types without length restrictions.

9. Complex objects There have to be support of a rich collection of complex types. At least there must be the following complex types: Type constructors Set of Record of Reference A user defined functions must have support for use of complex types. Like user defined types, complex data types must have arbitrary length.

10. Inheritance Data and function inheritance: A major characteristic of ORDBMS is according to support for inheritance. Both data and functions inheritance is necessary. Inheritance of data only apply to datatypes . The most powerful inheritance comes from inheritance of functions. Overloading: it should be possible to specialize the definition of a function to subtypes. Overloading must be supported.

11. … Inheritance of types not tables: types and tables are two different concepts. A table is a container used to had instances of a type. In this way there can be multiple tables of a specific type. Each of tables have the defined inheritance properties. Multiple inheritance: Multiple inheritances must be supported. It is needed In many application. Using a virtual attribute, a user can reference the placement of a function, where there is multiple inheritance.

12. A rule system Rules and triggers must exist in the ORDBMS and should have the following characteristics according to: Events and actions: rules and triggers are very useful in most application systems, they are often used to ensure the consistency of the database. The general form is : on event do action. Rule system must include the capability of executing the action just before or just after the event is processed. On event do action is a generalized trigger. Triggers normally only supports update/insert/delete if necessary.

13. … ii) Integration of rules with inheritance and type extension. The rules system should be totally integrated with the other object relational concepts. iii) Rich execution semantics for rules. The rule system must have ability to support different kinds of actions i.e immediate and same transactions.

14. An ORDBMS Database Design An ORDBMS supports a much better solution. First, we can store the video as an ADT object and write methods that capture any special manipulation we wish to perform. Second, because we are allowed to store structured types such as lists, we can store the location sequence for a probe in a single tuple , along with the video information.

15. … This layout eliminates the need for joins in queries that involve both the sequence and video information. An ORDBMS design for our example consists of a single relation called Probes_AllInfo : Probes_AllInfo ( pid : integer, locseq : location_seq , camera: string, video: mpeg_stream )

16. … This definition involves two new types, location_seq and mpeg_stream . The mpeg_stream is defined as an ADT, with a method display() that takes a start time and an end time and displays the portion of the video recorded during that interval.

17. … Our first query in extended SQL using this display method follows. We now retrieve only the required segment of the video rather than the entire video. SELECT display( P.video , 1:10P.M. May 10 1996, 1:15 P.M. May 10 1996) FROM Probes_AllInfo P WHERE P.pid = 10

18. … Now consider the location_seq type. We could define it as a list type, containing a list of ROW type objects: CREATE TYPE location_seq listof (row (time: timestamp, lat: real, long:real ))

19. … Now consider the locseq field in a row for a given probe. This field contains a list of rows, each of which has three fields. If the ORDBMS implements collection types in their full generality, we should be able to extract the time column from this list to obtain a list of timestamp values and apply the MIN aggregate operator to this list to find the earliest time at which the given probe recorded. Such support for collection types would enable us to express our second query thus:

20. … SELECT P.pid, MIN( P.locseq.time ) FROM Probes_AllInfo P Current ORDBMSs are not as general and clean as this example query suggests.

21. Object identity Now we discuss some of the consequences of using reference types or oids . The use of oids is especially significant when the size of the object is large, either because it is a structured data type or because it is big object such as an image. Although reference types and structured types seems similar, they are actually quite different.

22. For example… Consider a structured type my.theater tuple ( tno integer, name text, address text, phone text) and the reference type theater ref( theater_t ). CREATE TYPE theater_t AS ROW( tno integer, name text, address text, phone text) REF IS SYSTEM GENERATED; There are important differences in this way that database updates affect these two types:

23. Deletion Objects with references can be affected by the deletion of objects that they reference, while reference free structured objects are not affected by deletion of other objects. For example, if the Theaters table were dropped from the database, an object of type theater might change value to null, because the theater_t object it refers to has been deleted, while a similar object of type my_theater would not change value.

24. Update Objects of reference types change value if the referenced object is updated. Objects of referenced-free structured types change value only if updated directly.

25. Sharing versus copying All identified objects can be referenced by multiple reference-type items, so that each update to the object is reflected in many places. To get a similar effect in reference-free types requires updating all ‘copies’ of an object.

26. Nested Relations Motivation: Permit non-atomic domains (atomic  indivisible) Example of non-atomic domain: set of integers or set of tuples Allows more intuitive modeling for applications with complex data Intuitive definition: allow relations whenever we allow atomic (scalar) values — relations within relations Retains mathematical foundation of relational model Violates first normal form.

27. Example of a Nested Relation Example: library information system Each book has title, a set of authors, Publisher, and a set of keywords Non-1NF relation books

28. …

29. 1NF Version of Nested Relation flat-books

30. 4NF Decomposition of Nested Relation Remove awkwardness of flat-books by assuming that the following multivalued dependencies hold: title author title keyword title pub-name, pub-branch Decompose flat-doc into 4NF using the schemas: (title, author) (title, keyword) (title, pub-name, pub-branch)

31. 4NF Decomposition of flat – books

32. Collection Types ARRAY : ordered 1D array with maximum number of elements without duplicates . LIST : ordered collection that allows duplicates. SET : unordered collection without duplicates . MULTISET : unordered collection that allows duplicates.

33. Storage and access methods Since object relational databases store new types of data, ORDBMS implementers need to revisit some of the storage and indexing issues . In particular, the system must efficiently store ADT objects and structured objects and provide efficient indexed access to both.

34. Storing Large ADT and Structured Type Objects Large ADT objects and structured objects complicate the layout of data on disk. User defined ADTs can be quite large. Storage of large ADTs…. As large ADTs need special storage, it is possible to store them on different locations on the disk from the tuples that contain them.  For e.g.  BLOBs (Binary Large Object like images, audio or any multimedia object.)

35. … Structured objects can also be large, but unlike ADT objects, they often vary in size during the lifetime of a database.

36. Query processing ADTs and structured types call for new functionality in processing queries in ORDBMSs. They also change a number of assumptions that affect the efficiency of queries. In this section we look at two functionality issues (user defined aggregates and security) and two efficiency issues (method caching and pointer swizzling ).

37. User-Defined Aggregation Functions Most ORDBMSs allow users to register new aggregation functions with the system. To register an aggregation function, a user must implement three methods which we call initiaIize , iterate, and terminate. The initialize method initializes the internal state for the aggregation. The iterate method updates that state for every tuple seen. The terminate method computes the aggregation result based on the final state and then cleans up.

38. … As an example, consider an aggregation function to compute the second-highest value in a field. the initialize call would allocate storage for the top two values, the iterate call would compare the current tuple's value with the top two and update the top two as necessary, and the terminate call would delete the storage for the top two values returning a copy of the second-highest value.

39. Method security ADTs give users the power to add code to the DBMS; this power can be abused. A buggy or malicious ADT method can bring down the database server or even corrupt the database. The DBMS must have mechanisms to prevent buggy or malicious user code from causing problems.

40. Method caching User-defined ADT methods can be very expensive to execute and can account for the bulk of the time spent in processing a query. During query processing, it may make sense to cache the results of methods, in case they are invoked multiple times with the same argument.

41. … An alternative is to maintain a cache of method inputs and matching outputs as a table in the database. Then, to find the value of a method on particular inputs, we essentially join the input tuples with the cache table. These two approaches can also be combined.

42. Pointer swizzling In some applications, objects are retrieved into memory and accessed frequently through their oids ; dereferencing must be implemented very efficiently. Some systems maintain a table of oids of objects that are (currently) in memory. when an object O is brought into memory, they check each oid contained in 0 and replace oids of in-memory objects by in-memory pointers to those objects. This technique, called pointer swizzling , makes references to in-memory objects very fast. The downside is that when an object is paged out, in memory references to it must somehow be invalidated and replaced with its oid .

43. Indexing New Types One important reason for users to place their data in a database is to allow for efficient index via indexes. Unfortunatly , the standard RDBMS index structures support only equality conditions. An important issue for ORDBMSs is to provide efficient indexes for ADT methods and operators on structured objects.

44.  Query Optimization Challenge:  New indexes and query processing techniques increase the options for query optimization. But, the challenge is that the optimizer must know to handle and use the query processing functionality properly. Solution:  While constructing a query plan, an optimizer must be familiar to the newly added index structures. 

45. For a given index structure, the optimizer must know: WHERE-clause conditions matched by that index. Cost of fetching a tuple for that index.

46. Advantages of ORDBMSs Reuse and Sharing:  The main advantages of extending the Relational data model come from reuse and sharing. Reuse comes from the ability to extend the DBMS server to perform standard functionality centrally, rather than have it coded in each application. Increased Productivity:  ORDBMS provides increased productivity both for the developer and for the, end user.

47. … Support powerful query language: A n ORDBMS support an extended form of SQL referred nested objects, set valued attributed, inclusions of methods/functions and query involving abstract data types. For example: SQL 3, SQL/CLI etc. Support object views: O bject views can be used to build virtual objects from a relational data thereby enabling programmers to evolve existing schemas to support objects. This allows relational and object applications to co-exist on the same database.

48. … Reduce application development time: In ORDBMS object type declarations can be reused via inheritance makes schema definition more natural.

49. Disadvantages of ORDBMSs   Although the ORDBMS provide support for complex objects and new data types for many advanced applications. However, it has many, disadvantages also. The following disadvantages are: Complexity: ORDBMS design is more complicated because we have to consider not only the underlying design consideration of application semanties and dependencies in the relational data model but also the object oriented nature.

50. … Immature: since ORDBMS concepts is new and it still needs to be defined so it is not yet accepted globally. Also it is relative unproven. Increased cost: Because of the variety in data types in ORDBMS and associated operators, efficient storage and access of the data is important which increases the cost.

51. Comparison

52. Thank you