| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Database Modeling- Normalization - Dinosaurs or What?
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C2F37A.FBC3FB80
Content-Type: text/plain; charset="iso-8859-1"
We too have been down this route - our experiences may just be relevant to you, Paula - and others.
>From an early stage we recognised the crucial importance of getting the design RIGHT. That meant at least TNF. Why important? Well, read the gurus, Chris Date (most particularly), David McGoveran, Hugh Darwen, Fabian Pascal. If you cannot see the sheer unassailable logic in their arguments, you are, frankly, in the wrong business.
Next, go to your senior management, and (as we have) put the case that unless your data model is designed with due conformance to these principles, the integrity, and therefore correctness of your data CANNOT (and I stress) be guaranteed. Then allow them to reflect on the litigation that might result from an audit trail which reveals that the data supplied to a customer, on which costly decisions were subsequently made, was proven to be questionable, could not be assured (through our published quality control standards) to be correct, or even wrong in the first place...
We pass on data to various organisations all over the world - we simply cannot risk giving incorrect data. If such weaknesses were detected, we would risk being closed down. That's why we have adopted strict standards in our design approach.
Here in the UK we do not have such a strong inclination to seek recourse in the law as you folk in the US do (but the trend is that way, sigh) - I would think this must be a pretty strong argument over there too.
peter
edinburgh
-----Original Message-----
Sent: 25 March 2003 19:00
To: Multiple recipients of list ORACLE-L
I understand what database modeling is for, the different types of normalization and denormalization and the tradeoffs in different types of systems and ultimately to the data access of the system driven (should be ) by the business requirements. The problem is I don't think anyone that does development or provides COTS packages does and that negatively impacts my ability as a DBA to ensure data integrity. I was wondering if I was missing some boat. If anyone else was hitting this brick wall? If there is a way to make this point clear. I was thinking of even doing a prototype - this system versus that system - same app. code, same use of system, normalized and then denormalized so I could show why the heck normalization and RI on the database is the only real way to ensure data integrity. Then show all the ways the database integrity could go wrong. I feel like I have to prove why to use relational database design on a relational database engine built specifically for that purpose -
GEEEZ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Does anyone have somethingsigned by the Pope to show that relational theory in a RDBMS is necessary? I think that is what it really will take.
Oracle OCP DBA
-----Original Message-----
<mailto:DWILLIAMS_at_LIFETOUCH.COM> ]
Sent: Tuesday, March 25, 2003 9:29 AM
To: Multiple recipients of list ORACLE-L
Paula
I think their use of the term "object-oriented" maybe be incorrect. That
said, some new converts to object-oriented get carried away. Some even want to use Oracle in an object-oriented manner. In an effort to please everyone,
Oracle has even added object-oriented features to tables. I don't think they
are used much.
As Tom points out, the data model will need to support many purposes. One is reporting. If you don't normalize your data model, then it will be difficult or impossible to create reports.
Dennis Williams
DBA, 40%OCP, 100% DBA
Lifetouch, Inc.
dwilliams_at_lifetouch.com
-----Original Message-----
Sent: Monday, March 24, 2003 6:14 PM
To: Multiple recipients of list ORACLE-L
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
-- Please see the official ORACLE-L FAQ: http://www.orafaq.netReceived on Wed Mar 26 2003 - 03:33:39 CST
<http://www.orafaq.net>
-- Author: DENNIS WILLIAMS INET: DWILLIAMS_at_LIFETOUCH.COM Fat City Network Services -- 858-538-5051 http://www.fatcity.com
<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: ListGuru_at_fatcity.com (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). ********************************************************************* This e-mail message, and any files transmitted with it, are confidential and intended solely for the use of the addressee. If this message was not addressed to you, you have received it in error and any copying, distribution or other use of any part of it is strictly prohibited. Any views or opinions presented are solely those of the sender and do not necessarily represent those of the British Geological Survey. The security of e-mail communication cannot be guaranteed and the BGS accepts no liability for claims arising as a result of the use of this medium to transmit messages from or to the BGS. The BGS cannot accept any responsibility for viruses, so please scan all attachments. http://www.bgs.ac.uk ********************************************************************* ------_=_NextPart_001_01C2F37A.FBC3FB80 Content-Type: text/html; charset="iso-8859-1"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: Database Modeling- Normalization - Dinosaurs or What?</TITLE>
<META content="MSHTML 5.50.4807.2300" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=336222009-26032003><FONT face=Arial color=#0000ff size=2>We too
have been down this route - our experiences may just be relevant to you, Paula - and others.</FONT></SPAN></DIV>
<DIV><SPAN class=336222009-26032003><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=336222009-26032003><FONT face=Arial color=#0000ff size=2>From
an early stage we recognised the crucial importance of getting the design RIGHT. That meant at least TNF. Why important? Well, read the gurus, Chris Date (most particularly), David McGoveran, Hugh Darwen, Fabian Pascal. If you cannot see the sheer unassailable logic in their arguments, you are, frankly, in the wrong business.</FONT></SPAN></DIV>
<DIV><SPAN class=336222009-26032003><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=336222009-26032003><FONT face=Arial color=#0000ff size=2>Next,
go to your senior management, and (as we have) put the case that unless your data model is designed with due conformance to these principles, the integrity, and therefore correctness of your data CANNOT (and I stress) be guaranteed. Then allow them to reflect on the litigation that might result from an audit trail which reveals that the data supplied to a customer, on which costly decisions were subsequently made, was proven to be questionable, could not be assured (through our published quality control standards) to be correct, or even wrong in the first place...</FONT></SPAN></DIV>
<DIV><SPAN class=336222009-26032003><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=336222009-26032003><FONT face=Arial color=#0000ff size=2>We
pass on data to various organisations all over the world - we simply cannot risk giving incorrect data. If such weaknesses were detected, we would risk being closed down. That's why we have adopted strict standards in our design approach.</FONT></SPAN></DIV>
<DIV><SPAN class=336222009-26032003><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=336222009-26032003><FONT face=Arial color=#0000ff size=2>Here
in the UK we do not have such a strong inclination to seek recourse in the law as you folk in the US do (but the trend is that way, sigh) - I would think this must be a pretty strong argument over there too.</FONT></SPAN></DIV>
<DIV><SPAN class=336222009-26032003><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=336222009-26032003><FONT face=Arial color=#0000ff
size=2>peter</FONT></SPAN></DIV>
<DIV><SPAN class=336222009-26032003><FONT face=Arial color=#0000ff
size=2>edinburgh</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px"> <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Paula_Stankus_at_doh.state.fl.us [mailto:Paula_Stankus_at_doh.state.fl.us]<BR><B>Sent:</B> 25 March 2003 19:00<BR><B>To:</B> Multiple recipients of list ORACLE-L<BR><B>Subject:</B> RE: Database Modeling- Normalization - Dinosaurs or What?<BR><BR></FONT></DIV> <P><FONT size=2>I understand what database modeling is for, the different types of normalization and denormalization and the tradeoffs in different types of systems and ultimately to the data access of the system driven (should be ) by the business requirements. The problem is I don't think anyone that does development or provides COTS packages does and that negatively impacts my ability as a DBA to ensure data integrity. I was wondering if I was missing some boat. If anyone else was hitting this brick wall? If there is a way to make this point clear. I was thinking of even doing a prototype - this system versus that system - same app. code, same use of system, normalized and then denormalized so I could show why the heck normalization and RI on the database is the only real way to ensure data integrity. Then show all the ways the database integrity could go wrong. I feel like I have to prove why to use relational database design on a relational database engine built specifically for that purpose - GEEEZ!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Does anyone have something signed by the Pope to show that relational theory in a RDBMS is necessary? I think that is what it really will take. </FONT></P> <P><FONT size=2>Oracle OCP DBA</FONT> </P><BR> <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: DENNIS WILLIAMS [<A href="mailto:DWILLIAMS_at_LIFETOUCH.COM">mailto:DWILLIAMS_at_LIFETOUCH.COM</A>]</FONT> <BR><FONT size=2>Sent: Tuesday, March 25, 2003 9:29 AM</FONT> <BR><FONT size=2>To: Multiple recipients of list ORACLE-L</FONT> <BR><FONT size=2>Subject: RE: Database Modeling- Normalization - Dinosaurs or What?</FONT> </P><BR> <P><FONT size=2>Paula</FONT> <BR><FONT size=2> I think their use of the term "object-oriented" maybe be incorrect. That</FONT> <BR><FONT size=2>said, some new converts to object-oriented get carried away. Some even want</FONT> <BR><FONT size=2>to use Oracle in an object-oriented manner. In an effort to please everyone,</FONT> <BR><FONT size=2>Oracle has even added object-oriented features to tables. I don't think they</FONT> <BR><FONT size=2>are used much.</FONT> <BR><FONT size=2> As Tom points out, the data model will need to support many purposes.</FONT> <BR><FONT size=2>One is reporting. If you don't normalize your data model, then it will be</FONT> <BR><FONT size=2>difficult or impossible to create reports.</FONT> </P><BR><BR> <P><FONT size=2>Dennis Williams </FONT><BR><FONT size=2>DBA, 40%OCP, 100% DBA </FONT><BR><FONT size=2>Lifetouch, Inc. </FONT><BR><FONT size=2>dwilliams_at_lifetouch.com </FONT></P> <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>Sent: Monday, March 24, 2003 6:14 PM</FONT> <BR><FONT size=2>To: Multiple recipients of list ORACLE-L</FONT> </P><BR><BR> <P><FONT size=2>Guys, </FONT></P> <P><FONT size=2>The emphasis in many places I have worked is developing quick and dirty</FONT> <BR><FONT size=2>systems as quickly as possible and working with developers that don't seem</FONT> <BR><FONT size=2>to have very much understanding of Relational Database Theory but who prefer</FONT> <BR><FONT size=2>to program using flat files in relational databases - calling it</FONT> <BR><FONT size=2>"object-oriented" when it truly is not. Let us just say that it is highly</FONT> <BR><FONT size=2>denormalized. As a DBA I care about data integrity, extensibility and</FONT> <BR><FONT size=2>scalability but the up and coming esp. SQL Server developer types seem to</FONT> <BR><FONT size=2>operate in a world where this doesn't matter - just buy more hardware,</FONT> <BR><FONT size=2>denormalize to make the programming easier, etc. </FONT></P> <P><FONT size=2>I have been losing this battle. </FONT></P> <P><FONT size=2>So - what is your experience with this? </FONT></P> <P><FONT size=2>What about the idea of having everyone access all objects in the views so</FONT> <BR><FONT size=2>that if need be the DBA's could in fact still make physical changes to the</FONT> <BR><FONT size=2>schemas without a large amount of rewriting of code? - as a standard</FONT> </P> <P><FONT size=2>Living without normalization for most things - esp. small systems and w/o</FONT> <BR><FONT size=2>fk's except as they are maintained in the application for the sake of</FONT> <BR><FONT size=2>getting the application done quickly, cheaply.</FONT> </P> <P><FONT size=2>It turns my stomach but then I wonder about my own sanity - am I making too</FONT> <BR><FONT size=2>much out of nothing? What about these stovepipe systems? </FONT></P> <P><FONT size=2>Case in-point 100,000 row table for asset management - moving different</FONT> <BR><FONT size=2>types of addresses to a separate address table and moving different types of</FONT> <BR><FONT size=2>people to a person table. Developers are aghast at the performance</FONT> <BR><FONT size=2>implications. I am thinking perf. implications not real esp. with small</FONT> <BR><FONT size=2>amount but provides extensibility and RI with these reference tables instead</FONT> <BR><FONT size=2>of denorma. in multiple tables. They say mostly batch inserts/updates and</FONT> <BR><FONT size=2>batch reads - but then they say some OLTP. This is a SQL Server database.</FONT> <BR><FONT size=2>I think the separate reference tables provides only way for extensibility</FONT> <BR><FONT size=2>and data integrity. I say I will write for them a joined view. They say</FONT> <BR><FONT size=2>perf. implications. - AARRRGGHH!</FONT> </P> <P><FONT size=2>Oracle OCP DBA </FONT></P> <P><FONT size=2>-- </FONT><BR><FONT size=2>Please see the official ORACLE-L FAQ: <A target=_blank href="http://www.orafaq.net">http://www.orafaq.net</A></FONT> <BR><FONT size=2>-- </FONT><BR><FONT size=2>Author: DENNIS WILLIAMS</FONT> <BR><FONT size=2> INET: DWILLIAMS_at_LIFETOUCH.COM</FONT> </P> <P><FONT size=2>Fat City Network Services -- 858-538-5051 <A target=_blank href="http://www.fatcity.com">http://www.fatcity.com</A></FONT> <BR><FONT size=2>San Diego, California -- Mailing list and web hosting services</FONT> <BR><FONT size=2>---------------------------------------------------------------------</FONT> <BR><FONT size=2>To REMOVE yourself from this mailing list, send an E-Mail message</FONT> <BR><FONT size=2>to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in</FONT> <BR><FONT size=2>the message BODY, include a line containing: UNSUB ORACLE-L</FONT> <BR><FONT size=2>(or the name of mailing list you want to be removed from). You may</FONT> <BR><FONT size=2>also send the HELP command for other information (like subscribing).</FONT>
</P></BLOCKQUOTE><FONT SIZE=3><BR>
<BR>
*********************************************************************<BR> This e-mail message, and any files transmitted with it, are<BR> confidential and intended solely for the use of the addressee. If<BR> this message was not addressed to you, you have received it in error<BR> and any copying, distribution or other use of any part of it is<BR> strictly prohibited. Any views or opinions presented are solely those<BR> of the sender and do not necessarily represent those of the British<BR> Geological Survey. The security of e-mail communication cannot be<BR> guaranteed and the BGS accepts no liability for claims arising as a<BR> result of the use of this medium to transmit messages from or to the<BR> BGS. The BGS cannot accept any responsibility for viruses, so please<BR> scan all attachments. http://www.bgs.ac.uk<BR> *********************************************************************<BR>
</FONT>
</BODY></HTML>
------_=_NextPart_001_01C2F37A.FBC3FB80-- -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Robson, Peter INET: pgro_at_bgs.ac.uk 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: ListGuru_at_fatcity.com (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).
 |
 |