В общем, со стороны программирования тема вопроса относится к использованию языка запросов SQL, а смысл я его вижу в том, что если кто-либо и сталкивался с задачей выявления семантических циклов (понятие условное), то они возможны лишь в иерархически организованной базе данных, а, значит, с ним можно пообщаться и на тему принципов организации таких баз. В общем, если у базы данных нет иерархической организации, то и семантические циклы там вряд ли возможны.
Но что такое «семантический цикл»?
Положим, нам известен кто-либо, скажем:
1. Энгельс
Но он же не просто существует, но и что-либо делает:
2. Энгельс поделил всех философов на два больших лагеря - материалистов и идеалистов
в результате данного деления нам дано располагать и таким следствием:
3. лагерь материалистов
тогда в этом «лагере» дано состоять каким-то фигурам, в частности, это:
1. Энгельс
...
На этом цикл замыкается. Но поскольку семантический цикл скорее вреден, чем полезен, то полезно его рвать таким способом:
4. принадлежность Энгельса лагерю материалистов, -
что, с другой стороны, вредит унификации данных.
В виде таблиц все это реализовано следующим образом - заданы таблицы «a», «b» и «c», где «c» - таблица связей, мы ее для простоты опустим. В иерархической базе на первом шаге возможна запись в таблицу «a» поля «Энгельс», «b» - «Энгельс поделил ...», на втором шаге - в таблицу «a» поля «Энгельс поделил ...», «b» - «лагерь материалистов», на третьем - в таблицу «a» поля «лагерь материалистов», «b» - «Энгельс». База построена таким образом, что содержание записей в полях таблиц «a» и «b» уникально, да и строк таблицы «c» также.
Теперь нам можно перейти к программированию. Для поиска семантического цикла возможно применение такого запроса (для длины цикла 4 шага, в исполнении Access97):
SELECT DISTINCTROW a.l, b.d, b_1.d, b_2.d, b_3.d
FROM ((((((((((a INNER JOIN c ON a.wl = c.i) INNER JOIN b ON c.al = b.wd) INNER JOIN a AS a_1 ON b.d = a_1.l) INNER JOIN c AS c_1 ON a_1.wl = c_1.i) INNER JOIN b AS b_1 ON c_1.al = b_1.wd) INNER JOIN a AS a_2 ON b_1.d = a_2.l) INNER JOIN c AS c_2 ON a_2.wl = c_2.i) INNER JOIN b AS b_2 ON c_2.al = b_2.wd) INNER JOIN a AS a_3 ON b_2.d = a_3.l) INNER JOIN c AS c_3 ON a_3.wl = c_3.i) INNER JOIN b AS b_3 ON (b_3.d = a.l) AND (c_3.al = b_3.wd)
WHERE (((a_1.l) Is Not Null) AND ((a_2.l) Is Not Null) AND ((a_3.l) Is Not Null));
(таблицы обозначенные как *_1, *_2 и т.д. - полные копии таблиц a, b, c)
То, что недоступно простым пользователям, мало понимающим в программировании - это построение запроса на поиск семантического цикла чтобы он выдавал результаты одновременно с четным и нечетным числом шагов. Но, быть может, это невозможно в силу принципиальных ограничений; во всяком случае, буду благодарен за подсказку как можно построить поиск любых циклов в одном запросе. Также буду благодарен за совет, как такой запрос можно построить попроще, если это само собой возможно.
Однако основной смысл поста в другом - может он напомнит кому-то эту странную и удивительную фичу и он поделится опытом проектирования и использования баз данных, которые я называю «иерархическими».
не надо это делать через select
во-первых можно просто делать несколько запросов
во-вторых несколько запросов можно делать не через вызов select, а написанием соответствующей pl/sql функции, например в оракл.
В третьих количество действий и характеристик у вас неоднозначно, возможно реляционная база тут и не самый удачный вариант.
В четвертых - цель то какая?
Конечно, в моем случае можно написать такую функцию в VBA, если. конечно, он "съест" такие длинные запросы в функции))
Что такое "неоднозначное количество действий и характеристик" я не вполне понимаю - быть может, оно и принципиально неоднозначно, поскольку этот метод - иерархические базы данных - используется для анализа содержательных источников, по простому - книг. Результативность - хорошая, но хотелось бы лучше)
Цель, если это цель вопроса - поиск литературы, проще - любых пособий по такой архитектуре баз данных, - странным образом, никто такие решения не использует, чуть ли не патент бери)
Меня вообще интересует литература - есть ли какое-нибудь пособие пусть по графовым базам данных, но - с достаточным количеством деталей и нюансов?
Я думаю, что тот метод ведения базы, который я использую, он достаточно эффективный, а аналитика хромает - реальная аналитика практически только статистика, хотя вполне показательная. Есть ли какая-нибудь другая аналитика, вообще что можно искать при помощи пусть графовых баз данных?
Простой
