DB design answers:
1) No, since the values won't be unique, you can't have a unique key. You can have an index (or several) to help with the sorting.
2) Dunno, never used that.
3) This isn't a one-to-many or a many-to-one relationship either way, is it... You can have the same people in several incidents? And several people in the same incident? Yup, for many-to-many relationships you need a "junction" table, like "people_and_incidents". Two columns, "person_id" and "incident_id", foreign keys to the (primary-key) ID columns of those tables.
1) Nope. At least, not unless you put a default value ("N/A" or something, whatever) in the "Unit" field. But then it's of course not really optional anymore.
But, above all: The main thing you need to do is put an integer ID field -- autoincrement, sequence, whatever it's called in your (R?)DBMS -- in pretty much every table. That's your primary key, and what you refer to as a foreign key from other tables.
2) Dunno, never used that.
3) This isn't a one-to-many or a many-to-one relationship either way, is it... You can have the same people in several incidents? And several people in the same incident? Yup, for many-to-many relationships you need a "junction" table, like "people_and_incidents". Two columns, "person_id" and "incident_id", foreign keys to the (primary-key) ID columns of those tables.
1) Nope. At least, not unless you put a default value ("N/A" or something, whatever) in the "Unit" field. But then it's of course not really optional anymore.
But, above all: The main thing you need to do is put an integer ID field -- autoincrement, sequence, whatever it's called in your (R?)DBMS -- in pretty much every table. That's your primary key, and what you refer to as a foreign key from other tables.
