建立物理模型

建立物理模型第一頁，共八十六頁，編輯于2023年，星期日Contents在SQLServer中建立物理模型(CreatingthePhysicalModel

withSQLServer)

√索引方面的考慮(IndexingConsiderations)建立抽象層(CreatinganAbstractionLayer

inSQLServer)第二頁，共八十六頁，編輯于2023年，星期日CreatingthePhysicalModel

withSQLServer是時(shí)候生成數(shù)據(jù)庫了,本節(jié)先介紹SQLServer對象的命名規(guī)則(建議),再討論物理模型的建立.命名原則(NamingGuidelines)√生成物理模型(DerivingthePhysicalModel)實(shí)現(xiàn)商業(yè)規(guī)則(ImplementingBusinessRulesinthePhysicalModel)第三頁，共八十六頁，編輯于2023年，星期日NamingGuidelines在創(chuàng)建物理模型時(shí),使用命名原則極度重要,可能存在數(shù)百種命名標(biāo)準(zhǔn),使用哪一種無所謂,關(guān)鍵是要有.標(biāo)準(zhǔn)可以指示對象的類型.如果table均以tbl打頭,而view用vw打頭,那么用戶一看名稱就知道操縱的是表還是視圖.這可以節(jié)約很多時(shí)間,特別是在查找表現(xiàn)不好的T-SQL代碼時(shí).評價(jià)標(biāo)準(zhǔn):(1)是否易用易記;(2)別人能不能理解;(3)標(biāo)準(zhǔn)是否保持一致.即不能老是變來變?nèi)?第四頁，共八十六頁，編輯于2023年，星期日GeneralNamingGuidelines本課程后邊使用的標(biāo)準(zhǔn).不在對象名中用空格(NeverUseSpacesinObjectNames)不在對象名中用連字符(-)(NeverUseHyphensinObjectNames)不得用SQLServer關(guān)鍵字來命名對象(DoNotNameObjectsUsingSQLServerKeywords)命名時(shí)盡量短一點(diǎn)(KeeptheNamesShort)合理使用大小寫(UsingCaseinYourNames)SELECTwhere,and,name,dateFROMINSERTWHEREand=1ANDwhere='Omaha‘會(huì)報(bào)錯(cuò),但若改為:SELECT[where],[and],name,dateFROM[INSERT]WHERE[and]=1AND[where]='Omaha‘這是正確的,但顯然可讀性很差第五頁，共八十六頁，編輯于2023年，星期日NamingTables命名方法:”tbl_”后跟一個(gè)有意義的名字.MountainViewMusic數(shù)據(jù)庫中的部分表:tbl_ordertbl_customertbl_producttbl_employee另外,對表達(dá)多對多聯(lián)系的表,表示為:tbl_表1_表2,如:tbl_customer_address第六頁，共八十六頁，編輯于2023年，星期日NamingColumns列名不要前綴,它是前綴規(guī)則中唯一的例外.第七頁，共八十六頁，編輯于2023年，星期日NamingViews用”vw_”作為一個(gè)描述性名字的前綴.若視圖數(shù)據(jù)來自于多個(gè)表,則把各表名用”_”分開,例如:vw_customer_product第八頁，共八十六頁，編輯于2023年，星期日NamingStoredProcedures存儲(chǔ)過程用前綴”prc_”,也可用其它前綴,但是最好別用”sp_”,因?yàn)樗荕icrosoft在SQLServer中用來為系統(tǒng)存儲(chǔ)過程取名用的,免得造成混淆.第九頁，共八十六頁，編輯于2023年，星期日NamingUser-DefinedFunctions用戶定義函數(shù)用前綴”udf_”或其它.不要用”fn_”,因?yàn)橄到y(tǒng)用了.第十頁，共八十六頁，編輯于2023年，星期日NamingTriggers用前綴”trg_”跟一描述性文字．第十一頁，共八十六頁，編輯于2023年，星期日NamingIndexes以“idx_”為前綴．第十二頁，共八十六頁，編輯于2023年，星期日NamingUser-DefinedDataTypes直接取一個(gè)描述性的名字，不用前綴第十三頁，共八十六頁，編輯于2023年，星期日NamingPrimaryKeysandForeignKeys主碼用前綴”PK_”后跟表名；外碼前綴“FK_”+參照表名+”_”+被參照表名第十四頁，共八十六頁，編輯于2023年，星期日NamingConstraints缺省值約束用前綴”DF_”,后跟表名和列名check約束用前綴”CK_”唯一性約束用前綴“UNQ_”第十五頁，共八十六頁，編輯于2023年，星期日CreatingthePhysicalModel

