320 likes | 439 Views
Practical Databases. A look at DBMS in practice: A Trading and Inventory System. Introductory Guff. Your speaker is Dr Richard Keeble; Today’s talk - a look at database systems in a real-life environment ... A case study of real system s in a real company;
E N D
Practical Databases A look at DBMS in practice: A Trading and Inventory System
Introductory Guff • Your speaker is Dr Richard Keeble; • Today’s talk - a look at database systems in a real-life environment ... • A case study of real systems in a real company; • A look at the bigger issues surrounding database systems in financial environments.
What I’ll Talk About • Business background and rationale: • What systems did we look after and why? • How did they support the business goals? • A look at the systems themselves: • The various components and their relationships; • How the different elements of the business interact and are supported by the technology.
What You’ll Get Out Of This • An idea of the scale and complexity of ‘enterprise’ database systems; • An insight into how business systems fit together and inter-operate; • A look at some of the problems in the development of business database applications; • Experience from others’ cautionary tales ... !
The Business: What • Goldman Sachs: • General Activities: • Investment Banking; • Proprietary Trading. • My responsibilities: • Front-line support; • Routine maintenance and development; • Flow testing; • New development, test and commission.
The Business: What & Why • What’s a ‘Repurchase Agreement’ (‘Repo’)? • A short-term collateralised loan. • What’s it for? • Short-term low-risk borrowing and lending; • Also allows GS to spend the same money several times a day … !
Repo Trades • Legal definition: • ‘an agreement to sell and a simultaneous forward agreement to re-purchase’. • Contrast to a ‘normal’ trade: • A repo has a start and an end, as opposed to a share purchase which is a single event.
An Example Repo Trade • A one-week repo at 5% for EUR 10MM vs. 10MM BUNDs at par: • Start cash = 10MM EUR; • End cash = 10MM EUR + 9,491.48 EUR interest; • One Trade, but two Business Transactions: SELL 2003-01-30 RE-PURCHASE 2003-02-06 RP 10MM EUR vs 10MM BUND NEWPIECE FULLRETURN
Trading Volumes • Usually around 1300-1400 trades done per day; • Somewhere around 15,000 trades active at any point; • Approximately 40,000 different securities may be traded; • So how do we know what’s going on?
Security Projections • Sister to the NDR trading systems; • Shows traders and operations the Firm’s commitments summed over time, sorted: • By bond or bond group (called ‘book’); • By currency; • By legal entity. • Critical for keeping all the plates spinning!
Roles in the System • Front Office: • Traders, salespeople, trading assistants. • Middle/BackOffice: • Daily trading operations staff, controllers,clearance support staff and operations. • IT Personnel: • Looking after all of the above.
The Bigger Picture • Repo acts as both a source and a sink for information streams from many places: • As a sink for: currency rate information, inter-company trading data; • As a source for: other firm groups (cash ledgers, stock control, trading position management systems), legal, regulatory and clearing houses. • Projections: only a sink (easier to look after!)
Trade is Booked REPO(repo_db) PROJECTIONS(secproj_db) Traders Trade Entry Security Projections Window Traders & Operations OUTSIDE
Postings Generated REPO(repo_db) PROJECTIONS(secproj_db) Traders Trade Entry genesis2 Security Projections Window Traders & Operations OUTSIDE
Trade Hits Projections REPO(repo_db) PROJECTIONS(secproj_db) Traders Trade Entry genesis2 trades Security Projections Window Traders & Operations OUTSIDE
Trade Posts Internally REPO(repo_db) PROJECTIONS(secproj_db) Traders Trade Entry genesis2 trades Security Projections Window Traders & Operations OUTSIDE Cash Bonds
Clearance Instructed REPO(repo_db) PROJECTIONS(secproj_db) Traders Trade Entry genesis2 trades Security Projections Window Traders & Operations OUTSIDE Cash Bonds Banks, Clearing Houses
Confirm Received REPO(repo_db) PROJECTIONS(secproj_db) Traders Trade Entry genesis2 trades Security Projections Window settlements Traders & Operations OUTSIDE Cash Bonds Banks, Clearing Houses
Trade Settled – Done! REPO(repo_db) PROJECTIONS(secproj_db) Traders Trade Entry genesis2 Exception Window trades Operations Security Projections Window settlements Traders & Operations OUTSIDE Cash Bonds Banks, Clearing Houses
No Settlement? REPO(repo_db) PROJECTIONS(secproj_db) Traders Trade Entry genesis2 Exception Window trades Operations Security Projections Window Traders & Operations OUTSIDE Banks, Clearing Houses
Call The Counterparty! REPO(repo_db) PROJECTIONS(secproj_db) Traders Trade Entry genesis2 Exception Window trades Operations Security Projections Window Traders & Operations OUTSIDE Banks, Clearing Houses
Confirm Received (At Last) REPO(repo_db) PROJECTIONS(secproj_db) Traders Trade Entry genesis2 Exception Window trades Operations Security Projections Window settlements Traders & Operations OUTSIDE Banks, Clearing Houses
Trade Settled – Done! REPO(repo_db) PROJECTIONS(secproj_db) Traders Trade Entry genesis2 Exception Window trades Operations Security Projections Window settlements Traders & Operations OUTSIDE Banks, Clearing Houses
Transactions: 1 • Absolutely essential in sizeable, production systems: • To ensure integrity of data during protracted operations on the database; • To regulate concurrent accesses to the database. • By making it appear to whatever application or process that they are the only database user.
When It’s All Gone Pear-Shaped • Sometimes, there is no alternative to manipulating the database directly: • The dreaded ‘Manual Update’! • These are dangerous things to do: • In ‘Production’, you’ve no room for error; • How can you make adjustments and verify they’re correct?
Transactions: 2 • Also extremely important in supporting a real-time system where occasional manual updates are required: • Used correctly, you can do no wrong! • Just remember to always be in a transaction, or bad things may happen ... • And don’t forget the transaction afterwards ...
Environmental Separation • Using separate databases for different activities: • Development and Testing; • QA: Quality Assurance; • Production and Archival. • Much safer to use ... • ... as long as you remember where you’re looking at!
Multi-Tier Applications • The ‘n-tier’ application development idea: • 2-tier: user interface and database; • 3-tier: UI, business logic, DB; • 4-tier: UI, middleware, BL, DB. • and so on ... • A lot depends upon the application’s particular requirements: • Requirements can change over time ...
Example: Trade Entry • A collection of windows used by traders to book trades. • ‘2.5-tier’ architecture (apps, SPs+DB): • In the first place, a good thing: TE was the only source of trades and adjustments; • As time passed, a bad thing: business logic intertwined with UI software, plus additional sources of trading information.
Problems • The rules for ‘genesis2’: • Flexible rules, based on trade types (and other criteria); • Easily configurable without changing the program; • But is there a price to pay? • What if the rules are wrong?
So, are there ... • Any questions?