2 AlexeyPro:
Имеем базу данных(регистрация договоров купли продажи чего-либо) где надо вносить данные о клиенте(паспортные).

На самом деле имеет смысл сформулировать эту "большую" проблему разбить не более "маленькие", а то как-то не понятно, что именно нужно: правильная структура подмодели "договора-клиенты" (потому что Cat2 отклонился в эту сторону, а wara вообще талкует про очевидные вещи) или правильное хранение клиентов и доверенных лиц?

...Если клиент лично пришел то вносится его фио и паспортные данные, а если по доверенности то фио клиента и фио доверенного лица с паспортными данными. Как организовать БД? Т.е сегодня я пришел сам(как продавец) и внесли мои данные фио+паспорт, завтра я выступаю представителем продавца, после завтра я предствитель покупателя, или сам покупаю что либо.

А для доверенного лица в БД вносятся только его данные или также и данные доверителя, т.е. физ.лица, к-рое выписало доверенность? Если - Да, то самое простое:
сущность названная Клиент (поскольку все имеет отношение к клиенту в т.ч представитель), содержащая атрибуты:

ИД = <ИД физического лица (покупателя или представителя)>
...другие описательные атрибуты(паспортные данные,ИНН и тд)...
Тип_Клиента = "Непосредственный клиент" : "Доверенное лицо" : ...
ИД_Доверителя = <ИД доверителя, к-го представляет доверенное лицо> (т.е обратная связь)

Эта сущность также может описывать и Покупателя, только тогда еще потребуется и атрибут-флаг:

Тип_ФизЛица = "Клиент" : "Покупатель"

Но опять же лучше рассказать по-подробнее какие предполагаются отношения для физических и юр.лиц (продаваец, покупатель, представитель, посредник, доверитель и т.д)

Господа вы предлагаете разные модели, но вообще это все как-то напоминает строительство дома на зыбкой почве потому что не сформулирована сама предметная проблема а.к.а требования к модели данных, т.е по-пржнему сплошные вопросы\r
\r
2 AlexeyPro: \r
Имеем 3 таблицы \r
.....В итоге получается избыток внесенных данных. Т.е. я сегодня пришел сам и продал что то(внесли мои ФИО и паспортные данные в поля ФИО ), а завтра я продаю по доверенности и мои данные опять копируютя но в полях ФИО уже внесены ФИО доверителя, а мои ФИО заносятся в поле «ФИО доверенного лица». \r
\r
Вас ваша модель устраивает или вы ждете советы-критику по ней (действительно, смысла хранить избыточные данные нет)? Если не очень устраивает, то лучше рассказать по-подробнее какие требования к хранению данных о лицах\r
\r
2 wara: \r
А так нельзя?: \r
2.Люди (id_,Фамилия, Имя. Отчество, Город,Улица,Дом,Квартира,Номер паспорта, Кем выдан, FK типа людей)\r
- - - - - - - - \r
Хотя, пожалуй, таблица "типы" тут не нужна, так как, наверное, одно и то же лицо может выступать и как продавец и как покупатель и как доверенное лицо, а этот факт фиксируется в таблице договоров. \r
\r
Нет, в таблице Люди строки-люди будут дублироваться потому что если ввести ограничение Unique на ( Люди.Серия паспорта , Люди.Номер паспорта ) невозможно будет, например, добавить человека, к-рый является в одной сделке продавцом, а в другой покупателем.\r
Вообще это опять вопрос к предметной области, т.е к "AlexeyPro": нужно ли хранить данные лица в единственном экземпляре или нет. Если да, то вообще это правильнее, хотя и чуть сложнее реализовать (т.е будет нужна проверка существования записи). Если нет, то и такая схема подойдет\r
\r
Да, типы в отдельную сущность - это уже крутовато, их ведь всего 3, т.е 4 (с доверенным лицом продавца) и можно просто:\r
, где Person_Type - числовой признак, к-рый распознается в клиентском приложении\r
\r
3. Договор (id_dogovor, FK_люди (prodavec), FK_люди(pokupatel),FK_люди (кому доверяют), Данные договора) \r
Если поле FK_люди (кому доверяют) не заполнено, значит договор заключал сам человек... \r
\r
У продавца также может быть доверенное лицо:\r
...Продавцы(id_prodavec,Фамилия, Имя. Отчество, Паспортные данные, Доверенность, ФИО доверенного лица)\r
...а завтра я продаю по доверенности и мои данные опять копируютя но в полях ФИО уже внесены ФИО доверителя...

