Data Model Details

The tables in the model include the user tables that are populated when a new user is created in the system.  A user name is created by the UserService during the user registration phase.

• users
• user_details
• user_email
• user_phone
• user_address

After a user is created, an account is registered for that user by the AccountService.  This table is a place holder at this point and will be refactored when connections to a broker are built.  This table should be adequate during the first stages of system development.  An account can be either regt or pm margined, and either funded or paper/simulation.

• account

As strategies are developed, the strategy and strategy_settings tables are populated.  An entry in the strategy_run is associated with a specific set of settings, a specific account, and specific date range.  Multiple runs, can use the same set of strategy settings.  The allocation amount from an account to a specific run is set in the account_strategy_run table.  The allocation amount cannot be greater than the sum of the margin required by the strategy versus the account cash available.  All of these updates are handled by the StrategyService.

• strategy
• strategy_settings
• strategy_run
• account_strategy_run

A position is a set of options strikes, for example an iron condor, for specific expiration month.  A new position (PositionService) and security_option(s) (SecuritiesService) are created by the StrategyService just prior to the first order being sent by the StrategyService.  An order value object is created and sent via JMS to the OrderService.  The OrderService creates an entry in the order table and sends the order to the broker connector via JMS.  The OrderService monitors the status of orders and will update/cancel orders.  Order status alerts are sent by the OrderService to the StrategyService. 

• position
• security_option
• order - composed of options_security entities, and may result in multiple fills/transactions

The OrderService will match fills to orders and will send fills via JMS to the TransactionService.  The TransactionService will update the fill and transaction tables.  The TransactionService will send a fill alert via JMS to the StrategyService .  The StrategyService will then call the PositionService to update the position_details table.

• fill - composed of options_security entities
• transaction - composed of options_security entities, and associated with an order and position
• position_details - composed of transaction entities

The MetricsService will update the trade_summary and trade_details_by_day tables, as well as query these tables for data to display in charts.

• trade_summary
• trade_details_by_day

The next post will contain some ideas about other functionality required by the system.