Dennis
My recollection of Kimball vs. Inmon is the reverse, that Kimball said
"why not", while Inmon said "no way".
But anyway, I think the key is knowing the situation at your
organization. What are your user expectations? What is your refresh cycle -
weekly, daily, etc.? How likely is the interval to change (start with a
week, then the users say it must be daily)? Depending on your design, some
DW functions may be unavailable to your users during data refresh. For
example, we have a DW that is loaded weekly, but the refresh occurs on the
weekend so the users don't run reports then. If there is a load problem then
the users are notified which portions of the DW are not available until the
problem is fixed.
The relational bit bothers me. Too many experienced data modeling people
have trouble giving up on the relational. Sometimes you need a little
relational to help data integrity of loads, but often it gets in the way.
Too much relational will yield a crippled DW. But I never try to argue with
a relational bigot (not to offend anyone, speaking just in the context of
DW), life is just too short and there are others willing to assume that
duty. Ralph has had some good articles on why relational is just not
appropriate in the DW.
One thing Ralph is very firm about - get the grain of your fact table
correct because the tendency is to build at a higher grain and then you end
up rebuilding it again with much wasted effort and user frustration.
Dennis Williams
DBA, 40%OCP
Lifetouch, Inc.
[EMAIL PROTECTED]
-----Original Message-----
Sent: Friday, November 08, 2002 1:44 PM
To: Multiple recipients of list ORACLE-L
After reading literature from Kimball, Inmon and some other experts, it
seems to me that we should have a 3-tier architecture -
Tier 1 - operational data
Tier 2 - ODS which contains integrated, cleansed, transformed operational
detail data, or staging area in relational schema
Tier3 - star schema Data marts
The question/contention here is tier 2 - should we provide reporting
capability for this? According to Kimball, staging area should not be
accessible to end users for direct reporting. But Inmon seems to disagree
with him on this one.
If ODS is an integrated, authoritative data source of the enterprise, I
don't see why we can't create ad-hoc reports against it. Of course since it
is relational, we might need reporting tools and heavy IS involvement. So
IMHO it depends on what the user needs are to decide what tier2 should look
like and be used for.
Anybody cares to commend on this?
Thanks
Dennis Meng
Database Administrator
Focal Communications Corp.
Jared Still
<jkstill@cybcon. To: Multiple recipients
of list ORACLE-L <[EMAIL PROTECTED]>
com> cc:
Sent by: Subject: Re: Need Help on
Operational Data Store
[EMAIL PROTECTED]
11/08/2002 11:19
AM
Please respond
to ORACLE-L
Dennis,
I think you got it wrong right off when you stated that there's a
"lot of confusion in ODS vs. DW ".
It isn't that issue at all. No two people can agree on what an ODS
is at all, much less compare it to a DW.
To me for instance, an ODS is a place to stage data for the final
stages of some other process, be it a DW, or anything else.
An ODS is a rather generic term, and therefor whatever you
want it to be.
Jared
On Friday 08 November 2002 07:59, [EMAIL PROTECTED] wrote:
> Greetings -
> I need some help with building an Operational Data Store. I know there
are
> a lot of confusion in ODS vs. DW but I belong to the camp of 'ODS should
be
> used only for operational reporting, not decision support'. So while
> Kimball talks a lot about building a DW in his books, he does not cover
ODS
> much. Are there any books/websites/third parties that deal with building
an
> ODS?
>
> TIA
>
>
> Dennis Meng
> Database Administrator
> Focal Communications Corp.
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Jared Still
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: DENNIS WILLIAMS
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
