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

Откуда: Нижний Новгород
Сообщений: 1798
2Garya
автор
Пример. Имеется отношение (в просторечии - таблица), кортежи которого содержат в одном из полей ЗНАЧЕНИЕ, являющееся множеством. Всего в отношении 10000 записей, 4000 из которых содержат в данном поле ЗНАЧЕНИЕ {1; 5; 8; 9}, остальные 6000 содержат ЗНАЧЕНИЕ {2; 4; 7}. Если эти ЗНАЧЕНИЯ сохранять непосредственно в таблице, соответствующей отношению (например, в виде совокупности полей [Элемент1], [Элемент2], [Элемент3] и т.д.), то мы получим яркий пример нарушения 3NF
Нет. В свете текущих представлений тип значения может быть сколь угодно сложным, было бы определено равенство. Т.е. если мы умеем определить {1; 5; 8; 9} = / != {2; 4; 7} то можем рассматривать эти значения как атомарные с точки зрения 1NF. Причем тут 3NF непонятно, пока не определены ФЗ. В ФЗ соответствующий атрибут будет участвовать как атомарный и его внутренняя структура нарушить 3NF не может.
автор
Если их сохранять упакованными в varbinary, например, мы получим неоптимальность хранения и требования выполнять операции распаковки над каждой записью (выполнять Full Scan таблицы) при фильтрации кортежей по условиям, в которых фигурируют элементы данного множества. Наиболее очевидный способ нормализовать данные - создать вспомогательную таблицу, в которую поместить два набора записей, идентифицируемых по коду набора:
Номер набора Значение
1 1
1 5
1 9
2 2
2 4
2 7
, а в основной таблице ссылаться на номер набора.
Оптимальнось хранения зависит от приложения. Конечно, когда приложению нужен доступ к <1 8> и <2 4> то так лучше. Если приложение обрабатывет только множества целиком, то в чем проблема - БД и хранит их как атомарные значения.
7 сен 05, 15:02    [1855113]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Garya
Member

Откуда: Москва
Сообщений: 33226
Блог
U-gene
Хотя не один из Ваших примеров меня, честно гря, не убедил. Например, зачем сначала стирать продавца, а потом переставлять ссылки? Во-первых, можно сделать наоборот и проблемы не станет. Во вторых в R*O-системе предложенный вами вариант вообще не проканает, поскольку система осуществляет контроль целостности ссылок (стр34) и там всяк проидется сначала перназначит, а потом стирать.
Я стараюсь приводить относительно простые примеры, из которых дейсвтительно можно выкрутиться по большей части, хотя и не из всех. Посмотрите, еще раз вот этот пример и сообщите пожалуйста, как ОДНОЙ операцией присвоения значения свойствам объекта можно одновременно изменить значения нескольких атрибутов. А реальная жизнь гораздо сложнее и многограннее. В этой реальной жизни может понадобиться вносить изменения не только в несколько атрибутов ОДНОГО объекта, но и в несколько атрибутов нескольких взаимосвязанных объектов. И вероятность столкнуться с противоречивыми промежуточными состояниями данных, не преодолимых простой перестановкой последовательности выполнения операций внутри одной транзакции, становится все более возможной.
Немаловажен тот факт, что противоречивые состояния данных могут возникать даже при работе ОДНОГО пользователя. Если одни и те же "переменные отношения" доступны нескольким сеансам, и каждый из них творит с этими переменными что-то свое, при этом изменения атрибутов одним из сеансов этих объектов влияют СРАЗУ на все сеансы, вероятность столкнуться с противоречивыми данными резко возрастает даже на тех операциях, которые при однопользовательском доступе однозначно не приводят ни к каким конфликтам.

U-gene
в голове бродит мысль рассматривать любой метод как атомарную операцию, внутри котрого возможны изменения, но в результате должно возникнуть непротиворечивое состояние
И где же происходит обработка ошибок, если противоречивость выявляется, когда метод уже отработал?

U-gene
А можно привести пример такой ситуации? Я честно, пока что таковую не вижу. Только в деталях: пользователь собрался каким то образом поработаь с объктом.
Выше я уже приводил подобный пример про пальцы, кольца и микробов. Всё очень просто. В одном сеансе прежде чем выполнить какие-то действия над данными проверяется их значение и принимается решение, что содержимое данных требует их обработки одним способом №1. После выполнения этой проверки, но еще до запуска самой обработки в другом сеансе изменяется содержимое уже проверенных данных, в результате чего бизнес-логика требует, чтобы они изменялись способом №2. Но поскольку первый сеанс "ничего не знает" о том, что данные только что изменились, он их обрабатывает Способом №1, прводя в противоречивое состояние.

ModelR
2Garya
автор
Пример. Имеется отношение (в просторечии - таблица), кортежи которого содержат в одном из полей ЗНАЧЕНИЕ, являющееся множеством. Всего в отношении 10000 записей, 4000 из которых содержат в данном поле ЗНАЧЕНИЕ {1; 5; 8; 9}, остальные 6000 содержат ЗНАЧЕНИЕ {2; 4; 7}. Если эти ЗНАЧЕНИЯ сохранять непосредственно в таблице, соответствующей отношению (например, в виде совокупности полей [Элемент1], [Элемент2], [Элемент3] и т.д.), то мы получим яркий пример нарушения 3NF
Нет. В свете текущих представлений тип значения может быть сколь угодно сложным, было бы определено равенство. Т.е. если мы умеем определить {1; 5; 8; 9} = / != {2; 4; 7} то можем рассматривать эти значения как атомарные с точки зрения 1NF.
Рассматривать-то мы можем их как атомарные - теоретически. Но при этом каждый элемент атома-множества в свою очередь может быть атомом-множеством, в которое тоже могут быть тоже вложены атомы-множества и т.д. И при детальном рассмотрении можно прийти к выводу, что вообще вся многогигабайтная база данных с тысячами таблиц может быть представлена в виде атомарного значения (почти что скалярного - такого большого-большого космического числа). Нет никаких отношений и кортежей - одно лишь атомарное значение. И тогда не нарушаются требования никаких нормальных форм, пусть даже внутри этой базы сидит данных одна-единственная таблица, в которой описаны вперемешку содержимое документов, справочников, кулинарных рецептов и записок охотника. Только кому это атомарное значение нужно, если внутрь этого атома забраться и рассматривать отдельные кварки никто не собирается? Если мы рассматриваем элемент именно как МНОЖЕСТВО, а не как атомарное значение, значит это где-то и для чего-то нужно. Значит, где-то кто-то когда-то собирается выделять отдельные элементы этого множества и производить с ними какие-то операции.
7 сен 05, 18:15    [1856413]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

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

Еще раз повторяю, что сабж не рассматривает эти вопросы. Если Вам кажется, что один пользователь заблкирует всех остальных - я не готов ошибочность этого Вашего личного мнения доказывать. А на уровне разговоров о сложности жизни мне общаться не хочется. Могу лишь заметить, что все поднимеамые вами вопрсоы ИМХО так или иначе касаются любых многопользовательских систем (я в примере об ампутированных пальцах эт уже говорил), и в этих системах они каким то образом решаются. Например, на ваш пассаж
...В этой реальной жизни может понадобиться вносить изменения не только в несколько атрибутов ОДНОГО объекта, но и в несколько атрибутов нескольких взаимосвязанных объектов...
....я могу ответить пассажем о табличных СУБД со многими вложенными триггерами, когда изменеие одной записи может повлечь изменение состояния многих таблиц. И что? Теперь в таких системах работать невозможно? Если в предложении "Если одни и те же переменные отношения доступны нескольким сеансам, и каждый из них творит ...и.т.д..." я заменю "переменные отношения" на "таблицы", а "творит" на "вызывает хранимые процедуры" - от этого что-то в его смысле измениться? ИМХО абсолютно нет. Поэтому все эти сеансы, пальца, кольца и микробы - они к теме "объекты*отношения" отношения ИМХО не имеют отношения вообще. Формально же могу сказать, что в НРМ слово "многопользовательская система" не разу не употребляется. В связи с этим тот ваш изначальный вопрос "А где же разбор конфликтов одновременного доступа к данным?" он в общем то о том, что как бы и не декларируется(точно так же как нет ничего о производительности). Увы мне....:) Это, конечно, очень большая и важная тема, но я не готов, поэтому проблемы, связанные с многопользовательским доступом, обсуждать не хочу.
7 сен 05, 19:20    [1856611]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Garya
Member

Откуда: Москва
Сообщений: 33226
Блог
U-gene
Еще раз повторяю, что сабж не рассматривает эти вопросы.
Понятно. Это мой последний пост по теме, больше испытывать Ваше терпение я не буду.

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

U-gene
Формально же могу сказать, что в НРМ слово "многопользовательская система" не разу не употребляется. В связи с этим тот ваш изначальный вопрос "А где же разбор конфликтов одновременного доступа к данным?" он в общем то о том, что как бы и не декларируется(точно так же как нет ничего о производительности). Увы мне....:) Это, конечно, очень большая и важная тема, но я не готов, поэтому проблемы, связанные с многопользовательским доступом, обсуждать не хочу.
Я уже все понял... :) Есть у меня дурацкая привычка при виде формулы параболы сразу примерять ее к траектории полета снаряда, выискивать в ней учет сопротивления воздуха, изменения его плотности в зависимости от высоты, изменения g в зависимости от высоты, а также влияние луны и звезд на небе. А это всего лишь формула параболы... :) Больше не буду беспокоить.
7 сен 05, 19:56    [1856676]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
tchingiz
Member

Откуда:
Сообщений: 39057
Гаря
процессы, которые мы потеряли
http://www.softcraft.ru/paradigm/process/pr01.shtml
8 сен 05, 02:00    [1857035]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Garya
Member

Откуда: Москва
Сообщений: 33226
Блог
2 tchingiz. Спасибо. Прочитал. Классная статья!
8 сен 05, 13:09    [1858661]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Garya
ModelR
Нет. В свете текущих представлений тип значения может быть сколь угодно сложным, было бы определено равенство. Т.е. если мы умеем определить {1; 5; 8; 9} = / != {2; 4; 7} то можем рассматривать эти значения как атомарные с точки зрения 1NF.
Рассматривать-то мы можем их как атомарные - теоретически. Но при этом каждый элемент атома-множества в свою очередь может быть атомом-множеством, в которое тоже могут быть тоже вложены атомы-множества и т.д. И при детальном рассмотрении можно прийти к выводу, что вообще вся многогигабайтная база данных с тысячами таблиц может быть представлена в виде атомарного значения (почти что скалярного - такого большого-большого космического числа). Нет никаких отношений и кортежей - одно лишь атомарное значение. И тогда не нарушаются требования никаких нормальных форм, пусть даже внутри этой базы сидит данных одна-единственная таблица, в которой описаны вперемешку содержимое документов, справочников, кулинарных рецептов и записок охотника.
Да
Garya

Только кому это атомарное значение нужно, если внутрь этого атома забраться и рассматривать отдельные кварки никто не собирается?
Да, конечно собирается. Просто не обязательно средствами данной БД
Garya

Если мы рассматриваем элемент именно как МНОЖЕСТВО, а не как атомарное значение, значит это где-то и для чего-то нужно. Значит, где-то кто-то когда-то собирается выделять отдельные элементы этого множества и производить с ними какие-то операции.
Весь вопрос именно про границу - "где-то" - это где? Если в нашей системе нужны транзакции, изменяющие часть этого атома в то время как другие транзакции независимо меняют другую часть этого атома - наши проблемы, вникаем и моделируем. Если атом считывается, блокируется и возвращается только целиком, то зачем мне его структура? Без всякого нарушения нормализации можно и JPEG промоделировать реляционными таблицами, и весь дамп некоторой базы хранить одним полем.
9 сен 05, 12:19    [1862588]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
tchingiz
Гаря
процессы, которые мы потеряли
http://www.softcraft.ru/paradigm/process/pr01.shtml


Статья великолепная. Если добавить по треду к каждому объекту, получим процесс. Поместить что получилось в БД получим, уже даже говорить страшно ... скажу другими словами - СНС )))
9 сен 05, 14:00    [1863330]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
nkulikov
Guest
Не могу сказать что статья супер, могу предположить, что автор со Smalltalk не работал, хотя его упоминает... Многие из его идей там есть начинаяя с 1980 года...
9 сен 05, 14:45    [1863658]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
2 nkulikov
В САБЖе нет smalltalk'а!!!
9 сен 05, 15:13    [1863849]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
nkulikov
Guest
В Subj нет процессов тоже....
9 сен 05, 15:47    [1864025]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
А мы здесь тогда о чем?...тем более что "В Subj нет процессов тоже...."...
9 сен 05, 15:51    [1864053]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Garya
Member

Откуда: Москва
Сообщений: 33226
Блог
shuklin
Поместить что получилось в БД получим, уже даже говорить страшно ... скажу другими словами - СНС )))
Да, эта концепция перекликается с отслеживаем состяния хранимой в БД информации по двум осям времен, предложенная мной. Но это тема отдельного разговора, не хочу прогневать еще и модератора... :)
9 сен 05, 16:17    [1864188]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Garya
Member

Откуда: Москва
Сообщений: 33226
Блог
Кстати, некоторые участники разговора уже запутались - о чем вообще идет речь... :) Наверное, пора вернуть разговор к его истокам.
9 сен 05, 16:19    [1864198]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Garya
shuklin
Поместить что получилось в БД получим, уже даже говорить страшно ... скажу другими словами - СНС )))
Да, эта концепция перекликается с отслеживаем состяния хранимой в БД информации по двум осям времен, предложенная мной. Но это тема отдельного разговора, не хочу прогневать еще и модератора... :)


Где прочитать?
9 сен 05, 16:38    [1864292]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
Garya
Member

Откуда: Москва
Сообщений: 33226
Блог
shuklin
Где прочитать?
Вкратце я говорил в этом треде (см. абзац, начинающийся словами "Про R-переменные типа / компонентов типа - идея понравилась"). А также на своем "родном" форуме :) обмолвился, начиная отсюда.

Сейчас модератор мне точно по шее накостыляет. Если есть вопросы или замечания по МОЕЙ концепции, прошу их больше не втыкать в текущий тред. Можете открыть новую ветку (наверное, правильнее всего это сделать на форуме "Разработка информационных систем", или "Проектирование БД"). Только просигнальте мне на мыло, а то я не во все форумы регулярно заглядываю (мыло см. в разделе "Работа" моего профиля).
9 сен 05, 17:40    [1864641]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Garya
Можете открыть новую ветку (наверное, правильнее всего это

Рискнул ответить здесь
Cerebrum : Сетевая объектно-ориентированная система управления базой знаний
9 сен 05, 18:46    [1864942]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
U-gene
Member

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

Ну ты понаписал.

Я продолжаю исходить из предпосылки, что ты делаешь попытку создать
формальную систему.
Да я уже и сам не знаю….:) В предверсии наверное, а сейчас может быть наверное уже и нет. Скорее это попытка объяснить идею более–менее понятно, оставаясь при этом по возможности в каких то формальных рамках.

2. понятия
В третьем манифесте я не нашел (использовал в ворде ctrl+F) сочетание
"переменная отношения" и "значение отношения".
Я аж испугался. :) Пришлось консолидировать источники. Таки есть. Например в "Основы будущих баз данных. Третий манифест"(Москва Янус-К 2004) есть на 42й стр. Они должны явно различаться. Что же касается отношений как констант (то есть значений), то если не утрировано то отношение – это, конечно не описание и не схема, а просто тип. В этом случае значение оношения складываются их двух частей заголовок(схема) и тело. Соответсвенно могут быть разные значения, имеющие одинаковый заголовок(это разные отношения). Или разные значения, имеющие разные заголовки(тем более разные отношения). Но в любом случае (даже в последнем) – тип один и тот же. Я же постоянно использую термин значение отношения(хоть это и масло масленное) только для того что бы подчеркнуть, что это таки значение.

С другой стороны тип отношение ИМХО можно рассматривать и как метатип (тип типов). Метатип соотностися с типом так же, как тип соотноситься со значением. Из этого в частности следует, что, конструируя тип некого метатипа, мы в этом конструкторе можем использовать другой тип как аргумент. Тогда конструкция RelVar AS SET OF TupleType объявляет существование переменной типа, относящегося к метатипу "отношение", для которой в качестве типа аргумента-заголовка определен кортежный тип TupleType. Соответсвенно, например, операция проекции, определённая без сомнения для метатипа "отношение", манипулирует и телом (значением… данными) и заголовком (типом-аргументом…. метаданными). В результате получается новое значение с новым типом аргументом (то есть с новой схемой)

2.2. кортежи (tuples)
множестве ВСЕХ ЦЕЛЫХ ЧИСЕЛ, который говорит входит ли данное целое в тип
(множество ) short. Тип отношения имярек - множество всех отношений (множество
множеств) для которых выполняется некоторый предикат. Должен существовать
предикат, заданный на множестве ВСЕХ ОТНОШЕНИЙ, который говорит, входит ли
данное отношение в тип имярек. Этот предикат можно называть спецификацией
отношения.
В частности спецификация отношения может задавать названия атрибутов,
домены атрибутов, задавать предикат table-constraint
table-constraint :
[ CONSTRAINT constraint-name ] {
UNIQUE ( column-name, ... )
| PRIMARY KEY [ CLUSTERED ] ( column-name, ... )
| CHECK ( condition )
| foreign-key-constraint
}
ИМХО не нужно валить все в одну кучу. Например отношения, совместимые по схеме, могут иметь абсолютно разные CHECK'и. Я это объяснял в 1740981.

3. основное требование HРМ
1) обьекты - лишь дань сиюминутной (по сравнению с математикой) моде. Не
факт, что им будет уделяться такое же внимание через 10-20 лет.
2) понятие не слишком формализованное.
В основном требовании таки говориться "объекты предметной области. Я могe написать и "сущности предметной области" – от этого ИМХО ничего не измениться. Я явно оговариваюсь, что это не объекты языка или системы. А вот эти объекты я далее и стараюсь… ну не то, что бы формализовать, но хотя бы описать так, что бы формализация не составила труда.

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

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

То есть, понятие процесса - более общее. Раз есть претензия на описание
ЛЮБОЙ ПРЕДМЕТНОЙ области, то подразумевается, что R*O система должна описывать
предметную область сплошь состоящую из процессов.
Не знаю… ИМХО понятие процесса может быть и хорошее…. но забытое…. Опять же ну назову я это "процесс" так все равно от этого ничего не измениться. :) опять же с объектыкак то более ассоциипуются у народа со всякими наследованиями и полиморфизмами,о чем речь в НРМ идет. А вот состояние (изменчивое или неизменчивое) это в нем не есть главное.

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


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


4. Данные R*0 системы
4.1. Различимые значения
"Различимые значения" это че такое?
Ну…:)…эта….. Да. :) Уберу….

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

Однако пассажи о различимости убирать не буду – ИМХО это основное различие между объектными и значимыми типами, так что пусть уж плещется…

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

А вот здесь я не хочу идти за тем, что должно быть потому что оно так есть. Хотя бы потому, что в ОО прогамировании все типы – классы (суть объектные типы), а в НРМ – нет. Считай, что я эти "самые абстрактные типы" сразу же разведены на две группы. Экземляры одной сравниваются по значению а другой –по идентификатору. А в остальном я же не запрещаю эти отношения эквивалентности каким то образом задавать…. Опять же я не запрещаю пользовтелю определять любые свои опреции…Ведь могут объекты быть одинаковыми по объему, по массе, по фамилии… это же тоже отношения эквивалентности? Ну пусть он так и пишет…Или можно считать,что есть операции сравнения "=" и "==". Одна из них как определил пользоваетль, а вторая этакое абсолютное сравнение, по одному из двух предложенных вариантов. На самом длеле в конце концов все сводится к сравнению значимых типов, потому как когда мы пишем объект1 == объект2 мы сравниваем значение ссылочных перменных, то есть значение перменных значимого типа ( для них .... прямое и полное).

это запомнить невозможно. кроме того, что такое "ТИПЫ МНОЖЕСТВ"?
Да поллитра требуется. :) Что если так?
3)Конструируемый тип отношения. Значение этого типа представляют собой множество кортежей заданного кортежного типа. Соответственно этому определяется и переменная типа отношения (имя_переменной AS SET OF имя_кортежного_типа).
11 сен 05, 23:27    [1867007]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
tchingiz
Member

Откуда:
Сообщений: 39057
я воспринимаю слово тип как синоним слова множество значений.


то если не утрировано то отношение – это, конечно не описание и не схема, а просто тип. В этом случае значение оношения складываются их двух частей заголовок(схема) и тело. Соответсвенно могут быть разные значения, имеющие одинаковый заголовок(это разные отношения)



1
"разные значения, имеющие одинаковый заголовок == синоним разные отношения".
в этом предложении значение отношения эквивалентно отношению.

2
"то отношение - просто тип".
в этом предложении отношение это просто множество значений.
тогда "значение отношения" это константа (одна из типа), а отношение - это множество различных "значений отношения"

--
фразу номер 2 "отношение - это просто тип" -- я склонен расценивать как ошибочную.
то есть считать выражение "значение отношения" и "отношение" синонимами.


переменная отношения - отличается от отношения тем, что для переменной должна быть задана операция присвоения (например ее можно обозначить символом :=).
то есть если r1, r - отношения, а v - переменная отношения, то
в формальной системе (например, в R*O)
можно записать выражение
v := r
и нельзя записать выражение
r1 := r
-----
тогда эти термины оказываются согласованными с более общими терминами
переменная и значение.

а других отличий между переменной и значением не вижу.
Соответсвенно, длинные обсуждение разницы, вроде как у Дейта считаю бессмысленными.
12 сен 05, 07:07    [1867133]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
tchingiz
Member

Откуда:
Сообщений: 39057
опять имхо везде. )))))))

предложение по трактовке типов.

в самом общем виде - тип X задается как множество значений
(далее для формального описание использую синтаксис RSL)

type
   Integer = {| x: Int :- x <=32000 /\ x >= -32000 |}
   , Nat  = {| x: Integer :- x > 0 |}
variable
   i : Integer
   ,n : Nat

читается как в математике

Integer - множество значений из предопределнного
типа Int, для которого выполняется следующий предиткат - любое значение больше
равно -32000 и меньше равно 32000.
Nat - множество значений из типа Integer, которые больше 0.
Задал два новых типа - обьявил две новых переменных.


Почему для кортежей и отношений надо делать исключение?

  // пример с кортежами SaleQty
 type
   INTEGER, FLOAT, Article,
   SaleQty ::                                  // множество всех троек, кажда
                    Art : Acrticle             //
                    Quontity: INTEGER    // 
                     Price : FLOAT           //
   ,
   SaleQty1 = {| x : SaleQty1 :-   Quontity(x) > 0 /\      //          XXX 
                                               Price(x) > 0.0  /\ 
                                                Art(x) isin    RealActicle |}
 value 
   RealArticle : Article-set 

задал скалярные типы INTEGER, FLOAT, Article,
задал тип SaleQty - который удовлетворяет определению кортежного типа
и он действительно означает множество всех троек,
первая компонента которых (читай атрибут) принадлежит множеству Art, вторая принадлежит множеству целых чисел INTEGER, третья принадлежит FLOAT

задал тип SaleQty1 - выбрал из SaleQty только те кортежи, которые удовлетворяют
предикату - Qountity больше 0, Price больше 0, Art принадлежит некоторому еще
неопредленному множеству RealArt.

Тип отношение TRel из кортежей задается и переменная задается очевидным образом
   type 
       TX   = SaleQty-set
       ,TX1 = SaleQty1-set
   variable 
       table: TX
       table1: TX1 

TX это множество всех кортежей типа SaleQty,
TX1 это множество всех кортежей типа SaleQty1 (то есть для которых выполняется предикат XXX).
Задал переменные отношения table и table1.

что скалярные, что кортежи, что отношения, что чтото более сложное.
все записывается и понимается однообразно, а значит понятно.
12 сен 05, 07:45    [1867159]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
tchingiz
Member

Откуда:
Сообщений: 39057
[quot]
ИМХО не нужно валить все в одну кучу. Например отношения, совместимые по схеме, могут иметь абсолютно разные CHECK'и. Я это объяснял в 1740981.
[/qout]

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

2
в свете вышеизложенной трактовки терминов
фраза "отношения могут иметь абсолютно разные check" -
бессмысленна. Отношения чеков (предикатов) не имеют.
Кортежи отношения могут удовлетворять предикату. Чеки (предикаты) имеет задание типа отношения. занание типа -- синоним -- определение (спецификация, схема) отношения .




3



фразу "Почему для кортежей и отношений надо делать исключение"? надо читать как

"я не допонимаю, почему для кортежеи и отношений надо делать какие либо специальные оговорки вообще"?

формально твою фразу

3)Конструируемый тип отношения. Значение этого типа представляют собой множество кортежей заданного кортежного типа. Соответственно этому определяется и переменная типа отношения (имя_переменной AS SET OF имя_кортежного_типа).

я бы читал как (слово конструируемый - лишнее)
тип отношения TX.
значения типа TX представляют собой отношение R принадлежаее множеству TX.
Тоесть ничем не отличается от "значения типа Nat представляют собой константы принадлежащие множеству Nat"
---
пример (я убрал заголовок кортежа и отношения, чтобы меньше писать. )

TX = {{(1,2), (3,4)}, {(44,5),(2,3),(7,6)}}
тогда переменная x: TX, может принимать значение

либо {(1,2), (3,4)}
либо {(44,5),(2,3),(7,6)}
можно написать

x := {(1,2), (3,4)}

или
x := {(44,5),(2,3),(7,6)}
и нельзя
x := {(55,3),(7,6)}
----------------------------

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

TX1 = {{(1,2), (3,4)}, {(44,5),(2,3),(7,6)} , {(1,2,3), (3,4,5)}}
тогда в
переменную
x1 : TX1
можно будет присваивать {(1,2,3), (3,4,5)}.
12 сен 05, 08:20    [1867181]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
tchingiz
Member

Откуда:
Сообщений: 39057
Ведь могут объекты быть одинаковыми по объему, по массе, по фамилии… это же тоже отношения эквивалентности?

пусть задано множество X.
подмножество R из X >< X, назвается отношением
эквивалентности тогда и только тогда
когда для каждого x isin X, y isin X, z isin X
выполняются условия
1
рефлексивности: xRx -истинна ( xRx означает (x,x) isin R)

2
симметричности xRy истина тогда и только тогда когда yRx

3
транзитивности xRy /\ yRz влечет xRz.

тоесть отношений эквивалетности можно задать много.
12 сен 05, 08:29    [1867189]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
tchingiz
Member

Откуда:
Сообщений: 39057

С другой стороны тип отношение ИМХО можно рассматривать и как метатип (тип типов). Метатип соотностися с типом так же, как тип соотноситься со значением. Из этого в частности следует, что, конструируя тип некого метатипа, мы в этом конструкторе можем использовать другой тип как аргумент. Тогда конструкция RelVar AS SET OF TupleType объявляет существование переменной типа, относящегося к метатипу "отношение", для которой в качестве типа аргумента-заголовка определен кортежный тип TupleType.

рассуждения про метатип не понял.

пример с конструкцией понял

RelVar AS SET OF TupleType в любимом rsl
записывается как
  type 
    TupleType // както определено множество кортежей
  variable
    RelVar :  TupleType-set  
                // множество  всех конечных множеств, состоящих из кортежей TupleType
   ,RelVar1 : TupleType-infset 
                // множество всех  множества (и бесконечных тоже), состоящих из кортежей
а можно из них список задать
  variable
    RelVar :  TupleType-list  
                    // множество всех конечных списков, состоящие из кортежей 

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

Откуда: Москва. Россия
Сообщений: 1576
Эта... с тобой острожнее надо быть....
За слова отвечу:) . Конечно в фразе
"отношение – это, конечно не описание и не схема, а просто тип" имелось виду:тип отношения - это прото тип.

Далее о фразе "отношения могут иметь абсолютно разные check". Здесь подразумевалось, что check должен быть связан не с отношением и не с типом, а с переменной отношения. ИМХО тот факт, что чеки связаны с переменными делает систему гибче. Во всяком случае мы их можем например преопределить при наследовании, а если их ввести в определение отношения, то получилось бы что компоненты использюующие это определение так преопределить не смог бы.

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

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

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

рассуждения про метатип не понял.
Это я из замулина взял.... Не знаю насколько правильно :)
Вот смотри. Создавая объект класса а ты можешь использовать в консруктре некое значение в общем то любого типа, например целочисленное.
a := new A(integervalue).
Здесь А обновременно и имя типа и конструктор.

И сэто точки зрения сам описание класса А тоже можно рассматривать как
A СLASS
{ attr_a int;}
в общем то абсолютно аналогично.тоже можно рассмтаивать аналонично. CLASS здесь конструктор класса использующия другой тип. И это метатип - то есть "тип типов", опредлделяющий некие своства, общие для своих типов и, соответственно, для их значений. Например, свойство "у любых объектов любых классов есть ID" можно рассмаотривать как свойство, определяемое метатипом CLASS. МНо ведь можно предположить, что в системе может существовать другой метатип, и у его типов будут другие свойства. Например у его экземпляров такой уникальный ID отсутсвует.
12 сен 05, 12:22    [1868154]     Ответить | Цитировать Сообщить модератору
 Re: НРМ  [new]
tchingiz
Member

Откуда:
Сообщений: 39057
мне этот замулин жутко не нравится пока.
следующее что не нравится это его понимание спецификации обьекта.
бредовое какоето. я это еще читаю.

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

//все что бесполезно - вредно

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

пысы
читаю дальше
.
13 сен 05, 01:24    [1870658]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 5 6 7 8 9 10 [11] 12 13 14   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить