2 softwarer +0.75 с уточнениями

П1 - Указанный вами пункт 1 не является главным недостатком предложенной схемы.
Т.к. в схеме просто нет сущностей «проверяющий» и «проверяемый» и нет ясного понимания причины их отсутствия, то нет и оснований для выставления этого момента на первое место. Такое его творческое видение предмета, что «проверяемые» с «проверяющими» вовсе не сущности, а просто атрибуты. Составит это проблему для его задачи или нет – предмет правдоподобного, но домысливания.
К недостаткам предложенной схемы это относимо с натяжкой.
Тем более, что превращение их в сущности не составляет формальной проблемы в предложенной схеме.

П2 про излишество N-N – по существу – почти наверно - да.
N-N может оказаться практически неприемлемым при переименовании атрибутов. Но может и не оказаться.

П3. В предложенной схеме это главный недостаток.
Может быть компенсирован
- либо организацией интерфейса пользователя ( не гарантирует от ошибок программиста и администратора БД)
- либо организацией нетривиальных условий проверки целостности c использованием check constraint (если выбранная субд сможет их поддержать) или триггеров ( с тем же условием.).

Либо изменением характера связей между сущностями и перепроектированием сущности [Результаты_проверки].

Так, если изменить связи между [Объекты_проверок] и [Проверки]
И между [Объекты_проверок] и [Справочник_атрибутов_по_объектам]
С неидентифицирующих на идентифицирующие, то использованные в схеме сущности
более-менее естественным образом можно представить так;


[Объекты_Проверок](АйДи, прочие_атрибуты)
PK(АйДи)

[Справочник_Атрибутов](PK,АйДи, прочие_атрибуты)
PK(PK,АйДи)
FK(АйДи) REFERENCES [Объекты_Проверок](АйДи)

[Проверки](PK,АйДи, прочие_атрибуты)
PK(PK,АйДи)
FK(АйДи) REFERENCES [Объекты_Проверок] (АйДи)


[Результаты_проверок](PK,PK_П,АйДи,PK_А, прочие_атрибуты)
PK(PK,PK_П,АйДи)
FK(PK_П,АйДи) REFERENCES [Проверки](PK,АйДи)
FK(PK_А,АйДи) REFERENCES [Справочник_Атрибутов](PK,АйДи)

Использованный переход с идентифицирующим зависимостям позволит явно указать дерево зависимости сущностей - [Справочник_Атрибутов] оказывается явным образом ведомым для сущности [Объекты_Проверок], а [Результаты_проверок] явным образом ведомая для сущности [Проверки]. Дополнительно, такой вариант оформления сущности
[Результаты_проверки] автоматически не даст возможности допустить ошибку связывания строки проверки с атрибутом чужого проверяемого объекта без использования как heck constraint, так и триггеров.
П3 – ключевой в рамках предложенной схемы (если принять характер связей как адекватный предметной области – независимо от справедливости такого принятия, то проблема именно в сущности [Результаты_проверки]).


П4 – вопрос вкуса/стиля

П5 – домысливание задачи за пределы предложенной для выявления недостатков схемы.

Cheerful CalfЗЫ 2 сосед. был акцессник. теперь неи
А зачем в проверках Объект_проверки_АйДи, если его по вашей схеме всегда можно узнать из справочника_атрибутов по результатам_проверки?



Извините – я не понимаю этого вашего вопроса.

АйДи в сущность [Проверка] разместили вы, а не я. Извольте посмотреть свой первый пост с вопросом и убедиться, что это не просто второй атрибут в нарисованной вами
сущности [Проверка], а еще и атрибут значение которого опредляется внешним ключом.
Решать – нужен он там или нет не мне, а правилам, определяющим, что собой представляет сущность [Проверка]. Наличие или отсутствие связи между [Объектами_проверок] и [Проверками] (и, соответственно, наличие или отсутствие атрибута АйДи в сущности [Проверка]) дает логически различные, несовместные (словесные) определения сущности
Я лишь предположил, что вы понимаете эти правила и стараетесь им следовать. Иначе говоря – предполагал, что способны произнести человеческими словами то, что рисуете квадратиками. Поэтому просто следовал тому определению, которое предопределяется вашим первым рисунком для сущности [Проверка].

Cheerful CalfА будит ли для абстракционных проверок правильная данная схема?
Не знаю, кто такие «абстракционные проверки», но ваша вторая картинка сохраняет полностью недостаток, указанный softwarer-ом как пункт 3.

Cheerful CalfДа.. Получается объект в проверке излишний. …
никакой логической цепочки к этому утверждению от утверждения

BULK INSERT...

в твоей схеме каждый атрибут привязан к одному объекту отношением Объект-<Атрибуты , поэтому связь Проверка>-Объект ВООБЩЕ не нужна - нужный объект можно "вытащить" по конкретному проверяемому атрибуту

