Free Newsletters:
DatabaseDaily  
Database Journal
Search Database Journal:
 
MS SQL Oracle DB2 Access MySQL PostgreSQL Sybase PHP SQL Etc SQL Scripts & Samples Links Database Forum DBA Videos
internet.com

» Database Journal Home
» DBA Videos
» Database Articles
» Database Tutorials
MS SQL
Oracle
MS Access
MySQL
DB2
» RESOURCES
Database Tools
SQL Scripts & Samples
Links
» Database Forum
» DBA Jobs
» Sitemap

News Via RSS Feed



follow us on Twitter

Marketplace Partners
Be a Marketplace Partner

internet.commerce
Be a Commerce Partner


















Mariposa Bot Shipped With Vodafone Smartphone

IT Job Market Heating Up: Report

Bing Makes Strides But Momentum Stalls

internet.com
IT
Developer
Internet News
Small Business
Personal Technology

Search internet.com
Advertise
Corporate Info
Newsletters
Tech Jobs
E-mail Offers


Database Journal | DBA Support | SQLCourse | SQLCourse2







Database Administrator - SQL Server (PA)
Next Step Systems
US-PA-King of Prussia

Justtechjobs.com Post A Job | Post A Resume

Featured Database Articles

SQL Etc

March 22, 2000

Database Normalization

By Ian Gilfillan

By now some of you are familiar with the basics of using in your cgi scripts. Many of your databases will be small, with one or two tables. But as you become braver, tackling bigger projects, you may start finding that the design of your tables is proving problematic. The SQL you write starts to become unwieldy, and data anomalies start to creep in. It is time to learn about database normalization, or the optimization of tables.

Let's begin by creating a sample set of data. Imagine we are working on a system to keep track of employees working on certain projects.

Click here for table 1.

A problem with the above data should immediately be obvious. Tables in relational databases, which would include most databases you'll work with, are in a simple grid, or table format. Here, each project has a set of employees. So we couldn't even enter the data into this kind of table. And if we tried to use null fields to cater for the fields that have no value, then we cannot use the project number, or any other field, as a primary key (a primary key is a field, or list of fields, that uniquely identify one record). There is not much use in having a table if we can't uniquely identify each record in it.

So, our solution is to make sure that each field has no sets, or repeating groups. Now we can place the data in a table.

Click here for table 2.

Notice that the project number cannot be a primary key on it's own. It does not uniquely identify a row of data. So, our primary key must be a combination of project number and employee number. Together these two fields uniquely identify one row of data. (Think about it. You would never add the same employee more than once to a project. If for some reason this could occur, you'd need to add something else to the key to make it unique).



Go to page: 1  2  3  4  5  Next  

Tools:
Add databasejournal.com to your favorites
Add databasejournal.com to your browser search box
IE 7 | Firefox 2.0 | Firefox 1.5.x
Receive news via our XML/RSS feed

SQL etc Archives








Latest Forum Threads
SQL etc Forum
Topic By Replies Updated
What does * mean tonyd 1 March 11th, 09:07 AM
Searching by time and grouping by numer padstar 4 February 22nd, 02:01 PM
Finding max and sum in a row yesmein 1 February 13th, 08:57 AM
Selecting rectangle from large 'continuous' matrix? ropstah 1 January 20th, 03:38 PM









The Network for Technology Professionals

Search:

About Internet.com

Legal Notices, Licensing, Permissions, Privacy Policy.
Advertise | Newsletters | E-mail Offers