《中國電子商務(wù)》期刊介紹

/《中國電子商務(wù)》期刊簡介一、期刊名稱《中國電子商務(wù)》二、刊號國內(nèi)標(biāo)準(zhǔn)刊號：CN11-4440/F國際標(biāo)準(zhǔn)連續(xù)出版物號：ISSN1009-4067三、主管單位國家工業(yè)與信息化部四、主辦單位中國電子企業(yè)協(xié)會五、辦刊宗旨《中國電子商務(wù)》以傳播信息化理念、報(bào)道經(jīng)濟(jì)前沿、倡導(dǎo)信息創(chuàng)新、促進(jìn)經(jīng)濟(jì)開展為辦刊宗旨，大力普及電子商務(wù)知識，弘揚(yáng)科學(xué)精神，傳播科學(xué)思想，倡導(dǎo)科學(xué)方法。六、刊登內(nèi)容《中國電子商務(wù)》是廣闊經(jīng)濟(jì)和信息化領(lǐng)域的管理人員、科教工作者、高校師生、信息化技術(shù)人員發(fā)布學(xué)術(shù)文章的重要理論陣地，是獲取精神陶冶、知識滋養(yǎng)和科技經(jīng)濟(jì)信息的重要渠道。本刊主要刊登我國當(dāng)前信息化有關(guān)的科技、經(jīng)濟(jì)、教育、管理等方面具有一定學(xué)術(shù)和應(yīng)用價(jià)值的學(xué)術(shù)文獻(xiàn)和反映各學(xué)科、各領(lǐng)域的新成果、新技術(shù)、新工藝、新產(chǎn)品等方面的論述文章。七、主要欄目1.經(jīng)濟(jì)管理研究：國際經(jīng)貿(mào)、物流論壇、商業(yè)研究、物流平臺、供給鏈管理、資本運(yùn)營、區(qū)域經(jīng)濟(jì)、投資分析、產(chǎn)業(yè)經(jīng)濟(jì)、網(wǎng)絡(luò)營銷、企業(yè)管理、經(jīng)營管理、營銷策略、品牌戰(zhàn)略、市場調(diào)研、人力資源、企業(yè)文化、財(cái)務(wù)審計(jì)、財(cái)經(jīng)論壇、學(xué)術(shù)研究、管理科學(xué)。2.信息化研究：信息技術(shù)與平安、通訊技術(shù)、網(wǎng)絡(luò)技術(shù)、自動識別技術(shù)與應(yīng)用、電子商務(wù)、支付與結(jié)算、供給鏈管理、數(shù)據(jù)庫與數(shù)據(jù)庫管理、案例分析。3.科技研究：科技工程、科技政策、科技成果、科學(xué)普及、技術(shù)市場、科技新品、實(shí)用科技、科學(xué)實(shí)踐等、機(jī)電一體化、電氣自動化。4.教育教學(xué)研究：教學(xué)研究、教育生活、課程與教學(xué)、教育信息化、職教時(shí)空、教學(xué)園地、信息化教學(xué)等。5.工程技術(shù)研究：建筑工程、生物工程、醫(yī)學(xué)工程、環(huán)境科學(xué)、礦業(yè)工程、市政建設(shè)、水利工程、交通工程等。八、讀者對象經(jīng)濟(jì)領(lǐng)域和信息化領(lǐng)域的管理人員、科技企業(yè)科研開發(fā)人員、高等院校師生、信息化技術(shù)科研人員，社會各界關(guān)注經(jīng)濟(jì)開展和信息化開展的各界人士。聯(lián)系方式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