NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/database/8502

Text File | 1992-12-15 | 33.1 KB | 842 lines

Newsgroups: comp.databases
Path: sparky!uunet!mcsun!inesc.inesc.pt!dec4pt.puug.pt!ul!news
From: [e-mail] (Paulo Batista)
Subject: Re: Object-oriented RDBMS
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Dept. Informatica - Fac. Ciencias da Universidade de Lisboa
References: <[e-mail]>
Date: Mon, 14 Dec 1992 13:32:06 GMT
Lines: 830

In article <[e-mail]> [e-mail]
(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.
> ======================================================================