powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / вопрос по парадигмам БД
79 сообщений из 79, показаны все 4 страниц
вопрос по парадигмам БД
    #33069533
Илья(Phantom)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Пишу статью-обзор по используемым парадигмам отражения логических сущностей в приложениях на БД.
Получилось пока что 3 парадигмы, кратко:
1) сущность -> строка в таблице
2) объектные схемы БД с "класс -> объект" архитектурой
3) объектные схемы БД с "прототип -> объект" архитектурой

Может кто-нибудь в своей практике встечался с чем-то еще - более "экзотическим" и т.д.? Интересуют так же примеры схем БД и по этим 3 парадигмам(в основном по 2 и 3, т.к. в 1 досточно все просто).

Заранее благодарю!
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33069610
Фотография Павел Воронцов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Есть ещё одна парадигма - правильная. Это когда после составления схемы сущность-связь ещё идёт этап норализации. При этом отношение сущность - строка таблицы как правило нарушается. Почитали бы что ли книжки, чем кидаться писать статьи...
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33069690
Илья(Phantom)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Хмммм.... интересно, почему все себя априори считают уменее других? Начинают советовать почитать книжки и т.д.? У меня уже свыше 5 лет опыта проектирования БД и КИС систем, поэтому Ваш "наезд" просто считаю не актуальным.

Согласен - есть некоторая небрежность в моем вопросе, но думается, что человек имевший дело с большими КИС понял бы меня.

Позвольте расшифровать:

Есть некоторая система в которой представлены некоторые логические сущности. Эти сущности должны как-то персистятся (сохраняться) в базу данных. Именно на этом этапе и "случаются" те парадигмы о которых я говорил. В самом простом случае сущность отражается таблицей (одной или несколькими), а колонки таблицы это аттрибуты сущности. В более сложных случаях в КИС обычно разрабатывают в БД свою собственную объектную модель - как бы "поверх" таблиц.
Например возможна таблица object с полями object_id, name, parent_id, type_id ну и т.д. И уже разного типа сущности могут сохранятся в одну и туже схему таблиц. Ну и т.д.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33069730
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Илья(Phantom)...Эти сущности должны как-то персистятся (сохраняться) в базу данных.Wow...
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33069735
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> почему все себя априори считают уменее других?

Действительно. Вы сами об этом что думаете?

> У меня уже свыше 5 лет опыта проектирования БД и КИС систем

Ну, пять лет можно штаны по-разному протирать. Авторством каких проектов Вы можете похвастать?

> Есть некоторая система в которой представлены некоторые логические
> сущности.

Что это - "логические сущности"? Как они описаны?

Работы каких авторов Вы хотите рассматривать в Вашей статье?
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33069890
Фотография Павел Воронцов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Илья(Phantom)Хмммм.... интересно, почему все себя априори считают уменее других? Начинают советовать почитать книжки и т.д.? У меня уже свыше 5 лет опыта проектирования БД и КИС систем, поэтому Ваш "наезд" просто считаю не актуальным.

Согласен - есть некоторая небрежность в моем вопросе, но думается, что человек имевший дело с большими КИС понял бы меня.

Позвольте расшифровать:

Есть некоторая система в которой представлены некоторые логические сущности. Эти сущности должны как-то персистятся (сохраняться) в базу данных. Именно на этом этапе и "случаются" те парадигмы о которых я говорил. В самом простом случае сущность отражается таблицей (одной или несколькими), а колонки таблицы это аттрибуты сущности. В более сложных случаях в КИС обычно разрабатывают в БД свою собственную объектную модель - как бы "поверх" таблиц.
Например возможна таблица object с полями object_id, name, parent_id, type_id ну и т.д. И уже разного типа сущности могут сохранятся в одну и туже схему таблиц. Ну и т.д.Вам сюда и сюда . Welcome to the club
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33069927
Илья(Phantom)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
да... смешно здесь у вас - ей Богу:) Вместо того, чтобы попробовать понять и помочь человеку пытаетесь воспринять все в штыки:) А я то думал - зарегюсь на сайте - мож что дельное скажут.

2 guest_20040621
Хотя бы IBM и Xerox что-нибудь говорят?:)

Если угодно Логическая сущность = объект. Но это немного шире чем просто объект.

В основном работы по онтологиям и экспертным системам В.Л.Стефанюка.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33069964
Фотография Павел Воронцов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Илья(Phantom)да... смешно здесь у вас - ей Богу:) Вместо того, чтобы попробовать понять и помочь человеку пытаетесь воспринять все в штыки:) А я то думал - зарегюсь на сайте - мож что дельное скажут.

2 guest_20040621
Хотя бы IBM и Xerox что-нибудь говорят?:)

Если угодно Логическая сущность = объект. Но это немного шире чем просто объект.

В основном работы по онтологиям и экспертным системам В.Л.Стефанюка.Вы просто на мозоль наступили. Оцените размер топиков, на которые я тут ссылки дал (и восхититесь). Слова "персистить" выдают Вас с головой. Ничего более внятного, чем почитать правильные книжки посоветовать Вам не могу к сожалению. Есть только просьба - не пишите статью...
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33070015
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Вместо того, чтобы попробовать понять и помочь человеку пытаетесь воспринять
> все в штыки

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

> Хотя бы IBM и Xerox что-нибудь говорят?:)

Ну, есть такие лавки, и что? Интересно не Ваше место работы, а Ваши реальные проекты. Не знаю, как дела у Xerox, а криворукость т. н. девелоперов IBM мне известна.

> Если угодно Логическая сущность = объект. Но это немного шире чем просто
> объект.

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

> В основном работы по онтологиям и экспертным системам В.Л.Стефанюка.

Не читал, хвастать не буду. Вопрос, однако, задам: по-Вашему, как онтология и экспертные системы связаны с предметом обсуждения? Насколько я знаю, никаких специальных методик проектирования они не предполагаю.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33070083
Илья(Phantom)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Павел,

поделитесь как слово "персистеть" может выдавать с головой? Здесь что-то кроется какой-то скрытый (чисто данного форума) смысл?
Все проекты у нас делаются на J2EE и процесс сохранения (отражения) состояния системы в БД из покон веков назывался данным словом - сохранение. Что здесь может быть удивительного?

Топики конечно потрясают - но не удивляют. Объектные БД не интересуют как таковые. Интересует процесс "трансформации" - логических сущностей из объектов одной системы в другую.

Поймите, что материал уже набран, но вот проблема - термины абсолютно не те, к которым привыкли люди на этом форуме - те кто крутятся в основном в мире БД.

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

Ладно - я все понял. Товарищи на заграничных форумах намного теплее и понятливее, чем у нас.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33070123
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Объектные БД не интересуют как таковые.

Да убогие они. Ограниченные. Без внятной теоретической базы. Исключительно для детерминированных задач. Что здесь в принципе может быть интересного? Болото.

> материал уже набран,

Публикуйте, в чем проблема?
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33070191
Илья(Phantom)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Интересуют конкретные пример схем БД для 2 и 3 типа перечисленных мной. Желательно "открытые", чтоб можно было сослаться и т.д.

> Да убогие они. Ограниченные. Без внятной теоретической базы. Исключительно
> для детерминированных задач. Что здесь в принципе может быть интересного?
> Болото.

даааа - болото болотом и нафига мы его разрабатываем....:)
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33070223
Автору искренне КГ/АМ. Пересказывать то, о чем здесь годами тщательно и в подробностях претирают, народ, видимо, не хочет. А что, в лом поискать "маппинг|mapping" по конфам? Или "термин термин абсолютно не тот" ... в смысле - не знакомый? Ну так и отношение соответствующее. А поискать, так статья может показаться не очень нужной.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33070264
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Интересуют конкретные пример схем БД для 2 и 3 типа перечисленных мной.

Это предложение работы? Хм... лично мне эта задача не интересна. Поскольку а) тривиальна, б) уже имеет решения.

> даааа - болото болотом и нафига мы его разрабатываем....:)

Предположу: бабло зарабатываете. Что само по себе не предосудительно: кушать всем хочется. Только делаете Вы это хм... не слишком профессионально. ;))
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33070304
Фотография XM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Илья(Phantom)
Поймите, что материал уже набран, но вот проблема - термины абсолютно не те, к которым привыкли люди на этом форуме - те кто крутятся в основном в мире БД.

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

Если Вы и статью в таком стиле и такой терминологии собираетесь публиковать, кто её поймёт???

---
"Raffiniert ist der Herr Gott, aber boshaft ist Er nicht." Albert Einstein
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33070408
Фотография Jimmy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Илья(Phantom)Пишу статью-обзор по используемым парадигмам отражения логических сущностей в приложениях на БД.
Получилось пока что 3 парадигмы, кратко:
1) сущность -> строка в таблице
2) объектные схемы БД с "класс -> объект" архитектурой
3) объектные схемы БД с "прототип -> объект" архитектурой

Может кто-нибудь в своей практике встечался с чем-то еще - более "экзотическим" и т.д.? Интересуют так же примеры схем БД и по этим 3 парадигмам(в основном по 2 и 3, т.к. в 1 досточно все просто).

Заранее благодарю!

-- Multidimensional ("star" / "snowflacke" схемы) ?
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33071032
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Илья(Phantom)Пишу статью-обзор по используемым парадигмам отражения логических сущностей в приложениях на БД.
Получилось пока что 3 парадигмы, кратко:
1) сущность -> строка в таблице
...
А где собственно реляционный подход? То, что вы привели в п. 1 есть только частный случай. В более общем случае, каждый кортеж отношения представляет вовсе не сущность, а некоторый факт, то есть истинностное утверждение (аксиому), соответствующее предикату отношения. При этом информация о некоторой сущности реального мира представляется только всей совокупностью фактов о ней, хранящихся в БД.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33071035
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И еще. Как же можно писать о БД и жаловаться, что "вот проблема - термины абсолютно не те, к которым привыкли люди на этом форуме - те кто крутятся в основном в мире БД." Это выше моего понимания. Это, скажем, как писать специализированную статью о биологии и сетовать та то, что приходится использовать термины, привычные биологам.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33071237
Int23
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Как я понимаю автор просто пишет диссертацию и ему нужен список литературы )....Но мне не совсем понятно, что он хочет? Он хочет найти методики "объектно-ориентированного преобразования?"....Тогда нужно смотреть работы Ambler'а....Там есть примеры. А конкретная реализация так это Bold для Дельфи. Там можно построить БД в понятиях классов, а сохранить в реляционной БД (либо в XML). Я смотрел отображение на InterBase. И подобных инструментов куча. Мне кажется автор не до конца описал задачу исследования :))
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33071351
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Jimmy-- Multidimensional ("star" / "snowflacke" схемы) ?
Образцовый пример первого типа из перечисленных. Потому как именно что в отличие от нормализованных схем сущность почти однозначно соответствует строке в таблице.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33071373
Int23
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
А почему "звезда" описывает одну сущность в строке таблицы фактов? Ведь там же множество внешних ключей на размерности? И получается что одна строка содержит только ничего не значащие значения (внеш. ключи). А сами данные требуется получать из других таблиц. Так или я что-то не попимаю?
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33071433
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Int23А почему "звезда" описывает одну сущность в строке таблицы фактов?
И в строке таблицы измерений тоже. Единственно, принцип несколько нарушается с иерархиями в строгой звезде.

Int23Ведь там же множество внешних ключей на размерности?
И чему это противоречит?

Допустим, я живу возле м. Сокол. Это - атрибут меня как сущности. Но само м. Сокол вместе со всеми его рельсами, поездами, сотрудниками, Ленинградским шоссе над и домами вокруг - моим атрибутом не является.

Так и здесь: атрибутом, реквизитом факта является "упоминание", ссылка на измерение, "измерение как объект", но не атрибуты собственно измерения.

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

В первую очередь, строка таблицы содержит не столько внешние ключи, сколько значения, measures. Скажем, для факта покупки - сумму покупки. Таблицы фактов, все атрибуты которых являются измерениями - вырожденный случай; я такого, пожалуй, никогда не встречал. Можно, конечно, сделать сумму покупки измерением - но смысл?

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

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

Разумеется, в измерениях в принципе могут храниться какие-то показатели. Скажем, может храниться ставка НсП, разная для разных субъектов федерации. Но во-первых, именно этот случай - скорее исключение, а во-вторых, это будет именно атрибут субъекта федерации, измерения (меняющийся по времени). Атрибутом продажи может быть "текущая ставка НсП" - которая как правило будет выделена как measure в таблице фактов, скорее даже как "В том числе НсП".
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33071487
Фотография Jimmy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[quot softwarer Образцовый пример первого типа из перечисленных. Потому как именно что в отличие от нормализованных схем сущность почти однозначно соответствует строке в таблице.[/quot]

Ну, насчет образцовости я бы не стал утверждать, т.к. кроме иерархий (в "звезде") есть и другие отличия, типа истории изменения значения атрибута, которая хранится в таблице фактов. Если учитывать это обстоятельство, то понятие "сущность -> строка в таблице" нужно расширить до "сущность в определенный момент времени -> строка в таблице"
Мне так кажется.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33071676
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Попробуем перевести обсуждение в более техническую плоскость.
Есть два факта:
"Джим съел собаку", "Вчера Джим получил письмо от Джейн"
Логически (не вдаваясь в вопросы о ключах и индексах) их можно формализовать различными предикатными конструкциями:
Код: plaintext
( 1 )  Человек(Имя=Джим, Съел=собака, Получил_письмо_от=Джейн, Получил_письмо_когда=вчера)
Код: plaintext
1.
( 2 ) Съел (Кто=Джим, Кого=собака)
Получил_письмо (Кто=Джим, От=Джейн, Когда=Вчера)
Код: plaintext
1.
2.
3.
( 3 ) АтрибутТипаСобытия(Тип=съел, Номер_атрибута= 1 , Тип_атрибута=Кто)
АтрибутТипаСобытия(Тип=съел, Номер_атрибута= 2 , Тип_атрибута=Кого)
Событие (Тип=съел, Арибут1знач=Джим,Атрибут2знач=собака, ..., Атрибут100знач=NULL)
...
достаточно для начала.
Способы отличаются тем, что в одном случае "съел" отображается в атрибут, в другом в предикат, в третьем в значение.

2 Илья(Phantom) :
не вдаваясь в вопрос о том какое их этих отображений правильное (в частности что будет если Джим съест еще кого-нибудь или получит больше писем :), только чтобы понять вашу терминоглогию, точнее, ее применение к БД:
сколько здесь парадигм?
сколько здесь онтологий?
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33071728
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
JimmyНу, насчет образцовости я бы не стал утверждать,
Скажем так, куда более близкий к образцу, нежели обычная нормализованная схема :)

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

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

Разумеется, с логической точки зрения можно сказать, что таким срезом куба описывается некая "сущность реального мира". Но здесь с моей точки зрения как раз один из тех случаев, когда в проектировании уходят от однозначного соответствия реальных объектов сущностям проекта. Да, в реальном мире есть такая сущность. А в нашем проекте мы мыслим несколько другими. У этих других может быть прямой аналог в реальном мире - как у продаж, а может и не быть.

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

История как контрпример принципа "одна строка - одна сущность" опять-таки видна скорее в таблицах измерений, во всяких SCD2.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33071778
Фотография XM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ModelR
сколько здесь парадигм?
сколько здесь онтологий?
сколько здесь болтологий???
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33071804
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И естественно, мы неизбежно приходим к вопросу о том, что такое "сущность". И тут можно встретить 2 точки зрения:
1. Бизнес-сущность. Что-то, существующее в предметной области, вполне различимое, известное и понятное специалистам/пользователям.
2. Сущность-факт. Что-то, о чем можно сделать запись в данной таблице БД.
В этой теме можно наблюдать обе точки зрения. При этом использование одного и того же термина "сущность" приводит стороны к недопониманию.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33071868
Фотография XM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 mir
Не подскажете [толковый] словарь стандарной терминологии (относительно БД), который не вызывал бы кривотолков?
А то, блин, часто доводится видеть различные пояснения одних терминов и (почти) идентичные пояснения различных терминов :(
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33072012
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Насчет словаря. ИМХО лучше, чем это у нас не найти.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33072081
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mirИ естественно, мы неизбежно приходим к вопросу о том, что такое "сущность". И тут можно встретить 2 точки зрения:
1. Бизнес-сущность. Что-то, существующее в предметной области, вполне различимое, известное и понятное специалистам/пользователям.
2. Сущность-факт. Что-то, о чем можно сделать запись в данной таблице БД.
В этой теме можно наблюдать обе точки зрения. При этом использование одного и того же термина "сущность" приводит стороны к недопониманию.
Использование термина сущность для обозначения строки в таблице конечно неудачно. Сущность-факт, событие, сущность-связь других сущностей, как и сущность предмет - частные случаи сущности. Все они понятны бизнесу, только каждому по-своему . Вот дождь -это процесс или предмет? Нет, нет, не отвечайте плз., это не вопрос а иллюстрация. XM 2 mir
Не подскажете [толковый] словарь стандарной терминологии (относительно БД), который не вызывал бы кривотолков?
А то, блин, часто доводится видеть различные пояснения одних терминов и (почти) идентичные пояснения различных терминов :(
Лучше Дейта никто объяснять не умеет.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33072320
Фотография Jimmy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer
Jimmy есть и другие отличия, типа истории изменения значения атрибута, которая хранится в таблице фактов.
Тут, пожалуй, околотерминологическое расхождение.

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

Разумеется, с логической точки зрения можно сказать, что таким срезом куба описывается некая "сущность реального мира". Но здесь с моей точки зрения как раз один из тех случаев, когда в проектировании уходят от однозначного соответствия реальных объектов сущностям проекта. Да, в реальном мире есть такая сущность. А в нашем проекте мы мыслим несколько другими. У этих других может быть прямой аналог в реальном мире - как у продаж, а может и не быть.

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

История как контрпример принципа "одна строка - одна сущность" опять-таки видна скорее в таблицах измерений, во всяких SCD2.

Закроем глаза на "куб" и вообще любую многомерную структуру, кроме реляционной модели.

Возьмем упрощенную модель:
Сущность "Лицевой Счет"
-- Номер счета - атр.
-- Наименование счета - атр.
-- Остаток на счете - атр.
/* Существенная характеристика,изменяется во времени, т.е существует серия значений:
--- (на 01.01.2005)
--- (на 02.01.2005)
--- (на 03.01.2005)
--- (на 04.01.2005)
--- (на 05.01.2005)
--- (на 06.01.2005)
:::
*/
-- Дата открытия - атр.
-- Дата закрытия - атр.

Таблицы:
- Account
-- Account number (PK)
-- Account name
-- Open date
-- Close date

- Balance
-- Account number(PK)(FK Account)
-- Actual date(PK)
-- Account balance

Таким образом, "сущность - строка" описывается следующим запросом:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
SELECT
   a.[Account number],
   a.[Account name],
   a.[Open date],
   a.[Close date],
   b.[Actual date],
   b.[Account balance]
FROM
  Account a
  INNER JOIN
    Balance b
    ON
    a.[Account number] = b.[Account numer]
    AND
    b.[Actual date] = <Required date>

т.е. именно "сущность в определенный момент времени - строка". Иначе - "сущность - много строк".
ЗЫ Хотя, как я понимаю, все дело в интерпретации.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33072374
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ModelRИспользование термина сущность для обозначения строки в таблице конечно неудачно.Я тоже так считаю.
ModelRСущность-факт, событие, сущность-связь других сущностей, как и сущность предмет - частные случаи сущности.Точнее даже так: иногда запись в таблице соответствует бизнес-сущности (часный случай), но в общем случае информация о бизнес-сущности отображается на несколько записей в нескольких таблицах. Речь, разумеется, идет о РМД.
ModelRВсе они понятны бизнесу, только каждому по-своему.Полагаю, что "бизнесу" (т.е. пользователям) понятны исключительно бизнес-сущности, которые ему видны на внешнем уровне представления (по ANSI/SPARC). Всякие же "таблицы", "записи" и т.п. относятся к логическому уровню, который "бизнес" не видит и о котором часто даже не подозревает.[/quot]
ModelRВот дождь -это процесс или предмет? Нет, нет, не отвечайте плз., это не вопрос а иллюстрация.Мысль я не уловил, сорри.

XM 2 mir
Не подскажете [толковый] словарь стандарной терминологии (относительно БД), который не вызывал бы кривотолков?
А то, блин, часто доводится видеть различные пояснения одних терминов и (почти) идентичные пояснения различных терминов :(Сам бы такой хотел :) Собираешь всю жизнь с миру по нитке. Хороший источник "вразумления" - сайт Дейта и Паскаля http://www.dbdebunk.com. Но там все не систематизировано.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33072415
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Jimmy
Закроем глаза на "куб" и вообще любую многомерную структуру, кроме реляционной модели.

Возьмем упрощенную модель:
Сущность "Лицевой Счет"
-- Номер счета - атр.
-- Наименование счета - атр.
-- Остаток на счете - атр.
/* Существенная характеристика,изменяется во времени, т.е существует серия значений:
--- (на 01.01.2005)
--- (на 02.01.2005)
--- (на 03.01.2005)
--- (на 04.01.2005)
--- (на 05.01.2005)
--- (на 06.01.2005)
:::
*/
-- Дата открытия - атр.
-- Дата закрытия - атр.

Таблицы:
- Account
-- Account number (PK)
-- Account name
-- Open date
-- Close date

- Balance
-- Account number(PK)(FK Account)
-- Actual date(PK)
-- Account balance

Таким образом, "сущность - строка" описывается следующим запросом:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
SELECT
   a.[Account number],
   a.[Account name],
   a.[Open date],
   a.[Close date],
   b.[Actual date],
   b.[Account balance]
FROM
  Account a
  INNER JOIN
    Balance b
    ON
    a.[Account number] = b.[Account numer]
    AND
    b.[Actual date] = <Required date>

т.е. именно "сущность в определенный момент времени - строка". Иначе - "сущность - много строк".
ЗЫ Хотя, как я понимаю, все дело в интерпретации.В чем прикол? Таблиц ведь у вас две не случайно: логически сущностей тоже две
Счет(Номер,Наименование,ДатаОткрытия,ДатаЗакрытия) и
ОстатокСчета(Номер,Дата,Сумма)
и связь Каждый Счет имеет несколько ОстатокСчета.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33072690
Фотография Jimmy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот это и есть та самая интерпретация, о которой я говорил.

Логически - как раз-таки одна сущность.
Выделение сущности "остаток на счете" с точки зрения проектировщика оправдано, конечно, но с точки зрения бизнеса - несколько натянуто.

Тест простой:
-- Существует счет без остатка?
-- Существует ли остаток без счета?
Т.е. налицо композиция (в терминах ООП)

ЗЫ Чтобы понятия развести:
-- есть связи (1-М, М-М), которые применимы к парам " естественная сущность (объект реального мира) - естественная сущность (объект реального мира)", т.е. воспроизводят парадигму, по словам автора треда, "сущность-запись"

-- есть связи (1-М, М-М), которые применимы к парам " естественная сущность (объект реального мира) - суррогатная сущность (суррогатный объект, созданый для хранения атрибутов естественной сущности), т.е. то, что чаще всего и характерно для МДМ схем.

Несмотря на внешнюю схожесть это - разные вещи, что и сбивает с толку, наверное.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33072707
Фотография Jimmy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Извините, поправка:

-- есть связи (1-М), которые применимы к парам " естественная сущность (объект реального мира) - суррогатная сущность (суррогатный объект, созданый для хранения атрибутов естественной сущности), т.е. то, что чаще всего и характерно для МДМ схем
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33072808
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
JimmyЛогически - как раз-таки одна сущность.
Выделение сущности "остаток на счете" с точки зрения проектировщика оправдано, конечно, но с точки зрения бизнеса - несколько натянуто.
Я и говорю - вопрос в терминологии. Соотношение "одна бизнес-сущность - одна строка в таблице" - имеет максимальные шансы быть нарушенным, с этим трудно спорить, да и незачем.

Если мы помним, что физическая и логическая модели не обязаны соответствовать одна другой - конфликта не остается. У нас есть логическая модель с бизнес-сущностями, у нас есть физическая модель с таблицами (которые, если не ошибаюсь, Кодд и называл сущностями). В логической модели - если нам удобно так думать, давайте нарисуем счет с таблицей остатков. В Oracle Designer, кстати, для этого было очень удобное средство: можно было вкладывать сущности одна в другую. А потом появились nested tables, что дает "один в один" воспроизвести это отношение на физическом уровне.

Обсуждать, насколько далеко это от изначального утверждения автора - имхо бессмысленно. Ограничусь утверждением, что для "кубических" задач фактом будет именно "остаток по счету.. на дату.. равен..". Не потому что мы его натянуто выделили, а объективно - по смыслу решаемых задач.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33072848
Фотография Jimmy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 softwarer

Я согласен с каждым Вашим словом :0))

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

-- БД для регистрации транзакций (OLTP системы, 3-4 НФ)
-- БД для получения отчетов (OLAP в том числе, "звезда", "снежинка")
-- БД - универсальное "хранилище" ("объектная" надстройка над РСУБД)

2 Илья(Phantom)
Мне кажется, что такая классификация более соответствует практическим целям, нежели предложенная Вами.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33073117
Лучше бы Вы, Jimmy, для начала, закрыли глаза на реляционную модель...
В Вашем примере можно увидеть две "естественные", как Вы выразились, сущности - Счет и День. И связь между ними

Счет - Имеет остаток на/За который имеется остаток по - День

с характеристикой связи "Остаток". И ничего здесь не натянуто даже с точки зрения бизнеса...

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

"Парадигмы отражения", видимо, следует различать по механизмам идентификации сущностей, механизмам представления связей между сущностями и возможностям прямого доступа к сущностям (которого может не быть, например, если "сущность" "встроена" в другую "сущность")...
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33073326
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
JimmyЛогически - как раз-таки одна сущность.
Выделение сущности "остаток на счете" с точки зрения проектировщика оправдано, конечно, но с точки зрения бизнеса - несколько натянуто.
Не согласен. Каковы бизнес правила в данном случае?
(1) Каждый счет имеет единственное Наименование
(2) Каждый счет имеет один или несколько Остатков.
как иначе их выразить не вводя понятие Остаток?
Я не говорю, что этот язык абсолютно понятен бизнесу, однако это то минимальное общее понятийное поле, на котором проектировщик может надеятся найти общий язык с бизнесом на этапе проекта.
softwarer
Если мы помним, что физическая и логическая модели не обязаны соответствовать одна другой - конфликта не остается. У нас есть логическая модель с бизнес-сущностями, у нас есть физическая модель с таблицами (которые, если не ошибаюсь, Кодд и называл сущностями). В логической модели - если нам удобно так думать, давайте нарисуем счет с таблицей остатков. В Oracle Designer, кстати, для этого было очень удобное средство: можно было вкладывать сущности одна в другую. А потом появились nested tables, что дает "один в один" воспроизвести это отношение на физическом уровне.
Уточнение. В Oracle Designer вложение А в Б означало "Каждое А есть Б" в смысле состава атрибутов, т.е. скорее это было наследование.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33073338
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Илья(Phantom)
Пишу статью-обзор по используемым парадигмам отражения логических сущностей в приложениях на БД.


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

Илья(Phantom)
Если угодно Логическая сущность = объект. Но это немного шире чем просто объект.


Объекты тоже используют и в смысле обектов реального мира, и в смысле средств структурирования данных. Т.е. тада вторые тоже могут быть логическими? Сложность в том, что уже используются термины концептуальные и физические в одном ряду с логическими. И как правило, например, концептуальные отображаются в логические, а последние в физические. Реже наоборот и на одном уровне. Хотя считается некоторыми авторами, что иерархические можно отобразить в реляционные.
Я намекаю, на то что прилогательное "логические", возможно лучше выкинуть, а за одно и термины "парадигму" и "онтология" тоже претендуют на удаление из статьи про приложения БД.

Ну возможно, что объект в ООП уже сущности в ER, потому что строго идентифицирован и имеет дополнительные возможности - поведение. Т.е. больше признаков как у понятия.

Илья(Phantom)
В основном работы по онтологиям и экспертным системам В.Л.Стефанюка.


Зкспертные системы все же предполагают не приложения БД, а приложения БЗ (Баз знаний). Там, скорее всего, все сложнее и тока сущностиями, хотя и логическими, не отделаться.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33073443
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfoЯ намекаю, на то что прилогательное "логические", возможно лучше выкинуть, а за одно и термины "парадигму" и "онтология" тоже претендуют на удаление из статьи про приложения БД.А чем же тогда поразить вероятного читателя статьи ? Дабы увидев эти слова, просветлился и понял, что не лох какой писал, а человек ученый...
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33073503
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну, с термином "парадигма" не все так плохо. Это просто *концепция*, *модель постановки проблем и их решения*. Термин часто применяется для большего наукообразия.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33073825
Фотография Jimmy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Андрей Леонидович
Лучше бы Вы, Jimmy, для начала, закрыли глаза на реляционную модель...
В Вашем примере можно увидеть две "естественные", как Вы выразились, сущности - Счет и День. И связь между ними

Счет - Имеет остаток на/За который имеется остаток по - День

с характеристикой связи "Остаток". И ничего здесь не натянуто даже с точки зрения бизнеса...


0. Насчет закрытия глаз на реляционную модель - не понял, извините.
1. Рекомендую взглянуть, к примеру, на документ/форму/отчет "Выписка по счету", "Баланс" и т.п. Любой из этих документов, столь любимых бухгалтерами - срез состояния счета/ов на определенную дату.
3. И, еще раз повторюсь, специально для Вас: "Хотя, как я понимаю, все дело в интерпретации" (с) Jimmy.
Т.е. можно привести массу аргументов в пользу любой модели, и все они будут достаточно разумными (равно как и массу контрагрументов).
4. Тем не менее, смею утверждать, что нельзя смешивать концепции проектирования OLTP систем и DSS систем, т.к. они решают разные задачи, и вот контекст этих задач имеет смысл назвать "парадигмой" или как-то еще.
Ни больше - ни меньше.
5. Исходя из п.3 думаю флейм нужно прекратить.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33073944
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ModelRУточнение. В Oracle Designer вложение А в Б означало "Каждое А есть Б" в смысле состава атрибутов, т.е. скорее это было наследование.
Хм. Боюсь, я лет шесть им не пользовался; за это время что-то могло поменяться, да и я могу ошибиться.

Что есть "означало"? Насколько я помню, я применял это для "технических детальных таблиц", например - мог вложить в клиента таблицу "телефонные номера клиента", привязанную к клиенту по FK, многие к одному, и не имеющую других ссылок. По этой ER-ке генерилась нормальная (ожидаемая мной) структура таблиц. Наследованием такое вроде бы не является :) Хотя не исключаю, что я по неведению использовал фичу не так, как предполагали разработчики. Но было весьма удобно :)
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33074402
Уважаемый Jimmy !

0. "Закроем глаза на "куб" и вообще любую многомерную структуру, кроме реляционной модели." Вот откуда взялось "закрытие глаз".
1. Ну зачем же "сопоставлять" представление сущностей в БД и представление отчетов пользователям ? Хотя в идеале, конечно, эти представления могли бы совпадать.
3. Все дело, скорее, в сути, а не в интерпретации.
4. Существуют прикладные системы, в которых OLTP и DSS работают на одной БД. Можно, и даже нужно, "смешивать концепции".
5. Исходя из п.3 флейм может и нужно прекратить, но не путь к истине. Наверное ?..
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33074473
Фотография Jimmy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Закроем глаза на "куб" и вообще любую многомерную структуру, кроме реляционной модели." Вот откуда взялось "закрытие глаз".

Весьма странный вывод. Структура куба (MOLAP) - вещь далекая от РСУБД. И рассуждать о его устройстве - дело неблагодарное, в рамках данной темы, во всяком случае.
Или, я просто не уловил Вашу логику?

Существуют прикладные системы, в которых OLTP и DSS работают на одной БД. Можно, и даже нужно, "смешивать концепции

ОК, по простому скажу:
1. "Звезду" можно свести к одной таблице (сущности?), денормализованной до 1НФ, при этом DSS система будет работать . Т.е. процессы получения необходимых отчетов и/или формирования куба не пострадают, а может даже ускоряться.

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

Это, по вашему, одна и таже концепция (или парадигма?) проектирования? Что-ж, не буду разубеждать.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33075557
1. Да, Вы не уловили мою логику. Вы предложили закрыть глаза на одно, а я Вам - на другое. Это была ирония, конечно - не нужно ни на что закрывать глаза...
2. Если проектируемая БД предназначена для решения и тех, и других задач, то те "концепции проектирования", о которых Вы говорили, конечно "смешиваются". При чем здесь "сведение к одной таблице" ???
У Вас должна быть хорошо нормализованная, и, одновременно, хорошо денормализованная ОДНА БД...

Поскольку автор темы ей уже не интересуется, и не захотел четче сформулировать "проблему" (обиделся, вроде как, непонятно на что), то и обсуждать нечего...
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33075612
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> обсуждать нечего...

Отчего же? Очень даже есть чего.

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

Imho member ModelR в [1550920] был к ответу на исходный вопрос ближе всего.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33075679
Нет, guest_20040621. ModelR тоже предложил (ДВАЖДЫ в упомянутом Вами сообщении !) "не вдаваться в вопросы" (чем это отличается от "закрывать глаза" ?). Он может быть образнее других указал автору на не четкую формулировку "проблемы". Это да...
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33075711
Илья(Phantom), если Вы еще "здесь".
Конкретные примеры схем БД для 2 и 3 на логическом уровне ничем не отличаются от аналогичных схем для 1. Надеюсь "товарищи на заграничных форумах" Вам уже объяснили, что:

1) в ООСУБД связи многие-ко-многим на логическом уровне представляются так же, как и в "Р"СУБД;
2) встраивание объектов осложняет (мягко говоря) доступ к встроенным объектам (сущностям), и, опять же, реализовано и в большинстве "Р"СУБД (то бишь теперь - О"Р"СУБД)...
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33076032
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Все, капец топику.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33076045
Фотография Павел Воронцов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
c127Все, капец топику.Весеннее обострение.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33076061
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Павел Воронцов
Я тут подумал, что Андрей Леонидович приобрел репутацию паленой водки: сначала столбенеешь, потом становится весело, но в итоге сильно тошнит.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33076072
Фотография Павел Воронцов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mir2 Павел Воронцов
Я тут подумал, что Андрей Леонидович приобрел репутацию паленой водки: сначала столбенеешь, потом становится весело, но в итоге сильно тошнит.Да, похоже. Вообще тут уже легенды об Андрее Леонидовиче ходят (как о местном Гайавате). Скольких участников форума он сподвиг на обширные цитаты из классиков! И каке цитаты, мммм! За что ему большое человеческое спасибо.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33076454
А может быть он уже сваял ПАРУ ФОРМУЛ ? Андрей Леонидович, ВЫКЛАДЫВАЙТЕ!!!
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33077135
x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
x
Гость
Откуда такая бурная реакция ?
Вроде человек говорит по делу, аргументирует и к своим предыдущим сообщениям не отсылает.

Некрасиво поступаете
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33077163
Фотография Павел Воронцов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
xОткуда такая бурная реакция ?
Вроде человек говорит по делу, аргументирует и к своим предыдущим сообщениям не отсылает.

Некрасиво поступаетеБог в помощь! Общайтесь. А я в сторонке постою пока.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33077196
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Павел Воронцов

Ну хоть бы раз постояли :)
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33077317
Фотография Павел Воронцов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
funikovyuri

:-) Постараюсь исправиться.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33078207
Ну наконец-то наши любимые настоящие профессионалы начали высказываться по существу темы. Но, похоже, поздно. Никого она уже не интересует...
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33078554
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
x
Откуда такая бурная реакция ?
Вроде человек говорит по делу, аргументирует и к своим предыдущим сообщениям не отсылает.

Некрасиво поступаете

Существуют некоторые, возможно, неписанные правила, как минимум в технических дискуссиях, нарушение которых предполагает подозрения в грубой пропаганде уличного типа. В митинговщине. Тем более их многократное и злостное нарушение. Тем более явный перебор. Кроме того, имеет значение чувство меры. Такие перлы как "беда с ключами" или "крах реляционной модели" в сочетании с плохо скрываемым желанием протащить на первые позиции какую-то непонятную не то СУБД, не то перманентный язык, с дореляционной объектной моделью данных (как Вам нравится названьице?), да еще функционирующей на платформе другой СУБД (Кеша) в сочетании с мумпосом делают свое дело.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33078869
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 x
>Откуда такая бурная реакция ?

Это продолжение старого разговора, почитайте если вдруг не в курсе. Разговор длинный, начало разговора тут, если не ошибаюсь: /topic/9021&pg=14

Как видно поначалу к известному персонажу отнеслись нормально несмотря на явную агрессивность оного.


Павел Воронцов mir2 Павел Воронцов
Я тут подумал, что Андрей Леонидович приобрел репутацию паленой водки: сначала столбенеешь, потом становится весело, но в итоге сильно тошнит.Да, похоже. Вообще тут уже легенды об Андрее Леонидовиче ходят (как о местном Гайавате). Скольких участников форума он сподвиг на обширные цитаты из классиков! И каке цитаты, мммм! За что ему большое человеческое спасибо.

Лучшая цитата ИМХО эта:
Alex.CzechСтарик Державин нас заметил и в гроб сходя благословил
/topic/9021&pg=52
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33079078
Сильно, все-таки, задело vadiminfo замечание его коллеги о том, что он, как и другие мои оппоненты, ведет дискуссию не корректно. Не стоит обижаться, мне кажется, и раздражаться из-за того, что знания в области РМД (а вовсе не каких-то других "экзотических" моделей данных) оказались, скажем так, не достаточными, и это, конечно, серьезно мешает моим оппонентам понимать и другие модели данных.
А ведь я от своего предложения не отказывался. Вы ведь из Обнинска, vadiminfo ? Я даже к вам готов приехать на семинар по "КЛЮЧАМ В РМД и ИДЕНТИФИКАТОРАМ В ОМД" (раз выяснилось, что еще рано сравнивать модели данных и "парадигмы отображения сущностей" в БД). Ну совсем уж узкая тема, и вроде бы всем хорошо известная. Я сделаю доклад (30 мин). Вы и Ваши коллеги зададут все вопросы, я на них отвечу (60 мин). Потом Вы сделаете доклад (30 мин), и ответите на мои вопросы (60 мин.). Подготовим согласованный отчет, и опубликуем его...
И, еще раз напоминаю, я здесь ничего не собирался и не собираюсь "протаскивать" и "навязывать". Я только сообщал о том, о чем другие участники дискуссии не знают, как мне казалось. И ход дискуссии в двух темах, в которых я участвовал, показал, что мои предположения оказались верными. Действительно не знают. А вот то, что и знать не хотят, оказалось для меня неожиданностью...
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33079120
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Леонидович
знания в области РМД (а вовсе не каких-то других "экзотических" моделей данных) оказались, скажем так, не достаточными, и это, конечно, серьезно мешает моим оппонентам понимать и другие модели данных.

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

Андрей Леонидович
А ведь я от своего предложения не отказывался. Вы ведь из Обнинска, vadiminfo ? Я даже к вам готов приехать на семинар по "КЛЮЧАМ В РМД и ИДЕНТИФИКАТОРАМ В ОМД" (раз выяснилось, что еще рано сравнивать модели данных и "парадигмы отображения сущностей" в БД).

Вы что думаете, что у Вас есть что-то новое по сравнением с тем, что Вы здесь сказали? Вы про ключи прочитали какие-то введения для начинающих или обрывки из середены, вырванные из контекста. Думаете, в этом есть польза, чтобы про это слушать? Полно нормальной литры - где все систематически изложено. Зачем мне какие-то сомнительные лекции? Что в ООМД не смотря на OID все еще нужны ключи - Вы не поняли. Не согласились и не привели технических доводов (не технические приводили, но они ничего, к сожалению, не стоят). Я привел, Вы не опровергли. Здесь на форуме. Вместо этого применяли приемы не имеющие к доказательствам тех вещей никакого отношения. Например, одурачить, заговорить зубы начальству - возможно для этого такие приемы годятся. Но здесь начальства нет, поэтому они не проходят.

Андрей Леонидович
Сильно, все-таки, задело vadiminfo замечание его коллеги о том, что он, как и другие мои оппоненты, ведет дискуссию не корректно. Не стоит обижаться, мне кажется, и раздражаться из-за того, что знания в области РМД

Образец не технического приема. Я, к примеру, не думал обижаться - нет знаний так нет. Но теперь дело представлено так, что Ваши доводы чего-то стоили. Но доказывать их не надо, потому что кто с ними не согласится у того нет знаний, и он обижается. Эти фарисейские приемы не дают пользы для решения технических вопросов. И пока не появятся сведения об оратном, лучше считать, что им место где-нибудь на маевке, а не форуме и тем более семинаре.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33079432
x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
x
Гость
Ну вот.
Опять съехали на обсуждение у кого провалы в образовании глубже и ширше, аргументы пропали, опять пошли ссылки на старые топики...
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33080827
Мимо пробегал настоящий боец. А какой дизайн сообщений ! Невозможно пробежать мимо...

Мимо пробегал ! Нам с Вами не нужно "ваять" никаких формул. Они "сваяны" более 30-ти (а, скорее, более 120-ти) лет назад. Вам нужно только понять, что дореляционная ОМД (понимаю, что прилагательное "дореляционная" бьет по самолюбию некоторых знатоков теории баз данных, но факты - упрямая вещь) включает и концептуальную модель окружающего мира (то есть это в первую очередь концептуальная модель, хотя она традиционно и называется "моделью данных"). В РМД "аналогом" стала попытка применения концепции ключей. Но не удалось (к сожалению) соединить математическую модель абстрактных данных (отношение) с концептуальной моделью то ли сущностей и связей, то ли только сущностей (ключи).
В ДОМД (чтобы не путать с ОМД на принципах ООП) используются объекты и связи между ними
M={O,R}, O={o}, R={r}
Это придумал не я. Изучайте теорию баз данных, а не формулы.
Объект (перечитайте известную Вам дискуссию в части моего "спора" с U-gene, чтобы освежить в памяти что такое абстрактные и конкретные объекты) представляется идентификатором (это идентификатор объекта, а не экземпляра !), именем, способом конкретизации экземпляров (идентификации) и (не обязательно) набором характеристик
o->(io,no,k,{ho})
Это придумал не я. Изучайте теорию баз данных, а не формулы.
Связь представляется идентификаторами связываемых объектов, идентификатором связи, именами связей в обоих направлениях и (не обязательно) набором характеристик
r->(io1,io2,ir,n1,n2,{hr})
Это придумал не я...
Характеристика (и объекта, и связи) представляется идентификатором, именем, типом и другими атрибутами в зависимости от реализации самой ДОМД и реализации типов
h->(ih,nh,th,{atr})
И это тоже придумал не я...
Ну а собственно экземпляры объектов и связей я уже "формулизовывал" не один раз, как и стандартные операции манипулирования...
Ну вот, примерно в десятый раз "представили" ДОМД. Чтобы понять ее мощь нужна, конечно, практика. Причем сравнительная. У меня она есть. А у Вас, вероятно, нет. До сих пор я не встречал ни одного приложения, для которого РМД могла бы использоваться хотя бы на равных с ДОМД...
Извините, но, мне кажется, Вы не знаете элементарных вещей. Или делаете вид что не знаете ?..
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33080842
У меня есть не новое, vadiminfo. Дело в другом. Видимо такой способ общения почему-то "подталкивает" Вас к тому, чтобы извлекать из того, что пишется, только то, с чем Вы можете "справиться", и в чем ощущаете себя знатоком. Уверен, что Вы порядочный человек. И серьезный. И при живом общении такие приемы отпадут сами собой. Если же Вы считаете, что как раз я человек не порядочный, и со мной нельзя иметь дела, то тогда да - нет смысла со мной что-то обсуждать...
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33080850
Я свои аргументы по существу обсуждаемой "проблемы" привел. И всегда готов к конструктивному обсуждению.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33080885
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Андрей Леонидович
У меня есть не новое, vadiminfo. Дело в другом. Видимо такой способ общения почему-то "подталкивает" Вас к тому, чтобы извлекать из того, что пишется, только то, с чем Вы можете "справиться", и в чем ощущаете себя знатоком.


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

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

Андрей Леонидович
Я четко показал, скрупулезно анализируя, в частности, работы Кодда и Дейта, почему именно "беда с ключами"

Ну если только скурпулезным считать что-то вырванное из контекста. Особенно интересно, что Вы верите, что они бы не увидели этой беды, а Вы показали. Да и само словосочетание какое-то не техническое. Это впору на ферме какой-нибудь дояркам втюхивать.


Андрей Леонидович
И эти выводы (конечно же !) никак нельзя "применить" ни в "Р"СУБД, ни в О"Р"СУБД...

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


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

Обращаю опосредованно, через труды более продвинутых, чем я. Что же мне чтобы теорию множества изучать, обязательно труды Кантора читать? Их переработали и систематизировали. Я не собираюсь проделывать эту работу за тучу докторов и педагогов. Вы вон читаете сами, а что получается? Все наоборот Вы там поняли. Вы еще Евангилие сами почитайте и истолкуйте. Этому надо учиться лет 10.

Андрей Леонидович
А ответить нечем.

Ну и про что после этого говорить? Если у Вас после всего поворачивается язык на такое. Вы так запросто черное белым называете не моргнув глазом.


Андрей Леонидович
Если же Вы считаете ... и со мной нельзя иметь дела, то тогда да - нет смысла со мной что-то обсуждать...

Вот я Вам 10 раз уже говорю, что Ваши методы вести дискуссию не могут дать ничего рационального в технических вопросах. Нагибать юзеров на корявую систему, возможно, они подойдут. Или начальству запудрить мозги. Возможно, поэтому Ваша ДОМД еще не канула в лету.
Если же у Вашей точки зрения есть солидные источники, дайте ссылку на литературу. Мож хоть там аргументы реальные. Тока не подбрасывайте сайт Вашей фирмы. Я его обозревал, и остался весьма недоволен.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33081087
Ничего я Вам не собираюсь подбрасывать...

"Вы тут пытались проталкивать"
"Это впору дояркам на ферме втюхивать"
"Возьмите любую известную МД повыкидывайте из нее много, чего, а к названию припишите "Д""
"Я не собираюсь проделывать эту работу [прочитать работы Кодда - А.Л.] за тучу докторов и педагогов"
"Нагибать юзеров на корявую систему"
"Начальству запудрить мозги"

И все это в одном сообщении...
Согласен, vadiminfo - Ваши методы вести дискуссию (в отличие от моих) "рациональны в технических вопросах". Очень рациональны...
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33081144
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 vadiminfo
Парень, брось. Тут чем больше будешь спорить, тем больше распалишь товарища. И сам распалишься. Вспомни, как надо с нездоровыми обращаться: тихо, мирно, а лучше вообще игнорировать.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33081225
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
2 x

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

Ссылки еще никому не мешали. Повторение - мать учения. (С)

Если Вы не Андрей Леонидович, прочитайте те дискуссии, особеенно в начале, когда Андрею Леонидовичу, не разобравшись, еще пытались отвечать аргументированно. Статью Андрея Леонидовича тоже почитайте, на которую там ссылаются, о том что объект есть противостоящее субъекту в его какой-то там деятельности. Выскажите свои конкретные соображения, только конкретные, а не "у него аргументы, а у вас ссылки".

Если Вы Андрей Леонидович, тоже прочитайте те дискуссии, это необходимо, у Вас стек переполнился.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33081295
int23
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
softwarer Int23А почему "звезда" описывает одну сущность в строке таблицы фактов?
И в строке таблицы измерений тоже. Единственно, принцип несколько нарушается с иерархиями в строгой звезде.

Int23Ведь там же множество внешних ключей на размерности?
И чему это противоречит?

Допустим, я живу возле м. Сокол. Это - атрибут меня как сущности. Но само м. Сокол вместе со всеми его рельсами, поездами, сотрудниками, Ленинградским шоссе над и домами вокруг - моим атрибутом не является.


Я с Вами согласе, но кому будет понятно то, что Вы живёте возле метро с кодовым названием 123.


softwarer
Int23И получается что одна строка содержит только ничего не значащие значения (внеш. ключи). А сами данные требуется получать из других таблиц. Так или я что-то не попимаю?
Полагаю, Вы глобально заблуждаетесь.

В первую очередь, строка таблицы содержит не столько внешние ключи, сколько значения, measures. Скажем, для факта покупки - сумму покупки. Таблицы фактов, все атрибуты которых являются измерениями - вырожденный случай; я такого, пожалуй, никогда не встречал. Можно, конечно, сделать сумму покупки измерением - но смысл?

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

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


Опять же не согласен с Вами. Когда разрабатывается база данных, она предназначена для решения задач конкретной предметной области. А при описании предметной области пользователи используют привычные для них понятия (например названия районов), а уже в базе данных внешние ключи заменят названия. И разве после выполнения очередной задачи, например для выборки "десять районов с наибольшим объемом продаж" вы вернёте аналитикам таблицу с 2-я столбцами (Код района, Объём продаж).
Мне кажется, что вообще не стоит говорить об отображении сущность-строка таблицы, так как это будет нарушение 1НФ.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33081438
x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
x
Гость
c127Ссылки еще никому не мешали. Повторение - мать учения. (С)Мать ..шу. Ну начинайте на пару копипастить до полного прояснения. Он свое, вы свое.

Предлагаю воздержаться от повторов и отсылок к старому

c127Если Вы не Андрей Леонидович, прочитайте те дискуссииЯ, конечно, не Андрей Леонидович - он за псевдонимы не прячется
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33083006
Не врите с127. Люди же могут действительно почитать...
Аргументированно не "пытались", а всегда вели диалог лишь несколько (громко сказано) человек. А Вы, как и большинство других участников "диалога", ничего никогда не аргументировали...
И обострение у таких людей как Вы и mir, мне кажется вовсе не весеннее, а перманентное...
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33083050
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Андрей Леонидович>Аргументированно не "пытались", а всегда вели диалог лишь несколько (громко сказано) человек.

Явное переполнение стека, ничего не помнит.

x>Я, конечно, не Андрей Леонидович - он за псевдонимы не прячется

-Мастер?
-Первый разряд.
-А бъете как мастер.
(С)

Рассуждаете как мастер, отсюда и подозрения.

Ссылки уже почитали, со Статьей ( http://www.informx.ru/seminar1.htm ) и ее обсуждением ознакомились? Зачем зря языком болтать, выскажите свои возражения по обсуждаемым вопросам, если есть что сказать.

Там, например, обсуждались такие вопросы. Андрей Леонидович утверждает что статья очень хорошая. В этой статье дано определение объекта: "Объект — все, что противостоит субъекту в его предметно-практической и познавательной деятельности." Но определения субъекта в статье нет и нет ссылки на такое определение. Т.е. определение бессмысленно. Это даже не касаясь содержания определения. Что Вы можете сказать о научной статье, в которой в одном из основных определений допущена такая ошибка? Что можно сказать об авторе, который эту ошибку упрямо не признает и не приводит по этому поводу никаких аргументов вообще?

Совершенно конкретные вопросы. Хоть что-нибудь по-существу можете сказать об этом?
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33083199
с127 продолжает врать (я никогда не писал никаких статей на тему сравнения моделей данных и СУБД, а один из моих докладов на семинаре, о котором, видимо, идет речь, очень хорош, но с127 его почему-то послушать не захотел, и на семинар в далеком 1999 году почему-то не пришел; я уж не говорю о том, что мои взгляды с тех пор конечно изменились, причем в худшую для РМД и "Р"СУБД сторону), а мы продолжим по существу...

softwarer: "Таблицы фактов, все атрибуты которых являются измерениями - вырожденный случай; я такого, пожалуй, никогда не встречал."

А я использую при проектировании такие составные объекты (по Вашему - талицы фактов). Например, несколько упрощая

Материал под ответственностью МОЛа в подразделении (A) <- Имеет остатки на конец -> Период (B)

с соответствующими характеристиками связи.

Здесь объект A имеет только ссылки на объекты Материал, Человек, Подразделение. Удалить (ведь речь идет о приложениях, в которых решаются и OLTP, и DSS(OLAP)) ОДИН экземпляр объекта Период удобнее и эффективнее, чем сотни тысяч экземпляров объекта в варианте с интеграцией объекта Период в составной объект. Или миллионы, если поддерживаются еще и связи

Материал <- Имеет остатки на конец -> Период
Партия материала <- Имеет остатки на конец -> Период
ТТН <- Имеет долг на конец -> Период
...
...
Рейтинг: 0 / 0
79 сообщений из 79, показаны все 4 страниц
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / вопрос по парадигмам БД
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]