If you find this mail confusing, ignore it :-)

Just a point of (anally retentive) theory: Relational databases are not
called relational databases because you can put 'relationships' in... this
is an unfortunate clash of terminology...  In fact, a Table is a
representation of what in mathematics they call a 'Relation', e.g.

Table: Person
  Name
  Age
  Height

The person relation is a subset of NxRxH where N is the set of all names, A
is the set of all Ages and H is the set of all Heights.  (x is the
'cartesian product' operator).



> -----Original Message-----
> From: Enzo Zaragoza [mailto:enzaux@g...]
> Sent: 10 October 2001 21:46
> To: sql language
> Subject: [sql_language] RE: Normalization
> 
> 
> thanks Duncan!!!!  I was just wondering how do you create relational
> databases in SQL?  Because in Access there is an option of Relational
> databases where you drag & drop the tables then create 
> relational links for
> each tables (whether cascade delete or cascade updates).  
> Thanks Duncan it
> is well explained, I'll just have to read this deeper so that I'll
> understand it further =) GodSpeed!!!
> 
> Enzo
> 
> 
> ----- Original Message -----
> From: Duncan Faulkner
> To: sql language
> Sent: Thursday, October 11, 2001 3:51 AM
> Subject: [sql_language] RE: Normalization
> 
> 
> Hi enzo,
> 
> Normalisation.
> The term Normalisation refers to a process used to design relational
> database tables. When done properly; it will help to minimize 
> duplicated
> information in your databases, reducing the size of databases 
> and making
> them more efficient. Minimizing duplicate also helps to reduce the
> occurrence of inconsistencies where data is duplicated in 
> different tables
> but with different values.
> 
> Normalisation often involves splitting a table into two or 
> more smaller
> tables, then using a rejoining process, setting up a 
> relationship between
> the tables to put them back together. This process called nonloss
> decomposition, is the process of splitting a table into two 
> or more smaller
> tables that contain like or grouped data without losing information.
> 
> First Normal Form.
> The first normal form is based on two-dimensional tables, 
> rows and columns.
> There can only be one value for each attribute or column 
> heading. This means
> that you do not stuff a column. Each column will have only one meaning
> representing only one attribute.
> For example: When creating a table for employee records, you 
> would be in
> violation of first normal form if you placed both first and 
> last names in
> the same column.
> 
> Second Normal Form.
> The goal of second normal form is to remove duplicate data. 
> There will often
> be data that is stored in a different table so the detailed 
> data is not
> required. There will be some situations where duplicate data 
> is acceptable.
> For example: There will be duplicate data in an Invoice Date column.
> 
> Third Normal Form.
> No nonkey column can depend on another nonkey column. In 
> other words, the
> goal of third normal form is to remove all data that does not directly
> relate to the entity's primary key. These unrelated values 
> are known as
> independent attributes. They need to either be moved into 
> their own table
> (with their own primary key)or eliminated.
> 
> Forth Normal Form.
> Independent one-to-many relationships between primary key and 
> nonkey columns
> are not allowed.
> For example: Invoice items would be stored as seperate rows 
> rather than
> multiple columns in one row.
> 
> Fifth Normal Form.
> Tables must be broken down into the smallest possible units. 
> No data may be
> duplicated anywhere in the system. This form is seldom 
> employeed because of
> the number of small tables it would generate.
> 
> Denormalisation.
> The goal of normalisation is to break data down into small 
> interrelated
> tables. The problem is that trying to follow the 
> normalisation forms too
> closely can lead to an overly complex design. The time taken 
> to combine the
> data from the tables can actually slow performance.
> 
> In real world applications, your goal is to reach a workable 
> compromise,
> usually somewhere between the third and forth normal forms. 
> Not only wil
> this make your database design less complex, it will likely reduce the
> complexity of the objects you need to create to support your database
> application. Often the best way to approach normalisation is 
> to first create
> your normalised design, then selectively denormalise as appropriate.
> One advantage of normalisation is that it reduces the chance for error
> during data updates. In a normalised design, you only have to 
> update one
> location since the data only appears once in the database.
> 
> 
> You wanted to know what normalisation was!!!!!!
> 
> Duncan
> 
> > -----Original Message-----
> > From: Enzo Zaragoza [mailto:enzaux@g...]
> > Sent: 10 October 2001 15:10
> > To: sql language
> > Subject: [sql_language] Normalization
> >
> >
> >
> >    About my table looking de-normalised, uhhm  I have read 
> some article
> > regarding database normalization but still it doesnt make 
> any sense to me.
> > When can you say whether a table is normalised or 
> de-normalised?  What is
> > normalization in the first place?
> >
> > thanks,
> >
> > Enzo