Question

I have an assignment (so answer accordingly) which includes a many-to-many relationship between Animals and Zookeepers and I’ve set my SQL to create this relationship as the following:

CREATE TABLE Animal
( 
    animalID VARCHAR(5) NOT NULL PRIMARY KEY,
    -- more rows created here;
);

CREATE TABLE Zookeeper 
( 
    employeeID VARCHAR(5) NOT NULL PRIMARY KEY,
    -- more rows created here;
);

CREATE TABLE Animal_Zookeeper
(
    animal_id VARCHAR(5) NOT NULL,
    employee_id VARCHAR(5) NOT NULL,
    PRIMARY KEY (employee_id, animal_id)
);

-- insert data to Animal/Zookeeper tables

ALTER TABLE Animal_Zookeeper
    ADD CONSTRAINT FK_Animal_Zookeper_Relation_1
    FOREIGN KEY (animal_id)
    REFERENCES Animal(animalID)
    ON UPDATE RESTRICT
    ON DELETE RESTRICT,
    ADD CONSTRAINT FK_Animal_Zookeeper_Relation_2
    FOREIGN KEY (employee_id)
    REFERENCES Zookeeper(employeeID)
    ON UPDATE RESTRICT
    ON DELETE RESTRICT;

I’d like to check if this is the correct way to represent this relationship, or if I’ve missed something out as I’m not completely confident in how this is meant to behave (some clarification would be nice :D). I also have a Zero or More to One or More relationship to represent, is that simply done the same way as above?

Thanks in advance, as I said it’s for an assignment so don’t do it for me, just a bit of checking and some pointers would be helpful :p

Answer 1

That’s a proper many-to-many setup. For 0/1-to-many, you’d simply eliminate the animal_zookeeper table, and move the relationship into one of the parent animal and/or zookeeper tables, e.g.:

table animal {
  ...
  zookeeper foreign key ...
}

this would allow ONE zookeeper to be assigned to an animal, but the same zookeeper could have multiple animals assigned to them. If you require an animal to have a zookeeper, the zookeeper field is “not null”. If you want to have “orphaned” animals with no zookeeper, you allow nulls in the zookeeper field.

---

edit: set theory

view your two tables as sets of records: a set of zookeepers, and a set of animals.

This is the setup for a 1:many, where the animals are the many, and the zookeepers are the one. Note that the “one” doesn’t mean there’s only one zookeeper. The x:y stuff refers to RECORDS in the tables. one zookeeper record can have many animal records pointing at it. it doesn’t mean you’ve got one zookeeper taking care of the entire zoo.

 table animals {
     id
     zookeeper foreign key (zookeepers.id) default null
 }

 table zookeepers {
     id
 }

If you’ve got zookeepers “John” and “Jane”, then any given animal can have either (or neither) assigned to them.

 (many)    (one/none)
 tiger     John
 leopard   John
 monkey    (null)    <--monkey is orphaned, with no zookeeper assigned.
 elephant  Jane

So John is taking care of the tiger and leopard (one zookeeper, many animals), Jane has the elephant (a one:many that happens by chance to be a 1:1), and the monkey is all by itself with no one. But you’d never get John: monkey + Jane: monkey, because the animals can only ever have ONE zookeeper assigned to them.

To enforce a one:many, meaning no orphaned animals, you’d change your animal to be:

table animal {
   id
   zookeeper foreign key (zookeepers.id) NOT NULL
                                        ^^^^^^^^^
}

now the monkey cannot have “no one”, because the database enforces that you assign a zookeeper to the monkey. It’s still a 1:m, but you’ve now dissallowed the 0:m case.

1:m “there exists exactly ONE X which can have mutiple Y assigned to it”. e.g. one zookeeper can handle multiple animals, but each animal can have only one zookeeper assigned to them. or vice versa – one animal can have multiple keepers, but each keeper can only have one animal

m:m: wide open, multiple animals associated in varying combinations with multiple zookeepers. This is the most flexible setup, allowing any combination of zookeeper:animal relationships. But its side effect is that it’s difficult to prevent a 0:m situation, without adding CHECK CONSTRAINTS on the zookeeper_animal table, which not all databases support (e.g. mysql).