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

Откуда: Москва. Россия
Сообщений: 1576
Ключевой является фраза...
...А какая разница, что такое "навигация"?...

Если для Вас не представляет разницы, что это такое, то ИМХО навигация очень хорошо реализована например в GOOGLE EARTH. Там нажимаешь на любую точечку на земном шаре и БАЦ - система показывает ее поближе. Тоже ведь "навигация"? Или Вы все же какую-то другую "навигацию" имеет в виду? Но тогда Вам есть разница? Это я к тому, что если здесь кто то "замыливает вопросы" то это не я.

Например, по п.1. моего высказывания (... эффективные OLTP системы можно достаточно комфортно создавать и без применения реляционных СУБД.):

OLTP-системы прекрасно существовали и до появления реляционных СУБД. Они строились на базе т.н. мониторов транзакций, например: MVS-TSO, CICS, IMS. Позднее мониторы транзакций прилепили и к реляционным СУБД. Это, однако, вовсе не означает, что OLTP-системы, построенные на базе, к примеру, СУБД IMS (к слову, живет и здравствует и ныне) априори не эффективны - очень даже эффективны, если сделаны грамотно.
Отлично! Я могу развить эту мысль - грамотно сделанная система должна быть эффективной, иначе она сделана неграмотно (только, вы не находите, что это звучит как банальнось?) даже если она сделана на ассемблере.

И что? Какое отношение это длинное, красивое и без сомнения правильное предложение имеет к тезису ЧАЛа "РМД - бесполезный отстой" Мы зачем мы опять начинаем сравнимать системы с моделями?

Впрочем, все это действительно имеет весьма опосредованное отношение к сабжу.
Зачем тогда писать об этом?

Поэтому раскрывать все пункты здесь я не стану.
Понятно. Про "нативный уровень" это даже я не буду уточнять. Скорее всего услышу, что это не имеет значения.

Но замечу, что хотел лишь обратить ваше внимание на то, что хотя коллега ЧАЛ и выступает весьма эмоционально и непоследовательно, но в ряде его высказываний есть зерно разумного.
Ага... Ложка меда в бочке ..мммм..... дегтя. Удивительно, что здесь Вам ковыряться не лень и время на это есть.

Вы же предпочитаете вести себя в его стиле...
Ну если человек вопросы и просьбы не воспроинимает, что же мне остается делать? С волками жить...
...и замыливать вопрос...
Секундочку. Какой вопрос я замылил?
...вместо того, чтобы исправить свои недоработки...
Ага. ИМХО основная моя недоработка по ЧАЛу - то, что я ипользую РМД как формальный фундамент, и то, что результат также является реляционной системой. Можно я это исправлять не буду?
автор
...или пояснить свою позицию.
Если Вы не читали топик, то я скажу, что я честно это пытался сделать на протяжении последних четырех разворотов. Для того, что бы пояснить, я должен узнать, что же неясно. Если же в голове одно сплошное упрямое жжжжж, то с этим рано или поздно надоедает бороться. Опять же если Вы не читали топик, то я Вас уверяю - не разумные вопросы я стараюсь ответить максимально подробно.
Коллега ЧАЛ возможно и не заслуживает того, чтобы вы ему отвечали на все его наезды, но ведь и другие тоже читают эту дискуссию ...
Надеюсь.
30 авг 05, 17:47    [1830030]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
vybegallo
Guest
Alexey Rovdo

Ну а об отличии ключей и идентификаторов я уже высказывался, и если vybegallo пишет "... хранение связей внутри записи, т.е. то, на чем погорели сетевые базы данных", то мне бы хотелось увидеть как он раскроет эту тему подробнее (pleese).


Вопрос не в том, являются ли ROWID идентификаторами или нет. Вопрос в том, что начиная хранить связи внутри объекта (а не в отдельной таблице) , мы нарушаем первую нормальную форму. Результатом чего будет либо усложнение логики СУБД и числа чтений (времени доступа), либо необходимость перекомпилировать базу при изменении связей. По сути, это разница между компиляторами (СУБД с хранением связей в записях/объектах) и интерпретаторами (РСУБД). Откомпилированные программы могут быть быстрее, но интерпретаторы гибче, и в случае изменений вам придется "перекомпилировать" гигабайты/терабайты данных.
31 авг 05, 00:41    [1830864]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
vybegallo
Guest
Alexey Rovdo


Да не вопрос. Например, по п.1. моего высказывания (... эффективные OLTP системы можно достаточно комфортно создавать и без применения реляционных СУБД.):

OLTP-системы прекрасно существовали и до появления реляционных СУБД. Они строились на базе т.н. мониторов транзакций, например: MVS-TSO, CICS, IMS. Позднее мониторы транзакций прилепили и к реляционным СУБД. Это, однако, вовсе не означает, что OLTP-системы, построенные на базе, к примеру, СУБД IMS (к слову, живет и здравствует и ныне) априори не эффективны - очень даже эффективны, если сделаны грамотно.


Оригинальное высказывание было "навигацию прекрасно можно заменить операторами UPDATE, DELETE и SELECT". А можно не заменять. Т.е. именно OLTP системы можно строить _ В ТОМ ЧИСЛЕ НА SQL_. Поэтому все ваши примеры не в кассу.
А вот насчет второго высказывания (это которое "DW / DSS невозможно построить, используя навигационные системы") у вас есть возражения или контрпримеры ?
31 авг 05, 00:49    [1830880]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
tchingiz
Member

Откуда:
Сообщений: 39054
U-Gene
все 10 страниц не прочитал пока.
уже говорили, что кривые закладки в твоей статье?

К сообщению приложен файл. Размер - 0Kb
31 авг 05, 05:44    [1831011]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
tchingiz
Member

Откуда:
Сообщений: 39054
теоретически в левой части должно быть оглавление.
)))))))
1
поздравление со свидетельством.

2
можно ли считать, что в своем НРМ ты хочешь формализовать рассматриваемую область?
31 авг 05, 05:45    [1831012]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
tchingiz
Member

Откуда:
Сообщений: 39054
формализовать - свести к другим широко известным формальным понятиям, то есть это слово одновременно надо читать как определить и обьяснить.

эта.
если мое предположение про формализацию рассматриваемой области - правда,
то не мог бы ты дать ссылку на определение свойства постоянства данных.
имхо, разговор о нем (равно как и разговор о какихто временах и пространствах) явно избыточен, перегружает текст манифеста и должен быть удален из работы
31 авг 05, 05:55    [1831014]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Alexey Rovdo
Member

Откуда: Москва
Сообщений: 913
vybegallo

"навигацию прекрасно можно заменить операторами UPDATE, DELETE и SELECT". А можно не заменять. Т.е. именно OLTP системы можно строить _ В ТОМ ЧИСЛЕ НА SQL_.


Можно то можно. Но вот эффективность таких систем в ряде случаев можно поставить под сомнение.

vybegallo

А вот насчет второго высказывания (это которое "DW / DSS невозможно построить, используя навигационные системы") у вас есть возражения или контрпримеры ?


Равно и здесь, только ситуация обратная. DW/DSS таки можно строить на базе навигационных систем. Но вот эффективность будет скорее всего низкой.
31 авг 05, 10:49    [1831501]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 tсhingiz

теоретически в левой части должно быть оглавление.
ДА, конечно. Я заботился что бы текст на бумаге читался, и как то упустил, что у акробата дополнительные заморочки :).

можно ли считать, что в своем НРМ ты хочешь формализовать рассматриваемую область?
Стараюсь - если рассматриваемой областью считать следующее...
НРМ(стр2)
...как можно соотнести "мир объектный" и "мир реляционный". Существует еще один подход, который не может быть описан ни одним из предложенных в "Третьем Манифесте" вариантов ответа, и, тем не менее, позволяет объединить свойства объектных и реляционных систем в рамках единой системы...


не мог бы ты дать ссылку на определение свойства постоянства данных. имхо, разговор о нем (равно как и разговор о какихто временах и пространствах) явно избыточен, перегружает текст манифеста и должен быть удален из работы
По моему, в исходном тексте я употребил сочетание "свойство постоянства данных" только один раз, а именно: говоря о возможности реализации R*O системы на базе существующих РСУБД.
НРМ(стр24)
Отметим, что некоторые возможности реализуемой R*O системы целиком и полностью определяются свойствами используемой РСУБД; важнейшим из этих свойств, по нашему мнению, является свойство постоянства хранимых данных.
Я имел в виду, что, используя РСУБд как базовую систему, нам не прижется делать каких либо специальных телодвижения, для того, что бы обеспечить долговременное хранение данных. То есть это не свойство данных а свойтство системы(например, этим свойством не обладает ОЗУ). Согласен, фраза кривонавороченная. Однако, с учетом того, что это напрямую не относится к рассматриваемой областия (см. выше) я бы предпочел эту фразу исправить, но не выбрасывать.
1 сен 05, 01:01    [1834810]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Garya
Member

Откуда: Москва
Сообщений: 33194
Блог
Андрей Леонидович
"Нельзя не отметить, что между моделируемыми объектами и описывающим их множеством значений отношений существует сложная связь: данные о любом объекте могут храниться в разных переменных отношений и любая переменная отношения может хранить данные о разных объектах."

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

а) связей между "моделируемыми объектами" (Вы же нигде ясно не говорите, что связей не существует);

б) нормализации схемы БД.
Возможно, я не совсем понял суть спора между U-gene и АЛ. По-моему, они одновременно оба правы, но каждый - при взгляде с одного определенного ракурса. Вот, например, АЛ говорит в пункте б) о нормализации, имея в виду, судя по всему, классические N нормальных форм. Но они определены именно для классической реляционной теории, не всегда и не во всем стыкующейся с объектно-ориентированным подходом. Зачастую ООП-ешники вынуждены прибегать к денормализации, и это требования жизни. Нельзя молиться на принятый когда-то постулат. Насколько я понимаю, U-gene пытается эти постулаты несколько пересмотреть. Нормализация имеет положительные последствия (в части удобства манипулирования данными), но может иметь и отрицательные.

В процитированном отрывке я не углядел каких-либо противоречий. В ответе АЛ - тоже. Просто каждый говорит "немного о своем". :) U-gene - о пересмотре некоторых базовых принципов реляционного подхода. АЛ - о том, что пересматривать их нужно с учетом их незыблемости :).

Андрей Леонидович
Во-вторых, потому что без этих двух концепций она (фраза) относится к некоторой субъективной схеме: человек - это объект, а почки и кости мы будем хранить в разных отношениях. Получается, что кость - это не объект...
Разумеется, кость - это объект. Но попытка нормализовать отношения между всеми объектами может легко провалиться, если вы станете расписывать детальные отношения между многими и многими объектами, имеющимися в реальности. Потому что реальность не строго соответствует правилам и ограничениям целостности, как нам зачастую этого хотелось бы. У некоторых людей вместо почки может оказаться аппарат "искусственная почка". У некоторых людей могут быть ампутированы конечности, и вместо них установлены протезы. Объект "кость" может и не принадлежать объекту "человек", и даже объект "человеческая кость", найденный при археологических раскопках, может уже ему не принадлежать. Более того, этот объект может быть разбит на другие объекты - "обломки берцовой кости", которые, вроде бы являются частью объекта "берцовая кость". Если же при раскопках найден только один обломок берцовой кости (при отсутствии прочих), то объект "берцовая кость вообще" абстрактно, вроде бы есть, но физически - нет. Каждый человек - уникален, каждая берцовая кость - тоже. А уж об уникальности "обломков берцовой кости" можно было бы и не упоминать. Попытка систематизировать наши представления о предметной области неизбежно вносит в нее искажения. Чем более строгие правила мы пытаемся применять при систематизации, тем эти искажения более существенны. Попытка нормализовать отношения может также привести к искажениям. Отношения могут быть НЕЧЕТКИМИ, частичными, выполняющимися по некоторым условиям (формулировка которых также может быть нечеткой или неполной). И в таких условиях система, максимально эффективно обрабатывающая информацию, не должна жестко следовать правилам "самим в себе". Объект может иметь методы, причем у одних объектов они могут работать одним образом, у других - другим.

Само понятие объекта, имеющего индивидуальный идентификатор (OID) говорит о том, что объектно-ориентированный подход заведомо допускает наличие информации за пределами системы, которая влияет на классификацию объектов. Представим себе в системе два объекта, описанных двумя различными OID, но имеющим совершенно одинаковые значения всех своих атрибутов. Являются ли эти два объекта с точки зрения системы одним объектом? НЕТ!!! Почему? (очень важный вопрос!) ПОТОМУ ЧТО ЗА ПРЕДЕЛАМИ СИСТЕМЫ ИМЕЕТСЯ ИНФОРМАЦИЯ, КЛАССИФИЦИРУЮЩАЯ ИХ КАК РАЗНЫЕ ОБЪЕКТЫ, ИСХОДЯ ИЗ КОТОРОЙ ПОЛЬЗОВАТЕЛЬ СИСТЕМЫ ПРИНЯЛ РЕШЕНИЕ РАЗДЕЛИТЬ ИХ И В СИСТЕМЕ. ПРОСТО АТРИБУТЫ, ИМЕЮЩИЕ В РЕАЛЬНОСТИ РАЗНЫЕ ЗНАЧЕНИЯ, НЕ ПОПАЛИ В ОПИСАТЕЛЬНУЮ ЧАСТЬ ОБЪЕКТОВ ПРИ СИСТЕМАТИЗАЦИИ. Тем не менее, эта информация может учитываться неявно. Попытка нормализации отношений зачастую сводит на нет возможность оперировать с информацией, расположенной за пределами системы. Реляционная теория изначально исходит из того, что все атрибуты МОЖНО рассовать по кортежам отношений. Что в результате можно получить удобные для обработки в терминах реляционной алгебры множества значений. Но ведь реальная жизнь гораздо сложнее. В природе нет двух абсолютно одинаковых людей, деревьев, булыжников или даже молекул. Каждый объект хоть самую малость отличается от всех других. Хотя бы тем, что занимает в пространстве разные положения. Систематизируя информацию, мы заведомо отбрасываем часть информации, имеющей отношение к этой самой уникальности. И натыкаемся на проблемы в обработке информации системой, когда они вызваны именно УНИКАЛЬНОСТЬЮ.

Я говорю не про ту уникальность, которую можно определить оператором UNIQUE. Я говорю про глобальную уникальность всего и вся. При этом я не отвергаю реляционную теорию. Она предоставляет действительно очень удобный математический аппарат. Просто пользоваться им нужно выборочно. Когда речь заходит об объектной ориентированности, нужно проявлять особую осмотрительность.

Формулировки в манифесте "глобальной уникальности" в пределах объектов одного типа (а не в пределах отношения) так же выпадает за рамки реляционной теории (удивительно, что АЛ акцентировал внимание на менее существенной, ПМСМ, детали). Хорошо это или плохо? По-моему, это нормально. :)

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

А вот это место меня несколько смутило. "Компоненты FromWarehouse и ToWarehouse могут ссылаться на существующие в системе объекты типа Warehouse (зачение этих полей может быть не определено - FromWarehouse в случае поставок, ToWarehouse в случае продажи)". Это больше реляционный, нежели ОО-подход. В ООП принято наследовать классы от базового. В одном случае должен иметься класс "Поставки", в котором имеются ТОЛЬКО поля, соответствующие поставкам, в другом - класс "Продажи", в котором определены поля только для продаж. А вот как эта информация записывается в реляционные отношения - вполне может записываться и так (если речь идет об отношении, соответствующем родительскому классу). Честно говоря, я не понял, предлагаемый в примере подход предлагается как более правильный, или им предполагалось подчеркнуть преемственность реляционным подходам.

Приведенные в манифесте примеры очень похожи на те, с которыми мне довелось экспериментировать в Cache'. Даже термин OID там присутствует. Только с "хранимостью" все не так просто. В Cache' четко разделяется понятие объекта в БД (хранимого) и его копии в оперативной памяти, с которым в данный момент производятся какие-либо операции. Для обращения к объектам по идентификаторам даже используются РАЗНЫЕ идентификаторы. OID - это глобальный идентификатор объекта в БД. Но обращаясь по этому идентификатору, можно всего лишь загрузить объект в память (или сохранить обратно в базу данных). При загрузке в память ему выдается временный идентификатор для выполнения над ними любых манипуляций. После выгрузки объекта из памяти этот идентификатор освобождается и может быть присвоен другому загруженному в память объекту. При многопользовательском доступе в разных сеансах разные пользователи могут в результате в оперативной памяти несколько разных копий одного и того же объекта и по-разному их модифицировать. Все вопросы, которые касаются контроля логической целостности, конфликтов доступа и т.п. решаются именно в момент попытки сохранения. А вот в данном манифесте я не обнаружил лишь объявление "stored". А где же разбор конфликтов одновременного доступа к данным? Или там используются жесткие блокировки всего и вся при первых попытках доступа к информации первых же сеансов? Особенно, если речь идет об объектах, тип которых описан с применением многократных наследований - сколько же там реальных кортежей будет задествовано, если учесть, что и методы перегружались, и поля переопределялись, а часть информации все равно сохраняется в кортежах родительского класса (или это не так?).

"Переменная же t.a позволяет выполнить обратное действие - получить OID (т.е. ссылку на объект) на основании данных компонента". Уточню - или несколько ссылок. Или ни одной. При этом задействуется дорогостоящая поерация поиска. В Cache' есть такие же возможности, но к ним стараются прибегать только в исключительных случаях, и по возможности оперировать ВСЕГДА только с OID (а еще лучше не с ним, а с идентификатором копии объекта, уже загруженного в память). Иначе работа системы превращается в работу тормозной системы... :)

В Cache' OID - целое число. Вроде бы, его можно переопределить. Но OID всегда одного типа вообще для всех объектов в пределах БД. И это правильно. Можно, грубо говоря, обратившись к БД, спросить "а скажите, объект №12345 какого ТИПА?" Хотя я бы предпочел, чтобы это был GUID (чтобы не было поменьше проблем с репликацией).

Про R-переменные типа / компонентов типа - идея понравилась. У самого схожие были. Только я в более глубокие дебри залез. Сначала я понял, что попытка описать и систематизировать реальные объекты невозможна без выделения отдельной характеристики информации - времени. Объекты по жизни ИЗМЕНЯЮТСЯ. Не достаточно хранить моментальный снимок их состояния. Слишком часто нужно оперировать объектами в том виде, в котором они представлены в определенный момент времени. Более того, описания ТИПОВ объектов также могут изменяться во времени (это уже где-то на уровне проходной желтого дома :) ). Медитация на эту тему привела меня к пониманию, что и понятий "время" существует как минимум два (я делал доклад на эту тему, можно посмотреть презентацию). Но это было раньше. Сейчас дебри стали еще более непроходимыми. Я попытался по-максимуму приблизить концепции, которыми оперирует разработчик, и реальную жизнь. В реальной жизни отсутствуют отдельно "описание класса" и "объекты класса". Они существуют совместно в самом объекте - описание вместе с данными. При этом каждый объект уникален. Описание объекта "Василий Пупкин" хранится в ДНК самого этого объекта. И даже после смерти "родительских классов" объект продолжает нормально существовать, определяться, "отрабатывать методы" и "предоставлять атрибуты для операций". Василий Пупкин - это одновременно и описание класса, и экземпляр объекта. Он может выступать в качестве "родителя" для дочерних подобных ему же "типо-экземпляров". При этом работают базовые принципы "обектной ориентированности" (в частности, наследование), просто некоторые их положения требуют некоторого переосмысления. Каждый объекта:
1. Имеется возможность отслеживать изменение в ОПИСАНИИ класса во времени (он не умел ходить - теперь умеет, был полноценным человеком - теперь калека и т.п.). Для каждого объекта появляется возможность вносить изменения в его описание на ИНДИВИДУАЛЬНОМ уровне (вот она - природная уникальность всего и вся!). Несколько детей, родившихся у одних и тех же родителей, могут отличаться друг от друга не только ЗНАЧЕНИЯМИ атрибутов, но и генотипом - в результате мутаций. Каждый объект получает возможность корректировки его описания, не затрагивающего другие аналогичные объекты.
2. Отслеживать изменение ЗНАЧЕНИЙ АТРИБУТОВ экземлпяра класса во времени (был темноволосый - стал седой, весил 50кг, теперь 82 и т.п.)
3. Производить потомство, используя "множественное наследование", определяя для каждого экземпляра потомства, что именно должно быть унаследовано от какого родителя, а что должно отличаться от всех родителей (мутация).
4. Возможно внесение изменений в "родителя" (задним числом) так, чтобы эти изменения повлияли бы на ранее "рожденных" потомков (а вот этого в природе нет - вот зачем нужно второе время!). Это сродни переменным и методам класса, и "R-переменным типа". Только эти механизмы завязаны не на ВИД методов/переменных, а на ВИД модификации описания/данных). То есть, в самой операции модификации указывается, должно ли работать наследование и если да, то до какой степени иерархии.
5. В подобной концепции автоматически - на системном уровне реализуется журнализация всех операций и отслеживание версий. Причем, это касается не только модификации объектов, но и программного кода (!). Легко и просто реализуется репликация, а механизмы разрешения конфликтов репликации (даже самых-самых изощренных) очень просто выводятся на уровень бизнес-логики.
6. Модификация схемы данных и программного кода теряет глубокие отличия от модификации просто данных. При развитии визуальных средств программирования и одновременном упрощении пользования информационными технологиями (базовые элементы могут оказаться проще Бейсика) модификацией поведения объектов могут заниматься продвинутые пользователи. Обладающие исключительными познаниями IT-специалисты превращаются в экзотику вроде трубочистов (чего это я несу, сечас меня запинают свои же братья-кролики 8-/).
7. При этом существенно возрастет значение, а также возможности по управлению правами доступа к информации. Разделение на программистов и юзеров, грубо, делается именно с помощью этих механизмов.

