Optymalny model bazy danych - czegoś mi brakuje.

Witam, jestem początkującym programistą (w sumie to juniorkiem), na stud. podyplomowych z "Aplikacji biznesowych w JAVA EE". Realizuje temat, zadanie zaliczeniowe "System ewidencji kompetencji pracownika" - wiadomo wymagań specjalnych nie ma, prosta aplikacja CRUD. W końcu się trenuje jeszcze. No i teraz start - uczyli nas pracy w NetBeans, zaczynam od stworzenia sobie bazy danych (nie pytam jakich komend użyć, co kliknąć to łatwo odszukać). Myślę nad zaprojektowaniem dobrej, możliwie jak najbardziej optymalnej bazy pod mój program:

CREATE TABLE "CECHERZ".USERS
 (
	"ID_USER" INTEGER default 321 not null,
	check ("ID_USER" >= 321),
	"LOGIN" VARCHAR(12) not null unique,
	"PASSWORD" VARCHAR(20) not null,
	"E_MAIL" VARCHAR(40) not null unique,
	"ISADMIN" BOOLEAN default false not null,
	primary key ("ID_USER")
 );
CREATE TABLE "CECHERZ".WORKERS
(
	"NAME" VARCHAR(30) not null,
	"SURNAME" VARCHAR(60) not null,
	"DATE_OF_BIRTH" DATE not null,
	"ADDRESS" VARCHAR(120) not null,
	"E_MAIL" VARCHAR(40) not null,
	"PHONE_NUMBER" VARCHAR(15) not null,
	"ACTIVATION_DATE" DATE not null,
	FOREIGN KEY ("E_MAIL") REFERENCES USERS("E_MAIL")
);
CREATE TABLE "CECHERZ".QUALIFICATION
(
	"ID_USER" INTEGER default 321 not null,
	check ("ID_USER" >= 321),
	"PROGRAMMING_LANGUAGE" VARCHAR(120),
	"FRAMEWORKS" VARCHAR(300),
	"FOREIGN LANGUAGES" VARCHAR(120),
	"SOFTWARE" VARCHAR(300),
	"OTHER SKILLS" VARCHAR(500),
	FOREIGN KEY ("ID_USER") REFERENCES USERS("ID_USER")
)
CREATE TABLE "CECHERZ".EDUCATION
(
	"ID_USER" INTEGER default 321 not null,
	check ("ID_USER" >= 321),
	"BEGIN_EDUCATION" DATE,
	"END_EDUCATION" DATE,
	"NAME_OF_SCHOOL" VARCHAR(120),
	"KIND_OF_SCHOOL" VARCHAR(120),
	"SPECIALIZATION" VARCHAR(120),
	FOREIGN KEY ("ID_USER") REFERENCES USERS("ID_USER")
);
CREATE TABLE "CECHERZ".TRAININGS 
(
	"ID_USER" INTEGER default 321 not null,
	check ("ID_USER" >= 321),
	"BEGIN_OF_TRAINING" DATE,
	"END_TRAINING" DATE,
	"CONTENT_TRAINING" VARCHAR(500),
	"HOWLONG_TRAINING" SMALLINT,
	FOREIGN KEY ("ID_USER") REFERENCES USERS("ID_USER")
);
CREATE TABLE "CECHERZ".HISTORY_OF_WORK
(
	"ID_USER" INTEGER default 321 not null,
	check ("ID_USER" >= 321),
	"BEGIN_WORK" DATE,
	"END_WORK" DATE,
	"COMPANY" VARCHAR(60),
	"POSITION" VARCHAR(60),
	"CHARACTER_OF_WORK" VARCHAR(120),
	 "ACQUIRED_SKILLS" VARCHAR(500),
	FOREIGN KEY ("ID_USER") REFERENCES USERS("ID_USER")
); 

Środowisko mi łyka tabelki (niby nie ma problemu), nie trudno jednak zauważyć, że można by to lepiej zaprojektować. Nie mieliśmy zajęć z projektowania baz, a nie mogę zacząć tworzenia aplikacji bez dobrze skonstruowanych tabel. Przepraszam, że nie ma ładnych diagramów ale nie chciałem tracić czasu na nowe aplikacje. Proszę o uwagi, każda będzie dla mnie na wagę złota.

1.Nie masz po co na lewo i prawo pisać wielkimi literami.
2.Osobiście wolę nazewnictwo user_id, work_begin, school_name etc.
3.Nie powinieneś przypisywać domyślnej wartości na id użytkownika.
4.Prawa userów wydziel do osobnej tabeli - raz, że to myślenie o przyszłości aplikacji, to dwa: umożliwi wykonanie Ci ładnie ACLów. Ewentualnie zrób ACLe na grupy i wtedy zapisuj w tabeli użytkownika id grupy, do której należy.
5.Łącz pracowników po id użytkownika, nigdy po mailu.
6.Wybierz jakiś algorytm hashujący i pod niego ustaw długość pola z hasłem.
7.Jeżeli konto nie zostało aktywowane, jaka wartość ma być w polu activation_date?
8.Z całą pewnością nie może być howlong_training ;) training_time jak już.

To by było tyle, z tego co zauważyłem.

Wiele już zostało napisane, od siebie dodam:

    "NAME" VARCHAR(30) not null,
    "SURNAME" VARCHAR(60) not null,

Zamień na parę:
FIRST_NAME
LAST_NAME

lub trochę mniej intuicyjne:
GIVEN_NAME
SURNAME

https://en.wikipedia.org/wiki/Middle_name

Dziękuje za podpowiedź odnośnie nazw, zmienię je na bardziej intuicyjne. Co jednak z resztą tabel? Czy spinanie ich kluczem obcym w tym wypadku ma sens? W założeniu powinno być tak, że jeden pracownik może mieć wiele szkoleń, no ale wiersze powinno też dać się zidentyfikować jako osobne. Robiłem ten "szkic" intuicyjnie stąd moje pytanie czy ten podział i zapis relacji ma sens. Dosyć trudno mi znaleźć odpowiedź jak zaprojektować bazę pod konkretny przypadek zastosowania.

Każda tabela powinna mieć swoje PK (np. z ID). Bez wyjątku.

Klucz obcy ma sens, lecz faktycznie - szkolenia powinny mieć jeszcze własne idki, tak samo jak treningi, edukacja, kwalifikacje oraz historia pracy.
Plus nie zapomnij o przypadku, gdy ktoś chodzi jednocześnie na studia i do pracy, wtedy jeszcze nie ukończył edukacji, zatem END_EDUCATION może być nullem.