Помогите создать стуктуру базы данных.
Есть прибор который устанавливается на автомобиль и шлет на сервер сигналы (координаты автомобмиля и т.п.).
Сигнал выглядит так:
1010000002,20030217132813,121.646060,25.061725,20,157,133,7,0,11,15,0.096,0.000
Где первая цифра это номер прибора, вторая дата, далее координаты и др.данные.
Прибор при поставке имеет номер и пароль.

Мне надо к прибору привязать как минимум для начала водителя и автомобиль. Я предпологаю следущие таблицы в базе:
1. Таблица прибора:
ID прибора (пер. ключ)
Код прибора (заводской например, 1010000002) NOT NULL + UNIQUE тип integer
Пароль прибора (тоже заводской, например 0001) NOT NULL + UNIQUE тип строка
Примечание 

2. Таблица автомобиля:
ID автомобиля (пер. ключ)
Марка
Номерной знак
ID прибора (FK внешний ключ)
Фото автомобиля
Примечание
* в таблице автомобили ID прибора это внешний ключ к полю ID прибора таблицы приборы. Характеристики ключа FK при удалении записи из таблицы приборы ON UPDATE SET NULL ON DELETE SET NULL т.е. устанавливаем ID прибора в таблице автомобили в NULL при удалении записи из таблицы номер 1. И вообще нужен ли этот FK?

3. Таблица водителя:
ID водителя (пер. ключ)
Фамилия NOT NULL – надо?
Имя
Отчество
Дата рождения
Телефон 1
Телефон 2
Адрес водителя
Фото водителя
Примечание
* нужно ли какое-то дополнительное поле для связи таблиц в таблице водители?

4. Таблица сигналов идущего от прибора (лог сигналов):
ID пер.ключ, + 13 колонок для строки: 1010000002,20030217132813,121.646060,25.061725,20,157,133,7,0,11,15,0.096,0.000

5. Таблица связей:
ID связи (пер.ключ)
ID прибора NOT NULL
ID автомобиля NOT NULL
ID водителя NOT NULL
* нужны ли FK и эта таблица?

Помогите описать стуктуру. Спасибо. 

1. Я бы изменил направление связи автомобиль-прибор. Прибор не может стоять на нескольких автомобилях, только на одном. Потому прибор должен ссылаться на автомобиль на котором он установлен.

2. Как соотносится водитель и автомобиль? К водителю приписана одна машина или несколько? Несколько водителей могут быть приписаны к одной и той же машине?

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

Cпасибо за ответ!
Значит согласно вашей первой рекомендации должно быть так:

1. Таблица прибора:
ID прибора (пер. ключ)
Код прибора (заводской например, 1010000002) NOT NULL + UNIQUE тип integer
Пароль прибора (тоже заводской, например 0001) NOT NULL + UNIQUE тип строка
ID автомобиля /*(внешний ключ) какие у него характеристики ON UPDATE SET NULL ON DELETE SET NULL?*/
Примечание 

Правильно?  

По второму пункту точного ответа нет. Допустим программа будет работать в разных организациях. В одной организации за водителем может быть закреплен один автомобиль, а в другой несколько автомобилей. Наверное не возможно создать базу которая бы устраивала все организации сразу. 
Давайте расмотрим самый простой вариант: за одним водителем закреплена одна машина, как тогда будет выгядить правильная структура БД?

Добавлено @ 14:45
Akina, можно примерную схему? У меня проблемы с моделированием БД, серого вещества не хватает.   

Это сообщение отредактировал(а) Лена - 2.7.2008, 14:45

Лена, СУБД не указана, поэтому общий пример:
1. Таблица прибора:
ID прибора (пер. ключ)
Код прибора
и т.д.

2. Таблица автомобиля:
ID автомобиля (пер. ключ)
Марка
Номерной знак
и т.д.

2. Таблица прибор-автомобиль:
ID (пер. ключ) автоинкремент
ID прибора FK
ID автомобиля FK
Дата установки прибора not null default current_datetime
Дата снятия прибора
дополнительные поля при необходимости (кто ставил, где ставили и т.д.)

Аналогично связка водитель-автомобиль.

Deniz, большое спасибо, сейчас буду осмыслять!  
А база PostgreSQL...

P.S.
А какие правильные характеристики должны быть у внешних ключей в таблице прибор-автомобиль?
ON UPDATE SET NULL ON DELETE SET NULL?


Это сообщение отредактировал(а) Лена - 2.7.2008, 15:08

Вот вариант новый:

1. Таблица прибора:
ID прибора (пер. ключ)
Код прибора (заводской например, 1010000002) NOT NULL + UNIQUE тип integer
Пароль прибора (тоже заводской, например 0001) NOT NULL + UNIQUE тип строка
Примечание 