...
провести нельзя. Нет здесь никакого «поэтому» и ничего не «получается» в отрыве от определения того, что представляет собой [Проверка] и как определяется это понятие.
Пусть нашей предметной областью будет ветеринарная станция и [Проверкой] будет акт определения состояния животных.
Очевидно, что всякого быка можно определить по номеру, выбитому на его копытах и
на этом основании мы не включаем в схему мигрировавшего из [Объектов] в первичный ключ [Проверки] АйДи.
Тогда акт проверки состояния животных может включать в себя множество животных – быков, коз, овец.
Для выделения характеристик одного конкретного животного потребуется фломастер, чтобы отделить характеристики его копыт, рогов и хвоста от характеристик других быков и прочих животных, попавших в заданную проверку, даже если эти характеристики сгруппированы по животным в отчете о проведенной проверке.
В случае, когда правила предметной йобласти именно так трактуют понятие (атомарной и неделимой) проверки, то, несомненно, атрибут АйДи Объекта (животного) не будет включен в сущность Проверка. Однако, это решение никаким образом не связано с фактом того, что нумерованные копыта однозначно определяют конкретного быка.
Наличие или отсутствие АйДи Объекта в Проверке (и, соответственно н- наличие или отсутствие стрелочки-связи между ними) есть собственная характеристика сущности [Проверка], никак не выводимая из свойств [Атрибутов_Объекта.]

Допустим теперь, что правила предметной области звучат диаметрально противоположно – атомарная и неделимая Проверка это всегда набор тестирования свойств одного и только одного объекта.
Для такого случая миграция атрибута Айди из Объекта в Проверку естественным образом может быть использована далее как ограничение набора доступных к тестировании. свойств именно заказанного к тестированию объекта.

Правда состоит в том, что существует уникальная система – Microsoft Access, которая даже в этом случае понимания Проверки сможет обеспечить целостность данных в строках проверки декларативным образом, без миграции АйДи из Объекта в Проверку – путем объявления подходящего Check Constraint для таблицы [Результаты_проверки]
Кроме того, что такое решение окажется плохо переносимо на другие системы ( перенос в любом случае потребует написания программного серверного кода, даже там, где он возможен схожим образом – в виде наложения условия на табличный набор данных),
в целом оно не вполне вписывается в общие правила декомпозиции предметной области на сущности.


Кстати, в свете BULK INSERT...

… поэтому связь Проверка>-Объект ВООБЩЕ не нужна - нужный объект можно "вытащить" по конкретному проверяемому атрибуту

...

особенно познавательно выглядит картинка двумя постами выше - с мигрировавшим в проверку ObjectID и сохраненной возможностью записи в акт проверки быка результата тестирования козьих рогов.

Да. Это.
вот еще - совсем забыл - без обид.
копыта - па добраму.

Cheerful CalfНу нимагу же я тут выложить все таблицы, выложил только наиболее беспокоящие. Что касается быков (как класса) - у меня на первой схеме было _имяпроверяемого_ - это соответсвует внешнему ключу в реальной схеме, который ссылается на справочник экземпляров класса (номер копыт). На второй картинке его не стало, так как связи между тремя (или четырьмя, при ответе не видно) таблицами это никак не влияет. А связи плохие, так как образуют "кольцо"...
про _имяпроверяемого_ - понял. Хорошо.


Что до остального - плохо дело.
Нет у меня формального образования и дипломов в области АйТи вообще и проектирования БД в частности.
Может быть поэтому я не понимаю, кто такое кольцо, почему так называется и какими свойствами обладает.

Обе ваши картинки трактуют таблицу [результатов проверки] как связывающую между собой проверки и атрибуты объектов. При этом это чистая M:N связь, позволяющая вписывать в строку результата проверки одного объекта атрибут чужого объекта.
Предположительно, результаты проверки должны быть согласованы выбранным для проверки объектом. Ваша схема не содержит такого явного согласования.
Это было опознано как недостаток именно вашего варианта схемы.
(впрочем, с такими недостатками живут , может быть, почти все системы).

В предложенном вам softwarer-ом и (независимо) мной варианте оформления таблицы результатов показано, как поддержать на уровне ограничений внешнего ключа соглаованность результатов проверки по отношению к проверяемому объекту.

Попробую еще раз описать существо предложенного изменения.
Никакого кольца там нет. Есть, точно так же, как и у вас - две связи со стороной "много" на таблице результатов. Одна связывает результаты с атрибутами, другая с проверками. [Проверка] в смысле "состоит из, содержит в себе" - является главной ведущей таблицей для результатов.
(Т.к. из результатов проверки составляются сами проверки, а не атрибуты.)

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


Честно говоря, я не знаю - что еще и какими словами сказать на эту тему.
За сим, с вашего позволения, я удалюсь из этого топика.

авторЕсли смотреть атрибуты на строки результатов

должно читаться так:

Если смотреть на атрибуты строки результатов