I don't know what this concept is called... something about uniqueness

Question

Let's say I have a single table of maintenance tasks. The table will have the following columns:
auto incrementing index
task_name
step_number
step_name
So, each task will have a series of steps to complete it. I want to make sure that the step_numbers are not duplicated within a given task. Of course, one way to solve this would be to have a separate table for each maintenance task, which would only hold records for each step. But I don't know the number of different tasks, and will likely be adding more and more, so adding a new table each time doesn't make sense. So, is this "uniqueness" something that I would have to check on the client side before updating, or is there a way to create a database constraint such as this. Oh, and if this concept has a specific name, I would appreciate hearing it.

Answer 1

Well, then let's break down Centinul's response some.
Normalization - see the wiki: http://en.wikipedia.org/wiki/Database_normalization
His 'tasks' table uses a task_id as the primary key; can also be known as a surrogate key. The 'task_name' column is now just data. If you want to change the 'data' you can change it without affecting the relations between the tables. Change it to anything you want, as often as you want; it is just data. If you make 'task_name' the primary key you 'lock it in' and then it becomes part of the table-to-table relationship. Worse the task_name value would need to be duplicated in the task_steps table; you can't change it easily in either table because the tables are linked together.
The 'tasks' table becomes a master table of all possible tasks with one record for each task.
CREATE TABLE tasks
( task_id   NUMBER        PRIMARY KEY
, task_name VARCHAR2(255) NOT NULL
);His 'steps' table is, similar to the tasks table, a master table of all possible steps with one record for each possible task. There is no information in this table about what task a step belongs to. A step might be part of several tasks, or part of no tasks at all. As with the tasks table the step_id is just a number to make the records unique; it might be assigned a value using a sequence generator (Oracle sequence). The numbers don't have to be consecutive, can be positive, negative, include decimal values; the only requirement is that they are unique within the table.
The step_name now becomes just a piece of data. Feel free to change the name whenever you like. The new name will show up in new queries but it won't affect the relationship between tables.
CREATE TABLE steps
( step_id   NUMBER        PRIMARY KEY
, step_name VARCHAR2(255) NOT NULL
);Now the part that can look confusing at first. His task_steps table is known as an intersect table. It 'intersects' the tasks table and the 'task steps' table. The records in this table are what associates a step in the step table with a task in the tasks table.
To tie the two tables together he has added a 'task_id' column to reference a record from the tasks table and has added a 'step_id' column to reference a record from the steps table. Each corresponding REFERENCES clause tells Oracle to enforce this relationship. So you CANNOT add a record with a task_id value that does not exist in the tasks table. And you CANN"OT add a record with a step_id value that does not exist in the steps table.
But, you said that you want each step that is associated to a task to have a number from 1 to n; this means that each task will have a step one.
So Centinul added a 'step_order' column; this is the same as what you referred to as 'step_number' so you could use your name if you like. The UNIQUE CONSTRAINT on task_id and step_order tellsl Oracle that the combination of these two values MUST BE UNIQUE within the table. Oracle still doesn't care what the values are as long as they are unique. You can have step_order values of 2, 6, -1 and Oracle won't care; that is a business rule that Oracle won't enforce without more help.
{code}
CREATE TABLE task_steps
( task_id NUMBER NOT NULL REFERENCES tasks(task_id)
, step_id NUMBER NOT NULL REFERENCES steps(step_id)
, step_order NUMBER NOT NULL
, CONSTRAINT task_steps_pk PRIMARY KEY (task_id, step_id)
, CONSTRAINT task_steps_uk UNIQUE (task_id, step_order)
{code}
He gave you the best example possible for what you want to do.
To add a record to the task_steps table:
1. select a record that already exists from the tasks table and use the task_id value of that record
2. select a record that already exists from the steps table and use the step_id value of that record
3. determine the largest value of step_order that already exists in the task_steps table, add 1 to it, and use the new value for step_order for the new record.
Step #3 is the tricky part since there may be several users or processes trying to add records at the same time. This is why this business rule is often only used for applications such as INVOICE and LINEITEM wher the same process creates the parent (INVOICE - task for your example) and all of the LINEITEM (task_steps) records at the same time.
Does that help explain what Centinul was suggesting?