0

我找到了这个问题的几个答案，但没有一个符合我的问题。

http://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/ nosql 数据库中的树结构

这些示例中的大多数都对“是”图形层次结构进行建模。鞋子是衣服。这棵树是关于类型专业化的。

少数几个建模“有”关系，不支持类型。

我最初的问题来自于金融产品建模。为了简单起见： http ://en.wikipedia.org/wiki/Option_style

描述

假设一棵树，其中每个节点都是交换由两个子节点表示的资产的权利或义务。

例如。微软股票的欧式看涨期权：“我有权利（没有义务）以 50 美元的价格购买微软股票，2016 年 1 月 10 日”==> 交换是在美元现金和股票之间。

但是一个人也可以在另一个看涨期权上拥有看涨期权。“我有权（无义务）以 11 美元的价格购买上述选项，2015 年 6 月 10 日”

那个树

树的叶子必须是某个市场上的上市产品（股票、债券、利率、上市期权……），或此类产品的某个聚合篮子。

每个节点几乎可以是任何类型：

  1. 路径依赖的回报与否（亚洲，回顾......）
  2. 运动类型（百慕大、美国、欧洲）
  3. 看跌/看涨
  4. 长短

并且根据其类型可能具有非常不同的参数集，例如：

  • 百慕大行使将需要一系列的日期，其他的只有一个到期日。

因此，我必须对表示“具有”关系（包括篮子/索引聚合）的树进行建模，其中每个节点的性质可能非常不同，并且参数也非常不同。但我还必须在我的数据库结构中反映我的节点之间的某种类型继承，即美式看跌期权“是一个”期权。

约束

  1. 我必须有足够的信息来为预订的产品定价。Given DB + 市场数据访问 + 选择定价模型 ==> 价格
  2. 如果需要，可以假设 ACID 方面将在代码级别得到保证
  3. 速度是唯一的衡量标准，只要上述是好的

问题

我有什么选择？我非常开放，即使是文件写入和序列化，或者任何你可能有的疯狂想法。

我只需要大头脑风暴的大头脑风暴。

编辑：感谢克里斯托夫

对于 SQL 中的继承，我通常这样做

CREATE TABLE OPTION ("isin", "name", "emitter","typeId"); "use American type id"
CREATE TABLE AMERICAN_OPTION ("isin","foo1", "foo2");

问题更多在于它的“下行链路”，例如我的美式期权标的不一定是简单的上市产品。

CREATE TABLE ASSET ("uniqueIdentifier,"typeId","name","asset1","asset2");
CREATE TABLE ASSET_TYPE_1 ("uniqueIdentifier","DATA_1",..."DATA_N");
CREATE TABLE ASSET_TYPE_2 ("uniqueIdentifier","DATA_1",..."DATA_N");
CREATE TABLE ASSET_TYPE_1_B ("uniqueIdentifier","DATA_1",..."DATA_N");

....

“资产”几乎可以是任何东西。这在大多数情况下都有效，但需要一些技巧。例如，篮筐必须按照 christoph 描述的方式进行设计。例如，一个篮子上的美式期权，asset1 是现金，asset2 是篮子类型，并且是这样建模的。

ASSET( "XYZT12345", "American", "XYZT__1", "XYZT__2", ...[common admin data(e.g.tradedate,valuationCurrency...] )
ASSET( "XYZT__1", "cash", "NULL", "NULL" )
ASSET( "XYZT__2", "basket", "NULL", "NULL" )

CASH_ASSET( "XYZT__1", "10$" )
BASKET_ASSET( "XYZT__2", "Ric_1" )
BASKET_ASSET( "XYZT__2", "Ric_2" )
BASKET_ASSET( "XYZT__2", "Ric_3" )
VANILLA_OPTION_ASSET( "XYZT12345", "MaturityDate", "strikePrice" ); // both european and american fit in there

如果选项是 bermudean/carraibean，我可能需要一个 dateSet 模型表

4

1 回答 1

0

对数据库中的“is a”关系建模可以通过规范化数据来实现，即如果您有一个 OPTION 表和一个 AMERICAN_OPTION 表，那么它们可能如下所示：

（我正在切换到伪 SQL，但同样适用于 nosql）：

CREATE TABLE OPTION ("isin", "name", "emitter");
CREATE TABLE AMERICAN_OPTION ("isin", "name", "emitter", "foo1", "foo2");

在这里，您可以将其解释为“AMERICAN_OPTION 派生自 OPTION 并具有附加成员 'foo1' 和 'foo2'”。

或者，您可以将所有内容放在一个表中，并将未使用的列保留为 NULL。

建模“具有”关系通常是通过创建数据库索引和它们之间的关系来完成的。

ETF 篮子与其他产品“具有”1:n 关系。确保您的 NoSQL 数据库以某种方式支持 1:n 关系。由于许多 NoSQL 数据库不支持开箱即用的索引，因此您可能必须在应用程序中对这些关系进行建模。如果关系不太复杂，这通常没什么大不了的。您可以在 wikipedia 中搜索“Star Schema”以获取更多信息。

CREATE TABLE BASKET ("id", "name", "emitter");
CREATE TABLE INSTRUMENT ("id", "name", "emitter");
CREATE TABLE BASKET_TO_INSTRUMENT("etf_id", "instrument_id"); <-- your 1:n relationship

如果您要使用图形数据库，那么其中一些功能可能是开箱即用的，但我没有使用图形数据库的经验。不过，我不认为它们更快。

回顾一下，NoSQL 数据库的建模似乎与 SQL 数据库的建模没有什么不同，但作为应用程序开发人员，您还有更多工作要做。

此致，

克里斯托夫

于 2013-10-11T06:16:13.830 回答