2. Таблица автомобиля:
ID автомобиля (пер. ключ)
Марка
Номерной знак
Фото автомобиля
Примечание

3. Таблица автомобиль_прибор:
ID автомобиль_прибор (пер. ключ)
ID прибора FK (связь с таб. приборы)
ID автомобиля FK (связь с таб. автомобили)
Дата установки прибора NOT NULL default current_date
Дата снятия прибора
Примечание
* характеристики обоих FK это ON UPDATE CASCADE ON DELETE CASCADE

4. Таблица водителя:
ID водителя (пер. ключ)
Фамилия NOT NULL – надо?
Имя
Отчество
Дата рождения
Телефон 1
Телефон 2
Адрес водителя
Фото водителя
Примечание

5. Таблица водитель_автомобиль:
ID водитель_автомобиль (пер. ключ)
ID водителя FK (связь с таб. водители)
ID автомобиля FK (связь с таб. автомобили)
Примечание
* характеристики обоих FK это ON UPDATE CASCADE ON DELETE CASCADE

6. Таблица сигналов идущего от прибора (лог сигналов):
ID пер.ключ, + 13 колонок для строки: 1010000002,20030217132813,121.646060,25.061725,20,157,133,7,0,11,15,0.096,0.000

Что не правильно и что добавить?  

Я бы не стал накладывать уникальность на пароль прибора - мало ли...   

Вариант для проверки:   

1. Таблица прибора:
ID прибора (пер. ключ)
Код прибора (заводской например, 1010000002) NOT NULL тип integer
Пароль прибора (тоже заводской, например 0001) NOT NULL тип строка
Примечание 

2. Таблица автомобиля:
ID автомобиля (пер. ключ)
Марка 
Номерной знак NOT NULL + UNIQUE тип строка
Фото автомобиля
Примечание

3. Таблица автомобиль_прибор:
ID автомобиль_прибор (пер. ключ)
ID прибора FK (связь с таб. приборы)
ID автомобиля FK (связь с таб. автомобили)
Дата установки прибора NOT NULL default current_date ???
Дата снятия прибора
Примечание

4. Таблица водителя:
ID водителя (пер. ключ)
Фамилия NOT NULL 
Имя
Отчество
Дата рождения
Телефон 1
Телефон 2
Адрес водителя
Фото водителя
Примечание

5. Таблица водитель_автомобиль:
ID водитель_автомобиль (пер. ключ)
ID водителя FK (связь с таб. водители)
ID автомобиля FK (связь с таб. автомобили)
Дата закрепления водителя на автомобиль NOT NULL default current_date ???
Дата открепления водителя
Примечание

6. Таблица сигналов идущего от прибора (лог сигналов):ID пер.ключ, + 13 колонок для строки: 1010000002,20030217132813,121.646060,25.061725,20,157,133,7,0,11,15,0.096,0.000

Все FK имеют ON UPDATE CASCADE ON DELETE CASCADE. Правильно? Не надо для FK NOT NULL?
Правильно ли NOT NULL default current_date устнавливать в таб. 5 и 3?
Какие еще есть замечания?    

Это сообщение отредактировал(а) Лена - 2.7.2008, 17:18

С синтаксисом PostgreSQL не знаком.
Я бы вообще запретил удалять записи из всех таблиц - 1, 2, 4, 6 это как справочники, а в 3 и 5 есть "Дата окончания действия записи", история таки нужна.
обязательно, о чем может говорить запись в таблицах 3 и 5, например такая: ID водителя - 1, ID прибора - null ? Она просто не имеет смысла.
NOT NULL правильно, про текущую дату, вопрос к бизнес логике. Можно и не делать.
Из замечаний: предлагаю в таблице автомобиля вынести "марку автомобиля" в отдельную таблицу или несколько, смотря что там предполагается вести. Например: TOYOTA COROLLA - добавить 2 таблицы, производители и модели, привязанные к производителям.

Для упрощения работы с актуальными данными, чтобы не лопатить каждый раз по датам, в таблицу 3 (и возможно 5) просто ввести поле актуальности записи. Индексированное есссно.

Cпасибо! Есть над чем подумать...  

и что в этом поле будет храниться? 0/1?
И зачем тогда этот неэффективный индекс?
Можно конечно и удалять записи(для уменьшения кол-ва записей), если прибор сняли с машины, но я считаю, что история важнее чем небольшое уменьшение производительности и увеличение текста SQL запроса:

Deniz, что эффективнее:

или

?

Akina, надеюсь мы не будем вступать в перепалку?   
Я не говорил про эффективность запроса, только про создание индекса.
Причем я даже написал, что производительность немного ухудшится.
Если автор решит использовать статус записи(валидность) я не против, но индекс создавать не надо, оптимизатор все равно не будет его использовать, только дополнительные расходы на его содержание.