《中国电子商务》期刊介绍

/《中国电子商务》期刊简介一、期刊名称《中国电子商务》二、刊号国内标准刊号：CN11-4440/F国际标准连续出版物号：ISSN1009-4067三、主管单位国家工业与信息化部四、主办单位中国电子企业协会五、办刊宗旨《中国电子商务》以传播信息化理念、报道经济前沿、倡导信息创新、促进经济开展为办刊宗旨，大力普及电子商务知识，弘扬科学精神，传播科学思想，倡导科学方法。六、刊登内容《中国电子商务》是广阔经济和信息化领域的管理人员、科教工作者、高校师生、信息化技术人员发布学术文章的重要理论阵地，是获取精神陶冶、知识滋养和科技经济信息的重要渠道。本刊主要刊登我国当前信息化有关的科技、经济、教育、管理等方面具有一定学术和应用价值的学术文献和反映各学科、各领域的新成果、新技术、新工艺、新产品等方面的论述文章。七、主要栏目1.经济管理研究：国际经贸、物流论坛、商业研究、物流平台、供给链管理、资本运营、区域经济、投资分析、产业经济、网络营销、企业管理、经营管理、营销策略、品牌战略、市场调研、人力资源、企业文化、财务审计、财经论坛、学术研究、管理科学。2.信息化研究：信息技术与平安、通讯技术、网络技术、自动识别技术与应用、电子商务、支付与结算、供给链管理、数据库与数据库管理、案例分析。3.科技研究：科技工程、科技政策、科技成果、科学普及、技术市场、科技新品、实用科技、科学实践等、机电一体化、电气自动化。4.教育教学研究：教学研究、教育生活、课程与教学、教育信息化、职教时空、教学园地、信息化教学等。5.工程技术研究：建筑工程、生物工程、医学工程、环境科学、矿业工程、市政建设、水利工程、交通工程等。八、读者对象经济领域和信息化领域的管理人员、科技企业科研开发人员、高等院校师生、信息化技术科研人员，社会各界关注经济开展和信息化开展的各界人士。联系方式TEL：

Email:

SomeofthematerialpresentedinthisarticlewasexcerptedwithpermissionfromTheDataModelResourceBook:ALibraryofLogicalDataModelsandDataWarehouseDesignspublishedbyJohnWileyandSonsandauthoredbyLenSilverston,W.H.InmonandKentGraziano.TheConceptTheageofthedatamodelerasartisanispassing.Organizationscannolongeraffordthelaborortimerequiredforhandcraftingdatamodelsfromscratch.Inresponsetotheseconstraints,theageofthedatamodelerasengineerisdawning.Engineersbuildnewproductsusingprovencomponentsandmaterials.Indatamodeling,theanaloguetoacomponentisa"universaldatamodel."Auniversaldatamodelisagenericortemplatedatamodelthatcanbeusedasabuildingblocktojump-startdevelopmentofthecorporatedatamodel,logicaldatamodelordatawarehousedatamodel.Resistancetotheuseofuniversaldatamodelsisusuallybasedonthebeliefthataparticularorganizationhasuniqueneedsorthedreaded"notinventedhere"syndrome.Thisarticledescribestheapplicationofuniversaldatamodelstoseveraldisparateorganizations.Itdemonstratesthatthesamebasicmodels,withminorcustomization,canbesuccessfullyappliedineachexample.OneSizeFitsAll?Thebeliefthataparticularorganizationisuniquebecauseofitsmissions,goals,policies,values,functions,processesandrulescanbeverystrong.Afterall,somebusinessesselltopeopleandothersselltootherorganizations.Somedealwithproductsandothersdealwithservices.Eachindustryhasitsownsetofbusinessissues,andeachorganizationwithinanindustryvariesasmuchasthedifferencesbetweenthepersonalitiesofvariousindividuals.PeopleandOrganizationsAsubjectdataareathatiscommontomostenterprisesinvolvesthepeopleandorganizationsthatarepartofconductingbusiness.Thereisanimportantneedtotrackthenames,addresses,contactnumbersandvariousrelationshipsandinteractionsbetweenthepartiesconductingbusiness.Enterprisesneedtotrackinformationaboutcustomers,distributors,agentsandsuppliersaswellastheinternalorganizationsandpeoplewithintheenterprise.Thistypeofinformationiscriticalthroughoutallaspectsofbusinessincludingsales,marketing,customerservice,purchasing,shipping,invoicing,budgeting,accountingandhumanresources.Enterprisesspendsignificanteffortandtimedefiningthemosteffectivewaystomodelthistypeofinformation.Thedatamodelmayleadtosub-optimalsolutionsifcarefulanalysisisnotconducted.Forexample,manydatamodelsdepictseparateentitiesforeachtypeofpartythatexistsinanenterprise.TheremaybeentitiesforCUSTOMER,SUPPLIER,INTERNALORGANIZATION,BROKER,EMPLOYEE,INVESTORandanyotherrolethatapersonororganizationmayplayintheenterprise.Thereareproblemswithmodelingtheinformationthisway.Whatifapersonororganizationplaysmorethanoneroleintheorganization?Forinstance,whatifanorganizationsuppliesproductsand/orservicestoourorganizationandalsobuysproductsfromus?Doesthismeanthatwemaintaintheirname,addresses,contactnumbersandotherorganizationalinformationinboththeCUSTOMERandSUPPLIERentities?Underthisscenario,ifanameoraddresschanges,theinformationneedstobechangedintwoplaces.Furthermore,doestheorganizationplayotherrolessuchasanagentofthecompanyoradistributorofproducts?Eachtimeanorganization'sroleismodeledasaseparateentity,thereisapotentialforredundantandinconsistentinformation.Thesameargumentappliestopeople.ShouldwehaveaseparateEMPLOYEEentityaswellasaCONTRACTORentity?Whatifacontractorbecomesanemployeeoftheenterpriseorviceversa?Theperson'sname,demographicsandcontactinformationmaystillbethesame.Theonlythingthathaschangedisthenatureoftherelationshipbetweentheparties.Itonlymakessensetorefertopre-definedtemplatesoruniversaldatamodelswhenmodelingcommondatastructures.Universaldatamodelscanpointoutthemosteffectivemeanstomaintainthisinformationandassurethatsubtle,yetimportant,dataintegrityissuesarenotoverlooked.PeopleandOrganizationInformationFigures1,2,3and4depictuniversaldatamodelsforthepeopleandorganizationsinvolvedinconductingbusiness.Thesedatamodelsincludeinformationconcerningtherelationshipsbetweeneachpersonandorganizationaswellastheirassociatedcontactinformation.Beforebeginningourdiscussionofthesemodels,let'sclarifysomedatamodelingconventions.Entitiesarerepresentedusingrounded-edgerectangularboxes.Sub-typesarerepresentedbyshowingboxeswithinthelargerbox.Forexample,inFigure1,ORGANIZATIONandPERSONarebothrepresentedassub-typesofPARTY.Thelinesbetweenentitiesdefinerelationships.Thedashedsectionofeachlinerepresentsthatarelationshipisoptional.Forexample,inFigure1,aPARTYdoesnotnecessarilyhaveanassociatedPARTYDEFINITION.ThepartofthelineclosesttoPARTYDEFINITIONissolid,andthisrepresentsamandatoryrelationship.Therefore,eachPARTYDEFINITIONmustbeassociatedwitharelatedPARTY.ThesmallcrossedlineacrossthePARTYDEFINITIONtoPARTYrelationshipspecifiesthatthekeytoPARTY(party_id)isincludedaspartofthekeytoPARTYDEFINITION.The"crowsfeet"(threesmalllinesattheendofeachrelationshipline)denoteaone-to-many(1:M)relationship.Forexample,EachPARTYmaybedefinedbyoneormorePARTYDEFINITIONs.Viceversa,eachPARTYDEFINITIONmustbeusedtodefineoneandonlyonePARTYsincethelinefromPARTYDEFINITIONtoPARTYdoesnotendwitha"crowsfoot."Nowlet'sdiscussthedatamodels.Figure1identifiesasuper-typenamedPARTY,withtwosub-types,PERSONandORGANIZATION.Informationaboutapersonororganizationismaintainedindependentoftheirrolesorrelationships.Thisleadstoamuchmorestableandnormalizeddatastructuresinceinformationaboutvariouspeopleandorganizationsisonlystoredonce.Thesameinformationcanthenbeassociatedwitheachoftheparty'sroles.ThereasonthatPERSONandORGANIZATIONarebothsub-typedintoaPARTYentityisthatthereiscommoninformationrelatedtobothpeopleandorganizationssuchastheircreditrating,creditlimit,address,phonenumber,faxnumberore-mailaddress.Additionally,organizationsandpeoplecanserveinsimilarroles.Bothpeopleandorganizationsmaybebuyers,sellers,membersorpartiestoacontract.Partiesmaybeclassifiedintovariouscategories(i.e.,industrycodes,minorityclassifications)usingthePARTYDEFINITIONwhichstoreseachcategoryintowhichpartiesmaybelong.Figure2depictsthateachPARTYmaybeinvolvedinoneormorePARTYRELATIONSHIPs.PARTYRELATIONSHIPisusedtodefinetherelationshipbetweentwoparties.AnoccurrenceofaPARTYRELATIONSHIPmaybebetweentwoorganizations,suchasacustomerrelationshiptoaninternalcompany.Therelationshipmaybebetweenapersonandanorganization--forexample,anemployeeofaninternalcompany.Finally,therelationshipmaybebetweentwopeople.Anexampleofthisistherelationshipbetweenapurchasingagentandtheirpreferredsupplierrepresentative.ThePARTYRELATIONSHIPTYPEdefinesthepossibletypesofrelationships.PossibleinstancesofPARTYRELATIONSHIPTYPEare"employer/employee,""parent/subsidiary,"and"customer/customerrepresentative."ThePARTYTYPEROLEdefinesthetwopartsoftherelationship.Forexample,oneroleoftherelationshipmaybe"employer"andtheotherroleforthatsamerelationshipmaybe"employee."Finally,thePARTYPRIORITYandPARTYRELATIONSHIPSTATUSTYPEentitiesalloweachPARTYRELATIONSHIPtobeprioritized(high,medium,low)anddefinedviaastatus(active,inactive).BydistinguishingwhetherinformationshouldbeassociatedwiththePARTYorthePARTYRELATIONSHIP,wecanavoiddataanomalies.Forexample,manydatamodelsassociateastatuswithaPARTY.Thisdoesnotaccountforthefactthatthreesalesrepresentativesmayhavethreedistinctrelationshipswiththesameparty.Eachsalesrepresentativemaywanttorecordadifferentstatusfortheirrelationshipwiththeparty.IfthestatuswerestoredwiththePARTY,thenthesalesrepresentativeswouldhavetooverrideeachother'sinformation.Inactuality,therearereallythreeseparaterelationships,andthestatusshouldbeassociatedwiththePARTYRELATIONSHIP.Figures3representsaddressorlocationinformationaboutparties.ItshowsthatADDRESSisitsownentityandcanbeappliedtomanyparties.ThePARTYADDRESSisacross-referenceorassociativeentitythatallowseachpartytohavemanyaddresses(homeaddress,workaddress)andeachaddresstohavemanyparties(anofficelocationofmanyemployees).EachPARTYADDRESSmayhavemanyPARTYADDRESSROLESandviceversa.Theserelationshipsdeterminethepurposeoftheaddress.ExamplesofPARTYADDRESSROLEinclude"corporateheadquarters,""salesoffice"and"warehouse."Figure4isamodeltomaintainphonenumbers,faxnumbers,cellnumbers,e-mailaddressesandallotherCONTACTMECHANISMs.Insteadofdefiningthesecontactmechanismsasattributes,thismodelprovidesflexibilityinallowingasmanycontactmechanismstobestoredforaPARTYorPARTYLOCATIONasneeded.TheCONTACTMECHANISMTYPEentityidentifiesthetypeofmechanismsuchasphone,fax,cellularorpager.ThePARTYCONTACTMECHANISMisanassociativeentitythatallowseachCONTACTMECHANISMtoberelatedtomanyPARTYADDRESSesorPARTYs(asharedtelephonenumberforseveralconsultants).Conversely,eachPARTYorPARTYADDRESSmaybecontactedviamanyPARTYCONTACTMECHANISMs(apersonorlocationwithnumerouscontactmechanismsofdifferenttypes).ThelineconnectingthetworelationshipsunderPARTYCONTACTMECHANISMrepresentsanexclusivearcandstatesthateitheroneoftheserelationshipsexists,butnotboth.APARTYCONTACTMECHANISMmaybeeitherthemechanismtocontactaPARTYoraPARTYADDRESS.Similartoaddresses,contactmechanismsmayhaveroles.ExamplesofPARTYCONTACTMECHANISMROLETYPEsinclude"generalinformationnumber,""salesinformation"and"customerservicenumber."Afterextensiveanalysisandconsiderationofmanyalternatedatamodels,Ibelievethatthesefouruniversaldatamodelsrepresentaveryeffectivewaytomodelpeopleandorganizationsformostenterprises.Nowlet'stakealookathowtheseuniversaldatamodelscanbeappliedtospecificenterprises.AManufacturingEnterpriseLet'sconsidertheneedsofaparticulartypeofenterprise,specificallyamanufacturingfirm.Supposethisfirmmanufacturespersonalcomputers.Theyselltheirproductstoretailchains,distributorsanddirectlytoindividualsandorganizations.Itisimportanttorecordcontactinformationoneachdistributorandthepeoplewithinthoseorganizations.TheyneedtotracksupplierinformationtoindicatewhoprovidesPCcomponentsfortheirmachines.Informationontheirend-usercustomerswhohaveboughttheirequipmentiscritical.Theyalsomaintainemployeeinformationaswellasinformationaboutthemanysubsidiaries,divisionsanddepartmentsandtheirassociatedlocations.Thefirstcommentsanenterprisemaymakeaboutusingthepreviouslypresenteduniversaldatamodelsare"Whereisthecustomerentity?Ourmostimportantinformationneedsareaboutourcustomers.Weneedtorecordtheircreditlimit,billingoptionsandtheircustomerstatus.Similarly,wherearetheentitiesforsupplier,employee,distributororinternalorganization?"Eachofthesebusinessentitiesischaracterizedbyverycommoninformation.Theyallhavenames,addresses,phonenumbers,statusesandothercontactinformation.Thisleadsustotheconclusionthattheycouldbesub-typedtogether.Shouldwethenmodifythemodeltoaddthesub-typesCUSTOMER,SUPPLIER,DISTRIBUTOR,INTERNALORGANIZATIONandEMPLOYEEallwithinthePARTYentity?Anissueisthatasinglepersonororganizationmaybeinvolvedinmorethanoneoftheserelationships.Forexample,adistributorofthemanufacturermayalsobeasupplierofsomeoftheirPCcomponents.Again,wedonotwanttomaintainmorethanoneoccurrenceofthesamepersonororganizationasthiscanleadtodatainconsistencies.Figure5illustrateshowthepreviouslydescribeduniversaldatamodelscanbemodifiedtomeettheinformationneedsofourmanufacturingexample.Forsimplicityreasons,onlyafewimportantentitiesareshowninFigure5,butallpreviouslydescribedentitiesalsoapplytoourmanufacturingfirm.ThePARTYRELATIONSHIPissub-typedintotheapplicablebusinessrelationships,CUSTOMER,SUPPLIER,DISTRIBUTOR,EMPLOYEEandINTERNALORGANIZATION.Thisallowseachpersonororganizationtobeinvolvedinoneormoreofthoserelationships.Ifthereareothertypesofrelationshipssuchassalesagents,governmentagencieswhoregulatemanufacturingorstockholders,theycanalsobedefinedasadditionalPARTYRELATIONSHIPsub-types.Thebasicinformationabouteachpersonororganizationsuchastheirnames,creditrating,addresses,phonenumbersandothercontactinformationisassociatedwiththePARTY.TheinformationabouteachrelationshipisstoredinthePARTYRELATIONSHIPentity.Allsub-typesofPARTYRELATIONSHIPhaveafrom_date,through_dateandcomments.EachPARTYRELATIONSHIPsub-typemayhavedifferentattributestodefinethatspecificrelationshiptype.Forexample,theCUSTOMERsub-typehasacreditlimit,statement_day(definedastheclosingdayforstatements),andstatement_frq(definingthefrequencyofstatementssuchasweekly,bi-monthlyormonthly).Thismodelprovidesanextensive,flexibleandstablemeansofmaintainingpersonandorganizationinformationforthemanufacturingorganization.TheonlycustomizationrequiredwastoaddthePARTYRELATIONSHIPsub-typesapplicabletothemanufacturer.AFinancialSecuritiesCompanyIsthismodelapplicabletootherenterprisessuchasafinancialsecuritiescompany?Let'sassumethatthisenterprisesellsinvestmentvehiclessuchasmutualfunds,stocks,bondsandotherinvestmentstothegeneralpublic,mostlythroughbrokers.Thesametypeofbaseinformationisneededforpeopleandorganizationsinthistypeofcompany:theirnames,addresses,phonenumbersandinformationaboutdifferenttypesofpartiesandrelationships.Thedifferenceisinthetypesofbusinessrelationshipsinvolvedinafinancialsecuritiesfirm.Afinancialsecuritiescompanyneedstotrackinformationabouttheirbrokers,investors,wholesalers(thepartysellingtothebroker),employeesandinternalorganizations.Figure6showsthatthissameuniversaldatamodelcanbeeffectivelyusedforafinancialsecuritiescompanybyaddingtheapplicablePARTYRELATIONSHIPsub-typesandassociatingappropriateattributestoeachtypeofrelationship.InvestmentgoalisanattributeofINVESTOR,annualquotaisanattributeoftheWHOLESALERthatsellstothebrokerandtheexclusiveindicatorandbrokerlicensenumberarestoredfortheBROKERsub-type.OtherEnterprisesBynow,itishopefullyevidentthatmostenterprisescanusethissamemodelandcustomizeitbyaddingsub-typestorepresenttheirownpartyrelationships.HealthcareenterprisesmayhaveDOCTOR,PATIENT,INSURANCECOMPANY,HMOandPPOasPARTYRELATIONSHIPsub-types.UniversitiesmayhaveSTUDENT,FACULTY,ADMINISTRATOR,GOVERNMENTAGENCY(forgrants)andDONATORaspossiblesub-types.InaconsultingservicesenterprisethepartyrelationshipsmaybeCONSULTANT,CLIENT,INTERNALSTAFFandDEPARTMENT.Everyenterprisehasthesametypeofdatastructuresrelatedtopeopleandorganizations,buttheyareappliedtowarddifferenttypesofrelationships.OtherModelsWehaveonlyexamineddatamodelsforonecommonaspectofbusiness;namely,managingpartyandrelationshipinformation.Therearemanyotheruniversaldatamodelsformaintaininginformationonproduct/services,orders/agreements,shipments,timeentry,invoices,accounting,budgetingandhumanresources.Therearealsouniversaldatamodelsforstandarddatawarehousedesignapplicationssuchassalesanalysis,financialanalysisandhumanresourceanalysis.Ihavesuccessfullyassistedenterprisesinapplyingthesetemplatemodelsagainstmanyindustriesandhavefoundthatquiteoften60percentoftheuniversaldatamodelconstructsareapplicable.Thistranslatesintodatamodelsofmuchbetterqualityandsubstantialsavingsoftimeandcost.ConclusionUniversaldatamodelscansubstantiallyreducethetimetocompleteacorporatedatamodel,logicaldatamodelordatawarehousedesign.Theycanleadtohigherqualitydesignsbyidentifyingsubtletiesthatmaybeoverlookedbyinexperiencedmodelersorharriedmodelerswhomayhavetightprojectdeadlines.Businessesareveryunique.However,mostbusinesses'underlyingdatastructuresareverysimilar.Thisarticleusedspecificexamplestoillustratethatuniversaldatamodelscanbeeffectivelyappliedtodiversetypesofenterprises.Therearemanyotherexamplesofuniversaldatamodelsthatcansavetremendousamountsoftimeand,atthesametime,producehighqualitydatamodelsanddatawarehousedesigns.ThisarticlewaspreviouslypublishedinDataManagementReview()magazine(Vol.8No.8)inPhysicallyImplementingUniversalDataModelstoIntegrateDataInformationManagementMagazine,September2002HYPERLINKLenSilverstonTherehavebeenseveralrecentarticlesandbookspublishedconcerninguniversaldatamodelswhicharereusablemodelsforcommondataconstructsandindustryapplications(seeDMReview,January,March,MayandJuly2002,andTheDataModelResourceBooks,Volumes1and2,Wiley2002),buthowcanoneusethesetemplatesoruniversaldatamodelstoreallymakeadifference?Thesemodelscanbeusedasatooltoquicklydevelopqualitydatabasedesignsbyreusingcommonlyavailabledatamodelswhichareapplicabletotheenterprise'srequirementsandcustomizingthedetailsfortheapplicationathand.However,thereisanotherpurposeformanyofthesemodels–theyprovidepracticaldesignsandinsightsforintegratingdata,thusprovidingenterpriseswithpowerfulenterprise-wideinformation.Thisarticleprovidessuggestionsonhowtouseandimplementuniversaldatamodelstohelpprovidemoreintegratedandbetterqualityinformation.Forinstance,howcanthesemodelsbeusedtoidentifyandresolvedatainconsistenciesbetweenvarioussourcesystemsorapplicationpackages?Howcanthesemodelsbeusedtophysicallyconsolidateandintegratedata,providingpowerfulintegratedviewsofinformation?AdvertisementIntegratingDataIhaveheardthestatement,"Oursystemsaremostlybaseduponapplicationpackages.Universaldatamodelsseemvaluableforbuildinganewdatabase,butwhywouldweneedthem?Asamatteroffact,whywouldweneedanytypeofdatamodelsifourpackagesalreadyhaveadatabasedesign?"Asidefromtheusageofdatamodelstodefinethedatarequirementsofpossibleapplicationpackages,universaldatamodelscanbeusedtosynchronizeandintegrateinformationacrossvariousapplicationswithinanenterprise.Withoutanenterprise-wideintegratedpictureofhowdatarelatesacrossapplications,itisverydifficulttobuildintegratedarchitecturesthatprovideaccurate,consistentandintegratedinformation.FlexibleStructureEnterpriseresourceplanning(ERP)applicationpackagesclaimtooffercompleteenterprise-wide,integrated,customizablesolutions.However,organizationsthatselectanERPpackagegenerallyalsohavenumerousotherapplicationpackagesinordertoobtainbest-of-breedsolutions.Therefore,enterpriseswilloftenhaveoverlapping,redundantandincompletedatasources.Universaldatamodelsofferflexiblestructuresthatcanaccommodatealmostanydataformatfromanyapplicationpackage,allowingthedatafrommultiplepackagestobesynchronizedandintegratedwithinasingledataconstruct.Forexample,manyenterprisesselectaspecializedcontactmanagementapplicationpackage;anERPpackagetohandletheirmainlineorder,shipmentandinvoicingprocessing;aproductconfigurationand/orquotingsoftwarepackage;andanaccountingsoftwarepackage.Customer,supplierandemployeeinformationmay,therefore,berecordedredundantlyinthesesystems.Howcaninformationfromthesepackagesbesynchronizedandintegrated?Considerthestandardparty,partyroleandpartyrelationshipuniversaldatamodelthatisshowninFigure1.Notethatthisisjustoneexampleofauniversaldatamodel.Therearemanyotheruniversaldatamodelsforothercommonconstructs.ThismodelillustratesthataPARTYmaybeeitheraPERSONoranORGANIZATION,thateachPARTYmaybeactinginoneormorePARTYROLESovertimeandthateachcombinationofPARTYROLESformsvarioustypesofPARTYRELATIONSHIPS.ThePARTYentityfacilitatesaconsistentplacetostoredatasuchascontactdataordemographics,regardlessoftheirrole,thusavoidingredundant,inconsistentdata.ThePARTYROLEentitymaintainsinformationthatisrelevanttoaspecificrolethatapartymayplaysuchaspayrolldatarelatedtotheroleofEMPLOYEEorcredit-checkdatarelatedtotheroleCUSTOMER.ThePARTYRELATIONSHIPentityprovidesaplacetomaintaininformationrelevanttotherelationshipbetweenpartiessuchastherelationshipstatus,therelationshippriorityormeetings,phoneconversationsandothercommunicationeventsthatoccurredwithinthecontextofeachrelationship.ThisuniversaldatamodelprovidesasingleplacetomaintainPERSONandORGANIZATIONinformation,namelyinthePARTYentity.However,becausethereareusuallymultipleapplicationsanddatabaseswithinanenterprise,thesamepartymayexistineachoftheenterprise'ssystemsandmaybeinconsistentanddisjointed.

Figure1:UniversalDataModelforParties,PartyRolesandRelationshipsTheWholePartyThe"party"universaldatamodelinFigure1canofferthecapabilitytoviewconsolidated,integratedinformationforeachpartyonlyifthereisamechanismtocross-referencetheparty'senterprisekeywitheachoftheapplicationkeys.Forexample,supposethereareseveralrecordsforthesameperson,JohnSmith–oneinthecontactmanagementsystemandanotherrecordintheERPapplication.Theinformationfrombothsystemscouldbedifferent;forinstance,thenamecouldbespelleddifferentlyortherecouldbeadifferentpostaladdress,inconsistentphonenumberorinconsistentvalueforthedemographicdata.Cross-ReferencingtheDataFromMultipleApplicationsThekeytoprovidinganintegratedprotosetupanenterprise-widekeyforeachPARTY(intheuniversaldatamodel)andtocross-referenceitagainsteachoftheapplicationsystems–inthiscase,thecontactmanagementsystemandtheERPapplication.Therearethreegeneralstrategiesforcross-referencingthisinformation:Createaforeignkey,party_id,fromeachapplicationthatcross-referenceseachapplicationkeywiththeenterprisekey.Createacross-referencetablethatcross-referenceseachapplicationkeywiththeenterprisekey.Useacombinationofthesetwostrategies.Cross-ReferenceApplicationsIfthesystemcouldrelateandcross-referencealloccurrencesofanygivenparty,itwouldbeeasytoobtainalltheinformationaboutthatparty.Thisissignificantbecausetheabilitytohavecompleteinformationoneachpersonororganizationinanenterpriseisamajoradvantagetomostaspectsofbusiness,includingsellingandservicing.Figure2illustrateshowthephysicaltableswouldlookusingthiscross-referencestrategy.Theparty_idforJohnSmithisidentifiedas"111257."AnywhereJohnSmithhasarecord,thereisaforeignkeyof"111257,"thusallowinghisdatatobeconsolidated.Thus,theenterprisecouldcreatequeriesandreportsthatjointhePARTYtablefromtheenterprise-wideschema(possiblycontainedwithinanoperationaldatastoreoradatawarehouse)witheachoftheapplicationtablesthathasacorrespondingparty_idforeignkey.

Figure2:Cross-ReferencingApplicationstoUniversalDataModelsUsingForeignKeysCross-ReferenceTableThesecondstrategyinvolvescreatingacross-referencetable,linkingeachenterprise-widekeywiththeassociatedapplicationkey.Figure3illustrateshowthesetablescouldbesetuptocross-referenceanenterprise-widekeywithapplicationkeys.NoticethateachinstanceofkeysforJohnSmithisnowlinkedtohisenterprise-widekey.

Figure3:Cross-ReferenceTabletoMapApplicationKeystoEnterpriseKeysThisstrategyrequiresthatapplicationkeysarestoredredundantlyinthiscross-referencetable.Thisrequiressubstantialoverheadbecauseeverytimeanewapplicationkeyforapartyroleisgeneratedorchanged,thecross-referencetableneedstobeupdated.Whywouldoneusethisstrategyversusjustupdatingeachtablewithaforeignkey?Theansweristhatitisnotalwayspossibleoreasytoupdateeachapplicationwithaforeignkey.Forinstance,itmaybeverydifficultorevenimpossibletoaddforeignkeyfieldstolegacyapplications,custom-developedapplicationsorcertainapplicationpackages.Anothersolutionistoaddforeignkeyfieldswhenpossibleanduseacross-referencetablewhenitisnotpossibleorpractical.Thisallowsthecross-referencetabletobesmallerandreducestheoverheadfortheapplicationsthatusetheforeignkey;however,thedownsidetothisstrategyisthattheroutinesforobtainingaconsolidatedviewoft