Data Modeling on Steroids: Patterns and Reusability Presented by Bert Scalzo, PhD

About the Author  Oracle DBA for 18+ years, versions 4 through 10g  Worked for Oracle Education & Consulting  Holds several Oracle Masters (DBA & CASE)  BS, MS, PhD in Computer Science and also an MBA  LOMA insurance industry designations: FLMI and ACS  Books –The TOAD Handbook (March 2003) –Oracle DBA Guide to Data Warehousing and Star Schemas (June 2003) –TOAD Pocket Reference 2 nd Edition (June 2005)  Articles –Oracle Magazine –Oracle Technology Network (OTN) –Oracle Informant –PC Week (now E-Magazine) –Linux Journal –

About Quest Software We provide application management solutions that enable customers to: Develop Deploy Manage Maintain enterprise applications without downtime

What is Application Management? A holistic approach of managing the entire application - not individual components

How Do We Do It? We surround the application infrastructure: High Availability Database Management Microsoft Infrastructure Management Application Monitoring

Agenda  Definition of Pattern  Benefits of Designing for Reusability  Super and Sub Type Pattern  Intersection Patterns –Many to many relationships –Roles –Assemblies

World of Modeling … Identify all data & relationships - E/R (Entity/Rel’ship) diagrams - DB independent view Business Rules? Conceptual Data Modeling (CDM – E/R) Physical Data Modeling (PDM) Business Process Modeling (BPM) Object-Oriented Modeling (OOM - UML) DB-specific model Reverse engineer existing DB Create/Update DB from model Data Warehouse Modeling DBA DB Developer DB Architect Bus. Analyst Data Architect Data Analyst System Architect System Analyst App Developer End-user IT Partner/Liaison Business Analyst Support for all UML diagrams - Analyze requirements - Design application Reverse/forward engineer code Improve process efficiency Define/document Bus. Processes - create correct and complete application requirements QDesigner synchronizes models from all levels in a single tool

Basic Premises of Design Patterns  Not everything is specialized  Simply reuse what’s reusable  Anyone can do this (really…)  Not that hard to do technically  Merely requires some up front work

Not Everything is Custom  How many of your businesses are so specialized that you require custom modeling of everything?  We all have: –Customers –Products –Contracts –Orders –Addresses –etc, etc, etc … These base concepts are often repeated within one company across projects, departments, divisions …

Side Effects of Customization  I had one insurance company for: –Life and Accident –Automobile –Home Owners –Health Insurance –Administer 401K –Variable Annuity  I later worked for that company –Nearly 1000 entities –Close to 20,000 attributes –In a year, we simplified the model by 90%!!! Each statement was mailed using a different address style (i.e. diff info), and it took 6 separate change of address cards when I moved. So I switched insurance companies

Benefits of Re-Usable Models Takes time, but often yields:  Better data models –More robust fundamental business knowledge  Better database design –More accurate implementation of business requirements  Less rework –Avoids last minute implementation/coding discoveries  Less end-user re-training –Systems won’t need to be reworked and redeployed  Centralized databases –All can be based upon common modeling best practices

Anyone Can Re-Use Models Regardless of “IS” shop organization  Centralized Modeling group – easy  Centralized Data Admin – again, easy  Departmental or Project Oriented: –Merely requires open communication –Helps to all use the same modeling tool –Helps for everyone to follow some fundamental modeling rules, guidelines and best practices –Can still work in a limited fashion with none of the above – through grass roots efforts to work smarter  Consultants – simply require all data models be part of walk-throughs and deliverables (help them learn the business)

Simple Pattern: 2 Constructs  Simply requires the appropriate, consistent and liberal use of just two very basic data modeling constructs 1.Super and Sub Types 2.Bridging/Intersection Entities –NOTE: There are two highly specialized intersection scenarios for making reusable modeling components Roles Assemblies (sometimes called B.O.M. solution)

Super and Sub Types  In the business world, we often find that things (i.e. entities) do not fall into simple, clear cut classifications –We sometimes find that things are very similar - with just a few differences  In data modeling, this can be referred to as: –Entity Inheritance –Super and Sub Types –Generalization Hierarchies  The key question to ask is whether these different classifications are: –Exclusive: must be one way or the other –Inclusive: can actually be all ways at once

Candidate for Super/Sub Very similar entities in concept - some common attributes, but also some differing attributes …

Super/Sub Type Pattern X means Exclusive

Super/Sub Meta-Data This Super/Sub Type Meta-Data is only important for transforming conceptual to physical model…

Intersection Patterns  There are three ways to use intersections: 1.Resolve basic many-to-many relationships Not very intrinsically useful, but must mention for clarity 2.As “Roles” Powerful concept Can greatly reduce data model size 3.As “Assemblies” Powerful concept Can enable flexible database design

Resolve Many-To-Many  You CANNOT physically implement the concept of many-to- many relationships in a relational database  You may potentially miss multiple key business requirements  Many modeling tools will attempt to automatically resolve this

Intersection Meta-Data

Candidate for Roles Unlike Super/Sub types, we now have identical or near identical entities coming together into an intersection …

Poor Choice for Roles  Often, a first attempt to resolve the “Role” concept uses relationships. But there are two problems with this approach: 1.What if “Role” participation requires additional attributes? Where would you place them? 2.What if business requirements change and you need to add or subtract “Role” participants? How do you later add and subtract foreign keys in databases?

Solution for Roles By creating a “Role Type” as entity rather than attribute, adding/dropping Roles doesn’t require database change!

Candidate for Assemblies

Solution for Assemblies This does everything the prior model does, with the advantage of not being fixed in terms of what things can be combined or in levels of hierarchical combinations possible … Parts Minor Components Major Components Products

Assemblies Good for Anything  At insurance company, we used Assemblies to build dynamic product offerings comprised of: –Features –Federal Rules –State Rules –etc, etc, etc …  Real Benefit: new products required no new application systems, just a few new rows of data in existing tables  Product time to market reduced by 50%!!!

Assemblies Work … Component Type ComponentAssembly How many base parts in a Gizmo? (nine)

Did You Notice …??? Roles and Assemblies are nearly the same thing …

Parting Thoughts  Many Design problems have already been solved  Data Model constructs can be re-used as easily as code –Carefully consider which business requirements are really unique –Must look for ways to reduce model complexity while making it “generic”  There are many other modeling issues – this was just a start … –Breaking models into sub-models –Round-trip Engineering: Conceptual -> Physical Model compare and sync Physical Model -> Database compare and sync –Repository-based collaborative modeling –Horizontal and Vertical Partitioning –Data Warehousing (Star Schema design) –Object-Relational Mapping –etc, etc, etc …

More Information  Free 45-Day Trial of QDesigner™ – –Compete enterprise modeling solution Business Process Modeling (BPM) Object-Oriented (UML) Modeling (OOM) Conceptual Data Modeling (CDM) Physical Data Modeling (PDM)  Save $$$: Upgrade your TOAD/SQL Nav license to the Suite – Suites include PDM!!!  Modeling White Papers – Data Modeling: Common Mistakes and Their Impact Data Modeling: It's Really All About the Relationships Data Modeling: Reality Requires Super and Sub Types

QUESTIONS & ANSWERS