Здравствуйте!
Хочу спросить у Вас совета перед тем, как окончательно утвердить архитектуру базы данных. Собственно, вопрос будет один.

Постановка задачи:
Проектируется база данных и разрабатывается программа для работы с ней. БД содержит около 60 таблиц, связанных отношениями “один-к-одному” и “один-ко-многим”. Программа реализуется на Дельфи, связь с БД через ADO. В качестве СУБД выбрана Access 2003 с возможностью будущего перехода на SQL Server или др.

Иерархия объектов (по направлению “вниз”) в БД достаточно глубокая, например, связанные таблицы (от главной к подчиненной): “владелец” – “эксплуатант” – “эксплуатируемый объект” – “список участков эксплуатируемого объекта” – “список точек участков объекта” – “список оборудования на точке”. В данном примере, таблицы перечислены сверху-вниз, связаны отношением “один-ко-многим”, каждая имеет дополнительные связи и содержит расширенную информацию.

В программе обязательно будут использоваться следующие дополнительные возможности (кроме стандартных операций с данными):
1. Выполнение сложных запросов SQL с объединением данных нескольких таблиц с целью извлечь информацию для составления отчетов по таблицам БД.
2. Интерфейс программы будет поддерживать удобный механизм, реализующий для пользователя привычные режимы работы в режимах “мастер-деталь”, например, прежде чем добраться до окон с данными, последовательно выбрать “владельца” – “эксплуатанта” и “эксплуатируемый объект”. На уровне “эксплуатируемого объекта” данные будут уже “разветвляться” по множеству компактных связанных таблиц.
3. Потребуется ОДНОВРЕМЕННО представлять и редактировать несколько связанных по ключам таблиц в одном элементе DBGrid, для этого выполняется запрос SQL на объединение таблиц с использованием JOIN и вывод его результатов в DBGrid.

Вопрос:
Иерархия таблиц достаточно серьезная. Как поступить с первичными/внешними ключами – использовать сочетание полей или же вводить для сочетания полей уникальный код? Например: в таблице “эксплуатируемый объект” должны присутствовать поля “код владельца” и “код эксплуатанта” из таблиц уровнем выше. Во всех таблицах, подчиненных “эксплуатируемому объекту” будут присутствовать “код владельца”, “код эксплуатанта”, “код эксплуатируемого объекта” плюс еще параметр, обеспечивающий уникальность записей в таблице. Случай несколько утрирован и приведен для примера. Понятно, что “код эксплуатируемого объекта” может быть использован в качестве первичного ключа (или его части) и в качестве внешнего ключа (или его части) во всех подчиненных таблицах. Данный пример может быть перенесен на другие таблицы.
Вопрос – все же лучше кое-где использовать составные ключи или при первой же возможности вводить для сочетания столбцов свое уникальное значение (типа счетчика) и использовать в качестве ключа уже его? Существует еще несколько маленьких аргументов в пользу оставить кое-где составные ключи, которые могут вытекать из будущих требований заказчика, но критическими при принятии решения они не являются – просто облегчают работу и немного увеличивают надежность.
Спасибо
С уважением, Николай

apapacyПри этом если таблица1 хранит имеет составной первичнй ключ (char(100), char(100)) и 10 таблиц имеет внешним ключом ссылку на эту таблицу - то 100% будут содержать соответсвующее поле и в таблице1 и во всех таблицах, которые ссылаются на эту таблицу.

Вы, пожалуйста, не думайте, что все так уж запущено. В качестве первичных ключей (включая составные) выступают только числовые коды. Если нужно, значение, соответствующее коду, будет обнаружено в соответствующей таблице. Повторов информации, избыточности нет.

Вообще, я почерпнул много полезного из Вашего обсуждения. Еще существует некоторая проблема, скорее по стройности алгоритма (привожу абстрактный пример):

Таблица 1 "Владелец объекта":
код владельца (PK)
наименование владельца

