views:

770

answers:

5

In a database I'm having to design for MS Access, I have a table called "Measurements", which stores certain measurement parameters (Measured Values, Std Deviation, etc.) - each row has an integer ID as its primary key.

Other tables then link to this measurement table using foreign key relationships. Some tables contain two different "measurementID" fields, which both link to this one measurement table. However, each measurement should only ever be linked to by one of these fields.

How can I enforce a uniqueness constraint over several fields in several tables? Be there a way?

+3  A: 

Microsoft ACE/Jet engine does not support triggers, which is how you would normally implement this type of functionality.

EDIT: As pointed out by @onedaywhen, JET 4.0 onwards does support check constraints, but it is not simple to implement an xor type constraint across two columns.

If you are using Access Forms, you could implement the before update event of the form and check your constraint criteria.

Mitch Wheat
You say "Microsoft does not support triggers". Well, Microsoft SQL Server does, so presumably this is a typo and you meant to say "The Microsoft ACE/Jet engine does not support triggers) which is correct.
onedaywhen
Myself, I'd normally use table-level CHECK constraints to implement this type of functionality if the product in question supported them. Happily, ACE/Jet does support them.
onedaywhen
@onedaywhen: it was a typo! Thanks!
Mitch Wheat
Well, it is not simple to implement an xor type constraint across two *tables* in any SQL product. Hugh Darwen calls this a distributed foreign key (see http://www.dcs.warwick.ac.uk/~hugh/TTM/Missing-info-without-nulls.pdf).
onedaywhen
@onedaywhen: nice link (that talk was given at the uni I graduated from)
Mitch Wheat
A: 

Mitch is right about what's possible in Access. However, assuming you have a BL somewhere, this is edging into what's legitimate as a Business Rule. That's what I'd most likely do.

le dorfier
What do you mean by a "BL"? Business Layer?
Smashery
Yup. In other words, don't do this validation in the database.
le dorfier
I don't think Mitch is right about what's possible in Access because he hasn't considered table-level CHECK constraints, probably because he uses SQL Server which doesn't have them so, like me, has to resort to triggers to implement data constraints (yuck!)
onedaywhen
A: 

Given that you are designing this database. Are you sure your table structures are following standard normalisation rules.

It sounds an unusual structure for a row in table A to be able to reference two rows in table Measurements depending upon which A.row field you are looking at. I get the feeling that the data in table Measurments really needs to be split into two or more tables.

+3  A: 

Such constraints can indeed be implemented in ACE/JET using CHECK constraints.

The person who said they would usually use triggers for this kind of thing possible isn't aware of the difference between CHECK constraints in ACE/Jet and SQL Server respectively: in SQL Server they cannot include subqueries, meaning they cannot refer to values in other rows in the same table or to other tables, whereas in ACE/Jet there can.

In an ideal (but as yet AFAIK non-existent) SQL-92 product, the uniqueness described would be implemented using an ASSETION, being at the schema level. Because CHECK constraints are table-level and are only checked when the table on which they are defined are UPDATEd or INSERTed, you would need to put appropriate CHECK constraints on all the referencing table (the same would apply to SQL Server triggers). Here's a quick example:

CREATE TABLE Parent 
(
   parent_ID INTEGER NOT NULL IDENTITY UNIQUE, 
   data_col INTEGER NOT NULL
)
;
CREATE TABLE Child1
(
   parent_ID INTEGER NOT NULL
      REFERENCES parent (parent_ID), 
   data_col INTEGER NOT NULL
)
;
CREATE TABLE Child2
(
   parent_ID INTEGER NOT NULL
      REFERENCES parent (parent_ID), 
   data_col INTEGER NOT NULL
)
;
ALTER TABLE Child1 ADD
   CONSTRAINT child1__no_dups_in_child2
   CHECK (NOT EXISTS (
                      SELECT * 
                        FROM Child1 AS C1
                             INNER JOIN Child2 AS C2
                                ON C1.parent_ID = C2.parent_ID
                     ))
;
ALTER TABLE Child2 ADD
   CONSTRAINT child2__no_dups_in_child1
   CHECK (NOT EXISTS (
                      SELECT * 
                        FROM Child1 AS C1
                             INNER JOIN Child2 AS C2
                                ON C1.parent_ID = C2.parent_ID
                     ))
;

However, I'm wondering if you have subclasses (i.e. each entity represented by an ID can be typed), in which case you should be able to use FOREIGN KEYs and row-level CHECK constraints (or Validation Rules if you are more comfortable with the MS Access interface than SQL DLL that is required for CHECK constraints). The logic will be easier to implement than table-level CHECK constraints, just watch for cycles in CASCADE referential actions. Here's another simple example:

CREATE TABLE Parent 
(
   parent_ID INTEGER NOT NULL IDENTITY, 
   child_type VARCHAR(4) NOT NULL, 
   CONSTRAINT child_type__values 
      CHECK (child_type IN ('Boy', 'Girl')), 
   UNIQUE (child_type, parent_ID)
)
;
CREATE TABLE Girls
(
   parent_ID INTEGER NOT NULL, 
   child_type VARCHAR(4) DEFAULT 'girl' NOT NULL, 
   CONSTRAINT girl_child_type__must_be_girl
      CHECK (child_type = 'girl'),
   FOREIGN KEY (child_type, parent_ID)
      REFERENCES Parent (child_type, parent_ID), 
   data_col INTEGER NOT NULL
)
;
CREATE TABLE Boys
(
   parent_ID INTEGER NOT NULL, 
   child_type VARCHAR(4) DEFAULT 'boy' NOT NULL, 
   CONSTRAINT boy_child_type__must_be_boy
      CHECK (child_type = 'boy'),
   FOREIGN KEY (child_type, parent_ID)
      REFERENCES Parent (child_type, parent_ID), 
   data_col INTEGER NOT NULL
)
;
onedaywhen
A: 

I am myself wary of triggers and check constraints, mostly because I've developed most of my apps without them (Access/Jet and MySQL/MyISAM). I agree with BobClegg that this sounds like a supertype/subtype situation. In that case you'd use a join table with a unique index on the foreign key and a column indicating which type of measurement it was. The unique index on the FK would prevent the addition of a second type. It would also mean you wouldn't have empty fields in your main record. Certainly one empty numeric field is not a storage problem, but two fields that are exclusive always looks like a design error to me.

David-W-Fenton