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

0. Вы ловко перескочили с БД на ХД, но это Вам не поможет):

Речь шла о построении системы отчетов. Вот я и использую стандартный BI инструмент. Если мне надо небольшой текстовый файл отсортировать я тоже использую стандартный юниксовый sort, а не пишу свою программулину на сях. Время-деньги. Да и изобретать велосипед в 2001й раз мне неинтересно.

Бред

1. В БД неизвестен смысл данных
Сидоров, 45, 01.05.2003
?

А метаданные про которые я вам уже который раз пишу на что? Ваша изначальная послылка неверна, т.к. в БД Microstrategy хранит репозиторий метаданных:

таблица="people", колонка="last_name", описание="Фамилия",
таблица="people", колонка="weight_kg", описание="вес в кг",
таблица="people", колонка="incarceration_date", описание="дата отсидки"


Бред

будьте добры оплатить за "специализированную систему представления смысла данных"):

Есть бесплатные, причем с открытым кодом. Pentaho например.

Бред

2. Сказки про хранилища данных мне не нужно рассказывать. Я за свои слова отвечаю. Именно убожество. Не код, конечно, а концепция, и я много раз объяснял почему): И сейчас еще раз объяснил.

Вы конкретно с Microstrategy и Business Objects не работали, судя по тому что пишете. Убожество, говорите, "А пацаны-то не знают" (С). У пацанов из таких компаний как Google, Ebay, Wells Fargo Bank почему-то это "убожество" нормально работает. Народ не жалуется.

Бред

3. Какая еще работа. Вы совершенно запутались, и я икренне хочу Вам помочь.

Мне как раз все ясно, могу либо сделать, либо научить как делать. Но за деньги.


Бред

Если денег совсем нет могу и питание оплатить): А Вы о какой-то своей работе): Видимо об этой:
Сначала сами себе придумали "монолит"???
Тут же приписали эту "идею" мне!??

Объектный навигатор - надстройка над кашей. Интерфейс позволяющий заменить кашу на что-то другое - где? Вот я например могу из Microstrategy гонять одни и те же отчеты которые вынимают данные из Оракла и Teradata. Если на балабановской фабрике заменить кашу на GT.M что будет?

Бред

И начали ее "опровергать" путем рассказа об удивительной архитектуре со специализированными системами представления смысла данных, потому что метаданные СУБД не в состоянии представить смысл данных, хотя он где-то там, все-таки, есть (или "первый архитектор", все-таки, подкачал???).

Берете Microstrategy Desktop лезете в репозиторий метаданных и будет вам счастье.

Бред

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

Хватит ваньку валять. У вас есть конкретный проект где нужны мои услуги? Я меньше чем на 6 месяцев на консалтинг обычно не подписываюсь. Если речь о том что я должен куда-то ехать то минимум 12 месяцев, и я еще крепко подумаю ехать мне или нет.


Я никого не валяю. Очень прошу, в который раз, не выдергивать нужные Вам слова из текстов моих вопросов. Никаких лишних предложений в этих текстах нет): Итак, напомню:

0. Вы ловко перескочили с БД на ХД, но это Вам не поможет):
1. В БД неизвестен смысл данных
Сидоров, 45, 01.05.2003
?
Ну предположим, что "первый архитектор" подкачал, и смысл не известен.
"Второй архитектор" подумал и решил, что 45 - это вес Сидорова в кг, измеренный 01.05.2003.
Сделал отчеты, и ничего не подозревающие "пользователи" начали их тащить):
Однако "третий архитектор" подумал и решил, что 45 - это общее количество суток, которое Сидоров отсидел в КПЗ, а 01.05.2003 - дата окончания последней отсидки. Сделал отчеты, и пользователи начали их тащить, и уже просто тащиться от этих "архитекторов", и жизнь для них буквально заиграла новыми красками):
Или "первый архитектор" не подкачал, и в БД уже есть смысл в данных, а "второй архитектор" (с помощниками!) просто повторно воспроизводит этот смысл в другой системе. А "пользователям" объясняет, что "это все придумал Черчиль в 18-м году" (или Кодд в 1969 - суть не меняется), и будьте добры оплатить за "специализированную систему представления смысла данных"):
Никогда не сомневался, что нужно быть весьма умным человеком, чтобы обманывать других людей, но должен напомнить, что автор РМД как раз надеялся, что пользователи сами смогут работать с данными в БД):
2. Сказки про хранилища данных мне не нужно рассказывать. Я за свои слова отвечаю. Именно убожество. Не код, конечно, а концепция, и я много раз объяснял почему): И сейчас еще раз объяснил.
3. Какая еще работа. Вы совершенно запутались, и я икренне хочу Вам помочь. Если денег совсем нет могу и питание оплатить): А Вы о какой-то своей работе): Видимо об этой:
Сначала сами себе придумали "монолит"???
Тут же приписали эту "идею" мне!??
И начали ее "опровергать" путем рассказа об удивительной архитектуре со специализированными системами представления смысла данных, потому что метаданные СУБД не в состоянии представить смысл данных, хотя он где-то там, все-таки, есть (или "первый архитектор", все-таки, подкачал???).
Вот я Вам и говорю: пожалуйста, на конкретном примере. Вам нужен час, а это стоит 150 долларов? Ну хорошо, сообщите как я Вам могу заплатить 150 долларов (мне проще всего передать наличными кому-нибудь в Москве):).
------------
А что Вы ответили???
1. Речь нигде здесь не шла о "системах построения отчетов". Вы сами, неизвестно зачем, перескочили на другую тему, не желая отвечать на конкретные вопросы по теме):
2. Какие метаданные, о которых Вы пишете в который раз??? Потрудитесь прочитать что я Вам написал): Смысл есть в метаданных БД или нет??? Какая моя "посылка"??? Почему Вы уходите от ответов???
3. Судя по Вашему очередному резкому повороту (в сторону бесплатных "систем представления смысла данных") смысла в Р"перБД, все-таки, нет. Правильно?
4. Еще раз обратите внимание, что я конкретно объясняю почему убожество, без ссылок на каких-то пацанов. Не стоит переключаться с БД на ХД - эту абсолютно не обоснованную и бесперспективную технологию): Давайте мирно вернемся к БД, и не будем уходить от сути вопросов.
5. Замечательно, что Вам все ясно!!! За час можете ответить на кокретные вопросы без демагогии??? И я заплачу Вам 150 долларов):
6. Про спичечные фабрики к vadiminfo, пожалуйста): ОСУБД на mumps, конечно, будут работать на GT.M. Но Вы опять упорно уходите от сути вопросов представления связей в частности и семантики данных в целом в различных СУБД, основанных на различных МД):
7. В какой "репозиторий метаданных" я должен лезть за своим счастьем???
8. У меня есть конкретные вопросы, на которые мне интересно получить Ваши ответы. И я готов за это заплатить, раз бесплатно Вы отвечать не хотите):
16 июл 08, 00:55    [5938923]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
Бред
Здесь Вы видимо подразумеваете какой-то конкретный пример?

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

Для представления сущности Состав изделия=Ребра графа. Чего не понятного-то ? Если ребра не нагружены, то и столбцов нет.


Замечательно! Значит речь идет именно об этом конкретном примере с Составом изделия. Наконец-то можно прочитать этот простой текст:
-----
Ну хорошо, не хотите рассматривать мой пример, давайте рассматривать Ваш, в котором есть "таблица" "Состав изделия", по всей вероятности, с одной колонкой "Количество" (изделия, входящего в изделие), так как "ссылок" (то есть связей с "таблицей" "Изделие"), как мы помним, не должно быть в колонках этой таблицы. Правильно?
Итак, у нас два объекта и две связи между ними:
Изделие <-Используется как составное/Для- Состав изделия
Изделие <-Используется как компонента/Имеет в качестве компоненты- Состав изделия
В "моей" модели (то есть в классической объектной модели) в метаданных действительно хранится два объекта и две связи между ними. Вы же после некого преобразования (а зачем Вы делали какое-то странное "преобразование", и в чем заключается алгоритм преобразования "многоштриховых стрелочек"?) получили три объекта - так это выглядит на схеме БД после "преобразования". Или это некое "представление", а в схеме БД по-прежнему два объекта? Или, как Вы любите повторять, в "вычислительной модели" два объекта и две связи (но как они там представлены-то объясните, в конце концов):), а в какой-то "невычислительной модели" три объекта и две связи:

Изделие составное <-(семантика связи не нужна, так как помещена разработчиком в название фиктивного объекта)- Состав изделия
Изделие-компонента <- Состав изделия

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

Давайте описание "вашей " "объектной" (тогда и посмеемся)

Описание давно дано, но для понимания описания связей в любой удобной для Вас "Вашей" модели не нужно описание ни ОМД, ни какой-либо другой модели. Достаточно не уходить от сути вопросов. Пожалуйста, не уходите): Вы же сами разрешили задать Вам вопросы, что же Вы не отвечаете на них?): Может, все-таки, нужно заплатить?):
16 июл 08, 01:13    [5938939]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
Бред

1. В БД неизвестен смысл данных
Сидоров, 45, 01.05.2003
?

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

Блестяще!!! А то тут ЗлОй несколько не уверен): Теперь прояснилось - во всех известных Вам и ему БД никакого смысла данных нет. Очень хорошо. И, соответсвенно, приходится программировать приложения, пока разработчик не смылся, или быстрее приобретать "специализированные системы для представления смысла данных"):
16 июл 08, 01:18    [5938944]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
onstat-
Бред
_мод
Бред
Ну хорошо, я попытаюсь, а Вы поправьте, пожалуйста.

Поправим. Варианты:
РСУБД: два столбца: ссылка на родителя, ссылка на себя
ССУБД: таблица без столбцов (!) + связь с таблицей родителей + связь с основной таблицей
все это описывается на сотв. DDL

Здесь Вы видимо подразумеваете какой-то конкретный пример? "Родители", "на себя", "основная таблица"??? Что же Вы "поправили"? Только запутали): Таблицы не нужны для представления связей - так Вы говорили раньше. А теперь таблица, оказывается, нужна. Но без столбцов. А зачем она нужна? Чья "связь с таблицей родителей"??? Чья "связь с основной таблицей"???
Можете, наконец-то, объяснить на конкретном примере, или Вам тоже нужно заплатить 150 долларов?


Ответьте пожалуйста мне на вопрос являются ли связи(их свойства, параметры) данными, если не являются то чем они есть на самом деле с точки зрения модели.

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

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

Абсолютно точно - именно в модели): Кого Вы "очень просите"???
Если в МД есть объекты и есть связи, то какие могут быть сомнения, что связи, как и объекты, это данные???
Про физический смысл, пожалуйста, поясните):
Логический смысл связи заключается в том, что это связь между объектами, а не еще один объект):
Я и формально много раз это все объяснял, и за 4 года подустал немного, честно говоря): Можете меня немного пожалеть и ограничиться рассмотрением совершенно конкретных примеров? И, соответственно, задавать практические вопросы):
16 июл 08, 01:27    [5938954]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
onstat-
Ответьте пожалуйста мне на вопрос являются ли связи(их свойства, параметры) данными, если не являются то чем они есть на самом деле с точки зрения модели.

И да и нет. Если две таблицы t1 и t2 связаны 1:N, то это означает что каждая строка t2 содержит скрытый столбец, содержащий номер строки t1. Этот столбец не доступен для изменения, но м.б. доступен для чтения - псевдостолбец - это полезно. В DDL псевдостолбцы не описываются а описывается именно связь между t1 и t2. Это сетевая МД.

Добавлю только, что каждый экземпляр объекта t1 связан с экземплярами объекта t2, а не только каждый экземпляр объекта t2 связан с одним экземпляром объекта t1. Это объектная модель - наследница сетевой):
16 июл 08, 01:32    [5938959]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
onstat-
_мод
onstat-
Ответьте пожалуйста мне на вопрос являются ли связи(их свойства, параметры) данными, если не являются то чем они есть на самом деле с точки зрения модели.

И да и нет. Если две таблицы t1 и t2 связаны 1:N, то это означает что каждая строка t2 содержит скрытый столбец, содержащий номер строки t1. Этот столбец не доступен для изменения, но м.б. доступен для чтения - псевдостолбец - это полезно. В DDL псевдостолбцы не описываются а описывается именно связь между t1 и t2. Это сетевая МД.


Из вашего ответа данными они не являются потому как скрытый столбец( ссылка)
есть только метаинформация.

Как быть со свойствами? Как связи привязать определенные свойства?

Свойства связей не тоже самое что свойства обьектов.
С точки зрения модели это важно, иначе никаких преймуществ относительно РМД я не вижу.

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

Не преувеличивайте, пожалуйста): В РМД нет никаких связей, а есть только отношения. Связи нужно интерпретировать на уровне приложения, пока разработчик не сбежал, как нам объяснил -мод): Действительно, есть реализации ОМД, в которых у связей есть характеристики (по Вашему - свойства). Я с этим не согласен, и считаю, что у связей не может быть характеристик (таких, как у объектов). Если они есть - значит это объект): Кстати, этого же мнения придерживается и _мод):
16 июл 08, 01:39    [5938965]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
onstat-
_мод

Особых преймуществ и нет. Просто если ID строк и PK-FK автоматически поддерживаются где-то внутри СУБД ее собственными средствами, то это м.б. полезным с разных точек зрения.


Так очем тогда 15 страниц спорим?
Насколько я знаю РСУБД дают возмоножсть оперировать ROWID на чтение
и имеют возможность конечному пользователю осуществлять поиск по ROWID.

То есть любая РСУБД обладающая этим функционалом может считаться сетевой?

Да, Вы очень близки к истине): Если учесть, что в сетевой тоже нет никакого смысла в данных. Все (содержательные) метаданные - на уровне приложений.
16 июл 08, 01:42    [5938968]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
onstat-
студент-двоечник
onstat-
Как быть со свойствами? Как связи привязать определенные свойства?

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



Понятие ссылочный констреинт ничем не перегружено.
Что меня сильно радует.

Как у модели с нормализацией отношений сущьностей, какие механизмы ее достижения?


Если суть термина нормализация вы не понимаете тогда есть более общий вопрос:

Каким образом модель осуществляет контроль целостности данных?
Приведите механизмы и терминологию?


автор

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


Я не вижу преймуществ модели.


автор


Ну нарисовать конечно можно, но это и будет совсем другая модель данных.


Какая другая?
Делали самолет получили паравоз.

автор

Заняться тоже можно, только вот народ уже десятки лет пытается и в основном без успеха. Где-то чего-то не срастаеца.


Кто за это платит?
Зачем это нужно, лично Вам?

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

Вся сетевая модель изложенная на этих 15 страницах ее адептами
укладывается в знания получаемые на испытательном сроке (стажировке)
толковым студентом в нормальной софтверной конторе за 2-3 месяца.

М-да, Ваше непонимание основ теории БД намного глубже, чем я ожидал поначалу):
16 июл 08, 01:45    [5938970]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Бред

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


А как проиходит мониторинг закольцовки связей?


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

Бред

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


Так как у связи нет свойств, и какое направление от t1 к t2 или наоборот t2 к t1 описывает реальные взаимоотношения между объектами?

Вероятнее всего в этом случае нужно также
автор

программировать приложения, пока разработчик не смылся



з.ы. Мне кажется что вы сами себе наступили на хвост :)
16 июл 08, 03:02    [5939014]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Бред


М-да, Ваше непонимание основ теории БД намного глубже, чем я ожидал поначалу):


Так отвечают те, кому нечего сказать по существу.
16 июл 08, 03:06    [5939017]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Бред


Я и формально много раз это все объяснял, и за 4 года подустал немного, честно говоря): Можете меня немного пожалеть и ограничиться рассмотрением совершенно конкретных примеров? И, соответственно, задавать практические вопросы):


Практически вопросы у меня были, но Вам они не понравились,
Вашим ответом было

автор

М-да, Ваше непонимание основ теории БД намного глубже, чем я ожидал поначалу):


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

з.ы.
ОФФ: как общаться слепому с глухими, или свинье с гусем
очень хорошо описано законом мухи
16 июл 08, 05:11    [5939053]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
Теперь Вы говорите про "таблицу для представления сущности"??? Видите как Вы запутались):

А для чего же еще нужны таблицы ? (так кто запутался ?)
16 июл 08, 09:31    [5939404]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
Описание давно дано

И где ?
Бред
но для понимания описания связей в любой модели не нужно описание ни ОМД, ни какой-либо другой модели.

Приехали :)
16 июл 08, 09:33    [5939421]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
Теперь прояснилось

Рад за вас :)
16 июл 08, 09:35    [5939430]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
_мод
Guest
Бред
Добавлю только, что каждый экземпляр объекта

А вот не надо добавлять :). Про объекты речи не было.
16 июл 08, 09:37    [5939446]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
MX -- ALEX
Guest
onstat-

ОФФ: как общаться слепому с глухими, или свинье с гусем
очень хорошо описано законом мухи


По прочтению Закона Мухи :

бред сивой кобылы, высосанный из мухи

эта старая болезнь на тему превосходства неАрийской (неАмериканской) "расы"
обычно лечится тяжелой артиллерией и Нюрнбергским Трибуналом

(сие замечаниие не в обиду и никоим образом не относится к уважаемому мной onstat-)
16 июл 08, 12:04    [5940820]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Бред

Логический смысл связи заключается в том, что это связь между объектами, а не еще один объект):


Бред

и считаю, что у связей не может быть характеристик (таких, как у объектов). Если они есть - значит это объект):



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

Что вы предлагаете делать?

Изменять архитектуру БД где ребро уже будет не связью а объектом?

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


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

Как по мне, так отношения в РМД намного гибче масштабируемее связей.
16 июл 08, 17:20    [5943822]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
onstat-
Member

Откуда:
Сообщений: 6941
Бред

Опять ошибаетесь из-за невнимательности): Надеюсь):
Никакая это не классическая задача): "Классическая "задача" это только
Изделие <-Состоит из/Входит в-> Изделие
Чтобы Вы (вместе с _мод) поняли продолжу список:
Изделие <-Состоит из/Входит в-> Изделие
Изделие <-Используется как комплектующее для/Является комплектующим для-> Изделие
Изделие <-Используется для упаковки/Упаковывается в-> Изделие
Изделие <-Использует в качестве аналога/Является аналогом- Изделие
И т.д.
Ну а дальше у Вас опять голые декларации про "грамотно построенную архитектуру", которая:
1) является вынужденным решением из-за недостатков РМД;
2) удлиняет сроки разработки и снижает качество приложений;
3) приводит к постоянному программированию даже самых простых приложений.
И, конечно, у этих безобразных, а не "грамотных" архитектур есть лидеры, кто бы сомневался):
Но это теория, а почему бы Вам не показать на рассматриваемых конкретных примерах, как все делается в "грамотных архитектурах"?): Вот _мод хотя бы старается показать. Может Вы ему поможете?):


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


Изделие <-Состоит из/Входит в-> Изделие
V
|
V
в количестве N штук



Такая связь в большенстве случаев будет заменена обьектом описывающим связь еще до выхода преальфа версии.
16 июл 08, 17:49    [5944097]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
А в ответ тишина):
А я продолжаю перечитывать Ваши сообщения, уважаемый ЗлОй):
Итак, замечательная запись в Вашем репозитории метаданных "системы представления смысла данных":

таблица="people", колонка="weight_kg", описание="вес в кг",

(видимо для простоты не указали "описание" для "таблицы").

Вот как это выглядит в репозитории метаданных ОСУБД в результате проектирования БД:

Идентификатор объекта="A" [можно использовать people - дело вкуса - мне не нравится]
Наименование="Человек"
Описание="Экземпляры этого объекта..."
Идентификатор характеристики=1 [можно использовать weight_kg - дело вкуса - мне не нравится]
Наименование="Вес в кг"
Описание="При вводе значения этого поля следует ... Особый случай... И.т.д."

Это метаданные ОСУБД. А в навигаторе автоматически получаем наименование объекта, наименование поля и встроенную документацию с описаниями объектов, связей, характеристик и функций (если для создания "приложения" что-то приходится программировать). Естественно в интерфейсе пользователь может изменять наименования на "более удобные для себя" и это сохраняется, опять же, в репозитории метаданных. Но мы договаривались не уходить от МД, БД и СУБД ни с торону ХД, ни в сторону "приложений". Вернемся к БД.
Вам кровь из носа нужно всучить пользователям Microstrategy даже при использовании ОСУБД, правильно? Это серьезный продукт, и в нем не представляет никакого труда извлечь из метаданных любой СУБД метаданные и описать их в своем репозитории, правильно? Тогда вместо

Идентификатор объекта="A"
Наименование="Человек"
Описание="Экземпляры этого объекта..."
Идентификатор характеристики=1
Наименование="Вес в кг"
Описание="При вводе значения этого поля следует ... Особый случай... И.т.д."

получим

таблица="people", колонка="weight_kg", описание="вес в кг"

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

Column Name=Вес в кг
Description=При вводе значения этого поля......

Но что толку?. Ведь Column Name выполняет и роль идентификатора, не появится автоматически в "приложении", как и Description. И большинство разработчиков не будут писать в коде TSQL 'Вес в кг'. Тем не менее, не следует забывать об усилиях, прилагаемых разработчиками "Р"СУБД, для возвращения БД идентификации, навигации и семантики. Но у них ничего не может получиться даже теоретически, если оставаться в рамках РМД): И это, действительно, счастье, как Вы сказали! Так как имеется замечательный "повод" всучивать людям разнообразные "системы восстановления навигации и смысла баз данных"):
16 июл 08, 21:21    [5944950]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
onstat-
Бред

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


А как проиходит мониторинг закольцовки связей?


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

Бред

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


Так как у связи нет свойств, и какое направление от t1 к t2 или наоборот t2 к t1 описывает реальные взаимоотношения между объектами?

Вероятнее всего в этом случае нужно также
автор

программировать приложения, пока разработчик не смылся



з.ы. Мне кажется что вы сами себе наступили на хвост :)

Я Вам, как новичку (эти вопросы уже много раз обсуждались, и никаких тайн в них не осталось) советую (или прошу - как Вам больше нравится): не вырывайте слова из контекстов, не мешайте все вопросы в кучу, ведите себя достойно, раз Вы не хотите принять участия в очном семинаре по любому обсуждаемому вопросу, а хотите разобраться путем переписки в Интернете):
У связи есть смысл - в каждом направлении свой. Кучу примеров уже здесь рассмотрели, а Вы вместо того чтобы вникнуть в суть, пытаетесь кому-нибудь на хвост наступить): Вы хоть сами вчитайтесь в свой вопрос про "реальные взаимоотношения". Не суетитесь, нам торопиться некуда, здесь уже примерно шестая волна "непонимающих" пошла):
16 июл 08, 21:30    [5944975]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
onstat-
Бред


М-да, Ваше непонимание основ теории БД намного глубже, чем я ожидал поначалу):


Так отвечают те, кому нечего сказать по существу.

На что отвечают??? На какой вопрос???
16 июл 08, 21:31    [5944979]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
onstat-
Бред


Я и формально много раз это все объяснял, и за 4 года подустал немного, честно говоря): Можете меня немного пожалеть и ограничиться рассмотрением совершенно конкретных примеров? И, соответственно, задавать практические вопросы):


Практически вопросы у меня были, но Вам они не понравились,
Вашим ответом было

автор

М-да, Ваше непонимание основ теории БД намного глубже, чем я ожидал поначалу):


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

з.ы.
ОФФ: как общаться слепому с глухими, или свинье с гусем
очень хорошо описано законом мухи

Я себя не считаю ни слепым, ни глухим. Читайте что здесь обсуждается, не вырывайте слова из контекстов, иначе получается, что у Вас нет никаких вопросов, а есть сложившееся мнение. Что тоже неплохо, конечно):
Хорошо, я грубо ошибся, не раглядев практических вопросов по теме. Я извиняюсь. Не могли бы Вы повторить первый практический вопрос?
16 июл 08, 21:36    [5944993]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
Бред
Теперь Вы говорите про "таблицу для представления сущности"??? Видите как Вы запутались):

А для чего же еще нужны таблицы ? (так кто запутался ?)

То есть для представления сущностей (а не связей между сущностями) в некоей "Вашей модели" применяются таблицы без колонок. Я правильно понял?
16 июл 08, 21:39    [5945002]     Ответить | Цитировать Сообщить модератору
 Re: недостатки иерархических баз  [new]
Бред
Guest
_мод
Бред
Описание давно дано

И где ?
Бред
но для понимания описания связей в любой модели не нужно описание ни ОМД, ни какой-либо другой модели.

Приехали :)

Опять словечек надергали): Не хотите по существу говорить. Намекаете, все-таки на оплату интеллектуального труда?):
16 июл 08, 21:40    [5945005]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 11 12 13 14 15 [16] 17 18 19 20 .. 27   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить