Hey Michael I enjoyed your write-up.. especially a few db guys telling 'its relational because they are related'... I have also heard about it and the fact is that SQL the language for all the RDBMA is based on relational algebra and relational calcus and there in maths a rwo-column structure is called a relation.
During my acadamics I have studied the book by Korth and Sudarshan and i know er-diagram and normalization theoritically. My major experience is with production dbs (where the schema structure hardly changes) and the new assignment mostly involves data modelling.. and that too the model will not be freezed soon. it will change very frequently for quite sometime. Was wondering how can i manage db table/proc structure changes from different sectors and integrate them at the end of the day. I donot know erwin or designer etc. Thanks a lot Regards B S Pradhan ---------------------------------------------- On Tue, 21 Oct 2003 Michael Milligan wrote : >I would read some of C.J. Date's papers, or books from his "Relational >Database Writings" series. Also, there is a recent book called "Data >Modeling for Everyone" by Sharon Allen (Curlingstone Press) which is good. > >Most importantly, understand the fundamental principles of relational theory >as it pertains to relational databases. If you make an effort at this >you'll be ahead of 90% of developers/DBAs in this area, in my opinion. I've >heard "database experts" say that relational databases are called that >because they "relate" one table to another. This is false. It is called >"relational" because it is based on relational math, and because columns are >grouped together into special relations called relational tables. We call >them tables for short. > >The important thing to note here is this: the relationship that matters most >is the relationship among the columns of the SAME TABLE. That they really do >belong together is the most important thing to be sure of in data modeling. >They need to be "functionally dependent" on the same set of primary key >columns. Functional dependency is hugely important to understand and is the >basis of good data modeling. > >Some authors: > >C.J. Date >Fabian Pascal >Sharon Allen > >many others as well. > >HTH, > >Michael Milligan >Oracle DBA >Ingenix, Inc. >2525 Lake Park Blvd. >Salt Lake City, Utah 84120 >wrk 801-982-3081 >mbl 801-628-6058 >[EMAIL PROTECTED] > > > >This e-mail, including attachments, may include confidential and/or >proprietary information, and may be used only by the person or entity to >which it is addressed. If the reader of this e-mail is not the intended >recipient or his or her authorized agent, the reader is hereby notified that >any dissemination, distribution or copying of this e-mail is prohibited. If >you have received this e-mail in error, please notify the sender by replying >to this message and delete this e-mail immediately. >-- >Please see the official ORACLE-L FAQ: http://www.orafaq.net >-- >Author: Michael Milligan > 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).