Таблица 2 "Эксплуатант объекта":
код владельца (PK, FK на таблицу1)
код эксплуатанта (PK)
наименование эксплуатанта

Таблица 3 "Объект":
код объекта (PK)
код владельца (FK на таблицу2)
код эксплуатанта (FK на таблицу2)
................
наименование объекта

Таблица 4 "любая из множества таблиц на верхнем уровне характеристик объекта"
код объекта (PK, FK на таблицу 3)
код характеристики, например, номер детали (PK)
.................
значение 1
значение 2 и т.д.

Получается следующее:
- С таблицей 1 все нормально
- Таблица 2 содержит составной PK – программисты заказчика, а также функциональщики не решили объем функций, касающихся работы на данном уровне, но скорее всего он будет минимален – обеспечить пользователю возможность экспорта/импорта/создании копии эксплуатантов из другой или этой же БД. Естественно, копироваться будет эксплуатант со всеми подчиненными данными. Ради того, чтобы быстрее отработать возможность на прототипе – пока PK в таблице составной (им меньше пересечений искать при выполнении массы sql-запросов). Когда определятся – посмотрю, оставить так или сделать PK код эксплуатанта. Хотя, по-моему, здесь оба варианта нормальные – надо выбирать, что ближе задаче и надежнее с т.з. пользователя.
- Таблица 3 – последняя из таблиц, которая в себе содержит FK на код владельца и код эксплуатанта. В ней введен PK “код объекта” и во всех таблицах подчиненных уровней FK ссылаются на “код объекта” Таблицы 3 (я, естественно, упрощаю, т.к. уровней подчинения под объектом несколько, могут присутствовать составные FK).

Как с Вашей т.з., не слишком бросается в глаза, что Таблица 2 имеет составной PK, а в Таблицу 3 (и подчиненные) “волевым решением” введено ограничение на уникальный код объекта? Просто повторять еще код владельца и код эксплуатанта в каждой подчиненной таблице – перебор, я решил таким образом их отсечь пока на уровне объекта – в случае чего всегда можно восстановить по связям, тем более, что запросов и функций к владельцу и эксплуатанту будет гораздо меньше, чем на уровне объекта и его характеристик.

Выскажите свое мнение, пожалуйста. Ситуация упрощена для примера.
Давайте по этому примеру забудем первоначальную тему вопроса – ввести составной ключ или назначать простой и избавляться от составного – просто обсудим логику (отличия подхода) проектирования связей - сначала вроде выбран составной PK (Таблица 2), а потом на одном из уровней (Таблица 3) вводится простой уникальный, который уже используется дальше (иногда в составе составного – семейство таблиц 4).
Спасибо.

Сергей Васкецов собираетесь так сделать, или просто издеваетесь над присутствующими?
моя вина - не в том месте указал, почему такая необходимость возникла: Для создания прототипов некоторых функций программистами заказчика (для чего и понадобился такой грубый примитивный набросок верхнего уровня БД) с целью дать понять самому же себе (заказчику), какие функции ему нужны, а какие нет. В общем, типичная история. Я в это не вмешиваюсь - их требование (временное, зачем - не спрашивал) и их проблемы, как говорится. Ну не могут люди от программирования на VB под Excel отойти, да и на слово поверить не могут, хотят - пусть чего-то попробуют. Им после макросов, наверное, нелегко будет - выбрали, какой прототип таблицы им удобнее - не стал спорить. На каком ЯП будут прототипы свои делать - после этого даже не спрашивал - как сказали, так и сделал, но предупредил о "эффективности" таких проверок и таких прототипов. Парадоксов много. В окончательном варианте будет правильно. Заверили,что пробовать они будут только для себя, а программу все же нормальный коллектив будет делать. Ладно, это уже не по теме, всякие там организационные проблемы и внутриконторное соревнование. Я написал, что составной PK и FK в указанных Вами таблицах ненадолго в целях прототипирования, но некорректно. Не обращайте внимания на составной FK таблицы 3.

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