Тема: ? Схема БД

Коллеги,
пишу небольшую локальную систему для хранения музейной информации. Хотелось бы использовать элементы онтологической идеологии. Кто-нибудь может подсказать источник, где можно посмотреть схему реляционной БД для хранения онтологий? Достаточно упрощенной схемы для хранения классов с простым наследованием, отрибутов и триплетов.

Thumbs up Thumbs down

2

Re: ? Схема БД

на форуме онтологов в презентации по protege была схема БД для хранения OWL
http://shcherbak.net/2010/08/forum-onto … hi-onlajn/

Re: ? Схема БД

Shcherbak пишет:

на форуме онтологов в презентации по protege была схема БД для хранения OWL
http://shcherbak.net/2010/08/forum-onto … hi-onlajn/

Нашел там только вот это:
http://i768.photobucket.com/albums/xx323/chvlad/-.png

В таком виде это сложно переложить прямо в SQL. Лучший вариант нашел тут: http://www.dis.uniroma1.it/~degiacom/di … sitory.pdf

Thumbs up Thumbs down

4

Re: ? Схема БД

Вариантов может быть много, например,  на сайте графити и самиздата выложена схема БД
http://semanticfuture.net/index.php?title=Graffiti

Re: ? Схема БД

Shcherbak пишет:

Вариантов может быть много, например,  на сайте графити и самиздата выложена схема БД
http://semanticfuture.net/index.php?title=Graffiti

Схемы на указанном ресурсе не нашел (хотя, за ссылку - спасибо - интересно).

Thumbs up Thumbs down

6

Re: ? Схема БД

по ссылке обзор графити, а схема на сайте разработчика ( Дмитрия Бородаенко). Кстати его раздел на нашем форуме здесь http://forum.semanticfuture.net/viewtopic.php?id=58
А схема лежит в разделе документация
http://samizdat.nongnu.org/diagrams/samizdat_database.png

Re: ? Схема БД

Shcherbak пишет:

А схема лежит в разделе документация...

Я внимательно посмотрел документацию на Graffity (кстати, многие ссылки на сайте разработчика - не рабочие). Приведенная Вами схема - это не схема хранения онтологии, а скорее схема организации хранения данных CMS. Точнее, хранение онтологических данных в ней редуцировано до трех таблиц. И это странно.

Отредактировано Владимир (2010-10-27 22:21:24)

Thumbs up Thumbs down

8

Re: ? Схема БД

Классическая схема хранения RDF конструкций (триплетов) - три таблички - объект - атрибут - значение (субъект-предикат-объект) или тоже только в виде трех полей одной таблички, например, в документо ориентированных БД.

В основном любая онтология может свестить в плане хранения к трем табличкам.
Правда, Некоторые триплесторе используют четыре поля - квады - например, виртуозо. Об особенностях хранения данных в виртуозо, если захочет, расскажет Иван Михайлов.

9

Re: ? Схема БД

Про Виртуозу в данном контексте неинтересно. Чтобы нашу схему использовать с хорошей производительностью, надо и наши расширения SQL использовать.

10

Re: ? Схема БД

Иван, насколько я понял Владимира, речь идет о рассмотрении типовых вариантов построения семантических хранилищ. О последних ноухау никто не говорит.

11

Re: ? Схема БД

Наша схема без "выпендрёжей" будет совершенно непрактична, вот ведь проблема.
Табличка Graph-Subject-Predicate-Object --- многократно изобретённый велосипед, вот только последнее "колесо" у всех разное. Колонка(или несколько колонок) для Object сильно ограничивается в размерах (ибо многократно дублируется в индексах), и в то же время должна содержать как можно больше информации о литерале. Вокруг этого технического противоречия все и пляшут с бубном. Без поддержки в SQL большого выбора нет, надо просто нумеровать все различные литералы в отдельной таблице (если есть тип данных any, то все нечисловые литералы).

(Мы тоже пляшем, но немножко отдельно от остальных. Если загрузить RDF-представление квалификационной базы TPC-H в Virtuoso 7, то получается плотность примерно 6.1 байта на квад. Никак русский текст про это не допишу)

Re: ? Схема БД

Shcherbak пишет:

Классическая схема хранения RDF конструкций (триплетов) - три таблички - объект - атрибут - значение (субъект-предикат-объект)...

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

Shcherbak пишет:

...или тоже только в виде трех полей одной таблички, например, в документо ориентированных БД.

Вот, хотелось бы понять какая архитектура БД более правильная - разнесенная по таблицам или совмещенная в одной. К примеру и иерархию классов можно хранить в одной таблице классов, используя в записи спец. поле  (типа parent), либо же таксономию выделить в отдельную таблицу, где хранить пары parent->child.

Shcherbak пишет:

В основном любая онтология может свестить в плане хранения к трем табличкам...

Мне думается, только, если в ненормализованном виде. По крайней мере надо же как-то отделить описание тех же классов от самих объектов этих классов?

Thumbs up Thumbs down

Re: ? Схема БД

iv_an_ru пишет:

Про Виртуозу в данном контексте неинтересно. Чтобы нашу схему использовать с хорошей производительностью, надо и наши расширения SQL использовать.

Лично мне - довольно интересно.  smile

Thumbs up Thumbs down

Re: ? Схема БД

iv_an_ru пишет:

Наша схема без "выпендрёжей" будет совершенно непрактична, вот ведь проблема.
Табличка Graph-Subject-Predicate-Object --- многократно изобретённый велосипед...

А, что хранит поле Graph? Похоже я начинающий велосипедист smile

Thumbs up Thumbs down

15

Re: ? Схема БД

Владимир пишет:

А, что хранит поле Graph? Похоже я начинающий велосипедист smile

Идентификатор ресурса, которому принадлежит трипл subject-predicate-object, хранимый в этой строке.

Re: ? Схема БД

iv_an_ru пишет:
Владимир пишет:

А, что хранит поле Graph? Похоже я начинающий велосипедист smile

Идентификатор ресурса, которому принадлежит трипл subject-predicate-object, хранимый в этой строке.

В смысле, что-то типа hasAuthor?

Thumbs up Thumbs down

Re: ? Схема БД

В итоге, учитывая ограничения задачи пришел вот к такой схеме:

http://i768.photobucket.com/albums/xx323/chvlad/ontoevis.gif

Thumbs up Thumbs down

18

Re: ? Схема БД

Если у каждого класса есть subclass и superclass, то зачем их выносить в отдельную таблицу?

Тоже, range мне кажется лишней если она только посредует dataProperty и dataType (разве что у dataProperties[id] может быть несколько разных valueDataTypes)

Отредактировано sasha (2010-10-31 05:40:15)

Re: ? Схема БД

sasha пишет:

Если у каждого класса есть subclass и superclass, то зачем их выносить в отдельную таблицу?

Спасибо, что обратили внимание на мой творческий поиск! smile
Отдельная таблица, по моему разумению, позволяет хранить данные о множественном наследовании.

sasha пишет:

Тоже, range мне кажется лишней если она только посредует dataProperty и dataType (разве что у dataProperties[id] может быть несколько разных valueDataTypes)

Да. Тут Вы, в рамках ограничений моей задачи - правы. Хотя, конечно, к примеру, для разных классов одно и тоже свойство может быть разных типов.

Новая версия:

http://i768.photobucket.com/albums/xx323/chvlad/ontoevis-2.gif

Отредактировано Владимир (2010-10-31 07:29:58)

Thumbs up Thumbs down

20

Re: ? Схема БД

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

Что касается одной таблички или нескольких для хранения онтологий. Чем больше табличек, тем "тяжелее" выполнение запросов на больших объемах данных. Поэтому если данных у вас не очень много- условно до 20 Mb - и кол-во пользователей небольшое, то ваша схема в любом случае будет хороша.
На условно больших до 200-500 мб данных вероятно лучше будет уменьшить кол-то таблиц (может даже до 1).
Ну и главный ваш помощник шардинг базы данных.

Re: ? Схема БД

Shcherbak пишет:

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

Я пишу локальную программу для рабочих станций на AIR (фреймворк - Flex), соответственно, БД - SQLite. Есть готовые решения под такую конфигурацию ПО?

Thumbs up Thumbs down

22

Re: ? Схема БД

нет, о таких мне не известно. в Flex есть инструменты для работы с XML,  их можно применить для обработки формата сериализации RDF/XML в связке с SQLLite (если тип XML в этой Бд поддерживается).

Re: ? Схема БД

Shcherbak пишет:

нет, о таких мне не известно. в Flex есть инструменты для работы с XML,  их можно применить для обработки формата сериализации RDF/XML в связке с SQLLite (если тип XML в этой Бд поддерживается).

Хорошо, а какие есть решения именно для рабочих станций под яву? Именно фреймворки, которые можно модифицировать под свои нужды, а не готовые решения.

Thumbs up Thumbs down

24

Re: ? Схема БД

Читаем здесь  http://shcherbak.net/2009/05/sravniteln … et-i-java/

Re: ? Схема БД

Shcherbak пишет:

Читаем здесь  http://shcherbak.net/2009/05/sravniteln … et-i-java/

На сколько я понимаю, это все серверные решения под JEE.

Thumbs up Thumbs down