Очень схематично: нужно вести список клиентов и выполненные по ним заказы.
Клиенты представляются параметрами: код клиента, адрес (время от времени меняется, но нужно хранить в качестве шаблона для ввода).
Заказы: код клиента, код заказа, код адреса, код услуги1, код услуги2.
Естественно, создаются 2 справочника по адресам и услугам.
Итого все предстает в виде четырех файлов:
client (idClient, nAdres)
zakaz (idZakaz, nClient, nAdres, nUsluga1, nUsluga2)
adres (idAdres, tAdres)
usluga(idUsluga, tUsluga)

id-поля – автоинкрементные, VPF-8 .
Вопрос: проще хранить отдельными таблицами или стоит объединить в БД?
И как правильнее организовать отношения в ней? Ведь там получается отношение один-ко-многим, а также присутствует связь сразу двух файлов со справочником адресов.
Реально ли установить integrity rules через builder, чтобы целостность базы не нарушалась?

Я привел очень схематично условие задачи: клиент был представлен только одним полем: АДРЕС. Но в оригинале все представляется сложнее. Словно при Большом Взрыве, первоатом “АДРЕС” развернется в кучу пунктов, которые тоже получат собственную жизнь. Клиент - это пол, дата рождения, страна, город, край, район, улица, социальный статус, национальность, льгота, страховка, документ, местонахождение на момент заказа и много-много пунктов “ДА-НЕТ”. Как видно, неизменным остается только пол и дата рождения. Бывает, это тоже меняется. :)

( Разумеется, все, что можно, кодируется и хранится в справочниках, - нормализация, однако! Но комбинаторика пунктов «ДА-НЕТ» для кодировки вариантов убийственна.)
Причем, должна отслеживаться динамика их изменения во времени. При оформлении заказа, нужно вносить сразу все пункты. Они имеют значение на момент очередного заказа, как бы это ни было парадоксально! Собственно, заказ – мелочь по сравнению с обстоятельствами его осуществления. Следовательно, нужно где-то иметь шаблон. Брать за основу значения из последнего заказа нецелесообразно, т.к. часто бывает, что почти все меняется на момент 2-3-кратного заказа, а потом возвращается к прежнему шаблону.
Клиентов-20 тысяч. В общей сложности 100 заказов в день. Один заказ - это около 100 байт. Значит, экономия на каких-то жалких байтах, обернется полнейшим неудобством в работе.
Цель работы программы получение сводок в самых немыслимых разрезах и сочетаниях пунктов.

ВОПРОС 1.
Можно, конечно, отказаться от варианта хранения шаблона в справочнике по клиентам.
Тогда в справочнике по клиентам будет храниться необновляемая информация. Остальная переносится либо в отдельный файл шаблонов, либо в файл заказов. Во втором случае придется пометить запись с шаблоном неким значком ”Ш”, чтобы не считалась, как заказ. Правда, придется всякий раз отыскивать эту запись и копировать значения ее полей во вновь введенный заказ. Вы находите это более удобным?
Приведенная мною схема БД представляется мне оптимальной.


Про нормализацию мне известно. Но не всегда есть смысл за нею гнаться? Судите сами.

Что касается Вашего, Владимир М., предложения изменить структуру файла заказов, чтобы не ограничивать количество услуг, то нужды в том нет. Услуг, принципиально, не может быть больше 3. Обычно 2. Справочник услуг - сотня пунктов: 2 байта на код.
Экономия на 4 лишних байтах, обернется бОльшими потерями. Как у купца, что зажег червонец, чтобы найти оброненный пятак.
Все сводится к ВОПРОСУ: что предпочесть?
1) экономичный вариант: с 3 услугами в одной записи, датой-временем, кодом оператора, заказа и длинным сопровождающем перечнем «ДА-НЕТ»,
2) нормализованный: разбить эту запись на 1-2 или 3, по одной услуге в каждой + одинаковый код заказа в каждую запись,
3) комбинированный: помимо указанного разбиения ввести доп. файл, в который перенести строку с «ДА-НЕТ»+ код заказа

Под ЦЕЛОСТНОСТЬЮ БАЗЫ я понимал то, что машина сама будет сама удалять или запрещать удаление связанных записей, при удалении пункта из справочника.

ВОПРОС 3. Если я все free tables объединяю единую БД, то я получаю возможность машине за меня проводить эти действия, вместо обработки вручную? Удалил клиента, а все его заказы и все, что с ним связано, автоматом удалились без моего участия (или не удалились). Но в моем 1-м варианте получается, что к каждой записи нужно трижды привязать один справочник, что нелепо. Стало быть, нужно организовать еще пару курсоров из него. Что делать тогда с этой Referenty Integrity, я совсем не представляю.
Вот, и появляются мысли, а нужно ли все это загонять в БД, когда и так придется все самостоятельно выписывать.