NoSQL tree structure

Question

I found several answers to this question, but none matches my problem.

http://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/ Tree structures in a nosql database

Most of these examples model a "is a" graph hierarchy. A shoes is a clothing. The tree is about type specialization.

The few one modeling a "has a" relationship, do not support types.

My original problem comes from modeling financial products. To keep it simple: http://en.wikipedia.org/wiki/Option_style

Description

Assume a tree where each node is either the right or the obligation to swap the assets represented by the two children nodes.

For instance. European call option on Microsoft stock: " I have the right ( no obligation ) to buy Microsoft stock for 50$, January 10th 2016" ==> the exchange is between $ cash and a stock.

But one can also have a call option on another call option. " I have the right ( no obligation ) to buy the above described option for 11$, June 10th 2015"

The tree

The leaves of the tree MUST be a listed product on some market (stock, bond, rate, listed option ... ), or some aggregation basket of such products.

Each node can be of nearly any type:

1. Path dependent pay off or not ( Asian, look-back ...)
2. Exercise type ( Bermudan, American, European )
3. Put/Call
4. long/short

and may have very different parameter set based on its type, for example:

• Bermudan exercise will require an array of date, others only one maturity date.

So I must model a tree expressing a "has a" relationship ( including basket/index aggregation ) where each node can be of very different nature and have very different parameters. But I must also reflect some sort of type inheritance between my node in my DB structure, an american put option "is an" option.

Constaints

1. I must have enough information to price the booked products. The Given DB + market data access + choose a pricing model ==> price
2. One may assume that ACID aspects will be ensured at code level if needed
3. speed is the ONLY measure as long as the above is OK

Question

What are my options ? I'm very open, even to file writing and serialization, or whatever crazy idea you may have.

I just need a big brainstorming of big brains storming.

EDIT: Thanks to Christoph

For inheritance in SQL I usually do this

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

The problem is more about its "down links", for instance my american options underlying are not necessarily simple listed products.

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");

....

Where "assets" can be pretty much anythnig. This works in most case but some tricks are needed. For instance, the basket case must be design in the way below described by christoph. For instance, an american option on a basket, asset1 is cash, asset2 is of type basket and modeled like this.

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

if option had been bermudean/carraibean, I probably would have needed a dateSet model table

Answer 1

Modelling an "is a" relationship in databases can be achieved by normalizing the data, i.e. if you have an OPTION table and an AMERICAN_OPTION table then they could look like this:

(I am switching to pseudo-SQL but the same works for nosql):

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

Here, you could interprete this as "AMERICAN_OPTION derives from OPTION and has additional members 'foo1' and 'foo2'".

Alternatively, you can just put everything in one table and leave the unused columns as NULL.

Modelling a "has a" relationship is usually done by creating database indices and relationships between them.

An ETF Basket "has a" 1:n relationship to other products. Make sure that your NoSQL database supports 1:n relationships in some way or the other. Since many NoSQL databases do not support indices out of the box, you might have to model these relationships in your application. This is usually not a big deal if the relationships are not too complex. You can search wikipedia for "Star Schema" for more information.

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

If you would use a graph database then some of this functionality might come out of the box, but i do not have experience with graph databases. I do not think that they're faster, though.

In review it seems that modelling for a NoSQL database is not different from modelling for a SQL database, but there's more work for you as an application developer.

Best regards,

Christoph