Uniqueness Constraints in MS Access

Question

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?

Answer 1

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
)
;

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.