Помощь в проектировании БД

[sd]

Приветсвую.
Требуется помощь в разарботке модели БД почти с нуля.
Требования, предъявляемые к БД:
- Соответствие структуры базы данных требованиям третьей нормальной формы;
- целостность и непротиворечивость базы данных;
БД представляет собой учет транспортных средств на предприятии. Основная цель разработки БД, использовании ее потом в приложении на С++. Цель приложения - это мониторинг срока окончания дейтсвия ТО на ТС; страхового полиса; количества ДТП за определенный период по вине водителей, работающих на предприятии; срока действия мед. справки водителя; даты выхода водиетлей на пенсию.
Я прочитал различный материл в интернете и на основе прочитанного получилось вот что:
Сущности: водители, авто, документы, события.
Аттрибуты: водители (ФИО, дата рождения, стаж)
                  авто (номер, марка, модель, год выпуска, цевт)
                  документы (название документы, срок действия)
                  события (тип события, дата события, комментарии, затраты)
Дальше идут связи:
1) ВОДИТЕЛИ - ИМЕЮТ - ДОКУМЕНТЫ
Поскольку один водитель может иметь только одну медсправку, то связь 1:1
2) АВТО - ИМЕЕТ - ДОКУМЕНТЫ
Поскольку на одну машину приходится два документа (страховка, сретификат ТО), то связь 1:2
3) АВТО - ПРОИСХОДИТ - СОБЫТИЕ
Поскольку с одним авто может произойти множество событий, то связь 1:N
До этого не приходилось сталкиваться с проектированием БД, поэтому знаний в этой области мало и, как результат, составленная модель может оказаться очень некорректной.
Прокоментируйте, пожалуйста, модель которую я составил, укажите на недостатки и объясните как надо и почему.
Спасибо.

[RXL]

Событие (дата, тип события)
 имеет (возможно): водитель, авто

Для поиска события от авто или от водителя нужны соотв. индексы.

[Dale]

3) АВТО - ПРОИСХОДИТ - СОБЫТИЕ
Поскольку с одним авто может произойти множество событий, то связь 1:N

Тот день, когда столкнутся между собой два автомобиля этой организации, станет для базы данных последним.

[Qulac]

Вероятно, так как это зависит от оконечных требований, то может быть так.

Водитель может иметь несколько мед. справок с разным сроком начала и окончания действия, т.е медсправка - это сущность, отношение водитель - медсправка 1 ко многим.

Аналогично для документов авто и их отношений.
В принципе это все усложняет, но зато ближе к реальности.

[Aether]

Я бы всё таки сперва разобрался: какие у кого могут быть документы. Вот, например, у автомобиля единственный уникальный номер это VIN, государственный номерной знак может изменяться. Удобнее было бы записывать события, например, событие: регистрация в базе автомобиля: дата введения на учёт в БД, договор купли, птс, свидетельство о регистрации, распоряжение руководства об вводе в эксплуатацию... В любом случае лучше сразу уяснить некоторые организационные моменты на бумаге, согласовать их с руководством, потом подумать, как это оформить в БД. То есть, полный список исходных, и конечная цель в пунктах. Да, и ещё нюанс - километраж - влияет на техобслуживание, как вести его учёт - сменные вводы с одометра по факту?

[SCRIBE]

Нигде не увидел уникальных идентификаторов...

[Sla]

Не надо искать связей, когда их еще нет
Например
Документы - могут иметь признак ЧЕЛОВЕК/АВТО А сколько документов  не имеет значения, хоть 10, это не только  справка, но и.. трудовая, копии прав, и тд.
Также и документами на авто..

Кроме того должна быть таблица - вид документа, привязана к полю таблицы документы -
Т.е. страховой поли, документы на авто, документы на человека.

Человек - это не просто водитель, а также может быть и механик/слесарь
Т.е. соответственно - таблица специальности.

И т.д.

[Qulac]

Sla, слишком усложнено. К тому же дублируется информация, один раз в атрибуте человек/авто другой раз в самом отношении сущностей. Если документ уже имеет отношение к авто, то зачем ему еще атрибут? 
 Если так делать, то уж лучше имитация наследования документов, базовая таблица для всех документов и дочернии для конкретных документов.  Но это все лишняя сложность. 

[Sla]

Sla, слишком усложнено. К тому же дублируется информация, один раз в атрибуте человек/авто другой раз в самом отношении сущностей. Если документ уже имеет отношение к авто, то зачем ему еще атрибут? 
 Если так делать, то уж лучше имитация наследования документов, базовая таблица для всех документов и дочернии для конкретных документов.  Но это все лишняя сложность. 

Человек
id_people Василий Пупкин
Авто
id_auto Газ 66

Документ
id_doc1 id_people название человек
id_doc2 id_people название2 человек
id_doc3 id_auto название авто
id_doc4 id_auto название2 авто

Что здесь избыточное?

[Qulac]

Что такое в таблице человек и авто? Это не 3-я нормальная форма.  

[SCRIBE]

Человек (таблица slave)
id, s_type, s_firstname, s_secondname
Тип человека (таблица slave_type)
id, st_desc

Авто (таблица auto)
id, a_type, a_number, a_name, a_color, a_datecreate
Типы авто (auto_type)
id, at_desc

Документ (document)
id, d_type, d_name, owner_id (в зависимости от типа, ссылается на машину или человека)
Типы документов (document_type)
id, dt_desc

Событие (event)
id, e_type, e_desc, e_datebegin, a_id (id машины), s_id (id человека)
Тип события (event_type)
id, et_desc

Что-то типа)