John W. Colby
jcolby at colbyconsulting.com
Thu Mar 13 16:57:00 CST 2003
Charles, >It would be a very simple application, or a very astute individual, where all the relationships are obvious from the beginning. I would agree with that. >By that I mean as you go along you will discover that one or more of the tables you have already designed needs to be split since some of the data fields apply only to the subject of the table while other data fields does not. This implies that you are not designing tables using the simple rule "is it a property of the object this table models". Each table models an object. Banks, Account Holders, accounts, checks etc. There is no reason to be putting account holder info in the account table or vice versa. Account Holders are people, Accounts are not. The only case I can think of where you might put data in a table when it belongs in another is in the case of a property that ends up plural. Addresses are an example. A company has an address. Oops, it can have TWO (or 10) addresses. In this case, the data (addresses) ARE still properties of the object (company) it's just that the company can have several of that property (addresses) and thus they have to be a child table. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-admin at databaseadvisors.com [mailto:accessd-admin at databaseadvisors.com]On Behalf Of Wortz, Charles Sent: Monday, March 10, 2003 2:48 PM To: accessd at databaseadvisors.com Subject: RE: [AccessD] normalization question Susan, Whether you do it on paper or on the PC, it usually is an iterative process, at least in my experience. By that I mean as you go along you will discover that one or more of the tables you have already designed needs to be split since some of the data fields apply only to the subject of the table while other data fields does not. And you will notice that some data fields split over several tables should be combined into one table. It would be a very simple application, or a very astute individual, where all the relationships are obvious from the beginning. Charles Wortz Software Development Division Texas Education Agency 1701 N. Congress Ave Austin, TX 78701-1494 512-463-9493 CWortz at tea.state.tx.us -----Original Message----- From: Susan Harkins [mailto:harkins at iglou.com] Sent: Monday 2003 Mar 10 12:50 To: accessd at databaseadvisors.com Subject: Re: [AccessD] normalization question Yes, I agree... but in the process of making your paper lists -- when? ----- Original Message ----- From: <Mwp.Reid at Queens-Belfast.AC.UK> To: <accessd at databaseadvisors.com> Sent: Monday, March 10, 2003 1:34 PM Subject: RE: [AccessD] normalization question > > you do it before turning the PC on when your designing the structures. > The theory is that the data is normalised before you actually create > the tables > physically. > > Martin > > (<: > > > > Quoting Charlotte Foust <cfoust at infostatsystems.com>: > > > I tend to do it at the time so I don't forget. Of course, as we get > > older our memory ... Uh, what was I saying? <vbg> > > > > Charlotte Foust > > > > -----Original Message----- > > From: Susan Harkins [mailto:harkins at iglou.com] > > Sent: Sunday, March 09, 2003 3:36 PM > > To: AccessD at databaseadvisors.com > > Subject: [AccessD] normalization question > > > > > > When you remove a field to another table (for whatever reason), do > > you immediately create the foreign key in the original table, or do > > you wait until you've completely normalized each table and then > > return to the tables and insert all the foreign keys then? > > > > I tend to do it later because the nature of a single field can > > change. > > > > Does anyone know if the relational model requires a particular > > routine? > > > > Just curious. > > > > Susan H. _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com ---------------------------------------------------- Is email taking over your day? Manage your time with eMailBoss. Try it free! http://www.eMailBoss.com -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 3584 bytes Desc: not available URL: <http://databaseadvisors.com/pipermail/accessd/attachments/20030313/43d9081c/attachment-0001.bin>