У Сахавата налицо смешение разных понятий «класс, тип» и дурная наследственность EAV c его недоопределенностью.

Никогда в один классификатор не могут попасть элементы множеств с разной структурой (структурой – слово заезженное, тут в смысле «ступени», декартова произведения на множестве всех объектах-экземплярах).

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

Такие классы-множества сами являются объектами, обладающими идентичностью. То есть могут быть в одном множестве с экземплярами (это _мод, у которого «классы не являются сущностями»). Но, разумеется, в другом смысле, что необходимо выделить атрибутикой таких объектов.

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

В принципе никто не мешает туда же «в классификацию» добавить и проекции по определенным элементам (например, состав объекта ДСЕ25 по отношению «Спецификация»), но их необходимо выделить атрибутивно, так как это тоже ни к каком смысле не подмножества, ну и имя отношения и роль в нем придется указать.


Типы данных, свойства, объекты (экземпляры), классы это принципиально разные вещи, обращаться с ними надо по-разному. У Сахавата «тип» - это сборная солянка из всего, и отношение это сборная солянка из всего.

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

Короче, не расчищено. В топку такие конструкторы.

Чтобы EAV стала работоспособной, необходимо добавить более жесткие метаструктуры и навесить атрибутику на них, чтобы потом работать со всем правильно, а не складывать Сахавата и 52.

Сахават Юсифов,

авторСахават бы с удоволствием стер бы с словаря слова - класс, свойство, тип и т.д. Каждый понимает что хочет под этими словами.


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

авторНа самом деле нет никаких классов. Класс - это шаблонное видение классифициующего под который кастируются реальные объекты.

Тут никто не возражает против этого. Классов, свойств в природе нет. Имеются объекты. Субъекты вольны их раскладывать в определенные кучки по определенным правилам (например, свойствам объектов).
Чтоб не путаться, так и говорят, что класс может иметь структуру (набор свойств и значений) и совокупность объектов этой структуры.
Классы - это понятия. Каждое понятие имеет уникальный идентификатор (термин), чтобы не было синонимии, может (но не обязано) иметь структуру понятия и объем понятия (в частном случае нулевой, если под понятие не подходит не один объект).

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


авторВ любом случае класс= (Имя, идентификатор) + {свойств для отбора объектов}. Это при классификации по существующим свойствам объектов. (Select * where имеется {свойств для отбора объектов})

Обобщим до наличия свойства, а не только классификация по значению.
У тебя тут только 2 задачи, есть масса других, для чего используют классы и классификации:
- размещение объекта в класс по свойствам и значеиям;
- отбор, автоматическое формирование множества, объема понятия, соответствующего классу.

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


авторДругой вид классификации - агрегирующий, классификатор является СВОЙСТВОМ для всех агрегрированных объектов, у которых изначально НЕТ такого свойства. Например Мои_Друзья(перечень идентификаторов классов и отдельных объектов).
Нет возражений. То же можно сделать и с классами, имеющими свойства и значения - присваивать их объектам класса. Тут нет никакой принципиальной разницы, чтобы выделять эту модель классов в какие-то "агрегирующие". Все классы агрегирующие, то есть представляют множество своих объектов.

авторЭти два вида классифицирующих объектов составляет единый навигационный классификатор со множеством классифицирующих входов.

Не понятно. На картинке у тебя слева - это только классы? Экземпляров там нет?
Кроме того, как я говорила, там есть лишнее - то, что туда не может попасть. Типы данных, свойства, отношения разной структуры могут образовывать только отдельные непересекающиеся классификаторы.

авторКлассификатор не дерево.
А где я предлагала дерево. Я изначально предлагала множественный классификатор, которые отобразим на дерево.

авторОтнощение такой же класс как и остальные. Единственное отличие - объекты этого класса не имеют осмысленного имени. Нельзя
ИД1,Работает1, чел1, цех1
ИД2,Работает2, чел2, цех2

