papos,

а не наоборот?

Бредятина#Работник1
+ живет в Городе1
+ родился в Стране1
+ руководит работой Работника2, который
+ живет в Городе1
+ родился в Стране2 <> Стране1

Что означает:
Извлечь данные о сотрудниках, руководящих работой других сотрудников, которые живут в том же городе, что и их руководитель, но родились в другой стране.

Halpin считает, что это непросто сформулировать на SQL. А Вам, видимо, понравится, что-то мне, по косвенным признакам, подсказывает, что Вы работаете примерно в этом же направлении:)

За Халпин спасибо, посмотрю.
Тут у меня 2 вопроса.
1. Хватит мусолит этого Дейта и обсуждать его ошибки и сомнения. Неинтересно это.
Я от ВАС хочу услышать, что такое объект, характеристика и связь.
2.
#Работник1
+ живет в Городе1
+ родился в Стране1
+ руководит работой Работника2, который
+ живет в Городе1
+ родился в Стране2 <> Стране1

Тут проскакивает УЩЕРБНОСТЬ, уже заметно , что нужен допязык ограничений, потому что нет "связи (ну не знаю чего)" между Город и Страна.
Это как раз те Специальность и Квалификация, между которыми я не могу найти однозначной связи. Бесконечные вопросы о КЛАДР имеют те же корни.
Есть какие то контекстно-зависимые Сущности, часто контекст очевиден в бытовом смысле и не уточняется, а в модели нельзя не уточнить. Нельзя выбрать Город не уточнив Страну.
Т.е. определенные сущности не могут быть ополучены путем прибавления/уничтожения новых атрибутов в имеющиеся сущности. И это НЕ иерархия, не Классификация.
Я эу фигню называю Макротип, это несколько жестко семантически связанных типов.

На счет сомнений (теперь :)) Халпина о СКЛ скорее всего ошибка это. СКЛчем и ПЛОХ что позволяется собрать ЛЮБОЙ мусор, даже если негде его взять. Так как работает на самом низком уровне, никаких семантических узов.

Ух ты , да тут целый мильен!!!

Бредятина,

Вот теперь ты точно ответил на мои вопросы. Даже понятие "признак", "мера", "свойства" появились.
И с "Специальность" и т.д. все ясно. А то меня мучило сомнения :):):) насколько правмочно в одном суррогате спрятать море иерархической информации. Люди непонимают этого.
Чтобы это непонимание искоренить я ввел понятие "мигрирующие свойства", т.е. любой составной тип (состав = сумме связей) может унаследовать любое свойство от типов с которыми связан. Эти свойства могут быть перситентыми или виртуальными. Их актуализация автоматизирована полностью.

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

Умеешь ведь говориь когда хошь.
А этого Халпина я прочту, да там оказывается море народу мучается с поблемами.

Насчет языка ограничений.
Сами составные типы требуют определнных ограничений, которых невозможно (ну в мссскл напр) задать в чек констрейнт. опустим тип Расстояние(Структурный элемент, Структурный элемент) требует что бы оба Структурные элементы принадлежали к одному и тому же типу. А на самом деле Структурный элемент является классификатором (т.е. ссылка на Цех, Участок, Предприятие и т.д.). у надо указать что Структурный элемент.Тип=Структурный элемент.Тип.
А на Макротипах все это намного сложнее, так как там типов много и ограничений море.
Генерировать на все это триггер не сложно, но нужен нормальный декларативный язык сначала.
Пока пользуюсь Expression из DataColumn Net Framework, но он очень слабый :(
Пытаюсь перейти на лямбда и через ехпрешн три создать тело триггера. Сделаю скажу.

Бредятина,

Суррогат , смотри что за ней спрячено

Классификатор не Макротип.В Макротипе Типы связаны. Из любого типа есть путь к любому.
А в Классификаторе типы могут быть не связаны межу собой, роль связующего звена тут играет виртуальный тип - сам классификатор. Макротип дает только целостность, другой семантики у него нет, а классификатор может иметь разную семантику. При этом классификатор классифицирует и макротипы.

"Элементы адреса" есть Классификатор.

Начиная с Галактика и ниже любой Тип может образовать Макротип на любую глубину.
Макротип с главным типом Человек есть сам тип Человек.

Классификатор отображется на навигационное меню пользователя.

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

Методы типов макротипа отображется на групп меню (действие, отчет и т.д., какие сами сочтете нужным).

На все это наложено ограничение доступа по ролям.

"Мигрирующие свойства" наследуются в основном (рекомендовано) виртуально (обеспечение человекочитаемости - лукап), только ради производительности выборки можно сделать их персистентными.
Лукап обеспечивается параллельно еще одним механизмом. Создается и ведется словарь всех идентификаторов и их человекочитаемых расшифровок с учетом каскадности ссылок типов.

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

Тип может содержать в себе ссылки на другие типы и свойства.

во, уж можно начинать и документацию писать :)

"Вычислимы" я конечно ошибся в отношении типов и макротипов.
Просто через типизированные Связи и Роли (так же и Классификаторы) можно получить столько информации, что выбор соответсвующих типов е составляет труда. Т.е., если нам нужно удалит все типы в "Элементы адреса", то пофиг как они называются и как устроены, у нас есть более общий способ их идентификации. Тем самым не надо глубоко знать структуру БД.
Или если нам надо найти входимость всех "Составные сущности", то мы выбираем типы где есть ссылка на типы с таким Ролем. Или если мы ищем "Экземплярные классы", то ищем все типизированные связи "Наследование" и т.д. Структура БД практически не нужна, как больше семантики, так меньше нужды в логической структуре.

Чтоозначает, что структур можно и нужно делать как можно точнее для описания объектов, нефиг Икру и Сталь называть Товаром, Товар - Классификатор, Икра где то в Морских деликатесах, Насыщенных белковых структурах, Сталь в Сталях. :)
А то блин надоели эти , "а куда совать непохожие характреистики похожих фиговин", в Разные места!

vadiminfo,

Как с казал Бред, эти буквы как раз по теме от Галактики и до Квартиры

Бредятина,

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

В типе может быть явная ссылка на Классификатор, тогда тип ссылается на все типы по всей глубине классификации.

Макротип почти то же самое, но тут все входящие типы явно связаны, это какой - то горизонтальный агрегат. Тип не может в явном виде ссылаться на Макротип.

Обе образуют подсхему, но по разному, Классификатор как угодно, а Макротип инкрементно от точки входа(главного типа макротипа). У Классификатор точка входа сам Классификатор, а у Макротипа Тип на который ссылаются явно или косвенно (и через классифиактор тоже) другие типы.

Классификатор может НИЧЕГО не классифицировать, а Макротип хотя бы один тип.

Как все запущено блин. :(

Кроме
Свойство, Тип, ССылкаНаТип, Макротип, Классификатор, Тип связи, Роль Типа, Событие Типа, Метод Типа, Ограничение Типа (+ некоторые технические вещи для маппинга в РСУБД) в модели ничего нет.
Все другие Имена, которые мною названы - ПРИМЕРЫ.

Еще
Мигрирующие ссылки и Свойства
ну, можн выделить механизм обоспечения расшифровки суррогантных идентификаторов всего перечисленного

Бредятина,

ладно работать надо
скоро все равно придется документировать, год уже футболю :)

Бредятина,

лано, счас перекушу и отвечу, скоро базовые понятия наверное расшифруем

Бредятина1) Свойство - это что? Я Вам уже раз пять про свойство сообщал:) Видимо это характеристика объекта .


Храктеристика ничуть не информативнее Свойство.

Бредятина2) Тип - это что? Может быть объект ?


Тип и больше и меньше чем Объект. Больше в смысле Тип как Классификатор Объектов по совпадению типовых свойств.
Меньше в смысле не все Свойства Объекта Тип классифицирует.
Тип как сито, пропускает Объекты через полное совпадение однотипных :) Свойств Типа и Объекта, при этом у Объекта может быть и другие Свойства, которых нет в списке свойств Типа.

Бредятина3) Ссылка на тип . Ссылка из чего??? В классической объектной модели тоже на сегодняшний день помимо явнях связей есть ссылки. Там это ТИП ХАРАКТЕРИСТИКИ ОБЪЕКТА (второй, и явно избыточный, механизм связей между объектами). А у Вас в модели это что?


Это такое сложное Свойство, где Свойством является другой Тип. Через такие Свойства получем доступ к другим Типам полностью или частично.

Это Свойство обеспечивает Связь.

Бредятина4) Макротип . Дайте определение. Что это? Зачем? в чем объективная необходимость?


Для формирования и идентификации более сложных понятий через Связи. Это не Обобщение, а плоская Агрегация. Несколько связанных объектов образуют новое качество. Пальцы, Руки, Ноги, Голова, Глаза, Туловище = Человек.

Бредятина5) Классификатор . Ну про это отдельный разговор. Хорошо (в научно-познавательном плане), что Вы это включили в модель. Но, что это такое, и почему в Вашей модели это понятие имеет самостоятельное значение?


Это очень важный семантический инструмент обобщения и специализации.
У меня их несколько - по способу классификации. :) Не буду перечислять.

Бредятина6) Тип связи . Скорее всего, заблуждение. Я вот только что провел ревизию одного "ядра" для разработки web-приложений. Там тоже есть понятие "тип связи". Например, "имеет" (это такой тип). Его потом назначаем конкретным связям между конкретными "объектами". Это ошибочный подход, и его ошибочность хорошо проверена на практике. Понятие "тип связи" бессмысленно. Ну можно его использовать для извлечения из списка шаблонов при создании новой связи. Но практической пользы от этого нет никакой.


Ну до "Имеет" рядь ли когда придется опуститься. Тип связи почти полностью можно заменить Классификатором. Но тогда приходится создать связи между Классификаторами, что намного сложнее для понимания.
Приведу пример. Все Понятия здесь от модели предметной области.
Технолог назначил на Операцию Металлорежущий станок со скоростью шпинделя 100000 об/с.
Этот объект типизирован как Оборудование.
При планировании операции надо найти конкретный станок с такими характеристиками.
Конкретные станки типизированы в Оборудование в эксплуатации.
НООООО, а откуда это известно? Они могут быть (так и есть на самом деле) типизированы где угодно, и в Основных средствах, и в Оборудовнии к установке и т.д.
Как нам вычислить, что этот долбаный станок надо искать именно в Оборудование в эксплуатации?
Все указанные типы ссылаются на Оборудование, но только связь с Оборудование в эксплуатации типизирована как "Экземплярный класс", остальные по умолчанию "Навигация".
Тип связи "Экземплярный класс" решает все проблемы в данном и в многих других случаях.
А Классификатор "Экземплярный класс" ничего бы не дал в этом случае, так как там нет связи между Оборудование и Оборудование в эксплуатации. Факт что Оборудование в эксплуатации "Экземплярный класс" привел бы к поиску пути от него до Оборудование, чо очень затратно.