withSQLServer是時(shí)候生成數(shù)據(jù)庫了,本節(jié)先介紹SQLServer對象的命名規(guī)則(建議),再討論物理模型的建立.命名原則(NamingGuidelines)生成物理模型(DerivingthePhysicalModel)√實(shí)現(xiàn)商業(yè)規(guī)則(ImplementingBusinessRulesinthePhysicalModel)第十六頁，共八十六頁，編輯于2023年，星期日DerivingthePhysicalModel需要注意，表和實(shí)體未必是一對一的關(guān)系，因?yàn)閷?shí)體是對現(xiàn)實(shí)世界建模，而表要附合關(guān)系數(shù)據(jù)庫的理論．建立物理模型的過程是，先為每個(gè)實(shí)體建一張表，然后再分裂或者組合表．UsingEntitiestoModelTables√UsingRelationshipstoModelKeysUsingAttributestoModelColumns第十七頁，共八十六頁，編輯于2023年，星期日UsingEntitiestoModelTables(1)可以依賴軟件工具來把邏輯模式轉(zhuǎn)換為物理模型。也可以手工直接到SQLServer中去做。這里用的方法是先把所有實(shí)體分成若干個(gè)子模型(submodel)，這樣就不用一次面對所有的實(shí)體。為MountainViewMusic建立的子模型有：Products－包含所有關(guān)于產(chǎn)品和供應(yīng)商的細(xì)節(jié)Inventory－包含公司物理庫存的細(xì)節(jié)Orders－包含與訂購、支付和客戶相關(guān)的實(shí)體WebSession－包含實(shí)現(xiàn)web購物車相關(guān)的實(shí)體Lists－包含實(shí)現(xiàn)查找表的兩個(gè)實(shí)體MVM的完整模型與子模型舉例第十八頁，共八十六頁，編輯于2023年，星期日UsingEntitiestoModelTables(2)在建立物理模型時(shí),一次處理一個(gè)邏輯子模型.注意有的實(shí)體出現(xiàn)在多個(gè)子模型中,應(yīng)把它放入真正所屬的子模型中處理.下邊,首先處理子模型中的實(shí)體并找出其中物理模型中的位置,稍后再處理聯(lián)系.第十九頁，共八十六頁，編輯于2023年，星期日ProductsSubmodel有六個(gè)實(shí)體需要處理本例屬于比較簡單的情況,每個(gè)實(shí)體對應(yīng)到一張表,初建的物理模型如下圖(一開始只有表名和主碼)第二十頁，共八十六頁，編輯于2023年，星期日ProductsSubmodel–initialphysicalmodel第二十一頁，共八十六頁，編輯于2023年，星期日InventorySubmodel與Products子模型比較相似,也沒有多少工作可做第二十二頁，共八十六頁，編輯于2023年，星期日InventorySubmodel–initialphysicalmodel注意到Vendors和Products是第二次出現(xiàn),對它們啥也不需要做第二十三頁，共八十六頁，編輯于2023年，星期日OrdersSubmodel這是整個(gè)模型中最復(fù)雜的部分,包含12個(gè)實(shí)體.如圖所示.其中,Products和Employees已經(jīng)處理過了,Shipments,ShippingMethods,ShippingCarriers和OrderDetails可以直接轉(zhuǎn)換為表.對于Customers,希望為每個(gè)客戶存儲(chǔ)多個(gè)地址,故需要把地址信息分離成單獨(dú)的表,并與Customers建立聯(lián)系.如圖.Orders和Employees實(shí)體也有相似的地址問題,可以暫時(shí)為它們加上聯(lián)系.最后,還要考察Payments實(shí)體的子類型結(jié)構(gòu).第二十四頁，共八十六頁，編輯于2023年，星期日Payments實(shí)體的子類型結(jié)構(gòu)(1)如前所述,實(shí)現(xiàn)子類型有三種方法:用一個(gè)表實(shí)現(xiàn)超類型和所有的子類型.為每個(gè)子類型建一張表,把超類型的數(shù)據(jù)加入到每個(gè)子類型表中.把超類型用一張表實(shí)現(xiàn),各子類型用另外的表實(shí)現(xiàn).(Implementthesupertypeasatableandallthesubtypesasadditionaltables.)這里選擇第一種方法.如果選用第二/三種方法,聯(lián)系將變得非常的復(fù)雜.由此得到Payments表結(jié)構(gòu)如下:第二十五頁，共八十六頁，編輯于2023年，星期日Payments實(shí)體的子類型結(jié)構(gòu)(2)注意到這個(gè)表中的問題,不少屬性是可選的(允許NULL值),如何保證三種支付方式一定存在一種呢?稍后討論商業(yè)規(guī)則時(shí)再說.第二十六頁，共八十六頁，編輯于2023年，星期日OrdersSubmodel–physicalmodel至此,也Order有關(guān)的所有表基本成形了,如下圖所示.第二十七頁，共八十六頁，編輯于2023年，星期日WebSessionandListsSubmodel最后是兩個(gè)小的子模型,其中,websession只有一個(gè)新實(shí)體shoppingcart,它作為Customers和Products的連接,存儲(chǔ)客戶購買的產(chǎn)品,顯然向表轉(zhuǎn)換得加入CustomersID和ProductID.ListsSubmodel中是兩個(gè)用于查找的表:Lists和ListItems,它們的作用是為前臺(tái)應(yīng)用提供一個(gè)場所存儲(chǔ)相關(guān)的數(shù)據(jù)列表,如訂單狀態(tài)或各種產(chǎn)品屬性.只需要直接轉(zhuǎn)換.到此,所有的邏輯模型實(shí)體都找到了其物理模型中的歸屬,下邊處理聯(lián)系,即通過聯(lián)系來找出碼.第二十八頁，共八十六頁，編輯于2023年，星期日DerivingthePhysicalModel需要注意，表和實(shí)體未必是一對一的關(guān)系，因?yàn)閷?shí)體是對現(xiàn)實(shí)世界建模，而表要附合關(guān)系數(shù)據(jù)庫的理論．建立物理模型的過程是，先為每個(gè)實(shí)體建一張表，然后再分裂或者組合表．UsingEntitiestoModelTablesUsingRelationshipstoModelKeys√UsingAttributestoModelColumns第二十九頁，共八十六頁，編輯于2023年，星期日UsingRelationshipstoModelKeys已經(jīng)看到，我們使用屬性objid作為每個(gè)實(shí)體的主碼名字。外碼的名字使用被引用的表名跟上“_objid”。例：加上外碼的orders子模型第三十頁，共八十六頁，編輯于2023年，星期日DerivingthePhysicalModel需要注意，表和實(shí)體未必是一對一的關(guān)系，因?yàn)閷?shí)體是對現(xiàn)實(shí)世界建模，而表要附合關(guān)系數(shù)據(jù)庫的理論．建立物理模型的過程是，先為每個(gè)實(shí)體建一張表，然后再分裂或者組合表．UsingEntitiestoModelTablesUsingRelationshipstoModelKeysUsingAttributestoModelColumns√第三十一頁，共八十六頁，編輯于2023年，星期日UsingAttributestoModelColumns使用實(shí)體的屬性來對表屬性建模。需要注意的是，由于存在實(shí)體的拆分和組合，屬性也存在合并和分拆到相應(yīng)表的問題。也需要注意數(shù)據(jù)類型，如果前邊的工作完全按照本課程中的要求做了，那么屬性建模非常簡單，建模軟件可以完成所有的事情-拷過去就行了。可以看出，買一個(gè)好的建模軟件是非常重要的。這樣，你要做的僅僅按照標(biāo)準(zhǔn)改名字。第三十二頁，共八十六頁，編輯于2023年，星期日CreatingthePhysicalModel

withSQLServer是時(shí)候生成數(shù)據(jù)庫了,本節(jié)先介紹SQLServer對象的命名規(guī)則(建議),再討論物理模型的建立.命名原則(NamingGuidelines)生成物理模型(DerivingthePhysicalModel)實(shí)現(xiàn)商業(yè)規(guī)則(ImplementingBusinessRulesinthePhysicalModel)√第三十三頁，共八十六頁，編輯于2023年，星期日在物理模型中實(shí)現(xiàn)商業(yè)規(guī)則在SQLServer中實(shí)現(xiàn)盡可能多的商業(yè)規(guī)則可能是一種比較好的方案。（因?yàn)槲覀儾恍湃螒?yīng)用程序？）本節(jié)介紹利用SQLServer來實(shí)現(xiàn)商業(yè)規(guī)則的各種方案：UsingConstraintstoImplementBusinessRules√UsingTriggerstoImplementBusinessRulesImplementingAdvancedCardinality第三十四頁，共八十六頁，編輯于2023年，星期日使用約束來實(shí)現(xiàn)商業(yè)規(guī)則約束是控制進(jìn)入數(shù)據(jù)庫的數(shù)據(jù)的機(jī)制，這里介紹三種約束：Default-為屬性提供缺省值Unique–指定屬性中的值保持唯一Check–根據(jù)要求自定義屬性應(yīng)滿足的條件第三十五頁，共八十六頁，編輯于2023年，星期日DefaultConstraints添加default約束的代碼：ALTERTABLEdbo.tbl_employeeADDCONSTRAINTDF_statusDEFAULT1FORstatus使用自動(dòng)義函數(shù)來產(chǎn)生缺省值：ALTERTABLEdbo.tbl_orderADDCONSTRAINT[DF_ordernumber]DEFAULTdbo.udf_new_orderid()FORordernumber 第三十六頁，共八十六頁，編輯于2023年，星期日CheckConstraints用來保證裝入數(shù)據(jù)庫的數(shù)據(jù)確實(shí)是你所需要的。前邊介紹的customers表中，homephone,workphone,mobilephone都是允許為空的，但我們要求至少提供一個(gè)電話號(hào)碼，可以使用如下代碼添加check約束：ALTERTABLEdbo.tbl_customerWITHCHECKADDCONSTRAINTCK_phone_numberCHECK(([homephone]ISNOTNULLOR[workphone]ISNOTNULLOR[mobilephone]ISNOTNULL))第三十七頁，共八十六頁，編輯于2023年，星期日UniqueConstraints用來保證列沒有重復(fù)值,可作用于一列或者多列.例：ALTERTABLEdbo.tbl_orderADDCONSTRAINTUNQ_ordernumberUNIQUENONCLUSTERED(ordernumber)所以在選擇了主碼之后,要評估所有的候選碼,它們是實(shí)施唯一性約束的最好的對象.第三十八頁，共八十六頁，編輯于2023年，星期日在物理模型中實(shí)現(xiàn)商業(yè)規(guī)則在SQLServer中實(shí)現(xiàn)盡可能多的商業(yè)規(guī)則可能是一種比較好的方案。（因?yàn)槲覀儾恍湃螒?yīng)用程序？）本節(jié)介紹利用SQLServer來實(shí)現(xiàn)商業(yè)規(guī)則的各種方案：UsingConstraintstoImplementBusinessRulesUsingTriggerstoImplementBusinessRules√ImplementingAdvancedCardinality第三十九頁，共八十六頁，編輯于2023年，星期日UsingTriggerstoImplementBusinessRulesUsingtriggers,youcanwritecustomT-SQLcodetorunaftersomethinghashappenedtoatable.TriggerscanbesetuptorunafteranINSERT,UPDATE,orDELETEoreveninsteadofoneoftheseactions.Keepinmind,however,thattriggersfireaspartofthetransactionthatstartedthem,andtheyfireeachtimetheactionoccurs.可能導(dǎo)致性能低下.第四十頁，共八十六頁，編輯于2023年，星期日MVM中的觸發(fā)器前文中用一個(gè)表來實(shí)現(xiàn)實(shí)體Payments，必須使用某種支付方式（支付方式不為空），當(dāng)使用某種支付方式的時(shí)候，需要保證與該支付方式相對應(yīng)的屬性不得為空。例如，當(dāng)選用信用卡支付時(shí)，相關(guān)的屬性thecreditcardnumber,expirationdate,type,andcreditcardverification(CCV)code不能為空。可以用觸發(fā)器來實(shí)現(xiàn)這樣的要求。使用觸發(fā)器來實(shí)現(xiàn)商業(yè)規(guī)則可以得到更健壯的系統(tǒng)，盡管這些規(guī)則可以用應(yīng)用程序代碼來實(shí)現(xiàn)。第四十一頁，共八十六頁，編輯于2023年，星期日在物理模型中實(shí)現(xiàn)商業(yè)規(guī)則在SQLServer中實(shí)現(xiàn)盡可能多的商業(yè)規(guī)則可能是一種比較好的方案。（因?yàn)槲覀儾恍湃螒?yīng)用程序？）本節(jié)介紹利用SQLServer來實(shí)現(xiàn)商業(yè)規(guī)則的各種方案：UsingConstraintstoImplementBusinessRulesUsingTriggerstoImplementBusinessRulesImplementingAdvancedCardinality√第四十二頁，共八十六頁，編輯于2023年，星期日ImplementingAdvancedCardinality一到多的聯(lián)系相對簡單，前邊已經(jīng)討論過，多到多的聯(lián)系可以通過兩個(gè)一到多的聯(lián)系和一個(gè)聯(lián)系表來實(shí)現(xiàn)?，F(xiàn)在介紹一對一的聯(lián)系以及“更高級的”如一對二的聯(lián)系。例：一個(gè)學(xué)校有多個(gè)學(xué)院，若有規(guī)則一個(gè)學(xué)院只有一個(gè)院長，每個(gè)院長只能是一個(gè)學(xué)院的院長。可建立模型如下：顯然這是一個(gè)一對多的聯(lián)系，如何保證一對一的特性呢？即一個(gè)人只能是一個(gè)學(xué)院的院長可以使用觸發(fā)器來實(shí)現(xiàn)：第四十三頁，共八十六頁，編輯于2023年，星期日保證學(xué)院與院長一對一聯(lián)系的觸發(fā)器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第四十四頁，共八十六頁，編輯于2023年，星期日Pitfalls如果college表中數(shù)據(jù)很多，每次插入數(shù)據(jù)都要執(zhí)行觸發(fā)器代碼，可能導(dǎo)致較差的性能。可以考慮使用insteadof觸發(fā)器，在插入前評估本次插入。但每個(gè)表的每個(gè)動(dòng)作只能定義一個(gè)insteadof觸發(fā)器。一個(gè)構(gòu)建良好的商業(yè)規(guī)則層，表現(xiàn)總是優(yōu)于觸發(fā)器。第四十五頁，共八十六頁，編輯于2023年，星期日Contents在SQLServer中建立物理模型(CreatingthePhysicalModel

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

inSQLServer)第四十六頁，共八十六頁，編輯于2023年，星期日IndexingConsiderations索引的作用是加快檢索數(shù)據(jù)的速度。本節(jié)討論什么是索引，如何確定要建立的索引，如何實(shí)現(xiàn)。IndexingOverview√DatabaseUsageRequirementsDeterminingtheAppropriateIndexesImplementingIndexesinSQLServer第四十七頁，共八十六頁，編輯于2023年，星期日IndexingOverview討論索引前，需要對SQLServer2008如何把數(shù)據(jù)存儲(chǔ)到磁盤上有一個(gè)粗略的了解。數(shù)據(jù)庫以文件的形式存儲(chǔ)，每個(gè)數(shù)據(jù)庫至少有兩個(gè)文件(數(shù)據(jù)文件和日志文件各一)數(shù)據(jù)文件內(nèi)部包含若干個(gè)extents(分區(qū)？)，每個(gè)extents包含8個(gè)pages(頁面？)，每個(gè)pages占用8K空間,每個(gè)page通常有自己的標(biāo)識(shí)符(identifier)，記錄在頁面上按插入數(shù)據(jù)庫的順序存儲(chǔ)。第四十八頁，共八十六頁，編輯于2023年，星期日WhatAreIndexes?Bydefault,whenyoucreateanewtableinaSQLServerdatabase,theserverassignsastartingnumberofextentstothattable.Whenyoustartinsertingdata,itaddsrowsofdatatothepagesinsidetheextents.Simplyput,anindexisareferencingsetofpointerstorowsofdata.Indexesphysicallyexistondisk,andthustheytakeupdiskspaceseparatelyfrom,andinadditionto,youractualtabledata.第四十九頁，共八十六頁，編輯于2023年，星期日索引的類型Thetwobasicindextypesareclusteredandnonclusteredindexes.Allindexesthatyoudefineonyourtableswillbeoneofthesetwotypes.Clusteredindexesactuallyrestructurethedataondisk.Anonclusteredindexisonethatsimplystorespointerstothepagesthatcontaintherowsofdatayouarelookingfor.SQLServer2008還提供了其它類型的索引.第五十頁，共八十六頁，編輯于2023年，星期日OtherIndexTypesUniqueindexesIndexeswithIncludedColumns:Considerusingthisfeaturewhenyou’rebuildingindexestosatisfyveryspecificqueriesandtheindexhasgottentoolarge.XMLIndexesSpatialFull-TextIndexesIndexedViews第五十一頁，共八十六頁，編輯于2023年，星期日IndexingConsiderations索引的作用是加快檢索數(shù)據(jù)的速度。本節(jié)討論什么是索引，如何確定要建立的索引，如何實(shí)現(xiàn)。IndexingOverviewDatabaseUsageRequirements√DeterminingtheAppropriateIndexesImplementingIndexesinSQLServer第五十二頁，共八十六頁，編輯于2023年，星期日DatabaseUsageRequirementsReadsversusWritesTransactionData第五十三頁，共八十六頁，編輯于2023年，星期日IndexingConsiderations索引的作用是加快檢索數(shù)據(jù)的速度。本節(jié)討論什么是索引，如何確定要建立的索引，如何實(shí)現(xiàn)。IndexingOverviewDatabaseUsageRequirementsDeterminingtheAppropriateIndexes√ImplementingIndexesinSQLServer第五十四頁，共八十六頁，編輯于2023年，星期日DeterminingtheAppropriateIndexesReviewingDataAccessPatternsBalancingIndexesCoveringIndexesIndexStatisticsIndexMaintenanceConsiderations第五十五頁，共八十六頁，編輯于2023年，星期日IndexingConsiderations索引的作用是加快檢索數(shù)據(jù)的速度。本節(jié)討論什么是索引，如何確定要建立的索引，如何實(shí)現(xiàn)。IndexingOverviewDatabaseUsageRequirementsDeterminingtheAppropriateIndexesImplementingIndexesinSQLServer√第五十六頁，共八十六頁，編輯于2023年，星期日ImplementingIndexesinSQLServerNamingGuidelinesidx_Customer_LastName_FirstNameCreatingIndexesCREATENONCLUSTEREDINDEXidx_Customer_LastName_FirstNameONCustomer(LastNameASC,FirstNameASC)WITH(FILLFACTOR=70,SORT_IN_TEMPDB=ON,ONLINE=ON)NIndexFileGroupFilegroups:Filegroupsareamethodofstoringdatabasedatafilesinaseparatedfashion.SettingUpIndexMaintenanceRebuildsversusReorganization第五十七頁，共八十六頁，編輯于2023年，星期日Contents在SQLServer中建立物理模型(CreatingthePhysicalModel

withSQLServer)索引方面的考慮(IndexingConsiderations)建立抽象層(CreatinganAbstractionLayer

inSQLServer)√第五十八頁，共八十六頁，編輯于2023年，星期日CreatinganAbstractionLayer

inSQLServer現(xiàn)在，可以把數(shù)據(jù)庫交給數(shù)據(jù)庫管理員進(jìn)行實(shí)施和管理了。但是，大多數(shù)的應(yīng)用程序員都未必知道怎樣以最好的方式訪問和使用數(shù)據(jù)庫。因此，還應(yīng)該做一項(xiàng)工作——建立抽象層。WhatIsanAbstractionLayer?WhyUseanAbstractionLayer?AnAbstractionLayer’sRelationshiptotheLogicalModelAnAbstractionLayer’sRelationshiptoObject-OrientedProgrammingImplementinganAbstractionLayer第五十九頁，共八十六頁，編輯于2023年，星期日WhatIsanAbstractionLayer?Ingeneralterms,anabstractionlayerisawayofhidingthecomplexdetailsaboutthefunctionalityofaprocess.抽象層可以看成一個(gè)用戶接口，這里的用戶可能是一個(gè)程序。一般抽象層被實(shí)現(xiàn)為一個(gè)軟件層供用戶或其它程序訪問。例如windows硬件抽象層(HAL)，OSI模型，開放圖形庫(OpenGL)等。在數(shù)據(jù)庫中，抽象層的作用是隱藏模式的復(fù)雜性。在SQLServer中的抽象層由視圖，存儲(chǔ)過程，用戶定義函數(shù)和幾個(gè)其它的SQLServer對象組成。對于定義良好的抽象層，任何用戶或程序不能直接訪問物理表，任何事情都通過抽象層來處理。第六十頁，共八十六頁，編輯于2023年，星期日WhyUseanAbstractionLayer?抽象層屏蔽了數(shù)據(jù)庫結(jié)構(gòu)的復(fù)雜性，至少有這幾個(gè)好處：提供了一種管理安全性的方法，該方法不損害數(shù)據(jù)庫的數(shù)據(jù)建立了可擴(kuò)展的數(shù)據(jù)庫提供了最大限度的靈活性。第六十一頁，共八十六頁，編輯于2023年，星期日Security(1)建立抽象層為安全性控制提供了更多的選擇。表中可能包含敏感數(shù)據(jù)，涉及用戶隱私，還可能包含用戶登錄的口令。例如customer表。第六十二頁，共八十六頁，編輯于2023年，星期日Security(2)可以創(chuàng)建視圖屏蔽數(shù)據(jù)。CREATEVIEWvw_customer_detailASSELECTemail,customer_id,firstname,lastname,homephone,workphone,mobilephoneFROMtbl_customer第六十三頁，共八十六頁，編輯于2023年，星期日Security(3)另外，數(shù)據(jù)庫建好后，將來可能向其中添加隱私數(shù)據(jù)，例如身份證號(hào)碼。使用抽象層，必須額外添加才能訪問這些數(shù)據(jù)。（當(dāng)然，前提是你在定義視圖時(shí)沒有使用“select*”這樣的子句。）第六十四頁，共八十六頁，編輯于2023年，星期日ExtensibilityandFlexibility(1)可擴(kuò)展性指將來修改數(shù)據(jù)模型的方便程度。靈活性指在不造成重大影響的情況下可以修改模型多少內(nèi)容。一般說來靈活的模型總是有好的可擴(kuò)展性，但也并不總是如此。抽象層把應(yīng)用程序與物理數(shù)據(jù)隔離開來，它幾乎允許你在不影響應(yīng)用程序的情況下做任何事。只要所有的應(yīng)用和用戶都通過視圖來讀數(shù)據(jù)，通過存儲(chǔ)過程來操縱數(shù)據(jù)，當(dāng)修改發(fā)生時(shí)，只需要對視圖和存儲(chǔ)過程作出相應(yīng)的調(diào)整。第六十五頁，共八十六頁，編輯于2023年，星期日ExtensibilityandFlexibility(2)修改SQLServer代碼與修改應(yīng)用程序代碼有什么區(qū)別？SQL代碼不用編譯，意思是你可以隨時(shí)修改，而不用等到夜深人靜的時(shí)候。只有一個(gè)數(shù)據(jù)庫，而應(yīng)用程序被修改后要重新編譯和部署。第六十六頁，共八十六頁，編輯于2023年，星期日AnAbstractionLayer’sRelationshiptotheLogicalModelWhenit’stimetobuildyourabstractionlayer,youshouldfindthatitmorecloselytiestothelogicalmodelthantothephysicalmodel.要記住邏輯模型比物理模型更加“用戶友好”。不要為一個(gè)表創(chuàng)建四個(gè)存儲(chǔ)過程分別用于插入、刪除、更新和查詢。而是應(yīng)該創(chuàng)建一個(gè)過程來存儲(chǔ)實(shí)體，創(chuàng)建一個(gè)過程來插入和更新。第六十七頁，共八十六頁，編輯于2023年，星期日AnAbstractionLayer’sRelationshiptoObject-OrientedProgrammingOOP的核心概念是對象,而抽象層與邏輯模型緊緊地聯(lián)系在一起,其中心是實(shí)體.實(shí)體與對象很接近,表現(xiàn)在實(shí)體的屬性與對象的屬性幾乎是一一對應(yīng)的,但對象有方法(methods),實(shí)體沒有,反映到抽象層,可以用存儲(chǔ)過程,當(dāng)對象要操縱其數(shù)據(jù),例如order對象要存儲(chǔ)訂單,可以調(diào)用一個(gè)存儲(chǔ)過程向數(shù)據(jù)庫插入.若你的數(shù)據(jù)庫與一個(gè)應(yīng)用開發(fā)項(xiàng)目緊密地結(jié)合在一起,建議使用對象模型來指導(dǎo)抽象層的建立.第六十八頁，共八十六頁，編輯于2023年，星期日ImplementinganAbstractionLayer實(shí)現(xiàn)抽象層指在數(shù)據(jù)庫中創(chuàng)建對象(包括視圖,存儲(chǔ)過程和函數(shù))來作為應(yīng)用程序代碼與核心數(shù)據(jù)庫對象的中介.ViewsStoredProceduresOtherComponentsofanAbstractionLayer第六十九頁，共八十六頁，編輯于2023年，星期日Views使用視圖的目的是想基于用戶的需求以一種有意義的方式把實(shí)體展示給最終用戶.創(chuàng)建視圖時(shí)一定要清楚用戶能不能真正理解展示在其面前的數(shù)據(jù).創(chuàng)建視圖來使應(yīng)用程序邏輯更簡捷是一個(gè)好主意.避免使用”select*”語法和不帶值列表的insert語句.查看客戶(customer)數(shù)據(jù)的視圖第七十頁，共八十六頁，編輯于2023年，星期日視圖的例子(1)CREATEVIEWvw_customersASSELECT objid ,email ,customer_id ,firstname ,lastname ,homephone ,workphone ,mobilephoneFROMtbl_customer第七十一頁，共八十六頁，編輯于2023年，星期日視圖的例子(2)CREATEVIEWvw_customer_addressesASSELECT address_objid=objid ,address_label ,addressline1 ,addressline2 ,city ,region ,zipcode ,customer_objidFROMtbl_addressWHEREcustomer_objidISNOTNULL第七十二頁，共八十六頁，編輯于2023年，星期日StoredProcedures（1）存儲(chǔ)過程有著與視圖類似的規(guī)則。創(chuàng)建存儲(chǔ)過程的時(shí)候，考慮一下它們試圖影響的實(shí)體?？梢钥紤]創(chuàng)建一個(gè)標(biāo)準(zhǔn)來控制怎樣和為何創(chuàng)建存儲(chǔ)過程。正確實(shí)施存儲(chǔ)過程與環(huán)境和自身選擇有關(guān)，沒有絕對正確的答案。常見的做法是為每個(gè)實(shí)體創(chuàng)建一個(gè)存儲(chǔ)過程，它向所有相關(guān)的表更新或插入數(shù)據(jù)。第七十三頁，共八十六頁，編輯于2023年，星期日StoredProcedures（2）例：為MVM中的Customer實(shí)體存儲(chǔ)變更的步驟確定記錄是否已經(jīng)存在、若不存在，則插入若存在，則更新返回插入或更新的信息相應(yīng)的存儲(chǔ)過程如下：ALTERPROCEDUREprc_save_customer@emailvarchar(50),@customer_idchar(10),@firstnamevarchar(50),@lastnamevarchar(50)第七十四頁，共八十六頁，編輯于2023年，星期日StoredProcedures（3）,@homephonevarchar(15),@workphonevarchar(15),@mobilephonevarchar(15),@addressesCustomerAddressReadOnly,@customer_objidintOUTPUTASMERGEtbl_customerASpri_customer USING ( SELECTcustomer_id=@customer_id ) ASsource_customer(customer_id)第七十五頁，共八十六頁，編輯于2023年，星期日ON ( pri_customer.customer_id= source_customer.customer_id )WHENNOTMATCHEDTHENINSERT(email, customer_id, firstname, lastname, homephone, workphone, mobilephone)第七十六頁，共八十六頁，編輯于2023年，星期日VALUES(@email, @customer_id, @firstname, @lastname, @homephone, @workphone, @mobilephone)WHENMATCHEDTHEN UPDATE SETemail=@email, firstname=@firstname, lastname=@lastname, homephone=@homephone, workphone=@workphone, mobilephone=@mobilephone;第七十七頁，共八十六頁，編輯于2023年，星期日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 )第七十八頁，共八十六頁，編輯于2023年，星期日

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)第七十九頁，共八十六頁，編輯于2023年，星期日WHENNOTMATCHEDTHEN INSERT(address_label, addressline1, addressline2,