Re: Generic Modeling

Brian,
There are two books I can recommend to you:

• David C. Hay: Data Model Patterns: Conventions of Thought
• Len Silverstone: The Data Model Resource Book

The books are more concerned with data model *patterns* (party, address, activity, asset, invoice, sales order, work order etc ...). These patterns (given in Oracle ER notation) are the things that are important ....

In my opinion [no theoretical background, just my opinion] more generic data models (like the THING or THING/RELATIONSHIP tables) are not practically usefull neither to the programmer nor to the end-user. In David C. Hay book you can find a "Universal Data Model" which has 7 entities/tables and with witch you can model evertything. I'am sure that we will *never* see IT systems that *should* have 500 tables implemented in 7 !! For example, I don't see *any* argument why we should put the customers in the same table where the invoices are ?!?! But the 7-table approach can be interesting for parts of the model (see David's book for examples).

The world is made of atoms (and smaller particels) , but we almost never work with them directly, we work/see more compound structures... For example a wall is composed of bricks. The atoms are practically unimportant. The bricks are important ... We should investigate the bricks (data patterns) !!

But, I would like to hear other opinions, because this topic is interesting and it's a good topic for this newsgroup :-)

Happy New Year ... Let's hope it's a good one.

Greetings from Croatia,
Drago Ganic

"Brian Smith" <brian-l-smith_at_uiowa.edu> wrote in message news:60360d48.0112301941.2b44f613_at_posting.google.com...
> I am looking for information about generic modeling in relational
> databases (especially SQL). In particular, I have heard about the
> one-table-approach (the "thing" or "stuff" table), the two-table
> approach ("thing" and "relationship"), etc., etc. I have also seen a
> presentation on milder forms of generic database design (e.g.
> combining multiple code tables together, merging parts of CUSTOMER,
> EMPLOYEE, and COMPANY tables into a PARTY table, etc.
>
> In particular, I am looking for:
> * persuasive theoretical arguments about why generic modeling in the
> "thing-relationship" sense is good or bad for database design.
> * objective performance measurements and
> performance-enhancing techniques for the generic approach
> (preferable that are at least applicable to Oracle
> or PostgreSQL).
> * Storing various levels of meta-data (meta-meta-data, meta-data,
> and data)
> together in the same schema/table.
> * Ways to implement a relationl schema on top of a generic schema
> (or
> vice-versa); for example, creating (updatable) views on a "THING"
> relation
> to get back to "EMPLOYEE", "CUSTOMER", etc.
>
> Where can I find information about these specific topics? I am
> grateful to receive any pointers to resources you might know about. I
> tried searching on google but came up nearly empty; I guess I wasn't
> creative enough with my search criterea ("generic modeling SQL" is
> too, well, generic).
>
> Thanks,
> Brian
Received on Mon Dec 31 2001 - 17:01:08 CET