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:
- Path dependent pay off or not ( Asian, look-back ...)
- Exercise type ( Bermudan, American, European )
- Put/Call
- 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
- I must have enough information to price the booked products. The Given DB + market data access + choose a pricing model ==> price
- One may assume that ACID aspects will be ensured at code level if needed
- 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