2 wara:
Не вполне понятно, зачем второй раз куда-то кого-то добавлять...

А глупый пользователь спрашивать не будет, просто возьмет и добавит, особенно если ему БД позволит

По-моему в моей модели нет никакого дублирования
.....В одном договоре FK Сидорова может стоять в поле "внешний ключ продавца", в другом - в поле "внешний ключ доверенного лица продавца". И никакого дублирования.

Я говорил не про Договора , про таблицу Люди . Представим следующую ситуацию для вашей модели в таблице Люди :

Вывод: признак типа в таблице Люди не нужен и тогда все будет ОК

2 Andrew Campball: \r
Мне кажется вы упустили один момент, что при заключении договора участвуют данные от 2 до 4 людей. \r
\r
Это ежу понятно. И что нам это дает кроме того, что нужно разрешить NULL на столбцах [Договор.Представитель_продавца] и [Договор.Представитель_покупателя]? :)\r
\r
Мое виденье решения такое:\r
....\r
не имеет смысла разделять человека по признаку (типизировать) \r
единственная проверка необходима при вводе людей, что бы не допустить \r
дубляжа. И вторая проверка - В договоре ИД людей не должны иметь совпадений \r
\r
Ваше видение и замечания совпадает с таковыми, уже изложенными выше "wara" (пост 6 мая 03, 17:43), где он предлагает почти тоже самое: 3. Договор (id_dogovor, FK_люди (prodavec), FK_люди(pokupatel),FK_люди (кому доверяют), Данные договора) и мной, где я как раз заметил по поводу ненужности типов людей и нужности ссылки на доверенное лицо (представителя) продавца, но все равно приятно, что вы записали это аккуратно :)\r
- - - - - - - - - - - - - - - - - - - - - - - - - - - -\r
Попробую предложить немного другую модель с ассоциативной сущностью и признаком лица, но без хранения нулей:\r
\r
Лицо \r
\r
Договор \r
\r
Договор_Лицо \r
\r
Эта модель также позволяет лицу выступать только в одной роли в одном договоре

2 Andrew Campball:
...либо
Договор_ИД (PK) (FK Догвор) (UNIQUE1)
Лицо_ИД (PK) (FK Лицо) (UNIQUE1)
Признак (UNIQUE1)

Только либо PK либо UNIQUE

1. Чем обусловлено такое занесение ? Если только склонением, то
есть програмки, компоненты которые склолняют ФИО.

Просто у них клиентская программа печатает документы поэтому нужно склонять. Подобных скриптов на TSQL, PL/SQL полно в Инете, хотя бы тот же "сумма прописью" - можно сделать на основе его

2 AlexeyPro:
И еще, если представитель от фирмы то название фирмы вносится в поле Фамилия, поля Имя и Отчество остаются пустыми, а ФИО доверенного лица заносится соотв. в поле ФИО дов. лица. В итоге имеем по 100 дубликаций паспортных данных(одинаковые)а поля ФИО и ФИО дов.лица разные.

Вы предложенные здесь модели рассматривали? В итоге имеем по 100 дубликаций паспортных данных(одинаковые)а поля ФИО и ФИО дов.лица разные... - вас что-то в них не устраивает, почему бы тогда не рассказать еще более подробнее о концептуальной модели, а то это уже напоминает турецкий марофон или бег на месте :)

2 wara:
Что представляет из себя этот самый "признак"? Просто текст?

Что душе угодно - числовой код, текст

...Не правилнее ли брать эти значения как FK из справочника, от которого мы дружно отказались - "типы". В таком варианте модель окажется расширяема на случай, если в Киеве изменятся условия заключения договоров. Сейчас, к примеру, в договоре фигурирует до 4 персон 4 разных типов....

Вполне резонно. Тем более, если модель должна быть расширяема и хочется ее "расширять", т.е изменять через БД, а не через клиентское приложение