dt modeling Universl Dt Models nd P tterns By Len Silversn According Webster s, term universl cn be defined s generlly pplicble s well s pplying whole. There re some very common ptterns tht cn be generlly pplied in dt models develop higher qulity nd more holistic designs. Additionlly, reusing ptterns cn sve time nd eft providing model structures tht hve been proven work well, flexible lterntives tht cn hndle dditionl future needs, nd consistent models nd structures tht fcilitte dt shring. This rticle will describe few common ptterns tht cn be used build universl dt models, nmely, ptterns roles, sttuses, ctegoriztions. For ech pttern, I will show specific nd bstrct wys model se types constructs. Which one is right? I believe tht re re usully not right nd wrong dt models, but pros nd cons vrious wys model dt. More specific dt models hve dvntge being more esily undersod, nd y show encement business rules. More bstrct dt models hve dvntge flexibility nd mintinbility becuse model is much more dptble chnge. Lter in this rticle, I will discuss when use specific versus n bstrct pttern. Roles Roles represent prt tht prty plys, or ht tht it wers. There re two types roles: declrtive nd contextul. Declrtive roles declre tht prty is plying prticulr role, such s prty tht is identified s nd declred n ROLE 1 # ROLE1 ID * ID (FK) role ROLE 2 # ROLE2 ID * ID (FK) FIRST NAME LAST NAME role employee. Contextul roles show how prty cts context nor entity. For exmple, prty my ply role product mnger context entity, or prty my ply role qulity ssurnce mnger entity. Declrtive Roles ROLE N # ROLE1 ID * ID (FK) role NAME Most enterprises mintin inmtion bout key entities such s cusmer, employee, prtner, supplier nd or roles tht re plyed people nd/or orgniztions. However, people do not ten relize tht role in dt models is not sme s prty involved, nd re my be inmtion tht is relted prty CUSTOMER # CUSTOMER ID * ID (FK) role FIRST NAME LAST NAME SUPPLIER # SUPPLIER ID * ID (FK) role PARTNER # PARTNER ID * ID (FK) role NAME Notes bout this dt modeling nottion: The dotted line indictes optionlity (s opposed mndry) ech side reltionship. Figure 1 shows tht ech my be (since this is dotted prt line) one nd only one CUSTOMER. Reding or wy, ech CUSTOMER must be role one nd only one. A crow s foot (three prongs t end reltionship line) indictes tht re re mny occurrences entity ner crow s foot ech entity tht is not ner crow s foot. For exmple, Figure 2 shows tht ech my be cting in one or more ROLEs (entity nmes will be shown in cps in this rticle). A # in front n ttribute indictes tht this ttribute is key. A * indictes tht ttribute is mndry ttribute. An bee n ttribute indictes tht ttribute is optionl. Boxes boxes indictes subtypes or subentries. The tilde () on reltionship line represents eign key inheritnce. This mens tht primry key on entity closest tilde includes s prt its key primry key entity without crow s foot. Figure 1: Specific Declrtive Roles Pttern independent ir role. When we look t ABC Corportion s only cusmer, we re sometimes not seeing whole picture. A prty such s ABC Corportion my be cusmer enterprise, nd it my lso be prtner nd supplier s well s ply mny or roles. When we confuse this nd just show prty s cusmer, its inmtion my show up in mny plces - one ech role it plys. By showing tht re is entity (which my be eir person or n orgniztion), which is distinguished from prty s vrious roles, we crete models tht more closely represent relity nd, ree, re more stble. The models in Figure 1 show spe-
cific pttern modeling roles nd prties s well s n exmple using this pttern. Ech role my be represented n entity nd ssocited entity. For exmple, re my be CUSTOMER, SUP- PLIER nd PARTNER role entities nd ech re relted - so tht if sme prty is cusmer, supplier nd prtner, ir inmtion (such s ir nme nd contct inmtion) is mintined once. This specific model is reltively esy understnd, but one issues in this model is tht one my not be ble identify ll roles tht will exist over time. Theree, s new roles re identified, dditionl entities re needed model. Furrmore, re my be common inmtion ll roles, such s need trck reltionships tht exist between ny type roles. The pttern nd exmple in Figure 2 shows more flexible dt model declrtive roles. The ROLE entity is ROLE * ID ROLE FIRST NAME LAST NAME DECLARATIVE ROLE 1 DECLARATIVE ROLE 2 DECLARATIVE ROLE N NAME n ssocitive entity between nd. The ROLE entity is supertype vrious roles tht could occur. It effectively tgs prty s hving one or more role. The ROLE TYPE mintins inmtion on possible roles tht exist, exmple, cusmer, supplier, prtner, worker nd so on. The left side model shows pttern tht ny enterprise my use nd right side this digrm shows n exmple tht my be pplicble some types enterprises, in exmple, mnufcturer products. The dvntge this model is tht s new roles re discovered over time, model cn more esily ccommodte se with ddition nor. There my lso be inmtion relted, such s product pricing, dependent on role tht one plys or uthoriztions bsed on role. Plese note tht style modeling shows subtypes s well s entity becuse some inmtion my be ssocited with specific role (e.g., slry n employee), while or inmtion my be relted role type in generl (pricing discounts or uthoriztions relted ). Contextul Roles Contextul roles define how prty is (or ws) involved context nor entity. For exmple, re could ROLE FIRST NAME LAST NAME Figure 2: Flexible Declrtive Roles Pttern # ID CONTRACTOR NAME EMPLOYEE CONTACT COMPETITOR CUSTOMER BILL TO CUSTOMER SHIP TO CUSTOMER END USER CUSTOMER DISTRIBUTION CHANNEL AGENT DISTRIBUTOR SUPPLIER REFERRER PROSPECT WEB SITE VISITOR in be severl roles tht people or orgniztions ply context project. A person or orgniztion my be involvement1 ROLE1 involvement2 ROLE2 involvement3 involvementn ROLE 1 ROLE 2 ROLE 3 ROLE 4 Figure 3: Specific Contextul Role Pttern sponsor, worker, mnger, led, dvisor or qulity ssurnce mnger project. This my pply ny or entity tht hs roles such s order, contrct, shipment, pyment or product. For exmple, shipment could hve roles receiver, sender, crrier, pprover, entered nd so on. Figure 3 shows pttern nd n exmple modeling contextul roles using specific style modeling. The pttern shows tht re my be ny number roles relted n entity nd ech role my be relted using eir M:M ssocition or 1:M reltionship. For exmple, re my be s, s, MANAGER nd LEAD specific. These roles my hve been first declred using previous pttern or y my just be roles tht re only contextul, without need declre m. The benefits using this pttern re tht it is reltively esy understnd, nd it cn ence specific business rules tht my pply, REGULATORY AGENCY ASSOCIATION SHAREHOLDER PARTNER # ID SCHEDULED START DATE SCHEDULED END DATE SCHEDULED COMPLETION DATE TOTAL MONEY ALLOWED TOTAL HOURS ALLOWED ESTIMATED HOURS ACTUAL START DATETIME ACTUAL COMPLETION DATETIME ACTUAL HOURS SPECIAL TERMS I believe tht re re usully not right nd wrong dt models, but pros nd cons vrious wys model dt. sponsored sponsoring ssigning mnged led mnging leding MANAGER LEAD
ROLE # ID # ROLE ID involved in John Smith, Mnger, Project 123, from 1/6/06-3/31/06 WORK EFFORT ROLE # WORK EFFORT ROLE ID involved in WORK EFFORT Project 123, Activity 123-04 John Smith, Slly Jones, ABC Corp. MANAGER,,, LEAD QA MANAGER, SUPERVISOR Figure 4: Flexible Contextul Role Pttern exmple, tht re my be only one project mnger nd only one project led project. The disdvntge using this pttern is tht business rules nd/or processes my chnge over time, nd dt model (nd underlying dtbse) my need be chnged. For exmple, wht if new role ws dded lter qulity ssurnce mnger, or wht if business rule chnged tht llowed severl project mngers on sme project (t sme time or over time)? Theree, Figure 4 shows more flexible pttern tht llows n entity hve ny number s involved in ny ny number time frmes. This pttern ccommodtes lmost ny type new modeling requirements tht could occur, including new roles tht could be dded over time, chnges business rules nd mintining hisry over time. However, drwbcks using this # ID EVENT1 DATETIME EVENT2 DATETIME EVENT3 DATETIME Figure 5: Specific Sttus Pttern pttern re tht it is much more bstrct, nd ree more difficult understnd. Also, this model doesn t ence specific business rules, exmple, if rule ws needed tht re cn only be single project mnger project. However, if we re seeking stble, solid foundtion our dtbses so tht new business rules do not result in chnges underlying dt structures, n this pttern my be idel. Sttuses Any time dte ttribute or dtetime ttribute is needed in model, modeler my wnt use ptterns in Figures 5 nd 6. Figure 5 shows pttern modeling sttuses using specific style modeling s well s n exmple tht shows n ppliction this pttern. The model shows tht n ORDER (which could be purchse order or sles order or both, depending on inmtion ORDER # ORDER ID * ORDER RECEIVED DATETIME ORDER ENTRY DATETIME CONFIRMATION DATETIME EXPECTED SHIPMENT DATETIME APPROVED DATETIME CANCELLATION DATETIME requirements) could include ttributes ll types sttuses tht re be trcked. However, wht if new sttus is needed, such s dte tht purchse order ws delyed nd when new expected shipment dte is expected? There lso my be need mintin hisry se sttuses, exmple, record first expected shipment dte nd n new expected shipment dte. Thus Figure 6 shows more flexible pttern nd n exmple modeling sttuses tht llows ny number sttuses nd ccommodtes hisry sttuses over time. This sme pttern could be pplied or entities, such s sttuses requirements, quotes, invoices, products or prties over time. Ctegories Anor common pttern tht frequently occurs in dt modeling dels with clssifiction entities. Dt models ten hve vrious clssifictions, types, groups, fmilies nd or wys ctegorize entities. For exmple, re my be product groups, product types, product fmilies, cusmer types, fcility types, industry clssifictions nd mny or ctegoriztions entities. Often se ctegoriztions re modeled independently, without firm understnding common wys model se ctegoriztions. Figure 7 shows pttern tht n entity my simply be or typed using 1:M reltionship from type entity entity. The exmple on
STATUS # ID # STATUS ID * STATUS DATETIME sttus in stte right digrm shows tht product my be vi TYPE (such s service, good or solution), FAMILY (such s household products, cr products or fice products), or LINE (such s commercil or residentil lines products). Additionlly, re my be types types, s shown in recursive reltionships round FAMILY. For exmple, re my be fmily fice products tht is furr s computer products, fice supply products nd so on. While this pttern provides cler understnding vrious ctegoriztions products, re re disdvntges using this style modeling. Wht if new types product ctegories re dded over time, such s types mterils used in products, industry which product is intended or ny or ctegoriztion tht cretive sles or mrketing person deems is needed? Figure 8 shows more flexible pttern nd exmple ctegorizing entities tht llows ny number clssifictions nd ny number levels clssifictions. For exmple, if n entity such s seems hve mny different wys clssify it, with mny different levels clssifictions, n this flexible model my be pproprite. The CATEGORY entity could mintin ll types ctegories t vrious levels nd CATEGORY ROLLUP could mintin which product ctegoriztions roll up which higher level ctegoriztion. For exmple, in Tble 1 product ID 2222 Johnson bond pper 2000 my be s both n fice supply product, recurring product nd product type good (s opposed service). The CATEGORY CLASSIFICATION STATUS TYPE sttus Figure 6: Flexible Sttus Pttern ORDER STATUS # ORDER ID # ORDER STATUS ID * STATUS DATETIME in stte ORDER would relte this product lowest level ctegory tht pplies (tht Johnson bond pper is n fice supply), nd n CATEGORY ROLLUP could mintin tht product ctegory fice supplies is higher-level ctegory fice products nd tht household products ctegory is product fmily ctegory. Specific versus Abstrct Models By now you my be seeing pttern se ptterns. There re usully multiple wys model ny construct. This rticle covers only couple wys model few exmples ptterns; however, re re mny more ptterns nd vritions tht exist. One mjor vritions in modeling stems from wher model is using specific or bstrct style modeling. How cn one know wher use # ID STATUS TYPE clssifiction RECEIVED ENTERED CONFIRMED EXPECTED SHIPMENT APPROVED CANCELLED DATE TYPE # TYPE ID Figure 7: Specific Clssifiction Pttern specific pttern or n bstrct pttern? One could first sk question, Wht is purpose dt model? I believe tht re re two key purposes dt model: 1) To illustrte nd communicte inmtion requirements nd 2) To model sound foundtion dtbse design. These purposes cn be t odds with ech or. If purpose is illustrte nd communicte inmtion requirements, n modeler will most probbly develop more specific model showing specific needs business representtive. For instnce, model my show specific roles involved in project such s sponsors, workers, project mnger nd project led with specific crdinlities s shown in Figure 3. If purpose is model sound foundtion dtbse design, n modeler my incorporte flexibility nd use pttern such s one in Figure 4, where re cn be ny number prties nd roles over ny time period, nd thus model is very stble nd very unlikely need chnges bsed upon new business processes or rules. With this model, mny rules tht re in specific model my be documented in some or mt s n djunct dt model. If you re n dvocte Zchmn Frmework, you my recognize tht re my be different udiences dt model which results in need two models: model owner/ business representtive nd model designer/rchitect. The model tht one develops n owner or business representtive would most likely be specific model, nd ree one could use specific ptterns illustrte nd # ID DESCRIPTION clssifiction clssifiction clssifiction TYPE # TYPE ID composed FAMILY # FAMILY ID LINE # LINE ID
CATEGORY CLASSIFICATION ctegory defined mde up used define CATEGORY # CATEGORY ID ctegorized contining # ID CATEGORY ROLLUP prt communicte ir needs. The model designer or rchitect would most likely be designed flexibility nd dptbility chnge, reducing mintennce costs. Thus, CATEGORY CLASSIFICATION ctegory defined mde up used define Figure 8: Flexible Clssifiction Pttern WORK EFFORT SCHEDULED START DATE SCHEDULED END DATE SCHEDULED COMPLETION DATE TOTAL DOLLARS ALLOWED TOTAL HOURS ALLOWED ESTIMATED HOURS ACTUAL START DATETIME ACTUAL COMPLETION DATETIME ACTUAL HOURS SPECIAL TERMS WORK EFFORT ROLE # WORK EFFORT ROLE ID is sponsored ssigning mnged led CATEGORY # CATEGORY ID ctegorized contining # ID CATEGORY ROLLUP prt more bstrct nd flexible ptterns could be used develop this type model. To mintin business dt model nd n rchitecture dt model nd Figure 9: Specific nd Flexible Contextul Role Pttern Toger involved in sponsoring mnging MANAGER leding ROLE LEAD mp nd cross-reference m cn be quite bit work. A possible solution this is incorporte both specific nd bstrct ptterns in sme model s shown in Figure 9. Views cn be creted show specific spects model s well s bstrct spects model. For exmple, one could show view specific reltionships vrious roles work eft, nmely, sponsors, workers, project mngers nd project leds in order vlidte requirements. Then one could show n rchitecturl view model showing tht work eft (which could be project, ctivity, tsk or ny or unit work) my hve ny number prties with ny number roles ssocited with it over time. A Universl Approch Most dt models hve need mintin very common types dt such s sttuses, ctegoriztions nd roles tht vrious prties ply. There re severl wys model se recurring dt constructs, nd modeling method ten vries how specific or bstrct one chooses model dt. By providing severl effective lterntives modeling ech pttern (including specific nd bstrct styles) nd criteri mking choices between se lterntives, we cn develop more integrted nd much higher qulity dt models in shorter time frmes. Len Silversn is best-selling uthor The Dt Model Resource Book series, which describe more thn 230 reusble dt models nd which ws rted #12 on Computer Litercy Best Seller List. He is n uthor, consultnt nd speker with more thn 24 yers experience helping orgniztions integrte ir dt nd systems. Silversn hs been contribur DM Review nd frequently invited speker t mny interntionl conferences. He is winner DAMA Interntionl Pressionl Achievement Awrd 2004. Silversn s compny Universl Dt Models provides consulting, trining nd stwre jumpstrt dt modeling nd dt wrehouse design efts while incresing design qulity. 2005 SourceMedi, Inc. nd DM Review. All rights reserved. SourceMedi, One Stte Street Plz, New York, N.Y. 10004 (800) 367-3989