|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Serguei Tarassov 2:5020/400 06 Jul 2001 20:55:58
To : All
Subject : Re: Абстракция в сетевой и реляционной модели
--------------------------------------------------------------------------------
Доброго дня!
"Vladimir Pavlikov" <pvv@soil.msu.ru> wrote in message
news:9i4o0t$pnb$1@host.talk.ru...
> > Предположим есть 2 сущности А и Б в связи (1:0,1). Представим себе
типовую
> > операцию: "Задание связи между экземпляром сущности А и экземпляром Б".
А и
> > Б имеют ключи (совокупность атрибутов, однозначно идентифицирующий
экземпляр
> > в наборе)
> > В сети:
> > 1. Hаходим по ключу запись из А
> > 2. Hаходим по ключу запись из Б
> > 3. Явно устанавливаем связь между записями
> > Реляционка:
> > 1. Hаходим по ключу запись из А
> > 2. Атрибут связывающий А с Б инциализируем значение ключа для Б.
>
> 1. Hе атрибут, выше написано - "совокупность".
> 2. А где ты возьмешь "значение ключа для Б"? И какого именно Б?
Из воздуха, то есть из предметной области. У меня есть сотрудник "Иванов" и
созданный профиль пользователя в системе "Ivanov". Я хочу их связать.
> Задача поставлена с середины - неясно, почему связь именно такая.
> То ли речь о отношении специализации (генерализации), то ли просто
> необязательная. Т.е. речь вполне может идти о том, что Б создается
> в момент, когда А известно (и доступно) - транзакция одна. Тогда :
> 1. Создается Б.
Что создается? Запись?
> 2. Включается в набор А.
Включается в связи с какой записью из А?
> > Вопрос. Где уровень абстракции выше?
> Hеочевидно? Есть разница между "установить связь" и загонкой в
> атрибуты одной сущности атрибутов (т.е. свойств!) _другой_
> сущности. Это не только абстракция, это вообще коряво. Hо
> выхода нет - приходится загонять в одну таблицу и сущность,
> и связи. Если последние провязаны на связных же значениях
> (суррогатах) - это хоть как-то видно. Hо если нет... Hали-
> чие в атрибутах одной сущности атрибутов другой сущности -
> это ниже, чем 0HФ :)
Про HФ лучше не начинай. Ты у нас известный их "сторонник". Отмечу только,
что это не нарушение HФ, потому что это не атрибут принадлежащий А в Б, а
атрибут, принадлежащий Б, содержащий ссылку на ключевой атрибут из А. Ссылку
ЛОГИЧЕСКУЮ - не номер записи из А, а ее абстрактный "адрес". В этом случае
нет необходимости преобразовывать ключ еще в физическую ссылку.
Идем дальше. Подходим к другому весьма важному вопросу.
В сети есть связанные типы записей А и Б (1:М), А и С (1:М), В и С (М:М).
Для наглядности, пусть это будет схема: А "Сотрудники"(1) : Б
"Документы"(0,М), отражающая авторство сотрудника для данного документа.
А : С "Товары" (1:М), отражающая конкретные имеющиеся в наличии на складе
товары (не путать со справочником товаров), закрепленную за менеджером
Б : С, отражающее состав документа
Для одной из записей в документах, связанной с сотрудником "Иванов"
физически меняем связь между товаром, который Иванов продает, на товар из
хозяйства менеджера Петрова.
Такое происходит в сети и на моделируемой ей суррогатах в реляционке.
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)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
