Re: Clean Object Class Design -- What is it?

"Bob Badour" <bbadour_at_golden.net> hunched over a computer, typing feverishly;
thunder crashed, "Bob Badour" <bbadour_at_golden.net> laughed madly, then wrote:

>>what the heck is XNF?
>
>
>That is an excellent question! NF is short for Normal Form.
>
>5NF refers to fifth normal form, which is the highest normal form.
>
>BCNF refers to Baccus/Codd Normal Form, which fixes a small error in what
>was orginally published as 3NF.
>
>Most designs that are in 3NF/BCNF are also in 5NF.

Thanks for the pointers.

Most of my knowledge evolved from practical work experience; the normal forms aren't new to me, but the TLA's were.

***

I've watched the whole object-oriented database vs. relational database debate for quite a while, this is my two cents worth, for what it's worth.

***

I don't really have any argument one way or another, as far as what system people choose to use. If an OO dbase does the job better and quicker, use it.

But I think it misses the point. I don't think 'OO database' and 'relational database' are the same kinds of categories. The idea I've seen expressed that 'OO databases will replace SQL databases' seems to me a little like saying 'music is better than cooking'. They're not really comparable.

Sure an OO hierarchy might well contain enough information to determinately define relations and produce a dependable data storage/retrieval system.

But, for that matter, I might find a case where I could use an array to do database-like work and not need to go through SQL in a given application. If it works, of course I'd use it. Or a linked list or hashtable or whatever. At times, using a major database program would just be overkill and the overall performance of my application would be much worse than if I had taken the simpler approach.

Of course, that doesn't mean that relational database systems should be thrown out and replaced with arrays.

An existing database system, any of the major commercial ones, is an attempt to fully implement SQL (in theory, anyway...), and SQL is an attempt to present the logical language behind any data storage and retrieval system in a rigorous way. Mapping a complete branch of information theory to a practical working computer system is going to be difficult, if not impossible, so shortcuts are taken. I don't say that to criticize the makers of the system, it's just inevitable.

Even with shortcuts taken though, a really substantial implementation of SQL is going to be very resource-intensive. Quite possibly more than many applications are going to need.

The nature of the theory is just not necessarily going to be practical to implement completely in an electronic system.

And, for that matter, most databases in practice are not going to be 'perfect' implementations of their theoretical representation.

The normal forms are actually an excellent example, I'm glad I learned those terms. How often is -any- database going to be a perfect 5NF representation of it's subject? Almost never.

It's not that the developers are 'bad', it's just practicality. A perfect theoretical representation just isn't necessarily going to be needed. I think it's just important to bear scaleability in mind. I think anybody who has worked with databases in a practical situation would agree that the closer to an ideal, 5NF representation a database is, the less you are going to run into insurmountable problems as it grows and evolves. You set up a business system or something, you don't normalize, say, telephone numbers, but allow them to be one-to-one with 'service rep' or whatever. Then your customer complains because their service reps have home -and- cell phone numbers.

Depending on how far you've gone with your work -beyond- the point where you set up the 'service rep-phone number' relation, fixing it can be awful.

So IMO however you go, you are going to make some compromises. You just make the best judgement you can based on logic and experience, and cross your fingers.

Using an existing OO hierarchy structure like Java can be a good way to set up some systems.

Practically, I can see the advantages, although I would be a little leery of such a system if I expected the system to evolve much over time.

I don't think an 'OO Database' is really a different animal than a 'Relational database' though. I guess that's my point. It's just a different way of implementing it.

As others have said in this thread, a relational database -is- an 'OO system'. Personally, I would map the object classes to the tables, each table should be a class, and the object instances to the records.

In purely theoretical terms, I don't think there's -any- real separation.

In practical terms, the OO hierarchy wasn't designed to necessarily accomodate database type operations. If I decide I want my table X to have a relation to table Y, I just need to define the relationship logically. In an OO hierarchy, it isn't necessarily going to be that simple. I can certainly look at existing Java classes and see that's true. How exactly do you decide that you want to define a relation between two totally different classes? Inheritance? Interface implementation? What if you want your 'has-a' relation to become an 'is-a' relation? If I've defined class 'CustomerRep' and it has a member 'phoneNumber', then I decide that 'phoneNumber' should be a different class entirely, it seems like I'm going to have a long hard job of going through my class hierarchy with a fine tooth comb to remove references to 'CustomerRep.phoneNumber'. Etc.

Relational systems are simply closer to the theory. That isn't to say they're 'better' for all uses, but ultimately practice is going to tend to conform to theory.

Anyway. Blah blah blah. </my two cents worth>

I might very well look at Rosenberger's system, I could imagine that it would be a very good solution for some problems.

I just think one has to be careful thinking of it as a 'replacement' for anything, and it would be good to be cautious using it in a situation where you expect the database to undergo major changes as time goes by.

--
Joe Cosby
http://joecosby.home.mindspring.com
 
Eschatology's Just Another Word for Nothin' Left to Lose
 
 
Sig by Kookie Jar 5.98d http://go.to/generalfrenetics/