Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10   вперед  Ctrl      все
 Re: А вот мне интересно - Оракл объектная СУБД или нет?  [new]
it depends
Guest
Alexey Rovdo
ЧАЛ

... Вам не кажется, что "приложение" должно быть одно ? И это приложение - объектный навигатор - и может быть построено на концепциях классической ОМД, но никак не на концепциях РМД или ОМД на принципах ООП...

.... Где можно посмотреть на "объектный навигатор" живьем? Он существует в природе (хоть для какой-нибудь платформы)?

Коллега ЧАЛ, вероятно, имеет в виду X.Magic http://www.informx.ru/prod03.htm
Не кочал, ниасилил. :)
По описанию на первый взгляд сходно с реализацией ORM (Object Role Modeling)
21 сен 05, 10:51    [1897018]     Ответить | Цитировать Сообщить модератору
 Re: А вот мне интересно - Оракл объектная СУБД или нет?  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
автор
Коллега ЧАЛ, вероятно, имеет в виду X.Magic http://www.informx.ru/prod03.htm
Не подходит. Написано:

Приложения, созданные с помощью X.Magic программируются на одном языке – Cachй Object Script, и будут одинаково корректно работать как в терминальном текстовом, так и в графическом интерфейсе в среде MS Windows.
21 сен 05, 13:50    [1897994]     Ответить | Цитировать Сообщить модератору
 Re: А вот мне интересно - Оракл объектная СУБД или нет?  [new]
AI
Member

Откуда: Москва
Сообщений: 2817
ЧАЛ
Да, Al, это все известно. Но при чем здесь связи между объектами ? Это Вы так договоритесь до того, что первичные ключи "идентифицируют" сущности, а внешние ключи представляют связи между сущностями...


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

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

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

Я просто не понимаю, почему ведутся религиозные войны между разными моделями отображения одного и того же в программе. Разные подходы не появились бы, если бы у них не было своих достоинств. Оракл сейчас пытается сделать некую объектную надстройку над классическими таблицами, при этом сама надстройка влияет на механизмы работы. В частности, в том же оракле есть прямые ссылки на объекты с возможностью "прямой навигации". Это хорошо видно, если посмотреть на синтаксис SQL-команд. Документация по ораклу имеется на www.oracle.com в открытом доступе.

За сим позвольте откланяться.
21 сен 05, 15:33    [1898623]     Ответить | Цитировать Сообщить модератору
 Re: А вот мне интересно - Оракл объектная СУБД или нет?  [new]
Alexey Rovdo
Member

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

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


Это что-ли о TopLink?

AI

В частности, в том же оракле есть прямые ссылки на объекты с возможностью "прямой навигации".


Дайте ссылку на источник такой информации, а то это

AI

Это хорошо видно, если посмотреть на синтаксис SQL-команд. Документация по ораклу имеется на www.oracle.com в открытом доступе.


как-то расплывчато ...
21 сен 05, 16:20    [1898998]     Ответить | Цитировать Сообщить модератору
 Re: А вот мне интересно - Оракл объектная СУБД или нет?  [new]
ЧАЛ
Guest
Вы заблуждаетесь, ModelR. И Вы меня неправильно понимаете. Наверное я косноязычен. Вернемся к 1893669.
Нет никаких "FK" у связей. И нет никаких "FK" у объектов. И ни у объектов, ни у связей нет ничего отдаленно напоминающего "FK". Это же другой уровень абстракции. Есть объекты, и есть связи между объектами. Ни идентификаторы объектов не явлвются одной из характеристик объекта, ни идентификаторы ДРУГИХ объектов не являются одной из характеристик объекта.
Странно, что Вы этого не понимаете. Ведь этот вопрос хорошо исследован. Почитайте работы по базам данных с 1965 по 1980 годы (с тех пор в теории баз данных практически ничего не изменилось), и Вы во все разберетесь.
Моя вина, наверное тоже есть. Зря я упоминал работу Чена. Будем считать, что Вы из-за меня серьезно ошибаетесь, когда говорите, что в ER-модели есть "связи многие-ко-многим без атрибутов". На самом деле у Чена:

A relationship set, Ri, is a mathematical relation [5]...
[5] Birkhoff G., Bartee T.C. Modern Applied Algebra ...

Никаких связей, конечно, нет. Они есть только на "концептуальных" диаграммах. А на логическом уровне - "обычная" реляционная модель...
21 сен 05, 20:39    [1899884]     Ответить | Цитировать Сообщить модератору
 Re: А вот мне интересно - Оракл объектная СУБД или нет?  [new]
ЧАЛ
Guest
Никаких X.Magic-ов я в виду не имел. Мы говорим о моделировании данных. О том как моделируются связи между объектами. Я просто уверен, что без навигации работать с базами данных не эффективно, и будущее за объектными навигаторами. Причем они уже сейчас вполне в состоянии вытеснить большую часть приложений (в плане пользовательского интерфейса) - написал триггеры, в крайнем случае подменил некоторые функции навигатора "прикладными" и все. Так что зря, мне кажется, ModelR иронизирует про аптеку...
21 сен 05, 20:44    [1899891]     Ответить | Цитировать Сообщить модератору
 Re: А вот мне интересно - Оракл объектная СУБД или нет?  [new]
ЧАЛ
Guest
Я понимаю, Al, что Вы не понимаете. Оракл всегда (а не сейчас) пытался что-то сделать с "классическими таблицами". То есть всегда вел "религиозную войну" со своим собственным продуктом...
Лучше, когда никаких надстроек нет, а цель достигнута. Разве это не очевидно ?
21 сен 05, 20:47    [1899897]     Ответить | Цитировать Сообщить модератору
 Re: А вот мне интересно - Оракл объектная СУБД или нет?  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Возьмем общеизвестный пример:

Каждая Накладная может Содержать одну или более СтрокаНакладной.
Каждая СтрокаНакладной должна Содержаться_в ровно одной Накладная.
Каждая СтрокаНакладной должна Указывать ровно один Товар.
Каждый Товар может Быть_указан_в одной или более СтрокаНакладной.

Давайте начнем с уровня абстракции.
ЧАЛ

Нет никаких "FK" у связей. И нет никаких "FK" у объектов. И ни у объектов, ни у связей нет ничего отдаленно напоминающего "FK". Это же другой уровень абстракции. Есть объекты, и есть связи между объектами. Ни идентификаторы объектов не явлвются одной из характеристик объекта, ни идентификаторы ДРУГИХ объектов не являются одной из характеристик объекта.

В моем понимании пример описан на концептуальном уровне, где Накладная, СтрокаНакладной, Товар - сущности, Содержать, Содержаться_в, Указывать, Быть_указан_в - связи. Ничего пока неизвестно о способах идентификации, способах связывания и тем более о СУБД.

Мы на нужном уровне абстракции?
22 сен 05, 11:00    [1900728]     Ответить | Цитировать Сообщить модератору
 Re: А вот мне интересно - Оракл объектная СУБД или нет?  [new]
ЧАЛ
Guest
Конечно, ModelR ! Только почему это мой пример со связью многие-ко многим не общеизвестный ???
Вы же все прекрасно понимаете. Мы на нужном уровне абстракции.
Но на следующем шаге Вы опуститесь на другой уровень абстракции - на уровень отношений РМД. И скажете то, за что меня здесь назвали "демагогом", "шизофреником" и "уродом": что механизм внешних ключей РМД представляет связи концептуального уровня "должна Содержаться в" и "Указывать" (при этом сама семантика связи утрачивается, и симметрия так же утрачивается !).
А я останусь НА ТОМ ЖЕ УРОВНЕ абстракции. Потому что логическая модель Вашего примера в ОМД такая же, как и концептуальная:

Накладная -- Содержит/Входит в -> Операция отгрузки
Операция отгрузки <- Относится к/Имеет -- Товар

(извините, что немного изменил семантику).

P.S. На вопрос темы нужно ответить. Oracle не является объектной СУБД в смысле классической ОМД, так как в ней нет, и принципиально не может быть, идентификации, навигации и семантики на уровне БД. Потому что БД - "реляционная". Является ли Oracle объектной СУБД в смысле ОМД на принципах ООП ? Это, наверное, лучше скажет Alexey Rovdo...
22 сен 05, 21:29    [1903387]     Ответить | Цитировать Сообщить модератору
 Re: А вот мне интересно - Оракл объектная СУБД или нет?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ЧАЛ

Oracle не является объектной СУБД в смысле классической ОМД,...навигации


ЧАЛ

Является ли Oracle объектной СУБД в смысле ОМД на принципах ООП ?

В классической ОМД нет ООП !!!, а есть тока навигация.
Т.е. там ничего достойного О нет, а есть доступ, который есть в любой допотопной системе. Там и СУБД то первого поколения в лучшем случае, а то и вообще никакая. Что-то дореляционное.

Еще бы Оракл (один из лидеров среди СУБД) опустился до нуля, чтобы быть такой якобы классической ОМД. Нашли дураков.
22 сен 05, 22:29    [1903444]     Ответить | Цитировать Сообщить модератору
 Re: А вот мне интересно - Оракл объектная СУБД или нет?  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
ЧАЛ
Конечно, ModelR ! Только почему это мой пример со связью многие-ко многим не общеизвестный ???
Вы же все прекрасно понимаете. Мы на нужном уровне абстракции.
OK. Вашего пример ничем не хуже, ну раз уж подробно расписаны бизнес-правила про накладные, то проще их и обсуждать.
ЧАЛ

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


А я останусь НА ТОМ ЖЕ УРОВНЕ абстракции. Потому что логическая модель Вашего примера в ОМД такая же, как и концептуальная:

Накладная -- Содержит/Входит в -> Операция отгрузки
Операция отгрузки <- Относится к/Имеет -- Товар

(извините, что немного изменил семантику).
Уточним еще про понятие связи.
Пара правил:
Каждая Накладная может Содержать одну или более СтрокаНакладной.
Каждая СтрокаНакладной должна Содержаться_в ровно одной Накладная.
описывает одну связь "Содержать/Содержаться_в".
Эта связь не симметрична (1:1 к 0:M)
Это все, что я могу рассказать про семантику этой связи. Или есть еще что-то кроме пары правил, пары сущностей и пары глаголов для направлений связи ?
Про логический уровень не понял, если он такой же то зачем их два? Следующий уровень чем-то же должен быть более подробен.

Но главное - является ли собственно СтрокаНакладной (Операция Отгрузки) связью в Вашем понимании или сущностью?
Я уже говорил, в моем понимании это сущность, можно сущность-связь, но не просто связь - это ведет к двусмысленности.
"Связь Содержать/Содержаться_в (1:1 к 0:M) сущности-связи СтрокаНакладной со сущностью Накладная" как-то еще по-русски, но
"Связь ... связи ... с сущностью" как-то не того...

ЧАЛ

P.S. На вопрос темы нужно ответить. Oracle не является объектной СУБД в смысле классической ОМД, так как в ней нет, и принципиально не может быть, идентификации, навигации и семантики на уровне БД. Потому что БД - "реляционная". Является ли Oracle объектной СУБД в смысле ОМД на принципах ООП ? Это, наверное, лучше скажет Alexey Rovdo...

Про ORACLE я уже говорил - это программа на сегодня включает кучу машин, в т.ч. Java - а раз ява то запросто можно подцепить объектную базу и там уже сам черт не разберет...
23 сен 05, 00:26    [1903556]     Ответить | Цитировать Сообщить модератору
 Re: А вот мне интересно - Оракл объектная СУБД или нет?  [new]
ЧАЛ
Guest
Связь

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

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

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

Накладная -- Содержит/Входит в -> Операция отгрузки
Операция отгрузки <- Относится к/Имеет -- Товар

(извините, что немного изменил семантику).
23 сен 05, 00:56    [1903575]     Ответить | Цитировать Сообщить модератору
 Re: А вот мне интересно - Оракл объектная СУБД или нет?  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
автор
(извините, что немного изменил семантику).


т.е. переставил часть букф ???
23 сен 05, 08:23    [1903741]     Ответить | Цитировать Сообщить модератору
 Re: А вот мне интересно - Оракл объектная СУБД или нет?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ЧАЛ

А я останусь НА ТОМ ЖЕ УРОВНЕ абстракции.
навигации и семантики на уровне БД

Он останется на одном уровне абстракции с навигацией, т.е. циклами, ссылками, индексами и проч "семантикой". Пусть остается, если ему так нравится.
23 сен 05, 10:52    [1904263]     Ответить | Цитировать Сообщить модератору
 Re: А вот мне интересно - Оракл объектная СУБД или нет?  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Сорру, опечатка:
автор
OK. Вашего пример ничем не хуже, ну раз уж подробно расписаны бизнес-правила про накладные, то проще их и обсуждать.

следует читать
OK. Ваш пример ничем не хуже, ну раз уж подробно расписаны бизнес-правила про накладные, то проще их и обсуждать.
23 сен 05, 12:03    [1904707]     Ответить | Цитировать Сообщить модератору
 Re: А вот мне интересно - Оракл объектная СУБД или нет?  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
ЧАЛ
Связь

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

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

Каждая Накладная может Отгружать один или более Товар.
Каждый Товар может Отгружаться_в одной или более Накладная.

или

Накладная <-- Отгружать/Отгружаться_в -->Товар

Чем здесь является Отгружать/Отгружаться_в ? Конечно связью, но поскольку она типа M:M, то она должна быть декомпозирована и представлена в пределах концептуального моделирования сущностью. Вот про нее я и говорю : СтрокаНакладной исходного примера или по-вашему ОперацияОтгрузки - это сущность-связь, декомпозиция связи Отгружать/Отгружаться_в предшествующего уровня абстракции. Для простоты будем далее использовать только имя ОперацияОтгрузки. В результате декомпозиции мы получили новую сущность ОперацияОтгрузки и две новых связи. Эти связи в некотором смысле простые, их дальнейшая декомпозиция не имеет смысла, процесс окончен.

Уфф...
Я такими мелкими шагами не с целью запутать, а как раз обратной.

Про симметрию.

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

Простые же связи

Накладная -- Содержит/Входит в -> Операция отгрузки
Операция отгрузки <- Относится к/Имеет -- Товар

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

Вопрос. Какой симметрии и как и для чего можно достигнуть в этих связях?
23 сен 05, 13:37    [1905240]     Ответить | Цитировать Сообщить модератору
 Re: А вот мне интересно - Оракл объектная СУБД или нет?  [new]
ЧАЛ
Guest
Это мы уже обсуждали с исчезнувшим вместе с "процессорной инициативой" "дураг с инецеативой". Операция отгрузки - это объект, а не связь. Произошла именно отгрузка, а не "товарная накладная". Так что, если уж убирать объект, так "накладную", останется

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

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

Про недостатки "вариантов ООСУБД" я четко сказал, и про каждый конкретный вариант, и в целом - уже наличие вариантов - это плохо, так как это означает, что не хватает концепций.
В связи с этим полезно вернуться к сообщению 882900 в теме "Сравнение ... СУБД", и реакции U-gene 882983. Наверное U-gene понял "что побуждает [меня] все это говорить", когда мы дошли до обсуждения НРМ. Но и до этого я неоднократно подчеркивал, что ОМД на принципах ООП не несет ничего нового, и что "денормализация" путем "встраивания" объектов бесполезна. Упоминал часто встречающийся в литературе по "объектным свойствам" Oracle пример с объектным типом "Адрес" и т.п. Думаю невозможно найти ни одного примера полезности встраивания. Утрата симметрии, и ничего взамен...

Насчет "глупости итератора" не согласен. Действительно связь можно интегрировать в объект, использую ссылочный тип характеристики объекта. Но я уже говорил, что возражаю против этого. Если собственный идентификатор - это не характеристика объекта, то зачем делать характеристикой "чужой" идентификатор. "Итератор" замечательно возьмет первый и единственный экземпляр (примеры операторов я уже приводил). Симметричная поддержка связи во всех отношениях лучше необходимости индексирования ссылки...
23 сен 05, 22:40    [1907087]     Ответить | Цитировать Сообщить модератору
 Re: А вот мне интересно - Оракл объектная СУБД или нет?  [new]
ЧАЛ
Guest
Продолжаю ощущать, что Вы, ModelR, не умышленно наверное, запутываете. Целый день думал зачем же Вы рассматривали Ваш пример "с конца". И зачем было потом его рассматривать "с начала". Так и не придумал. Ну "с начала", так "с начала". Итак, "представление заказчика":

Накладная <- Содержит/Содержится в -> Товар

Если дальнейший анализ покажет, что:

- отгрузка по накладной делается с одного склада и от одного МОЛа;
- в одно транспортное средство;
- не нужно поддерживать партионный учет;
- не нужно поддерживать бухгалтерский учет (вот эти проводкИ сделаны по этой ОПЕРАЦИИ);
- не нужно поддерживать корректировки ОПЕРАЦИЙ в "закрытых" документах;
- и т.д.

то я сохраню это "представление заказчика". Зачем же БЕСЦЕЛЬНО нервировать заказчика ? Он будет видеть данные (даже без всяких приложений) именно в этом виде.

А Вы зачем отказались от этой схемы ? Только из-за того, что в РМД (и в ОМД на принципах ООП) не поддерживаются связи многие-ко-многим ?
Но ведь об этом хорошо известно. Что Вы хотите для себя понять ?
РМД, хоть и не была реализована, "привела" к утрате идентификации, навигации и семантики, без которых БД теряют и эффективность и привлекательность (так как отгорожены от пользователя бесполезными "приложениями"). Сейчас это пытаются "поправить", пока безуспешно, с помощью "ООП над РБД". Все так просто, по моему, и очевидно.
Или есть что-то весьма сложное, чего я не вижу ?
24 сен 05, 17:25    [1907397]     Ответить | Цитировать Сообщить модератору
 Re: А вот мне интересно - Оракл объектная СУБД или нет?  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
ЧАЛ

Целый день думал

Када знаний нет, то можно думать без всякой пользы и 30 лет, а не тока один день.

ЧАЛ

Так и не придумал.

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


ЧАЛ

БД теряют и эффективность и привлекательность (так как отгорожены от пользователя бесполезными "приложениями").

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

Раньше сам придумывал недостатки РМД. Получалось слишком смешно. Решил брать из литры, и сам "развивать". Опять смешная отсебятина получается, но балабаноских со спичечной фабрики мож и проще так одурачить и развести на поддержку. Особенно термины "навигация" и "семантика" рядом хорошо смотрятся.

ЧАЛ

Сейчас это пытаются "поправить", пока безуспешно, с помощью "ООП над РБД".

Видимо сожаление о том, что на дореляционную ОМД совсем забили, и уже ничего не пытаются - ей ничем помочь нельзя уже лет 30.

ЧАЛ

Все так просто, по моему, и очевидно.
Или есть что-то весьма сложное, чего я не вижу ?

Можно подумать, что достаточно простые, известные на третьем курсе факты коллега ЧАЛ когда-нибудь видел. С его то дореляционным кругозором. А он о сложном уже беспокоится.
24 сен 05, 20:14    [1907456]     Ответить | Цитировать Сообщить модератору
 Re: А вот мне интересно - Оракл объектная СУБД или нет?  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
ЧАЛ
Продолжаю ощущать, что Вы, ModelR, не умышленно наверное, запутываете. Целый день думал зачем же Вы рассматривали Ваш пример "с конца". И зачем было потом его рассматривать "с начала". Так и не придумал.
Чтобы понять, какой вариант лучше и в каком случае, нужно по крайней мере их перечислить.
ЧАЛ

Ну "с начала", так "с начала". Итак, "представление заказчика":

Накладная <- Содержит/Содержится в -> Товар

Если дальнейший анализ покажет, что:

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

ЧАЛ

- не нужно поддерживать корректировки ОПЕРАЦИЙ в "закрытых" документах;
- и т.д.
Про корректировку не понял - почему корректировка требует декомпозици?
ЧАЛ

то я сохраню это "представление заказчика". Зачем же БЕСЦЕЛЬНО нервировать заказчика ? Он будет видеть данные (даже без всяких приложений) именно в этом виде.
Кроме видеть ему нужно еще и обрабатывать. Нужен язык запросов типа а сколько у меня связей в процентном отношении по стоимости? Ни товар, ни накладные не интересны. Если бы это была сущность, я бы спросил обычным путем, но это атрибутированная связь. Для нее нужны специальные конструкции запросов?
ЧАЛ


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

Откуда: Нижний Новгород
Сообщений: 1798
В любом случае проектируя БД, мы должны делать это с открытыми глазами и называть вещи своими именами. В частности, различать простые связи и связи-сущности на концептуальном уровне, видеть последствия отказа от декомпозиции.
26 сен 05, 11:54    [1909190]     Ответить | Цитировать Сообщить модератору
 Re: А вот мне интересно - Оракл объектная СУБД или нет?  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Про иденификаторы по-прежнему темно...
ЧАЛ
Действительно связь можно интегрировать в объект, использую ссылочный тип характеристики объекта. Но я уже говорил, что возражаю против этого. Если собственный идентификатор - это не характеристика объекта,
А каким образом идентификатор является собственным, если он не интегрирован? Я понимаю различие между адресом и данными, не понятно, только, почему данные об адресе нельзя рассматривать как данные:). Каковы его специальные свойства?
ЧАЛ

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

А как без индекса по идентификатору его найти? Независимость от носителя все равно нужна.
26 сен 05, 12:26    [1909390]     Ответить | Цитировать Сообщить модератору
 Re: А вот мне интересно - Оракл объектная СУБД или нет?  [new]
ЧАЛ
Guest
1. Я немного удивлен. "Тогда Вы видимо говорите, что ... СУБД должна уметь работать с такой конструкцией как Связь_имеющая_атрибуты." !?
Я говорю, что СУБД, как это и есть в ОСУБД, должна "уметь работать" со связями, и в том числе (всего лишь) со связями, "имеющими атрибуты". Разве это не очевидно ? Почему Вы говорите "Тогда Вы видимо ..." ?

2. Потому что корректировки именно операции, и их может быть много. И это не корректировки товара или накладной, а корректировки именно операции отгрузки. Частности, конечно, но, мне кажется, тоже очевидные.

3. Очевидно, что если есть концепции "объект", "характеристика объекта", "связь", "характеристика связи", то нужны "специальные конструкции". Но что в них специального ? Я же говорил, что результатом запроса (в любой СУБД) должна быть подсхема схемы БД. Так что ничего удивительного и "специального" нет.

4. Вы очень хорошо сказали про "если однажды окажется" ! А если однажды окажется, что связь многие-ко-многим, а не один-ко-многим ? Это я про связи, которые Вы представляете "с помощью ограничений целостности". Тогда что ? Пожалуйста, перечитайте последний абзац пункта "Связи" главы 14 (изд. 8-е, стр. 539) или главы 13 (изд. 7-е, стр. 513) у Дейта. Плохо, что связи, которые реально есть, не поддерживаются явно в "Р"СУБД, ООСУБД и ОРСУБД.

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

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

7. Идентификаторы не являются характеристиками объекта. Мы это уже, вроде, обсудили. Это и в ООСУБД так. Но не в ОРСУБД, гже "идентификаторы" "спрятаны" в той же таблице, где и "остальные" атрибуты "отношения".
Я уже совсем не понимаю, что Вы не понимаете с идентификаторами.

8. Нет никаких индексов по идентификаторам. Я же уже много раз объяснял про навигацию по привязанным экземплярам и т.п. См. так же сообщение 1916091 в теме "РМД пора на пенсию".
27 сен 05, 23:54    [1916162]     Ответить | Цитировать Сообщить модератору
 Re: А вот мне интересно - Оракл объектная СУБД или нет?  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
ЧАЛ
1. Я немного удивлен. "Тогда Вы видимо говорите, что ... СУБД должна уметь работать с такой конструкцией как Связь_имеющая_атрибуты." !?
Я говорю, что СУБД, как это и есть в ОСУБД, должна "уметь работать" со связями, и в том числе (всего лишь) со связями, "имеющими атрибуты". Разве это не очевидно ? Почему Вы говорите "Тогда Вы видимо ..." ?
Потому что не было написано явно. ОК, ясно.
ЧАЛ


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


3. Очевидно, что если есть концепции "объект", "характеристика объекта", "связь", "характеристика связи", то нужны "специальные конструкции". Но что в них специального ? Я же говорил, что результатом запроса (в любой СУБД) должна быть подсхема схемы БД. Так что ничего удивительного и "специального" нет.

4. Вы очень хорошо сказали про "если однажды окажется" ! А если однажды окажется, что связь многие-ко-многим, а не один-ко-многим ? Это я про связи, которые Вы представляете "с помощью ограничений целостности". Тогда что ?
Будет плохо. Если есть подозрение, что связь может оказаться M:M, следует сразу ее делать таковой - сущностью-связью. Однако реально есть связи типа M:1, например Адрес -> Страна. Для них плодить лишние сущности было бы ошибкой.
ЧАЛ


Пожалуйста, перечитайте последний абзац пункта "Связи" главы 14 (изд. 8-е, стр. 539) или главы 13 (изд. 7-е, стр. 513) у Дейта. Плохо, что связи, которые реально есть, не поддерживаются явно в "Р"СУБД, ООСУБД и ОРСУБД
Они поддерживаются. Способы поддержки другие. Понятно, что для предлагаемого универсального навигатора нужно явное объявление связей, которого нет в описании отношений. Но даже если задаться задачей создания такого навигатора, можно генерировать их примерно как ERWin генерирует связи при реинжениринге SQL базы.
ЧАЛ


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

6. Про "открытые глаза" трудно не согласиться. Я бы хотел, напомню, чтобы концептуальная модель стала бы и логической, и чтобы между пользователем и данными не было бы никаких приложений, кроме универсального объектного навигатора.
Для каких-то задач вещь полезная. Типа ввода и просмотра данных без больших наворотов. Но заменить ею расчет зарплаты.... ???
ЧАЛ


7. Идентификаторы не являются характеристиками объекта. Мы это уже, вроде, обсудили. Это и в ООСУБД так. Но не в ОРСУБД, гже "идентификаторы" "спрятаны" в той же таблице, где и "остальные" атрибуты "отношения".
Я уже совсем не понимаю, что Вы не понимаете с идентификаторами.

8. Нет никаких индексов по идентификаторам. Я же уже много раз объяснял про навигацию по привязанным экземплярам и т.п. См. так же сообщение 1916091 в теме "РМД пора на пенсию".

С навигацией все ясно.
Про идентификаторы было бы яснее, если бы вы рассказали, как взаимодействовать двум вашим ОМД, изначально созданным независимо.
Как написать, и при необходимости исправить информацию о том, что страна, которая у наc имеет идентификатор '1' у них имеет иденификатор 'F', ой нет 'Z'.
Это изменение идентификатора, или чужой идентификатор -не идентификатор?
Еще. Если в нашей БД иденификаторы - числа, то семантически эквивалентна ли ей БД, в которой все идентификаторы равны исходным плюс единица?

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

Я не говорю, что ОМД бесполезна, просто пытаюсь понять их соотношение.
28 сен 05, 11:25    [1917214]     Ответить | Цитировать Сообщить модератору
 Re: А вот мне интересно - Оракл объектная СУБД или нет?  [new]
ЧАЛ
Guest
1. "Плодить сущности" - не согласен в концептуальном плане. Это в РМД приходится плодить сущности. Но связь всегда лучше представлять как связь. Ведь в ОМД для этого ничего не нужно плодить.
Про "Адрес" лучше не говорить - слишком большое разнообразие представлений. Ведь если все нормализовать, то никакого "М:1 Адрес->Страна", конечно, не будет.

2. Про ERWin и реинжениринг SQL базы, мне кажется, тоже уже все обсудили. Собственно в ER-модели связей нет (так как это просто реляционная модель на логическом уровне), а "диаграммная техника" сама по себе не представляет интереса. С ОРМ и всевозможными надстройками над "Р"БД тоже все понятно.
В ОСУБД никаких надстроек нет.

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

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

Вы "мягкий" человек, ModelR, а я "жесткий", и говорю, что РМД именно бесполезна, и весьма тщательно это доказываю. И не думаю, что это кого-то может задеть...
28 сен 05, 23:20    [1920611]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7 8 9 10   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить