зоранее благодарень ByKiSНе понял, так чтоли?

IMHO лучше сделать многие-ко-многим DutiesByOrders

создаем ордер tblOrders
определяем ответсвенность tblAssignments
назначем ответственных tblEmployeesдык у автора так и есть. tblAssignments=tblOrderWorkers (так кажется называется - почему SQL.ru в режиме поста не показывает картинки:( ).

ByKiSЭто гут? Если да, то что делать ключами в tblOrderJobs ?вполне. Судя по примеру, всех может быть несколько. Значит, unique (OrderID ,DutyID, Employee ).
По бизнесу, могут быть еще данные - типа доля в доле - два манагера, одному 85% другому 15% манагерских. Контроль за 100% программно.

4НФ это "если в отношении существует нетривиальная многозначная зависимость...." а где она в Вашем случае? Нема.. Кстати МЗ по определению не может существовать в одиночестве - ей нужна пара. Ограничение типа "Для данного Заказа обязательны все Стадии" не есть МЗ, если другие атрибуты зависят комбинации Заказа + Стадия, а не от чисто Заказа.

Скорее всего, Программист-Любитель имел ввиду то, что Вы следом и нарисовали. И называется оно EAV.

Ищите и фильтруйте:)
http://www.sql.ru/forum/actualtopics.aspx?search=EAV+select&bid=36
http://www.compress.ru/Archive/CP/2001/8/9/

Верной. В том смысле что именно так выглядит альтернатива 12 полям-параметрам в таблице.

ByKiSВот вы меня вторым предлжением ну просто убили :) Это просто к тому, что выбор альтернативы пока не очевиден. Возможно, резервирование N полей решает все проблемы c параметрами жалюзей на 10 лет вперед.
Но коль и параметров, и типов ожидается неопределенно много и связи между ними множественные, то собственно по EAV.
1)Один параметр может быть применим к нескольким типам объектов. Лучше
отдельно
словарь параметров:
Parameters(Prm_id,Prm_name,Prm_type,Prm_defaultvalue) PK(Prm_id) Unique(Prm_name)

сочетания типов объетов и параметров:
BlindTypeParameters (BTP_id, Prm_id,BlindType_id, PrmBT_defaultvalue) PK(BTP_id) Unique(Prm_id,BlindType_id)

И костяк из 5 таблиц: Словарь типов объектов, словарь параметров, ограничитель сочетаний типов объетов и параметров, таблица объектов и таблица значений собственно на месте. Иногда можно обойтись без ограничителя, но в вашем случае это будет слишком грубая схема.

Дальнейшее развитие:
2)остался открытым вопрос о контроле комбинаций (Blind_Id, Prm_Id) в таблице значений SelledBlindParameters - я бы переименовал ее в SelledBlindParamValues - на соответсвие ограничителю BlindTypeParameters. Можно делать процедурно - все равно для работы с EAV-структурами, а то и с базой вообще, пишется некое API. Но за счет дополнительного расхода памяти можно и декларативно.
3)Для значений сделать несколько полей по типам значений: NumberValue, DateValue... - уйти от свертки/развертки значений в строку.
4)Добавить интеллекта в части единиц измерения. Пока предполагается, что единица измерения - часть наименования.
5)Значения могут быть ссылками на объекты. Параметры такого типа уже суть связи.
6)Ну и история - некотрые параметры возможно меняются во времени.

Как говориться, выберите по вкусу:)

ByKiS1) Или сделать ещё одну подобную таблицу для жалюзей и туда писать? Ведь менеджер/консультант/т.п. у всех жалюзей одного заказа только один.ИМХО разумно. ByKiS
2) По поводу параметров а что оставить в самой таблице Жалюзи? Только цена и количество? А ширина, высота, цвет тоже идёт доп-параметры? (Кто-то может заказть только механиз для жалюзи - у него нет высоты, только ширина/длина)Есть эмпирическое правило 80/20. В применении к этому случаю - оставьте то, что заполнено в 80% из 100. Но еще раз EAV - средство масштабирования по числу параметров. Так ли много их ожидается?

