Modeling_Patterns

Download Report

Transcript Modeling_Patterns

Data Modeling on Steroids: Patterns and Reusability

Presented by Bert Scalzo, PhD [email protected]

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 – www.Linux.com

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: Application Monitoring High Availability Database Management Microsoft Infrastructure Management

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 …

• End-user • IT Partner/Liaison • Business Analyst

Business Process Modeling

(

BPM

) • System Architect • System Analyst • App Developer • Bus. Analyst • Data Architect • Data Analyst

Object-Oriented Modeling

(

OOM

- UML)

Conceptual Data Modeling

(

CDM

– E/R) • DBA • DB Developer • DB Architect

Physical Data Modeling

(

PDM

) QDesigner synchronizes models from all levels in a single tool • Improve process efficiency • Define/document Bus. Processes - create correct and complete application requirements • Support for all UML diagrams - Analyze requirements - Design application • Reverse/forward engineer code • Identify all data & relationships - E/R (Entity/Rel’ship) diagrams - DB independent view • Business Rules?

• DB-specific model • Reverse engineer existing DB • Create/Update DB from model • Data Warehouse Modeling

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 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  I later worked for that company – Nearly 1000 entities – Close to 20,000 attributes – In a year, we simplified the model by 90%!!!

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 http://www.quest.com/whitepapers/Reality_Requires-QDesigner.pdf

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 1 2 3 4 Part Minor Major Product Component 7 8 9 1 2 3 4 5 6 Screw Nut Washer Bracket Widget Gadget Sprocket Cog Gizmo 3 3 4 1 1 1 1 2 2 How many base parts in a Gizmo? (nine) Assembly 5 5 5 6 6 7 9 9 7 8 8 1 2 3 1 4 5 7 8 6 1 5

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™ – http://www.quest.com/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 – http://www.quest.com/whitepapers/qdesigner/index.asp

• 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