Presentation on theme: "Practical Databases A look at DBMS in practice: A Trading and Inventory System."— Presentation transcript:
Practical Databases A look at DBMS in practice: A Trading and Inventory System
Introductory Guff Your speaker is Dr Richard Keeble; Todays 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 Ill 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 Youll 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 Whats a Repurchase Agreement (Repo)? –A short-term collateralised loan. Whats 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, EUR interest; –One Trade, but two Business Transactions: RP 10MM EUR vs 10MM BUND NEW PIECE FULL RETURN SELL RE-PURCHASE
Trading Volumes Usually around 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 whats going on?
Security Projections Sister to the NDR trading systems; Shows traders and operations the Firms 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/Back Office: –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!)
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 Its 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, youve no room for error; –How can you make adjustments and verify theyre 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 dont 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 youre 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 applications 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?