Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7 8 9 10 .. 14   вперед  Ctrl
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Сбили меня тут своим классами :)

В НРМ есть, конечно же, объектные типы, и они допускают множественное наследовангие. Вс екомпоененты этих типов можно переопрелелять при наследовании. То есть и компоненты и, следовательно, сами эти типы являются полиморфными.
21 июл 05, 16:45    [1725041]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
U-gene
Сбили меня тут своим классами :)

В НРМ есть, конечно же, объектные типы, и они допускают множественное наследовангие.
И каковы тогда правила разрешения конфликтов?
21 июл 05, 17:26    [1725269]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Хороший вопрос.

Насчет спецификаций - это ИМХО связано с тем же отображением (объекты <=> R-переменные). Если у о-типа А есть много наследников, и от них от всех мы потом множественно наследуем о-тип B, то в спецификации этого типа все равно будет только по одному компопненту из спецификации типа А.

Можно объяснит так. Спецификации компонентов можно рассматривать как элементы некого множества. Спецификация типа - это множество. Множественное наследование (применительно к спецификации о-типа) - это, фактически, объединение нескольких множеств. Естественно, объединение нескольких, содержащих одинаковые элементы множеств в точности повторяет любое из исходных множеств - элементы (т.е. спецификации компонентов) дублироваться не могут. Я не уверен, но насколько я помню , это называется виртуальным множественным наследованием. Или я не тот термин употребляю?

Конечно же будет конфликт реализаций. Но ИМХО данные момент не является принципиальным. Этот конфликт в любом случае можно как-то можно разрешить. Аутоматично (например, брать реализацию из первого типа в списке базовых типов ... ГЫ-ГЫ) или руками (например, в случае конфликто явно указывать, какая реализация нужна - вплоть до требования явного преопределения). Т.е. это дело не НРМ, а конкретной системы, реализующей НМР. В НРМ это могло бы прозвучать как "В системе должен существовать механизм разрешения возможных в случае множественного наследования конфликтов реализаций компонентов"
21 июл 05, 18:45    [1725649]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 ModelRВторой раз счасибо. :)
21 июл 05, 18:47    [1725654]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Андрей Леонидович
Guest
Почему "язык и только язык" ? И при чем здесь "рисование схем" ? Речь идет именно об интерфейсе "низкого уровня". Об интерфейсе "к концептуальной схеме". Не следует (и не получится) при использовании "объектных технологий" уходить от концептуальных схем и навигаторов...

Что значит "нифига" ??? По-моему, Вы серьезно заблуждаетесь. И слово "факт" ничего не меняет. "Факт" любой из этих операций, "входящих" в один документ, после его совершения КОНЕЧНО ЖЕ ЯВЛЯЕТСЯ САМОСТОЯТЕЛЬНЫМ ОБЪЕКТОМ, к которому должен быть прямой доступ, как к самостоятельному объекту. Он не чуть не хуже ни товара, ни склада...

Что значит "изобразить что-то подобное ссылкам" ??? При чем здесь встраивание объектов в другие объекты, о чем я Вас спрашивал ? Зачем встраивать ? Используйте, на здоровье, "что-то подобное ссылкам". В ОМД есть именно связи

Документ: товарная накладная --- Состоит из/Входит в ---> Операция отгрузки

Операция отгрузки <--- Для/Имеет --- Товар

а у Вас будет "что-то подобное ссылкам", чтобы от товара можно было бы получить операции его отгрузки. Только и всего...

Что значит "абсолютно никакой проблемы ... делаете SELECT... WHERE" ???
И после этого Вы не понимаете, что за слои ??? Так сделайте, пожалуйста, этот SELECT на объектном (концептуальном) уровне, чтобы было понятно...

Нет, НЕ ПОНЯТНО про многие-ко-многим. Я же старательно изобразил Ваш же пример. Есть связь многие-ко-многим

Товар <-*- Хранится на/Хранит ---> Склад

с характеристиками связи (!) (например, количество товара на складе). Вот этот пример и приведите, пожалуйста, в НРМ...
21 июл 05, 22:31    [1725999]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Андрей Леонидович
Guest
Плохо, ModelR, что Вы "не видите проблем". При чем здесь GoodsMotion ?
В примере, который я подробно описал на концептуальном и, одновременно, на логическом уровне, есть только одна связь многие-ко-многим

Товар <-*- Хранится на/Хранит ---> Склад

причем, у нее есть свои собственные характеристики...
21 июл 05, 22:36    [1726004]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Уважаемый Андрей Леонидович.

Во первых, я не понимаю Ваших терминов. У Вас в голове какая то своя, сложная система (нам, гагарам, сие недоступно). Я же во вступлении не пишу, что целью НРМ является реализация сложной системы, существующей в голве у Андрея Леонидовича. Цель гораздо более простая - совмещение манипуляционных возможностей РСУБД с выразительными возможностями, присущими ОО-языкам. Всего то.

И потом - я же Вас просил не перетаскивать меня на "концептуальный уровень". Ну я слегка повелся, но больше ни-ни. Не буду больше об этом. Тьфу-тьфу - зарекаюсь. :) Ну не подходт Вам предложенная система типов - ну что я могу сделать. Ну нет там явно определяемых связей, что с этим делать то?. Ну не кажется Вам она более выразительной, что набор явно определяемых таблиц, а я Вам обратное доказывать и не собираюсь. В общем в отношении Ваших схем и стрелочек я посыпаю голову пеплом и умываю руки. Только я прошу - не надо раздувать здесь флейм по этому поводу.

И наверное в отношений связей Вы правы. ;) Вот взять вес в килограммах! Вроде бы казалось, чистой воды "атрибут" "объекта". Ан нет - приглядишся, и оказывается, что это очень абстрактное представление "связи" между этим объектом, эталонной гирей в Париже и земным шаром. А там глядь! ...кругом то одни связи!! а от объектов вообще ничего не осталось!!! Что делать, что делать??? Караул.....

Еще раз прошу - не надо раздувать здесь флейм. Если приспичит (сорри, но понравилось мне это слово:) ) зовите меня в топик называемый "Вопрос". Ведь все равно никто уже и не помнит, что это был за вопрос....
21 июл 05, 23:28    [1726070]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 Андей Леонидович
Ах да! Я забыл - Вы же просили показать, " чтобы от товара можно было бы получить операции его отгрузки". Посколку в примере я использую внешний ключ, то эта выборка будет выглядеть до обидного просто
Object(GoodsMotion WHERE MovedItems.ArtNo = 'ваштовар')
Это вернет групповую ссылку на множество обектов, содержащих данные об отгружаемом товаре.

Кстати, если бы я использовал ссылку - то есть вместо поля ArtNo, явно содержащее строку-товарный артикул (внешний ключ), было бы поле ArtRef, ссылающееся на объект о-типа Goods - это выглядело бы так
Object(GoodsMotion EXPAND MovedItems.ArtRef<No = 'ваштовар'>)


Хотя... может Быть вам нужно отгужаемое количество?
GoodsMotion.MovedItems [Pieces] WHERE ArtNo = 'ваштовар'


Или Вам нужны даты, когда товар был отгужен?
GoodsMotion [DateOfAction] WHERE MovedItems.ArtNo = 'ваштовар'


В общем не стесняйтесь - спрашивайте, чтоВам из схемы в примере нужно достать. Только не надо срашивать как это или почему это так - находите объяснение в тексте сами.
22 июл 05, 00:30    [1726129]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Андрей Леонидович
Плохо, ModelR, что Вы "не видите проблем".
Мне нет
Андрей Леонидович
При чем здесь GoodsMotion ?
Оккам так советовал
Андрей Леонидович

В примере, который я подробно описал на концептуальном и, одновременно, на логическом уровне, есть только одна связь многие-ко-многим

Товар <-*- Хранится на/Хранит ---> Склад

причем, у нее есть свои собственные характеристики...
Хорошо, бог с Оккамом, возьмем ваш новый пример.
ИМХО НРМ допускает все три способа представления количества Kij товара ti на складе sj:
(t1,((s1,k11),(s2,k12)))
(t2,((s1,k21),(s3,k23),(s4,k24)))
(t3,((s2,k32),(s4,k34)))
или
(t1,s1,k11)
(t1,s2,k12)
(t2,s1,k21)
(t2,s3,k23)
(t2,s4,k24)
(t3,s2,k32)
(t3,s4,k34)
или
(s1,((t1,k11),(t2,k21))
(s2,((t1,k12),(t3,k32)))
(s3,((t2,k23)))
(s4,((t2,k24),(t3,k34)))
Так в чем проблема?
22 июл 05, 11:01    [1726814]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Андрей Леонидович
Guest
Есть, Ugene ! Не буду, конечно же, "раздувать здесь флейм" про "концептуальный уровень", хотя цель (моя, во всяком случае) - чтобы он не отличался от лигического...

Вы НЕ ПОКАЗАЛИ КАК ОТ ТОВАРА ПОЛУЧИТЬ ОПЕРАЦИИ ! Вы показали как в реляционной системе получить множество операций с необходимостью использования оптимизатора ! Неужели не понимаете разницу ? Но ведь это я опять "флейм раздуваю"...
23 июл 05, 22:56    [1730545]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Андрей Леонидович
Guest
Вы, ModelR, так совсем запутаетесь. Выберите уж какой-нибудь один способ, чтобы связи многие-ко-многим поддерживались бы на уровне СУБД.
Второй способ понятен. Это "Р"СУБД.
А вот ни первый, ни третий способы связь на уровне СУБД не представляют. Это разве не очевидно ?
Вот U-gene в ироничной форме (предупредив, чтобы я не "раздувал флейм") намекнул, что связи вообще не нужно представлять на логическом уровне (а про концептуальный говорить нельзя)...
Может Вы тоже так считаете ?..
23 июл 05, 23:01    [1730547]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Эта... Андрей Леонидович... тогда я вообще ничего не понял. Я описал отгузки и товары. В моей "концептуальной" схеме отгрузка характеризуется отгужаемыми в ней товарами, что успешно могу представить в схеме "логической" как с помощью ключа, так и с помощью ссылки. Далее Вы просите показать дословно " чтобы от товара можно было бы получить операции его отгрузки". Я показываю как это можно сделать. Оказывается - это не то! А что тогда? Вы подробно объясните!!!

Только давайте Вы будете использовать мою "концептуальную" и мою абсолютно соотвествующуу ей "логическую" схему. Или, по крайней мере, поставте себя на мето кладовщика или логиста, представте себе какие данные им нужны (это ИМХО не зависит от всяких схем) и попробуте сформулировать вопрос так, как задали бы его они. Ну а если ничто из предложенног Вам не подходит, то я опять таки посыпаю голову пеплом и умываю руки. "Концептуализировать" по Вашему я не буду.
24 июл 05, 00:24    [1730563]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Андрей Леонидович
Guest
Да, U-gene, "это не то". И я очень четко объяснил что именно "не то". Вы показали как в РЕЛЯЦИОННОЙ системе получить множество операций с НЕОБХОДИМОСТЬЮ использования оптимизатора ! Неужели не понимаете разницу ???
Извините, что приходится напоминать Вам и ModelR элементы теории баз данных. Они касаются представления любых связей - и "нашей с Вами" один-ко-многим, и "нашей с Вами и ModelR" многие-ко-многим. (Кстати "вариант 2" ModelR так же не полноценно представляет, на самом деле, связь двух объектов. Мое "одобрение и понимание" - это всего лишь "реверанс" в сторону "реляционных традиций", так сказать.)

Связь между n объектами может быть ПОЛНОЦЕННО ПРЕДСТАВЛЕНА только с помощью n! перестановок идентификаторов ("внешних ключей" в "Р"СУБД). "К счастью" при n=2 n! так же, опять же извините, =2.
Так что, ModelR, не 1-ый или 3-ий, а что-то типа "1-ый И 3-ий" ! Но это криво получается, и не на уровне СУБД...

Теперь, надеюсь, понятно, что к идентификатору товара "привязаны" (в ОСУБД) идентификаторы соответствующих операций...
24 июл 05, 23:35    [1731027]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Ув Андрей Леонидович!

Я в прошлый раз забыл спростиь - а что такое "оптимизатор"? Откуда Вы его взыли? Опять из головы? У меня нет оптимизатора. У меня есть операции рел алгебры. Откуда в Вашей голове ВДРУГ появился оптимизатор??? Его нет, аллё, расслабтесь!!!

Давайте не будем махать факториалами, выдавая это за элементы теории баз данных. Я, нагло ссылаясь на собственный текст, не пытаюсь выдать это за элементы теории, Если Вы пишите "элементы теории" дайте ссылку. Я таких "элементов теории" явно нигде не видел. Но даже не в этом дело. Я просто не нахожу глобальной разницы, между тем, что говорю я и тем что говорите Вы.

Андрей Леонидович. На протяжении 3 разворотов сего топика я пытался донести простую идею - для того, что бы работать с переменными отношений необязательно их явно определять. Некоторые не поняли и ушли. Надеюсь, что некоторый процент людей это понял. Теперь, специально для Вас :) я попытаюсь донести такую же простую мысль - для того, что бы работать с той информацией, которую Вы пытаетеся представить в виде связи. её так же не обязательно явно (как связь) описывать.

Итак, когда я говорю про ссылки, я имею в виде конечно ссылки, которые определны в спецификации типа. То есть это
НРМ(стр4)
... декларативный перечень внешних свойств (атрибутов и методов), который можно рассматривать как интерфейс, по которому можно организовывать взаимодействия с объектом.
Из того, что он декларативный, следует то, что он доступен для чтения всеми пользователями системы. Естественно мы можен определить все типы, на которые ссылается данный тип (это определно в спецификации этого типа), однако я так же хорошо представляю себе операцию, которая возвраoftn нам все компопнеты всех классов, содеражащие ссылки на данный тип. Эта операция не описана в НМР, но ей богу это будет всего лишь простая выборка по каталогу значимых типов. То есть информацию о том, что ссылки существуют(мета данные) можно получить в любом случае - и том случае ссылки из объекта наружу, и в случае ссылки снаружи на объект.

Далее
автор
...Операция раскрытия ссылки позволяет организовывать ассоциативный доступ к данным объектов любого типа, связанного с объектами данного типа по ссылке. При этом доступ к данным возможен как по ссылке, так и в противоположном направлении (конечно, на самом деле используемое при этом отношение, являющееся результатом операции EXPAND, не подразумевает каких-либо направлений, поскольку поля, содержащие OID объектов, ссылочные поля, содержащие OID связанных объектов, и поля данных в них абсолютно равнозначны).
Это я специально для Вас выделил. Понимаете ли в R-переменные - они так и построены. Схема R-переменной может содержать любое число равнозначных атрибутов-ссылок среди любого числа других атрибутов. Конечно , среди этого любого числа атрибутов-ссылок один (OID) будет обязательнным: в каждом кортеже эта ссылка на объект, данные о котором в этом кортеже представлены. Но эта "обязательность" - единственная черта, которая отличает его от всех остальных ссылок.

То есть если в о-типе специфицирован компопнет, содержащий ссылку ..., refOID, ... . то в соотвествующей R-переменной мы получаем пору ссылок
автор
OID, ... , refOID, ...
, что в точности представляет вашу связь (все это в НМР прописано). Может быть оно по другому называется, может быть эти чвязи и не и не заданы явно, но в принципе это абсолютно тоже самое.

Но все таки, Андрей Леонидович..... Вы меня попросили дословно чтобы от товара можно было бы получить операции его отгрузки". Я Вам это показал. Я показал, как в НМР можно получить доступ к набору объектов типа "Отгрузки" или информацию о этих отгрузках, используя как критерий поиска данные объектов, на которые ссылаются объекты типа "Отгрузка".

Скажите, я Вам требуемуемую информацию достал? все равно - с использованием "ортимзатора" (но все же......что это? в модели нет никаких оптимизаторов, я в предложенных опрециях я , явно или неяно, пользовался только рел. алгеброй... откуда он взялся?) или без использования оного - результат то достигнут???

Или Вы думаете, что пользователь, проанализирует какой-нить там план исполнения этого простого запроса, и увидев, что использовался пресловутый "оптимизатор" (ГЫ-ГЫ), в сердцах выбростит результат вне зависимотсти от его правильнсоти? Думаю вряд ли. Он "же не индиот" (с)Лем
25 июл 05, 01:38    [1731080]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Андрей Леонидович
Второй способ понятен. Это "Р"СУБД.
А вот ни первый, ни третий способы связь на уровне СУБД не представляют. Это разве не очевидно ?
Не понимаю....
В моем понимании связь как термин (в рамках тематики форума) - категория семантического моделирования, применяемая в методологии "Сущность-связь".
Плз:
1) что вы называете связью?
2) что означает "представлять связь на уровне СУБД" и чем первый и третий способы не представления?
25 июл 05, 10:15    [1731334]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Андрей Леонидович
Guest
Без оптимизатора, в Вашем случае, никуда, даже есди я расслаблюсь. Это "сердце" любой "Р"СУБД, и при реализации НРМ никуда от него не денешься. И упоминание о нем в моем сообщении более четко конкретизирует простую мысль: Вам придется перебирать ВСЕ операции ради того, чтобы найти те, которые сделаны с ЭТИМ товаром...
Так что не следует критиковать меня за упоминание про оптимизатор...

