|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Serguei Tarassov 2:5020/400 16 Jul 2001 18:06:46
To : All
Subject : Re: текстовые ключи
--------------------------------------------------------------------------------
Доброго дня!
"Tolik Tentser" <tt@katren.ru> wrote in message
news:9iujls$fc8$1@news.nsk.su...
> > Доступны, но излишни.
> Опять двадцать пять ...
> То ты критиковал доступность, теперь снимаешь это возражение - и тут же
> никак логически не связаное: "но излишни".
Именно так. Доступны, но излишни, поэтому пользователю эти данные (СК) не
показывают. Hарушение сохраняется.
Другое дело, что эти "лишние" данные как-то системно обусловлены.
Далеко не для всех систем необходимость каскадных изменений являтся
критичной и, тем более, частой операцией.
> > Метаданные никак не связаны с конкретной моделью данных. Это как раз
> способ
> > от нее абстрагироваться. К Кодду отношения не имеют.
> Hу почему же ?
> Метаданные как раз дают непрдготовленному пользователю понятное ему
> представление структуры БД. Именно максимально сводя её к инфологической
> модели. К Кодду - да не имеют, как и все твои предыдущие рассуждения. ибо,
> повторюсь - если клиентом БД выступает приложение (как оно сегодня
> практически всегда, в отличие от времен Кодда и бывает) - то ему все
> полностью открыто и прозрачно. Твой аргумент с Коддом был слегка мимо.
Во времена Кодда, как ты понимаешь, приложения тоже существовали. Просто с
переходом к моделям даных более высокого уровня, чем файлы, записи и
индексы, они перестали быть зависимыми от данных. Стало быть, номер записи в
виде СК им теперь не нужен :-)
Относительно пользователя - он в общем случае совсем не знает, что такое БД.
Метаданые - способ описания доступа к БД исходя из понятий предметной
области. Это не имеет прямого отношения к инфологической модели (они во
многом из нее следуют, но добавляются элементы из прикладной логики, вроде
вычисляемого поля в отчете "дежурный по цеху", отсутствующее в
инфологической модели), скорее, как ты говоришь, "реализационный прием" для
унификации user view на БД.
> А чего тут аргументировать ?
> Я не навязываю сетевую модель, пользователь (приложение) по прежнему ничем
> не ограниченно в выборе JOIN`ов
JOIN по неключевым атрибутам?
> Менять будет тот, кого изменение предметной области застигнет над БД.
> И не вижу зачем делать процесс изменений еще более дорогим.
Этого без конкретики утверждать нельзя. Hе всегда смена базового типа домена
и автоматические (!) каскадные обновления дороги. И, опять таки, надо
рассчитывать изменения в системе, а не только в БД.
> > Чтобы в физической (для реляционной модели) получить. В сетевой бы не
> > пришлось. Еще один косвенный аргумент.
> Почему ?
> Если сущности связаны (логически) по ЕК - он рисуется и именно по этому же
> месту пройдет связь по СК. Что изменилось ?
> Еще раз повторю - в инфологической модели нет ни самих СК, ни темы для их
> обсуждения и рисовать их не придется именно потому, что их там нету
совсем.
> Они есть только у каких-то выдуманных тобой программистов, которые
> проектирование БД начинают с написания
Если я тебя правильно понял, ты утверждаешь, что нарисовав логическую схему
без СК можно получить физическую с СК для реляционной модели? Я утверждал,
что такое возможно для сетевой.
> Hу имеют, ну и что ?
> Это совершенно не означает какого-либо наследования на уровне структуры
БД.
Hе означает. Значит есть унифицированная обработка ядром. Сервис получает
OID и что-то с объектом делает.
> --
> Bye ...
> Тенцер А.Л.
> tolik@katren.ru
> ICQ 15925834
--
с уважением,
Сергей Тарасов
http://www.arbinada.com
mailto:templar@arbinada.com
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
