_модБредятинаА с преподавательской работы я давно ушел:)
Я задал вопрос. Если ответа нет, то так и скажите. Ждемс
Не обманывайте:) Это же не прилично. Я Вам здесь много раз разжевывал этот вопрос с примерами. Даже подробно рассматривал потуги MS в виде русскоязычных имен полей и не системного атрибута (поля таблицы) Description (не системного, так как, во-первых, у других элементов этого атрибута нет, а, во-вторых, его нельзя использовать по назначению в приложении). Но, все-таки, какие-то шаги делаются в направлении создания СУБД из реляционной системы:) А про метаданные, пожалуйста, не смешите людей - Вы же не студент насколько я понимаю:)

_модБредятинаВы подразумевали класс систем? А пиэльдробьэскуэль в конкретной:)
Ессно. pl\sql (т.е. АДА) используется в разных СУБД. Нет разницы
Не вполне ясно почему Вы пиэльдробьэскуэль обозначаете какими-то латинскими буквами.
Итак, АДА (теперь:)) используется в разных СУБД. Очень хорошо. Я искренне рад.

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

[quot vadiminfo]В имени таблицы и колонок. Я же писал. Никада не видели? А ить я Вам давно предлагал забросить Мумпс. Счас бы таких вопросов Вам и в голову не пришло.[quot _мод]
Очевидная неправда:) Нет этой информации в имени таблицы и колонок в РСУБД, попса никогда не была ориентирована на семантику данных - это выше ее сил, вероятно:) В имени таблицы и колонок есть информация только для программистов. Это идентификаторы элементов структуры данных (технические метаданные), а вовсе не имена (содержательные метаданные). _мод и говорит о том, что этого вполне достаточно, и спорить вам (двум сторонникам РМД) здесь совершенно не о чем:)

_модВсе это известно либо юзеру, либо приложению.
Нет (хотя прояснение и наступает, периодически:)), правильно - либо пользователю (без посредничества программиста), либо программисту, а уже с его помощью пользователю. Когда используется РСУБД пользователь, конечно, не сможет узнать фамилию сотрудника без программиста:)

_модvadiminfoСмысл моделирования: абстрагирование от ненужных деталей.
Смысл моделирования: абстрагирование от семантики, переход к формальным структурам и методам. Т.е. реальное семантическое представление о предметной области мы заменяем формальной моделью, лишенной этой семантики. Зате применяя формальные же методы получаем ре-т и конвертируем его обратно в семантическую область. Это ж азбука :)
Я бы не называл вот так походя, азбуку убожеством:) Азбука - хорошая штука. Еще раз напомню пример удачного применения алгебры - алгебра статистических показателей. В этом случае пользователю понятен результат манипулирования. Тогда как в случае алгебры отношений он понятен только программисту:) И, главное, алгебра не применяется для моделирования данных. Моделирование данных банально подогнано под использование алгебры в случае РМД. Я Вам много раз это объяснял, тщательно аргументируя и с конкретными примерами:)

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

vadiminfo_мод Т.е. реальное семантическое представление о предметной области мы заменяем формальной моделью, лишенной этой семантики.
....:
Да Вы можете хоть у себе в иерахических заменить, что угодно. А нам то нуно моделировать предметную область.
Нам то нужно. Только _мод пишет о "реляционной практике". Причем довольно точно, как знаток этой практики. Жаль только, что он путает семантику операций (знак +) с семантикой данных (Сидоров - это Фамилия):)
vadiminfo_мод Зате применяя формальные же методы получаем ре-т и конвертируем его обратно в семантическую область. Это ж азбука :)
Делать вам нечего. У нас таких траблов нет.
Не понимаю, почему нужно говорить неправду, ради корпоративной солидарности:) Это же не профессионально. Именно в случае РМД такие траблы есть, и это очень хорошо известно. Поэтому и возникло через год после появления более менее целостного описания РМД, направленной на алгебраическое манипулирование данными, такое направление, как "семантическое моделирование ":)

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

_модБредятинаалгебра не применяется для моделирования данных. Моделирование данных банально подогнано под использование алгебры в случае РМД.
Ессно нет. алгебра - средство манипулирования МД. И никто ничего не подгонял - сначала РМД, потом рел. алгебра. Существуют РСУБД без всякой алгебры. Мат. часть подучити.
Для Вас - не естественно. Так как пропустили целый пласт в ходе образования. Не знаете даже такого элементарного факта - сначала алгебра, потом РМД. Я Вам много раз советовал почитать отчеты Кодда. Не общеизвестные, а в хронологическом порядке:)

_модБредятинаРешили же уже все вопросы:)
Причем давно
Именно, поэтому Вам и нужно вернуться к связям, хоть "циклическим", хоть "просто связям". Чтобы более выпукло продемонстрировать "Вашу" идею о приложении, в котором у Вас неизбежно будет ДРУГАЯ модель данных с последующим маппингом и прочими попсовыми штучками:)

_модvadiminfoА нам то нуно моделировать предметную область.
Зачем ? Вам это не надо. Если в модели сохраняется вся семантика, то чем модель отличается от предметной области ? Вот и работайте прямо с ней (у вас же "траблов нет")
Просто не прилично должно быть писать откровенные глупости. Разумеется, что все и работают прямо в ней (а не с ней). Но не все могут держать у себя в голове всю информацию. Не все используют одинаковые термины и т.п. Так что БД для этой предметной области, конечно же, должна содержать ВСЮ НЕОБХОДИМУЮ семантику (все необходимые метаданные) для правильной интерпретации данных. И эти метаданные никак не могут зависеть от прихоти каких-то программистов:) Если это БД в области программирования, пожалуйста, а людям не нужно мешать работать своими прикладными программами:) Расчеты - да. Одна из программ, условно говоря, входящих в состав СУБД, должна понимать + и выполнять операцию (интерпретировать + вполне конкретным образом). Но и другая должна банально сопроводить значение "172" метаданными, не допускающими различных интерпретаций:) Для чего Вы это как бы не понимаете, я не понимаю:)

_модБредятина "семантическое моделирование "
семантическое моделирование - это промежуточный этап осмысления и формализации предметной области. Оно не отменяет и не заменяет необходимость моделирования собсно вычислительной среды. Конечно для простых фактографических систем (как у vadiminfo) этап моделирования можно пропустить и РСУБД вообще не нужна, а нужна ОСУБД.
1) Неправда. Опять. Он промежуточный вынужденно, если у Вас "реляционная система". Вам же нужно подогнать данные под алгебру:)
2) Этап какого моделирования можно пропустить? У Вас же два моделирования: "семантическое" и "собственно вычислительной среды":) Вероятно, этап "семантического моделирования". Итак, ОСУБД нужна, когда нужно моделировать "собственно вычислительную среду"?:) Непонятно, правда, что понимается под ОСУБД. Если, ОСУБД на концепциях ООП, то напомню, что к БД эти концепции не имеют ни малейшего отношения.
3) Другой вариант: в "фактографических системах" (это уточнение Вашей позиции, о котором Вы почему-то умалчивали) не нужно "моделировать собственно вычислительную среду", и поэтому можно использовать СУБД, в которых поддерживаются метаданные? Или семантика данных и в этих СУБД не должна поддерживаться?:) Тогда зачем Вы вдруг завели речь о "простых фактографических системах". Например, ERP - классический пример такой системы:)