1 - Integrity is maintained using what is called a FOREIGN KEY constraint. A reasonable scenario might have you do these two tables:
Table Name: STATE_CODE
ID DESCRIPTION
=================
1 Alabama
2 Arkansas
...
50 Wyoming
Table Name: CUSTOMER
=====================
CUST_ID CUST_NAME CUST_STATE
100 AAA Company 1 --they are in Alabama!
200 ZZZ Company 50 --they are in Wyoming!
This answers your question #2: The state codes, not the full names, go in the CUSTOMER table in this example.
A typical script to impose this kind of structure on an existing layout would be like this:
--first, create the lookup table
CREATE TABLE STATE_CODE(
ID INTEGER NOT NULL
,DESCRIPTION VARCHAR(100) NOT NULL
,PRIMARY KEY(ID)
);
--now add a reference to the lookup table inside your existing table
--the REFERENCES part will **force** entries
--to have a matching entry in STATE_CODE
ALTER TABLE CUSTOMER ADD STATE_CODE_ID REFERENCES STATE_CODE(ID);
And this answers your question #1: That "REFERENCES" command will create a Foreign Key constraint that will force all entries in CUSTOMER.STATE_CODE to have a corresponding entry in the STATE_CODE table. After setting this up, if someone were to try this:
INSERT INTO CUSTOMER(CUST_ID,CUST_NAME,CUST_STATE)
VALUES(9000,'Martians',74837483748);
Then they would get an error message, and that faulty data would never get entered (unless, of course, you really did have a state with a code of 74837483748).