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

Ну, в общем, чтобы передать строку по ключу, нужно указать провайдера, сервер, логин, пароль, базу, схему, таблицу, поле, значение... Вы об этом?
6 дек 06, 21:38    [3501727]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
okdoky
Member

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

1. [Идентифицирующие свойства] Определить эти два поля в классе обозначаемых объектов. Недостатки:
- для каждого нового класса объектов надо вводить такие поля, а их м.б. много (выход: наследование).
- надо писать процедуру, которая будет перебирать все объекты и искать нужный путем сравнения (ускорение с помощью индексов).
- кто-то может подумать, что это обычные свойства и, скажем, поменять их (выход: запретить это)
- не понятно как передавать эти поля в качестве ссылки и осуществлять прозрачный доступ, ведь эти два поля не отдельный элемент, а всего лишь набор значений.

2. [Новый класс ссылки] Определить эти два поля как новый тип ссылки и ассоциировать процедуру доступа с ней. Преимущества:
+ мы по-прежнему пользуемся ссылками, не подозревая, что там содержится что-то другое.
+ они отделены от объектов, не хранятся внутри, а передаются из рук в руки.
+ они обслуживают много разных классов объектов, т.е. разрабатываются как универсальное средство отдельно от классов объектов и независимо от них.
+ доступ осуществляется путем разрешения ссылки в базовую ссылку (которая в свою очередь опять может разрешаться и т.д.)
Перед тем как рассматривать ваши плюсы, хотелось бы уточнить как вы предполагаете ассоциировать процедуру доступа со ссылкой? Вы создаете новый класс ссылок, ссылок на что? На "объекты" которые хранятся во внешней памяти? Но, как я вам объяснил, объекты в обычной БД (с большим объемом данных) не идентифицируются адресом...
6 дек 06, 22:01    [3501754]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
foobar
Guest
foobar
Долгота и широта тоже не идентифицируют ни одного объекта, если не считать "потусторонних" (точка, полюс, экватор). Потустороннее не интересно.

Хотя, с другой стороны, прибьем гвоздями или закон движения...
7 дек 06, 00:04    [3501915]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
okdoky
Member

Откуда:
Сообщений: 349
Александр Савинов
доступ к объекту не может быть организован на основе его свойств
Все, что вы предлагаете
<имя, номер> ---> <свойство1, свойство2, …>
используется в СУБД и называется индексацией. При этом, кроме <имя, номер>, другие свойства также участвуют в индексации и также являются идентификаторами. Незаметно для себя вы скатились на физический уровень реализации. При этом сильно ограничили идентификацию и забыли про то, что в запросе присутствуют не только имена объектов, но и их свойства.
7 дек 06, 09:07    [3502365]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Александр Савинов
Итак, в РМД идентификаторы не нужны, правильно я понял (обеспечение целостности или уникальности это ведь не есть идентификация)?
А что такое «идентификаторы»? Когда формально определите, тогда и можно будет сказать, нужны или нет.

Второе. Понятия «идентификатор» и «идентификация» похожи, но не равноправны. Первое трудно корректно определить для общего случая (вы этого и не сделали), а со вторым все куда яснее, строго говоря, идентификация — признание тождественности, отождествление объектов, опознание (Современная энциклопедия). Поскольку в РМД методом отождествления является простое сравнение значений, то идентификация в РМД методологически изначально присутствует. Другое дело, что идентификация в любой формальной системе обязательно требует вовлечения знания семантики, контекста, иначе возможен полный абсурд. Например, использования сохраненных адресов ОЗУ для отождествления программных объектов в памяти будет бессмысленным, если после сохранения (запоминания) адреса (к примеру, на диске или на бумажке) компьютер перезагружается. В РБД, скажем, для отождествления требуется знание природы сравниваемых значений и контекста сравнения. Но это вопрос отдельный.

Короче, вывод: отдельная концепция «идентификатора» в РМД формально не нужна, а концепция «идентификации» крайне нужна (как же без этого-то), и она таки там есть.

Александр Савинов
Но тогда идинственный способ сохранить информацию о значении или кортеже состоит в запоминании свойств сущности.
Позвольте даже так: единственный способ сохранить информацию — это ее сохранить. Вы с этим будете спорить? В любом случае компьютер и/или человек должны что-то где-то хранить. В оперативной ли памяти (что компьютер, что человек), на внешнем ли носителе (скажем, бумажка для человека, диск для компьютера).
Александр Савинов
Далее мы надеемся, что эти сохраненные свойства дадут нам возможности найти целевой элемент.
О да, если человек или компьютер ничего не сохранил, то он ничего и никогда не найдет.
Александр Савинов
Например, есть кортеж с описанием личности. Чтобы запомнить его, мы сохраняем какие-то свойства, скажем <глаза=хитрые, руки=длинные, религия=РМД>. Такие же свойства хранятся в кортеже, а потому при необходимости мы можем найти данный объект. Я правильно понимаю, или где-то ошибка?
Правильно. Как у нас в жизни-то: занесли данные о нужном человеке в записную книжку: «глаза — глупые, руки — короткие, религия — ОМД». Потом надо, скажем, найти эту запись, да хоть чтобы ее удалить. Вот мы и ищем согласно тому, что запомнили. Если этот набор атрибутов удовлетворяет свойству уникальности, то мы найдем в своей книжке ровно одну запись или ни одной. Если нет, возможно найдем множество. То же в точности происходит и в РБД.
Александр Савинов
Если да, то это не идентификатор, а идентифицирующие свойства, коих может быть сколько угодно и они никак не поддержаиваются.
Ой, я таки вас умоляю, хватит использовать слово «идентификатор», никак его строго не определив. Мало ли вы что под ним подразумеваете? Ваш сосед, может, понимает под ним другое, а я и вовсе третье… Это не разговор, а переливание из пустого в порожнее.

Фразу про «они никак не поддерживаются», простите, совсем не понял. Кем не поддерживаются? Как не поддерживаются? Почему не поддерживаются? Что вообще значит — «поддерживаются»?
Александр Савинов
Но хуже всего то, что такой способ не работает, поскольку, как было отмечено, невозможно получить доступ к объекту, исходя из его свойств.
Какой способ? Поиск в записной книжке по фамилии? А ну-ка, ну-ка, берем мобильник, открываем справочник, ищем по имени «Андрей Артибякин»… Опа — нашел! Тут тебе и номер телефона и еще много чего. Смотри-ка, а Александр Савинов говорил, что этот способ не работает. Странно… Видимо, злое колдунство :)

А если серьезно (простите мне чуток сарказма, обидеть не хотел), то вы, видимо, плохо изучали в ВУЗе различные компьютерные архитектуры. В частности, есть архитектуры с ассоциативной памятью, называемой так же память с доступом по содержимому (content-addressable memory). В них, знаете ли, доступ к памяти можно осуществлять не только по адресу, но и по значению (ассоциативно).

А вы так смело говорите, что это невозможно. Понимаете, это даже в железе реализовано. Если уж вас пример с записной книжкой не убедил :)
Александр Савинов
Если это не ясно, то могу пояснить. Чтобы найти человека с заданными идентифицирующими свойствами, надо уже (заранее) иметь доступ к объекту, чтобы иметь возможность получить и сравнить его свойства.
Понимаете, какая штука. В компьютерной системе человек храниться не может. Тупо не влезет в системный блок. А влезет, так и помрет быстро (снова пардон за этот грубый и несмешной щютка). Серьезно, мы храним в компьютере только данные. А уж коли мы их храним, то они всегда доступны.
Александр Савинов
Таким образом, вывод:
доступ к объекту не может быть организован на основе его свойств
Таким образом, вывод ни на чем не основан.
Александр Савинов
Идентификатор как средство доступа это всегда отделяемая часть объекта, которая существует независимо от обозначаемого объекта и, вообще говоря, можеть жить даже без него. Как же тогда осуществляется связь между ними, это уже другой вопрос. Но ясно только, что НЕ с помощью свойств обозначаемого объекта.
Где же, позвольте спросить, цепочка доказательств, которая приводит к этим смелым выводам? Пока что, извините, кроме вашего внутреннего убеждения никаких аргументов не наблюдается. Вам-то, может, и «ясно», да вот этого пока недостаточно.
Александр Савинов
Что касается РМД, то из вашего краткого изложения следует, что в ней понятия доступа нет, т.е. никто не знает как получить доступ к значениям v1 и v2.
И как же вы ухитрились такой вывод сделать? И доступа-то там нет, и как получить доступ к значению переменной никто не знает… Такое чувство, что вы под «доступом» что-то свое, глубоко лично понимаете.
Александр Савинов
А значит и не надо моделироваь идентификаторы
Что такое «идентификаторы» и что значит «моделировать идентификаторы»?
Александр Савинов
единственный способ что-то сохранить для дальнейшего доступа это использовать (уникальные) свойства. Правильно?
Логически — да.
Александр Савинов
РМД занимается только моделированием свойств сущностей (но не идентификаторов).
Строго говоря, РМД занимается (помимо прочего) моделированием данных. Реляционная база данных хранит факты (а не сущность или объекты, что бы это не значило).
Александр Савинов
Правда, есть одно "но". Дело в том, что говорить о сущностях, будь то значения или кортежи, без того, чтобы сказать как осуществляется к ним доступ, это по моему, полный абсурд.
По-моему, абсурд появляется при путанице логического (модель данных) и физического (реализация в конкретной СУБД). Вы (совершенно определенно) путаете логический и физический доступ. Логический доступ заключается всего лишь в формальной нотации. Показать, как осуществляется логический доступ — значит всего лишь продемонстрировать запись нужного выражения. Зачем вы мешаете еще до кучи физический доступ — совершенно непонятно. Вы еще скажите, что говорить о доступе к переменной без того, чтобы сказать, как при этом осуществляется взаимодействие электромагнитных полей и элементарных частиц — это полный абсурд.
Александр Савинов
Зачастую бОльшая часть дизайна как раз приходится на моделирования идентификаторов.
Да ну?
Александр Савинов
Но делается это неадекватными способами через идентифицирующие признаки. Но это уже другой вопрос.
Позвольте спросить, что в точности означает «неадекватность»? Неадекватность чему? Критерии адекватности?
7 дек 06, 09:30    [3502429]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Господа, что-то нить обсуждения теряется. Было интересно читать, а теперь пошёл ликбез...
7 дек 06, 09:55    [3502543]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
pavelp
Господа, что-то нить обсуждения теряется


А она была ? Нить, в смысле.

Снова туманные беседы про некие мистические идентификаторы :(

Тут нужен только лкбез, причем короткий :

1. РМД предназначена для хранения и манипулирования данными.

2. Данные могут быть представлены в виде кортежей , кортежи объединяются в отношения.

3. Если "идентификатор" (что бы под ним не подразумевалось) это данные, то в РМД он будет представлен в виде элемента кортежа (см. пункт 2), если это не данные (навигатор кол. ЧАЛ-а,адрес в памяти для ЭВМ конкретной архитектуры, философская категория, бесплотный дух и т.п. и т.д.) он не является предметом рассмотрения РМД (см. пункт 1).


В последнее время всё больше и больше народу рассуждает о моделях, семантике, ОО-чего-то-там, банально путая физический и логический уровень.
7 дек 06, 10:17    [3502691]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
Александр Савинов
В целом, единственное, что я хотел сказал, это то, что первый способ (идентификационные метки) это плохо, а второй способ это хорошо. Но с другой стороны, в настоящее время поддержка имеется только первого способа (и то довольно плохая, например, в РМД), а второй практически не поддерживается (за редкими исключениями).

Надо отметить, что РСУБД медленно мигрируют к поддержке идентификаторов.
Идентификатор не хранится в самом объекте, но должен хранится как ссылка на этот объект из других объектов (т.е. это св-во ссылающихся объектов).
зы. со всем остальным согласен.
7 дек 06, 10:40    [3502850]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
mir
По-моему, абсурд появляется при путанице логического (модель данных) и физического (реализация в конкретной СУБД).

Это точно. Вот только с каких пор реализация в конкретной СУБД стала физическим уровнем ?.
Концепт. модель -> модель данных -> логический уровень СУБД -> физический уровень СУБД
Мат. часть ?
7 дек 06, 10:50    [3502933]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
okdoky
Александр Савинов
доступ к объекту не может быть организован на основе его свойств
Все, что вы предлагаете
<имя, номер> ---> <свойство1, свойство2, …>
используется в СУБД и называется индексацией.

Да, все правильно, именно такое разбиение на две группы я и предлагаю, но в общем случае лучше записать так:
<св-во_ссылки1, св-во_ссылки2,...> ---> <св-во_объекта1, св-во_объекта2, …>
Первая группа это, что передается по значению и обычно (но не обязательно) идентифицирует объект. Вторая группа это обычный объект, который передается по ссылке и доступен только через ссылку. Заметим, что здесь нет никакой памяти, процессора, шины данных и др. элементов конкретной архитектуры.

Для сравнения, в РМД, если использовать ключ для идентификации, то получается следущее:
<имя, номер> ---> <имя, номер, свойство1, свойство2, …>
Почувствуйте разницу. Как минимум, информацию дублируется (откуда интерес к СУБД по принципу БД=индекс). Но хуже то, что в дизайне отсутствует принципиальное разделение этих двух ролей и ответственности.

Кстати, это не есть индексация (хотя и сильно связано с этим механизмом). Строго говоря, индекс работает исключительно со ссылками, т.е. свойства объектов там никак не задействованы:

<св-во_ссылки1, св-во_ссылки2,...> ---> <св-ва базовой ссылки>

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

okdoky
При этом, кроме <имя, номер>, другие свойства также участвуют в индексации и также являются идентификаторами. Незаметно для себя вы скатились на физический уровень реализации. При этом сильно ограничили идентификацию и забыли про то, что в запросе присутствуют не только имена объектов, но и их свойства.

Я как раз ничего не говорил про физический уровень, а вот вы пытаетесь туда переместить рассуждение зачем-то. Так можно дойти до руды, из которой компьютеры делают. В частности, индексы нигде не формализованы и не являются частью модели. Поэтому можно их опустить.

Но если все-же их рассмотреть, то быстрый доступ по любым свойствам объекта это хорошо, никто не спорит. Но здесь есть несколько моментов, которыя и собстсенно и хотел отметить. Во-первых, такой доступ всегда основан на каком-то фундаментальном механизме доступа, т.е. на фундаментальных ссылках, которых не входят в набор свойств объекта (например, номер записи). Т.е. доступ по полям это ближе к поиску нужного объекта. Но хуже, что такое удобство и равноправие колонок провоцирует на неправильный дизайн. В целом, как уже было не раз отмечено, РМД просто так устроена и все тут. Т.е. в ней удобно получать данные по содержимому, но называть это полноценной идентификацией нельзя - это поиск объектов по их свойствам. Вот и все.
7 дек 06, 11:57    [3503456]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
mir
Александр Савинов
Но хуже всего то, что такой способ не работает, поскольку, как было отмечено, невозможно получить доступ к объекту, исходя из его свойств.
Какой способ? Поиск в записной книжке по фамилии? А ну-ка, ну-ка, берем мобильник, открываем справочник, ищем по имени «Андрей Артибякин»… Опа — нашел! Тут тебе и номер телефона и еще много чего. Смотри-ка, а Александр Савинов говорил, что этот способ не работает. Странно… Видимо, злое колдунство :)

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

Отсюда можно сделать некоторые определения:
Поиск - процедура нахождения объекта с нужными свойствами.
Доступ - процедура получения свойств объекта по его ссылке.

Первое очевидно основано на втором, а не самом себе. Более того, второй механизм фундаментален, а первый нет.
7 дек 06, 12:22    [3503671]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

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

Первое очевидно основано на втором, а не самом себе. Более того, второй механизм фундаментален, а первый нет.


+1
7 дек 06, 12:31    [3503743]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Александр Савинов

Для того, чтобы найти нужный объект, надо проверить его свойства, которые хранятся внутри него. Это значит, что этот объект уже должен быть доступен (как-то).
Да
Александр Савинов
Таким образом, необходимо иметь какую-то процедуру, которая получает доступ к объекту без знания его свойств.
Нет. Достаточно иметь процедуру, которая переберет все объекты. Т.е.достаточно памяти последовательного доступа.
7 дек 06, 12:50    [3503912]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
okdoky
Member

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

<св-во_ссылки1, св-во_ссылки2,...> ---> <св-во_объекта1, св-во_объекта2, …>
Первая группа это, что передается по значению и обычно (но не обязательно) идентифицирует объект. Вторая группа это обычный объект, который передается по ссылке и доступен только через ссылку. Заметим, что здесь нет никакой памяти, процессора, шины данных и др. элементов конкретной архитектуры.
На логическом уровне идентификатор, это левый кортеж? Чтобы связать между собой объекты на месте свойств должны находится логические идентификаторы (свойства ссылок) или физические (ссылки)? В любом случае, на логическом уровне объект будет выглядеть как-то громоздко
<<св-во_ссылки1, св-во_ссылки2,...>,<св-во_ссылки1, св-во_ссылки2,...>,...>
7 дек 06, 13:04    [3504035]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
nooo
Guest
Александр Савинов
Отсюда можно сделать некоторые определения:
Поиск - процедура нахождения объекта с нужными свойствами.
Доступ - процедура получения свойств объекта по его ссылке.

Первое очевидно основано на втором, а не самом себе. Более того, второй механизм фундаментален, а первый нет.

Ссылки определены в пределах конкретных адресных пространств, бессмысленны сами по себе. Тема адресных пространств не раскрыта. Равенство двух чисел выглядит более фундаментально.
7 дек 06, 13:39    [3504366]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
pavelvp
Member

Откуда:
Сообщений: 673
Александр Савинов
Отсюда можно сделать некоторые определения:
Поиск - процедура нахождения объекта с нужными свойствами.
Доступ - процедура получения свойств объекта по его ссылке.

Первое очевидно основано на втором, а не самом себе. Более того, второй механизм фундаментален, а первый нет.
Термин "ссылка" никак не тянет на фундаментальность.
7 дек 06, 13:49    [3504458]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
nooo
Ссылки определены в пределах конкретных адресных пространств, бессмысленны сами по себе. Тема адресных пространств не раскрыта.
Именно так. Вот немного про этот момент.
7 дек 06, 13:56    [3504520]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

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

<св-во_ссылки1, св-во_ссылки2,...> ---> <св-во_объекта1, св-во_объекта2, …>
Первая группа это, что передается по значению и обычно (но не обязательно) идентифицирует объект. Вторая группа это обычный объект, который передается по ссылке и доступен только через ссылку. Заметим, что здесь нет никакой памяти, процессора, шины данных и др. элементов конкретной архитектуры.
На логическом уровне идентификатор, это левый кортеж?

Да (для целей данного обсуждения).

okdoky
Чтобы связать между собой объекты на месте свойств должны находится логические идентификаторы (свойства ссылок) или физические (ссылки)?

Логические идентификаторы. Физические ссылки нигде напрямую не участвуют (если явно это не указано).

Более точно, там хранится логический идентификатор, который соответствует типу свойства. Например, если объект (скажем, описание человека) имеет свойство банковский счет:
Person <String passportNumber> ---> <..., Account account, ...>
то поле account содержит логическую ссылку на объект типа Account:
Account <Bank bankName, String accountNumber> ---> <..., double balance, ...>
В данном случае будет храниться два поля. Далее, если у нас есть ссылка на человека, то можно получить остаток на его счету:
Person person = findPerson("Vasya");
Account account = person.account;
double balance = account.balance;
Здесь переменные person и account (также как и поля в объектах и ссылках) хранят логические ссылки, т.е. имеют определенную внутреннюю структуру в соответствии с левой частью. Свойства:
- свойства объектов отделены от свойств логических ссылок (как на уровне объявления, так и на физическом уровне).
- логические ссылки передаются только по значению.
- объекты передаются только по (логическим) ссылкам.
- доступ всегда опосредован и осуществляется через разрешение логических идентификаторов

okdoky
В любом случае, на логическом уровне объект будет выглядеть как-то громоздко
<<св-во_ссылки1, св-во_ссылки2,...>,<св-во_ссылки1, св-во_ссылки2,...>,...>

Эта внутренняя структура не видна, хотя именно так и есть и в общем случае вложенность м.б. гораздо глубже. Когда мы объявляем переменную или поле с типом объекта, то оно имеет конкретное имя (account, balance), но внутренняя структура скрыта. Так что использование ничем не отличается от обычного ООП. Разница в том, что можно определять свои собственные ссылки и свой собственный механизм доступа по ним.

Ну раз уж мы так далеко добрались, то есть смысл ввести определение новой конструкции:

Концепт это комбинация двух классов: класса объекта и класса ссылки.

Например:
concept Account // Одно имя для пары классов
  reference { // Класс ссылки
    String bankName;
    String accountNumber;
  }
  class { // Класс объекта
    Person owner;
    double balance;
  }
7 дек 06, 14:02    [3504578]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
nooo
Александр Савинов
Отсюда можно сделать некоторые определения:
Поиск - процедура нахождения объекта с нужными свойствами.
Доступ - процедура получения свойств объекта по его ссылке.

Первое очевидно основано на втором, а не самом себе. Более того, второй механизм фундаментален, а первый нет.

Ссылки определены в пределах конкретных адресных пространств, бессмысленны сами по себе.

Почему?

Я бы сказал, что определение класса ссылок это и означает определение (адресного) пространства.
7 дек 06, 14:05    [3504614]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
pavelvp
Александр Савинов
Отсюда можно сделать некоторые определения:
Поиск - процедура нахождения объекта с нужными свойствами.
Доступ - процедура получения свойств объекта по его ссылке.

Первое очевидно основано на втором, а не самом себе. Более того, второй механизм фундаментален, а первый нет.
Термин "ссылка" никак не тянет на фундаментальность.

Более точная формулировка: понятие ссылки не менее фундаментально, чем объекта.
Следствие: уметь моделироваь ссылки не менее важно, чем объекты.
7 дек 06, 14:29    [3504821]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
Александр Савинов
pavelvp
Термин "ссылка" никак не тянет на фундаментальность.
Более точная формулировка: понятие ссылки не менее фундаментально, чем объекта.
Следствие: уметь моделироваь ссылки не менее важно, чем объекты.
Увы и ах, понятие объекта вообще не фундаментально. Лингвистически оно полностью размыто, а математически не определено.
Тем паче не определено понятие ссылки. И идентификатора.
Вы, Александр, не замечаете, что пытаетесь строить критику РМД на крайне зыбком фундаменте, я бы сказал -- практически без фундамента?
"Критика" строго формальной теории с крайне неформальных позиций выглядит... несерьезно, по меньшей мере.
7 дек 06, 16:09    [3505710]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
mir
Member

Откуда: Томск
Сообщений: 1027
мод
mir
По-моему, абсурд появляется при путанице логического (модель данных) и физического (реализация в конкретной СУБД).

Это точно. Вот только с каких пор реализация в конкретной СУБД стала физическим уровнем ?.
Концепт. модель -> модель данных -> логический уровень СУБД -> физический уровень СУБД
Мат. часть ?

Вариант ответа №1 (грубый): Именно матчасть. В сад.
Вариант ответа №2 (вежливый): логический уровень СУБД и есть уровень модели данных.
7 дек 06, 16:13    [3505739]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
мод
Guest
mir
Вариант ответа №2 (вежливый): логический уровень СУБД и есть уровень модели данных.

В принципе да, но при условии, что СУБД полностью поддерживает данную модель ( а это не всегда так). Но по любому здесь нет физического уровня, физический уровень -это файлы, индексы, спейсы и т.д.
7 дек 06, 16:21    [3505805]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
mir
Александр Савинов
pavelvp
Термин "ссылка" никак не тянет на фундаментальность.
Более точная формулировка: понятие ссылки не менее фундаментально, чем объекта.
Следствие: уметь моделироваь ссылки не менее важно, чем объекты.
Увы и ах, понятие объекта вообще не фундаментально. Лингвистически оно полностью размыто, а математически не определено. Тем паче не определено понятие ссылки. И идентификатора.

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

mir
Вы, Александр, не замечаете, что пытаетесь строить критику РМД на крайне зыбком фундаменте, я бы сказал -- практически без фундамента?
"Критика" строго формальной теории с крайне неформальных позиций выглядит... несерьезно, по меньшей мере.

Неправильно. Во-первых, меня не очень интересует РМД вообще и ее критика в частности. А во-вторых, некоторые ее черты, которые я отметил, не означают критики, а просто констатация факта. Например, молотком трудно заворачивать шурупы. Это ведь не критика, а свойство молотка. Так же с помощью РМД трудно моделироваь ссылки и механизм доступа, поскольку она для этого не предназначена. Существующие РСУБД пытаются это исправить, но при этом перестают быть Р, а становятся просто СУБД. Но это уже другой вопрос.
7 дек 06, 16:44    [3506023]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
nooo
Guest
Александр Савинов
Я бы сказал, что определение класса ссылок это и означает определение (адресного) пространства.

Вы заменили интуитивно понятное мне "адресное пространство" на интуитивно понятное вам "класс ссылок". Кстати, мое адресное пространство интуитивно упирается в железо. Может быть и означает. Судя по реакции shuklin, не означает(!).
7 дек 06, 17:07    [3506236]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 [9] 10 11 12 13 .. 31   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить