Моделирование атомарных фактов в реляционной базе данных

Question

Я хочу записать, что различные источники говорят об исторической фигуре. т.е.

• На сайте Википедии написано, что Сьюзен Б. Энтони родилась 15 февраля 1820 года, и ее любимый цвет - синий
• В книге Век борьбы говорится, что Сьюзен Б. Энтони родилась 12 февраля 1820 года, и ее любимый цвет - красный
• В книге История женского избирательного права говорится, что Сьюзен Б. Энтони родилась 15 февраля 1820 года, ее любимый цвет - красный, и она была второй кузиной Авраама Линкольна

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

• Пользователь А на 90% уверен, что Сьюзен Б. Энтони родилась 15 февраля 1820 года; 75% уверены, что ее любимый цвет - синий, и 30% уверены, что она была двоюродной сестрой с Авраамом Линкольном
• Пользователь B на 30% уверен, что Сьюзен Б. Энтони родилась 12 февраля 1820 года; 60% уверены, что ее любимый цвет был синим, и 10% уверены, что она была двоюродной сестрой с Авраамом Линкольном

Затем я хочу, чтобы у каждого пользователя было видение Сьюзен Б. Энтони, которое показывает ее день рождения, любимый цвет и отношения, которые пользователи считают наиболее вероятными.

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

Source(id)
Person(id)

Claim(claim_id, source, FOREIGN KEY(source) REFERENCES Source(id) )
Alleged_birth_date(claim_id, person, birth_date, FOREIGN KEY(claim_id) REFERENCES Claim(id), FOREIGN KEY(person) REFERENCES person(id))
Alleged_favorite_color(claim_id, person, color, FOREIGN KEY(claim_id) REFERENCES Claim(id), FOREIGN KEY(person) REFERENCES person(id)) 
Alleged_kinship(claim_id, person, relationship type, kin, FOREIGN KEY(claim_id) REFERENCES Claim(id), FOREIGN KEY(person) REFERENCES Person(id))

User(id)
Confidence_in_claim(user, claim, confidence, FOREIGN KEY(user) REFERENCES User(id), FOREIGN KEY(claim) REFERENCES claim(id))

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

Это, я думаю, та же проблема, которую Мартин Фаулер называет Противоречивые наблюдения .

Answer 1

Вам следует попробовать модель «Звездная схема», сосредоточенную вокруг таблицы «Факт» и нескольких таблиц «Измерение». Это хорошо изученная модель, и для нее существует множество оптимизаций базы данных.

претензия_факт (source_id, person_id, user_id, details_id, weight)

Source_dimension (id, name)

Person_dimension (идентификатор, имя)

User_dimension (id, name)

details_dimension (id, имя NOT NULL, цвет NULLABLE, родство NULLABLE, день рождения NULLABLE)

Каждая претензия будет содержать источник, лицо, пользователя и данные. Значения NAME для деталей будут такими, как "родство", "день рождения".

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

РЕКОМЕНДУЕМОЕ ЧТЕНИЕ: Набор инструментов хранилища данных (Кимбалл и др.)

Answer 2

RDF отлично подходит для этого. Обычно это описывается как формат для метаданных; но на самом деле это графовая модель «утверждений» на триплетах.

Вся идея «семантической сети» состоит в том, чтобы публиковать множество фактов в RDF, и поисковые системы будут механизмами логического вывода, которые пересекают объединенный граф для поиска взаимосвязей.

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

В качестве большого примера, вся OpenCyc «база знаний Commonsense» запрашивается в RDF

Answer 3

Я думаю, что вы хотите использовать это "мешок свойств". Вместо того чтобы моделировать каждый отдельный тип факта, который вы хотите описать, вы хотите иметь таблицу, которая будет содержать идентификатор, «ключ» (в данном случае, предполагаемую информацию (например, «родство»)) и «значение». "(в данном случае это предполагаемое значение (например," Авраам Линкольн) ". Затем вы хотите иметь вторую таблицу, которая связывает ваших заявителей с этой таблицей, а также уровень уверенности, который они имеют в этой информации. Эта таблица будет просто имейте идентификатор источника, идентификатор свойства и уверенность, которую источник имеет в информации. Таким образом, вы можете иметь источник, который имеет много или мало информации, вы также можете моделировать разные источники с разным уровнем доверия к данному атрибуту, также нет ограничений на количество различных типов информации, которую вы можете хранить.

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

Answer 4

Такое ощущение, что это очень сложно очень быстро

Ты не шутишь. Взгляните на работу по онтология и представление знаний .