Subscribe to:
Post Comments (Atom)
skip to main |
skip to sidebar
The aim of this Blog is to provide a forum for raising questions and discussing the paper on Foreign Keys.
Download the Discussion Paper from here.
http://www.eternal-donut.com/downloadp/foreign_key_discussion_kratochvil_v11.pdf
The only rule that I ask is that you read the whole paper (in its entirety) before making any comments.
Eternal Donut Blog
Blog Archive
About this Paper
- Marcelle Kratochvil
- Canberra, ACT, Australia
- Marcelle Kratochvil is CTO for Piction and is the Oracle ACE Director for all data/any data. She has extensive experience in the business of setting up and manging multimedia sites, having setup over 30 in the last 5 years. Marcelle has been using the Oracle database for the past twenty years and originally began using Oracle with V5 on MVS and VMS. She has been awared PL/SQL Developer of the year in 2004, and has won awards for development of a shipping system and state government digital asset management. Over the last ten years Marcelle has been involved in the core development of Piction and has been involved in the installation and management of this product in countries around the world. She has extensive experience in Oracle Database Administration, including the performance of large databases, network management and application development. She has been a regular presenter at OpenWorld and first presented at OpenWorld in 1993. She recently presented at OpenWorld 2010 and has done internal presentation to Oracle. Marcelle is also an 11g Beta Tester and does tuning trouble shooting for Government Departments and commercial organisations.
Posts
Don't forget that in logical E/R modeling you specify relationships with optionality and cardinality on both ends. This translates to a physical design that may allow NULL values for the foreign key. It also helps you decide in physical design which table gets the foreign key - always the "many" end of the relationship. Many to many relationships can be diagrammed with or without an intermediate entity, but are always implemented with an intersection table.
ReplyDeleteSome of the problems with foreign keys that you note in your paper are actually due to improper design, or failure to carefully check your design. For instance, you give an example where an order has a foreign key to an account, but you have a legal requirement to be able to delete the account. Obviously, this is therefore an optional foreign key, in which case you can NULL the key and delete the account without a problem.