我想记录各种消息来源对历史人物的看法。即
我还希望研究人员能够在这些来源的个人主张中表达他们的信心,例如百分比。即。
然后我希望每个用户都能看到Susan B. Anthony的视图,其中显示了她的生日,最喜欢的颜色以及用户认为最有可能真实的关系。
我也想使用关系数据库数据存储区,我想这样做的方法是为每个单独的原子事实类型创建一个单独的表,我希望用户能够表达他们的信心因此,对于这个例子,总共有八个表,三个单独的表用于三个独立的原子事实。
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))
这感觉很快变得非常复杂,因为实际上想要记录很多类型的原子事实。有更好的方法吗?
我认为,这与Martin Fowler称之为Contradictory Observations的问题相同。
答案 0 :(得分:3)
您应该尝试以“事实”表和几个“维度”表为中心的星型模式模型。这是一个经过深思熟虑的模型,并且有许多数据库优化。
claim_fact(source_id,person_id,user_id,details_id,weight)
Source_dimension(id,name)
Person_dimension(id,name)
User_dimension(id,name)
details_dimension(id,name NOT NULL,color NULLABLE,kinship NULLABLE,birthday NULLABLE)
每个声明都有源,人,用户和详细信息。详细信息的名称值将是“亲属关系”,“生日”等值。
请记住,这是一个OLAP架构(而不是OLTP结构),因此它没有完全规范化。这样做的好处超过了由于冗余而可能遇到的任何问题,因为星型模式的查询通过为数据仓库配置的DBMS进行了高度优化。
推荐阅读:数据仓库工具包(Kimball等)
答案 1 :(得分:2)
RDF非常适合这一点。它通常被描述为元数据的格式;但实际上它是三元组'断言'的图形模型。
整个“语义网”的想法是在RDF上发布大量事实,搜索引擎将是遍历统一图形以寻找关系的推理引擎。
还有一些机制可以引用一个三元组,所以你可以说一个断言,比如它的起源(谁说这个?),或者当它被断言时(他什么时候这么说?),或者你有多少相信它是真实的等等。
作为一个很好的例子,整个OpenCyc'常识知识库'可在RDF中查询
答案 2 :(得分:1)
我认为您想要使用的是“财产包”。您想拥有一个包含ID,“密钥”(在这种情况下,所谓的信息(例如“亲属关系”))和“值”的表,而不是对您要描述的每个类型的事实进行建模。 “(在这种情况下,所谓的价值(如”亚伯拉罕·林肯“)。然后你想要一张第二张表,将你的索赔人与该表联系起来,以及他们对该信息的信任程度。只需拥有源的ID,属性的ID以及源在信息中的置信度。这样,您可以拥有一个包含大量或少量信息的源;您还可以为不同的源建模在给定属性中具有不同的置信水平;对于您可以存储多少种不同类型的信息也没有限制。
这是一个非常标准的解决方案,适用于您需要交叉引用的大量可选信息的情况。
答案 3 :(得分:0)
这感觉很快就变得非常复杂
你不是在开玩笑。请查看ontology和knowledge representation上的工作。