Вот только окончательно я еще все не осмыслил и выложить в виде готовой концепции я это пока не могу. Есть очень непростые моменты, которые нужно разложить по полочкам. Но (копчиком чую) в подобной концепции зарыты колоссальные возможности. Никогда не поздно учиться у матушки-природы... :) Подобные системы могут стать основой саморазвивающихся интеллектуальных комплексов, и человек на Земле... гхм... может стать лишним... В общем, еще семь дней, глядишь, еще одну Землю сотворю... :) А может быть ну его к лешему? Лучше уж на каком-нибудь DBase-II ковыряться, а то еще нападут на наших детей-внуков какие-нибудь "терминаторы"? :)

Пожалй, лучше вернуться к обсуждению НРМ, для нашего же блага...

В общем, интересный документ. Мне понравился. Не понятно, только , пропуск буквы T в слове CONSTRAINT - это предлагаемая специфика синтаксиса, или просто опечатка? По крайней мере, он соответствует духу эволюционного развития всего и вся. А всяких попрыгунчиков завсегда щелкали по носу... :)
1 сен 05, 13:32    [1836575]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Garya
Но попытка нормализовать отношения между всеми объектами может легко провалиться, если вы станете расписывать детальные отношения между многими и многими объектами, имеющимися в реальности.

Предлагаю не использовать термин «отношение» иначе, чем в реляционном смысле, так как очень трудно воспринимать мысль. Может надо что-то вроде «связи между объектами»?
Garya
Потому что реальность не строго соответствует правилам и ограничениям целостности, как нам зачастую этого хотелось бы. < <skipped> >.
Полагаю, что напротив, реальность гораздо более строго соответствует правилам и ограничениям, чем мы в состоянии вообще понять. В конце концов, законы физики еще никто не отменил. Они лишь уточняются, и процесс этот бесконечен. А законы физики ни что иное, как правила и ограничения, которым подчиняется реальность.
Garya
Попытка систематизировать наши представления о предметной области неизбежно вносит в нее искажения.
Тут, видимо, просто нечетко выражена мысль. Я не могу поверить, что вы действительно полагает, что например систематизация моих представлений о геологии может исказить эту самую геологию.
Garya
Чем более строгие правила мы пытаемся применять при систематизации, тем эти искажения более существенны.

А мне кажется, что дело не в строгости правил, а в их адекватности. Более того, чем меньше мы определяет правил и ограничений, тем более зыбкими, нечеткими, некорректными предстают знания о предметной области, тем меньше способна система «сделать» что-либо осмысленное с данными этой предметной области. В пределе — ноль правил —> ноль знаний —> ноль возможностей системы управлять данными.
Garya
Попытка нормализовать отношения может также привести к искажениям. Отношения могут быть НЕЧЕТКИМИ, частичными, выполняющимися по некоторым условиям (формулировка которых также может быть нечеткой или неполной). И в таких условиях система, максимально эффективно обрабатывающая информацию, не должна жестко следовать правилам "самим в себе".
Тут, видимо, надо определиться с понятием «эффективность обработки информации», Я не понимаю, что это значит в точности в данном контексте. Но я точно знаю, что достоверность результатов обработки данных немыслима без наличия правил и ограничений, причем чем их больше и чем они точнее, тем достоверность выше. А зачем нужна эффективность без достоверности? Можно ответ получить быстро, но кому нужен неверный ответ?
1 сен 05, 15:13    [1837189]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
2Garya
автор
Само понятие объекта, имеющего индивидуальный идентификатор (OID) говорит о том, что объектно-ориентированный подход заведомо допускает наличие информации за пределами системы, которая влияет на классификацию объектов. Представим себе в системе два объекта, описанных двумя различными OID, но имеющим совершенно одинаковые значения всех своих атрибутов. Являются ли эти два объекта с точки зрения системы одним объектом? НЕТ!!! Почему? (очень важный вопрос!) ПОТОМУ ЧТО ЗА ПРЕДЕЛАМИ СИСТЕМЫ ИМЕЕТСЯ ИНФОРМАЦИЯ, КЛАССИФИЦИРУЮЩАЯ ИХ КАК РАЗНЫЕ ОБЪЕКТЫ, ИСХОДЯ ИЗ КОТОРОЙ ПОЛЬЗОВАТЕЛЬ СИСТЕМЫ ПРИНЯЛ РЕШЕНИЕ РАЗДЕЛИТЬ ИХ И В СИСТЕМЕ. ПРОСТО АТРИБУТЫ, ИМЕЮЩИЕ В РЕАЛЬНОСТИ РАЗНЫЕ ЗНАЧЕНИЯ, НЕ ПОПАЛИ В ОПИСАТЕЛЬНУЮ ЧАСТЬ ОБЪЕКТОВ ПРИ СИСТЕМАТИЗАЦИИ.

Они являются с точки зрения данных неразличимыми. (Да, в РМД это запрещено, но чисто формальным приемом - еще один суррогатный атрибут - решается.). Мы знаем только одно - объектов с именем "X" (любым иным набором несуррогатных атрибутов) два. Если придет сообщение <один объект "X" переименован в "Y">, то никаким образом невозможно понять, какие именно данные должны подвергнуться изменениям - просто берем первый попавшийся из "X".
Объектный подход - оперирование не только данными, а еще и полочками, на которых лежат данные внутри системы. Как и суррогаты, полочки вне системы не определены - или это не полочки, а искусственые ключи, тогда они являются данными и мы обрели способ различать объекты по данным.
Я к тому, что объектный подход не решает проблему "правильного" соответсвия программных объектов объектам внешнего мира. Это иллюзия, примерно как вечный двигатель. Еще раз: полочки - не объекты внешнего мира. Лучше вообще говорить не объектах а фактах внешнего мира, оставляя "объект" за программными полочками, чтобы не путать кардинально различные понятия.
автор
Я попытался по-максимуму приблизить концепции, которыми оперирует разработчик, и реальную жизнь. В реальной жизни отсутствуют отдельно "описание класса" и "объекты класса". Они существуют совместно в самом объекте - описание вместе с данными. При этом каждый объект уникален.
Верно, но сила абстракции именно в том, что выделив общее, мы можем один и тот же метод применить к разным объектам. За что и боремся, а тут вроде предлагается для каждой гайки - свой ключ? Впрочем, еще не смотрел презентацию, может ошибаюсь.
автор
Модификация схемы данных и программного кода теряет глубокие отличия от модификации просто данных
Легким движением руки брюки превращаются.... Успехов!
1 сен 05, 17:16    [1838000]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Garya
ЧАЛ
НРМ
"Нельзя не отметить, что между моделируемыми объектами и описывающим их множеством значений отношений существует сложная связь: данные о любом объекте могут храниться в разных переменных отношений и любая переменная отношения может хранить данные о разных объектах."


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

Возможно, я не совсем понял суть спора между U-gene и АЛ. ...Просто каждый говорит "немного о своем". :) U-gene - о пересмотре некоторых базовых принципов реляционного подхода.
Объясните, где это в этой фразе пересматриваю реляционный подход? Есть отгрузка (или документ об отгрузке) Для хранения информации об отгрузках любой реляционьщик будет использовать две таблицы - одну на заголовки, другую на строки. Информацию о каждой отгрузке попадает в множество(две) таблиц. И каждая из этих таблиц содержит информацию о множестве отгрузок. Я так и написал. Где здесь пересмотр чего -либо?

Garya
Небольшая неточность в манифесте. В одном месте написано "Типы делятся на значимые и объектные". И подробно разжевано, чем они отличаются (кстати, мне очень понравилось это место :) ). Суть в том, что объекты не сравнимы по значениям. И вдруг дальше я натыкаюсь на "Для объектов этого типа не определены глобальные ключи - таким образом, в системе могут существовать неразличимые по значению объекты этого типа". В принципе, я понял, что имелись в виду значения атрибутов объектов, развернутые до значимых типов. Но не все это могут понять. Может быть, имеет смысл немного подредактировать формилировки.
Да, если глобальный ключ для класса определен, то в данной конкретной системе все объекты будут уникальны по своему значению (состоянию = совокупность значений компопнентов). Если глобальный ключ не определен. - в системе могут в один момент времени могут существовать разные объекты имеющие одинаковое состояние. Глобальный ключ - это ограничение целсотности данных. Если оно для класса задано - все объекты должны быть разными по состоянию (совокупности значений компопнентов). Не задано - могут существовать одинаковые по состоянию. Для объектов описывающих отгрузки такой ключ может быть задан на поле "номер отргузки". Это гаратирует, что эти объекты будут разными не только сами по себе (как разные объекты), но и по полю "номер отргузки". ИМХО никаких неточностей нет. Разве что (с учетом того, что ранее написано, что...
НРМ(стр5)
Совокупность значений компонентов объекта определяет состояние объекта.
...) вместо "неразличимые по значению" можно написать "неразличимые по состоянию". Так будет точнее?

Garya
А вот это место меня несколько смутило. ....Честно говоря, я не понял, предлагаемый в примере подход предлагается как более правильный, или им предполагалось подчеркнуть преемственность реляционным подходам.
Не то и не другое. Мне так показалось короче - одни класс, который описывает движение товара и по складам, и на склады, и со складов.

Насчет Cashe... и всего остального. ИМХО в данном случае Вам Ваши знания, мысли и идеи неколько мешают. Например, Вы пишете про "хранимые объекты и объекты в памяти". В НРМ этого нет. Там есть просто объекты - они где лежат, там и обрабатываются. Я же недаром, отвечая tchingiz'у, сказал, что фразу
НРМ(стр24)
"некоторые возможности реализуемой R*O системы целиком и полностью определяются свойствами используемой РСУБД; важнейшим из этих свойств, по нашему мнению, является свойство постоянства хранимых данных."
(точнее идею, которая эта фраза несет) предпочел бы оставить. В частности, предполагается, что в используемой РСУБД деление данных на хранимые(на диске) и обрабатываемые(в ОЗУ) уже преодолено. В РСУБД данные где лежат, там же и обрабатываются - R*O системы, построенная Над_Реляционной, этим пользуется. (Конечно, подразумевается, что объекты R*O системы клиентам не отдаются - отдаются данные о этих объектах.)

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

Garya
При этом задействуется дорогостоящая поерация поиска.

Если подходить к этому делу формально, то...
НРМ(стр23)
Замечание. Рассматривая принципиальную возможность предлагаемой реализации, мы не задаемся вопросами ее производительности и эффективности.
Если неформально и образно, то сравнение скорости R*O-системы со скоростью используемой РСУБД (где вся логика реализована на стороне РСУБД), ИМХО подобно сравнению скорости программы на С++ со скоростью программы на ассемблере.

Garya
...Можно, грубо говоря, обратившись к БД, спросить "а скажите, объект №12345 какого ТИПА?"...

...это есть...
НРМ(стр10)
Для объектов определены операции, позволяющие определить тип этих объектов. В связи с тем, что в R*O системе поддерживается наследование объектных типов, данное требование требует некоторых разъяснений. Существуют две операции, позволяющие определить тип объекта. Первая операция o IS t (где o - ссылка на объект, а t – имя типа), возвращает истину, если объект, определяемый ссылкой o, является объектом данного типа. Подразумевается, что, в случае наследования, объект любого типа-наследника является также объектом базового типа.... Вторая операция, o OF t, возвращает истину, когда объект, определяемый ссылкой o, был создан как объект класса t (т.е. этот объект был создан операцией new t)....


ГЫ-ГЫ - это я про CONSTRAIN. Чесно слово - не виноват! Я забыл как, набил CONSTRAIN, а WORD это сожрал - я и подумал, что прально. :) Ну да фиг с им - одно глагол, другое существительное.... В общем CONSTRAIN it. :) Клянусь, исправлю.

Про время, гены, мутации и т.д. - без комментариев. Я предпочёл остаться на уровне значений, переменных и типов. Так оно спокойнЕе. По крайней мере понимаешь, о чем говоришь...:)
2 сен 05, 02:10    [1839068]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
tchingiz
Member

Откуда:
Сообщений: 39054
U-gene
2 tсhingiz

теоретически в левой части должно быть оглавление.
ДА, конечно. Я заботился что бы текст на бумаге читался, и как то упустил, что у акробата дополнительные заморочки :).

можно ли считать, что в своем НРМ ты хочешь формализовать рассматриваемую область?
Стараюсь - если рассматриваемой областью считать следующее...
НРМ(стр2)
...как можно соотнести "мир объектный" и "мир реляционный". Существует еще один подход, который не может быть описан ни одним из предложенных в "Третьем Манифесте" вариантов ответа, и, тем не менее, позволяет объединить свойства объектных и реляционных систем в рамках единой системы...


не мог бы ты дать ссылку на определение свойства постоянства данных. имхо, разговор о нем (равно как и разговор о какихто временах и пространствах) явно избыточен, перегружает текст манифеста и должен быть удален из работы
По моему, в исходном тексте я употребил сочетание "свойство постоянства данных" только один раз, а именно: говоря о возможности реализации R*O системы на базе существующих РСУБД.
НРМ(стр24)
Отметим, что некоторые возможности реализуемой R*O системы целиком и полностью определяются свойствами используемой РСУБД; важнейшим из этих свойств, по нашему мнению, является свойство постоянства хранимых данных.
Я имел в виду, что, используя РСУБд как базовую систему, нам не прижется делать каких либо специальных телодвижения, для того, что бы обеспечить долговременное хранение данных. То есть это не свойство данных а свойтство системы(например, этим свойством не обладает ОЗУ). Согласен, фраза кривонавороченная. Однако, с учетом того, что это напрямую не относится к рассматриваемой областия (см. выше) я бы предпочел эту фразу исправить, но не выбрасывать.

))))))))))))
я читал майский экземпляр и не ожидал, что ты ее так переделываешь
1
если мы рассматриваем формализацию, то ты (на мой взгляд) слишком много пишешь. невозможно читать почти.

правда это больше про предыдущую версию. эту еще не одолел.

/*
шкала для сравнения из тех книжек, которые читал )))
100 ... Топология Энгелькинга
90 .... Общая Топология. акад.Мирзаханян
... элементарный учебник физики под редакцие проф. Ландсберга.
80
70.... политэкономия капитализма Маркса
60.... Дейт
50
40 ... НРМ предверсия.
30 ... политэкономия социализма
20
10 .... программирование в виндовсе. петзольд
*/
из текущей версии
1
предоложения надо всетаки короче. Слишком навороченные обороты.

2
вторая страница предложение
"Предполагается, что речь идет о данных, описывающих некую предметную область, которая представляет собой совокупность реально существующих обьектов".
НЕ ПРЕДПОЛАГАЕТСЯ, что эти обьекты реально существуют. В след. абзаце уже идет противоречие - речь идет о любой предметной области и о любом ее обьекте.
// В пт Джамиля маячила както с игрой рагнарок, игра написана на MySql.
// база хранила описание обьектов из воображаемого мира

3
долговременность я бы выкинул, как и упоминания о времени.
есть формальные эквивалентные определения алгоритма (вычислимость по черчу, машина Поста, машина Тьюринга). Любой алгоритм эквивалентен программе на машине Поста. В частности, любая R*O система может быть повторена на машине Поста. В его определениях использовалось понятие непротиворечивости и не использовалось время и долговременного хранения.

Интуитивно, я подозреваю что отсутствие долговременного хранения данных влечет нарушение непротиворечивости Поста. То есть выходит за рамки программирования как такового.

4
правильно ли я понял, что (утрированно)
отношение - это описание таблицы;
значение отношения - множество кортежей, которые лежат в таблице;
переменная отношения - место в памяти RDMS-машины, где лежит множество кортежей?


Вот я бы, в разделе основное требование НРМ включил бы эти(или другие короткие определения) и основное требование.
А все обьяснения про взаимосвязи обьектов и отношений выкинул бы..
2 сен 05, 08:38    [1839230]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

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

По сравнению с майской версией это на 60-70% написана с нуля.

1) Знаю. Стараюсь.
2) Реально существующие выброщу прои первом же случае
3) Не знаб что сказать. Если я и гворю ог долговременности (ктсати где?) то абсолютно неформально. тончно также можно гвоврить просто о хранении данных.
4)
правильно ли я понял, что (утрированно)
отношение - это описание таблицы;
значение отношения - множество кортежей, которые лежат в таблице;
переменная отношения - место в памяти RDMS-машины, где лежит множество кортежей?
Утрировано - да. Но про это в общем то в используемой литературе написано - в том же третьем манифесте.
5 сен 05, 13:06    [1846339]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Garya
Member

Откуда: Москва
Сообщений: 33194
Блог
U-gene
Garya
ЧАЛ
НРМ
"Нельзя не отметить, что между моделируемыми объектами и описывающим их множеством значений отношений существует сложная связь: данные о любом объекте могут храниться в разных переменных отношений и любая переменная отношения может хранить данные о разных объектах."


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

Возможно, я не совсем понял суть спора между U-gene и АЛ. ...Просто каждый говорит "немного о своем". :) U-gene - о пересмотре некоторых базовых принципов реляционного подхода.
Объясните, где это в этой фразе пересматриваю реляционный подход? Есть отгрузка (или документ об отгрузке) Для хранения информации об отгрузках любой реляционьщик будет использовать две таблицы - одну на заголовки, другую на строки. Информацию о каждой отгрузке попадает в множество(две) таблиц. И каждая из этих таблиц содержит информацию о множестве отгрузок. Я так и написал. Где здесь пересмотр чего -либо?
Мне кажется, что вот здесь:
U-gene
Здесь просто надо понимать, что одно знанчние - это тоже множество, и что это значение может быть подмножеством другого значнеия, описываещего предметную область в целом
Дело в том, что если одно и то же МНОЖЕСТВО повторяется, являя ЗНАЧЕНИЯ какого-то поля в таблице (например, для всех его записей), то можно с уверенностью сказать, что в классическом смысле 3NF в данном случае не просматривается. По идее под понятие "множество" должна быть заведена ОТДЕЛЬНАЯ ТАБЛИЦА, в нее помещена одна-единственная запись, реализующая данное множество, а во всех местах, где это множество используется, должна использоваться ССЫЛКА на эту запись.
Если вы скажете, что этот вопрос относится к цвету кишок конкретной реализации, то я с этим не совсем согласен. Если именно нормализованную схему хранения этой информации применить в какой-либо реализации, то... Мы можем столкнуться с тем, что реализация МОДИФИКАЦИИ значения множества таким образом, чтобы она коснулась только некоторых кортежей, связана с определенным трудностями. Если мы используем традиционный UPDATE самого множества, то получим его изменение также в тех кортежах, модифицировать которые не собирались. Подобные "затруднения" (решаемые, в общем-то) касаются любых операций с данными, требующим записи (INSERT, DELETE, UPDATE). Есть методы решений этих затруднений без нарушения 3NF - 5NF, но связанные с некоторым напряжением серого вещества. Есть простой метод - ДЕнормализация. В данном конкретном случае напряжение серого вещества кажется вполне приемлемым. Но если мы вспомним, что любой элемент любого множества в свою очередь может оказаться множеством, и число итераций таких "множеств во множествах" не ограничено, то выясняется, что решения задумки без нарушения 3NF табличных данных придумать уже очень непросто. Хотя, может быть, и возможно (я просто не напрягался до такой степени, чтобы в этом убедиться). Во всяком случае требуется, чтобы некоторые триггеры что-то там где-то проверяли, создавали бы автоматически новые наборы записей, переставляли бы ссылки с разных записей на одну и ту же, или творили еще какие-то подобные чудеса.

U-gene
Garya
А вот это место меня несколько смутило. ....Честно говоря, я не понял, предлагаемый в примере подход предлагается как более правильный, или им предполагалось подчеркнуть преемственность реляционным подходам.
Не то и не другое. Мне так показалось короче - одни класс, который описывает движение товара и по складам, и на склады, и со складов.
Если речь идет о "классе", то наверняка он выступает в качестве родительского для классов, которыми описаваются движения различного вида. Мне вот интересно узнать, как авторы манифеста видят себе хранение информации в таблицах, соответствующим объектам класса, рекурентно унаследованного от множества предков. Что происходит с переопределенными свойствами, перегруженными методами, с восстановленными от "древних предков" (reintroduce), с множественным наследованием (и конфликтами определений, которые при этом могут возникать). В Cache' имеется реализация многих этих наворотов, включая множественное наследование, но далеко не всех. А возможности организации "объектов в объекте" там вообще вызывают слезы жалости.

U-gene
Насчет Cashe... и всего остального. ИМХО в данном случае Вам Ваши знания, мысли и идеи неколько мешают. Например, Вы пишете про "хранимые объекты и объекты в памяти". В НРМ этого нет. Там есть просто объекты - они где лежат, там и обрабатываются. Я же недаром, отвечая tchingiz'у, сказал, что фразу
НРМ(стр24)
"некоторые возможности реализуемой R*O системы целиком и полностью определяются свойствами используемой РСУБД; важнейшим из этих свойств, по нашему мнению, является свойство постоянства хранимых данных."
(точнее идею, которая эта фраза несет) предпочел бы оставить. В частности, предполагается, что в используемой РСУБД деление данных на хранимые(на диске) и обрабатываемые(в ОЗУ) уже преодолено. В РСУБД данные где лежат, там же и обрабатываются - R*O системы, построенная Над_Реляционной, этим пользуется. (Конечно, подразумевается, что объекты R*O системы клиентам не отдаются - отдаются данные о этих объектах.)
Мне кажется, тут зарыта большая собака, причем очень кусачая, которую Вы проглядели. Клиентская часть орагнизует пользовательский сеанс, который "видит" информацию как определенную совокупность данных. Существуют блокировок в транзакциях, проблемы грязного чтения... Предлагаемые Вами трактовки делают эти проблемы на многие порядки более существенными. Представим себе такую ситуацию. Одновременно запущено два сеанса. В одном сеансе делается проверка "если у человека на правой руке 5 пальцев...", которая возвращает TRUE. Спустя милисекунду в другом сеансе ампутируется безымянный палец. А в первом сеансе идет "продолжение банкета": ... то одеть на безымянный палец кольцо. И ба-бах! - непонятная ошибка. Это - проблема грязного чтения, решение которой кажется очевидным. До тех пор, пока мы не проверяем число пальцев у невесты данного объекта, число ложноножек у инфузорий, живущих на этих пальцах и т.д. И через некоторое время выясняем, что в такой системе реально может работать только один пользователь. Потому что всем другим доступ к информации полностью закрыт на время работы первого вошедшего в систему юзера, который умудрился заблокировать все ресурсы. А если не все? Тады - дедлок, вероятность которого возрастает на многие порядки. Один сеанс проверил число пальцев у жениха, второй у невесты, надели кольца куда положено, затем они пытаются проверить "ответные руки" - а не получается - дедлок. И если в простой реляционной модели более-менее понятно, как с такими вещами бороться, то в этой я, например, понятных раз и навсегда рецептов не вижу. Опять же имеется проблема быстродействия. В Cache' не просто так разделяются операции чтения/записи от операций обращения к свойствам объекта. Если сразу множество свойств одного и того же объекта должны претерпеть модификацию, то гораздо-гораздо быстрее произвести 100 операций модификаций в оперативной памяти и только один раз сохранить результат.
В процессе многоэтапной модификации полей одного объекта у него могут возникнуть "нелогичные" состояния. Но поскольку они имеют отношения только к процессу модификации и не связаны с операцией сохранения в БД, эти состояния никак не конфликтуют с констрейнтами, установленными для объектов данного типа. Представьте, что с помощью команды модификации данных мы пытаемся переделать женщину в мужчину. Выдаем команду Пол:=мужской, данная информация сразу сохраняется в БД и на какое-то время в нем возникает мужчина со всеми женскими причиндалами. Происходит нарушение кучи констрейнтов, которыми мы заранее определили, что в базе данных могут быть только полноценные мужчины или полноценные женщины. Но положения НРМ нам воткнули палку в колеса.

U-gene
Возможные конфликты при манипуляциях с этим объектом разруливаются транзакциями, причем механизм транзакций - это еще одна крайне поезная штука, которую R*O система может напрямую взять из используемой РСУБД - и он, без сомнения, будет работать (аналогия - существует комп, который позволяет сохранить и загрузить копию своего ОЗУ. Этой возможностью может пользоваться любая программа - хоть на ассемблере, хоть на С++)
Нарушение констрейнтов может произойти и ВНУТРИ транзакции, в результате чего он уткнется носом в песок. Объекты - это такие очень злобные мурены, которые которые очень не любят, когда кто-то забывает, что они именно объекты, а не что-то другое.
5 сен 05, 16:38    [1847585]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
автор
Дело в том, что если одно и то же МНОЖЕСТВО повторяется, являя ЗНАЧЕНИЯ какого-то поля в таблице (например, для всех его записей), то можно с уверенностью сказать, что в классическом смысле 3NF в данном случае не просматривается.......
Эту фразу я не понял. Объясните подробнее. Можно на пальцах или пример?... кстати, это фраза не из НРМ. Забыл, откуда... интересно посмотреть контекст.

автор
По идее под понятие "множество" должна быть заведена ОТДЕЛЬНАЯ ТАБЛИЦА,
Не согласен в любом случае. Откуда такая идея? Почему из простой мысли, что простое значение является подмножеством более сложного, следует, что для этого простого должна быть заведена отдельная таблица? А что если оно просто артибут кортежа?

автор
...рекурентно унаследованного от множества предков...
Искал в Яндексе "рекурентное наследование" не нашел. Может яндекс тупой, может быть я . Объясните, что это.

автор
Что происходит с переопределенными свойствами, перегруженными методами, с восстановленными от "древних предков" (reintroduce), с множественным наследованием (и конфликтами определений, которые при этом могут возникать).
Мне кажется что-то из этогоуже обсуждалось(начиная отсюда). В рзультате сейчас это выглядит следующим образом...
НРМ(стр7-8)
Объектные типы образуют иерархию наследования (невозможно наследование объектных типов от значимых, значимые типы не могут наследоваться от объектных). Наследование объектных типов подразумевает, что спецификация типа наследника включает спецификацию родительского типа (или типа предка). Допускается множественное наследование. Существует предопределенный фиктивный объектный тип Object, по умолчанию являющийся предком для любого объектного типа.

Замечание. При множественном наследовании от типов, имеющих общий базовый тип, спецификация последнего не дублируется (используя термины С++ можно сказать, что спецификации объектных типов наследуются виртуально). В системе должен существовать механизм, позволяющий разрешать возможные в случае множественного наследования конфликты реализаций компонентов.
...
При наследовании компонента его реализация может меняться. Таким образом, компоненты типа (а, следовательно, и сам тип) являются полиморфными в том смысле, что одной спецификации может соответствовать несколько реализаций.


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

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

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

...Опять же имеется проблема быстродействия...
Ага... Она всегда есть :). ПОвторю, что...
НРМ(стр23)
Замечание. Рассматривая принципиальную возможность предлагаемой реализации, мы не задаемся вопросами ее производительности и эффективности.
5 сен 05, 17:56    [1848034]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Garya
Member

Откуда: Москва
Сообщений: 33194
Блог
U-gene
автор
Дело в том, что если одно и то же МНОЖЕСТВО повторяется, являя ЗНАЧЕНИЯ какого-то поля в таблице (например, для всех его записей), то можно с уверенностью сказать, что в классическом смысле 3NF в данном случае не просматривается.......
Эту фразу я не понял. Объясните подробнее. Можно на пальцах или пример?...
Пример. Имеется отношение (в просторечии - таблица), кортежи которого содержат в одном из полей ЗНАЧЕНИЕ, являющееся множеством. Всего в отношении 10000 записей, 4000 из которых содержат в данном поле ЗНАЧЕНИЕ {1; 5; 8; 9}, остальные 6000 содержат ЗНАЧЕНИЕ {2; 4; 7}. Если эти ЗНАЧЕНИЯ сохранять непосредственно в таблице, соответствующей отношению (например, в виде совокупности полей [Элемент1], [Элемент2], [Элемент3] и т.д.), то мы получим яркий пример нарушения 3NF. Если их сохранять упакованными в varbinary, например, мы получим неоптимальность хранения и требования выполнять операции распаковки над каждой записью (выполнять Full Scan таблицы) при фильтрации кортежей по условиям, в которых фигурируют элементы данного множества. Наиболее очевидный способ нормализовать данные - создать вспомогательную таблицу, в которую поместить два набора записей, идентифицируемых по коду набора:
Номер набора Значение
1 1
1 5
1 8
1 9
2 2
2 4
2 7
, а в основной таблице ссылаться на номер набора.

Конечно, мне можно возразить, что в реляционной алгебре нет понятия Full Scan и оптимизаторов. Но они имеются в реальной жизни, и имеют наглость вносить в эту жизнь помехи, которые иногда приводят к невозможности существования этой самой жизни. Абстрактные теоретические измышления, как мне кажется, могут иметь лишь абстрактную ценность. Извините, не имею желания никого обидеть. Но это мое IMHO, я его никому не навязываю. Поглядел уже выше диспут около этой темы - позиция Андрея Леонидовича мне кажется достаточно обоснованной (мой пример это тоже иллюстрирует).

U-gene
кстати, это фраза не из НРМ. Забыл, откуда... интересно посмотреть контекст.
отсюда.

U-gene
автор
По идее под понятие "множество" должна быть заведена ОТДЕЛЬНАЯ ТАБЛИЦА,
Не согласен в любом случае. Откуда такая идея? Почему из простой мысли, что простое значение является подмножеством более сложного, следует, что для этого простого должна быть заведена отдельная таблица? А что если оно просто артибут кортежа?
Пример показан чуть выше. Либо отдельная таблица, либо денормализация, либо Full Scan с дорогостоящими операциями распаковки. Иных вариантов мною, по крайней мере, не просматривается. Если Вы их видите, приведите пожалуйста. Либо я что-то не так понял... :)

U-gene
автор
...рекурентно унаследованного от множества предков...
Искал в Яндексе "рекурентное наследование" не нашел. Может яндекс тупой, может быть я . Объясните, что это.
От прабаушки с прадедушкой унаследована бабушка. От бабушки с дедушкой унаследован папа. От папы с мамой унаследован сын и дочка. В итоге сын и дочка рекурентно унаследованы от прабабушки и прадедушки. Сорри, если не совсем понятно выразил мысль. Если у прадедушки дедушки было свойство "рыжая борода", а Василий Пупкин унаследовал это свойство у своего деда, то... Где эта борода хранится - у прадеда или у Василия? А если взять и изменить задним числом рыжую бороду деда на черную - у Василия она тоже станет черной, или он теперь живет самостоятельной жизнью?

U-gene
НРМ(стр7-8)
Объектные типы образуют иерархию наследования (невозможно наследование объектных типов от значимых, значимые типы не могут наследоваться от объектных). Наследование объектных типов подразумевает, что спецификация типа наследника включает спецификацию родительского типа (или типа предка). Допускается множественное наследование. Существует предопределенный фиктивный объектный тип Object, по умолчанию являющийся предком для любого объектного типа.
Допустимость множественного наследования (МН) - это принципиальная фича Вашей концепции? В последнее время вокруг МН в определенных кругах полыхали очень бурные споры. Кто в них прав, то не прав - я судить не берусь. Но кроме конфликтов между несколькими родителями, существуют более глубокие проблемы. Некоторые аналитики приходят к выводу, что МН "не только полезно, но и вредно" :). Таким образом, отказ от МН, например в платформе .NET, обосновывается не только и не столько сложностью ее реализации, сколько желанием устранить сумбур в голове тех, кто МН намерен использовать на практике. Тут можно прочитать кое-что на эту тему. Вот выдержка по ссылке:
выдержка
Читатель может заметить - а как же множественное наследование? А никак. В природе такового не существует - все объекты реального мира являются или цельными, или составными. Множественное наследование было создано только как методика проектирования классов, когда разработчик не обладает полной информацией о самих классах. Автор статьи считает, что множественное наследование только запутывает реализацию прикладной области. Например, в ряде книг приводится случай, когда объект "тесто" получается множественным наследованием объектов "вода" и "мука". На самом деле это не так - даже при диффузии отдельные материалы все равно остаются сами собой, т.е. в данном случае мы имеем совершенно новый объект "тесто", который имеет среди атрибутов указатели на два класса - "тесто" и "вода" (или список составляющих "тесто" классов, как угодно). Характеристики "теста" при этом зависят не только от состава "воды" и "муки", но и от их процентного соотношения.
То же самое относится и к биологическому "рождению" - ребенок наследует свойства родителей, т.е. их наборы хромосом, и представляет собой типичный составной объект при отсутствии какого бы то ни было множественного наследования.
Конечно, множественное наследование в редких случаях облегчает программирование, однако это не значит что оно отражает суть реальных вещей, которые можно описать в программе.
Я не являюсь противником МН, скорее даже наоборот. Просто делать на него упор в данном документе или не делать - может быть просто промолчать?

U-gene
[quot ]...В процессе многоэтапной модификации полей одного объекта у него могут возникнуть "нелогичные" состояния....
Фраза ясна. Но точно также можно сказать, что в процессе модификации данных в любой БД в ней могут возникнуть "нелогичные" состояния. На то транзакции и нужны, что бы такие ситуации не фиксировались как состояние системы.
Это НЕ только и не столько проблема транзакций. Это еще и проблема реализации проверки констрейнтов. В частности, если вы используете ограничения ссылочной целостности (DRI MS SQL Server), то вы не сможете удалить заголовочную часть накладной, ДО detail-части, соответствующей ее позциям ДАЖЕ В ТРАНЗАКЦИИ, поскольку ограничения (констрейнты) проверяются ВНУТРИ ТРАНЗАКЦИИ после каждой операции. Если вы намерены удалить и заголовочную часть накладной, и ее позиции, то СНАЧАЛА необходимо удалить dteail-часть, а уже потом - master. Добаление же информации о новой накладной необходимо производить в проивоположной ПОСЛЕДОВАТЕЛЬНОСТИ. То есть, требования ACID в части атомарности транзакции не столь глобальны, как это иногда может представляться. Эти "атомы" немножко делятся на кварки. :) И порядок расположения этих "кварков" может оказаться весьма существенным для промежуточных состояний объекта. Подобные вопросы невозможно решить ТОЛЬКО транзакциями.

...Опять же имеется проблема быстродействия...
Ага... Она всегда есть :). ПОвторю, что...
НРМ(стр23)
Замечание. Рассматривая принципиальную возможность предлагаемой реализации, мы не задаемся вопросами ее производительности и эффективности.
Мда... Это я уже понял... :) А жаль... :) Но все равно спасибо за полезное чтиво.
6 сен 05, 22:19    [1852623]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
tchingiz
Member

Откуда:
Сообщений: 39054
Гаря.
Пост тоже не задавался вопросами производительности,
строя свою машину.
Ничего не жаль.

У-гене
везде подразумевать имхо.
)))))))))))))
                                        1
                                         


                           1.  долговременное хранение


     Я  думал,  что  текущая  и   предыдущая   версия   не   очень   отличаются.
"Долговременное" хранение было в предыдущей. Я бы и хранение не упоминал бы.

                                        2
                                         


                                   2.  понятия


     хорошо разбираемся с понятиями.


                                    Remark
     
     В третьем манифесте я не нашел (использовал в ворде ctrl+F)  сочетание
     "переменная отношения" и "значение отношения".

     В логике (программировании) есть сущности  которые  меняются,  и  сущности,
которые не меняются. Cущности, которые меняются - переменные. Сущности,  которые
не меняются - константы. Совершенно привычное  выражение  "переманная  принимает
значения из множества имярек" подразумевает, что значения являются константами.
     
     
     2.1.  отношение

     Я продолжаю  исходить  из  предпосылки,  что  ты  делаешь  попытку  создать
формальную систему. Желательно, что бы вновь создаваемая твоя формальная система
была согласованна (то ест использовала ранее)  с  предыдущей.  Иначе  невозможно
понимать. Предыдущая формальная система - это математика. В математике отношение
- это подмножество декартового произведения n - возможно различных множеств.  По
определению - это константа.

1
     чтобы уж совсем точно, то то что мы называем отношение тут  обозначено  как
     G(R)
     
          http://en.wikipedia.org/wiki/Relation_%28mathematics%29
     
          In mathematics, an n-ary relation (or n-place relation or often simply relation) is a
          generalization of binary relations such as "=" and "<" which occur in statements such
           as "5 < 6" or "2 + 2 = 4".
           It is the fundamental notion in the relational model for databases.
     
          Formally, a relation over the sets X1, ..., Xn is an (n + 1)-tuple R=(X1, ..., Xn, G(R)) where
          G(R) is a subset of X1 >< ... >< Xn
          (the Cartesian product of these sets). If X=X1=X2=...=Xn, R is simply called a relation over X.
          G(R) is called the graph of R and, similar to the case of binary relations,
          R is often identified with its graph.
     
     Поскольку отношение - это без сомнения константа,  то  выражение  "значение
отношения" воспринимается как  пропаганда  социализма.  типа  масла  маслянного.
"Значение  отношения"  невозможно  понять  иначе,  чем   "отношение".   Значение
                                        3
                                         

константы 5 есть просто 5.
     2.1.1.  6-е издание Дейт. страницы 84 - 86,

     Читал его лет 15 (другие издания) наконец дошло, что не нравится в  разделе
называемом "Значения отношения" я не нашел  что  это  такое.  Зато  в  дейте  на
странице 85 сверху обнаружил следующий текст:


                                    Remark
     
     Поэтому будет использоваться  термин  "переменнная  отношения",  когда
     нужно подчеркнуть, что имеем в виду  собственно  переменную;  и  будет
     специально использваться неудачный термин "отношение" для  обозначения
     значения отношения.

     Из выше сказанного надо признать неудачным термином  "значение  отношения".
На мой взгляд можно говорить о  "значении  переменной  отношения"  которое  есть
просто отношением.

     Далее отношение в смысле баз данных надо отделять  от  отношения  в  смысле
математики. БД-отношение, например.

     Переменная отношения - это понятно - если  не  абстрактно,  то  именованное
место в памяти, в которое можно ложить отношения.
     
     
     2.2.  кортежи (tuples)

     c кортежами можно согласиться коекак. )))) Хотя  кортеж  должен  быть  тоже
константой, и бессмысленно говорить о значении кортежа.
     
     2.2.1.  6-е издание Дейт. раздел переменные отношений. страница
             87 сверху


                                    Remark
     
     в первой статье Кодд говорил об изменяющихся со временем отношениях

     Вот это совершенно четкое нарушение принципа Оккама достойно лифтера.
     
     
     2.3.  тип переменной отношения, спецификация отношения

     Раз есть переменные, то толжен быть  тип  переменной  отношения.  Предлагаю
называть типом некоторое множество значений. Целый тип (short) - множество целых
значение от  -32000  до  +32000.  Диапазан  определеяет  предикат,  заданный  на
                                        4
                                         

множестве ВСЕХ ЦЕЛЫХ ЧИСЕЛ,  который  говорит  входит  ли  данное  целое  в  тип
(множество ) short. Тип отношения имярек - множество всех  отношений  (множество
множеств)  для  которых  выполняется  некоторый  предикат.  Должен  существовать
предикат, заданный на множестве  ВСЕХ  ОТНОШЕНИЙ,  который  говорит,  входит  ли
данное отношение в  тип  имярек.  Этот  предикат  можно  называть  спецификацией
отношения.

     В частности  спецификация  отношения  может  задавать  названия  атрибутов,
домены атрибутов, задавать предикат table-constraint
table-constraint :
[ CONSTRAINT constraint-name ] {
     UNIQUE ( column-name, ... )
   | PRIMARY KEY [ CLUSTERED ] ( column-name, ... )
   | CHECK ( condition )
   | foreign-key-constraint
}


                                    Remark
     
     А может и не  задавать  эта  спецификация  список  и  имена  атрибутов
     бд-отношения. В самом общем случае в переменную  отношения  Х,  должна
     быть возможность положить ЛЮБУЮ БД-ОТНОШЕНИЕ.  Это  просто  расширение
     возможностей   такого   оператора   рдбмс   как   alter   table.   Или
     последовательности drop table .....; create table....

                                        5
                                         


                           3.  основное требование HРМ

     
     
     3.1.  обьекты

     Упоминание обьктов в основном  требовании  надреляционного  манифеста  (как
претендующего на "вечность" как формальной системы) - неправильно. Имхо,

     1) обьекты - лишь дань сиюминутной (по сравнению с  математикой)  моде.  Не
