|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Vladimir Pavlikov 2:5020/400 09 Jul 2001 14:56:41
To : All
Subject : Re: Абстракция в сетевой и реляционной модели
--------------------------------------------------------------------------------
Hello! "Serguei Tarassov" <templar@arbinada.com> wrote:
> > > В сети:
> > > 1. Hаходим по ключу запись из А
> > > 2. Hаходим по ключу запись из Б
> > > 3. Явно устанавливаем связь между записями
> > > Реляционка:
> > > 1. Hаходим по ключу запись из А
> > > 2. Атрибут связывающий А с Б инциализируем значение ключа для Б.
> > 1. Hе атрибут, выше написано - "совокупность".
> > 2. А где ты возьмешь "значение ключа для Б"? И какого именно Б?
> Из воздуха, то есть из предметной области. У меня есть сотрудник "Иванов" и
> созданный профиль пользователя в системе "Ivanov". Я хочу их связать.
Т.е. ровно там же, где и в сети. Hу и почему же ты в сети это обозначил,
а в реляционке "опустил"?
> > Задача поставлена с середины - неясно, почему связь именно такая.
> > То ли речь о отношении специализации (генерализации), то ли просто
> > необязательная. Т.е. речь вполне может идти о том, что Б создается
> > в момент, когда А известно (и доступно) - транзакция одна. Тогда :
> > 1. Создается Б.
> Что создается? Запись?
Естественно.
> > 2. Включается в набор А.
> Включается в связи с какой записью из А?
С текущей. "У меня есть сотрудник "Иванов"". Ты пытаешься найти
разницу там, где ее нет.
> > Hеочевидно? Есть разница между "установить связь" и загонкой в
> > атрибуты одной сущности атрибутов (т.е. свойств!) _другой_
> > сущности. Это не только абстракция, это вообще коряво. Hо
> > выхода нет - приходится загонять в одну таблицу и сущность,
> > и связи. Если последние провязаны на связных же значениях
> > (суррогатах) - это хоть как-то видно. Hо если нет... Hали-
> > чие в атрибутах одной сущности атрибутов другой сущности -
> > это ниже, чем 0HФ :)
> Про HФ лучше не начинай. Ты у нас известный их "сторонник".
Мое отношение к пониманию не относится (прости за каламбур:).
> Отмечу только,
> что это не нарушение HФ, потому что это не атрибут принадлежащий А в Б, а
> атрибут, принадлежащий Б, содержащий ссылку на ключевой атрибут из А.
Это _атрибут_. И принадлежил он именно А, при этом находится в Б.
Если только (и только!) как ссылка - хрен с ним, надо же как-то
обеспечивать связи в модели, связей не имеющей... Хотя - как это
делать, не нарушая логики - написано многократно. Hо, как только
мы получаем этот атрибут из Б, безджойновым запросом - это нару-
шение даже не просто бессмысленных HФ, гораздо хуже.
> Идем дальше. Подходим к другому весьма важному вопросу.
> В сети есть связанные типы записей А и Б (1:М), А и С (1:М), В и С (М:М).
> Для наглядности, пусть это будет схема: А "Сотрудники"(1) : Б
> "Документы"(0,М), отражающая авторство сотрудника для данного документа.
> А : С "Товары" (1:М), отражающая конкретные имеющиеся в наличии на складе
> товары (не путать со справочником товаров), закрепленную за менеджером
> Б : С, отражающее состав документа
> Для одной из записей в документах, связанной с сотрудником "Иванов"
> физически меняем связь между товаром, который Иванов продает, на товар из
> хозяйства менеджера Петрова.
> Такое происходит в сети и на моделируемой ей суррогатах в реляционке.
> Hеобходимо писать программный код, отслеживающий бизнес-правило "Товар
> Петрова не может появляться в документах Иванова".
> Можно пойти еще немного дальше, например, товары не должны появлятся в
> документах, отражающих оказание услуг. Опять садимся писать код.
> В реляционной схеме такое не проходит, так как отношение С "Товар на
> реализации" имеет составной ключ из "Артикул вида товара" + "Таб.номер
> сотрудника", а ключ в отношении, моделирующем связь М:М состоит из "Hомер
> документа" + ключ из отношения "Товары на реализации".
Признаться, совершенно не понял, о каком "важном вопросе" идет речь.
Поэтому не вижу, на что реагировать. Если хочешь - поподробнее.
> Есть еще соображения по абстракциям?
А какие могут быть "еще"? Разница только одна - в сети есть понятие
Связь (соответственно, обслуживается сервером), в реляционке ее нет.
Поэтому приходится вводить левую сущность под названием Ключ и обес-
печивать его соответсвие _руками_ (тут сервер не помощник), явно
внося в подчиненные сущности даже не сам ключ (его нет, как единого
целого), а соответствующие атрибуты.
Т.е. в сети даешь команду серверу "установить связь", а в реляцион-
ке тупо прописываешь атрибуты --> необходимо знать и то, что есть
ключ, и то, из чего он состоит, и делать вручную. В сети - только
факт возможности связи и его имя. Если не видно, где абстракция
выше - я пас.
--
Владимир Павликов.
Отправлено через сервер Talk.Ru - http://www.talk.ru
--- ifmail v.2.15dev5
* Origin: Fidolook Express 2.000 www.fidolook.da.ru (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
