Иван FXS
Кто-нибудь из присутствующих интересуется темой БЗ (KB), - в аспекте: как можно это реализовывать средствами MS Access?

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

Народ иногда называет базы данных базами знаний, так как последнее более громко звучит. Наверное, можно считать БД Знанием фактов. Управляла СУБД базами данных как-то столько лет, а теперь пусть и базами знаний поуправляет. Какая разница? Микрософт бы обрадовался, если Access объявили СУБЗ. Все Ораклы, DB2, SQL Server и прочие умерли бы только от одной зависти. Хотя с другой стороны много ли надо? В принципе заменить SQL на Пролог или какой другой логический язык, еще кое-что там подправить. Реляционную модель данных на какую нибудь модель знаний. В идиале научить ее решать задачи искусственного интеллекта. И так по мелочам еще чего туда добавить.

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

Иван FXS
Вы не хотите меня понять: точно так же, как в текстовом файле мы можем создавать и хранить не только "просто текст", но и, например, программы на языке С (или - XML-данные), - точно также в mdb-файле мы можем хранить не только "просто" базы данных, но и содержимое, котороя - благодаря некоторым ДОПОЛНИТЕЛЬНЫМ КОНВЕНЦИЯМ - будет выражать некое ДРУГОЕ, более мощное содержание!


В файле текстовом или нет программы - данные для компилятора. Для человека это программы, а в текстовом файле могут быть знания про базы знаний, например. От этого их совокупность останется данными для компа, до тех пор пока он не будет способен выводить новые знания. Вот если бы он мог вывести из этого как можно построить СУБЗ, тогда другое дело.
Когда речь о БЗ заходит, то имеется в виду, как правило, что не человек, а комп будет обрабатывать знания и получать новые знания. Т.е. эксперты будут заносить свои знания в каком-то виде, и на основе этих знаний система выдаст решения по запросу. Хотя доки про учебники формально можно назвать, наверное, БЗ. Но какая от этого польза?
У ACCESS есть команда создать БД. И уже в силу этого независимо от ДОПОЛНИТЕЛЬНЫХ КОНВЕНЦИИЙ это будет БД. БД - это большое достижение в инфотехнологиях, которое обеспечил значительную производительность приложений. Но БЗ еще большее должно быть. Вообще использование ACCESS для чего-то другого выглядит как использование средства не по назначению. Типа автомобиля для полетов.

Иван FXS
Долнительные конвенции (формализмы) - это, конечно, важно: для человека, не знакомого с XML-конвенциями, XML кажется просто текстом ... малоосмысленным текстом, перегруженым зачем-то символами ">" и "<".

БЗ - это не тогда, когда в компе БД, а то что там про что-то знания у человека в голове. Все должно быть в компе. И преимущество БЗ в том, что не важно, что кажется для человека, не знакомого с XML-конвенциями. Этот человек напишет команду и получит готовое решение, без всяких специальных знаний. Например, поставить символы ">" и "<" в нужных местах (шутка). Более сложные решения - не из программирования или форматирования. Хотя и там не всегда правильная подсказка ошибок. В БЗ должна быть правильная, так как на основе опыта туда смогли занести и эвристические знания. А система их обработает и выдаст и то, чего не знали разработчики.

