|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Serguei Tarassov 2:5020/400 03 Jul 2001 16:13:59
To : All
Subject : Re: текстовые ключи
--------------------------------------------------------------------------------
Доброго дня!
"Vladimir Pavlikov" <pvv@soil.msu.ru> wrote in message
news:9hs6q7$b2l$1@host.talk.ru...
> > Володя, есть понятие такое "информационное моделирование". Это часть
общего
> > процесса моделирования предметной области. Ты в курсе, я знаю.
> Хорошо.
> > Оно безотносительно БД. И понятие ключа там присутствует, как ни
странным
> > тебе может показаться.
> Прости, но это чушь. Hint - информационное моделирование не есть реляци-
> онное, это искуственное заужение модели. В любом случае до модели пред-
> почитаю иметь инфологическую схему самой предметной области, внемодель-
> ную, а в ней "ключей" нет просто потому, что быть не может.
Ты или ошибаешься, или подразумеваешь под инфологической моделью что-то
другое.
В определении же это "...обощенное, не привязанное к каким-либо ЭВМ и СУБД,
описание предметной области (наборов данных, их типов, размеров, связей и
т.п.)..."
Понятие "сущность" вводится на уровне инфологической модели. Ключ -
минимальный набор атрибутов, по значениям которых можно однозначно найти
требуемый экземпляр сущности.
> И параллельно, и раньше ты намекаешь на то, что некоторые начинают с
"конца".
> У меня нет сомнений, что такие есть, и их много. Hо если ограничится лишь
> собеседниками - ты начинаешь с "середины", я - всегда с "начала".
При этом уже представляя на 2 шага вперед, как в физической БД к таблице
будет пристегнуто автоинкрементное поле?
> > Ты хочешь сказать, что твои задачи не осуществляют межсистемного
> > взаимодействия? Hе верю ;-)
> Это другое, ты меняешь тему. Hо, если хочешь :
>
> 1. Почему не веришь? Такие задачи есть, и мне попадались.
Hу не верю ;-) В простейшей программе печати платежек куча связей.
> 2. Взаимодействие бывает разное, к примеру, простой экспорт/импорт.
> Чего только и куда/откуда не приходилось...
Аналогично. Конвертеров и оффлановых репликаторов я за свою практику
обписАлся. Hекоторые делались очень быстро, т.к. БД источник содержала ЕК.
> 3. Если БД сразу проектируется, как часть большего хранилища - суррогаты
> являются _наилучшими_ механизмами подобного взаимодействия.
А почему не воспользоваться общими средствами?
> 4. Синхронизация с БД, о существовании которой на момент проектирования
> было ничего не известно. Задача выходит за рамки действия суррогатов,
> они для ее решения не годятся. Hо я никогда не утверждал обратного :)
> Решаться может самыми разными способами
> - сведением к 3. (с допроектированием, ессно)
> - работой по атрибутам (отнюдь не только уникальным, бывало и по пол-
> ному кортежу, с "ручным" принятием решений - жизнь сложна)
> - многое другое....
Согласен. Hе для всех сущностей удается отыскать нормальные ключи.
Приходится делать анализ по неключевым атрибутам или даже в контексте связей
с другими сущностями.
> Да, возможно, уникальные совокупности атрибутов-свойств решают эту задачу.
> Как частный случай, и наличие суррогатов этому никак не мешает. Hо это
> малая (и не самая частая) часть применения ключей.
Совершенно верно, не мешает. Поэтому там где можно без них обойтись - почему
бы не обойтись, чтобы не поддерживать две параллельные системы поддержания
целостности и непротиворечивости?
> --
> Владимир Павликов.
>
>
> Отправлено через сервер Talk.Ru - http://www.talk.ru
--
с уважением,
Сергей Тарасов
http://www.arbinada.com
mailto:templar@arbinada.com
--- ifmail v.2.15dev5
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
