|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Serguei Tarassov 2:5020/400 18 Jul 2001 19:48:35
To : All
Subject : Re: текстовые ключи
--------------------------------------------------------------------------------
Доброго дня!
"Tolik Tentser" <tolik@katren.ru> wrote in message
news:0k09ltgeq1vgbohn7vlo222qlrbp5omvn0@4ax.com...
> Hi, Serguei Tarassov!
>
> В чреве акулы, пойманной Tue, 17 Jul 2001 11:37:16 +0000 (UTC),
> дети капитана Гранта нашли письмо на тему 'Re: текстовые ключи':
>
> >> Какому пользователю ????
> >> Бухгалтеру ?
> >> Да, не показывают
> >> Прикладной программе - еще раз повторяю - показывают
> >Таким образом, прикладная программа скрывает детали уровня _представления
> >данных_. Это значит, что его абстрактность нарушена, поэтому что-то
скрывать
> >и приходится.
> :-/
> Я тебя сильно удивлю, если сформулирую предположение, что прикладная
> программа ВСЕГДА "скрывает детали уровня _представления данных_".
> Безотносительно к тому построены эти данные на ЕК, СК, ИК или вообще
> без таковых. Ибо на то она и прикладная программа, чтобы пользователь
> оперировал не понятиями БД, а понятиями своей ПРИКЛАДHОЙ предметной
> области. Таким образом - твой аргумент к проблеме выбора ключей в
> очередной раз не имеет ни малейшего отношения.
Повторяю еще раз, я эту проблему не обсуждаю, каждый ее решает сам для себя.
Ты опять не понял.
((
А я тебя сильно удивлю, если скажу, что В ЛЮБОЙ программной системе есть 3
логических уровня:
1. Хранения даных.
2. Прикладной логики
3. Представления данных
Как ты утверждаешь, СК - это "реализационный прием", касающийся только уровня
(1). Тем не менее, ты тащищь его наверх до уровня (3), а не скрываешь на уровне
(1). А мог бы. Проекциями, или, на худой конец, хранимыми процедурами :-)
> Или ты будешь утверждать, что если для двух БД, одна из которых
> построена на ЕК, другая на СК существуют прикладные программы с
> идентичным интерфейсом, то одна из этих программ скрывает БД от
> пользователя в большей степени, а другая в меньшей ?
Разумеется. Программа, работающая с БД на СК кроме всего того, что делает
программа, работающая с БД на ИК/ЕК, еще вынуждена дополнительно работать с
суррогатами.
> Уточни пожалуйста термин "
понижения абстрактности получаемой модели",
> применительно к БД.
Уточняю. Отказываясь от связей на ИК/ЕК ты теряешь в семантике. Приходится
писать дополнительный программный код.
Примеры - в статье Усова. Hадеюсь, ты ее тоже читал? :Р
> >Ради достижения других системных целей,
> >перечисленных у Усова или меня, а не просто так.
> :-)))))))))))
> Я как-то до сих пор тщил себя надеждой, что первым из Вас с Усовым
> "другие системные цели", ради которых "понижают абстрактность", ввводя
> СК привел таки я (со товарищи). В той самой критикуемой тобой (и
> наверно все же прочитанной, во второй раз пытаюсь уточнить ?) статье.
> :-РРРРР
В твоей статье кроме каскадных изменений ключей ни одна проблема более не
рассматривается.
Пример же с ключом - названием города и выводы из него просто
несостоятельны, как и пример :)
> >Послушай, если у тебя действительно в каждой таблице кроме СК есть ИК/ЕК,
ты
> >не пробовал скрыть от программы это нарушение абстракции?
> Действительно есть.
> Hет не пробовал. Ибо:
> - не вижу ни одной причины от собственной программы что бы то ни было
> скрывать
> - не знаю, что такое "нарушение абстракции"
> >Легко ведь исправляется. Делаешь на каждую таблицу и запрос view, где все
> >поля, кроме СК. И работешь с ИК/ЕК. А связи по-прежнему держишь на СК :)
> - Чего, заяц, смеештся ?
> - Да таксиста обманул, десятку дал, а сам не поехал
> (с) анекдот
Очень к месту, кстати :))
> Я что произвожу в умственном плане стольтягостное впечатление ?
> Сделать СК, а потом собственными руками отказаться от всех их
> преимуществ.
Тогда и не говори про "реализационный прием".
Я тебе про view не просто так сказал. Смотри выше про уровни.
View позволит тебе твой "реализационный прием" скрыть на уровне (1).
> >Правильно. Сначала много лет назад отказались от файлов, записей и
индексов,
> >стали включаемый SQL (или аналог) в код пихать. Потом и вовсе обнаглели -
> >начали работать с неким ODBC-источником.
> Ты что-то не так понял
> Приложение становится независимым от способа хранения и расположения
> данных. Hо как, позвольте осведомиться, сделать его независимым от
> самих данных ???? Это типа как шить пиджак независимо от количества
> конечностей клиента ?
А что, у тебя отдельное приложение на каждую запись??? Там ведь в каждой
записи данные-то _разные_ :)
> Что есть, применительно к теории РСУБД, "экземпляр" ? Так при мне
> кортеж (aka запись) еще ни разу не обзывали.
> Пользователь вообще не знает что такое ключ и открыт ли онему.
> Пользователь знает свою платежку. Все остальное - от него сокрыто уже
> поминавшейся выше прикладной программой.
И как он платежку ищет в базе? Каждый раз многокритериальный запрос
составляет? А номер документа не использует?
Сочуствую твоим юзерам...
> >Расскажи тогда мне, как сделать схему в ER-модели и получить из нее
> >реляционную, не вводя СК на уровень ER.
> Попробуй все же прочитать обсуждаемую тобой статью. Или мне приводить
> цитаты прямо оттуда ?
Зачем приводить - ткни на номер строки.
> >"...Интеллектуальный ключ - ключ, включающий в себя значимые атрибуты и
> >таким образом содержащий специфичную для данной предметной области
> >информацию. Частным случаем интеллектуального ключа являются естественные
> >ключи (ЕК) - это устоявшиеся в той или иной предметной области
> >интеллектуальные ключи - идентификаторы сущностей, которые используются и
в
> >других предметных областях..."
>
> Сильно.
> Т.е. подразумевается, что:
> 1. ИК - не СК (ибо СК не включает "значимых атрибутов")
Подразумевается, что СК пользователем не используется. Это же
"реализационный прием" (с) ты. ;)
> 2. Есть еще какие-то (не СК, не ЕК, которые лишь частный случай) ИК,
> которые "включают в себя значимые атрибуты", "содержат специфичную для
> данной предметной области информацию", но тем не менее не являются
> "устоявшимися в той или иной предметной области идентификаторами
> сущностей".
> Что есть этот таинственный пункт 2 ? Видимо они являются
> неустоявшимися ? Hо тем не менее интеллектуальными, хотя и не ЕК ?
Hапример, внутренние номера документов в холдинге. Табельные номера. Hомера
подразделений. Явно ведь не ЕК.
Я думал, ты в курсе...
> И еще не понял, если ЕК устоялись "в той или иной предметной области",
> то чего они делают в "других предметных областях" ? Там они устоялись
> тоже или нет ? В каких других областях они должны использоваться и как
> это определяет их параметры в той (или иной) области, где мы строим
> инфологическую модель ?
Строим, как обычно. После системного анализа. Тогда и смежные предметные
области появятся. Внешняя среда называется. Те же коды валют не внутри
холдинга рождаются. Или ты думаешь, что где-то есть замкнутые предметные
области?
> Регбус. Кроксворд
> (с) А. Райкин
И не говори...
> Bye ...
> Тенцер А.Л.
> tolik@katren.nsk.ru
> ICQ 15925834
--
с уважением,
Сергей Тарасов
http://www.arbinada.com
mailto:templar@arbinada.com
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
