Re: is ius o-o?

so, ius being o-o means that you can store your own data types and create functions to manipulate them? so o-o in this context isn't quite like java or c++ principles... like you have an object and its methods and attributes, but instead you have data types, and you stick attributes and functions on them? On Tue, 9 Feb 1999, Obnoxio The Clown wrote: > >i've got ius 9.12 and a kind of newbie question. is it object oriented > >or just plainly relational? > > Yes, it is. :-) > > It's object-relational, which means you can treat it like a relational > database and you can treat it like an object database and store objects, > create your own data types, etc., etc. > > The best of both worlds. > > -- > "I'll Be Back" > Obnoxio > > ***************************** > I DO NOT want unsolicited e-mail & I will bill you for it. > By US Code Title 47, Sec. 227(a)(2)(B), a computer/modem/printer meets > the definition of a telephone fax machine. By Sec.227(b)(1)(C), it is > unlawful to send any unsolicited advertisements to such equipment, > punishable by action to recover actual monetary loss, or $500, whichever > is greater, for each violation. > > Pursuent to US Code, Title 47, Chapters 5, Subchapter II, Sec. 227, any > and all non-solicitied commercial e-mail sent to this address is subject > to a download & archival fee of $500 US. > > E-mailing denotes acceptance of these terms. > ***************************** > > > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com > _____________________________________________ Roberto Dircio Palacios Macedo Interactive and Cooperative Technologies Lab., UDLAP, Mexico. http://ict.udlap.mx/people/roberto | Just for the sake of it make sure tel:(22)292431 | you're always frowning, it shows the mail: is092756@cca.pue.udlap.mx | world that you have substance and depth ____________________________________________________________________________

Roberto Dircio Palacios-Macedo (is092756@cca.pue.udlap.mx) wrote: : so, ius being o-o means that you can store your own data types and create : functions to manipulate them? : so o-o in this context isn't quite like java or c++ principles... like : you have an object and its methods and attributes, but instead you have : data types, and you stick attributes and functions on them? 1. So, taking a pretty conventional definition of object-oriented systems, OO = Encapsulation ( Structure, Behavior ) + Inheritance + Identity. [This is from Yourdon and Coad. I expect there are others.] 2. In the ORDBMS, you make a distinction between the class/type system and the tables system. For example: -- -- Create the structure for the class. Note that this is just one -- of several ways to do this. You can also use 'C' structures or -- Java classes for OPAQUE types, where the structure is encapsulated. -- CREATE TYPE BirthDay ( Day INTEGER NOT NULL, Month INTEGER NOT NULL, LeapYearBirth BOOLEAN NOT NULL ); -- -- Now, you obviously want to create new instances of this -- class using, among other things, a date, or a triple of -- values, or a double of values. In other words, these -- are constructor functions for a BirthDate Object. -- CREATE FUNCTION BirthDate ( MMonth INTEGER, DDay INTEGER, FromLeapYear BOOLEAN ) RETURNING BirthDate IF (( MMonth = 2 ) AND ( DDay = 29 ) AND ( NOT ( FromLeapYear ))) THEN RAISE EXCEPTION -746, 0, "Birthdate Error: Feb 29th must be leap year"; END IF; RETURN ROW (MMonth, DDay, FromLeapYear)::BirthDate; END FUNCTION; GRANT EXECUTE ON FUNCTION BirthDate ( INTEGER, INTEGER, BOOLEAN ) TO PUBLIC; -- CREATE FUNCTION BirthDate ( MMonth INTEGER, DDay INTEGER) RETURNING BirthDate IF ((( MMonth BETWEEN 1 AND 12 ) AND (DDay BETWEEN 1 AND 28 )) OR (( MMonth IN ( 1, 3, 5, 7, 8, 10, 12)) AND (DDay BETWEEN 1 AND 31 )) OR (( MMonth IN ( 2, 4, 6, 9, 11 )) AND (DDay BETWEEN 1 AND 30 ))) THEN RETURN BirthDate(MMonth,DDay,'f'::boolean); ELIF (( MMonth = 2 ) AND ( DDay = 29 )) THEN RETURN BirthDate(MMonth,DDay,'t'::boolean); END IF; RAISE EXCEPTION -746, 0, "BirthDate Error: Illegal DDay for Birth Date"; END FUNCTION; GRANT EXECUTE ON FUNCTION BirthDate ( INTEGER, INTEGER ) TO PUBLIC; -- -- NOTE: FromLeapYear() is a function that returns a boolean based on -- whether or not the INTEGER year is a leap year. -- CREATE FUNCTION Birthdate ( Arg1 date ) RETURNING BirthDate DEFINE nYear INTEGER; LET nYear = YEAR(Arg1); RETURN ROW (MONTH(Arg1), DAY(Arg1),FromLeapYear(nYear))::BirthDate; END FUNCTION; GRANT EXECUTE ON FUNCTION BirthDate ( date ) TO PUBLIC; -- -- But you want other things of your objects: you want to -- compare them, modify them, analyse sets of them, and so on. -- For example, you might want to compare two BirthDates to -- see if they are the same. The complexity is due to the way -- that you want people born on the 29th Feb during a leap year to -- come up as having their birthday on 28th Feb during a non-leap -- year. -- -- The implementation of this is cumbersome and not really -- important. -- CREATE FUNCTION Compare ( Arg1 BirthDate, Arg2 BirthDate ) RETURNS INTEGER . . END FUNCTION DOCUMENT "Compare ( BirthDate, BirthDate ) returns -1 iff. Arg1 occurs ", "before Arg2, 0 if they occur on the same day, and 1 iff. Arg1", "is after Arg2."; GRANT EXECUTE ON FUNCTION Compare ( BirthDate, BirthDate ) TO PUBLIC; -- CREATE FUNCTION Equal ( Arg1 BirthDate, Arg2 BirthDate ) RETURNING boolean DEFINE nIntVal INTEGER; LET nIntVal = Compare ( Arg1, Arg2 ); IF ( nIntVal = 0 ) THEN RETURN 't'::boolean; END IF; RETURN 'f'::boolean; END FUNCTION; GRANT EXECUTE ON FUNCTION Equal ( BirthDate, BirthDate) TO PUBLIC; -- -- -- In other words, you now have an almost class BirthDate. It isn't -- fully encapsulated in the sense that you can access its innards -- but I could easily have implemented it so that it was. You will -- also note that when you declare this thing you declare each -- interface function/method separately from the declaration of the -- class. This is simply pragmatics. One of the strengths of a database -- like this is its flexibilty. You need to be able to modify -- interface functions (add new ones, change them, etc) and the -- alternative is to have a MODIFY CLASS kind of sytnax. At that point, -- the difference is all syntax. -- -- So far, everything I have done has been types and functions. Even -- this is kind of useful. For example, you might want to use this -- stuff in database procedures. But the point of the ORDBMS data model -- is to make these complex objects available in a query-centric -- framework. So, suppose I have the following good old fashioned -- SQL-92 table. -- CREATE TABLE Employees ( Id INTEGER NOT NULL PRIMARY KEY, Name VARCHAR(32) NOT NULL, DOB DATE NOT NULL ); -- -- The whole idea is being able to ask the following kind of -- question: "Who shares a birthday with 'Max Weber'?" -- SELECT E1.Name FROM Employees E1, Employees E2 WHERE E2.Name = 'Max Weber' AND BirthDate(E1.DOB) = BirthDate(E2.DOB); -- -- We can get religious about the difference between this syntax, -- and the following: -- SELECT E1.Name FROM Employees E1, Employees E2 WHERE E2.Name.Equal('Max Weber') AND E1.DOB->BirthDate()->Equal(E2.DOB->BirBirthDate()); -- -- but the idea is the same. -- Well, the example's a bit contrived, but you get the idea. The object part of the ORDBMS is its type system and user-defined functions. The ORDBMS doesn't do identity, but all of the other tremendously useful design principles that you get from OO land are there. The relational part is the tables/views/query centric view of the world. It's what gives you queries. There's other stuff too but I'm going on a bit here. I just wouldn't get too hung up on the differences in naming, or the fact that the encapsultion happens in the run-time system, rather than at the compiler. Hope this helps! KR Pb

Also , IUS implements strong typing so you can do lots of neat things with your types like provide casts. You also have function and operator overloading as well as the ability to provide secondary access methods or treat external data as if it were part of the database. You can also implement inheritance in your types too ( not that hr is a great application of OR): Create Row Type PERSON_T( last_name varchar(30), first_name varchar(10), mi char(1), ssn varchar(11) ); Create Row Type Emp ( emp_id integer, person PERSON_T ) UNDER PERSON_T; Create Table Person OF TYPE PERSON_T; Create Table Employee Of Type Emp UNDER Person; Frank Oelschlager ECOlogic Corporation Paul Brown wrote in message <79qct0$auc$1@agate.berkeley.edu>... >Roberto Dircio Palacios-Macedo (is092756@cca.pue.udlap.mx) wrote: >: so, ius being o-o means that you can store your own data types and create >: functions to manipulate them? >: so o-o in this context isn't quite like java or c++ principles... like >: you have an object and its methods and attributes, but instead you have >: data types, and you stick attributes and functions on them? > > 1. So, taking a pretty conventional definition of object-oriented > systems, OO = Encapsulation ( Structure, Behavior ) + Inheritance + > Identity. [This is from Yourdon and Coad. I expect there are others.] > > 2. In the ORDBMS, you make a distinction between the class/type > system and the tables system. For example: > > -- > -- Create the structure for the class. Note that this is just one > -- of several ways to do this. You can also use 'C' structures or > -- Java classes for OPAQUE types, where the structure is encapsulated. > -- > CREATE TYPE BirthDay ( > Day INTEGER NOT NULL, > Month INTEGER NOT NULL, > LeapYearBirth BOOLEAN NOT NULL > ); > -- > -- Now, you obviously want to create new instances of this > -- class using, among other things, a date, or a triple of > -- values, or a double of values. In other words, these > -- are constructor functions for a BirthDate Object. > -- > CREATE FUNCTION BirthDate ( MMonth INTEGER, DDay INTEGER, > FromLeapYear BOOLEAN ) > RETURNING BirthDate > IF (( MMonth = 2 ) AND ( DDay = 29 ) AND ( NOT ( FromLeapYear )))THEN > RAISE EXCEPTION -746, 0, > "Birthdate Error: Feb 29th must be leap year"; > END IF; > RETURN ROW (MMonth, DDay, FromLeapYear)::BirthDate; > END FUNCTION; > GRANT EXECUTE ON FUNCTION BirthDate ( INTEGER, INTEGER, BOOLEAN ) > TO PUBLIC; > -- > CREATE FUNCTION BirthDate ( MMonth INTEGER, DDay INTEGER) > RETURNING BirthDate > IF ((( MMonth BETWEEN 1 AND 12 ) AND (DDay BETWEEN 1 AND 28 )) OR > (( MMonth IN ( 1, 3, 5, 7, 8, 10, 12)) AND (DDay BETWEEN 1 AND31 )) OR > (( MMonth IN ( 2, 4, 6, 9, 11 )) AND (DDay BETWEEN 1 AND 30 ))) THEN > RETURN BirthDate(MMonth,DDay,'f'::boolean); > ELIF (( MMonth = 2 ) AND ( DDay = 29 )) THEN > RETURN BirthDate(MMonth,DDay,'t'::boolean); > END IF; > > RAISE EXCEPTION -746, 0, > "BirthDate Error: Illegal DDay for Birth Date"; > > END FUNCTION; > GRANT EXECUTE ON FUNCTION BirthDate ( INTEGER, INTEGER ) TO PUBLIC;> -- > -- NOTE: FromLeapYear() is a function that returns a boolean based on > -- whether or not the INTEGER year is a leap year. > -- > CREATE FUNCTION Birthdate ( Arg1 date ) > RETURNING BirthDate > DEFINE nYear INTEGER;> LET nYear = YEAR(Arg1); > RETURN ROW (MONTH(Arg1), DAY(Arg1),FromLeapYear(nYear))::BirthDate; > END FUNCTION; > GRANT EXECUTE ON FUNCTION BirthDate ( date ) TO PUBLIC;> -- > -- But you want other things of your objects: you want to > -- compare them, modify them, analyse sets of them, and so on. > -- For example, you might want to compare two BirthDates to > -- see if they are the same. The complexity is due to the way > -- that you want people born on the 29th Feb during a leap year to > -- come up as having their birthday on 28th Feb during a non-leap > -- year. > -- > -- The implementation of this is cumbersome and not really > -- important. > -- > CREATE FUNCTION Compare ( Arg1 BirthDate, Arg2 BirthDate ) > RETURNS INTEGER > . > . > END FUNCTION > DOCUMENT "Compare ( BirthDate, BirthDate ) returns -1 iff. Arg1 occurs ", > "before Arg2, 0 if they occur on the same day, and 1 iff. Arg1", > "is after Arg2."; > GRANT EXECUTE ON FUNCTION Compare ( BirthDate, BirthDate ) TO PUBLIC;> -- > CREATE FUNCTION Equal ( Arg1 BirthDate, Arg2 BirthDate ) > RETURNING boolean > DEFINE nIntVal INTEGER;> > LET nIntVal = Compare ( Arg1, Arg2 ); > > IF ( nIntVal = 0 ) THEN > RETURN 't'::boolean; > END IF; > > RETURN 'f'::boolean; > END FUNCTION; > GRANT EXECUTE ON FUNCTION Equal ( BirthDate, BirthDate) TO PUBLIC;> -- > -- > -- In other words, you now have an almost class BirthDate. It isn't > -- fully encapsulated in the sense that you can access its innards > -- but I could easily have implemented it so that it was. You will > -- also note that when you declare this thing you declare each > -- interface function/method separately from the declaration of the > -- class. This is simply pragmatics. One of the strengths of a database > -- like this is its flexibilty. You need to be able to modify > -- interface functions (add new ones, change them, etc) and the > -- alternative is to have a MODIFY CLASS kind of sytnax. At that point, > -- the difference is all syntax. > -- > -- So far, everything I have done has been types and functions. Even > -- this is kind of useful. For example, you might want to use this > -- stuff in database procedures. But the point of the ORDBMS data model > -- is to make these complex objects available in a query-centric > -- framework. So, suppose I have the following good old fashioned > -- SQL-92 table. > -- > CREATE TABLE Employees ( > Id INTEGER NOT NULL PRIMARY KEY, > Name VARCHAR(32) NOT NULL,> DOB DATE NOT NULL > ); > -- > -- The whole idea is being able to ask the following kind of > -- question: "Who shares a birthday with 'Max Weber'?" > -- > SELECT E1.Name > FROM Employees E1, Employees E2 > WHERE E2.Name = 'Max Weber' > AND BirthDate(E1.DOB) = BirthDate(E2.DOB);> -- > -- We can get religious about the difference between this syntax, > -- and the following: > --