факт, что им будет уделяться такое же внимание через 10-20 лет.

     2) понятие не слишком формализованное.
Я тебе давал ссылку на статью, автор которой считал, что лучше  бы  использовать
такое понятие как процессы. Обьект легко моделируется процессом,  а  процесс  не
легко моделируется обьектом.


                                    Remark
     
     Главное отличие, (если я ничего не путаю) процессы  от  взаимодействия
     до взаимодействия могут менять свое состояние. ОБьекты - нет.  Вот  на
     сишарпе работал, чето мне не бросились в глаза возможности у  обьектов
     менять состояние от одного вызова  метода  обьета  до  другого  вызова
     метода обьекта.

     То есть, понятие процесса - более общее. Раз  есть  претензия  на  описание
ЛЮБОЙ ПРЕДМЕТНОЙ области, то подразумевается, что R*O система  должна  описывать
предметную область сплошь состоящую из процессов.

требование нрм
     значение,  описывающее  состояние  сущностей  предметной  области,   должно
     представлять собой множество отношений. В текущей реализации манифеста  под
     термином сущность будем понимать термин обьект.

                                        6
                                         


                             4.  Данные R*0 системы

     
     
     4.1.  Различимые значения

     "Различимые значения" это че такое?

     8[]

     И длительное обсуждение "полного и прямого различения" тоже вода  сплошная.
Смахивает на лифтера после прочтения книжки "оракл за 24 урока".

     Даже в случае самых абстрактных типов, ВСЕГДА задается операция  сравнения.
Эта  операция  дает  ответ  на  вопрос  два  значения  находится   в   отношении
эквивалентности или нет. Все однозначно  трактуется.  Никаких  полных  и  прямых
различений нет. Обсуждение этих различений ничего не обьясняют.  А  в  обьектном
ориентированном программировании вновь создаваемые  типы  должны  обрабатываться
как встроенные. Операция сравнения обязана быть реализована.
     
     
     4.2.  типы множеств значений заданного кортежного типа

     это запомнить невозможно. кроме того, что такое "ТИПЫ МНОЖЕСТВ"?

7 сен 05, 08:26    [1852879]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 Garya
автор
Пример. Имеется отношение (в просторечии - таблица), кортежи которого содержат в одном из полей ЗНАЧЕНИЕ, являющееся множеством. Всего в отношении 10000 записей, 4000 из которых содержат в данном поле ЗНАЧЕНИЕ {1; 5; 8; 9}, остальные 6000 содержат ЗНАЧЕНИЕ {2; 4; 7}. Если эти ЗНАЧЕНИЯ сохранять непосредственно в таблице, соответствующей отношению (например, в виде совокупности полей [Элемент1], [Элемент2], [Элемент3] и т.д.), то мы получим яркий пример нарушения 3NF.
Аааа, понятно!... только где у меня в переменных отношения есть такие множества как атрибуты? У меня в переменных отношения в атрибутах только скаляры. Соответсвенно никаких отдельных таблиц, денормализаций и фулсканов нет в приципе. Я это на своем примере поясню.

НРМ(стр7,12,13)
Пример...Объектный тип GoodsMotion описывает движение товара. Существующие в системе объекты этого типа уникальны по атрибуту No. Компоненты FromWarehouse и ToWarehouse могут ссылаться на существующие в системе объекты типа Warehouse (значение этих полей может быть не определено - FromWarehouse в случае поставок, ToWarehouse в случае продажи). Компонент MovedItems содержит информацию о количестве перевозимого товара.

CREATE CLASS GoodsMotion
{
No INTEGER
CONSTRAIN GLOBALKEY No;
DateOfAction DATE;
FromWarehouse Warehouse;
ToWarehouse Warehouse;
MovedItems SET OF ArtQty
CONSTRAIN
LOCALKEY Art;
}
....
Определение объектного типа GoodsMotion можно также рассматривать как объявление R-переменной компонента типа GoodsMotion.MovedItems со схемой (OID, Article, Quantity). ...
....
Объектному типу GoodsMotion соответствует (так же) R-переменная этого типа GoodsMotion со схемой (OID:DOID, No:INTEGER, DateOfAction:DATE, FromWarehouse:Warehouse, ToWarehouse:Warehouse, MovedItems.Article:STRING, MovedItems.Quantity:INTEGER). Отметим, что это отношение определено на множестве скалярных типов, включающих тип объектных идентификаторов DOID и ссылочный тип Warehouse, который был определен в процессе объявления соответствующего объектного типа.
Итак мы сделали класс с несомненно сложной структурой. Тут даже 1НФ не пахнет. Однако объявление этого класса рассматривается также как объявление переменных отношений определенных на множестве скалярных атрибутов. В частности, есть переменная с именем GoodsMotion.MovedItems содержащая скалярный атрибут No и также, есть переременная с именем GoodsMotion содержащая скалряный же атрибут MovedItems.No. То есть в последнем слуучае выражение MovedItems.No - это всего лишь сложное имя скалярного атрибута. Если Вы воспринимаете здесь что-то, как какую-то сложную структуру, то слава богу - я именно этого и добивался. Но с формалной точки зрения, с точки зрения РМД MovedItems.No - это просто имя, а то, что Вы видите сложную структуру всего лишь слествие того, что оно похоже(всего лишь!) на имя элемента элемента сложной структуры. В заключении еще раз повторяю, что...
НРМ(стр23)
...использование сложных (с точки зрения пользователя) имен переменных и атрибутов отношений позволяет сохранить семантику сложных структур для данных, представленных в виде множества значений отношений.
...при этом конечно же подразумевается, что все эти отношения определены на множестве скалярных значений

От прабаушки с прадедушкой унаследована бабушка. От бабушки с дедушкой унаследован папа. От папы с мамой унаследован сын и дочка. В итоге сын и дочка рекурентно унаследованы от прабабушки и прадедушки.
Замечательно. Только при чем здесь реккурентно - убей непонял. ИМХО реккурентно было бы ежели бабушка с дедушкой были бы своими собственными родителями (ужос то какой!!!). А то, что Вы описали - это ИМХО называется непрямое наследование.

Если у прадедушки дедушки было свойство "рыжая борода", а Василий Пупкин унаследовал это свойство у своего деда, то... Где эта борода хранится - у прадеда или у Василия? А если взять и изменить задним числом рыжую бороду деда на черную - у Василия она тоже станет черной, или он теперь живет самостоятельной жизнью?
Лихой поворот событий. Сначала мы говорим о наследовании типов, а теперь как то незаметно переходим на объекты? "Рыжая борода" - это имя атрибута? Или есть атрибут "борода" а у него может быть значения "рыжая, черная"? Вы определитесь, а потом мы разберёмся.....

Допустимость множественного наследования (МН) - это принципиальная фича Вашей концепции?
Да нет. оно само собой получается. Правда. Совершенно пофигу, сколько у объектного типа предков один или много.

...
автор
...Конечно, множественное наследование в редких случаях облегчает программирование, однако это не значит что оно отражает суть реальных вещей, которые можно описать в программе.
...
Таки да? :)

Я не являюсь противником МН, скорее даже наоборот. Просто делать на него упор в данном документе или не делать - может быть просто промолчать?
А что, фраза, что такое наследование допускается - это упор?

Это НЕ только и не столько проблема транзакций. Это еще и проблема реализации проверки констрейнтов. В частности, если вы используете ограничения ссылочной целостности (DRI MS SQL Server), то вы не сможете удалить заголовочную часть накладной, ДО detail-части, соответствующей ее позциям ДАЖЕ В ТРАНЗАКЦИИ, поскольку ограничения (констрейнты) проверяются ВНУТРИ ТРАНЗАКЦИИ после каждой операции....
Опять же - Вы так и не обяснили, какое отношение транзакции имеют к вопросу поднимаемому в НРМ. Что же касается конкретно вашего пример, то в НРМ он решается просто. Создание объекта типа "накладная" подразумевает, в частности, то, что в используемой РСУБД возникает кортеж, соответсвующий заголовку. Для этого пользователю никаких ограничения целостности не надо определять вообще. Система за него это делает.

НРМ(стр23)
Замечание. Рассматривая принципиальную возможность предлагаемой реализации, мы не задаемся вопросами ее производительности и эффективности.

Мда... Это я уже понял... :) А жаль... :)
Увы мне.:) Но я не первый, кто допускает подобные "ошибки".

Но все равно спасибо за полезное чтиво.
WELCOME again! Хотя бы что бы немножко понять, о чем речь. А то из Ваших замечаний этого пока как то не видно. Отвечу на любые внятные вопросы.
7 сен 05, 11:03    [1853484]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Garya
Member

Откуда: Москва
Сообщений: 33194
Блог
tchingiz
Я тебе давал ссылку на статью, автор которой считал, что лучше бы использовать такое понятие как процессы
А можно эту ссылочку погромче прошептать, чтобы другие тоже расслышали? :)

Garya
Подобные вопросы невозможно решить ТОЛЬКО транзакциями.
Небольшое дополнение-пример. Представим себе таблицу, в которой определены поля Field1 и Field2 типа bit, для которой определен констрейнт CHECK, проверяющий выполнение условия Field1<>Field2. Представим также, что в этой таблице содержится одна запись, значения полей которой Field1=0 и Field2=1. В исходном состоянии значения констрейнта НЕ нарушается.
В соответствии с логикой текущей обработки информации нам необходимо изменить значения этих полей на противоположные (инвертировать их), то есть получить после сохранения в БД и завершения транзакции результат Field1=1, Field2=0, который НЕ приводит к нарушению условия CHECK-констрейнта. Если подобная модификация производится за одну ОПЕРАЦИЮ (а не транзакцию), то нарушения констрейнта не происходит:
Вариант 1
begin tran
update MyTable
set Field1=1, Field2=0
end tran
Однако, если попытаться в рамках транзакции выполнить операции модификации данных ПОСЛЕДОВАТЕЛЬНЫМИ операциями, то нарушение констрейнта станет неизбежным:
Вариант 2
begin tran
update MyTable
set Field1=1   /* здесь произойдет ошибка, поскольку возникнет промежуточное состояние записи Field1=1 и Field2=1 */
update MyTable
set Field2=0
end tran
Вариант 3
begin tran
update MyTable
set Field2=0   /* здесь произойдет ошибка, поскольку возникнет промежуточное состояние записи Field1=0 и Field2=0 */
update MyTable
set Field1=1
end tran
Для того, чтобы констрейн НЕ НАРУШИЛСЯ мы просто обязаны (вынуждены) использовать вариант 1. Особенность этого варианта в том, что в нем присвоение значений нескольким полям происходит В ОПЕРАТИВНОЙ ПАМЯТИ ДО МОМЕНТА ИХ СОХРАНЕНИЯ В БД, при котором и запускается проверка констрейнта.
Теперь спроецируем эту ситуацию на объекты, полагая, что Field1 и Field2 являются полями класса. Не имея возможности присвоить нескольким полям объекта в оперативной памяти ДО запуска операции записи в БД нескольким полям некоторой совокупности значений приводит к нарушению констрейнта CHECK из-за некорректных (с точки зрения этого констрейнта) временных промежуточных состояний объекта. Во многих и многих случаях придется просто отказаться от использования констрейнтов только потому, что присвоение значений полям объекта приводит к их моментальному сохранению в БД. Механизм транзакций эту проблему НЕ решает.
7 сен 05, 11:17    [1853559]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 Garya Прочитал ваш последний пост. Супер. Только о какой такой оперативной памяти Вы говорите? Откуда Вы ее взяли? Какое отношение это все имеет к САБЖу?
7 сен 05, 11:46    [1853770]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Garya
Member

Откуда: Москва
Сообщений: 33194
Блог
U-gene
2 Garya Прочитал ваш последний пост. Супер. Только о какой такой оперативной памяти Вы говорите? Откуда Вы ее взяли? Какое отношение это все имеет к САБЖу?
Оператвиная память взялась на моих пальцах, когда я на них (то есть, на пальцах) пытался раскрыть суть проблемы. Собственно проблема связана с тем, что практическая реализация сабжа невозможна без решения проблем разделяемого доступа к данным, которые в предложенном документе просто обойдены молчанием. У меня возникло ощущение, что эти проблемы не были достаточно хорошо продуманы, хотя бы из этой Вашей реплики:
U-gene
Фраза ясна. Но точно также можно сказать, что в процессе модификации данных в любой БД в ней могут возникнуть "нелогичные" состояния. На то транзакции и нужны, что бы такие ситуации не фиксировались как состояние системы.
Еще раз акцентирую внимание на том, что не все проблемы разделяемого доступа к данным могут быть решены ТОЛЬКО ЛИШЬ с помощью транзакций. Или решение этих проблем Вы полагаете возложить на тех, кто возьмется за конкретные воплощения идей манифеста?

U-gene
Аааа, понятно!... только где у меня в переменных отношения есть такие множества как атрибуты? У меня в переменных отношения в атрибутах только скаляры. Соответсвенно никаких отдельных таблиц, денормализаций и фулсканов нет в приципе.
Честно говоря, я уже немного запутался. :) Я исходил из Вашего комментария, высказанного здесь:
U-gene
...просто надо понимать, что одно знанчние - это тоже множество, и что это значение может быть подмножеством другого значнеия, описываещего предметную область в целом
. Возможно, я его не совсем правильно понял.

U-gene
Лихой поворот событий. Сначала мы говорим о наследовании типов, а теперь как то незаметно переходим на объекты? "Рыжая борода" - это имя атрибута? Или есть атрибут "борода" а у него может быть значения "рыжая, черная"? Вы определитесь, а потом мы разберёмся.....
Определяемся. Был тип (класс) "многострочные документы", например. В нем имеются атрибуты, объявленные хранимыми. От него унаследовали классы "счета", "накладные" и "счета-фактуры". Далее насоздавали по тысяче объектов каждого из этих классов. Потом спохватились - а давайте добавим системное поле "Автор документа" в родительский класс "многострочные документы", причем потребуем обязательности его заполнения. Оно (это поле) автоматически появится у прежде созданных объектов счетов, накладных и счетов-фактур? Можно расписать подробнее, как Вы себе представляете модификацию типа ПОСЛЕ того как созданы хранимые объекты унаследованных классов?

U-gene
Опять же - Вы так и не обяснили, какое отношение транзакции имеют к вопросу поднимаемому в НРМ. Что же касается конкретно вашего пример, то в НРМ он решается просто. Создание объекта типа "накладная" подразумевает, в частности, то, что в используемой РСУБД возникает кортеж, соответсвующий заголовку. Для этого пользователю никаких ограничения целостности не надо определять вообще. Система за него это делает.
Я пытаюс показать, что ПОСЛЕДОВАТЕЛЬНОСТЬ выполнения операций имеет может иметь значение. DRI с каскадными операциями в РСУБД могут быть настроены таким образом, чтобы при удалении заголовка накладной автоматически удалялись также и объекты многострочной части (позиции накладной). При этом НЕВОЗМОЖНО создать запись многострочной части, не создав предварительно запись заголовка накладной. В Вашем случае строка многострочного документа является самостоятельным объектом. И, значит, если я правильно понял, эти объекты могут существовать ВНЕ ЗАВИСИМОСТИ от существования объекта накладной, что может вызвать проблемы логической целостности.
Еще один пример. Заголовок накладной ссылается на объекты "покупатель" и "продавец". Что произойдет с объектом "накладная", если попытаться грохнуть продавца, на который ссылается данный объект? Причем, "продавец" - это НЕ часть объекта "накладная" - это именно самостоятельный объект. Поскольку на него аналогичным образом ссылается еще множество других объектов. Ошибка? Ок. А теперь вернемся к проблеме. В ТРАНЗАКЦИИ сначала грохается продавец, на которого имеются ссылки из накладных, а потом уже эти ссылки в накладных переустанавливаются на ДРУГОГО ПРОДАВЦА. После выполнения всей СОВОКУПНОСТИ действий, определяемых транзакцией, должно возникнуть непротиворечивое состояние данных. Но имеется ПРОМЕЖУТОЧНОЕ ИХ СОСТОЯНИЕ, в котором они на некоторое время окажутся противоречивыми. Устранение промежуточных противоречивых состояний НЕ ВСЕГДА возможно одним только механизмом транзакций. Нужны еще механизмы управления моментами запуска проверки непротиворечивости. Один из подобных механизмов реализован в Cache. Запуск непротиворечивости данных запускается при попытке СОХРАНЕНИЯ всей совокупности информации об объекте. Сама же модификация совокупности информации об объекте может происходить целой серией операций, приводящих к появлению временно-противоречивых состояний объекта, которые игнорируются, поскольку Cache четко отделяет реально хранимый объект в БД от его копии, подгруженной в сессии, с которой оперирует разработанная программистом логика. Я не наставиваю на том, что именно такой механизм должен быть во всех случаях. Но какой-то нужен. Иначе, повторяю, работать с информацией, реализующей принципы рассматриваемого манифеста сможет только один пользователь.

U-gene, прошу меня извинить, если мои высказывания показались Вам слишком настойчивыми. Я лишь пытаюсь найти ответы на вопросы, которые у меня возникают. Возможно, я черезмерно ориентирован на практику, и поэтому не могу воспринять достаточно абстрактно озвученные в манифесте положения. У меня нет намерения как-либо принизить Вашу работу. Я считал и продолжаю считать ее достойной изучения. Надеюсь, Вы не станете воспринимать меня Вашим противником. :)
7 сен 05, 13:17    [1854444]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
ModelR
Member

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

Определение объектного типа GoodsMotion можно также рассматривать как объявление R-переменной компонента типа GoodsMotion.MovedItems со схемой (OID, Article, Quantity).

то откуда No:
U-gene

есть переменная с именем GoodsMotion.MovedItems содержащая скалярный атрибут No
7 сен 05, 14:35    [1854964]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

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

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

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

Определяемся. Был тип (класс) "многострочные документы", например. В нем имеются атрибуты, объявленные хранимыми. От него унаследовали классы "счета", "накладные" и "счета-фактуры". Далее насоздавали по тысяче объектов каждого из этих классов. Потом спохватились - а давайте добавим системное поле "Автор документа" в родительский класс "многострочные документы", причем потребуем обязательности его заполнения. Оно (это поле) автоматически появится у прежде созданных объектов счетов, накладных и счетов-фактур?...
Да.
Можно расписать подробнее, как Вы себе представляете модификацию типа ПОСЛЕ того как созданы хранимые объекты унаследованных классов?
Мммм.... а давайте мы пока с системой типов разберемся?... Без этого не понять соотношения между объектами к отношениями, а как мы это станет понятно, так, глядишь, и вопрос проясняться начнет....

Я не наставиваю на том, что именно такой механизм должен быть во всех случаях. Но какой-то нужен.
Экий Вы настырный.....:).....
1)Еще раз повоторяю, что данная проблема не является проблемой которую пытается решить НРМ.
2)Допускаю, что такие механизмы нужны. Хотя не один из Ваших примеров меня, честно гря, не убедил. Например, зачем сначала стирать продавца, а потом переставлять ссылки? Во-первых, можно сделать наоборот и проблемы не станет. Во вторых в R*O-системе предложенный вами вариант вообще не проканает, поскольку система осуществляет контроль целостности ссылок (стр34) и там всяк проидется сначала перназначит, а потом стирать.
3) Еще раз повторю, что видимо, такие механизмы нужны. И хотя это и не имеет отношение к НРМ, но в голове бродит мысль рассматривать любой метод как атомарную операцию, внутри котрого возможны изменения, но в результате должно возникнуть непротиворечивое состояние.
Иначе, повторяю, работать с информацией, реализующей принципы рассматриваемого манифеста сможет только один пользователь
А можно привести пример такой ситуации? Я честно, пока что таковую не вижу. Только в деталях: пользователь собрался каким то образом поработаь с объктом. Что он делает(по операциям), как в результате он всех остальных блокирует. Только чур!...надо бы поближе ознакомившись с предложенным подходом, дабы конфузов, как с "строка многострочного документа является самостоятельным объектом" не вышло. :)
7 сен 05, 14:41    [1854998]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 ModelR Моя себя сама здесь не понимай. Ошипси. Гранд сорри. Исходную фразу здесь надо читать, конечно, как

...В частности, есть переменная с именем GoodsMotion.MovedItems содержащая скалярный атрибут Article и также, есть переременная с именем GoodsMotion содержащая скаляряный же атрибут MovedItems.Article. То есть в последнем слуучае выражение MovedItems.Article - это всего лишь сложное имя скалярного атрибута. Если Вы воспринимаете здесь что-то, как какую-то сложную структуру, то слава богу - я именно этого и добивался. Но с формалной точки зрения, с точки зрения РМД MovedItems.Article - это просто имя, ...
7 сен 05, 14:46    [1855023]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 5 6 7 8 9 [10] 11 12 13 14   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить