數(shù)據(jù)庫及數(shù)據(jù)倉庫精要

數(shù)據(jù)庫及數(shù)據(jù)倉庫精要第一頁，共三十五頁，編輯于2023年，星期三前言數(shù)據(jù)庫扮演的角色也叫聯(lián)機事務處理OLAP(OnlineTransactionalProcessing)，數(shù)據(jù)庫保存由日常管理過程中涉及的業(yè)務操作創(chuàng)建的操作型結構化數(shù)據(jù)，數(shù)據(jù)記錄系統(tǒng)管理行為（通過各種業(yè)務邏輯來交互）。反映細粒度的事務數(shù)據(jù)，保存時間短。主要依賴關系建模方法論。數(shù)據(jù)倉庫扮演的角色也叫聯(lián)機分析處理OLAP(OnlineAnalyticalProcessing)，數(shù)據(jù)由聯(lián)機事務處理來，經(jīng)過選擇和聚集，變?yōu)榉治鍪聦嵁a(chǎn)生的因果，輔助決策制定（通過各種分析報表來交互）。反映大范圍的事實數(shù)據(jù)，保存時間長。主要依賴多維建模方法論第二頁，共三十五頁，編輯于2023年，星期三問題的導入結構良好的表，范式，SQL語言及關系基本表與中間表、臨時表不同，基本表及其字段之間的關系，應盡量滿足第三范式，是結構良好的表，它可以消除刪除行，改變行，修改行(實例)的錯誤和異常。它具有如下四個特性：(1)原子性，基本表中的字段是不可再分解的。(2)原始性，基本表中的記錄是原始數(shù)據(jù)（基礎數(shù)據(jù)）的記錄。(3)演繹性，由基本表與代碼表中的數(shù)據(jù)，可以派生出所有的輸出數(shù)據(jù)。(4)穩(wěn)定性，基本表的結構是相對穩(wěn)定的，表中的記錄是要長期保存的。(5)基本表的每個決定因子都必須是候選建。(6)菲基本表必須分解為兩個或多個基本表。三個基本范式：(1)1NF是對屬性的原子性約束，要求屬性具有原子性，不可再分解。(2)2NF是對記錄的惟一性約束，要求記錄有惟一標識，即實體的惟一性。(3)3NF是對字段冗余性的約束，即任何字段不能由其他字段派生出來，它要求字段沒有冗余大多數(shù)結構不良好的表，會產(chǎn)生或包含大量的冗余數(shù)據(jù)，同時可能會出現(xiàn)刪除行，改變行，修改行的錯誤和異常，這都是都是使用了SQLDMLCURD語句產(chǎn)生的。像中間表、報表和臨時表：(1)中間表是存放統(tǒng)計數(shù)據(jù)的表，它是為數(shù)據(jù)倉庫、輸出報表或查詢結果而設計的，有時它沒有主鍵與外鍵(數(shù)據(jù)倉庫除外)。(2)臨時表是程序員個人設計的，存放臨時記錄，為個人所用。(3)基表和中間表由DBA維護，臨時表由程序員自己用程序自動維護。關系是一個由行和列組成的二維表，不一定結構良好，特征為：行包括實體的數(shù)據(jù)，列包含實體性質的數(shù)據(jù)，表中的單元格存儲單個值，每列的所有實體類型一致，每列具有唯一名稱，列的順序任意，行的順序任意，任意兩行互不重復。這是最大的復合關系模式的條件，符合這個要求的表就是關系型表格。統(tǒng)計，匯總，分析表自動用Excel做第三頁，共三十五頁，編輯于2023年，星期三目錄E-R模型的概念與表示實體-聯(lián)系方法(概念設計)E-R圖向關系表的轉換(邏輯設計)第四頁，共三十五頁，編輯于2023年，星期三E-R模型的概念與表示實體集-語義(名詞類性)實體（Entity）事物就是在行動影響下物質本身的改變，或者進行?？陀^存在并可相互區(qū)別的事物稱為實體。實體可以是具體的，也可以是抽象的概念或聯(lián)系。具有共性的一類實體可歸類為一個實體集(Entityset)。屬性（Attribute）實體所具有的某一特性稱為屬性。一個實體可以由若干個屬性來刻畫。域（Domain）屬性的取值范圍或類型。鍵或標識符（Key）標識符是實體中一個或多個屬性的集合，可用來唯一標識實體中的一個實例。每個實體都必須至少有一個標識符。如果實體只有一個標識符，則它為實體的主標識符。如果實體有多個標識符，則其中一個被指定為主標識符，其余的標識符就是次標識符了第五頁，共三十五頁，編輯于2023年，星期三E-R模型的概念與表示聯(lián)系集-語義(動詞類型)實體之間可以通過聯(lián)系來相互關聯(lián)。與實體和實體集對應，聯(lián)系也可以分為聯(lián)系和聯(lián)系集，聯(lián)系集是實體集之間的聯(lián)系，聯(lián)系是實體之間的聯(lián)系，聯(lián)系是具有方向性的。聯(lián)系具有方向性，每個方向上都有一個基數(shù)。聯(lián)系的兩個方向上各自包含有一角色名，描述該方向聯(lián)系的作用。按照實體類型中實例之間的數(shù)量對應關系，通?？蓪⒙?lián)系分為4個基本聯(lián)系分為類，即一對一（ONE

TOONE）聯(lián)系、一對多（ONETOMANY）聯(lián)系、多對一（MANYTOONE）聯(lián)系和多對多聯(lián)系（MANYTOMANY）。三個特殊聯(lián)系每個實體類型都有自己的標識符，如果兩個實體集之間發(fā)生聯(lián)系，其中一個實體類型的標識符進入另一個實體類型并與該實體類型中的標識符共同組成其標識符時，這種聯(lián)系則稱為標定聯(lián)系，也叫依賴聯(lián)系。反之稱為非標定聯(lián)系，也叫非依賴聯(lián)系。遞歸聯(lián)系是實體集內(nèi)部實例之間的一種聯(lián)系，通常形象地稱為自反聯(lián)系。同一實體類型中不同實體集之間的聯(lián)系也稱為遞歸聯(lián)系。第六頁，共三十五頁，編輯于2023年，星期三E-R模型的概念與表示第七頁，共三十五頁，編輯于2023年，星期三E-R模型的概念與表示E-R圖的設計步驟

第一步：針對特定的應用，確定實體、屬性和實體間的聯(lián)系，畫出局部E-R圖。第二步：綜合各個局部E-R圖，產(chǎn)生反映數(shù)據(jù)庫整體概念的總體E-R圖。第八頁，共三十五頁，編輯于2023年，星期三E-R模型的概念與表示弱實體集有些實體集的所有屬性都不足以形成主碼，這樣的實體集稱為弱實體集(WeakEntitySet)，依賴于其它實體集而存在。與此相對，其屬性可以形成主碼的實體集稱為強實體集。弱實體集所依賴的實體集稱為標識實體集（identifyingentityset），相應的關系為標識聯(lián)系（identifyingrelationship）。OrderItemdatestatuspaymentorder#item#tagInclude第九頁，共三十五頁，編輯于2023年，星期三E-R模型的概念與表示弱實體集通常沒有主鍵。以訂單的分項為例，訂單項實體集可能有編號（局部的編號）、商品名稱、數(shù)量、單價等屬性，但是這些屬性不足以識別一個定單項，因為完全有可能在另外一張訂單中出現(xiàn)相同的內(nèi)容。必須把訂單的關鍵字（如一個全局的訂單編號）和定單項的局部編號結合起來才能標示一個定單項。弱實體集的屬性中，用來與標識實體集的鍵結合以識別一個弱實體集的屬性稱為部分鍵（partialkey）。弱實體集的主鍵=它的標識實體集的鍵+它的部分鍵第十頁，共三十五頁，編輯于2023年，星期三4.1E-R模型的概念與表示ER圖使用雙線矩形表示弱實體集，弱實體集與其標識實體集之間的聯(lián)系用雙線菱形表示，弱實體集的部分鍵使用虛下劃線表示。OrderItemdatestatuspaymentorder#item#tagInclude第十一頁，共三十五頁，編輯于2023年，星期三E-R模型的概念與表示實體集的層次關系現(xiàn)實世界中的很多概念之間都具體層次關系。ER模型使用實體集間的繼承和ISA關系來描述這種概念間的層次關系實體集老師或學生都繼承自實體集人，并且實體集老師或學生與實體集人之間都滿足ISA關系，即老師或學生都是人的一種。ISA關系可以從兩個方向進行設計從自上而下的方向，首先設計出人這一實體，然后根據(jù)屬性的不同，將兩種不同的人具體化（specification）為老師或者學生。從自下而上的方向，首先設計出老師或學生，然后將他們的共性提取出來，泛化（generalization）為人。第十二頁，共三十五頁，編輯于2023年，星期三E-R模型的概念與表示層次關系的約束從子實體集之間是否相交角度，不相交（disjoin）泛化要求繼承自同一父輩的多個子實體集之沒有交集，重疊（overlapping）泛化則允許有交集。從泛化是否完全角度，全參與泛化要求所有父輩實體都必須同時也是某一子輩實體，部分泛化則允許不是任何子輩實體的父輩實體存在。例如，在采用會員制的銷售系統(tǒng)中，顧客被分為會員（VIP)與非會員(NONVIP)兩種，會員擁有消費積分(credit)，非會員擁有固定的折扣率(discount)。一個顧客要么是會員、要么是非會員，二者必取其一，因此為全參與不相交。第十三頁，共三十五頁，編輯于2023年，星期三E-R模型的概念與表示CustomerISAVIPNONVIPcreditdiscountdisjoincustomer#namegenderbirthdaycityaddressemail第十四頁，共三十五頁，編輯于2023年，星期三E-R圖例第十五頁，共三十五頁，編輯于2023年，星期三實體-聯(lián)系方法實體還是屬性凡是滿足以下兩條準則的事物，一般均可作為屬性對待。作為屬性，不能再具有需要描述的性質。屬性必須是不可分的數(shù)據(jù)項，不能包含其他屬性。屬性不能與其他實體具有聯(lián)系，即E-R圖中所表示的聯(lián)系是實體之間的聯(lián)系。例如書籍是一個實體，書號、書名、作者、出版社、定價是書籍的屬性，如果應用系統(tǒng)不再需要作者的其他信息，如電話、住址、個人主頁等，那么根據(jù)原則1可以將作者作為書籍的屬性對待。但是如果這些信息是必須的，那么作者作為一個實體看待更為恰當。第十六頁，共三十五頁，編輯于2023年，星期三實體-聯(lián)系方法bookisbntitlepricepresswritten_bynameauthorauthorcityserialbookisbntitlepricepressauthor第十七頁，共三十五頁，編輯于2023年，星期三實體-聯(lián)系方法實體還是聯(lián)系一般來說，實體對應現(xiàn)實世界中實際存在的事物，是名詞類型；聯(lián)系對應的概念一般是一種動作，是動詞類型。例如：書和作者都是現(xiàn)實世界中的名詞，因此作為實體。而written_by表示作者寫書這一動作，因此作為聯(lián)系。映射基數(shù)往往影響到一個概念是作為實體還是聯(lián)系的選擇。若一項貸款只能由一個分行發(fā)放，并且只能由一個客戶借貸，則將Loan作為Customer與Branch之間的聯(lián)系比較合適。但如果允許多個客戶共同借貸同一項貸款，在這種情況下，將Loan作為實體。第十八頁，共三十五頁，編輯于2023年，星期三實體-聯(lián)系方法二元關系還是多元關系數(shù)據(jù)庫中使用得最多的是二元聯(lián)系。通常，將多元關系轉換為二元關系。如學校選課系統(tǒng)，涉及到學生、教室、教師、課程等多個實體，可表示為一個四元關系。

學生上課教室教師課程學生選課課程授課教師地點教室第十九頁，共三十五頁，編輯于2023年，星期三實體-聯(lián)系方法但也有一些情況下使用多元聯(lián)系更好（如需要表達多個實體集間的約束時）如學校選課系統(tǒng)中若一門課程可由多個教師教授，并且若課程和教師確定，則上課的地點也隨之確定。第二十頁，共三十五頁，編輯于2023年，星期三實體-聯(lián)系方法聯(lián)系屬性的放置影響聯(lián)系屬性放置的主要因素是聯(lián)系的映射基數(shù)。對于一對一或一對多聯(lián)系，選擇作為聯(lián)系屬性或實體屬性只是體現(xiàn)語義側重點的不同如銷售系統(tǒng)需要記錄顧客（Customer）與訂單（Order）之間的關系（Possess）。由于一個訂單只能由一個顧客所有，因此為顧客與訂單之間為一對多關系。這時，記錄生成訂單日期的屬性（date）既可以作為聯(lián)系Possess的屬性，也可作為訂單的屬性。

OrderdatestatuspaymentorderPossesCustomer第二十一頁，共三十五頁，編輯于2023年，星期三實體-聯(lián)系方法對于多對多聯(lián)系，聯(lián)系的屬性不能作為實體的屬性。如，顧客與希望書籍之間的聯(lián)系希望購買(Wish_for)。Wish_for有一屬性date，表示顧客發(fā)出購買意向的日期，這一屬性不能作為參與聯(lián)系的兩個實體Customer或Book的屬性。BookWish_forCustomerdate第二十二頁，共三十五頁，編輯于2023年，星期三實例——在線書店數(shù)據(jù)庫類似于Amazon的在線書店系統(tǒng)所用的數(shù)據(jù)庫數(shù)據(jù)庫中要求存儲所有書籍的相關信息，并對書加以分類；顧客的有關信息也要求存儲在數(shù)據(jù)庫中，并且允許用戶選擇自己感興趣的書籍類別及希望購買的圖書；顧客在決定購買時可以發(fā)出訂單，同一訂單可以包含多種書，每種書可一次購買多本。顧客在訂單中提供送貨地址，系統(tǒng)根據(jù)訂單發(fā)貨。第二十三頁，共三十五頁，編輯于2023年，星期三第二十四頁，共三十五頁，編輯于2023年，星期三實例——在線書店數(shù)據(jù)庫合并分E-R圖各分E-R圖之間的沖突主要有三類:屬性沖突