Зря Вы так стараетесь донести до меня "простую мысль". Ее уже донес Кодд. Точнее - Дейт, так как у Кодда были сомнения относительно способов представления связей. А вот "моя" "простая мысль" о естественном (явном) представлении связей все еще нуждается в "донесении"...
Информацию Вы ДОСТАЛИ. РЕЗУЛЬТАТ ДОСТИГНУТ ! Но не от товара Вы получили операции его отгрузки, а от операций отгрузок. Как и "полагается" в реляционной системе...
26 июл 05, 00:48    [1734436]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Андрей Леонидович
Guest
Я рассказал, ModelR, о представлении связей в сообщении 1731027. См. так же тему "Вопрос".
26 июл 05, 00:50    [1734439]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Андрей Леонидович
Без оптимизатора, в Вашем случае, никуда, даже есди я расслаблюсь. Это "сердце" любой "Р"СУБД, и при реализации НРМ никуда от него не денешься. И упоминание о нем в моем сообщении более четко конкретизирует простую мысль: Вам придется перебирать ВСЕ операции ради того, чтобы найти те, которые сделаны с ЭТИМ товаром...


Тюююю, Андрей Леонидович, очевидно мне еще раз придется повторить простую мысль - я работал с формальной моделью и с формальными операциями. Как оно реализовано (есть оптимизатор или их нет) - меня не касается. По мне так любая РСУБД выполняет любую операцию мгновенно... или с задержкой... в общем меня это не касается. Вдруг кто-нить через ...цать лет реализует в железе какую-нить супер-пупер ассоциативную реляционную память, где любые операции над любым подмножеством выполняются с одной и той же скоростью? мои построения от этого никак не изменяться.

Еще раз говорю, что моей задачей было показать принципиальную возможность совмещения манипуляционных возможностей РСУБД с выразительными возможностями, присущими ОО-языкам (безотносительно того, как это может быть реализовано в некой конкретной РСУБД и того, какие в этой конкретной РСУБД имеются или отсутсвуют оптимизаторы). Ваш последний пост прямо-таки убеждает меня в том, что результат достигнут.

Андрей Леонидович
Информацию Вы ДОСТАЛИ. РЕЗУЛЬТАТ ДОСТИГНУТ ! Но не от товара Вы получили операции его отгрузки, а от операций отгрузок. Как и "полагается" в реляционной системе...
Нам гагарам этот Ваш дзэн - "результат ничто, путь все" - не ясен. "РЕЗУЛЬТАТ ДОСТИГНУТ!"(с) Андрей Леонидович
26 июл 05, 01:37    [1734455]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Андрей Леонидович
Связь между n объектами может быть ПОЛНОЦЕННО ПРЕДСТАВЛЕНА только с помощью n! перестановок идентификаторов ("внешних ключей" в "Р"СУБД). "К счастью" при n=2 n! так же, опять же извините, =2.
Так что, ModelR, не 1-ый или 3-ий, а что-то типа "1-ый И 3-ий" ! Но это криво получается, и не на уровне СУБД...
Да, если это навигационная СУБД, то есть n! вариантов навигации. Или, если это индекс к реляционной таблице по n полям, то есть n! вариантов индекса. Вы утверждаете, что только то представление (схема индексирования) полноценна, которое хранит все навигационные пути (все индексы)? И к чему такая крутизна? Для оптимизатора?
26 июл 05, 11:39    [1735306]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
U-gene
По мне так любая РСУБД выполняет любую операцию мгновенно... или с задержкой... в общем меня это не касается.

Однако практика показала, что распространение получают эффективные а не формальные реализации. Тот же SQL в качетве примера взять. IBM его РЕАЛИЗОВАЛА ЕФФЕКТИВНЕЕ по сравнению с имеющимися на то время другими реализациями других подходов! И это определило развитие СУБД на десятилетия в перед. Мало того, формальные подходы не учитывающие потребности практики рискуют остаться оторванными от жизни, тоесть не полными в формальном смысле )))
26 июл 05, 12:05    [1735460]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
shuklin
...Однако практика показала, что распространение получают эффективные а не формальные реализации...