Иван FXS
То есть - на Ваше "это все все-равно относится к БД" - я отвечаю: а XML при таком подходеь "все-равно относится к" тексту :-(



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


Иван FXS

Конечно, сделать "полнофункциональную" БЗ сложно ... тем более - в MS Access, но я пытаюсь делать - и обсуждать - ЭЛЕМЕНТЫ парадигмы БЗ, ПРИБЛИЖЕНИя к ней, которые можно реализовывать в рамках СУБД-среды ... даже в MS Access. То, что никто здесь не готов обсуждать эту тему ПО СОДЕРЖАНИЮ, это ... скажем так ... весьма любопытный феномен!


"полнофункциональную" БЗ скорее всего не возможно сделать не только в MS Access, но например, и В ОРАКЛе, который поддерживает не только XML, но и средства по обработке текстов.
Согласно "такого подхода" (традиционного), скорее всего, надо начинать приближаться не к БЗ, а к СУБЗ. Ведь тогда создание БЗ превратится в нечто обычное. А так это в плане технологий ничего не меняет. Возможно, кто-то объявил свои продукты СУБЗ. Тогда, наверное, лучше их использовать, чем MS Access. Хотя бы эти разработчики будут считать, что Вы создали БЗ. А так ни те ни другие.

Иван FXS
Но очевидно, что - прежде, чем "обрабатывать и получать новые" - система должна быть способна ВОСПРИНЯТЬ и ХРАНИТЬ знания, причем - не в свободной форме (текстовой, например: "доки про учебники формально можно назвать, наверное, БЗ. Но какая от этого польза?") , а - в структрированом виде. Вот эту БАЗОВУЮ функцию СУБЗ я - на данном этапе - и обсуждаю.

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

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

Иван FXS
как соотносятся БЗ и СУБЗ - я думаю - все здесь понимают

Вот и хорошо, что понимают. Access - СУБД. С помощью него трудно получить СУБЗ. Т.е. его нужно самого тогда переделать из нутри, но с помошью С скорее всего.

Иван FXS
ву-а-ля: знание - это фиксация того, что ... либо:

Вопрос о том, что такое знание поднимался специалистами по БЗ. И вывод примерно тако: что такое "знание вообще" Вам не скажет никто - это слишком обширное понятие. Однако формальная логика дает представление о некоторых формах мысли: Понятие, Суждение и Умозаключение. В, частности, примеры Аристотелевских суждений: Все S являются P, Никакой из S не является P и т.д.
Иван FXS
а. у объекта О имеется свойство P и его значение равно V,

В лучшем случае соотносится с понятием, которое характеризуется своими признаками. На самом деле описание чего-то, что и относится к области БД.
Т.е. это факты.
Иван FXS
объекты O1,O2,... On находятся между собой в отношении R

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



Иван FXS
Уверяю Вас, если мы научимся вот так понимаемые знания хранить - в вот так структурированном виде, то ... будет нам счастье!

Я бы хотел осчастливиться, но так понимаемые знания уже умеют хранить и обрабатывать. А счастья все еще нет. Это делают СУБД. В этом плане использование СУБД Access уместно, но ничего не дает нового в плане БЗ.

Иван FXS

a. базовые технологии СУРБД = реляционное связывание таблиц по ключевым полям, - и

Вы слишком упрощаете. Это всего лишь один из аспектов. Там есть, например, реляционная алгебра. Что существенно для получения результатов. А ведь ради этого получения информации весь сыр бор.
Иван FXS

онтологическую ИНТЕРПРЕТАЦИЮ этих таблиц, определяющую то, как соотносятся таблицы СУРБД с отображаемой в базе ОБЪЕКТНОЙ РЕАЛЬНОСТЬЮ.

Любая модель должна обеспечивать механизм интерпретации, иначе она не модель. Вроде все это различают, и мы последуем их примеру.

Иван FXS

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


Вообще РСУБД поддерживает реляционную модель данных (РМД). Т.е. это Каноны РМД. А Вы хотите создать другую модель данных в рамках РСУБД, но которую последняя поддерживать не обязана. Но пока это еще модель данных, а не знаний.
Иван FXS
В СП заводится отдельная таблица для каждого класса (типа) отображаемых объектов

В KB8 – каждому типу (классу) объектов соответствует запись в таблице ContextS (в первом приближении; есть нюансы, о которых - позже)


Пока это означает, что в Вашей БД будет храниться информация о классах. Ну, такая БД может быть полезна в ООП, например. Т.е. ПО – проектирование программного обеспечения.
Иван FXS
. В СП - для каждого типа объектов – может отображаться только ФИКСИРОВАННЫЙ набор свойств объекта и его отношений с другими объектами (другими типами объектов)

. В СП свойства объектов зафиксированы как поля таблиц, т.е. как элементы структуры БД



На то РМД и относится к классу структурированных моделей данных. Но есть полу структурированные модели данных - XML. Но все равно данных, а не знаний.
Иван FXS
В KB8 – к каждому объекту можно присоединить любой (неограниченный) набор свойств (и отношений), создавая новые контексты

В KB8 свойства объектов – это записи в таблице FieldS, то есть набор свойств поддерживается ДИНАМИЧЕСКИ.



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