(1)屬性域沖突，即屬性值的類型、取值范圍或取值集合不同。

例如：屬性“訂單號”有的定義為字符型，有的為數(shù)值型。

(2)屬性取值單位沖突。

例如：屬性“庫存”有的以冊為單位，有的以千冊為單位。

命名沖突

(1)

同名異義。不同意義對象相同名稱。

例如：Author和Customer均有屬性name。

(2)

異名同義（一義多名）。同意義對象不相同名稱。

例如：“項目”和“課題”。

第二十五頁，共三十五頁，編輯于2023年，星期三實例——在線書店數(shù)據(jù)庫結構沖突

(1)

同一對象在不同應用中具有不同的抽象。

例如：“作者”在某一局部應用中被當作實體，而在另一局部應用中則被當作屬性。

(2)

同一實體在不同局部視圖中所包含的屬性不完全相同，或者屬性的排列次序不完全相同。

(3)

實體之間的聯(lián)系在不同局部視圖中呈現(xiàn)不同的類型。

例如：實體E1與E2在局部應用A中是多對多聯(lián)系，而在局部應用B中是一對多聯(lián)系；又如在局部應用X中E1與E2發(fā)生聯(lián)系，而在局部應用Y中E1、E2、E3三者之間有聯(lián)系。

解決方法是根據(jù)應用的語義對實體聯(lián)系的類型進行綜合或調整。

第二十六頁，共三十五頁，編輯于2023年，星期三E-R圖向表的轉換通過實體—聯(lián)系方法可以方便得得到現(xiàn)實世界的一個抽象模型，但這一模型并不能為數(shù)據(jù)庫管理系統(tǒng)接受。要完成從現(xiàn)實世界到信息世界的轉化，還必須將實體—聯(lián)系方法所得的E-R圖轉化為關系表定義。第二十七頁，共三十五頁，編輯于2023年，星期三實體的轉換將一個普通實體（非弱實體）轉換為表定義是相當直觀的，實體的每個屬性對應表中的一個字段，實體的主鍵對應表的主鍵。如Book實體轉化到表的結果為：Book(isbn,title,price,press,stock)第二十八頁，共三十五頁，編輯于2023年，星期三聯(lián)系的轉換一個多對多聯(lián)系在轉換后也對應一個表，表中的屬性包括參與聯(lián)系各實體的主鍵聯(lián)系的描述屬性參與聯(lián)系各實體的主鍵之和構成表的超鍵。如多對多聯(lián)系Written_by轉化為表之后其主鍵將由參與該聯(lián)系的兩個實體Book和Author的主鍵構成，如下：Written_by(isbn,author#,serial)第二十九頁，共三十五頁，編輯于2023年，星期三聯(lián)系的轉換一對一和一對多聯(lián)系A與B之間是一對多聯(lián)系，不轉換為一張單獨的表，而只在B轉換后的表中增加A的主鍵屬性（當然這些屬性將形成一個引用到A的主鍵的一個外鍵），以此表示某B實體所從屬的A實體。這種方法可以產(chǎn)生更少的表，有利于提高數(shù)據(jù)庫性能，還可以表達更多的約束如對于聯(lián)系Possess，將在Order表中增加一列customer#表示訂單從屬的顧客第三十頁，共三十五頁，編輯于2023年，星期三弱實體的轉換由于弱實體總是全參與它與它的標識實體之間的多對一聯(lián)系，因此可以采用上面提出的一對多聯(lián)系方法進行轉換。弱實體轉換后生成的表的主鍵由標識實體的主鍵與弱實體本身的部分鍵組合而成。如弱實體Item轉換后，構成如下：Item（order#,item#,isbn,qty)第三十一頁，共三十五頁，編輯于2023年，星期三實體層次的轉換將實體層次轉換為表定義時可采用兩種方法父輩實體與子輩實體都轉換為單獨的表

通用方法，任何情況適用。每一個子輩實體轉換為單獨的表，其中既包含各子輩實體的特殊屬性，也包含子輩與父輩實體的公有屬性。

只適用全參與泛化，因無法比哦啊是不從屬于任何子輩實體的父輩實體如Customer與VIP、NONVIP之間的全參與泛化可用第二種方法轉換為：VIP(customer#,name,gender,birthday,city,address,email,credit)NONVIP(customer#,name,gender,birthday,city,address,email,

discount)第三十二頁，共三十五頁，編輯于2023年，星期三一些實際的考慮一般來說，在