Snowflake is often used because people still want to normalize (and save some disk space !) which is not the way to go to ease query.
If you do an hybrid data model, your loading will be easier as you will have less problems to solve. I agrre with you, the complexity comes from the number of sources and their quality. But, from experience, at my last job, the DW has designed an hybrid data model to ease the ETL processes. Let me tell you that the querying and reporting was painful and slow. We have redesign it in a more formal star schema and we had some real challenges to load the DW. On the current project, we have 15 sources (excel, cobol, Oracle, Clipper, DB2/MVS, Nomad,... ) we are doing a prototype with an ETL, we will have fun ! It is feasible just to have a date column in the fact table. That's what they had done at the previous job. I do not recommend that. If you carefully do the analysis, you'll see that the users want to manage all kind of special events like season, national day, F1 racing (in Montreal, a beer company is checking if beer is more sold during the week-end Grand Prix). Also, often the fiscal year do not match the calendar year. So there is plenty stuff you may want to track with the time dimension. Using a generated key or the date value as the key is a good question. On the theoritical side you should use a generated key. I've used a date field without problem. --- Alexandre Gorbatchev <[EMAIL PROTECTED]> a �crit�: > St�phane, > > Thanks for response. > > > I have always discplined myself to use star schema > and > > never snowflake. > Would you mind asking why? > > > The "Which one is easier to implement and easier > ETL > > ?" is not a good question as your data model > should > > not be design for the ETL procecess but only for > the > > querying. > I mean ETL to load data _INTO_ data warehouse. Of > course, complexity is > mostly determined by sources, but still I'd like to > know if there is any > general influence by DW's data model. > > Another question. Is it feasible to make date > dimension or just use date > column? For example, Oracle Discoverer can work with > date columns using > hierarchies Y->M->D and similar. > What is faster: separate table for date dimension or > date column? > If I go with date dimension table should I use date > column as a foreign key > in fact table or use some artificial key? > > TIA, > Alexandre > > -- > Please see the official ORACLE-L FAQ: > http://www.orafaq.com > -- > Author: Alexandre Gorbatchev > 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). ===== St�phane Paquette DBA Oracle, consultant entrep�t de donn�es Oracle DBA, datawarehouse consultant [EMAIL PROTECTED] ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en fran�ais ! Yahoo! Mail : http://fr.mail.yahoo.com -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: =?iso-8859-1?q?paquette=20stephane?= 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).
