hi to all,

i have been designing databases now for about a couple of years... however, they were all "supply chain"

this year, i would be responsible for designing DBs for the finance industry

i do know that the old and test rules of DB design could be applied - however, there are specific characteristics about the finance industry that just makes it difficult for me to apply (like lots of ATTRIBUTES, and LONG ones at that!)

i was kind of wondering if anyone could lead me to a certain reference site, or at least suggest a book that would allow me to at least make better designs for the finance industry (life insurance, investments, etc.)

thanks in advance!!

Working in that industry, I can say that that in any group of N people, there will be approximately N * Log(N) opinions on how a database shoudl be structured.

When you work in the financial industry, you have to clearly separate OLTP from OLAP usage. The two are very different beasts.

OLTP you need to normalize until you can't normalize it anymore. Third normal form is a good start. Anything less and you'll go insane before product rollout. More is better.

OLAP needs to be designed for simplicity. The financial guys are rocket scientists in the financial arena, but often can't find the door in a relational world. They tend to think in (wildly complicated) spreadsheets, not in tables.

There are at least two books that I know of in the works, but neither one is even near being published. They'll shed a great deal of light on these issues, from a real world perspective. As of right now though, I don't know of any single reference that will help much.

-PatP

yes...

since i have designed a couple of data warehouses before (for the dessert/beverage industry), this wouldnt be a problem

hhhmmm... i think that summarizes it quite neatly... as of this weekend i did check out the current database - and wow!!! each table runs for at least 20 columns (based on experience, tables with more than 20 columns need to go through further normalization). well, it could be an OLAP system, but when i dug in further, this particular table is for online transactions wherein client policies are entered, say thousand of times a day

unfortunately, most of the design is based on a third-party system called INGENIUM by SOLCORP - is anyone familiar with this?... it seems that this was originally based on a COBOL design, and then ported to DB2 (our production system uses Oracle as the back-end)

is that so... *bummer*
but i would appreciate any kinds of links - my greatest worry right now is how to convince these financial geeks how to follow database modelling rules and/or when to decide between following traditional design rules, or just go with the flow (ie., the INGENIUM)

thanks