UML系統(tǒng)分析與設計教程(第2版) 課件 第12章 數(shù)據(jù)庫設計

UML系統(tǒng)分析與設計SystemAnalysis&Design第十二章數(shù)據(jù)庫設計持久性數(shù)據(jù)庫層對象數(shù)據(jù)庫模型對象關系數(shù)據(jù)庫模型關系數(shù)據(jù)庫模型UML系統(tǒng)分析與設計第2版ZhenyanJi2數(shù)據(jù)庫設計在UML中，類圖定義了應用程序所需要的數(shù)據(jù)結構，用實體類以及實體類之間的關系來為數(shù)據(jù)庫中持久存在的數(shù)據(jù)結構建模。因此，需要將實體類映射為可以被數(shù)據(jù)庫識別的數(shù)據(jù)結構。如何將實體類、關聯(lián)關系、聚合關系、類屬關系轉變?yōu)?種數(shù)據(jù)庫（面向對象型、對象關系型、關系型數(shù)據(jù)庫）模型中的數(shù)據(jù)結構？UML系統(tǒng)分析與設計第2版ZhenyanJi3持久性數(shù)據(jù)庫層數(shù)據(jù)模型數(shù)據(jù)模型（DataModel）是以比原始的位和字節(jié)更易理解的方式描述數(shù)據(jù)庫結構的抽象。通用的數(shù)據(jù)模型層分類法認可3種抽象。概念數(shù)據(jù)模型概念數(shù)據(jù)模型是面向用戶、面向現(xiàn)實世界的數(shù)據(jù)模型邏輯數(shù)據(jù)模型邏輯數(shù)據(jù)模型提供的模型反應了數(shù)據(jù)庫管理系統(tǒng)DBMS的存儲結構，它是用戶從數(shù)據(jù)庫所看到的數(shù)據(jù)模型。物理數(shù)據(jù)模型物理數(shù)據(jù)模型定義了實際應用中數(shù)據(jù)是如何存儲于持久存儲設備（如磁盤）中的。UML系統(tǒng)分析與設計第2版ZhenyanJi4持久性數(shù)據(jù)庫層UML模型與持久數(shù)據(jù)庫層UML系統(tǒng)分析與設計第2版ZhenyanJi5對象數(shù)據(jù)庫模型ODB建模原語對象數(shù)據(jù)庫模型的基本建?；菍ο蠛妥置媪?。每個對象都有個對象標識符，字面量沒有對象標識符。ODB區(qū)分類（Class）和類型（Type），一個類型可以有多個類。例如，類“Tiger”和類“Lion”都實現(xiàn)了接口“Animal”，它們的類型都是“Animal”。ODB類可以有特性（Properties）和操作，特性可以是屬性（Attribute）或關系（Relationship），即連接該對象與其他對象的屬性。UML系統(tǒng)分析與設計第2版ZhenyanJi6對象數(shù)據(jù)庫模型ODB建模原語1．字面量和對象類型字面量可以分為以下3種類型：（1）原子字面量（AtomicLiterals）。（2）結構化字面量（StructuredLiterals）。（3）集字面量（CollectionLiterals）。對象類型可以分為以下3種類型。（1）原子對象。（2）結構化對象。（3）集（如set<Person>，Person是一個類）。UML系統(tǒng)分析與設計第2版ZhenyanJi7對象數(shù)據(jù)庫模型ODB建模原語2．關系對于關聯(lián)關系、聚合關系和類屬關系這3種關系，ODB模型可直接支持關聯(lián)關系和類屬關系，聚合關系則通過約束關聯(lián)來支持。UML系統(tǒng)分析與設計第2版ZhenyanJi8對象數(shù)據(jù)庫模型ODB建模原語3．ISA和EXTENDS繼承ODMG對象模型定義了兩種類屬關系，即ISA關系和EXTENDS關系。其中，ISA關系對應于早期的接口繼承（InterfaceInheritance），EXTENDS關系對應于實現(xiàn)繼承（Implemen-tationInheritance）。UML系統(tǒng)分析與設計第2版ZhenyanJi9對象數(shù)據(jù)庫模型映射到ODB1．映射實體類理論上，UML沒有禁止設計者通過定義新類（在分析階段）和使用模板（在設計階段）來擴充類型系統(tǒng)。但在實踐中，為了避免UML中次要類的激增，只有當實現(xiàn)平臺支持可擴充的類型系統(tǒng)、內建的結構化類型、集類型時，設計者才這樣做。UML系統(tǒng)分析與設計第2版ZhenyanJi10對象數(shù)據(jù)庫模型將實體類映射到ODB設計UML系統(tǒng)分析與設計第2版ZhenyanJi11對象數(shù)據(jù)庫模型映射到ODB2．映射關聯(lián)在UML模型中，類之間的關聯(lián)允許類對象之間的導航，這正是對象數(shù)據(jù)庫所擅長的，即由永久對象標識符連接的對象之間的導航。在映射過程中，可對設計進行優(yōu)化，將一些UML屬性或UML類模擬為ODB接口，從而將這些接口用作ODB類的屬性的類型。UML系統(tǒng)分析與設計第2版ZhenyanJi12對象數(shù)據(jù)庫模型關聯(lián)的映射UML系統(tǒng)分析與設計第2版ZhenyanJi13對象數(shù)據(jù)庫模型映射到ODB3．映射聚合UML的聚合有兩種語義，即具有引用語義的聚合（Aggregation）和具有值語義的組合（Composition）。在數(shù)據(jù)庫中，聚合被模擬為關聯(lián)或嵌套屬性。如果要加入特別的聚合語義，則需通過過程的方式（在程序中）實現(xiàn)，而不是通過聲明的方式（在數(shù)據(jù)結構中）實現(xiàn)。UML系統(tǒng)分析與設計第2版ZhenyanJi14對象數(shù)據(jù)庫模型聚合關系和組合關系UML系統(tǒng)分析與設計第2版ZhenyanJi15對象數(shù)據(jù)庫模型映射到ODB4．映射類屬從UML類屬關系到ODB的ISA和EXTENDS關系的映射基本上是“一對一”的，接口繼承用ISA關系來模擬，類繼承用EXTENDS關系來模擬。UML系統(tǒng)分析與設計第2版ZhenyanJi16對象數(shù)據(jù)庫模型類屬關系的映射UML系統(tǒng)分析與設計第2版ZhenyanJi17對象關系數(shù)據(jù)庫模型對象關系數(shù)據(jù)庫（Object-RelationalDatabaseMode，ORDBM）合并了老式關系模型數(shù)據(jù)庫和新式對象模型數(shù)據(jù)庫，使得對象關系數(shù)據(jù)庫管理系統(tǒng)（Object-RelationalDatabaseManagementSystem，ORDBMS）既能處理關系數(shù)據(jù)結構（關系表），又能處理對象數(shù)據(jù)結構（對象表）。UML系統(tǒng)分析與設計第2版ZhenyanJi18對象關系數(shù)據(jù)庫模型ORDB建模原語ORDB建模原語由對象建模原語和關系建模原語組成。主要的對象建模原語是用戶定義的結構化類型（StructuredType），該類型對應于ODB的“Interface”概念和UML的“Class”概念。ORDB的存儲機制是表（Table），表的列代表了可以接受用戶定義的結構化類型的值。為了與常規(guī)的關系表相區(qū)別，在ORDBMS實現(xiàn)中將這樣的表稱為對象表（ObjectTable）。UML系統(tǒng)分析與設計第2版ZhenyanJi19對象關系數(shù)據(jù)庫模型ORDB建模原語1．結構化類型ORDB表的列可以接受內建類型或用戶定義類型的值，ORDB的內建類型的功能類似于ODB的內建類型的功能。UML系統(tǒng)分析與設計第2版ZhenyanJi20對象關系數(shù)據(jù)庫模型ORDB建模原語2．對象表（ObjectTable）對象表是具有一個或多個列的行的集合。行是行類型的實例，對象表中的每一行都是由一個OID唯一標識的對象。行是可以插入表中或從表中刪除的數(shù)據(jù)的最小單位。為了快速區(qū)別對象類型和對象表，建議結構化后的類型名使用后綴TY。UML系統(tǒng)分析與設計第2版ZhenyanJi21對象關系數(shù)據(jù)庫模型ORDB建模原語3．行類型（RowType）行類型允許表在沒有使用結構化類型或集類型的情況下，具有相當復雜的內部結構。行類型是域的序列（即<域名><數(shù)據(jù)類型>對）。實際上，行類型允許將一個表嵌入到另一個表中，且表中的列可以含有行值。從數(shù)據(jù)庫編程的角度來說，行類型允許將完整的行存儲到變量中，允許將完整的行作為操作的輸入?yún)?shù)進行傳遞，還允許將完整的行作為操作的輸出參數(shù)或返回值進行返回。UML系統(tǒng)分析與設計第2版ZhenyanJi22對象關系數(shù)據(jù)庫模型ORDB建模原語4．引用類型（ReferenceType）結構化類型可以用來定義引用類型，用關鍵字“ref”來定義引用。例如，studref(StudentTY)就表示對象表中一個對結構化類型的引用。在SQL:1999中，引用類型是有作用域的，即它們引用的表在編譯時是確定的。UML系統(tǒng)分析與設計第2版ZhenyanJi23對象關系數(shù)據(jù)庫模型ORDB建模原語5．OF和UNDER繼承SQL:1999允許為已存在類型創(chuàng)建子類型，目前，SQL:1999只支持單一的實現(xiàn)繼承。對應于類型層次結構，可創(chuàng)建表層次結構。也就是說，為超類型創(chuàng)建超表，為子類型創(chuàng)建子表。但有時候，在表層次結構中有可能忽略類型層次結構中的類型UML系統(tǒng)分析與設計第2版ZhenyanJi24對象關系數(shù)據(jù)庫模型ORDB中的繼承UML系統(tǒng)分析與設計第2版ZhenyanJi25映射到ORDB1．映射實體類（EntityClass）UML系統(tǒng)分析與設計第2版ZhenyanJi26對象關系數(shù)據(jù)庫模型映射到ORDB2．映射關聯(lián)（Association）UML系統(tǒng)分析與設計第2版ZhenyanJi27對象關系數(shù)據(jù)庫模型映射到ORDB3．映射聚合（Aggregation）UML系統(tǒng)分析與設計第2版ZhenyanJi28對象關系數(shù)據(jù)庫模型映射到ORDB4．映射類屬（Generalization）UML系統(tǒng)分析與設計第2版ZhenyanJi29對象關系數(shù)據(jù)庫模型關系數(shù)據(jù)庫模型在過去的20年，關系數(shù)據(jù)庫模型（RelationalDatabaseModel）已經(jīng)基本占領了數(shù)據(jù)庫軟件市場，關系數(shù)據(jù)庫模型已經(jīng)取代了分層數(shù)據(jù)庫（HierarchicalDatabase）和網(wǎng)絡數(shù)據(jù)庫（NetworkDatabase）模型。最后的關系數(shù)據(jù)庫模型標準是SQL92，它是1992年得到ANSI和ISO的批準而發(fā)布的。市場上所有重要的RDBMS產(chǎn)品（包括Oracle、DB2、Sybase、Informix、SQLServer等）都遵守這一標準，雖然其方式各不相同。UML系統(tǒng)分析與設計第2版ZhenyanJi30關系數(shù)據(jù)庫模型RDB建模原語1．列、域和規(guī)則關系數(shù)據(jù)庫將數(shù)據(jù)存儲在由行和列組成的表中。其中存儲在行列交叉點的數(shù)據(jù)值必須是不可分的、單一的值，也就是說，列具有原子域（數(shù)據(jù)類型）。域定義了列可以接受的合法的值集，域可以是匿名的（如namevarchar(40)）也可以是有名的（如nameName），域Name在用來定義列“name”之前已經(jīng)定義過了。UML系統(tǒng)分析與設計第2版ZhenyanJi31關系數(shù)據(jù)庫模型RDB建模原語2．關系表關系表是由它的固定列集定義的，列具有內建的或用戶定義的類型。表可以有任意多行，但沒有重復的行。特定行的列值可以是Null，Null值意味著“值目前不知道”或“值不適用”。由于RDB模型要求“沒有重復行”，因此每個表都有一個主鍵（PrimaryKey）。一個表可以有多個鍵，任意選擇這些鍵中的一個作為對用戶最重要的主鍵，其他的鍵則被稱為備用鍵（AlternateKeys）。UML系統(tǒng)分析與設計第2版ZhenyanJi32RDB建模原語3．引用完整性（ReferentialIntegrity）RDB模型通過引用完整性約束來維護表之間的關系。這種表之間關系不是固定的行到行的連接，而是每當用戶請求系統(tǒng)發(fā)現(xiàn)關系時，RDB才去發(fā)現(xiàn)行到行的連接。這種發(fā)現(xiàn)是通過比較一個表的主鍵值與該表或另一個表的外鍵值來實現(xiàn)的。外鍵（ForeignKey）被定義為表中的列的集合，其值為Null，或者通過匹配同一個表中或另一個表中的主鍵值所得。主、外鍵的一致性被稱作引用完整性，引用完整性中的主鍵和外鍵必須是基于同一個域定義的，但可以有不同的名字。UML系統(tǒng)分析與設計第2版ZhenyanJi33關系數(shù)據(jù)庫模型引用完整性UML系統(tǒng)分析與設計第2版ZhenyanJi34關系數(shù)據(jù)庫模型RDB建模原語4．范式（NormalForms）RDB設計中一個最重要、但同時最不容易被理解的概念就是規(guī)范化。關系表必須是范式（NormalForm，NF），范式被分為以下6種。第一范式。第二范式。第三范式。BC范式（Boyce-Codd范式）。第四范式。第五范式。UML系統(tǒng)分析與設計第2版ZhenyanJi35關系數(shù)據(jù)庫模型映射到RDB如同ODB和ORDB模型一樣，RDB設計也可以用UML衍型和其他擴充機制來模擬。從UML類模型到RDB模式設計的映射需考慮RDB模型的局限性，即在關系模式中表達類的一些內建的聲明式語義是不可能存在的，這樣的語義必須在數(shù)據(jù)庫程序中解決。1．映射實體類（EntityClass）實體類到關系表的映射必須遵循表的第一范式，列必須是原子的。UML系統(tǒng)分析與設計第2版ZhenyanJi36關系數(shù)據(jù)庫模型映射實體類UML系統(tǒng)分析與設計第2版ZhenyanJi37關系數(shù)據(jù)庫模型映射到RDB2．映射關聯(lián)（Association）將關聯(lián)映射到RDB的過程涉及了表之間引用完整性約束的使用。任何“一對一”或“一對多”的關聯(lián)都可以通過在一個表中插入一個外鍵來匹配另一個表中的主鍵來表達。對于“一對一”關聯(lián)，可以將外鍵添加到其中任何一個表中，也可將兩個實體類合并在一個表中（取決于想達到的規(guī)范化水平）。對于遞歸的“一對一”或“一對多”關聯(lián)，外鍵和主鍵位于同一個表中。UML系統(tǒng)分析與設計第2版ZhenyanJi38關系數(shù)據(jù)庫模型映射關聯(lián)UML系統(tǒng)分析與設計第2版ZhenyanJi39關系數(shù)據(jù)庫模型映射到RDB3．映射聚合（Aggregation）關聯(lián)映射的主要原理也適用于聚合映射。對于強形式聚合——組合（具有引用語義的聚合被看作是弱形式的聚合，具有值語義的組合則被看作是強形式的聚合），應該將子集和超集實體類組合到一張表中。這對于“一對一”的聚合是可能的，但對于“一對多”的聚合，子集類（無論是強形式聚合還是弱形式聚合）則必須被模擬為一個單獨的表（用一個外鍵將它和它的超集類的表連接起來）。UML系統(tǒng)分析與設計第2版ZhenyanJi40關系數(shù)據(jù)庫模型映射聚合UML系統(tǒng)分析與設計第2版ZhenyanJi41關系數(shù)據(jù)庫模型映射到RDB