www.databasejournal.com/sqletc/article.php/1474411
March 22, 2002
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.
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.
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 6 Next |
|
|
|
|
|
|