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

>Database Systems
A practical approach to desing, implementation and management

Second Edition

Thomas M. Connolly
Carolyn E. Begg


Эта книга издавалась в мае 2004 года, так что Ваши опасения что она устарела беспочвенны.

В 2000 издавалась следующая:
Database solutions : a step-by-step approach to building databases
Thomas M. Connolly, Carolyn E. Begg.
Addison-Wesley, 2000.

Они взаимозаменяемы?

Я посмотрел оглавление последней. Там все стандартное, с использованием в РСУБД. Нечто связанное с объектами, насколько можно судить по оглавлению, упоминается на 7 страницах:
11 - Advanced modeling techniques 197
11.1 - Specialization/Generalization 198
11.1.1 - Superclasses and subclasses 198
11.1.2 - Superclass/Subclass relationships 198
11.1.3 - Attribute inheritance 199
11.1.4 - Specialization process 200
11.1.5 - Generalization process 200
11.1.6 - Constraints on superclass/subclass relationships 202
11.2 - Creating tables to represent specialization/generalization 204

Остально типа:
5.5.2 - One-to-many (1:*) relationships 91
6.4 - Second normal form (2NF) 107
Step 2.4 - Define integrity constraints 175
15 - Physical database design - Step 7 267
17.1.2 - QBE (Query-By-Example) 281
8 июл 04, 07:06    [792164]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
2 c127
Я рад, что Вы так быстро нашли книгу да еще 2004 года. Но я ее не видел, поэтому ничего не могу сказать о сравнении с 2000.
c127

Я посмотрел оглавление последней. Там все стандартное, с использованием в РСУБД. Нечто связанное с объектами, насколько можно судить по оглавлению, упоминается на 7 страницах:
11 - Advanced modeling techniques 197
11.1 - Specialization/Generalization 198
11.1.1 - Superclasses and subclasses 198
11.1.2 - Superclass/Subclass relationships 198
11.1.3 - Attribute inheritance 199
11.1.4 - Specialization process 200
11.1.5 - Generalization process 200
11.1.6 - Constraints on superclass/subclass relationships 202
11.2 - Creating tables to represent specialization/generalization 204

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


c127

Остально типа:
5.5.2 - One-to-many (1:*) relationships 91
6.4 - Second normal form (2NF) 107
Step 2.4 - Define integrity constraints 175
15 - Physical database design - Step 7 267
17.1.2 - QBE (Query-By-Example) 281

Это про РМ.
8 июл 04, 23:34    [795166]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 vadiminfo

Это оглавление книги 2000 года, о ней речь. О книге 2004 года информации, кроме названия, нет.

Это та книга, которую Вы имели в виду?
Database solutions : a step-by-step approach to building databases
Thomas M. Connolly, Carolyn E. Begg.
Addison-Wesley, 2000.

Название у нее не совпадает с Вашим.

>Вам сразу вопрос: реляционная нуждается в общем случае в поддержке инфологических моделей в процессе проектирования БД, объектная, скорее всего, нет. Что Вы об этом думаете. В плане достоинств и недостатков?

По-моему Ваше утверждение в первой части неверно: любые дополнительные модели не являются необходимыми в процессе разработки реляционной БД. Они иногда бывают удобны но и то, по моему опыту, только на этапе начального обсуждения проблемы. А в принципе этап построения ER и им подобных не является необходимым. Я ни разу не работал с проектом, в котором этот этап хотя бы примерно был выдержан от начала и до конца со всеми формальностями. При этом проекты завершались успешно.

По-видимому в ООБД тоже не сразу объекты пишутся, по крайней мере те объекты, которые фигурируют на этапе постановки задачи не совпадают с теми, которые разработчик создает в БД. По крайней мере при работе с C++ ситуация выглядит так. Т.е. ООБД нуждается в этом этапе в той же мере что и РБД. Так что пока преимущества ООБД не очевидны.

А вот кто любит ER так это начальство и всякие бестолковые менеджеры: с одной стороны многое будто понятно а с другой выглядит круто, и вроде участвуешь в профессиональном обсуждении. Есть повод начать себя уважать за ум и сообразительность.
9 июл 04, 01:08    [795189]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
2 c127
Вы достали только за 2000 год?

автор

Это та книга, которую Вы имели в виду?
Database solutions : a step-by-step approach to building databases
Thomas M. Connolly, Carolyn E. Begg.
Addison-Wesley, 2000.

Название у нее не совпадает с Вашим.

Но я же не вижу отсюда то, что у Вас.
Сколько у Вашей страниц? Какие ключевые главы?
автор

По-моему Ваше утверждение в первой части неверно: любые дополнительные модели не являются необходимыми в процессе разработки реляционной БД. Они иногда бывают удобны но и то, по моему опыту, только на этапе начального обсуждения проблемы. А в принципе этап построения ER и им подобных не является необходимым. Я ни разу не работал с проектом, в котором этот этап хотя бы примерно был выдержан от начала и до конца со всеми формальностями. При этом проекты завершались успешно.

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

По-видимому, в ООБД тоже не сразу объекты пишутся, по крайней мере те объекты, которые фигурируют на этапе постановки задачи не совпадают с теми, которые разработчик создает в БД. По крайней мере при работе с C++ ситуация выглядит так. Т.е. ООБД нуждается в этом этапе в той же мере что и РБД. Так что пока преимущества ООБД не очевидны.

Нет, измените. Одно дело одна модель на разных этапах проектирования, пусть там на разных этапах и не все. Другое дело разные модели. Если кто пользуется только РМ, у него тоже на разных этапах может разное оказаться.
Я не настаиваю на этом недостатке как на критическом. Но мне интересно, что Вы думаете про это.
автор

А вот кто любит ER так это начальство и всякие бестолковые менеджеры: с одной стороны многое будто понятно а с другой выглядит круто, и вроде участвуешь в профессиональном обсуждении. Есть повод начать себя уважать за ум и сообразительность.

Сильное предположение. Даже в Access и SQL Server можно рисовать диаграммы. Конечно, это не полноценные ERD, а скорее то, что получается после ее преобразования в расчете на реляционную модель. Но все-таки.
Про менеджеров и начальство - это все-таки из области управления в общем случае не только технической стороной проекта. Уважение к себе - это из области психологии. Не моя специализация.
9 июл 04, 15:57    [797115]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
>Но я же не вижу отсюда то, что у Вас.

Как я уже говорил, у меня есть оглавление книги
Database solutions : a step-by-step approach to building databases
Thomas M. Connolly, Carolyn E. Begg.
Addison-Wesley, 2000.

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

>Это начальный этап проектирования БД, а не обсуждения. Это этап концептуального проектирования.

Хорошо, пусть это обсуждение называется проектированием. Оно не является необходимым. Более того, по моему опыту, даже в тех случаях, когда ER модель строилась тщательно, в дальнейшем проект ВСЕГДА уходил в от нее в сторону, и никого это не беспокоило, все работало, а если не работало, то совершенно по другим причинам. Вывод: можно было обойтись и без ER модели (и подобных ей), которая часто является удобным, но вовсе не обязательным этапом проектирования.

А то что этот этап упоминается во всех книгах по проектированию БД ни о чем не говорит, да и авторы вроде не утверждают, что этот этап совершенно необходим.

Мне лично ER и ей подобные не нравятся из за расплывчатости концепции. Например, говорилось уже, отношение много ко многим может выступать в роли отношения, а может - в роли сущности, в зависимости от контекста и требований заказчика, которые меняются десять раз на день. Куда его сунуть на схеме в E или в R? Самое надежное - все положить в сущности, но тогда получится как раз реляционная схема и возня с ER теряет смысл.

В РСУБД такой проблемы нет, там все едино. ИМХО нужно строить ER-подобные модели на основе множеств-отображений и проблем тоже не будет.
10 июл 04, 00:58    [798249]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

Как я уже говорил, у меня есть оглавление книги
Database solutions : a step-by-step approach to building databases
Thomas M. Connolly, Carolyn E. Begg.
Addison-Wesley, 2000.

Название я приводил. Оно отличается. Можно только сравнивать главы.
c127

Хорошо, пусть это обсуждение называется проектированием. Оно не является необходимым. Более того, по моему опыту, даже в тех случаях, когда ER модель строилась тщательно, в дальнейшем проект ВСЕГДА уходил в от нее в сторону, и никого это не беспокоило, все работало, а если не работало, то совершенно по другим причинам. Вывод: можно было обойтись и без ER модели (и подобных ей), которая часто является удобным, но вовсе не обязательным этапом проектирования.
А то что этот этап упоминается во всех книгах по проектированию БД ни о чем не говорит, да и авторы вроде не утверждают, что этот этап совершенно необходим.

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

Мне лично ER и ей подобные не нравятся из за расплывчатости концепции. Например, говорилось уже, отношение много ко многим может выступать в роли отношения, а может - в роли сущности, в зависимости от контекста и требований заказчика, которые меняются десять раз на день. Куда его сунуть на схеме в E или в R? Самое надежное - все положить в сущности, но тогда получится как раз реляционная схема и возня с ER теряет смысл.

Как это расплывчатые концепции? Наоборот. В ER нет отношений. Там есть типы сущностей и связей. И есть связи многие ко многим. И в роли отношения она выступать не может, так как в этой модели их нет. Концепция достаточно строга. И уж выразительнее в плане отображения реального мира, чем реляционная, потому что и Вашем опыте было ее применение. Но математики у нее нет, такой как у рел модели, тогда зачем пытались ее применять? В E сущности, а в R отношения. Поэтому положив в сущности Вы положили в E, а не в R. И правильно сделали. А на следующем этапе логического проектирования БД она попадет в R.

Давайте будем объективны. Не будем общепризнанные вещи типа ER куда-то задвигать. Она в тех или иных нотациях присутствует в CASE средствах. В стандартах типа IDEF1X по информационному моделированию. И т.д. Иначе мы получим совсем далекие от реального положения дел результаты.

c127

В РСУБД такой проблемы нет, там все едино. ИМХО нужно строить ER-подобные модели на основе множеств-отображений и проблем тоже не будет.

Какой проблемы нет в РСУБД? Что проектировщик не знает сущность это или связь? Это проблема проектировщика, а не модели какой бы она не была. Абстрагирование от этой разницы - лучший способ все запутать и тем снизить пользу от информации, которая в БД. Производители СУБД типа Оракла имеют дизайнеры для проектирования, которые поддерживают ER. Что значит ER подобные? Инфологические что ли? У инфологических проблем с концепциями меньше проблем, чем у даталогических. Их для того и придумывали. Речь о том, что ООМД, возможно, не нуждается в дополнительной - инфологической. Т.е. в ней уже есть и инфологическая и даталогическая, что приближает реализацию к концептуальному проектированию. Вопрос о множествах-отображениях предлагаю пока отложить. Мы на него много потратили. Замените его математическим обоснованием. Для концептуального проектирования роль математического обоснования пока не считается такой важной как для логического, там нет вычислений, получения результата и т.д.
10 июл 04, 22:49    [798628]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
>В ER нет отношений.

Ну да! А как ER расшифровывается?

>Давайте будем объективны. Не будем общепризнанные вещи типа ER куда-то задвигать.

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

Вы все время заменяете обосноваение разговорами на признинность и общепризнанность, но без ссылок на источники этой информации, но когда Вам говорят, например, что ООДБ не пользуются популярностью Вы требуете доказательсв в виде ссылок и статистики. Вот и приведите для начала статистику по реляционным БД, построенным в полном соответсвии с общепризнанными этапами построения, у которых ER схема соответствует окончательному варианту физической модели данных. Я думаю таких не найдется вообще.
11 июл 04, 00:04    [798649]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

Ну да! А как ER расшифровывается?

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

c127

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

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

c127

Вы все время заменяете обосноваение разговорами на признинность и общепризнанность, но без ссылок на источники этой информации, но когда Вам говорят, например, что ООДБ не пользуются популярностью Вы требуете доказательсв в виде ссылок и статистики. Вот и приведите для начала статистику по реляционным БД, построенным в полном соответсвии с общепризнанными этапами построения, у которых ER схема соответствует окончательному варианту физической модели данных. Я думаю таких не найдется вообще.

Ну одну ссылку я вам дал. Общепризнанность означает, что существует положительный опыт. Это серьезное обоснование. А как Вы еще можете обосновать в рамках форума. Строгих теорем тут нет. Но не пользуются популярностью - что это значит? Значит ли это, что они окончательно сошли со сцены? Объектно-ориентированное программирование пользуется популярностью. Поэтому и идея о ООМД не кажется лишенной смысла. Я не требую в доказательство пока ничего. Я спрашивал, знаете ли Вы что-то про это. Или еще кто-то может пролить свет на положение дел. В той книге, что я Вам дал, говорится о том, что пока не известно что победит ООМД или ОРМД.
Про статистику опять же из той книги: только 15% проектов из исследованных, соответствуют все критериям качества. 40% вообще не завершились. В ответ на это и был предложен структурированный подход - Жизненный цикл ИС. Там однозначно предполагается этап концептуального проектирования. Но на нем ER - Вы же против этого не возражали. Соответствие ER окончательному варианту, означает, что возвращались к этому этапу. Но не соответствие не доказывает, что от нее не было пользы.
Вы думаете, Жуков на Курской дуге все планировал до последнего приказа рядовому об ориентирах для ведения огня? Я вообще думаю, что в больших проектах проектировщикам концептуальной модели платят больше, чем проектировщикам физической.

Вот ответьте на вопрос: признаете Вы, что для концептуального проектирования лучше подходит ER, чем реляционная модель?
Вы отрицаете полезность концептуального уровня и вместе с ним ER?
Тогда надо говорить не о ER, а о значении этого этапа.
Отложить пока про ER. Иначе получается путаница.
11 июл 04, 15:31    [798799]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Уважаемые c127 и vaviminfo !
Да, книга шотландцев:

Базы данных. Проектирование, реализация и сопровождение. Теория и практика. Третье издание.
Database systems. A Practical Approach to Design, Implementation, and Management. Third Edition (так "упомянут" оригинал в русском переводе).

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

i $$g(io,ie,ih)="" d ^PRG q

если значение характеристики ih экземпляра ie объекта io не существует, то выполнить программу PRG и завершить текущую программу. Вот что такое интегрированный язык баз данных и "ужасная" ручная навигация. Я уж не говорю о фактическом слиянии концептуального и логического этапов проектирования, о чем Вы, vadiminfo, пока безуспешно пытаетесь растолковать c127.
Если Вы, с127, думаете, что при усложнении "запросов" к БД начнет проявляться польза от SQL, то Вы заблуждаетесь. Впрчем, если бы идентификация и навигация были бы возможны в реляционных системах наряду с "автоматической" навигацией, может быть и не было бы сейчас никаких споров. Но это (теоретически) невозможно. Кодд НЕ СПЕЦИАЛЬНО убрал (и так и не смог вернуть) из баз данных идентификацию, навигацию и семантику. Это все лишь плата за реляционную алгебру.
Еще раз предлагаю живой семинар. За более чем месяц обсуждения в Internet Вы не продвинулись ни на шаг...
11 июл 04, 19:21    [798869]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Извините, что в обращении написал vaviminfo, вместо vadiminfo !
11 июл 04, 19:25    [798871]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

Объектные концепции в базах данных и их реализации появились, как минимум, одновременно с записеориентированными (реляционными) концепциями, а не ПОСЛЕ них. Коммерческая "победа" записеориентированных систем- это одно. А их теоретическая и практическая ущербность - это другое.

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

Андрей Леонидович

Я уж не говорю о фактическом слиянии концептуального и логического этапов проектирования,

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

Андрей Леонидович

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

Если записеориентированная, то это однозначно предполагает навигацию. Хождение по записям и есть навигация, насколько я понимаю использование этого термина. Поэтому для реляционных термин записеориентированные вызывает вопросы. Споры были бы, так как есть проблемы связанные не только со способом извлечение информацией из записей, но и с тем, что с помощью записей, возможно, не всегда можно хорошо описывать реальный мир. Т.е. может играть роль и семантическая выразительность модели данных. Польза от SQL все-таки уже проявилась на столько, что и к ООМД предъявляются требования иметь непроцедурный язык запросов, для извлечения достаточно сложной информации.
автор

Кодд НЕ СПЕЦИАЛЬНО убрал (и так и не смог вернуть) из баз данных идентификацию, навигацию и семантику. Это все лишь плата за реляционную алгебру.

Действительно, реляционная алгебра дорого стоит. Но семантика там присутствует все-таки. Вопрос о том, что она имеет какие-то недостатки. Мы здесь говорили, например, о семантической перегрузке. Но мы увязли на вопросе о том, что играет ли роль семантика для моделей данных вообще или нет.
Андрей Леонидович

Еще раз предлагаю живой семинар. За более чем месяц обсуждения в Internet Вы не продвинулись ни на шаг...

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

Для меня то, что форум стимулирует изучение вопроса, чтение лит-ры и уяснение чего-то, хотя бы для самого себя - уже польза.
11 июл 04, 22:09    [798923]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 vadiminfo

>Но общепризнанно, что есть и недостатки, в ответ, на которые на сцену могут выйти, например, ООСУБД, ОРСУБД.

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

c127>Ну да! А как ER расшифровывается?
vadiminfo>Сущность-связь. EER - расширенная модель Сущность-Связь.


На самом деле ER расшифровывается как entity-relationship. Это переводится как сущность-отношение, для связи в английском языке есть link и connection и если бы авторы модели хотели чтоб была сущность-связь, то они бы назвали ее EL.

Я нигде не утверждал, что ER совершенно бесполезна, я утверждал что ее полезность преувеличена. Я уже говорил, ER любит начальство и менеджеры, т.е. как раз те люди, ктоторые принимают решение о поекупке продукте, так что неудивительно что оракл и M$ и пр. включили ее в свои продукты. На самом деле ИМХО полезность ER модели меньше чем кажется.

>Я не говорил, что от реляционной модели нет никакого толка. Общепризнанно, что от них есть толк.

Не может быть!

>Про статистику опять же из той книги: только 15% проектов из исследованных, соответствуют все критериям качества. 40% вообще не завершились. В ответ на это и был предложен структурированный подход - Жизненный цикл ИС. Там однозначно предполагается этап концептуального проектирования.

Из Ваших слов следует, что концептуальное проектирование не необходимо: до его появления 15% проектов завершились успешно. Это во-первых.

Во-вторых концептуальное проектирование != ER, есть другие схемы, кроме ER. Я вообще не говорил о концептуальном проектировании. Я всего-лишь навсего сказал, что те модели, о которых я читал (включая ER) мне не понравились, можно было придумать что-нибудь поприличнее.

Кстати, а сколько C++ проектов завершились неудачно? По идее должны быть примерно те же цифры. Если да, то это можно считать доказательством, что ОО не имеет преимуществ, т.е. источник проблем не в модели.

>Вот ответьте на вопрос: признаете Вы, что для концептуального проектирования лучше подходит ER, чем реляционная модель?

С точностью до того, как я понимаю ER - да, она подходит больше, чем классическая реляционная модель. Я не предлагал использовать существующую реляционну модель для концептуального проектирования, я предлагал придумать что-нибудь на тех же принципах (множества-отображения), более подходящее, чем ER, которая не очень удачна с моей точки зрения.
12 июл 04, 02:49    [799005]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Видите как долго приходится устранять довольно простые недопонимания на форуме, уважаемый vadiminfo...

1. Реализации объектных концепций появились именно в базах данных, а не в языках программирования. Где Вы видите в приведенном мной примере на языке MUMPS объектные концепции в языке программирования ?
2. Реляционные системы являются принципиально записе-ориентированными. Мне кажется Вы не ощущаете разницу между объектно-ориентированными и записе-ориентированными системами. Ключи в реляционной модели находятся среди атрибутов отношения, а идентификаторы экземпляров не являются просто одной из характеристик объекта.
3. При использовании объектной модели концептуальный и логический этапы естественным образом сливаются в один этап, а при использовании реляционной - НЕТ. Опять недопонимание.
4. c127 все время хотел рассмотреть пример. Вы предположили, что на простых примерах РСУБД выиграют. Я привел очень простой и очень распространенный (мягко говоря) пример. Жду от c127 реализации этого примера на языке баз данных какой-либо РСУБД. И объяснения почему РСУБД и SQL выигрывают в этом простом примере. Если получится, то я перехожу на сторону c127 и, я думаю, мы сможем убедить Вас, что РСУБД ВСЕГДА лучше.
12 июл 04, 14:11    [800103]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

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

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

c127

На самом деле ER расшифровывается как entity-relationship. Это переводится как сущность-отношение, для связи в английском языке есть link и connection и если бы авторы модели хотели чтоб была сущность-связь, то они бы назвали ее EL.

Я Вам привел название этой модели в русскоязычной литературе. То, что относится к букве R - тип связи - множество ассоциаций между экземплярами типов сущностей. Опять жаль, что Вы не достали еще эту книгу. Впрочем, детали этой модели не очень важны для данной темы.
c127

Из Ваших слов следует, что концептуальное проектирование не необходимо: до его появления 15% проектов завершились успешно. Это во-первых.

Безусловно, не необходимо. Но настоятельно рекомендуется.
c127

Во-вторых концептуальное проектирование != ER, есть другие схемы, кроме ER. Я вообще не говорил о концептуальном проектировании. Я всего-лишь навсего сказал, что те модели, о которых я читал (включая ER) мне не понравились, можно было придумать что-нибудь поприличнее.

Да, я говорил про инфологические модели. Значит, я неудачно выразился. Действительно, кроме ER есть и другие инфологические модели. Например, Семантическая Объектная модель. Просто ER пока наиболее распространенная. Тогда уточню вопрос, реляционная модель нуждается при проектировании в дополнительных инфологических моделях? Типа ER.
Например, на этапе концептуального проектирования.
Вопрос имеет значение в том плане, что ООМБ, возможно, не нуждается в дополнительных моделях. Все делается в плане проектирования БД, скорее всего, только с ее помощью.
Я выделил Вам основное, так как допускаю, что Вы не все читаете.

c127

Кстати, а сколько C++ проектов завершились неудачно? По идее должны быть примерно те же цифры. Если да, то это можно считать доказательством, что ОО не имеет преимуществ, т.е. источник проблем не в модели.

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

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

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

Андрей Леонидович

1. Реализации объектных концепций появились именно в базах данных, а не в языках программирования. Где Вы видите в приведенном мной примере на языке MUMPS объектные концепции в языке программирования ?

Вообще если эта реализация появилась в БД, то это хуже для ООМД. Т.е. она попадает в класс дореляционных и ,кроме того, такое долгое ее топтание на месте внушает опасения и в ее будущем. Но Ваш пример на языке MUMPS не совсем мне понятен. Мы тоже в реляционной про языки пока не говорили. Пока только про концепции. Лучше примеры про объекты, классы в плане БД. В настоящее время есть язык Пролог – непроцедурный, который можно рассматривать как некий язык баз знаний. Но о реальной реализации СУБЗ пока говорить не приходится. Мало ли что там было похожего на ООМД. Впрочем, пока вопрос об историческом аспекте не кажется существенным. Что принципиально он меняет?
Андрей Леонидович

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

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

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

Я не понимаю преимуществ сливания этапов в общем случае. Ведь это менее структурированный подход – ухудшение управлением проекта. Например, концептуальное проектирование – проектирование, абстрагированное от любых деталей реализации. Оно нужно в общем случае не зависимо от моделей данных. Другое дело если на этих этапах используется одна и та же модель данных или разные. Правда, эти разные могут быть достаточно хорошо согласованы. Например, так думают про ER и РМД.
Андрей Леонидович

c127 все время хотел рассмотреть пример. Вы предположили, что на простых примерах РСУБД выиграют. Я привел очень простой и очень распространенный (мягко говоря) пример. Жду от c127 реализации этого примера на языке баз данных какой-либо РСУБД. И объяснения почему РСУБД и SQL выигрывают в этом простом примере. Если получится, то я перехожу на сторону c127 и, я думаю, мы сможем убедить Вас, что РСУБД ВСЕГДА лучше.

Конечно, мне интересно, что ответит c127. Но я не понимаю, как Вы из одного примера выводите преимущества целой модели. Из частного общее. Ведь это выглядит как неполная индукция. На простых, а точнее традиционных приложениях (бизнес приложениях) реляционная выигрывает, не только за счет непроцедурных и эффективных языков запросов (сильное математическое обоснование), но и за счет простоты механизмов интерпретации. Например, в этих областях было традиционно использование таблиц еще до появления реляционной модели данных. Все это упрощает и проектирование, и понимание модели разными специалистами. Тем более, что в отличии ООМД эти правила одинаковы. Вы, в первый раз взглянув на схему, уже многое можете понять. Язык запросов тоже достаточно семантичен. Например, выборка – выбираете из множества экземпляров какое-то подмножество с требуемыми свойствами. Не важно, о какой конкретной БД идет речь. Это слово знают даже операторы. А вот на сложных, или назовем их специализированных, в силу самой сложности все равно понять что-то трудно. Например, если там придется строить неимоверное количество отношений, и сами они могут описывать весьма специфические факты или артефакты, то, скорее всего, преимущества реляционной модели ослабляются, а недостатки усиливаются.
13 июл 04, 00:39    [801549]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Андрей Леонидович

>Я привел очень простой и очень распространенный (мягко говоря) пример.

Где?

2 vadiminfo

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

Уже лет 20 выходят, все выйти не могут. Это как последнее 1436-е китайское предупреждение.

>Объект - уникально идентифицируемая сущность, которая содержит атрибуты, описывающие состояние объектов "реального мира", и связанные с ними действия.

Тут как минимум нужно еще определить следующие слова "сущность", "содержит", "атрибуты", "описывающие", "состояние объектов", "реальный мир", "связанные", "действия". Пока что это пока просто набор слов. Вы утверждаете что все эти слова определены в книге? Не верю. Посмотрю при возможности.

Кроме того, "объект" определяется через "состояние объекта", которое (состояние) в свою очередь, по-видимому, определяется через "объект". Если так, то ошибка.

>... реляционная модель нуждается при проектировании в дополнительных инфологических моделях?

Нет. Этих моделей не было в те годы, когда "только 15% проектов из исследованных, соответствуют все критериям качества. 40% вообще не завершились.", а 15% проектов все-таки завершались удовлетворительно. Вывод: не нуждается.

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

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

Вот я и спрашиваю: насколько успешен? Давайте сравним процент успешных/завершенных проектов в РСУБД и C++, java, smalltalk. Может оказаться что ничего в базах данных менять не нужно, ибо положение в OO мире еще хуже.

>Существенно то, что Вы подтвердили, что реляционная модель не подходит для концептуального проектирования.

Не подтверждал.

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

>Резюме: ИС, в которой используется РСУБД, нуждается в общем случае в дополнительной инфологической модели, например, ER или другой. ООБД, возможно не нуждается.

Резюме основано на ложных посылках.
13 июл 04, 02:36    [801567]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

Тут как минимум нужно еще определить следующие слова "сущность", "содержит", "атрибуты", "описывающие", "состояние объектов", "реальный мир", "связанные", "действия". Пока что это пока просто набор слов. Вы утверждаете что все эти слова определены в книге? Не верю. Посмотрю при возможности.

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

Кроме того, "объект" определяется через "состояние объекта", которое (состояние) в свою очередь, по-видимому, определяется через "объект". Если так, то ошибка.

Термин Объект для структурирования данных в модели и термин объект "реального мира" - разные вещи. Здесь многозначность языка, против которой Вы не возражали. Или теперь возражаете?
c127


Нет. Этих моделей не было в те годы, когда "только 15% проектов из исследованных, соответствуют все критериям качества. 40% вообще не завершились.", а 15% проектов все-таки завершались удовлетворительно. Вывод: не нуждается.


Модель ER Чена - 1976 год. Как понимать слово нуждается.
Вот Ваши слова:
ER - да, она подходит больше, чем классическая реляционная модель. Я не предлагал использовать существующую реляционну модель для концептуального проектирования
Не нуждается - если она подходит больше чем, ER, иначе нуждается. Не нуждается, если Вы ее предлагаете использовать.
c127

Вот я и спрашиваю: насколько успешен?

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

Но отсюда не следует, что какая-то слегка обобщенная реляционная модель не подходит для концептуального проектирвания.

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

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

Я все время говорю, что она подходит для бизнес приложений. Вы не все читаете. Где же Ваше требования к точности? Не адекватна для тех приложений, что мы уже обсуждали. Там я ее не приенял еще.
c127

Резюме основано на ложных посылках.

Т.е. Вы рекомендуете в общем случае что? Избегать этапов концептуального проектирования. А если не получится, то применять реляционную модель? А если не понравится - слегка обобщить ее? Т.е. заняться вопросами разработки моделей данных. Т.е. возможно более сложной задачей, чем сам проект? В какой этап это включить? Я бы не подписал такой план проектирования БД. Но, может, есть более храбрые парни, чем я.
Вы хотите что-то выяснить про эти три типа СУБД? Или хотите формально доказать что-то? Или чтобы кто-то доказал что-то формально, а если не докажет, то значит это доказательство правильности Ваших утверждений?. Сразу говорю, что никто ничего не докажет формально, так сам предмет дискуссии не формальный. Но это ничего не доказывает и в пользу противоположных утверждений. Но тем ни менее эти три СУБД как-то не формально соотносятся, и это имеет значение. Для меня, по крайней мере.
13 июл 04, 11:14    [802114]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Просто мучения какие-то. Давайте встретимся и не останется никаких непониманий. Останутся только ОБЪЕКТИВНЫЕ проблемы баз данных. Конечно, они сложные...

1. Реализации появилась именно в БД. И теперь Вы об этом знаете. Уже хорошо !
Это хуже для ООМД ? Не буду спорить хуже, так хуже.
Попала в класс дореляционных ? Даже не спрашиваю автора классификации. Пусть так.
Долгое топтание на месте ? Учтем. Будем активнее развивать ООМД.
Исторический аспект важен. Так как связан с важными знаниями, которые, к сожалению, могут утрачиваться (см. п.2).
2. Ключи НАХОДЯТСЯ (будьте внимательны, хотя прекрасно понимаю, что при такой форме общения - это сложно) среди атрибутов отношения, В ЗАПИСИ. Поэтому реляционная модель является записе-ориентированной (внимательно просмотрите гл. 2 третьего издания книги, которую Вы сами же приводили в пример), и навигация в ней принципиально невозможна.
3. Концептуальное и логическое проектирование. Я был небрежен в этой части. Вы высказываетесь убедительно, и я с Вами соглашаюсь.
4. Объектная модель выигрывает на традиционных приложениях не только за счет возможности навигации, но и за счет простоты механизмов интерпретации ! Может быть не будем ждать реализации моего примера от c127 ? Вам же нетрудно самому написать несколько символов. В ТРАДИЦИОННОМ приложении есть объект с идентификатором io (отношение с именем io). У него есть характеристика с идентификатором ih (атрибут с именем ih). И в нем есть экземпляр с идентификатором ie (прямая аналогия невозможна по, теперь я надеюсь, понятным Вам причинам). И где-то в коде приложения нужно

i $$g(io,ie,ih)="" d ^PRG q

В чем проблема ? Почему нельзя написать код на языке баз данных РСУБД ?
13 июл 04, 11:51    [802278]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
c127
Guest
2 Андрей Леонидович
>Может быть не будем ждать реализации моего примера от c127 ?

Еще раз: где этот знаменитый пример?

Если вдруг "очень простой и очень распространенный (мягко говоря) пример" это: "i $$g(io,ie,ih)="" d ^PRG q"

то его аналогом будет "select * from x". Либо insert, либо update - что больше нравится.

27 символов в OO против 16 в SQL, раз уж так неймется.

2 vadiminfo

>в Вашей любимой теории множества "произвольная совокупность объектов", "принадлежность" и "равенство" не определяемые понятия

Их 3 или около того на всю теорию множеств и об их наличии говорится явно. В Вашем определении состоящем из 17 слов считая предлоги "в", "с" неопределенных терминов - 8, и они по-видимому нигде ни раньше ни позже в книге не определены. Почувствуйте разницу. (C)

>Термин Объект для структурирования данных в модели и термин объект "реального мира" - разные вещи.

Они не могут быть разными или одинаковыми, поскольку они не определены.

>Как понимать слово нуждается.

Так же как слово "необходимо". "Подходит больше чем" синонимом "нуждается" не является.

Цитируйте полностью, не будет вопросов. Вот цитата: "Я не предлагал использовать существующую реляционну модель для концептуального проектирования, я предлагал придумать что-нибудь на тех же принципах (множества-отображения), более подходящее, чем ER, которая не очень удачна с моей точки зрения."

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

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

Следующий момент: интересно узнать насколько изменилась ситуация а РСУБД после введения этапов проектирования, ER и пр?

Следующий момент: интересно узнать процент проектов РБД, в которых этапы проектирования были полностью соблюдены?

И сразу многие вопросы исчезнут.

>А от меня хотите формальных определений общих понятий.

Не хочу я от ВАС формальных определений. Приведеите ссылки на доступные источники, этого будет достаточно. Более того, достаточно просто знать, что эти определения есть в природе. Но их по-видимому нет.

После того, как Вы сказали, что модель формализовать не нужно (не неоходимо) я отношусь к разговору как трепу, так что не судите строго. Я же Вас сразу предупредил, что необходимость формализации не обсуждается.

c127>Резюме основано на ложных посылках.
vadiminfo> Т.е. Вы рекомендуете в общем случае что? Избегать этапов концептуального проектирования.


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

А в общем случае - зависит от случая. Например, специально для внимательно читающих могу повторить еще раз: "...придумать что-нибудь на тех же принципах (множества-отображения), более подходящее, чем ER".
13 июл 04, 22:21    [804502]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Видите, что такое форум, vadiminfo ?

"Если значение атрибута ih "кортежа" ie отношения io не существует, то выполнить программу PRG, и завершить выполнение текущей программы" на языке баз данных РСУБД выглядит так

select * from x

и ведь не знаю как возразить...

Почему люди так бояться обнаружить, что РСУБД и SQL бесполезны для "простых" задач ("запросов") ? Ведь потом мы бы начали двигаться к более сложным запросам. И при этом, уверяю Вас, шансы SQL оказаться полезным возрастали бы.
13 июл 04, 23:01    [804551]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
"Если значение атрибута ih "кортежа" ie отношения io не существует, то выполнить программу PRG, и завершить выполнение текущей программы" на языке баз данных РСУБД выглядит так

select * from x

и ведь не знаю как возразить...

Давайте не будем придираться, не все понимают "птичий" язык сокращений. Пусть будет так:
IF NOT EXISTS(SELECT * FROM x WHERE ...)
THEN
  CALL PRG ();
  RETURN;
END IF;
Если Вы считаете, что Ваш вариант "i $$g(io,ie,ih)="" d ^PRG q" лучше, то значит так Вы и считаете, но это не означает, что он действительно лучше. Давайте лучше "взрослые" примеры приведем, например нужно сделать выборку для отделений (dep_id) 100 и 200 для штатов (state) 'CA', 'UT', 'NY', 'AZ' заказов всех покупателей (emp_lname) с перечислением даты заказа (start_date), суммы заказа (salary) и нарастающего итога по суммам заказов для каждого отделения отдельно согласно сортировке по датам заказов:
SELECT dept_id, emp_lname, start_date, salary,
  SUM(salary) OVER (PARTITION BY dept_id
    ORDER BY start_date
    RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) AS "Sum_Salary"
FROM employee
WHERE state IN ('CA', 'UT', 'NY', 'AZ') AND dept_id IN ('100', '200')
ORDER BY dept_id, start_date;
Вот так вот просто - одним запросом решается вполне реальная задача :) Интересно посмотреть на Ваше решение с малым кол-вом буковок (только с расшифровкой пожалуйста на человеческий язык).

автор
Почему люди так бояться обнаружить, что РСУБД и SQL бесполезны для "простых" задач ("запросов") ?

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

А это собственно говоря результат приведенного запроса:

К сообщению приложен файл. Размер - 0Kb
13 июл 04, 23:42    [804604]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Andreww
Member [заблокирован]

Откуда:
Сообщений: 1752
2 c127


>Еще раз: где этот знаменитый пример?

>Если вдруг "очень простой и очень распространенный (мягко говоря) пример" это: "i $$g(io,ie,ih)="" d ^PRG q"

>то его аналогом будет "select * from x". Либо insert, либо update - что больше нравится.

>27 символов в OO против 16 в SQL, раз уж так неймется.


Это вы от коллеги ЧАЛ-а хотите пример получить ?

Не стоит тратить время. Даже если после пары страниц вам удастся получить внятную формулировку этого самого примера (в чём я лично очень сильно сомневаюсь) и вы продемонстрируйте его решение на "непригодном для данных" SQL

Вам покажут очередную козявку в стиле o$k$h%%^#$@_PROGR = h(iu,ia,io) и выяснится, что вы не так всё поняли.

Коллеге ЧАЛ-у показали в чём кривь в его "статье", и почему её (писульку) не стоит воспринимать серьёзно, не смотря на десятилетия кропотливых исследований, а он через пару страниц продолжает как ни в чём ни бывало приглащать всех на семинар



>>Термин Объект для структурирования данных в модели и термин объект "реального мира" - разные вещи.

>Они не могут быть разными или одинаковыми, поскольку они не определены.


Ну если принять предложение о необязательности формализации модели, терминами (определениями) можно вообще пренебречь или оставлять их размкнутыми в стиле коллеги ЧАЛ-а (Объёкт - всё что противостиоит субъекту .... :)) )

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


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

>Вот и приведите статистику об успешных проектах на OO языках. Мы ее сравним с приведенной статистикой по РСУБД и оценим, насколько OO подход успешнее чем реляционный. Эта просьба повторяется в третий раз, а Вы все уводите в сторону.

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

Первое место прочно держал COBOL (!), второе и третье почти одинаково держали FORTRAN и C, С++ находился в первой восьмёрке помню точно.


>Следующий момент: интересно узнать процент проектов РБД, в которых этапы проектирования были полностью соблюдены?

Где соблюдены полностью,таких наверное нет или это каке-нибудь образцово-показательно-учебные проекты.


>После того, как Вы сказали, что модель формализовать не нужно (не неоходимо) я отношусь к разговору как трепу, так что не судите строго. Я же Вас сразу предупредил, что необходимость формализации не обсуждается.

Если есть какие-то сомнения в необходимости формализации модели, только и остаётся что относиться как к трёпу.

Ээээх, а какой был топик .....
13 июл 04, 23:57    [804621]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

Просто мучения какие-то. Давайте встретимся и не останется никаких непониманий. Останутся только ОБЪЕКТИВНЫЕ проблемы баз данных. Конечно, они сложные...

Не думаю, что у меня в голове есть хорошо структурированные знания, чтобы что-то прояснить во время семинара в такой сложной теме. Форум дает возможность подумать над ответами и заглянуть в литературу. Кроме того, посмотрите из какого я города, и график у меня тяжелый. А форум мне нравится еще и тем, что я здесь много узнаю в разных аспектах технологий БД.
Андрей Леонидович

Реализации появилась именно в БД.

Пока из той книги я вижу, что раньше 1983 года о таких БД не удается в принципе ничего сказать. Т.е. в 1966 появился язык Simula, но объектно-ориентированное программирование стало восприниматься как новая парадигма в 1983. А определения ООМД - 1989 год гл.22 Или мы о разном говорим?
Андрей Леонидович

Попала в класс дореляционных ? Даже не спрашиваю автора классификации.

Про автора не скажу, но термин используется, например, все в той же книге (Второе издание)
стр.819
Недостатки
В подразделе
Отсутствие универсальной модели данных.
Сразу вопрос: "Вы признает, что существует эпоха реляционных БД в инфотехнологиях или нет?"
Андрей Леонидович

Ключи НАХОДЯТСЯ (будьте внимательны, хотя прекрасно понимаю, что при такой форме общения - это сложно) среди атрибутов отношения, В ЗАПИСИ. Поэтому реляционная модель является записе-ориентированной (внимательно просмотрите гл. 2 третьего издания книги, которую Вы сами же приводили в пример), и навигация в ней принципиально невозможна.

Гл.2 Просмотрел. Но у меня издание второе. Про ключи не нашел. Но классификацию моделей на объектные и основанные на записях нашел. Ну что ж, спасибо, что напомнили. Такая классификация интересна (автор не указан). Однако, термина записе-ориентированные не нашел. Он есть в третьем издании? Более того, объектно-ориентированные наряду с ER включены в объектные. Т.е. уже как минимум это не деление моделей на объектно-ориентированные и записе-ориентированные. В иерархических и сетевых, как я говорил, для структурирования данных используется тип записи, но в реляционной - отношение. В первых двух навигация, а в последней ее нет. Поэтому не просто отнести РМД к моделям, основанным на записях. Но потому признаку, что там используются – присутствие записей с полями в реализации, наверное можно. Но про термин записе-ориентированные все же пока недопонимаю.

Андрей Леонидович

Объектная модель выигрывает на традиционных приложениях не только за счет возможности навигации, но и за счет простоты механизмов интерпретации ! Может быть не будем ждать реализации моего примера от c127 ? Вам же нетрудно самому написать несколько символов. В ТРАДИЦИОННОМ приложении есть объект с идентификатором io (отношение с именем io). У него есть характеристика с идентификатором ih (атрибут с именем ih). И в нем есть экземпляр с идентификатором ie (прямая аналогия невозможна по, теперь я надеюсь, понятным Вам причинам). И где-то в коде приложения нужно

i $$g(io,ie,ih)="" d ^PRG q

В чем проблема ? Почему нельзя написать код на языке баз данных РСУБД ?

Польза от навигации благодаря РМД мне не так очевидна.
Простота механизмов интерпретации и их привязанность к модели - это как раз достоинство РМД для таких приложений. Я приводил пример о таблицах и их привычности в данных областях.
Отношение сопоставляется не объекту, а множеству объектов. А объекту - кортеж. Я пока понял, что io – имя отношения, ih -имя атрибута, ie - значение атрибута.
Что означает i $$g(io,ie,ih)="" d ^PRG q я не понимаю. Скажите словами - что требуется?
Про то, что существуют запросы, невыразимые в реляционной алгебре, мы с c127 обсуждали.
Это один из недостатков. Но имеет значение - насколько он критичен.
Нет оснований считать его критичным во многих случаях, исходя из успешности РМД в бизнес приложениях. Вообще же речь шла о том, что есть недостатки и достоинства у РСУБД, ООСУБД и ОРСУБД, Об их общей оценке с учетом, что в разных типах приложений значение недостатков и достоинств может сильно отличаться. Например, в традиционных приложениях недостатки РМД часто не очень ощутимы, зато достоинства существенны. Это факт, имеющий практическое подтверждение - успешность многих проектов.
Поэтому, если чего-то и нельзя с помощью языка БД, например, SQL - это еще не значит, что РСУБД проиграла. Сила SQL в непроцедурности. А в конкретных приложениях он может все-таки очень много. Но СУБД имеют и процедурные языки, которые все равно позволят получить результаты, если SQL недостаточно, в том числе функции могут вызываться в SQL запросах. Поэтому Вы уточните, что i $$g(io,ie,ih)="" d ^PRG - это что-то непроцедурное, чего не может SQL. Но может язык баз данных ООСУБД. Однако придется еще и углубиться в ООМД, и описать в терминах этой модели. И что это за язык? Я говорил, например, про непроцедурный язык Пролог. Он тоже кое-что может. Но этого пока мало для СУБЗ.
И еще надо будет понять насколько и в каких типах приложений это существенно.
Тем более, что есть парни, которые все что важно и часто нужно включают и в стандарты SQL, а производители в диалекты SQL своих СУБД.
13 июл 04, 23:59    [804623]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
Ваш взрослый пример представляет собой обычный нерегламентированный запрос, который пользователи ООСУБД создают без программирования. Зачем же я буду писать программу, если ее можно не писать ? Вчера был на одном предприятии, беседовали с сотрудницей транспортно-складского хозяйства, она себе создала более 50 значительно более сложных запросов. Причем оптимизатор ООСУБД использует наиболее эффективные алгоритмы... и т.д.

Так что вернемся к детскому примеру.
"Если значение атрибута ih "кортежа" ie отношения io не существует, то выполнить программу PRG, и завершить выполнение текущей программы" (так на РУССКОМ, а не птичьем языке изначально звучал этот пример) по гипотезе ASCRUS выглядит так

IF NOT EXISTS (SELECT * FROM x WHERE ...)
THEN
CALL PRG() ;
RETURN;
END IF;

Я пока не говорю, что это хуже. Я дождусь:

1) когда кто-то наконец-то напишет правильный код;
2) когда кто-то расскажет про оптимизацию этого запроса;
3) когда даже ASCRUS признает, что SQL не просто бесполезен, но вреден в этом примере.

И мы спокойно двинемся дальше...
14 июл 04, 00:24    [804637]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
Андрей Леонидович
Guest
1. Я признаю, что существует эпоха РСУБД. Безусловно. Но это не мешает мне считать их бесполезными.
2. 25 лет назад сравнивали "объектно-ориентированные" и "записе-ориентированные" системы. Я ничего не имею против молодежной моды (терминологии). Если сейчас модно сравнивать "системы, основанные на объектах" и "системы, основанные на записях", я не против.
3. ie - это идентификатор экземпляра. $$g(io,ie,ih) возвращает значение характеристики ih экземпляра ie объекта io.
4. Насколько существенно чтение значения конкретного атрибута, конкретного кортежа конкретного отношения ? По моим данным это один из самых распространенных запросов в типичных приложениях.
14 июл 04, 00:42    [804646]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение объектно-ориентированных, реляционных и объектно-реляционных СУБД .  [new]
vadiminfo
Member

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

Их 3 или около того на всю теорию множеств и об их наличии говорится явно. В Вашем определении состоящем из 17 слов считая предлоги "в", "с" неопределенных терминов - 8, и они по-видимому нигде ни раньше ни позже в книге не определены. Почувствуйте разницу. (C)

Определение, к сожалению, не мое. Kim, 1991. А я бы не против, чтоб мое определение приводили в солидных книгах.
Арифметический подход ничего не меняет. Есть интуитивно ясные вещи.
c127

Цитируйте полностью, не будет вопросов. Вот цитата: "Я не предлагал использовать существующую реляционну модель для концептуального проектирования, я предлагал придумать что-нибудь на тех же принципах (множества-отображения), более подходящее, чем ER, которая не очень удачна с моей точки зрения."

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

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

Некорректное сравнение. Ничего не даст. Разные проблемные области. Но продуктов где так или иначе применялись ОО программирование много, в том числе на стороне клиента для РСУБД в моей конторе. Да и есть разные типы приложений. Вы, намерено, это упускаете из виду? В разных типах может быть разное их соотношение. Бизнес приложений наверняка больше. Там РСУБД господствуют пока. Вообще пока их инстоляций более 90%. Но некторые называют себя уже ОРСУБД. Например, Оракл - 36%.
c127

Следующий момент: интересно узнать насколько изменилась ситуация а РСУБД после введения этапов проектирования, ER и пр?

Если бы ER ничего не давал, им бы не занимались. А ведь он применяется именно в проектах с РСУБД в основном.
Врочем, пока можно ER заменить на ту, которую нужно придумать.
Полно CASE средств с ним. Но есть и UML - это уже в сторону ОО или вообще всего в конечном счете. Т.е. он может и ER включит или что-то для реляционных. Как видите уже придумали.

c127

Следующий момент: интересно узнать процент проектов РБД, в которых этапы проектирования были полностью соблюдены?

Ну пусть не полностью. Роль от тех моделей, что на них применялась утрачивается? Не полностью соблюдены = отсутствуют совсем?
Ведь вопрос в другом. О значении того, одна или несколько моделей в проекте.
Если вы хотите, доказать единство РМД в проектировании БД, вы должны раз и на всегда отвергнуть концептуальное проектирование. Или твердо сказать, что на нем всегда достаточна РМД. Иначе нет единства модели в проекте на все случаи.
c127

После того, как Вы сказали, что модель формализовать не нужно (не неоходимо) я отношусь к разговору как трепу, так что не судите строго. Я же Вас сразу предупредил, что необходимость формализации не обсуждается.

Вообще-то более точно я говорил о том, что теоретическое обоснование, в том числе и формализация, хоть и имеют значение, но не обязательно решающее. Я не против, чтобы отнести это к одному из недостатков. Но ставит ли этот недостаток крест на ООМД? Человечество очень долго не могло формализовать в математике очень многое. Лейбниц чуть ли ни сверхестественное приписывал. До появления теории множеств интуитивного оставалось достаточно много. Тем ни менее многое было придумано до ее открытия. Т.е. если и нет общепризнанной универсальной ООМД, то это не значит, что класс моделей, в которых используется принципы ОО программирования обречены на неуспех. Тем более позже вообще могут устранить этот недостаток.
Вы относитесь как к трепу, а я все равно надеюсь узнать что-то полезное.
Пусть и не много. Мне сгодится.
Для Вас необходимость формализации не обсуждается, а я менее щепетилен в этом вопросе. Для меня все что связано с СУБД обсуждаемо. Форум один из источников знаний.
Уточнили позиции.
c127

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

А в общем случае - зависит от случая. Например, специально для внимательно читающих могу повторить еще раз: "...придумать что-нибудь на тех же принципах (множества-отображения), более подходящее, чем ER".

Вот именно что не хотели сказать, а я то когда Вы спрашиваете не ссылаюсь на свое нежелание сказать. И я собирал из ваших других высказываний.
Вы ставили под сомнение концептуальное проектирование, но и отрицать его полностью отказались. Значит первое предложение резюмэ. Вы и теперь говорите о другой модели. Во второй части есть про другую модель. Пусть придуманную - там это не уточняется. Какие тут посылки ложные?
Пока не вижу.
14 июл 04, 01:42    [804666]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 14 15 16 17 18 [19] 20 21 22 23 .. 83   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить