Object Oriented Database Design

[Chris Nebinger]

Okay, here's my question. How do you handle OO design
with inheritance?

For example, lets say we're developing a Real Estate
application, using .Net against an Access DB (Or SQL
Server/MSDE, etc.)

Now, we have a generic Person class (FName, LName,
Address, etc.)

We also have an Agent Class that inherits from Person,
adding a few more properties. Throw in a Client, Seller,
etc. type classes that will inherit from person, each
adding their own properties.

Do you have a person table (PersonID as PK), and then an
Agent Table (Again, PersonID as PK on 1-1 relationship),
or combine all possible fields into Person Table?

If you use seperate tables for each inherited class (no
person table, but FName fields in Agent, Client, etc.
tables), how do you handle things like mailing lists?

Anyone have any examples of UML's and the db design
supporting them? Or links to websites that talk about it?


Chris Nebinger

 

[Craig Alexander Morrison]

OODB - a total waste of time, not soundly based.

Access/Jet, SQL Server, DB2 and Oracle are (roughly) based on Relational
Theory.

Do not use a spanner when a screwdriver is more appropriate.

comp.databases may have an OO group check there.

Do not confuse OO application development with Databases you may find that
the R database is exactly what you need for your OO app.

 

[Craig Alexander Morrison]

As to the particular design you mention this is handled simply by applying
the subtyping structure.

Person is a relation (table) that contains data that is pertinent to all
Persons the subtypes such as Agent and Client and Seller have 1 to 1
relationships with the Person relation these relations contain the data that
is pertinent to that subtype only.

 

[Chris Nebinger]

This is my first venture into fully OO application
development. In Access, I have used classes, even
collection classes, to represent some objects, but the
data structure ultimately drove development.

Now I'm working on a .NET project that will be fully OO.
There's no doubt that the data will be stored in a DB of
some kind, probably Access for distrubution. But, it will
be an 3 tier system, with a complex middle layer and GUI-
layer, and relatively simple backend.

I have a great grasp on the objects and their properties &
methods, but designing the database has led me to several
different possible schemas.

On http://www.agiledata.org/essays/mappingObjects.html, I
found that the schemas that I came up with are exactly
what the author recommended. It sounds like this is a
book I should pick up.

Now, I'm going to head over to comp.databases and see
what's there. Thanks alot.


Chris Nebinger

 

[Craig Alexander Morrison]

The data structure will always drive the development with a tool such as
Access it was designed to work with relational database designs.

Be careful if you are wandering from the relational path.

 

[Chris Nebinger]

So, how would you recommend saving object oriented data if
not in a database?

And from what I've read, mostly on the sight I linked to
earlier, one path is to seperate the data structure design
from the object design.

Chris Nebinger

 

[Craig Alexander Morrison]

I would use a relational database to contain the data.

Use the objects to manipulate that data for use by the application.

The relational model should support the data in base tables, you could use
views, stored procedures etc (aka queries) to process the data for use in
the application.

Problem is that most products do not support fully the relational model,
domains (not the pathetic user defined type) but if domains were correctly
supported you would have more or less what you need domains equate to object
classes. This means that if domains were properly supported by the current
products a relational system could do all that the OO systems claim they can
do and the relational systems cannot.

Domains can contain anything; arrays, lists, photographs, songs, maps,
blueprints. The encapsulation takes place in the domain not the relation.
Sorry it does leave you a bit stuck, but OODBs are even more immature than
relational systems.

It is unfortunate but you have to try to make the best of the systems
available.