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

Точнее, это не имеет отношения к проектированию:) А имеет отношение к программированию.
ser_shu
Нужно хотя бы ченовскую модель сущности - связи реализовать с поддержкой целостности данных, а так опять все ручками и намеками в комментариях.
Об этом и речь. Только модель Чена была изначально ориентирована на создение (в конечном счете) РБД. К сожалению. Так что реализация связей может быть основана только на ясном понимании связи. Здесь не годятся "ссылки", не "внешние ключи" и т.п. Если уж идентификатор экземпляра объекта (по Чену - сущности) не является просто одной из характеристик объекта, то идентификаторы экземпляров других объектов и подавно не могут быть характеристиками объекта:)
Впрочем, все уже давно реализовано..

misha_shar
Целостность данных это отдельная песня и она связана не с моделью объектов. А с моделью баз данных хотя в КАШЕ все это свалено в кучу.

Целостность - один из трех важных аспектов модели данных (наряду со структурой и манипулированием). Поскольку модель данных Саche точно не известна, определенная путаница, конечно, есть:)
misha_shar
При проектировании приложения я всегда начинаю с проектирования основных данных и уделяю этому основное внимание. Все эксплуатационные характеристики приложения зависят от основных структур данных. Когда у меня уже есть структуры данных я начинаю проектировать их связи и обеспечение целостности и этому уделяю очень много внимания.

Вы просто вынуждены уделять этому очень много внимания:) Так как поддерживаете целостность данных на уровне приложения (впрочем, структуру тоже). Это весьма трудоемкий путь..
misha_shar
Как это делается в конкретном случае я поясню на примере.
Вот я разрабатываю бух.учет. У меня 3 основные структуры Классификаторы, Документы и Проводки.
Ссылки на коды в классификаторе есть и в документах и в проводках. Документы и Проводки также завязаны между собой на уровне ссылок. В проводках есть ссылки на номера документов которые их породили.
Целостность между Документами и Проводками я обеспечиваю следующим образом.
Корректировка Проводок пользователем закрыта к ним по записи прямого доступа он не имеет. И проблемы целостности для этой структуры нет.
С документами уже хуже пользователь имеет доступ к документам поэтому я закрываю доступ по записи на уровне отдельного документа для проведенных документов.
С классификаторами дело обстоит еще сложнее их коды присутствуют и в документах и проводках. От обратных ссылок я отказался. Проверять всю входимость в Документах и Проводках
тоже очень накладно. Я проверяю программно входимость кодов в Проводки оставляя не проведенные документы без проверки.
Я считаю что для данного случая это обеспечение целостности оптимально.

Очень не оптимально. И структура (этот подход и в 1с), и специфическая поддержка целостности.
Очевидно, что намного удобнее иметь возможность корректировать "документы" (то есть, исправлять ошибки в совершенных операциях).
misha_shar
Я вообще стараюсь избегать построения обратных ссылок. У меня был печальный опыт построения завязанных таким образом баз. Как бы я не старался нарушение целостности происходило и мне приходилось переодически проверять целостность и в случае необходимости ее восстанавливать. А это связано еще и с ведением архивов удалений.
Нужно поддерживать настоящие связи а не "обратные ссылки". То есть, нужно сначала написать нормальную СУБД (для чего и предназначен mumps), а уж потом разрабатывать приложения:)
А Вы работаете как 40 лет назад работали. Впрочем и тогда люди создавали Fileman и другие СУБД.

Блок А.Н.
авторЯ вообще стараюсь избегать построения обратных ссылок.

Мы ведь говорим о Каше? Используйте индексы

Не лучшая, мягко говоря, идея - использовать индексы (?) для организации связей.

Блок А.Н.Возможно, я неправильно понял задачу misha_star?
В классе А есть ссылка на класс В, это поле индексируется.
По сути индекс будет "обратной связью" из класса В в класс А.
Так вроде реализуется связь "один ко многим". Или речь о чем-то другом?
Дело не в задаче misha_star. А в понимании что такое связь. И в ее реализации, основанной на таком понимании.
1) Связь не может быть свойством объекта (по Вашему класса). Дом, в котором я живу, не является моим свойством:) Таким образом, ни "ссылки", ни "обратные ссылки", ни "индексы", ни "внешние ключи" не являются правильным способом реализации связей. В частности, в РМД "внешние ключи" - это элемент ограничения целостности, а вовсе не "связи".
2) Связь - это принципиально не объект (не класс в Вашем понимании). То есть, связь многие-ко многим НЕЛЬЗЯ ПРЕДСТАВИТЬ С ПОМОЩЬЮ КЛАССА.
3) У связи нет никаких характеристик (подобных характеристикам объекта). Это формально следует из 2).
4) Связь всегда бинарная и двусторонняя. Не бывает никаких триарных и т.п. связей. Обычно за n-арные связи выдают события. А событие, наряду с сущностью - это просто разновидность объекта (по Вашему - класса), но никак не связь.
5) Все связи, независимо от их мощности, следует реализовать одинаково. Кстати, Дейт рекомендует представлять все связи с помощью отдельных отношений ("и не только потому, что связь один-ко-многим может со временем преобразоваться в связь многие-ко-многим"), но, формально, это сделать просто невозможно в РМД.

ser_shu
действительно с понятием связь что-то туго... Но другое слово на ум не приходит.
Да и модель сущности-связи Чена зацепил, так что слово не выбросишь.

Это важное понятие, и его не нужно выбрасывать. А нужно только понять:)
ser_shu
Побродил по интернету, такое впечатление, что 25 лет назад обсуждение этой модели было совсем другое, сейчас действительно только реализация для РБД, прямоугольники, ромбики, вилки, лапы...
Но даже в тех статьях, которые нашел, связь - это не структурные ссылки.

Если почитаете статью Чена, то там вполне очевидна ориентация на РМД.
ser_shu
Рассмотрим множество связей PROJECT-WORKER (ИСПОЛНИТЕЛЬ-ПРОЕКТА) (рис. 3). Атрибут PERCENTAGE-OF-TIME (ПРОЦЕНТ-ВРЕМЕНИ), представляющий долю времени, выделенную конкретному служащему на конкретный проект,– это атрибут, определенный на множестве связей PROJECT-WORKER. Он не является ни атрибутом сущности EMPLOYEE, ни атрибутом сущности PROJECT, так как его смысл зависит и от служащего, и от проекта. Понятие атрибута связи важно для понимания семантики данных и определения функциональных зависимостей между данными.

Именно так это и было давно реализовано:) Например, в X-Magic.
Однако, это формально не точно.
Здесь налицо объект "Распределение объемов работ над проектами по исполнителям", а вовсе никакая не связь. То есть, в этом примере мы видим ТРИ объекта и ДВЕ связи.
ser_shu
То есть в примере misha_shar:
Вот я разрабатываю бух.учет. У меня 3 основные структуры Классификаторы, Документы и Проводки.
Классификаторы - это сущности.
Документы и Проводки - это связи.

Нет:) См выше.
ser_shu
Дальше мои термины, чтобы не путаться, (хотя опять слово связь...).
Для обеспечения целостности данных в ИС строятся и поддерживаются (на уровне описания\реализации модели, а не ручками и комментариями)
- структурные связи, это ссылки
- логические связи, это алгоритмы и правила
Тогда для поддержания целостности данных в ИС при записи\корректировке\удалении сущности или связи нужно проверить, чтобы не нарушались структурные связи и логические связи.
В примере с проводками:
- структурные связи - ссылки на документы
- логические связи - вычисляемые остатки на начало года, месяца (алгоритмы), обеспечение хронологической последовательности, запрет записи\удаления\корректировки ранее последней такой же по типу проводки (правила).

Опять у Вас какие-то "ссылки". Вместо нормальных связей.
И потом, "остатки" могут быть и хранимыми, а не вычисляемыми, но ведь они не могут быть "структурными связями" (ссылками). Они будут объектами, а не связями... Мне кажется, напрасно Вы запутываете ситуацию со связями:)

Блок А.Н.
Это все понятно, когда мы говорим об астрактной СУБД в вакууме.
Но что нам делать на земле? Реализовывать связь один ко многим через поле таблицы или класса?
Если говорить про абстрактную СУБД, то связь это вещь совершенно другая, чем сущность, и в тех же таблицах их хранить как-то неправильно?

Да, связь не нужно хранить "в тех же таблицах". И все это давно реализовано. Конкретно, а не абстрактно. Но нужно двигаться дальше:)

servit misha_shar

Возможно, Вам будет интересно почитать книгу СУБД Caché 5: работа с объектами .
Автор: Труб И.И.
Оглавление к ней.
Да, чего там мелочиться со связями. Будем сразу "работать с метасвязями":)