ИМХО не надо вот так прямо противопоставлять эффектифность и обоснование. То есть
Системы баз данных третьего поколения: Манифест
...Предложение 2.4: Показатели производительности не имеют почти ничего общего с моделями данных и не должны в них проявляться...
Это не я придумал. Так написано в "Манифесте БД третьего поколения" - в манифесте, так или иначе реализуемым СУБД, которые называют себя объектно-реляционными. Тем же Oracle.

То есть можно бороться за эффективность соблюдая при этом достаточный формализм. Я не говорю, что реализация должна быть абсолютно формальной. Но она называется реализацией именно потому что что то реализует. Какую то идею, какие то принципы.

Например, SQL не реализует в чистом виде то, что написал Кодд. Однако основные то идеи в нем как то(хорошо или плохо) выражены. Но если бы не было статьи Кодда, то сегоднящнего SQL не было бы вообще.
26 июл 05, 12:29    [1735660]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Еще вопросец. Ничего не сказано о функциональных зависимостях и нормализации, хотя допускается у объектного типа несколько глобальных ключей.

Кстати, в каком смысле понимается ключ - как РМД (минимальный набор атрибутов) или как в SQL (суперключ - то же ключ)?

Считается ли что нормализация просто не актуальна - типа при должном семантическом проектировании все и так будет хорошо? Или проработка отложена на будущее?
26 июл 05, 13:52    [1736250]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
автор
...Ничего не сказано о функциональных зависимостях и нормализации, хотя допускается у объектного типа несколько глобальных ключей.
.....
Считается ли что нормализация просто не актуальна - типа при должном семантическом проектировании все и так будет хорошо? Или проработка отложена на будущее?


Да не то что бы на будущее. У меня уже были некоторые мысли по этому поводу. Наверное, их стоит переписать используя термины НРМ и пример из него.

автор
Кстати, в каком смысле понимается ключ - как РМД (минимальный набор атрибутов) или как в SQL (суперключ - то же ключ)?
Я нашел в сети формулировку для "суперключа" - "сложный ключ с большим числом столбцов, чем необходимо для того, чтобы быть уникальным идентификатором." То есть суперключ включат ключ - может это кому то потребуется. В НРМ требование минимальности отсутсвует.
26 июл 05, 14:22    [1736437]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
В конструкции R переменной типа должна учитываться структура локальных ключей. Для краткости опущены типы скаляров не ссылочного типа и определения кортежей даны ин-лайн.
Склад
{    Наименование;
    Остатки Set of (Дата; Товар; Ячейка; Количество;) Localkey (Дата,Товар,Ячейка);
}

ФЗ: Склад.Остатки.( Ячейка->Товар )

Декомпозиция
Склад
{   Наименование;
    НазначениеЯчеек Set of ( Ячейка;Товар;) Localkey (Ячейка);
    Остатки Set of (Дата; Ячейка; Количество;) Localkey (Дата,Ячейка);
    Constrain local foreign key   Остатки.Ячейка on НазначениеЯчеек.Ячейка;
}
Т е. R переменная типа - не (усложненное) декартово произведение, а (усложненное) эквисоединение с учетом структуры локальных ключей.

Либо вместо декомпозиции - "объективизация" ячейки или остатка. Как я понимаю вложение:
Склад
{   Наименование;
    Ячейки Set of ( 
        НомерЯч;
        Товар ;
        Остатки  Set of (Дата; Количество;)  Localkey (Дата);  ) Localkey (НомерЯч);
}
не допускается, но
Ячейка 
    {   НомерЯч;
        Товар;
        Остатки  Set of (Дата, Количество;)  Localkey (Дата);  )
    };
Склад
{   Наименование;
    Ячейки Set of (Ячейка: Ячейка);
}
приемлемо.
26 июл 05, 16:52    [1737347]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Или лучше
Склад
    {   Наименование;
    }
Ячейка 
    {   
        НаСкладе: Склад;
        НомерЯч;
        Товар;
        Остатки  Set of (Дата, Количество;)  Localkey (Дата);  )
    };
?
Вообще при объектном подходе критерии выбора весьма не однозначны. По какой причине можно из приведенных вариантов предпочесть один?
26 июл 05, 17:03    [1737405]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7 8 9 10 .. 14   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить