ORACLENERD: Design: The Entity = The Party

Design: The Entity = The Party

Monday, September 1, 2008

I've discussed the merits of design and the entity here and here.

In a recent interview, the prospective employer mentioned the "party" model. I had no idea what they were talking about at the time only that it was similar to my entity model.

In another interview, I was asked about subtyping. I didn't know the vernacular as it pertained to database modeling, but I went on to explain the entity model. He told me they were one and the same! Now I have a name for it and I came to something that others had already "invented." While it would have been easier to read one of the books on modeling that discussed the Party Model, but I can't seem to read technical books (online is a different story for some reason). I also think it's pretty cool I came to the same conclusion as others outside of their influence. I do have to wonder though if I took it in at some point of time but don't explicitly recall it.

Anyway, it's definitely nice to have an idea validated.

Below are some general links on data modeling and specific ones on the Party Model:
Data Modeling on Wikipedia
A Universal Person and Organization Data Model
Siebel/Oracle - Party Data Model
Party Information Framework

Labels: database, design

¶ 9/01/2008 05:25:00 PM

Comments:

aka the "Everything is a..." model, in the case "everything is a party".

imho very overused and frequently underperforming.

# posted by

DomBrooks : September 2, 2008 at 3:48 AM

Come on Dom...let me enjoy the moment! ;)

I would stick to the person and organization and perhaps subtypes of those. So not everything (I think).

So far I've seen that app dev people like it (more "object-oriented" I guess?), that in itself should scare me right?

chet

# posted by

oraclenerd : September 2, 2008 at 7:37 AM

Um...

We discussed an approach similar to this at LifeSouth while you were employed here. The party table provided a common point for attaching addresses, phone numbers and other things common to a party/entity and supplemental tables held class specific data (e.g. a table for persons with blood types and cmv results, one for companies with terms, etc).

I don't know if it's an "app dev" person's favorite or not (as an aside, I think you're a little hung up on app dev vs. database dev--it's been argued both ways by smarter people than us). Parties and other archtypes are quite useful during schema modeling, but like everything else, during implementation it should be tested before the decision to keep the class/subclass model or flatten it is made.

# posted by

Tom Wurzbach : September 3, 2008 at 9:48 AM

Mr. Wurzbach how nice to see you finally. :)

I don't recall anything specific but that doesn't mean it didn't happen. Much of what I now know was based on what I learned with you.

I wholly agree. Dev/testing should ultimately define the physical implementation.

I would disagree that I am hung up on the app dev vs database dev. It's been an observation the last few years that continues to pop up. I believe you provided an environment that was pretty well rounded...which is the ideal. It seems to get specialized in other places (either/or not and). Many of the app dev people don't know how the database works (sweeping generalization) and many data dev people don't understand the app side.

Plus, I don't know if there are that many smarter than you out there. ;)

# posted by

oraclenerd : September 3, 2008 at 10:09 AM