4

I am building a database using SQL Server 2008 to store prices of securities that are traded on multiple markets.

For a given market, all the securities have the same holiday calendar. However, the holiday calendars are different from market to market.

I want the following four tables: Market, GoodBusinessDay, Security, and SecurityPriceHistory, and I want to enforce that SecurityPriceHistory does not have rows for business days when the market on which a security was traded was closed.

The fields in the tables are as follows:

Market: MarketID (PK), MarketName

GoodBusinessDay: MarketID (FK), SettlementDate (the pair is the PK)

Security: SecurityID (PK), MarketID (FK), SecurityName

SecurityPriceHistory: This is the question - my preference is SecurityID, SettlementDate, SecurityPrice

How can I define the tables this way and guarantee that for every row in SecurityPriceHistory, there is a corresponding row in GoodBusinessDay?

If I added a column for MarketID to SecurityPriceHistory. I could see how I could do this with two foreign keys (one pointing back to Security and one pointing to GoodBusinessDay), but that doesn't seem like the right way to do it.

OracleOfNJ
  • 75
  • 1
  • 5

3 Answers3

1

This model should do. The relationship between Market and BusinessDay is identifying, that is, a businessday does not exist outside the context of the market to which it belongs.

Similarly, the relationship between BusinessDay and SecurityPriceHistory is identifying, as it the relationship between Security and SecurityPriceHistory.

This means that the primary key of SecurityPriceHistory is composite: security_id,market_id and settlement_date.

take 1

This will enforce the constraint that each security may be have no more than one row in SecurityPriceHistory for a given market/business day. It does, however, allow for the same security to trade in multiple markets, despite the security's relationship to a particular market: to restrict that, the relationship between Market and Security needs to be identifying, thus:

take 2

Nicholas Carey
  • 71,308
  • 16
  • 93
  • 135
  • One other thing to note: making the Security-trades-on-Market relationship an identifying relationship means that it complicates a Security moving from, say, the NYSE to NASDAQ, as the market ID is part of the Security's primary key. Just something to keep in mind. – Nicholas Carey May 19 '11 at 18:20
  • This is approaches 4NF and 5NF BTW (I'm not thinking too deeply about it...) – gbn May 19 '11 at 18:41
  • Thanks for the caveat - given the actual securities/markets (which are things like US bonds vs European bonds as opposed to US stocks trading on NYSE vs US stocks trading on Nasdaq) I'm fine with the assumption that the market will never change for a given security. – OracleOfNJ May 19 '11 at 19:17
0

SecurityPriceHistory could have a FK to GoodBusinessDay and NO FK to Market. You could figure out the market by joining to the GoodBusinessDay table. I don't really like this option, but it's a possibility.

You could also use a trigger to check and make sure that there's a proper GoodBusinessDay record on insert/update, otherwise reject the transaction.

Rex Morgan
  • 2,979
  • 2
  • 21
  • 32
0

I think you're going to need the marketID field in your securityPriceHistory table, assuming the same securityID could be sold in different markets on the same goodBusinessDay.

Setting it up the way you're thinking is fine. You have a parent, two related children, then a grandchild that has relationships with both children.

Even if a security can only be sold on one market, I'd still include the marketID in the securityPriceHistory table, with two compound FKs, MarketDay and MarketSecurity. Clearer that way, IMO.

Beth
  • 9,531
  • 1
  • 24
  • 43