Order headers and lines

Hi,

I am trying to design a data mart that will server as a data source for an Analysis cube. I would like to know the best practice for handling order headers and order lines. Do I need 2 fact tables in the data mart, and does there need to be a foreign key relationship between them.

The header table will contain information like whether a delivery was made on time, which depot delivered the order, how many times the delivery was attempted, total distribution charge, whereas the line table will contain product related information with quantities ordered / delivered, and the cost per line

Thanks

Depends on the analysis that needs to be supported, both by the data mart and the cube. For example, the FactInternetSales and FactResellerSales tables in the sample Adventure Works DW database are at the line level. But from your description, it sounde like there are relevant measures at both the header and line item level, so 2 fact tables (with 2 mesure groups) may be preferable. The detail table would then have a foreign key for the parent header table.

In terms of dimensions, those which directly relate to the detail measure group can be configured with a "many-many" relation to the header measure group (using the detail measure group and header fact dimension as intermediates). And those dimensions which directly relate to the header measure group can be configured as "referenced" (via the header fact dimension) for the detail measure group.

This article argues for a single detail-level fact table, but the AS 2005 modelling features may mitigate some of these issues:

Managing Your Parents

Be mindful of reporting needs when designing parent and child fact tables

By Ralph Kimball

...

Oracle-style exception handling in SQL2000

Hello!

I'm working on a project that migrates an Oracle based DB application into SQL2000 server.

The original version of the application uses the Oracle exception-handling mechanism. In SQL2000 I wasn't able to find exception handling. Of course, there is an error handling mechanism, but it is far less sophisticated.

The raised error doesn't exit the procedure, neither propagate the "error state" through the whole call-stack, which means that I have to simulate the exception handling by putting error check after virtually all the DB access statements, which is a painstaking job.

Is there any better solutions?

Thanks for your help!

BalageNope..

If @.Error_Out <> 0
BEGIN
Select @.Error_Loc = 1
Select @.Error_Type = 50001
GOTO Load_Ledger_Init_sp_Error
END

If @.Month1 = '99' Or @.Month2 = '99' Or @.Month3 = '99'
BEGIN
SELECT @.Error_Loc = 2
SELECT @.Error_Message = 'Month Not set for File name. Check System Variables. Values are: '
+ ' Proof_Year=~' + @.Proof_Year + '~'
+ ' Proof_Quarter=~' + @.Proof_Quarter + '~'
SELECT @.Error_Type = 50002
GOTO Load_Ledger_Init_sp_Error
END

One check for system error, one for business logic error|||We are a small company and we specialise in Database Migration. We have our toolbox that we have developed after long years of research and experience. However, even then, there were these hard nuts that we could never crack.

Of late, we have found a powerful utility in a product called Vaman DataServer. This product is essentially a DBMS, but what sets them apart, is their utility to migrate data from any source to any destination. I was a little sceptical to begin with, but eventually I figured that this tool is a nifty little thing that every migration company can use.

Right now it is free, but we are in talks with them for a commercial version, which they say migrates DDLs as well.

You could check out this link
http://www.vaman.net/vmndataserver.asp

You need to login for the download.

Hope this helps.