ByKiS авторТак ли много их ожидается?Сколько их ожидается неизвестно - может 2, может 30, а может и 12.
EAV не всегда оправдан?До 30 ИМХО вполне можно обойтись без этого.

Ну да. Кстати, словарь параметров и ограничитель сочетаний типов объетов и параметров в этом случае тоже полезен.

ByKiSХочу просто уточнить про EAV (правильно ли я понял эту систему) - все объекты тогда надо хранить в одной таблице? То есть все мои "жалюзи", "серии квитанций", "сотрудники", "монтажи" сольются в одну таблицу?Нет, для каждого достаточно крупного класса - свои таблицы значений - это нормально. Теоретически, все можно впихнуть в обобщенную модель из 4 таблиц. Это даже полезное для развития навыков проектирования БД упражнение, но у Вас наверняка есть и более актуальные дела. ByKiS

И сообственно само сообщение.

В данный момент, все БП очень неопределённые и каждый день что-то появляется новое, что-то пропадает. Если делать ТЗ - его надо было бы переписывать каждый день. К примеру, по "клиентам" сейчас надо только ClientID, ClientName, DepartmentID. В ближайшем будущем потребуется CompanyName, CompanyCode, ClientAddress, CreditLimit, PaymentTerms. Что потребуется не в ближайшем будущем (год-два) сказать никто не может. Тоже самое касается и остальных сущностей. Но среди них есть такие, атрибуты которых известны и менятся не будут, скажем "Единицы измерения", "Способ оплаты", "Вылюты", "Оплаты" и тому подобное.
Пока это все достаточно типичные ситуации - организационная структура, должности и люди, адрес/средство связи, действующие лица и их роли в отношениях ByKiS
В связи с чем два вопроса:

1) Приходится сослаться на сказанное
ModelR (тута)До 30 ИМХО вполне можно обойтись без этого.
BULK INSERT (Microsoft Access)за стенкой МоделеР говорит, что при общем возможном количестве атрибутов порядка 30-ти - нет смысла заморачиваться на Тенцера и EAV - игра не стоит свеч - это не такие уж простые в реализации подходы...
лучшее враг хорошего
На теперешний день ещё не продумал схему базы, а первые таблицы уже надо переделывать. Насколько сказанное Вами остаётся верно учитывая сказанное мной в этом сообщении? EAV опарвдает себя в данном случае? Может есть что-то кроме ЕАV?

2) Возможен ли (и будет ли он разумным) вариан использования смешанной системы? Имею ввиду оставить таблицы для некоторых объектов, атрибуты которых меряться не будут, и сделать таблицы по принципу EAV для всего остаоьного? Или оставить часть атрибутов в таблицах, а часть вынести за её пределы (как предлагал Програмист-Любитель) ?Да, так и делают. Начиная с некоторого уровня сложности в системе невозможно иметь только один вариант. По принципу "и пиво тоже" дают возможность в родной таблице в плоском виде хранить наиболее общие и интенсивно эксплуатируемые параметры (ОРГАНИЗАЦИЯ - Название, юридическа форма) плюс ролевые таблицы, подтипы для более специальной информации (КЛИЕНТ - кредитные лимиты, скидки). И там и там можно предусмотреть резервные поля и механизм их настройки. Плюс EAV для всего, что со временем не влезет в плоскую часть.
Все умножить на историю по необходимости.

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

На что еще стоит потратить немного времени - на систему имен.
Если таблица с суррогатным ИД называется <X>s, то ее суррогатный ключ <X>ID.
Вместо BlindStatusHistory в систему лучше вписывается BlindStatusEvents.

ByKiS ModelRЕсли таблица с суррогатным ИД называется <X>s, то ее суррогатный ключ <X>ID. Можно пример? Один мой тепершний и как его назвать?
Вместо OrderBlinds просто Blinds (других ведь все равно нет), ключ остается BlindID.