Presentation is loading. Please wait.

Presentation is loading. Please wait.

Copyright © 2006 Quest Software Data Modeling: It’s All About the Relationships Presenter: Bert Scalzo, Oracle Domain Expert AUDIO.

Similar presentations


Presentation on theme: "Copyright © 2006 Quest Software Data Modeling: It’s All About the Relationships Presenter: Bert Scalzo, Oracle Domain Expert AUDIO."— Presentation transcript:

1 Copyright © 2006 Quest Software Data Modeling: It’s All About the Relationships Presenter: Bert Scalzo, Oracle Domain Expert Bert.Scalzo@Quest.com AUDIO INFORMATION Toll free: Toll: Confirmation Code:

2 1 About the Author … Domain Expert & Product Architect for Quest Software Oracle Background: Worked with Oracle databases for over two decades (starting with version 4) Work history includes time at both “Oracle Education” and “Oracle Consulting” Academic Background: Several Oracle Masters certifications BS, MS and PhD in Computer Science MBA (general business) Several insurance industry designations Key Interests: Data Modeling Database Benchmarking Database Tuning & Optimization "Star Schema" Data Warehouses Oracle on Linux – and specifically: RAC on Linux Articles for: Oracle’s Technology Network (OTN) Oracle Magazine, Oracle Informant PC Week (eWeek) Articles for: Dell Power Solutions Magazine The Linux Journal www.linux.com www.orafaq.com

3 2 Books by Author … Coming in 2008 …

4 3 Agenda Purpose –Identify the primary and secondary goals of a data modeling –Speculate as to why data models so often miss primary goal –Propose data modeling tools can’t make up for human error –Examine three well known yet often repeated relationship errors –Provide Best Practices to resolve these issues (i.e. avoid them) Overview –No such things “Partial Foreign Keys” –Neither do “Incomplete Foreign Keys” –Unification – what is it and when to do –Conclusion & Questions/Answers

5 4 Partial Foreign Keys Don’t Exist Q: Why can’t I make certain attributes of a unique identifier relate to the foreign key (FK) in a child any way I like? A: Because Relational Algebra, Relational Calculus, Codd, Date, and all that’s relational say “Heck No!!!” Three fundamental FK requirements: Relation R1 references R2 R1’s FK attributes have exactly the same domain R2’s PK attributes For each tuple (i.e. row) t1 in r(R1) and t2 in r(R2), either t1[FK] = t2[PK] (entirely),or t1[FK] is NULL

6 5 Example #1 Identifying relationship lost Toad Data Modeler won’t permit this error

7 Toad Data Modeler makes this less likely 6 Example #2 Identifying relationship overuse

8 7 Example #3 Identifying relationship misuse Toad Data Modeler can workaround error

9 8 Incomplete Foreign Keys Do Not Exist All or None Complete PK as the FK (i.e., both columns) or supply the FK with just column A Not referentially correct, but permitted since column B is optional Looks Safe Just as bad or actually worse Can be legal: A+B, or NULL+NULL Can be illegal: A+NULL or B+NULL

10 9 Toad Data Modeler will generate check constraint to be safe: constraint FK_COMPLETE check ((A is null and B is null) Or (A is not null and B is not null)) ANSI SQL 92 permits and databases such as Oracle support alternative matching rules for composite foreign keys, including: Match Full –Partially null foreign keys are not permitted. Either all components of the foreign key must be null, or the combination of values contained in the foreign key must appear as the primary or unique key value of a single row of the referenced table. Match Partial – Partially null composite foreign keys are permitted. Either all components of the foreign key must be null, or the combination of non-null values contained in the foreign key must appear in the corresponding portion of the primary or unique key value of a single row in the referenced table. Match None – Partially null composite foreign keys are permitted. If any column of a composite foreign key is null, then the non-null portions of the key do not have to match any corresponding portion of a parent key. Incomplete Foreign Keys Do Not Exist

11 10 Unification – not as scary as it sounds! Q: Why doesn’t Table_3 have columns A and B twice? A: We performed column level unification

12 11 …Otherwise we would have had this – with A & B duplicates in TABLE_3. Unification – not as scary as it sounds!

13 12 Let’s Test What We’ve Learned – Is This Model Okay? FK1 and FK2 both share the column SSN If employee has doctor’s report, but without associated accident, unifying FK1 and FK2 leads to incomplete FK (i.e., SSN without an accident date) Left side of Relationship2 is optional – therefore, model is correct

14 13 Thank you! Questions or Comments? Three Part Data Modeling Series: –Data Modeling: Common Mistakes and Their ImpactData Modeling: Common Mistakes and Their Impact –Data Modeling: It’s All About the RelationshipsData Modeling: It’s All About the Relationships –Data Modeling: Reality Requires Supertypes and SubtypesData Modeling: Reality Requires Supertypes and Subtypes Toad Data Modeler v3.2 –Reasonable cost, easy to use data modeling tool for the rest of us … –Support for Oracle 11g and Access 2000-2003, import from SQL script, SQL code generation by SCHEMA, and much more! –http://www.quest.com/Toad-Data-Modelerhttp://www.quest.com/Toad-Data-Modeler


Download ppt "Copyright © 2006 Quest Software Data Modeling: It’s All About the Relationships Presenter: Bert Scalzo, Oracle Domain Expert AUDIO."

Similar presentations


Ads by Google