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

Попробуйте
vadiminfo
Нарисуйте на ворде любую таблу, а потом выкиньте заголовок.

Номера столбцов останутся, их не выкинешь (и это фундаментальное св-во таблицы)
Кстати про ER. Простой пример: связанные сущности Накладная и Товар. В таком виде цена диаграммы равна 0. Преобразуем в три таблицы: Заголок накладной, Строки накладной ссылка на Товар. Это уже рабочая схема для любой СУБД. Мораль: пока не построили таблицы, МД нет.

Серьезное заблуждение:
Накладная-Имеет/Относится к->Операция отгрузки<-Использует/Использовался при-Товар
(где -> один ко многим)
Это уже рабочая схема для любой нормальной ОСУБД.
А Ваши три таблицы - это принципиально не схема):
2 июл 08, 18:13    [5878087]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод

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

Все-таки следует. Просто при переходе к таблицам они не превращаются в столбцы, а становятся связями.
Бред
Интегрированность языка баз данных намного важнее декларативности.

Принцип простой - макс декларативности, остальное как получится

Не таблиц две, а объекта (сущности) два: неужели событие отгрузки (кстати, независимо ни от какой накладной, так что связь вовсе не иерархическая) - это не объект?
Все-таки, не следует - нет в конце концов никакого свойства ("колонки таблицы").
Принцип еще проще - максимум интегрированности, остальное как получится):
2 июл 08, 18:22    [5878135]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
И почему, кстати, нечто между (заголовком) накладной и операцией отгрузки Вы назвали связью (да еще иерархической), а то же самое между операцией и товаром, почему-то, ссылкой??? Что за ссылка, ведь и то, и другое в любой "Вашей СУБД" представляются "связями между таблицами"!?
2 июл 08, 18:34    [5878210]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
Возможно, Вы считаете, что любая связь 1:М - иерархическая. Тогда связь между Товаром и (его) Операциями отгрузки тоже иерархическая. Правильно? А что это дает? Вот это прилагательное - иерархическая???
2 июл 08, 18:44    [5878265]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
Это уже рабочая схема для любой нормальной ОСУБД.
А Ваши три таблицы - это принципиально не схема):

Я же объяснял - эти таблицы - схема для ЛЮБОЙ СУБД. Т.е. выбор СУБД идет после построения схемы, а не до.
3 июл 08, 09:25    [5879404]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
Не таблиц две, а объекта (сущности) два

Мой подход (никому не навязываю) в том, что объекты, сущности, события, операции - это все остается в голове проектировщика. На бумаге строится МД в терминах таблиц и связей. Эта МД реализуется в выбранной (или навязанной) СУБД.
зы интегрированный - пустой термин, за ним ничего не стоит.
ззы связь 1:N = иерархическая связь. в сетевой МД все связи тоже иерархические, но топология сеть, в иерархической МД топология - иерархия. В РМД нет связей. Вот и вся разница.
3 июл 08, 09:36    [5879452]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
ln123
Guest
Прикольно т.е. отношение наследования в ООБД вы то же с помощью таблиц выражать будете?
Я например знаю как минимум три способа выразить наследование с помощью таблиц, так это что по вашему три разных модели данных для ООБД или модель все же одна?
Кстати а как с помощью таблиц выразить например схему для СУБД которая может поддерживать n-мерные массивы вы 3-х мерный массив то же с помощью таблицы будете представлять или возможна другая структура данных?
Кстати а таблица со столбцами t1,t2,t3 будет представлять собою ту же МД что таблица со столбцами t1,t3,t2 (смысл столбцов одинаков), просто вроде как таблицы разные (столбцы по разному упорядочены и выгладить они не одинаково будут :) ) а МД все та же осталась?
3 июл 08, 09:49    [5879506]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
_мод
Я же объяснял - эти таблицы - схема для ЛЮБОЙ СУБД. Т.е. выбор СУБД идет после построения схемы, а не до.

Но может быть это "объяснение" еще не произвело достаточно убедительное впечатление? Не все же являются поклонниками книжек типа введение в БД на DBASE в досе для начинающих 80-х. Да и, возможно, не все же готовы париться впихивая реальный мир в таблы, например, на стадии концептуального проетирования. Да и не в любой СУБД таблы могут оказаться. И таблы разные могут быть у разных СУБД. Да и причем тут объяснения? Это вроде Вы называли Вашим типа предложением.
3 июл 08, 10:03    [5879595]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
ln123
Прикольно т.е. отношение наследования в ООБД вы то же с помощью таблиц выражать будете?

No comments в виду отсутствия СУБД для этих самых ООБД
ln123
Я например знаю как минимум три способа выразить наследование с помощью таблиц

А что такое наследование и зачем его выражать с помощью таблиц
ln123

Кстати а как с помощью таблиц выразить например схему для СУБД которая может поддерживать n-мерные массивы вы 3-х мерный массив то же с помощью таблицы будете представлять или возможна другая структура данных?

Массив - это тип данных. С точки зрения СУБД - столбец таблицы.
ln123

таблицы разные (столбцы по разному упорядочены и выгладить они не одинаково будут :) ) а МД все та же осталась?

Столбцы именованы, но не упорядочены - учите матчасть.
3 июл 08, 10:31    [5879822]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
vadiminfo
Да и, возможно, не все же готовы париться впихивая реальный мир в таблы, например, на стадии концептуального проетирования.

Т.е. не все способны строить МД - согласен на все 100%
3 июл 08, 10:32    [5879835]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
vadiminfo
Member

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

Т.е. не все способны строить МД - согласен на все 100%

Да, возможно, "строить" то, что Вы понимаете под "МД" не все способны, в том смысле в каком не все способны поймать неуловимого Джона.
3 июл 08, 11:26    [5880285]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
Бред
Это уже рабочая схема для любой нормальной ОСУБД.
А Ваши три таблицы - это принципиально не схема):

Я же объяснял - эти таблицы - схема для ЛЮБОЙ СУБД. Т.е. выбор СУБД идет после построения схемы, а не до.

"Мои" три объекта, между прочим, не отличаются от "Ваших" трех таблиц. Вот у меня, как раз, схема, а Вашей схемы я пока не видел, согласитесь):
3 июл 08, 13:02    [5880986]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
Бред
Не таблиц две, а объекта (сущности) два

Мой подход (никому не навязываю) в том, что объекты, сущности, события, операции - это все остается в голове проектировщика. На бумаге строится МД в терминах таблиц и связей. Эта МД реализуется в выбранной (или навязанной) СУБД.
зы интегрированный - пустой термин, за ним ничего не стоит.
ззы связь 1:N = иерархическая связь. в сетевой МД все связи тоже иерархические, но топология сеть, в иерархической МД топология - иерархия. В РМД нет связей. Вот и вся разница.

Плохой подход - скрытие знаний от пользователя.
Рассмотрим еще раз Ваш пример подробнее.
Вы, видимо, забыли, что, исторически, "накладная" - это физический уровень вручную поддерживаемой базы данных. Рассматривать его, как концептуальный уровень при проектировании компьютерной базы данных - серьезная ошибка. Ей можно дать условное обозначение 1с (или R/3). На самом деле: есть сущности и есть события, участниками которых являются сущности (на данном, зачаточном, этапе развития моделей БД и сущности, и события рассматриваются, как "объекты"). Эти события типизируются (например, отгрузка), и их, конечно, можно группировать в макрособытия (вот формальное объяснение иерархии, раз уж Вам так необходима, неизвестно зачем, иерархия), перенося в макрособытия общие свойства событий, и группируя, таким образом, события с одинаковым значением этих свойств. Далее мы можем формировать (распечатывать, грубо говоря) различные отчеты (их принято называть "документами", и их форм может быть много) по каждому макрособытию и входящим в него событиям. Но это всего лишь отчеты, имеющие весьма косвенное отношения к проектированию БД (конечно, мы "размещаем" в макрособытиях, событиях и сущностях - участниках событий - свойства, которые правительство и международные организации "хотели" бы видеть в "документах").
Итак, приведенная мной схема не должна оставаться в голове проектировщика. С ней пользователь работает. А Ваша "технология" ничем не отличается от "реляционной": семантика данных повторно (!) генерируется на уровне приложения, а не хранится в БД.
И здесь плавно переходим к интегрированности языка БД. Программировать, собственно, уже почти ничего не нужно, тем не менее, если уж программировать, то на одном языке, а не на нескольких. На mumps можно написать приложение БД, потому что это интегрированный язык, а на SQL - нельзя. Хороша "декларативность", над которой неизбежно приходится строить "процедурность" на другом языке.
3 июл 08, 13:24    [5881164]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
Плохой подход - скрытие знаний от пользователя.

Я вас понял и считаю этот подход в общем случае неверным. Приложение для пользователя - это одно, а внутренняя модель данные+вычисления - это совсем другое, действительно скрытое от пользователя.
3 июл 08, 15:08    [5881924]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
а Вашей схемы я пока не видел, согласитесь):

Ну это просто:
Заголовок накладной <- Строки накладной -> Товар
-> связь вида N:1
3 июл 08, 15:10    [5881948]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
Бред
Плохой подход - скрытие знаний от пользователя.

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

Да нет, не поняли, пока):
Накладная - Операция отгрузки - Товар (упрощенно повторил схему)
это и концептуальная и логическая модели, и то, с чем работает пользователь. Этот подход не просто верный, а единственный верный, потому что позволяет до минимума сократить затраты на создание приложения БД при одновременном повышении качества приложения. Уверяю, что рано или поздно Вы к этому придете):
3 июл 08, 15:18    [5882019]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
Бред
а Вашей схемы я пока не видел, согласитесь):

Ну это просто:
Заголовок накладной <- Строки накладной -> Товар
-> связь вида N:1

Хорошо. Но есть один недостаток, по сравнению с "моей" схемой. Между двумя объектами (по Вашему - таблицами) может быть несколько связей, поэтому семантику связей так же нужно указывать (очень важные вопросы идентификации мы здесь не рассматриваем, просто напомню, что в "реляционных" СУБД из-за отсутсвия идентификации не поддерживаются метаданные (семантика) не только на уровне связей, но даже и на уровне объектов и их свойств, и в том числе поэтому приходится программировать, программировать и программировать даже самые пустяковые приложения).
3 июл 08, 15:27    [5882095]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
Накладная - Операция отгрузки - Товар (упрощенно повторил схему)
это и концептуальная и логическая модели

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

Старая проблема - решается в разных СУБД по разному. Мне нравится подход с синонимами таблиц - просто и наглядно.
3 июл 08, 16:46    [5882829]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
_мод
Мне нравится подход с синонимами таблиц - просто и наглядно.

А можно это поподробней? Мне чего-то не представить как синонимы могут решить проблему связей
3 июл 08, 17:01    [5882938]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
Бред
Накладная - Операция отгрузки - Товар (упрощенно повторил схему)
это и концептуальная и логическая модели

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

Старая проблема - решается в разных СУБД по разному. Мне нравится подход с синонимами таблиц - просто и наглядно.

1. Ну вот видите, а говорили, что поняли): Какая же подмена понятий??? Я просто исправил Вашу очевидную аналитическую ошибку.
Рассмотрим еще раз Ваш пример подробнее.
Вы, видимо, забыли, что, исторически, "накладная" - это физический уровень вручную поддерживаемой базы данных. Рассматривать его, как концептуальный уровень при проектировании компьютерной базы данных - серьезная ошибка. Этой ошибке можно дать условное обозначение 1с (или R/3). На самом деле: есть сущности и есть события, участниками которых являются сущности (на данном, зачаточном, этапе развития моделей БД и сущности, и события рассматриваются, как "объекты"). Эти события типизируются (например, отгрузка), и их, конечно, можно группировать в макрособытия (вот формальное объяснение иерархии, раз уж Вам так необходима, неизвестно зачем, иерархия), перенося в макрособытия общие свойства событий, и группируя, таким образом, события с одинаковым значением этих свойств. Далее мы можем формировать (распечатывать, грубо говоря) различные отчеты (их принято называть "документами", и их форм может быть много) по каждому макрособытию и входящим в него событиям. Но это всего лишь отчеты, имеющие весьма косвенное отношения к проектированию БД (конечно, мы "размещаем" в макрособытиях, событиях и сущностях - участниках событий - свойства, которые правительство и международные организации "хотели" бы видеть в "документах").
Итак, приведенная мной схема для Вашего примера (из трех взаимосвязанных объектов) не должна оставаться в голове проектировщика. С ней пользователь работает. А Ваша "технология" ничем не отличается от "реляционной": семантика данных повторно (!) генерируется на уровне приложения, а не хранится в БД.
2. Про семантику связей: никакой проблемы нет, абсолютно. В ОСУБД все совершенно естественно, как я и представил на схеме Вашего примера. В "Р"СУБД проблема неразрешима в принципе (возможно разрешить только на уровне специальной надстройки, в которой можно было бы реализовать типизацию отношений-связей). Ну а в остальном посмотрим на Ваш ответ SergSuper.
3 июл 08, 17:35    [5883171]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
SergSuper
А можно это поподробней? Мне чего-то не представить как синонимы могут решить проблему связей

Изделия <= Состав изделий
преобразуем
Изделия-куда (=Изделия) <- Состав изделий -> Изделия-что (=Изделия)
3 июл 08, 17:44    [5883237]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
недостатки иерархических
Guest
Это ничего, что я к теме топика вернусь?
Тока не кидайтесь табуретками...

http://en.wikipedia.org/wiki/Database#Hierarchical_model
http://www.tar.hu/sqlbible/sqlbible0011.html
http://wiki.answers.com/Q/What_are_the_Advantages_and_disadvantages_of_hierarchical_model

Каждая ссылка содержит немного и о недостатках.

И немного устно
недостаток, который я бы поставил в наш коллективно составленный список
Трудность модификации структуры базы, которая выражается в необходимости выгрузки/загрузки данных.
Я тут помыслил, касательно IMS это вилимо так и есть. Надо будет уточнять, но я с ходу не вижу другого способа.
Может, в других реализациях по-другому.
В RDBMS иная можификация структуры тоже потребует перезагрузки данных, но в IMS но в IMS как-бы не каждая.

С другой стороны - с момента изобретения монахом-францисканцем принципа двойной записи, в бухгалтерии принципиально ничего не изменилось. То есть применительно к финансовым транзакциям это значит , что менять-то ничего особо не надо.
Из того, что ещё знаю - cisco выдают на удивление одинаковые CDR, тоже структуру под них один раз можно составить.
Наверное, такая стабильность присуща многим отраслям народного хозяйства.
3 июл 08, 17:44    [5883246]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
Вы, видимо, забыли, что, исторически, "накладная" - это физический уровень вручную поддерживаемой базы данных.

Это просто документ такой. Его надо просто хранить - вот и все. Так что все ваши рассуждения мимо кассы.
3 июл 08, 17:46    [5883257]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
На самом деле: есть сущности и есть события, участниками которых являются сущности

Вполне разумный подход на уровне концепции. Но и то и другое в МД превратится в таблицы и станет неразличимым. Вы как-то забываете о необходимом этапе построения вычислительной модели, к которой пользователь никакого отношения не имеет.
3 июл 08, 17:51    [5883306]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
SergSuper
А можно это поподробней? Мне чего-то не представить как синонимы могут решить проблему связей

Изделия <= Состав изделий
преобразуем
Изделия-куда (=Изделия) <- Состав изделий -> Изделия-что (=Изделия)

Что значит "преобразуем" ???
Есть две таблицы в этом примере. Вы предложили использовать синонимы таблиц. Хорошо. Вы используете для одной из таблиц два синонима, а для другой не используете синонимов. Правильно? А что вы получили в результате, что это за схема? Где хранятся эти "связи с помощью синонимов" в метаданных?
Рассмотрите уж этот пример именно с несколькими связями между двумя объектами (в данном случае, правда, все связи "сам с собой"):
Изделие <-Состоит из/Входит в-> Изделие
Изделие <-Используется как комплектующее для/Является комплектующим для-> Изделие
и т.д.
3 июл 08, 18:01    [5883399]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 4 5 6 7 8 [9] 10 11 12 13 .. 27   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить