автор
можно считать её(OLAP) БЗ

Но лучше считать хранилищем данных, так как OLAP одна их технологий для работы с хранилищами данных. Ни в литературе, ни в доках пока не встречалось, чтобы это связывалось с БЗ. Хотя кто-то может написать такое и в книгах. Иван FXS назвал РБД базой знаний. Жаль, что не придумали термин БИ база интеллекта и другие. Поэтому от перегрузки страдает БЗ.

Иван FXS

- извините, базой знаний я назвал не "РБД", а "специальным образом организованную и специальным образом используемую РБД"!


Но "специальным образом организованнуя и специальным образом используемуя РБД" - частный случай РБД. Т.е. это конкретная модель класса РМД или проще просто РМД модель.
Это означает на самом деле, что не только для ЛЮБЫХ знаний, но и для ЛЮБЫХ данных, может хуже подойти, чем конкретная модель для другой конкретной ПО. Вы ослабили типизацию. Теперь к примеру кто-то напишет "Сократ прожил 70 лет", где вместо цифры 0 , буква О. Теперь кто-то захочет посчитать средний возраст всех выдающихся деятелей. Что он получит? Т.е таблица "Выдающийся Деятель" с полями "ФИО" и "Прожил" - второе типа NUMBER подойдет лучше.
Я уже не говорю, что каждый раз при проектировании БД учитываются примерно инфо потребности и конкретные запросы. Это учитывается при структуризации. А у Вас одна структура на все случае жизни:
Records, Fields и Values.
Кроме того, модель РМД включает компоненту манипулирования данными. И у Вас только она и есть, структуры - таблицы и поля фиксированы. А Вам нужна модель знаний, которая бы включала компоненту манипулирования знаниями с целью получения новых знаний.
Аналогичные Вашей идеи появляются периодически. Но объявляются не БЗ, а универсальной БД или гибкой системой. На деле оказывается не выразительной, так как остаются в рамках РБД и в силу сохранения материи не могут превзойти с помощью тольео ее средств, но вносят ограничения. Например у Records, Fields и Values фиксированы, а просто в РМД разработчик не ограничен конкретными полями в период проектирования.

Иван FXS
- дополнения к языку, - именно к ЯЗЫКУ, а вовсе не к системе ХРАНЕНИЯ данных в РЕЛЯЦИОННЫХ ТАБЛИЦАХ, - позволяют выйти за пределы РМД ... Вы согласны с этим?



Это относится к вопросам РМД, а мы с Вами решаем вопрос про БЗ. Что касается РМД, то Дейт, например, считает, что SQL извращает РМД. С другой стороны есть базавая РМД, а есть ее расширения, которые никто строго формально не зафиксировал, последнее расширение внесением средств ООП называют ОРМД. В последнее время появился термин универсальный сервер - туда включили элементы других моделей данных, хотя базовой остается РМД. Но все это пока БД, хотя могут интерпретироваться как облее сложные знания чем, просто свойства и состояния объектов.

автор
Извините, круг замкнулся, мы с этого начинали.
Я говорю: программа на языке С - это "специальным образом организованный и специальным образом используемый" текст,
а Вы говорите: программа на языке С - это "частный случай" текста :-(

Нет. Вы говорите, что внутри С создали какие-то структуры, которые позволят больше, чем сам С. Т.е. другие структуры, кроме Ваших не нужны, но теперь можно не только все что может С, но и создавать программы искусственного интеллекта. Т.е. позволяет решать задачи не поддающиеся алгоритму. В этой аналгии структуры соответствуют схеме РБД, а искуствеенный интеллект - БЗ. А я в этом не уверен. Хотя я к аналогиям отношусь как к не очень удачным в плане строгости при доказательствах. Поэтому в первый раз не стал обращать внимание на Вашу аналогию с С.
автор

- "ЛЮБЫЕ данные" в "конкретную модель для другой конкретной ПО" - ПРОСТО НЕ ВСТАВЯТСЯ! Для КОНКРЕТНЫХ данных, СПЕЦИАЛЬНО ОТОБРАНЫХ под "конкретную модель другой конкретной ПО" - конечно - "конкретную модель"будеь работать лучше ... ну и что?


А то что данные с интерпретацией - это еденицы знаний, простейшие знания. Т.е. даже для простейших знание ухудшение в этих структурух. Что уж говорить о сложных знаниях?

автор
- да, ослабил ... в том смысле, что СТРУКТУРА базы теперь не обеспечивает строгой типизации, ее должна обеспечивать НАДСТРОЙКА.
А вот пример - неудачный: при импорте "Сократ прожил 70 лет" в ([Сократ], [прожил , лет], 70) - значение 70 должно попасть в таблицу vNumberS, там никакие буквы О не прокатят :-(



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

автор

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



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


Это гипнотизирует не только меня. Ведь зачем нужны компы? Чтобы что-то получать. Из данных данные. Из знаний знания. А что же еще? Из данных и текстов знания, уже готовые? Или их приращения в виде фактов, занесенных операторами? Или у Вас эксперты буду заносить свои знания? Но тоже фиксированные. Но это было и называется по другому.
автор
- а что, аббревиатура УБД мне тоже нравится ... она такая же неопределенная, как и БЗ, такая же метафорическая, а если термин еще не занят - возможно, от него будет польза ... Я его беру ;-)


Вы отказываетесь от термина БЗ? Он входит в систему СУБЗ, которую раньше иногда называли система искусственного интеллекта. Если Вы отказываетесь то, нам легче будет выяснить чем универсальная БД хуже обычной.

автор
- точно: разработчик - не ограничен конкретными полями в период проектирования ... лучше не скажешь! А мне нужно, чтобы ПОЛЬЗОВАТЕЛЬ был "не ограничен" - в период ЭКСПЛУАТАЦИИ!



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

автор

- нет, выход за пределы - не относится к вопросам (ВНУТРЕННИМ вопросам) того, за пределы чего, мы выходим ...

Но я Вам пытался сказать, что войти в ее пределы тоже не просто и от того оказаться за ее пределами тоже легко, смотря что под этими пределами понимать. Возьмите клиппер и его не все признают РСУБД. Дейт SQL - признает РМД. Но это все относится к базам данных. Но сначало надо разобраться с БЗ.
Поскольку БЗ вызодит за пределы любых БД, поэтому ,что толку выяснять выход за пределы РМД? Ну там будут другие БД. Вы же не думаете, что за пределами РБД сразу начинается БЗ?

Извиняюсь. Забыл исправить автор на Иван FXS. На работе пишу - в стеснных временем обстоятельствах.

Иван FXS
Неужели Вы думаете, что "зашивать" СОДЕРЖАТЕЛЬНЫЕ ограничения на значения, которые могут иметь те или иные предикаты, - зашивать их в структуру таблиц - это эффективно? Очинтресно, какое ограничение на значение поля "возраст" Вы вмонтируете в таблицу Persons? (А у меня - оно будет ДИНАМИЧЕСКИМ ...)

Не зашивать в структуру таблиц, а накладывать ограничения на возможные значения колонки в данном случае. Ограничения целостности, как и средства манипулирования данными в РМД согласованы. Ограничения целостности можно менять без изменения структуры в РМ. Поэтому оно есть ДИНАМИЧЕСКОЕ. Просто у Вас кто это будет делать в каждом случае динамически и как?
Иван FXS
вопроса не понял: ограничение на возраст действительно только для значений предиката [возраст] - в чем тут проблема?

Ну, я имел ввиду если другая запись "Сократ любил яд Кураре". То для Кураре ограничение 200 ничего не даст. Там ограничение для предиката Любить уже ведь другое надо. Как Вы описывать будете эти ограничения? В РМД при каноническом проектировании БД такого типа ограничения реализуются декларативно.

Иван FXS
- не верно! Я уже писал: СУБД как инфраструктура, ка технология работы с данными, хранящимися в "связанных таблицах", - мне подходит.
Мне НЕ подходит каноническая онтологическая интерпретация БД ... точнее - наоборот: мне не подходит канонический способ отображения предметной области в БД, который требует, чтобы для каждого класса объектов в базе данных имелась ОДНА ОТДЕЛЬНАЯ таблица ...


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

Иван FXS
- знаете, это звучит очень наивно: "получать ... знания". РАБОТАТЬ с данными и со знаниями: хранить и обрабатывать их - это, конечно, более общая формулировка, но при том - более адекватная, ИМХО.



Адекватная? Т.е. выводить из одних знаний другие - это наивно, а хранить и обрабатывать - это адекватно в контексте систем БЗ? А что подразумевается под обрабатывать? Находить в текстах? Ну Ворд найдет еще и синонимы и ошибки. Что же доки не торопятся назвать БЗ? Точнее такие попытки объеденных документальных и фактографических БД называть БЗ были. Но они сошли на нет. Ведь имеет значение прагматическая сторона. Необходимо, чтобы не эксперт, а лицо принимающее решение могло получить это решение( или их совокупность с оценкой выигрышей и рисков). Иначе будет разочарование от системы БЗ. Выяснится что это все те же Access + Word или еще хуже - только одно из них. Можем мы себе позволить так дискредитировать высокие идеи?

Иван FXS
- да, будут заносить ... не вижу разницы: из документа знания или "из эксперта" ;-)
Да, - фиксированные ... ПОСЛЕ того, как они зафиксированы, знания СТАНОВЯТСЯ фиксированными

Знаете, я тут в связи с этой дискуссией почитал из истории про системы БЗ.
Там одна группа пыталась использовать ПРОЛОГ. Но у него один из недостатков - фиксированные способы вывода знаний. А вы говорите о фиксации самих знаний, т.е. не предполагаете никакого вывода новых знаний, даже фиксированного.


Иван FXS
- я готов не употреблять его в дискуссии С ВАМИ, поскольку у Вас с ним связано что-то уж очень "сокровенное" ;-)



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

Иван FXS
- на искусственный интеллект я не претендую ... в этом топике - уж точно! Эта тема для меня - намного более "практическая" ...



Лишний довод в пользу осторожности в использовании таких сильных терминов как БЗ.

Иван FXS
- только чем хуже? А чем лучше - не будем выяснять? А как ее строить наиболее эффективной - тоже не будем?

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

Иван FXS
- зато он, по крайней мере СМОЖЕТ РАБОТАТЬ ... поскольку не получит отлуп от программистов, типа: "Вам не подходят СУБД для Ваших задач" :-(




Не скажите. Это не так все очевидно. Я про СМОЖЕТ РАБОТАТЬ. На жизненный цикл ИС оказывают влияние разные факторы. Первые ИС в 60 тоже смогли работать, но не долго. Наступило быстро разочарование. Даже появился термин - Депрессия программного обеспечения.

Иван FXS
- поскольку тут Вы говорите, очевидно про СВОИ БЗ, БЗ в Вашем понимании, то ... тут я - пас.



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