建立物理模型

建立物理模型第一页，共八十六页，2022年，8月28日Contents在SQLServer中建立物理模型(CreatingthePhysicalModel

withSQLServer)

√索引方面的考虑(IndexingConsiderations)建立抽象层(CreatinganAbstractionLayer

inSQLServer)第二页，共八十六页，2022年，8月28日CreatingthePhysicalModel

withSQLServer是时候生成数据库了,本节先介绍SQLServer对象的命名规则(建议),再讨论物理模型的建立.命名原则(NamingGuidelines)√生成物理模型(DerivingthePhysicalModel)实现商业规则(ImplementingBusinessRulesinthePhysicalModel)第三页，共八十六页，2022年，8月28日NamingGuidelines在创建物理模型时,使用命名原则极度重要,可能存在数百种命名标准,使用哪一种无所谓,关键是要有.标准可以指示对象的类型.如果table均以tbl打头,而view用vw打头,那么用户一看名称就知道操纵的是表还是视图.这可以节约很多时间,特别是在查找表现不好的T-SQL代码时.评价标准:(1)是否易用易记;(2)别人能不能理解;(3)标准是否保持一致.即不能老是变来变去.第四页，共八十六页，2022年，8月28日GeneralNamingGuidelines本课程后边使用的标准.不在对象名中用空格(NeverUseSpacesinObjectNames)不在对象名中用连字符(-)(NeverUseHyphensinObjectNames)不得用SQLServer关键字来命名对象(DoNotNameObjectsUsingSQLServerKeywords)命名时尽量短一点(KeeptheNamesShort)合理使用大小写(UsingCaseinYourNames)SELECTwhere,and,name,dateFROMINSERTWHEREand=1ANDwhere='Omaha‘会报错,但若改为:SELECT[where],[and],name,dateFROM[INSERT]WHERE[and]=1AND[where]='Omaha‘这是正确的,但显然可读性很差第五页，共八十六页，2022年，8月28日NamingTables命名方法:”tbl_”后跟一个有意义的名字.MountainViewMusic数据库中的部分表:tbl_ordertbl_customertbl_producttbl_employee另外,对表达多对多联系的表,表示为:tbl_表1_表2,如:tbl_customer_address第六页，共八十六页，2022年，8月28日NamingColumns列名不要前缀,它是前缀规则中唯一的例外.第七页，共八十六页，2022年，8月28日NamingViews用”vw_”作为一个描述性名字的前缀.若视图数据来自于多个表,则把各表名用”_”分开,例如:vw_customer_product第八页，共八十六页，2022年，8月28日NamingStoredProcedures存储过程用前缀”prc_”,也可用其它前缀,但是最好别用”sp_”,因为它是Microsoft在SQLServer中用来为系统存储过程取名用的,免得造成混淆.第九页，共八十六页，2022年，8月28日NamingUser-DefinedFunctions用户定义函数用前缀”udf_”或其它.不要用”fn_”,因为系统用了.第十页，共八十六页，2022年，8月28日NamingTriggers用前缀”trg_”跟一描述性文字．第十一页，共八十六页，2022年，8月28日NamingIndexes以“idx_”为前缀．第十二页，共八十六页，2022年，8月28日NamingUser-DefinedDataTypes直接取一个描述性的名字，不用前缀第十三页，共八十六页，2022年，8月28日NamingPrimaryKeysandForeignKeys主码用前缀”PK_”后跟表名；外码前缀“FK_”+参照表名+”_”+被参照表名第十四页，共八十六页，2022年，8月28日NamingConstraints缺省值约束用前缀”DF_”,后跟表名和列名check约束用前缀”CK_”唯一性约束用前缀“UNQ_”第十五页，共八十六页，2022年，8月28日CreatingthePhysicalModel

withSQLServer是时候生成数据库了,本节先介绍SQLServer对象的命名规则(建议),再讨论物理模型的建立.命名原则(NamingGuidelines)生成物理模型(DerivingthePhysicalModel)√实现商业规则(ImplementingBusinessRulesinthePhysicalModel)第十六页，共八十六页，2022年，8月28日DerivingthePhysicalModel需要注意，表和实体未必是一对一的关系，因为实体是对现实世界建模，而表要附合关系数据库的理论．建立物理模型的过程是，先为每个实体建一张表，然后再分裂或者组合表．UsingEntitiestoModelTables√UsingRelationshipstoModelKeysUsingAttributestoModelColumns第十七页，共八十六页，2022年，8月28日UsingEntitiestoModelTables(1)可以依赖软件工具来把逻辑模式转换为物理模型。也可以手工直接到SQLServer中去做。这里用的方法是先把所有实体分成若干个子模型(submodel)，这样就不用一次面对所有的实体。为MountainViewMusic建立的子模型有：Products－包含所有关于产品和供应商的细节Inventory－包含公司物理库存的细节Orders－包含与订购、支付和客户相关的实体WebSession－包含实现web购物车相关的实体Lists－包含实现查找表的两个实体MVM的完整模型与子模型举例第十八页，共八十六页，2022年，8月28日UsingEntitiestoModelTables(2)在建立物理模型时,一次处理一个逻辑子模型.注意有的实体出现在多个子模型中,应把它放入真正所属的子模型中处理.下边,首先处理子模型中的实体并找出其中物理模型中的位置,稍后再处理联系.第十九页，共八十六页，2022年，8月28日ProductsSubmodel有六个实体需要处理本例属于比较简单的情况,每个实体对应到一张表,初建的物理模型如下图(一开始只有表名和主码)第二十页，共八十六页，2022年，8月28日ProductsSubmodel–initialphysicalmodel第二十一页，共八十六页，2022年，8月28日InventorySubmodel与Products子模型比较相似,也没有多少工作可做第二十二页，共八十六页，2022年，8月28日InventorySubmodel–initialphysicalmodel注意到Vendors和Products是第二次出现,对它们啥也不需要做第二十三页，共八十六页，2022年，8月28日OrdersSubmodel这是整个模型中最复杂的部分,包含12个实体.如图所示.其中,Products和Employees已经处理过了,Shipments,ShippingMethods,ShippingCarriers和OrderDetails可以直接转换为表.对于Customers,希望为每个客户存储多个地址,故需要把地址信息分离成单独的表,并与Customers建立联系.如图.Orders和Employees实体也有相似的地址问题,可以暂时为它们加上联系.最后,还要考察Payments实体的子类型结构.第二十四页，共八十六页，2022年，8月28日Payments实体的子类型结构(1)如前所述,实现子类型有三种方法:用一个表实现超类型和所有的子类型.为每个子类型建一张表,把超类型的数据加入到每个子类型表中.把超类型用一张表实现,各子类型用另外的表实现.(Implementthesupertypeasatableandallthesubtypesasadditionaltables.)这里选择第一种方法.如果选用第二/三种方法,联系将变得非常的复杂.由此得到Payments表结构如下:第二十五页，共八十六页，2022年，8月28日Payments实体的子类型结构(2)注意到这个表中的问题,不少属性是可选的(允许NULL值),如何保证三种支付方式一定存在一种呢?稍后讨论商业规则时再说.第二十六页，共八十六页，2022年，8月28日OrdersSubmodel–physicalmodel至此,也Order有关的所有表基本成形了,如下图所示.第二十七页，共八十六页，2022年，8月28日WebSessionandListsSubmodel最后是两个小的子模型,其中,websession只有一个新实体shoppingcart,它作为Customers和Products的连接,存储客户购买的产品,显然向表转换得加入CustomersID和ProductID.ListsSubmodel中是两个用于查找的表:Lists和ListItems,它们的作用是为前台应用提供一个场所存储相关的数据列表,如订单状态或各种产品属性.只需要直接转换.到此,所有的逻辑模型实体都找到了其物理模型中的归属,下边处理联系,即通过联系来找出码.第二十八页，共八十六页，2022年，8月28日DerivingthePhysicalModel需要注意，表和实体未必是一对一的关系，因为实体是对现实世界建模，而表要附合关系数据库的理论．建立物理模型的过程是，先为每个实体建一张表，然后再分裂或者组合表．UsingEntitiestoModelTablesUsingRelationshipstoModelKeys√UsingAttributestoModelColumns第二十九页，共八十六页，2022年，8月28日UsingRelationshipstoModelKeys已经看到，我们使用属性objid作为每个实体的主码名字。外码的名字使用被引用的表名跟上“_objid”。例：加上外码的orders子模型第三十页，共八十六页，2022年，8月28日DerivingthePhysicalModel需要注意，表和实体未必是一对一的关系，因为实体是对现实世界建模，而表要附合关系数据库的理论．建立物理模型的过程是，先为每个实体建一张表，然后再分裂或者组合表．UsingEntitiestoModelTablesUsingRelationshipstoModelKeysUsingAttributestoModelColumns√第三十一页，共八十六页，2022年，8月28日UsingAttributestoModelColumns使用实体的属性来对表属性建模。需要注意的是，由于存在实体的拆分和组合，属性也存在合并和分拆到相应表的问题。也需要注意数据类型，如果前边的工作完全按照本课程中的要求做了，那么属性建模非常简单，建模软件可以完成所有的事情-拷过去就行了。可以看出，买一个好的建模软件是非常重要的。这样，你要做的仅仅按照标准改名字。第三十二页，共八十六页，2022年，8月28日CreatingthePhysicalModel

withSQLServer是时候生成数据库了,本节先介绍SQLServer对象的命名规则(建议),再讨论物理模型的建立.命名原则(NamingGuidelines)生成物理模型(DerivingthePhysicalModel)实现商业规则(ImplementingBusinessRulesinthePhysicalModel)√第三十三页，共八十六页，2022年，8月28日在物理模型中实现商业规则在SQLServer中实现尽可能多的商业规则可能是一种比较好的方案。（因为我们不信任应用程序？）本节介绍利用SQLServer来实现商业规则的各种方案：UsingConstraintstoImplementBusinessRules√UsingTriggerstoImplementBusinessRulesImplementingAdvancedCardinality第三十四页，共八十六页，2022年，8月28日使用约束来实现商业规则约束是控制进入数据库的数据的机制，这里介绍三种约束：Default-为属性提供缺省值Unique–指定属性中的值保持唯一Check–根据要求自定义属性应满足的条件第三十五页，共八十六页，2022年，8月28日DefaultConstraints添加default约束的代码：ALTERTABLEdbo.tbl_employeeADDCONSTRAINTDF_statusDEFAULT1FORstatus使用自动义函数来产生缺省值：ALTERTABLEdbo.tbl_orderADDCONSTRAINT[DF_ordernumber]DEFAULTdbo.udf_new_orderid()FORordernumber 第三十六页，共八十六页，2022年，8月28日CheckConstraints用来保证装入数据库的数据确实是你所需要的。前边介绍的customers表中，homephone,workphone,mobilephone都是允许为空的，但我们要求至少提供一个电话号码，可以使用如下代码添加check约束：ALTERTABLEdbo.tbl_customerWITHCHECKADDCONSTRAINTCK_phone_numberCHECK(([homephone]ISNOTNULLOR[workphone]ISNOTNULLOR[mobilephone]ISNOTNULL))第三十七页，共八十六页，2022年，8月28日UniqueConstraints用来保证列没有重复值,可作用于一列或者多列.例：ALTERTABLEdbo.tbl_orderADDCONSTRAINTUNQ_ordernumberUNIQUENONCLUSTERED(ordernumber)所以在选择了主码之后,要评估所有的候选码,它们是实施唯一性约束的最好的对象.第三十八页，共八十六页，2022年，8月28日在物理模型中实现商业规则在SQLServer中实现尽可能多的商业规则可能是一种比较好的方案。（因为我们不信任应用程序？）本节介绍利用SQLServer来实现商业规则的各种方案：UsingConstraintstoImplementBusinessRulesUsingTriggerstoImplementBusinessRules√ImplementingAdvancedCardinality第三十九页，共八十六页，2022年，8月28日UsingTriggerstoImplementBusinessRulesUsingtriggers,youcanwritecustomT-SQLcodetorunaftersomethinghashappenedtoatable.TriggerscanbesetuptorunafteranINSERT,UPDATE,orDELETEoreveninsteadofoneoftheseactions.Keepinmind,however,thattriggersfireaspartofthetransactionthatstartedthem,andtheyfireeachtimetheactionoccurs.可能导致性能低下.第四十页，共八十六页，2022年，8月28日MVM中的触发器前文中用一个表来实现实体Payments，必须使用某种支付方式（支付方式不为空），当使用某种支付方式的时候，需要保证与该支付方式相对应的属性不得为空。例如，当选用信用卡支付时，相关的属性thecreditcardnumber,expirationdate,type,andcreditcardverification(CCV)code不能为空。可以用触发器来实现这样的要求。使用触发器来实现商业规则可以得到更健壮的系统，尽管这些规则可以用应用程序代码来实现。第四十一页，共八十六页，2022年，8月28日在物理模型中实现商业规则在SQLServer中实现尽可能多的商业规则可能是一种比较好的方案。（因为我们不信任应用程序？）本节介绍利用SQLServer来实现商业规则的各种方案：UsingConstraintstoImplementBusinessRulesUsingTriggerstoImplementBusinessRulesImplementingAdvancedCardinality√第四十二页，共八十六页，2022年，8月28日ImplementingAdvancedCardinality一到多的联系相对简单，前边已经讨论过，多到多的联系可以通过两个一到多的联系和一个联系表来实现。现在介绍一对一的联系以及“更高级的”如一对二的联系。例：一个学校有多个学院，若有规则一个学院只有一个院长，每个院长只能是一个学院的院长。可建立模型如下：显然这是一个一对多的联系，如何保证一对一的特性呢？即一个人只能是一个学院的院长可以使用触发器来实现：第四十三页，共八十六页，2022年，8月28日保证学院与院长一对一联系的触发器ALTERTRIGGERtrg_one_dean_per_collegeONtbl_collegeFORINSERT,UPDATEASDECLARE@college_countintSELECT@college_count=COUNT(tbl_college.id)FROMtbl_collegeJOINtbl_faculty ONtbl_college.dean_id=tbl_faculty.idWHEREtbl_faculty.id=(SELECTdean_idFROMINSERTED)IF@college_count>1BEGIN RAISERROR('Thisfacultymemberisdeanofanothercollege',11,1) ROLLBACKEND第四十四页，共八十六页，2022年，8月28日Pitfalls如果college表中数据很多，每次插入数据都要执行触发器代码，可能导致较差的性能。可以考虑使用insteadof触发器，在插入前评估本次插入。但每个表的每个动作只能定义一个insteadof触发器。一个构建良好的商业规则层，表现总是优于触发器。第四十五页，共八十六页，2022年，8月28日Contents在SQLServer中建立物理模型(CreatingthePhysicalModel

withSQLServer)索引方面的考虑(IndexingConsiderations)√建立抽象层(CreatinganAbstractionLayer

inSQLServer)第四十六页，共八十六页，2022年，8月28日IndexingConsiderations索引的作用是加快检索数据的速度。本节讨论什么是索引，如何确定要建立的索引，如何实现。IndexingOverview√DatabaseUsageRequirementsDeterminingtheAppropriateIndexesImplementingIndexesinSQLServer第四十七页，共八十六页，2022年，8月28日IndexingOverview讨论索引前，需要对SQLServer2008如何把数据存储到磁盘上有一个粗略的了解。数据库以文件的形式存储，每个数据库至少有两个文件(数据文件和日志文件各一)数据文件内部包含若干个extents(分区？)，每个extents包含8个pages(页面？)，每个pages占用8K空间,每个page通常有自己的标识符(identifier)，记录在页面上按插入数据库的顺序存储。第四十八页，共八十六页，2022年，8月28日WhatAreIndexes?Bydefault,whenyoucreateanewtableinaSQLServerdatabase,theserverassignsastartingnumberofextentstothattable.Whenyoustartinsertingdata,itaddsrowsofdatatothepagesinsidetheextents.Simplyput,anindexisareferencingsetofpointerstorowsofdata.Indexesphysicallyexistondisk,andthustheytakeupdiskspaceseparatelyfrom,andinadditionto,youractualtabledata.第四十九页，共八十六页，2022年，8月28日索引的类型Thetwobasicindextypesareclusteredandnonclusteredindexes.Allindexesthatyoudefineonyourtableswillbeoneofthesetwotypes.Clusteredindexesactuallyrestructurethedataondisk.Anonclusteredindexisonethatsimplystorespointerstothepagesthatcontaintherowsofdatayouarelookingfor.SQLServer2008还提供了其它类型的索引.第五十页，共八十六页，2022年，8月28日OtherIndexTypesUniqueindexesIndexeswithIncludedColumns:Considerusingthisfeaturewhenyou’rebuildingindexestosatisfyveryspecificqueriesandtheindexhasgottentoolarge.XMLIndexesSpatialFull-TextIndexesIndexedViews第五十一页，共八十六页，2022年，8月28日IndexingConsiderations索引的作用是加快检索数据的速度。本节讨论什么是索引，如何确定要建立的索引，如何实现。IndexingOverviewDatabaseUsageRequirements√DeterminingtheAppropriateIndexesImplementingIndexesinSQLServer第五十二页，共八十六页，2022年，8月28日DatabaseUsageRequirementsReadsversusWritesTransactionData第五十三页，共八十六页，2022年，8月28日IndexingConsiderations索引的作用是加快检索数据的速度。本节讨论什么是索引，如何确定要建立的索引，如何实现。IndexingOverviewDatabaseUsageRequirementsDeterminingtheAppropriateIndexes√ImplementingIndexesinSQLServer第五十四页，共八十六页，2022年，8月28日DeterminingtheAppropriateIndexesReviewingDataAccessPatternsBalancingIndexesCoveringIndexesIndexStatisticsIndexMaintenanceConsiderations第五十五页，共八十六页，2022年，8月28日IndexingConsiderations索引的作用是加快检索数据的速度。本节讨论什么是索引，如何确定要建立的索引，如何实现。IndexingOverviewDatabaseUsageRequirementsDeterminingtheAppropriateIndexesImplementingIndexesinSQLServer√第五十六页，共八十六页，2022年，8月28日ImplementingIndexesinSQLServerNamingGuidelinesidx_Customer_LastName_FirstNameCreatingIndexesCREATENONCLUSTEREDINDEXidx_Customer_LastName_FirstNameONCustomer(LastNameASC,FirstNameASC)WITH(FILLFACTOR=70,SORT_IN_TEMPDB=ON,ONLINE=ON)NIndexFileGroupFilegroups:Filegroupsareamethodofstoringdatabasedatafilesinaseparatedfashion.SettingUpIndexMaintenanceRebuildsversusReorganization第五十七页，共八十六页，2022年，8月28日Contents在SQLServer中建立物理模型(CreatingthePhysicalModel

withSQLServer)索引方面的考虑(IndexingConsiderations)建立抽象层(CreatinganAbstractionLayer

inSQLServer)√第五十八页，共八十六页，2022年，8月28日CreatinganAbstractionLayer

inSQLServer现在，可以把数据库交给数据库管理员进行实施和管理了。但是，大多数的应用程序员都未必知道怎样以最好的方式访问和使用数据库。因此，还应该做一项工作——建立抽象层。WhatIsanAbstractionLayer?WhyUseanAbstractionLayer?AnAbstractionLayer’sRelationshiptotheLogicalModelAnAbstractionLayer’sRelationshiptoObject-OrientedProgrammingImplementinganAbstractionLayer第五十九页，共八十六页，2022年，8月28日WhatIsanAbstractionLayer?Ingeneralterms,anabstractionlayerisawayofhidingthecomplexdetailsaboutthefunctionalityofaprocess.抽象层可以看成一个用户接口，这里的用户可能是一个程序。一般抽象层被实现为一个软件层供用户或其它程序访问。例如windows硬件抽象层(HAL)，OSI模型，开放图形库(OpenGL)等。在数据库中，抽象层的作用是隐藏模式的复杂性。在SQLServer中的抽象层由视图，存储过程，用户定义函数和几个其它的SQLServer对象组成。对于定义良好的抽象层，任何用户或程序不能直接访问物理表，任何事情都通过抽象层来处理。第六十页，共八十六页，2022年，8月28日WhyUseanAbstractionLayer?抽象层屏蔽了数据库结构的复杂性，至少有这几个好处：提供了一种管理安全性的方法，该方法不损害数据库的数据建立了可扩展的数据库提供了最大限度的灵活性。第六十一页，共八十六页，2022年，8月28日Security(1)建立抽象层为安全性控制提供了更多的选择。表中可能包含敏感数据，涉及用户隐私，还可能包含用户登录的口令。例如customer表。第六十二页，共八十六页，2022年，8月28日Security(2)可以创建视图屏蔽数据。CREATEVIEWvw_customer_detailASSELECTemail,customer_id,firstname,lastname,homephone,workphone,mobilephoneFROMtbl_customer第六十三页，共八十六页，2022年，8月28日Security(3)另外，数据库建好后，将来可能向其中添加隐私数据，例如身份证号码。使用抽象层，必须额外添加才能访问这些数据。（当然，前提是你在定义视图时没有使用“select*”这样的子句。）第六十四页，共八十六页，2022年，8月28日ExtensibilityandFlexibility(1)可扩展性指将来修改数据模型的方便程度。灵活性指在不造成重大影响的情况下可以修改模型多少内容。一般说来灵活的模型总是有好的可扩展性，但也并不总是如此。抽象层把应用程序与物理数据隔离开来，它几乎允许你在不影响应用程序的情况下做任何事。只要所有的应用和用户都通过视图来读数据，通过存储过程来操纵数据，当修改发生时，只需要对视图和存储过程作出相应的调整。第六十五页，共八十六页，2022年，8月28日ExtensibilityandFlexibility(2)修改SQLServer代码与修改应用程序代码有什么区别？SQL代码不用编译，意思是你可以随时修改，而不用等到夜深人静的时候。只有一个数据库，而应用程序被修改后要重新编译和部署。第六十六页，共八十六页，2022年，8月28日AnAbstractionLayer’sRelationshiptotheLogicalModelWhenit’stimetobuildyourabstractionlayer,youshouldfindthatitmorecloselytiestothelogicalmodelthantothephysicalmodel.要记住逻辑模型比物理模型更加“用户友好”。不要为一个表创建四个存储过程分别用于插入、删除、更新和查询。而是应该创建一个过程来存储实体，创建一个过程来插入和更新。第六十七页，共八十六页，2022年，8月28日AnAbstractionLayer’sRelationshiptoObject-OrientedProgrammingOOP的核心概念是对象,而抽象层与逻辑模型紧紧地联系在一起,其中心是实体.实体与对象很接近,表现在实体的属性与对象的属性几乎是一一对应的,但对象有方法(methods),实体没有,反映到抽象层,可以用存储过程,当对象要操纵其数据,例如order对象要存储订单,可以调用一个存储过程向数据库插入.若你的数据库与一个应用开发项目紧密地结合在一起,建议使用对象模型来指导抽象层的建立.第六十八页，共八十六页，2022年，8月28日ImplementinganAbstractionLayer实现抽象层指在数据库中创建对象(包括视图,存储过程和函数)来作为应用程序代码与核心数据库对象的中介.ViewsStoredProceduresOtherComponentsofanAbstractionLayer第六十九页，共八十六页，2022年，8月28日Views使用视图的目的是想基于用户的需求以一种有意义的方式把实体展示给最终用户.创建视图时一定要清楚用户能不能真正理解展示在其面前的数据.创建视图来使应用程序逻辑更简捷是一个好主意.避免使用”select*”语法和不带值列表的insert语句.查看客户(customer)数据的视图第七十页，共八十六页，2022年，8月28日视图的例子(1)CREATEVIEWvw_customersASSELECT objid ,email ,customer_id ,firstname ,lastname ,homephone ,workphone ,mobilephoneFROMtbl_customer第七十一页，共八十六页，2022年，8月28日视图的例子(2)CREATEVIEWvw_customer_addressesASSELECT address_objid=objid ,address_label ,addressline1 ,addressline2 ,city ,region ,zipcode ,customer_objidFROMtbl_addressWHEREcustomer_objidISNOTNULL第七十二页，共八十六页，2022年，8月28日StoredProcedures（1）存储过程有着与视图类似的规则。创建存储过程的时候，考虑一下它们试图影响的实体。可以考虑创建一个标准来控制怎样和为何创建存储过程。正确实施存储过程与环境和自身选择有关，没有绝对正确的答案。常见的做法是为每个实体创建一个存储过程，它向所有相关的表更新或插入数据。第七十三页，共八十六页，2022年，8月28日StoredProcedures（2）例：为MVM中的Customer实体存储变更的步骤确定记录是否已经存在、若不存在，则插入若存在，则更新返回插入或更新的信息相应的存储过程如下：ALTERPROCEDUREprc_save_customer@emailvarchar(50),@customer_idchar(10),@firstnamevarchar(50),@lastnamevarchar(50)第七十四页，共八十六页，2022年，8月28日StoredProcedures（3）,@homephonevarchar(15),@workphonevarchar(15),@mobilephonevarchar(15),@addressesCustomerAddressReadOnly,@customer_objidintOUTPUTASMERGEtbl_customerASpri_customer USING ( SELECTcustomer_id=@customer_id ) ASsource_customer(customer_id)第七十五页，共八十六页，2022年，8月28日ON ( pri_customer.customer_id= source_customer.customer_id )WHENNOTMATCHEDTHENINSERT(email, customer_id, firstname, lastname, homephone, workphone, mobilephone)第七十六页，共八十六页，2022年，8月28日VALUES(@email, @customer_id, @firstname, @lastname, @homephone, @workphone, @mobilephone)WHENMATCHEDTHEN UPDATE SETemail=@email, firstname=@firstname, lastname=@lastname, homephone=@homephone, workphone=@workphone, mobilephone=@mobilephone;第七十七页，共八十六页，2022年，8月28日SELECT@customer_objid=objidFROMtbl_customerWHEREcustomer_id=@customer_id;MERGEtbl_addressAScurrent_addresses USING ( SELECTcustomer_objid=@customer_objid, address_label, addressline1, addressline2, city, region, country, zipcode, is_deleted FROM@addresses )第七十八页，共八十六页，2022年，8月28日

ASsource_addresses(customer_objid, address_label, addressline1, addressline2, city, region, country, zipcode, is_deleted) ON ( current_addresses.address_label= source_addresses.address_label AND current_addresses.customer_objid= source_addresses.customer_objid)第七十九页，共八十六页，2022年，8月28日WHENNOTMATCHEDTHEN INSERT(address_label, addressline1, addressline2, city, reg