From: pb@fc.ul.pt (Paulo Batista)
Subject: Re: Object-oriented RDBMS
Organization: Dept. Informatica - Fac. Ciencias da Universidade de Lisboa
Date: Mon, 14 Dec 1992 13:32:06 GMT

In article <1992Dec8.205346.1675@oracle.us.oracle.com> rchiluvu@oracle.com  
(Raju Chiluvuri) writes:
> 
> 
> 
> 		I appreciate your opinion on the concept presented in
> 	the following document.
> 
> 		I believe, It is relatively simple to incorporate the
> 	concept into RDBMS with the expertise available to day in the
> 	Object-oriented technology and I'm excited about the advantages
> 	I see, of the Object-oriented RDBMS.
> 
> 		I welcome your valuable comments and criticism on the
> 	concept. Any information, If exists, on the research or products
> 	based on the concept is appreciated.
> 
> 	Thanks In Advance,
> 
> 	Raju.
> 
> 
> 	
> ========================================================================
> 	 +----------------------------------------------------+
> 	 |  O.O.R.D.B : Object Oriented Relational Database.  |
> 	 +----------------------------------------------------+
> 			--Raju Chiluvuri.
> 				Home Ph # (408) 733 - 5775
> ========================================================================
>      Combination of the best and the most elegant concepts of both
>      the Relational technology and the Object Oriented technology.
> ========================================================================
> 	The objective of the document is to express my ideas about
> the improvements we can make to RDBMS. This short document briefly
> discuses the philosophy of how to incorporate object oriented
> technology into RDBMS.  Although it is not required, knowledge of C++
> (Object Oriented) will be help full in understanding this document.
> 
> 	If the modifications discussed in this document are
> incorporated in to the RDBMS, I believe RDBMS will become simple,
> flexible and user friendly for users and developers of applications
> and also provide very high level modular development environment
> for RDBMS developers.
> ========================================================================
> OORDB model:
> 
> +-----------------------+
> |		        |
> |  Application or API   |
> |		        |
> |   +-------------------+  ----------------------------------
> |   |		        |  * Data Conversion & Interpretation.
> |   | O.O. Interface.   |  * Object/Data Presentation.
> |   |		        |  * Object/Data Operations & Comparison.
> |   +-------------------+  ----------------------------------
> |   |		        |  * Data Storage & Retrieval(Executing SQL)
> |   | Data Base Engine. |  * Security & data integrity.
> |   |		        |  * Error recovery etc.
> +---+--------+----+-----+  ----------------------------------
> 	     |    ^
> 	     |    |
> 	     v    |
> 	     .......
> 	    +.......+
> 	    |	    |
> 	    |  DATA |
> 	    |Storage|
> 	    |	    |
> 	    |.......|
> 	    +.......+
> ========================================================================
> 	The database should be divided logically(not physically) in
> to two layers.
> 	(1).	The data base engine layer and 
> 	(2).	The object oriented(OORDB) interface layer.
> --------------------------------------------------------------------
> 
> 	In current RDBMS, all the objects data representation and
> operation procedures are all hard coded in to the RDBMS. The RDBMS
> is not providing any method for the application developer to define
> abstract data objects. Adding this capability with out effecting
> any transaction processing, data accessing(object schemas) power of
> RDBMS (relational model), is the function of the Object Oriented
> Interface.
> 
> 	The SQL statements are executed/interpreted by the data
> base engine. The SQL statements are divided in to four types.
> 
> Queries:
> 	Ex: SELECT ENAME, MGR
> 		FROM EMP
> 		WHERE	(MGR = 234) or (MGR = 123);
> 	To process Queries RDBMS needs procedure to compare objects.
> The developer of the object should provide the procedures(Pointers
> to functions and expected parameter format description) that performs
> defined search operations.
> 
> Data Manipulation Statements:
> 	Ex: INSERT, UPDATE, DELETE etc.
> 		INSERT INTO emp
> 			VALUES(2, 'GORE', 'VICE-PRESIDENT',
> 				1, '20-JAN-93',1000,500,10);
> 
> 	DELETE FROM emp WHERE name IN ('BUSH', 'QUYLE');
> 
> 	To process the SQL statements, RDBMS requires procedures to
> validate(parse/check) the external object data (given in external
> format) and convert to internal representation of the object.
> Ex: If the object is date and given as a string "20-JAN-93".  The
>     RDBMS needs a function that converts this to internal data
>     representation format.
> 	
> Data Definition Statements:
> Data Control Statements:
> 
> 	CREATE TABLE emp
> 	    (	empno		NUMBER NOT NULL,
> 		job		CHAR(10),
> 		mgr		NUMBER(5),
> 		hiredate	DATE,
> 		sal		NUMBER(9,2),
> 		comm		NUMBER(9,2),
> 		deptno		NUMBER(5)	)
> 
> 	To build a table with objects RDBMS needs the size of fields
> and object type of fields and its properties.
> 
> 	If developer provides all the information RDBMS required to
> execute SQL statements for new objects, There is no reson RDBMS can
> not support the new object just like any build in data types.
> 
> 	The Object Oriented Interface should provide simple method
> to define new objects for developers. He should provide all the 
> required information for RDBMS to process the new objects just like
> any other build in object types.
> 
> --------------------------------------------------------------------
> 	The RDBMS should provide the application developer the
> capability of defining new object and how an object physically
> represented in it's field.  In addition the developer should be
> able to define what kind of operations are allowed on the new
> object and the procedure how the operations should be performed.
> 
> 	To achieve this goal the RDBMS should be modified, so that,
> it recognizes new objects and it should use the information provided
> for the object to perform any requested operations on the object.
> That is, If RDBMS need to perform an operation on the new object, it
> should use the information provided for the object to determine that
> the operation is allowed and use it to perform the operation.
> 
> 	The physical data in a DB field is nothing but a description
> (or representation) of an object. The developer conceptualizes the
> relationship between the object and physical data representation of
> the object. He should have knowledge of properties and behavior of
> the object to define the object specific operations and the procedure
> how the operations should be carried out on the physical data.
> 
> 	To make RDBMS developer life easy, In early phases of OORDB:
> (1). It can have some restrictions like the user defined objects can
>      not be used to create indexes.
> (2). The RDBMS can keep the build in data types as it is.
> 	
> --------------------------------------------------------------------
> Note:	For an example look at the section titled "The scenario of
> 	how OORDBMS works".
> ========================================================================
> 
> The Data Base Engine:
> ---------------------
> 
> 	The field or column data type of the data base table can be
> divided in to two categories.
> 1). fixed size types (Ex: "DATETYPE", "INTEGER" etc. whose size is
>     predefined and fixed always.) and
> 2). The variable size types.
> 
>     Data base engine should need the following information to do its
> job, for every data/object type defined as a column in the data base.
> 
> 1). If the type is fixed size, the size in bytes.
> 2). If the type is not fixed  size, maximum allowed size in bytes.
> 3). If "=" (equals to) operation is allowed on the object, It needs
>     a pointer to a function that takes two objects as parameters and
>     returns 1 or 0 to indicate True or False.
>     Note: Most of the cases bit/byte wise comparison is enough. But
> 	for some objects user may use some equality rules.
> 4). If "<","==" and ">" operations are allowed on the type, It needs
>     a pointer to a function that returns positive, zero and negative 
>     values respectively.
> 5). If user defined operations like "LIKE" are allowed on the type
>     (with or with out wild cord like %), It needs a pointer to a
>     function that performs the operation and returns the result etc.
> 
> 	Notice this information is enough for each object used in
> database table field(column) for database engine to perform search,
> store and retrieval operations.
> 
> 	When user defining a new object type, He should provide all
> the required procedures code to process all the necessary operations
> on the object and link into the OORDBMS.
> 
> 	The Object-oriented interface should provide the RDBMS, a
> list of the user defined objects for the application and for each
> of the object all the information required by the RDBMS.
> 
> Example:
> 	For each new object defined in Object-oriented interface, it
> builds a structure with the following data and pass it to RDBMS.
> 
> typedef struct
>     {
>      short type_code;	     /* A code assigned to the type.*/
>      char  type_name[16];   /* The name of the type. */
>      short size;	     /* -1; If type is not of fixed size. */
>      int   (*is_same_func)();  /* NULL; If "==" is not allowed. */
>      int   (*compare_func)();  /* NULL; If comparison not allowed.*/
>      operation_info operation_abc; /* Look below. */
> 	:	:	:	:	
> 	:	:	:	:	
> 	:	:	:	:	
>     }type_data_handlers;
> typedef struct
>     {
> 	char operation_name[16]; /* Operation name. Ex: LIKE. */
> 	short operation_type;    /* This may be used to categorize
> 		the operation to determine how the operation should
> 		be performed. Ex: Unary, Binary etc. */
> 	int (*operation_procedure)(); /* A pointer to the function,
> 				which performs the operation. */
> 	short result_type;
> 	short parameter1_type;
> 	short parameter2_type;
> 	:	:	:	:	
> 	:	:	:	:	
>     } operation_info;
> 
> The database engine saves the list of the type/object structures and
> uses the information and handlers in them, to process SQL statements.
> 
> Note: The external data is converted by OORDB interface into internal
>       data representation format for storage in the object field and
>       internal data is converted by OORDB interface to external data
>       format for presentation.
> 
> The Object Oriented Interface:
> ------------------------------
> 
> 	The object oriented interface should provide simple method
> for the developer to define new objects. It should also enforce the
> completeness and consistence of the object information provide by
> the developer.
> 
> 	The Object Oriented Interface provides all the required
> information (the object data representation and the operation
> procedures) about the object to the data base engine and also
> performs some operations on objects on the requests of user or data
> base engine.
> Note:	Most of the object operation procedures are executed at the
> 	Data Base engine level.
> 
> * Data Interpretation & Conversion.
> 	If data is received from externally, It interprets the data
>     and converts in to internal format to store in Database table.
>     Note: The data in column fields are a representation of an object
> 	like DATE. When user assigning a value "6-SEP-88" to a date 
> 	field, The SQL reads the ascii string and converts into
> 	internal representation of the date and stores in the field.
> 
> * Object/Data Presentation.
> 	If data is obtained from the data base table, it converts
>     into proper format for presentation.
>     Note: To display a field, the database reads the internal data
> 	and converts into a string for presentations(in ascii mode).
> 	The presentation procedure is dependent on the object type.
> 	(It also dependent on user request, because same object can
> 	be presented in several ways.)
> 
> * Object/Data Operations & Conversion.
> 	It provides object operation functions like add, multiply and
>     subtraction etc.. It also provides type conversion functions, If
>     type conversion is allowed.
> 
> ========================================================================
> 
> AN EXAMPLE AND STARTING POINT:
> 
> 	The architecture of the X11 server, the X11 library, the Xt
> library and the Motif objects. Although this is not very good match
> to our needs the work done in the following sections could help us
> in pointing the right direction.
> 1. The Xt library services to build graphical objects on top of raw
>    primitive X11 library.
> ========================================================================
> OBJECT examples:
> 
> 	consider an object "pie" chart. The data representation of a
> income of a department in a company.
> 
> typedef struct
> 	{ 
> 		int total_income; 
> 
> 		int sales_share;
> 		int services_share;
> 		int consultancy_share;
> 	} income_pie_chart;
>  	In this case RDBMS engine needs 4*4 bytes fixed size storage
> to store the data. The data is interpreted and presented by Object
> Oriented interface. The presentation function draws the proper pie
> chart object using data in the column.
> Note: User can also implement operation "+" in the interface. This
>       can be used to find the total pie chart of all departments.
>       User can also define "/" operation to find average income pie
>       of departments. These operations may take different objects
>       and return new object, The Object-oriented interface should
>       provide the information to RDBMS to process SQL.
> 
> 	consider an other object "pie" chart. The data representation
> of an expenditure of a department in a company. This is more general
> "pie" chart with variable number of components.
> 
> typedef struct
> 	{ 
> 		int	expenditure_item_count; 
> 		int	total_expenditure; 
> 
> 		char	expenditure_title1[16];
> 		int	expenditure1;
> 		char	expenditure_title2[16];
> 		int	expenditure2;
> 		char	expenditure_title3[16];
> 		int	expenditure3;
> 		:	:	:
> 		:	:	:
> 		:	:	:
> 		:	:	:
> 	} income_pie_chart;
>  	In this case RDBMS engine needs variable size storage to
> store the data. The size is calculated by Object Oriented Interface
> using the value of "expenditure_item_count". The data is interpreted
> and presented by Object Oriented interface.
> 
> 	One object can have several presentation functions. The DBMS
> uses proper presentation function depending on presentation control
> parameter(s). Also object can have several operation procedures for
> same operation(like operator overloading in C++). The DBMS uses
> proper procedure depending on operands.
> 
> ========================================================================
> (1).	OORDB:  This logical separation provides a solid simple
> 	flexible base and direction for engineers and VARs to
> 	develop next generation OORDBMS tools, utilities and
> 	applications that better suite customers real world needs.
> 
> (2).	Objects are building blocks of more complex applications.
> 	Well designed and implemented objects(the abstract nature
> 	of object) will provide reliable high level design and
> 	building blocks for more complex tools and applications.
> 
> (3).	RDBMS should provide a rich commonly used set of objects as
> 	part of the base RDBMS product. RDBMS also should provide a
> 	simple method for developers to define their objects and
> 	test the objects off line and integrate them in to RDBMS.
> 
> 	(Note: These are the application specific objects defined by
> 	developers to use as building blocks in their applications.
> 	For example, in an Biological application an animal can be
> 	defined as an object and could support several operations
> 	to search or group them using common properties.)
> 
> (4).	This provides modular development for OORDBMS developers.
> 	That is, it allows the 2 layers can be modified and upgraded
> 	independently, as long as their interface is consistent.
> ======================================================================
> User Defined Operations:
> ------------------------
> 
> 	This document is not intended to provide specific details
> of OORDBMS, but to explain briefly the general theory we can use
> in implementing OORDBMS (with examples).  This resulted in some
> inconsistences.
> 
> 	For new object depending on the nature of the object the 
> developer provides several operations and procedures.
> 
> Example:
> 	Consider a simple Text Retrieval system. The Text field of a
> column in data base is defined as user defined object type "DOCUMENT"
> of variable size up to "65,535(LONG)". This object supports an user
> defined operation "LOOK_FOR_KEYS".
> 
> User can execute the following SQL statement for the following table.
> 
> SQL> DESC  DOCUMENT_TABLE
> 	-------------------     ---------------------
> 	Field Name		Type
> 	-------------------     ---------------------
> 	DOC_NUM			NUMBER
> 	WRITER_NAME		CHAR(32)
> 	DOC_DATE		DATE
> 	DOC_TITLE		CHAR(255)
> 	DOC_CONTENTS		DOCUMENT     /* User defined Obj.*/
> SQL>
> SQL> SELECT writer_name, doc_data, doc_title
> 	FROM document_table
> 	WHERE (writer_name LIKE '%RAJU%') and
> 	    (doc_date > (SYSDATE - 30)) and
> 	    (DOC_CONTENTS %LOOK_FOR_KEYS ('URGENT' or 'IMPORTANT'));
> SQL>
> 
> 	Note the symbol "%" is directive to the SQL/DBMS to indicate
> that the following string is an user defined operation. (This % may
> be optional to simplify the implementation of SQL extension). RDBMS
> calls the proper handler function for "LOOK_FOR_KEYS" operation with
> the information "('URGENT' or 'IMPORTANT')". The function parses the
> data, stores the search information and performs the search.
> 
> 	User defined object names and user defined operation names on
> the object are incorporated in to SQL. The Object-oriented interface
> provides all this information. A method how it can be done is briefly
> discussed in the section titled "The scenario of how OORDBMS works".
> 
> Note:	In C++ the object should be defined before using the object
>     or object operations in a source file. The compiler uses this
>     information in object definition to compile the statements,
>     which contains the object operations. In OORDBMS the object
>     information is provided in advance to Object interface and SQL
>     interpreter uses this information when executing SQL statements.
> 
> Note::	It is good practice to assign priority to search operations.
> 	In the above example obviously the "%LOOK_FOR_KEYS" is very
> 	slow. So it should be assigned lowest priority, so that DBMS
> 	can perform this operation last, if the ROW already satisfied
> 	"(writer_name LIKE '%RAJU') and (doc_date > (SYSDATE-30))".
> ======================================================================
> Object Information ::
> 
> 	The well defined objects are the objects modeled ofter real
> life objects with real life operations. Objects should be easy to
> understand and use.
> 
> 	To use any object in SQL statements, The User needs full
> description of the object. This includes size, operations allowed to
> perform on the object and the presentation methods.  It is also help
> full, If some convenience functions are provided for the object for
> commonly performed procedures.
> 
> --------------------------------------------------------------------
> Example I:
> 	The following is a sample example DESCRIPTION for the object
> 	"DOCUMENT".
> 
> Type Name:	DOCUMENT
> Size	 :	Variable Size. Maximum Limit is 65,535 bytes.
> 	
> Operations:
> 	JOIN:
> 		doc1 JOIN doc2: The contents of doc2 is added to the
> 		end of doc1.
> 
> Comparison Operations:
> 	LOOK_FOR_KEYS
> 		%LOOK_FOR_KEYS ('KEY1' or 'KEY2' ....)
> 	THESAURAL_RELATION
> 		%THESAURAL_RELATION ('WORD1' or 'WORD2' ....)
> 	WORD_PROXIMITY
> 		%WORD_PROXIMITY ('WORD1' ....)
> 	PHRASE_SEARCH
> 		%PHRASE_SEARCH .............
> 	SYNONYM_SEARCH
> 		............................
> Convenience Routines:
> 	document_top(doc):	This function just gets only the
> 				first paragraph of the document.
> 	document_page(doc,page_no): This function just gets only
> 			one page of data given in "page_no".
> 	print_document(doc,file): This function prints the document
> 				to the file given in "file".
> 		:	:	:	:	:
> 		:	:	:	:	:
> 
> Presentation Control:
> 		None.
> 
> Restrictions And Limitations:
> 		:	:	:	:	:
> 		:	:	:	:	:
> 
> --------------------------------------------------------------------
> Example II:
> 	The following is a sample example DESCRIPTION for the object
> 	"SCIENTIFIC_TIME".
> 
> Type Name:	SCIENTIFIC_TIME
> Size	 :	8 bytes.
>     typedef struct
>       {
> 	int	seconds;	/* Maximum 2,000,000,000 */
> 	int	neno_seconds;	/* Maximum 999,999,999. */
>       }scientific_time;
> 	
> Operations:
> 	+, -, *, /,=:
> 
> Comparison Operations:
> 	==, <=, >=, != .....
> Convenience Routines:
> 		:	:	:	:	:
> 		:	:	:	:	:
> 
> Presentation Control:
> 	print_time(time,format): This function prints the time in
> 				the given format.
> 	update_display(time,display): This function updates the
> 				given graphical display object.
> 	If no presentation format is given, It prints the time
> 	using default print function provided for the object.
> --------------------------------------------------------------------
> Example III:
> 	The following is a sample example DESCRIPTION for the object
> 	"TELEPHONE_NO".
> 
> Type Name:	TELEPHONE_NO
> Size	 :	6 bytes.
>     typedef struct
>       {
> 	short	area_code;	/* Maximum 999. */
> 	short	middle_code;	/* Maximum 999. */
> 	short	last_num;	/* Maximum 9999. */
>       }telephone_no;
> 	
> Operations:
> 	None
> 
> Comparison Operations:
> 	== .....
> 	%AREA_CODE_IN (NUM1,NUM2,..)
> 	%MIDDLE_CODE_IN (NUM1,NUM2,..)
> 
> Convenience Routines:
> 		:	:	:	:	:
> 		:	:	:	:	:
> 
> Presentation Control:
> 	print_phone_nu(ph_no,format): This function prints the phone
> 				number in the given format.
> 	If no presentation format is given, It prints the time using
> 	default print function provided for the object.
> --------------------------------------------------------------------
> Note: The syntax of the SQL is upto the choice of OORDBMS designer.
> 	SELECT * FROM emp WHERE area_code_of(ph_no) IN (408, 415);
> 	(or) SELECT * FROM emp WHERE ph_no %ARE_CODE_IN (408,415); 
> 	I choose the later one in this document examples.
> --------------------------------------------------------------------
> 	The user defined searching operations like AREA_CODE_IN or
> LOOK_FOR_KEYS is extremely powerful, yet simple.
> 
> i.  User can define simple but flexible searching operations and can
>     add new searching operations as needs arise with out changing any
>     structure of DATABASE physical object data.
>     (Ex:These searching operations can be used to access the objects
> 	on the bases of some common property like two legged animals
> 	from animal description object data field or phone numbers
> 	from same area code etc..)
> ii. The object structure design helps in packing less used several
>     fields(columns) in to one field, results in saving access time
>     and disk storage space.
>     Ex: Database table designer can define a column "ADDRESS" of a
> 	customer as a object(field) instead of several fields like
> 	STREET, CITY, STATE and ZIP and still have the flexibility
> 	of performing searches on ZIP, STATE and/or CITY.
> 	(Note:	An extreme case!. For the sake of discussion(fun).
> 	Combine all the columns of a table in to 1 column(object).
> 	Then Provide a rich set of searching operations.
> 	... Is this still a relational model?.)
> iii.These searching operations are executed at RDBMS kernel level and
>     application developer can implement fastest algorithm that meet
>     his requitements.
> 	
> ======================================================================
> The scenario of how OORDBMS works:
> 
> 	This following is not inteded as specification but to give
> some details to help understand more.
> 
> Note:	I believe this document is not easy to understand. So I
> am trying my best to give simple examples to explain as much as
> I can.
> 
> --------------------------------------------------------------------
> Implementation Part:
> --------------------------------------------------------------------
> 
> 	The OORDBMS vender provides a template "*.c" file to define
> new object for application developers. It contains a struct of the
> form given below.
> 
> typedef struct
>     {
> 	char		obj_name[16];
> 	short		obj_code;
> 	short		obj_max_size;
> 	short		is_fixed_size;
> 	int		(*equal_op_func)();
> 	int		(*comp_op_func)();
> 	operations	*ops_list;
> 	short		ops_list_size;
> 	user_operations	*user_ops_list;
> 	short		user_ops_list_size;
> 	int		(*default_presentation_function)();
> 		:	:	:
> 		:	:	:
>     }object_struct;
> Where::
> 	typedef struct
> 	    {
> 		char	operation[16];
> 		short	parameter_count;     /* Binary or unary */
> 		char	parameter1_name[16];
> 		short	obj_parameter1_code;
> 		char	parameter2_name[16];
> 		short	obj_parameter2_code;
> 		int	(*function_ptr)();
> 		char	return_obj_name[16];
> 		short	return_obj_code;
> 	    }operations;
> 	typedef struct
> 	    {
> 		char	operation[16];
> 		short	parameter_count;     /* Binary or unary */
> 		char	parameter1_name[16];
> 		short	obj_parameter1_code;
> 		char	parameter2_name[16];
> 		short	obj_parameter2_code;
> 		int	(*function_ptr)();
> 		char	return_obj_name[16];
> 		short	return_obj_code;
> 	    }user_operations;
> 
> object_struct fields:
> ---------------------
> obj_name:: The maximum size is 15 char. This name is given to the
> 	object and used in SQL statements when creating tables using
> 	this object.
> 	Note::	This name is used as any other type like DATE or
> 		NUMBER. All the information SQL interpreter needs
> 		to do its job is provided in the "object_struct".
> obj_code:: This code is not initialized by the user, and no interest
> 	to the user. This is the assigned code number to the object
> 	by the RDBMS and internally used by RDBMS.
> is_fixed_size:: If this object data is fixed size set to 1 else 0.
> obj_max_size::  The maximum data size required to store the object.
> (*equal_op_func)():: This function takes 2 object's data as formal
> 	parameters and returns ZERO if both are equal, else ONE.
> (*comp_op_func)()::  This function takes two objects data as formal
> 	parameters and returns 1, 0 or -1 depending on 1st object
> 	is greater, equal or less than the 2nd object respectively.
> *ops_list:: This is the list of structs which contains information
> 	to perform operations.
> ops_list_size:: The size of the above list.
> 		:	:	:	:
> 		:	:	:	:
> 
> user_operations fields:
> -----------------------
> operation:: The maximum size is 15 char. This name is given to the
> 	operation and used in SQL statements to perform searching
> 	or other operation on the object.
> 	Note::	The SQL interpreter calls the proper function with
> 		the parameter data depending on the operation name
> 		and the parameters, which performs the requested
> 		operation and returns the result of the operation.
> 		The SQL has all the information it needs to execute
> 		the operation in the structure "user_operations".
> 		:	:	:	:
> 		:	:	:	:
> 
> 	The object developer initializes the structure with proper
> data and sets the function pointers with developer implemented
> specific object operation handler functions. (Developer tests his
> object function off line before compiling in to RDBMS).
> 
> 	When RDBMS starts running during initialization time it
> builds internal structures which contains full object information
> for all the known Objects and assigns them object codes. The RDBMS
> during execution uses the information in these structures to process
> SQL and PL/SQL statements. 
> Note:	The object information includes the object name string and
> 	user defined object search operation name string and uses 
> 	these name strings in processing/parsing SQL statements.
> 
> Note:	All the object operation functions are very simple and can
> 	be tested completely off line with out any knowledge or help
> 	from RDBMS. This ensures high quality and modularity for
> 	object and application development.
> --------------------------------------------------------------------
> Using The Object:
> -----------------
> 	The implementer of the object provides a description of
> the object to user of the object. The example given above for the
> object "DOCUMENT" is a simple example. This information for
> most of the objects will be less than a page and easy to use.
> 
> --------------------------------------------------------------------
> Using The Object From 3GL language("c") in client/server environment:
> --------------------------------------------------------------------
> 	For every object the developer provides a "*.h" file and
> a set of conversion functions to link with client application.
> Note: These functions may be part of Object Oriented Interface.
> 
> Converting Internal data to External data:
> ------------------------------------------
> Consider an object "ADDRESS"
> typedef struct
>     {
> 	char	street[32];
> 	char	city[16];
> 	short	state;	/* 1-50 code numbers of states*/
> 	int	zip;
>     } address;
> 
> 	This information could be stored in DBAS file in 54 bytes.
> (32 + 16 + 2 + 4 = 54). 
> 
> 	To present this information to the application developer
> in SUN/SPARC the data should be properly aligned on "4" byte
> boundary (in this case). This could be done by the presentation
> layer of the Object Oriented part.
> 
> 	The presentation part is responsible for data conversion to
> the client environment. This may be achieved by providing a "objx.h"
> file and providing presentation function for the client environment.
> 
> example:
> int present_postal_address(client, client_ptr, db_buf_ptr)
> int	client;		/* The client code. */
> address	*client_ptr;	/* the client data structure. */
> char	*db_buf_ptr;	/* The data base object data ptr. */
> {
> 	:	:	:
>     switch(client)
>     {
> 	case SUN_SPARC:
> 	    memcpy((client_ptr->street),db_buf_ptr, 32);
> 	    memcpy((client_ptr->city),&db_buf_ptr[32], 16);
> 	    memcpy(&(client_ptr->state),&db_buf_ptr[48], 2);
> 	    memcpy(&(client_ptr->zip),&db_buf_ptr[50], 4);
> 		/* Assuming Sun don't need Byte Swap. */
> 	    break;
> 	case VAX_VMS:
> 		:	:	:
>     }
> }
> 
> address *add_ptr;
> 		:	:	:
> 	add_ptr = (address *) malloc(sizeof(address));
> 	SELECT emp_add INTO :add_ptr WHERE emp_num = 1234; 
> --------------------------------------------------------------------
> Converting external object data in to internal data:
> 	Developer provides several functions, precompiler uses proper
> function to convert external data to DB internal data.
> 
> 		EXAMPLES
> Way 1:
> 	UPDATE emp
> 		SET ph_num = '408-555-1212'
> 		WHERE	ename = 'BUSH';
> 	    In this way, If developer provides character string
> 	initialization procedure for the object call the procedure
> 	to convert the external data in to internal data.
> 	Note: If we want to make the precompiler happy, use:
> 		UPDATE emp
> 		    SET ph_num = string_to_internal('408-555-1212')
> 		    WHERE	ename = 'BUSH';
> 
> Way 2:
> 	short	last_num = 1212;	/* Host variable. */
> 	UPDATE emp
> 		SET ph_num = {408, 555, :last_num}
> 		WHERE	ename = 'BUSH';
> 	    In this way, If developer provides a procedure to set
> 	each individual basic(char, string,int,float) types, call
> 	the corresponding function to set the data to the object.
> 	Note: If we want to make the precompiler happy, use:
> 		UPDATE emp
> 		   SET ph_num = struct_to_internal(408,555,:last_num)
> 		   WHERE	ename = 'BUSH';
> 
> Way 3:
>     typedef struct
>       {
> 	short	area_code;	/* Maximum 999. */
> 	short	middle_code;	/* Maximum 999. */
> 	short	last_num;	/* Maximum 9999. */
>       }telephone_no;
> telephone_no phone_no = {408, 555, 1212}; /*Declaring a variable.*/
> 
> 	UPDATE emp
> 		SET ph_num = :phone_no
> 		WHERE	ename = 'BUSH';
> 	    Use the conversion procedure to convert from host
> 	environment to data base internal format.
> --------------------------------------------------------------------
> 	To automate the object development process, The OORDB can
> provide a set of core object templates. Implementing most of the
> objects can be as easy as implementing an object in "C"/"C++" and
> filling the blanchs in appropriate core object template file.
> ======================================================================
> OORDBMS adds one more dimension of flexibility to RDBMS(3D-DBMS?).
>     --	Each object may contain several pieces of information and
> 	several operations can be supported(defined) on the object.
> 
> Ease of Migration.
>     --	The OORDBMS two layer approach provides easy migration 
> 	path for RDBMS and provides good back ward compatibility.
> 	Existing Objects can be supported as pre defined objects.
> ======================================================================
> 	I believe the object-oriented concepts I discussed in the
> document are already used in various fields and it is time that, the
> RDBMS should make use of the existing object-oriented technology.
> 
> 	Although, I have no experience in evolving Object-oriented
> data bases, I believe the OORDBMS provides good balance of both the
> relational(RDB) and the Object-oriented(OODB) models.
> ======================================================================
> 		< End Of The Document >
> 					--Raju Chiluvuri.
> ======================================================================
Newsgroups: comp.databases