RE: Database Modeling- Normalization - Dinosaurs or What?

[Jeremy Pulcifer]

Title: Message

I disagree. A hybrid database is usually a combination of OLTP and OLAP: then you normalize the transactional, de-normalize the DSS.

 

While I understand that sometimes we have to live with a less-normalized database than we'd like, if I'm building the database, it is normalized if the application is transactional, and de-normalize from that to support whatever DSS operations are necessary. I'm a duhveloper and have rarely (never?) seen a situation where a transactional database was "too" normalized (stopping at 3rd normal). That's been blamed for a lot, but usually the end result is either the user/duhveloper is trying to either provide DSS functionality or is writing poor code. Of course, designing a flexible de-normalized schema is/seems less clear-cut, to be sure.

 

That being said, you can only enforce this concept where you have complete authority over the data model. If this isn't the case, then all bets are off.

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 25, 2003 10:54 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: Database Modeling- Normalization - Dinosaurs or What?

It is often not so cut and dried.  There are degrees of normalization and hybrid databases.  Wish it was that easy.  I think you oversimplified the matter and honestly that doesn't help the data modeling efforts. 

 

Oracle OCP DBA

-----Original Message-----
From: Jeremy Pulcifer [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 25, 2003 11:59 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: Database Modeling- Normalization - Dinosaurs or What?

OLTP = Normalize

OLAP/DSS = DeNormalize

 

End of discussion. We figured this out what, 10 years ago?

-----Original Message-----
From: Stephane Paquette [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 25, 2003 7:24 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: Database Modeling- Normalization - Dinosaurs or What?

DBA are responsible for the data model.

I spend time to show the developpers the benefits of data normalization.

 

I do not agree with Tom on "A good data model produces good opportunities for all kinds of data retrieval tools in the later life of the application." as I just did a performance review of a Decision Support System and my conclusion is that the data model is too normalized for a query intensive usage.

It depends on what the system will be use for. For OLTP, yes third normal form is good. For datawarehousing, a star schema is the way to go.

 

 

Stephane

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Mercadante, Thomas F
Sent: Tuesday, March 25, 2003 7:47 AM
To: Multiple recipients of list ORACLE-L
Subject: RE: Database Modeling- Normalization - Dinosaurs or What?

Paula,

 

Keep fighting for normalization.  Something almost all developers fail to recognize is the long-term use of the database - they only think in the "here and now" - they need to develop the application right now.  What they fail to recognize are the poor untrained users down the line who will need to develop reports off of the data.  Having denormalized data will cause tons data inconsistencies in a few years - exactly what we had back in the "good old Cobol flat file days".  A real mess.

 

One of the most important jobs that a DBA has is producing a good data model keeping all players and users in mind when designing the tables.  A good data model produces good opportunities for all kinds of data retrieval tools in the later life of the application.

 

Hope this helps.

 

Tom Mercadante
Oracle Certified Professional

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Monday, March 24, 2003 7:14 PM
To: Multiple recipients of list ORACLE-L
Subject: RE: Database Modeling- Normalization - Dinosaurs or What?

Guys,

The emphasis in many places I have worked is developing quick and dirty systems as quickly as possible and working with developers that don't seem to have very much understanding of Relational Database Theory but who prefer to program using flat files in relational databases - calling it "object-oriented" when it truly is not.  Let us just say that it is highly denormalized.  As a DBA I care about data integrity, extensibility and scalability but the up and coming esp. SQL Server developer types seem to operate in a world where this doesn't matter - just buy more hardware, denormalize to make the programming easier, etc. 

I have been losing this battle. 

So - what is your experience with this?

What about the idea of having everyone access all objects in the views so that if need be the DBA's could in fact still make physical changes to the schemas without a large amount of rewriting of code? - as a standard

Living without normalization for most things - esp. small systems and w/o fk's except as they are maintained in the application for the sake of getting the application done quickly, cheaply.

It turns my stomach but then I wonder about my own sanity - am I making too much out of nothing?  What about these stovepipe systems? 

Case in-point 100,000 row table for asset management - moving different types of addresses to a separate address table and moving different types of people to a person table.  Developers are aghast at the performance implications.  I am thinking perf. implications not real esp. with small amount but provides extensibility and RI with these reference tables instead of denorma. in multiple tables.  They say mostly batch inserts/updates and batch reads - but then they say some OLTP.  This is a SQL Server database.  I think the separate reference tables provides only way for extensibility and data integrity.  I say I will write for them a joined view.  They say perf. implications.  - AARRRGGHH!

Oracle OCP DBA