Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 12 13 14 15 16 [17] 18 19 20 21 .. 31   вперед  Ctrl
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
ModelR
Александр Савинов
Вот вам версия в SQL-подобном синтаксисе:
SELECT e.FIO, SUM( e.{Menu.dinnerid.emplID}.<count * dishid.cost> )
FROM Employee e 
WHERE COUNT( e.{Menu.dinnerid.emplID} ) > 100 
  AND dishdate > '01.02.2006' 
  AND name = 'Борщ' 

Ура!!! Я выиграл!! Моя версия короче!
Но алфавит длинннее: {}, <>

Согласен, я сам не люблю всякую криптографию типа &, *, %, {}, <>. Да и вообще данный пример ничего не показывает. Но раз был вопрос, надо как-то ответить. Дело в том, что в обоих версиях есть множество предположений. Например, в SQL:

- использование INNER JOIN, который является приспособой и предполагает особое именование ключей, а также ряд ограничений, например, невозможность ссылаться два раза на одну таблицу (проще говоря, в общем случае это не работает).

- уникальные имена колонок в разных таблицах, а в общем случае, name может встречаться во всех таблицах.

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

Поскольку в обоих случаях был не общий случай, но сравнение некорректно.

В общем, теоретически мой вариант мне больше нравится, но практически я бы использовал SQL. Но оба варианта достаточно кривые и на них видно, как все запущено в этой области.
13 дек 06, 15:31    [3531096]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
shuklin
!

Пожалуйтста, расскажите еще раз, для тех кто в танке,
про алгоритм проверки идентичности и равенства?

Надоело. Те кто в танке идут читать документацию C# про отличие value type от reference type


Ну я читал документацию (и немножка Рихтера)
value размещаются на стеке reference в управляемой куче.
Дык как это поможет от закольцованных сцылак та ???

Ни[censored] слив ни засчитан
13 дек 06, 15:40    [3531179]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
U-gene
mir
Что в предложении SELECT означают выражения count и dishid.cost? Для них нет никакого способа быть вычисленными из таблицы


Я бы не стал так с плеча. :)

Скажите, Александр Савинов, а у Вас в "FROM Employee e" это самое Employee - это отоношение (как определяет РМД)?

Я таких предположений не делал и запрос (при определенной поддержке) д.б. верен в РМД. По крайней мере его можно более или менее легко транслировать в обычный SQL. Хотя я допускаю, что при этом могут быть нарушены какие-то теологические постулаты РМД. Единственное существенное, что использовалось, так это то, что таблицы упорядочены, т.е. порядок между таблицами важен. Без него восстановить связи (осмысленно) нельзя.
13 дек 06, 16:04    [3531405]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Gluk (Kazan)
Дык как это поможет от закольцованных сцылак та ???

А причем к этому вообще закольцованные ссылки? Мы тут про идентификацию рефернс тайпов говорим.

PS. Про закольцованные ссылки у того же рихтера.
13 дек 06, 16:15    [3531502]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Александр Савинов
Но оба варианта достаточно кривые и на них видно, как все запущено в этой области.
Я на практике хотел бы в стандартном SQL иметь операцию KEY JOIN, как в диалекте SQL Sybase ASA (я о ней уже упоминал). Она покрывает IMHO 80-90% всех случаев использования соединений (т.е. по FK->PK), не основана на именах, и не требует указания имен колонок. Достаточно удобная штука. И при этом не требуется пересмотр синтаксиса SQL.
А то, что вы предлагаете, по первым ощущениям, пригодно лишь для простейших случаев, выглядит замудрено и (есть такое подозрение) в сложных запросах влечет ряд неоднозначностей.

Короче говоря, проблемы тут, как вы пытались представить, особо нет, все же это вопрос синтексический, и в диалекте SQL Sybase ASA решенный просто и легко. Никакой кривизны. В отличие от вашего подхода.

И все же жду пояснений.
13 дек 06, 16:20    [3531569]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
okdoky
Member

Откуда:
Сообщений: 349
okdoky
В последнее время под типом в РМД, все чаще, понимают именованное множество значений. Происходит прогресс. Но даже этого недостаточно. Я бы кратко охарактеризовал тип как множество определяемых значений. Определение типа, это не только задание ему имени, но и описание свойств. Реально, как в РМД, так и в ОМД, описание свойств типа сводится к перечислению типов свойств, то есть к описанию некоторой структуры значений (объектов).
Прошу прощения. Излишняя детализация иногда приводит к большим ошибкам. Правильнее охарактеризовать тип как определяемое множество значений. Впрочем для многих это одно и то же.

Александр Савинов
okdoky
Например, класс «страна».
страна : [ Россия, США, …]
Возможные способы задания отношения для класса «страна» на языке Zigzag
{=страна: Ягугу} (материк: Европа);
страна: Ягугу (материк: Европа);
А что такое отношение (в контексте Зигзага) и для чего оно нужно?
Отношение это связь. Впрочем класс это тоже связь. Зигзаг оперирует всего двумя типами связей «класс» и «отношение». Всё. В этом и заключается выразительная мощь Зигзага. Фактически знаком равно, двоеточием и круглыми скобками можно городить что угодно. Определение каких-то новых типов связей не требуется.

Александр Савинов
А класс и тип в Зигзаге это синонимы?
Нет. Класс это связь «один ко многим», но он может использоваться как тип. Тип нужен прежде всего для ограничения или определения множества возможных значений.
13 дек 06, 16:27    [3531650]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
shuklin
Gluk (Kazan)
Дык как это поможет от закольцованных сцылак та ???

А причем к этому вообще закольцованные ссылки? Мы тут про идентификацию рефернс тайпов говорим.



Нет мы про это говорим :

shuklin

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


Наличие (появление) закольцованных ссылок явно подразумеваются
в ваших словах:
shuklin

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


Вот и возник вопрос как вы их определяете и какие существуют механизмы
для их обработки (определения, разрешения, недопущения обращения по кольцу, etc)?
13 дек 06, 16:33    [3531721]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
mir
Александр Савинов

Вот вам версия в SQL-подобном синтаксисе:
SELECT e.FIO, SUM( e.{Menu.dinnerid.emplID}.<count * dishid.cost> )
FROM Employee e 
WHERE COUNT( e.{Menu.dinnerid.emplID} ) > 100 
  AND dishdate > '01.02.2006' 
  AND name = 'Борщ' 
Ура!!! Я выиграл!! Моя версия короче!
Не хвались, идучи на рать, а хвались, идучи с…хм… рати.

Пока вы не дадите пояснения, говорить не о чем. Итак, для начала:

1. Что в предложении SELECT означают выражения count и dishid.cost? Для них нет никакого способа быть вычисленными из таблицы Employee — единственной таблицы в предложении FROM. То есть как построитель плана запроса догадается, из каких таблиц всей БД брать count и dishid.cost?

В данном случае все честно.
e.{Menu.dinnerid.emplID}
возвращает множество из Menu, которые ссылаются на e. Это можно продолжить как обычно, например:
e.{Menu.dinnerid.emplID}.count
Даст множество чисел, а
e.{Menu.dinnerid.emplID}.dishid
даст множество записей из Dish. Но нам нужно произведение, а потому используем такую запись
e.{Menu.dinnerid.emplID}.<count * dishid.cost>
Это вернет набор записей из Menu, указывающих на e, но содержащих одно указанное поле в виде произведения. Мне лично такая запись не очень нравится, но работать будет.

mir
2. Тот же вопрос про поля dishdate и name в выражении WHERE. Откуда они должны быть взяты?

Поскольку все поля уникальны, то таблицу можно восстановить. Если нет, то добавьте имя таблицы перед полем.

mir
И, соответственно, как в целом данный предикат из WHERE может быть вычислен для записей таблицы Employee?

Это главный вопрос. Дело в том, что в данном примере эта связь однозначно может быть восстановлена. Связь также м.б. восстановлена я для более сложных случаев (но не для всех). Для этого надо посмотреть на структуру таблиц. Ограничения, которые накладываются на одну таблицу, скажем, тип блюда Борщ, далее автоматически распространяются сперва вниз до самой специфичной таблицы (Menu), а потом вверх до целевой таблицы (Employee). Проще говоря, сперва удаляем все Menu, которые не относятся к Борщу, а потому выбираем только тех Employee, которые связаны с оставшимися Menu. Если хотите формальностей, то могу дать ссылку. Но Вы бы могли также попытаться вспомнить что такое universal relation model (URM), которую успешно прибили реляционные фундаменталисты, хотя вещь была весьма перспективная (впрочем, внутри РМД это по любому не выжило бы).

mir
3. Что означают угловые скобки?

В точечно нотации мы пишем имена колонок. Но часто в конце надо вернуть не одно поле, а несколько, поэтому можно записать в угловых скобках (можно и в любых других, конечно):
account.owner.address.<street, haus>
В моем примере, я использовал их, чтобы вложить туда вычисляемое поле:
e.{Menu.dinnerid.emplID}.<count * dishid.cost>
Здесь count и dishid это поля Menu.

mir
4. Что означают фигурные скобки? И имя таблицы перед выражением в фигурных скобках?

Просто последовательность колонок ведет нас в одном направлении, скажем:
menu.dinnerid.emplID
даст работника, который жрал меню m.
Фигурные скобки это оператор обращения. Он позволяет инвертировать последовательности, т.е. рассмотреть ее в обратном направлении. Например,
e.{Menu.dinnerid.emplID}
Вернет все меню, которые жрал работник.


Во всем этом главное, что таблицы упорядочены. Соответственно, есть оператор инверсии {}. Ну а дальше уже вопрос упирается в синтаксис языка.

Еще одно принципиальное отличие этих двух примеров запроса в том, что в SQL клауза FROM включает все вовлеченные таблицы (что вполне обоснованно в рамках РМД). В моем же примере клауза FROM включает только целевые таблицы, из которых будут извлекаться записи. Включать туда все вовлеченные таблицы не только не нужно, но и неправильно. Почему? Я уже упомянул где-то два типа запросов: от ограничений к цели, и от цели к ограничениям. Так вот, надо выбрать один из этих вариантов, а не оба вместе, т.е. не валить все таблицы с разными ролями в одну кучу. Вы конечно применили картинаьлный подход: соединили все таблицы (и получили универсальную таблицу в терминах URM, далее наложили ограничения, потом сгруппировали, а потом вернули, что нужно. В этом случае все таблицы играют равную роль. В моем же примере я попытался как раз указать, что раз нам нужны работники, то собственно указываем только их в FROM. После этого указываем, а собственно какие работники нас интересуют и формируем их агрегированые свойства. Так что различия в двух примерах существенные.
13 дек 06, 16:39    [3531777]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
okdoky
Правильнее охарактеризовать тип как определяемое множество значений.
Дайте отличия типа как множества значений (что, по-вашему, неверно) и типа, как определяемого множество значений.
Короче, чем кардинально отличается множество значений и определяемое множество значений?
13 дек 06, 16:40    [3531781]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
!
Вот и возник вопрос как вы их определяете и какие существуют механизмы
для их обработки (определения, разрешения, недопущения обращения по кольцу, etc)?

Хоть я и не понял причем тут одно к другому, уточняю вопрос. Вас интересует состояние дел в моей разработке, в мире или в абстрактно модельном смысле?
13 дек 06, 16:47    [3531852]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
okdoky
Отношение это связь. Впрочем класс это тоже связь. Зигзаг оперирует всего двумя типами связей «класс» и «отношение». Всё.

В чем тогда необходимость такого разделения? Я не могу их спроецировать на обычные понятия. Может пример поможет. Если есть связи, то должно быть то, что они связывают, скажем, объекты. Правильно?

okdoky
Класс это связь «один ко многим», но он может использоваться как тип. Тип нужен прежде всего для ограничения или определения множества возможных значений.

«один ко многим» - что есть один и что есть много? В смысле, если мы говорим о связи, то что связывает класс? Например,
страна : [ Россия, США, …]
где здесь "один" и где здесь "много"?
Из данного примера я так понимаю, что (в традиционных терминах) мы определили множество "страна", включающее два элемента.
13 дек 06, 16:51    [3531892]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Александр Савинов
Хотя я допускаю, что при этом могут быть нарушены какие-то теологические постулаты РМД.
Нет, никакие теологические постулаты при этом не нарушаются. Конечно есть требования к описываемой сложной ссылочной структуре.
13 дек 06, 16:57    [3531942]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Александр Савинов
В данном случае все честно.
e.{Menu.dinnerid.emplID}
возвращает множество из Menu, которые ссылаются на e.
Выражение e.{Menu.dinnerid.emplID} по смыслу -- подзапрос. Но как ваша система отличает некоррелированные выражения-подзапросы (то есть SUM(e.{Menu.dinnerid.emplID}.<count * dishid.cost>) для всех записей из e) от коррелированных выражений-подзапросов (то есть SUM(e.{Menu.dinnerid.emplID}.<count * dishid.cost>) для каждого ФИО)?

Александр Савинов
mir
2. Тот же вопрос про поля dishdate и name в выражении WHERE. Откуда они должны быть взяты?

Поскольку все поля уникальны, то таблицу можно восстановить.
Вот СУБД видит одиночное поле dishdate. Хоть оно десять раз уникально, из какой таблицы его брать?

Александр Савинов
mir
И, соответственно, как в целом данный предикат из WHERE может быть вычислен для записей таблицы Employee?

Это главный вопрос. Дело в том, что в данном примере эта связь однозначно может быть восстановлена.
Вами -- да, вы же видите картинку БД и понимаете задачу. А СУБД картинку не видит и задачу не понимает. Ей определенность подавай.

Александр Савинов
Ограничения, которые накладываются на одну таблицу, скажем, тип блюда Борщ, далее автоматически распространяются сперва вниз до самой специфичной таблицы (Menu), а потом вверх до целевой таблицы (Employee).
У вас пока неясно, как это "одну" таблицу СУБД определит. Слова, что все делается автоматически, желательно подкрепить описанием этой процедуры. Я пока не понял.
Александр Савинов
Если хотите формальностей, то могу дать ссылку.
Хочу.

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

Александр Савинов
В моем же примере я попытался как раз указать, что раз нам нужны работники, то собственно указываем только их в FROM.

Ошибка. Нам не нужны работники. Нам нужна некая информация, которая в БД распределена по отношениям. И все они равноправны. С чего это вдруг таблица работников "главнее" других? Информация в ней не важнее информации в остальных таблицах.
13 дек 06, 17:11    [3532035]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
okdoky
Member

Откуда:
Сообщений: 349
mir
Дайте отличия типа как множества значений (что, по-вашему, неверно) и типа, как определяемого множество значений.
Короче, чем кардинально отличается множество значений и определяемое множество значений?
Все верно. Они абсолютно не противоречат друг другу. Для начинающих, например для студентов кулинарного техникума, первое определение даже больше подходит.
13 дек 06, 17:13    [3532048]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
shuklin
!
Вот и возник вопрос как вы их определяете и какие существуют механизмы
для их обработки (определения, разрешения, недопущения обращения по кольцу, etc)?

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


В модели на которой строится Ваша разработка.

Двигаясь от общего к часному, у Вас в принципе не определено
понятие констреинта(ограничения) .

Поэтому я уверен, что в разработке этого нет.


Глобальное состояние дел я смогу узнать из других источников.
13 дек 06, 17:18    [3532091]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
okdoky
Member

Откуда:
Сообщений: 349
Александр Савинов
okdoky
Отношение это связь. Впрочем класс это тоже связь. Зигзаг оперирует всего двумя типами связей «класс» и «отношение». Всё.

В чем тогда необходимость такого разделения? Я не могу их спроецировать на обычные понятия. Может пример поможет. Если есть связи, то должно быть то, что они связывают, скажем, объекты. Правильно?

Пример:
страна : [ Россия, США, …]
Этот класс можно представить как связь
    
страна
/ \
Россия США
Здесь «страна» играет роль имени класса. Россия – значение класса. Скорее это не объекты, а элементы в терминах XML-СУБД. С объектом можно ассоциировать отдельную связку (например страна:Россия). Элементов «страна» в БД может быть сколько угодно. Но те элементы, которые образуют связь «класс», не могут образовать связь «отношение». В этом суть разграничения на два типа связей: класс, отношение. Конечно, чтобы понять, нужно вникать в особенности модели данных Зигзаг.
13 дек 06, 17:34    [3532214]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
!
В модели на которой строится Ваша разработка.
т.к. абстрактная модель оперирует неограниченными рессурсами - стройте циклические ссылки сколько душе угодно. сборка мусора - подробности реализации сборщика и его забота, а не модели.
13 дек 06, 17:42    [3532279]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
mir
Александр Савинов
В данном случае все честно.
e.{Menu.dinnerid.emplID}
возвращает множество из Menu, которые ссылаются на e.
Выражение e.{Menu.dinnerid.emplID} по смыслу -- подзапрос. Но как ваша система отличает некоррелированные выражения-подзапросы (то есть SUM(e.{Menu.dinnerid.emplID}.<count * dishid.cost>) для всех записей из e) от коррелированных выражений-подзапросов (то есть SUM(e.{Menu.dinnerid.emplID}.<count * dishid.cost>) для каждого ФИО)?

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

Возможно Вы затрагиваете вопрос как коррелируют разные ограничения? Но это уже не для начинающих SQL-щиков, поэтому Вам вряд ли будет интересно.

mir
Александр Савинов
mir
2. Тот же вопрос про поля dishdate и name в выражении WHERE. Откуда они должны быть взяты?

Поскольку все поля уникальны, то таблицу можно восстановить.
Вот СУБД видит одиночное поле dishdate. Хоть оно десять раз уникально, из какой таблицы его брать?

Из той, где оно определено, т.е. из Dinner.

mir
Александр Савинов
mir
И, соответственно, как в целом данный предикат из WHERE может быть вычислен для записей таблицы Employee?

Это главный вопрос. Дело в том, что в данном примере эта связь однозначно может быть восстановлена.
Вами -- да, вы же видите картинку БД и понимаете задачу. А СУБД картинку не видит и задачу не понимает. Ей определенность подавай.

РСУБД действительно не понимает, она же тупая. Ей надо все вручную прописать. Надо умную СУБД или просто транслятор в SQL.

mir
Александр Савинов
В моем же примере я попытался как раз указать, что раз нам нужны работники, то собственно указываем только их в FROM.

Ошибка. Нам не нужны работники. Нам нужна некая информация, которая в БД распределена по отношениям. И все они равноправны. С чего это вдруг таблица работников "главнее" других? Информация в ней не важнее информации в остальных таблицах.

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

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

Я вложил схему, где таблицы упорядочены, чтобы было немного понятнее.
13 дек 06, 17:48    [3532326]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
okdoky
Member

Откуда:
Сообщений: 349
okdoky
те элементы, которые образуют связь «класс», не могут образовать связь «отношение»
Уточню мысль. Тороплюсь. Приходится поправлять себя. Те элементы, которые образуют друг с другом связь «класс», не могут образовать друг с другом связь «отношение». В приведенном ранее примере элемент "Россия" входит в класс
страна:[Россия, ...]
и может входить в отношение, например
страна:Россия (материк:Европа)
13 дек 06, 17:49    [3532329]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
shuklin
!
В модели на которой строится Ваша разработка.
т.к. абстрактная модель оперирует неограниченными рессурсами - стройте циклические ссылки сколько душе угодно. сборка мусора - подробности реализации сборщика и его забота, а не модели.


Меня интересует могу ли я как разработчик системы ограничивать
пути доступа к обьектам.
Задавать соответствующие бизнес правила.

Если говрить о самом верхнем логическом уровне ,
то это (определять , ограничивать, приоретизировать ) контекст использования обьекта?

Например:
Система умеет говорить по испански, но в ее словаре
нужное слово есть только на русском и английском языках.

Как она должна себя вести? И где это определяется?

Если ваш ответ - это определяет сервер приложений, можете не отвечать.
Я это уже слышал.
В чем же тогда преймущества вашей модели(разработки) над другими ?
13 дек 06, 18:10    [3532468]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
okdoky
okdoky
те элементы, которые образуют связь «класс», не могут образовать связь «отношение»
Уточню мысль. Тороплюсь. Приходится поправлять себя. Те элементы, которые образуют друг с другом связь «класс», не могут образовать друг с другом связь «отношение». В приведенном ранее примере элемент "Россия" входит в класс
страна:[Россия, ...]
и может входить в отношение, например
страна:Россия (материк:Европа)

Т.е. исходить надо из наличия элементов.
Далее мы говорим, что элементы могут группироваться двумя способами, т.е. есть два типа связи:
- классы (элементов), и
- отношения (элементов)
Правильно я догадался?
Ну например, есть (первичные) элементы а, б, в, г, д. Далее мы говорим, что а и б образуют класс (первый тип группирования). А три элемента в, г и д образуют отношение (второй тип группирования). Тогда возникает вопрос, а являются ли элементами сами эти связи, т.е. новые классы и отношения? Другой вопрос, могут ли пересекаться группы (связи) одинакового типа и разных типов? Ну и все еще у меня остается вопрос, какой в этом всем смысл, т.е. что можно описать с помощью таких средств. Что здесь является аналогом привычного объекта со свойствами?
13 дек 06, 18:12    [3532478]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
!
Меня интересует могу ли я как разработчик системы ограничивать
пути доступа к обьектам.


В 90% случаев путь доступа состоит из одного шага, в остальных:


!
Если ваш ответ - это определяет сервер приложений, можете не отвечать.
Я это уже слышал.


!
В чем же тогда преймущества вашей модели(разработки) над другими ?


Если посмотреть на первое сообщение ветки, про приемущества там ничего нет. Речь идет об отличиях. Это другая модель разработки, и это в ней главное. Точнее - другая модель структуры данных.

А для приемуществ надо вспомнить про виртуальные методы у хранимых в БД экземпляров.
Т.е. про апп уровень. Это опять обычный ООП но в котором экземпляры не умирают при перегрузке системы, сохраняя свою идентичность.
13 дек 06, 18:22    [3532532]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
mir
Александр Савинов
Если хотите формальностей, то могу дать ссылку.
Хочу.
Наслаждайтесь:
http://conceptoriented.com/savinov/publicat/csjm_06.pdf
http://conceptoriented.com/savinov/publicat/sac-06.pdf
Попроще:
http://conceptoriented.com/papers/ComInformalIntroduction.html
13 дек 06, 18:26    [3532565]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
shuklin

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


Пошли по N кругу.
Раскажите как вы храните ссылки в стиле C# на ROM.

И мы выйдем на в очередной раз заданный вопрос :

ВСЕ ХОРОМ (В одни голос)

Чем это отличается от отношений ПК-ФК ?


Может заранее подготовить и написать ответ.
13 дек 06, 18:31    [3532582]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
!
Может заранее подготовить и написать ответ.

От того что вы в тысячный раз одно и тоже спросите, ни модель ни реализация не изменится. Следовательно вы или получите тот же ответ или отсылку куда нибудь ... Зачем спрашивать очередной раз тоже самое если уже все поняли?
13 дек 06, 18:36    [3532609]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 12 13 14 15 16 [17] 18 19 20 21 .. 31   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить