ViPRosПочему все время увиливаешь от ответа? Ты ж можешь сказать, что характеристики объекта сть такие же объекты.

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

Это и есть глубокое заблуждение Дейта (который так и не смог этого обосновать в рамках обоснования РМД) и многих других специалистов. Не тратьте свое время зря. Между объектами и связями между объектами нет абсолютно ничего общего:)
ViPRosИли тыдумаешь не так? Дык скажи. За 30 лет то наверное у тя все это выкристаллизвалось в башке?
Я и говорю, но Вы же это не хотите слушать, а вместо этого упорно навязываете сами себе какие-то понятия, которые непонятно что характеризуют - какие-то роли объектов в отношении. Но если уж Вы используете эти понятия, я бы Вам порекомендовал изучить, например, объектно-ролевое моделирование (ORM) Halpin T. (для начала см. описание у того же Дейта) и, соответственно, язык ConQuer - концептуальный язык создания запросов, основанный на ORM. Пример:

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

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

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

ViPRos1. Хватит мусолить этого Дейта и обсуждать его ошибки и сомнения. Неинтересно это.

Вы опять чересчур категоричны. Именно через Дейта, его ошибки и сомнения мы выходим на многие интересные и актуальные аспекты теории баз данных.
ViPRosЯ от ВАС хочу услышать, что такое объект, характеристика и связь.

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

Объект - все, что может быть идентифицировано, и (не обязательно) обладает набором характеристик.

Понятно, что у объекта может не быть ни одной характеристики. В РМД это невозможно. Не может быть отношения без атрибутов (точнее, может, но в таком отношении может быть ровно один кортеж).

Характеристика - количественный или качественный признак какого-либо свойства объекта, котрый можно наблюдать, измерять или вычислять.

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

Вы преувеличиваете. Что значит нет связи между Специальностью и Квалификацией? У специальности (пусть, пока, это будет объектом) швея-мотористка есть совершенно конкретный набор квалификаций (пусть, пока, это тоже будет объектом, таким образом Специальность --Имеет/Относится к --> Квалификация). У меня, например, 4-ый разряд швеи-мотористки (я не шучу). Я понимаю, что Вас волнует не эта связь, а применение пары Специальность-Квалификация как "единого целого" в определенных местах приложения. То же и в КЛАДРе. Однако, все не так сложно, как кажется. Именно иерархия, а для экземпляра-владельца достаточно определить только нижний узел. А именно, для представления Адреса прописки для Человека достаточно связать Человека только с идентифицированной квартирой (или домом). При этом и улица, и населенный пункт, и страна, и планета определяются автоматически. Я бы просто дополнительно создал вычисляемую характеристику Адрес прописки объекта Человек, и выводил бы в ней этот самый Адрес прописки в стандартном "красивом" виде. Собственно я Вам и объясняю, что единственное, что все еще нужно немножко программировать при создании приложения - это триггеры и вычисляемые характеристики. Кстати, вместо (не хранимых в БД значений) вычисляемых характеристик можно использовать триггеры, в этом случае ввод данных будет по-медленнее, а вывод по-быстрее:).

В последнем варианте, наряду с триггером используется характеристика определенного типа с ХРАНИМЫМ в БД значением.

Кстати, чтобы у модераторов не было сомнений, все это имеет самое непосредственное отношение к нормальной форме Бойса-Кодда:)

paposЛадно, коль уж тему превратили непонятно во что, ответьте на мой вопрос пожалуйста =)

Мы всегда помним о Вас.
papos"Вроде как я понял, как нужно исправить - необходимо в таблице Артист сделать PK из двух полей - ФИО и Название выступления. Так?

Нет, не так.
paposНе будет ли ключ из 2 полей избыточным?"

Не будет.
Вам нужно показать четко концептуальную модель. Вам это уже объясняли. Что такое выступление? Выступление артиста в сборном концерте? В сольном концерте? Просто одно, например, главное в жизни, выступление? Роль персонажа в спектакле?:)

ViPRosВот теперь ты точно ответил на мои вопросы. Даже понятие "признак", "мера", "свойства" появились.

Они не являются понятиями модели данных. Это я просто объяснил почему термин "характеристика" правильнее, чем "свойство".
ViPRosИ с "Специальность" и т.д. все ясно. А то меня мучило сомнения :):):) насколько правмочно в одном суррогате спрятать море иерархической информации. Люди непонимают этого.

Но, квартира - это не суррогат:) Да и адрес не слишком похож на море:)
ViPRosЧтобы это непонимание искоренить я ввел понятие "мигрирующие свойства", т.е. любой составной тип (состав = сумме связей) может унаследовать любое свойство от типов с которыми связан. Эти свойства могут быть перситентыми или виртуальными. Их актуализация автоматизирована полностью.

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

Свойство не тип, и не объект, а объективная особенность объекта, проявляющаяся в процессе его производства, эксплуатации, жизнедеятельности. Не стоит ничего выдумывать, и использовать занятые понятия.
Почему макротипом называются только НЕКОТОРЫЕ связанные типы? У других связанных типов целостность не блюдётся?:)
ViPRosСвязь мжду типами типизирован (ну, именован), типы в составном типе отношении) имеют роли (типизированные тоже).

Это ключевой момент. Здесь в дополнение к связанным типам (макротипам) появились составные типы (или составные типы-отношения?). Появились связи между непонятно какими типами (то ли между типами внутри то ли макротипа, то ли составного типа; то ли между составными типами)? И наконец появились роли. При этом непонятны цель и способ использования "связей" и "ролей".
ViPRosТип связи и Роль усиливает семантику модели, можно работать не с самими типами а только Типаи связей и Ролями, так как сами типы становятся вычислимыми

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

Плохо. Классификатор - это просто один из типов (по Вашему "макротип"), а не отдельное понятие наравне с типом.
ViPRosА этого Халпина я прочту, да там оказывается море народу мучается с поблемами.

Да, там у них за границей вообще чёрти-что творится:)