Программисты баз данных, помогите нормализовать реляционную базу данных.⁠⁠

рублей за 1000, на выходных могу сделать

блин, пляши от "функций", т.е. более чем очевидно, что таблицу нужно "развалить" на три:
1 - контрагент (нарколыга, шмот в лобарт притаранивший);
ID клиента - PK (первичный ключ)

2 - договор (номер договора, когда принесли, контрольные сроки, кто принял);
Ключем выступает либо договор, либо (что более жизненно) ключ составной (Номер+Дата договора, т.к. каждый год нумерация начинается по новой, годно, если в номере договора "зашивают" номер года).
Если ключ составной - то добавь поле ID, автогенерируемое (тупо инкремент или GUID).
Обязательно вставить поле ID клиента (ClientID), чтобы договор можно было связать с контрагентом, а контрагента с N договоров. Да, если я правильно помню терминологию (более 10 лет 1Сничаю, там такой фигней редко заморачиваешься), то в этой таблице ClientID объявляется FK (внешний ключ). Если СУБД более или менее воспитанная и ты в ней не только таблицу написал, но и диаграмму связей, то она не даст тебе "грохнуть" запись контрагента до того, как ты "погрохаешь" записи о его договорах.

3 - состав договора (перечень принятого шмота);
Ну тут все поля, прямо относящиеся к конкретной шмотке договора (наименование, оценочная стоимость, инвентарник и т.д. когда пришла, когда "ушла").
Инвентарник (рег. номер) - PM (первичный ключ, автогенерируемый).

Есть поле "Договор" (ID договора или его номер, смотря что ты в 2ой таблице за PK принял), чтобы N вещей можно было связать с конкретным договором. Поле это, конечно же FK.

за 100 рублей могу только ссылкой поделиться))

курсовая за стольник, ахуенный ты еврей

Сумма?)

Сумма и сроки?)