Совсем не такой же. Отдельный, причем каждое отношение отдельно. Пробую объяснить.
Классы одного классификатора образуют подклассы, объединение экземляров дочерних дает исходный класс.
Никогда отношение на классах не сможет стать подклассом или надклассом, оно всегда в отдельном классификаторе. Несколько разных отношений иногда могут быть в одном классификаторе, если все они построены на одной ступени (являются подмножествами одинакового декартова произведения двух классов, то есть подклассами).

Таким образом классификаторы объектов и классификаторы разных отношений никогда не пересекаются.

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

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

Классы, объекты классов могут входить в разные отношения, причем иногда по нескольку раз в одно отоншение в разных ролях. По Людям и отношению "работают в" можно найти цеха. Цеха не являются подклассом Людей, и помещение их в классификатор может быть только условностью, выделенной атрибутикой метамодели. Подмножества Цехов для каждого человека свои, то есть это разные множества и назвать их именем отношения не допустимо в силу уникальности классов. По Цехам в свою очередь может быть найдена проекция соответствующих Людей.
Об этих навигационных циклах речь?
Запретить такие циклы - опять же нарушить уникальность раскрытия объекта, класса.
Не запретить - бред.
Так что это никакое не раскрытие, и к классификатору не имеет отношения вообще. Но показать, выделив явным образом, можно.

авторМожно создать агрегирующий классифицирующий объект Документ и приписать к нему отношения. Т.е. ничем классификация отношений не отличается.

Не понятно ниче ты пишешь. Отношением принято называть множество. Документ - это элемент отношения, экземпляр. И куда ты его в классификаторе засунешь, кроме как в само отношение?

авторПроекция - динамическая классификация по свойству классификатора (свойства классификатора является фильтром в select. Любой узел графа классифицирующего является оператором Select.

Нет, я имела в виду операцию взятия проекции отношения, то есть получение подмножества соответствующего класса или другого отношения.

авторТипы данных, свойства, объекты (экземпляры), классы это принципиально разные вещи, обращаться с ними надо по-разному. У Сахавата «тип» - это сборная солянка из всего, и отношение это сборная солянка из всего.
авторЭто все одна и та же фигня с точки зрения возможности приведения в вид (ИД, Наименование).

Это вообще не при чем. Идентификатор имеют, конечно, но на этом схожесть заканчивается.

авторЕдиница измерения, цвет (есть у него такие в списке) – это не объекты, а свойства. Классификатор объектов никогда не может быть смешан с классификатором свойств. Свойства не образуют множеств, и с ними нельзя обращаться как с множествами. Нельзя посчитать число элементов «множества свойства». Число заданных значений иногда можно посчитать (для перечислимых свойств), но это бессмысленно и совсем другое. Но можно посчитать число красных объектов.
авторНу, прогеры привыкли, что есть класс "Color"и справочник "Едизм" с несколькими свойствами.

Проггеры привыкли с разными классами работать по разному. Посмотри на свой код для разных справочников. Справочники справочникам рознь.

авторЧтобы EAV стала работоспособной, необходимо добавить более жесткие метаструктуры и навесить атрибутику на них, чтобы потом работать со всем правильно, а не складывать Сахавата и 52.

авторДык, это дело прикладника, а не проги моей. Пусть опишет правильно. :)

Это станет твоим делом, когда прога начислит тебе неправильную зарплату или разобьется самолет с твоей дочерью?
Если метамодель некомпиллируема, то кодом потом ты их исправишь только в частных случаях.

Если ты делаешь прогу для себя - то и бог с тобой. Ты владелец своих моделей. А если хочешь сделать нечто отчуждаемое, то надо все переделывать.

_мод,

авторYulka
Чтобы EAV стала работоспособной, необходимо добавить более жесткие метаструктуры и навесить атрибутику на них, чтобы потом работать со всем правильно

авторЯ бы сказал наоборот: для реализации метаструктуры можно применить EAV (и не только - есть и другие методы). Т.е. под цель подбираются средства.

Согласна. Как физически хранить - это отдельный вопрос. EAV - для уникального, например для задания самих метамоделей самое оно. А все множества удобней жестко хранить.