資料庫面向對象設計

A. 面向對象的多媒體資料庫系統的設計與實現

看你的開發量吧,一般你使用ACCESS就足夠了,sql是大型資料庫使用的,個人PC或者非專業設計師使用SQL或其它的都不理想,主要是它需要比較高的設備,還有它們的編程的難度都比ACCESS要大一些,推薦你去買一本開發類的書吧~~按照它的步驟一步一步來~!

B. 面向對象資料庫有哪些

面向對象是一種認識方法學，也是一種新的程序設計方法學。
目前，商品化的資料庫管理系統以關系型資料庫為主導產品，技術比較成熟。
面向對象的資料庫管理系統雖然技術先進，資料庫易於開發、維護，但尚未有成熟的產品。國際國內的主導關系型資料庫管理系統有ORACLE、SYBASE、INFORMIX和INGRES。這些產品都支持多平台，如UNIX、VMS、WINDOWS，但支持的程度不一樣。在下面的分析中會比較他們的平台支持能力。IBM
的DB2也是成熟的關系型資料庫。
但是，DB2是內嵌於IBM的
AS/400系列機中，只支持OS/400操作系統。

C. 哪些資料庫具有面向對象功能，主要是主流資料庫

面向對象資料庫是一種資料庫模式，oracle、postgresql都具有這功能。
優點如下：
1、易維護
採用面向對象思想設計的結構，可讀性高，由於繼承的存在，即使改變需求，那麼維護也只是在局部模塊，所以維護起來是非常方便和較低成本的。
2、質量高
在設計時，可重用現有的，在以前的項目的領域中已被測試過的類使系統滿足業務需求並具有較高的質量。
3、效率高
在軟體開發時，根據設計的需要對現實世界的事物進行抽象，產生類。使用這樣的方法解決問題，接近於日常生活和自然的思考方式，勢必提高軟體開發的效率和質量。
4、易擴展
由於繼承、封裝、多態的特性，自然設計出高內聚、低耦合的系統結構，使得系統更靈活、更容易擴展，而且成本較低。

D. 面向對象資料庫和關系資料庫的區別

以關系資料庫為例，SQL語言是一種非過程化的面向集合的語言，它雖然用起來非常簡單，但由於是解釋實現，效率不如人意。因此許多應用仍然是由高級程序設計語言（如C）來實現的，但是高級程序設計語言是過程化的，而且是面向單個數據的，這使得SQL與它之間存在著不匹配，我們把它叫做「阻抗失配」。不論你是用嵌入式SQL，還是CLI，都需要化很多工夫去完成兩種語言之間的相互轉化。 但是關系資料庫在資料庫系統方面發展地非常完善，有強大的管理功能和可操縱性。另外，關系模型具有堅實的數學基礎。

面向對象資料庫的產生主要是為了解決「阻抗失配」，它強調高級程序設計語言與資料庫的無縫連接。什麼叫無縫連接，假設你 不用資料庫，用C語言編了一個程序，你可以不需要（或基本不需要）任何改動就將它作用於資料庫，即你可以用C語言透明訪問資料庫，就好象資料庫根本不存在一樣，所以也有人把面向對象資料庫理解為語言的持久化。怎麼樣，聽起來挺玄的吧，可是我們自己開發的資料庫系統——OSCAR早就做到了這一點。 由於實現了無縫連接，使得面向對象資料庫能夠支持非常復雜的數據模型，從而特別適用於工程設計領域。打個比方，想像CAD中的一個復雜部件，它可能由成千上萬個不同的零件組成，要是用關系模型中的表來表達，得用多少張表啊？而描述這種復雜的部件，正好是高級程序設計語言的強項。

此外，面向對象資料庫還吸收了面向對象程序設計語言的思想，如支持類、方法、繼承等概念。 面向對象資料庫很好地解決了阻抗失配的問題，但它也有缺點。它的缺點正好是關系資料庫的強項，由於模型較為復雜（而且缺乏數學基礎），使得很多系統管理功能難以實現（如許可權管理），也不具備SQL處理集合數據的強大能力。

另一方面，隨著多媒體數據的大量出現和應用的日益復雜，關系資料庫也在不斷吸收面向對象資料庫的優點，出現了現在所謂的對象關系型資料庫（象ORACLE8i、DB2-5以上都是這種系統）。其主要改進包括支持自定義類型（UDT），方法，繼承（目前僅DB2-6支持），和引用（使得對象間可以直接引用，想想原來的關系資料庫需要靠連接來實現引用，性能真是慘不忍睹）。 總之，資料庫系統發展的趨勢是，面向對象資料庫和關系資料庫將不斷融合。而對象關系資料庫由於繼承了上述兩者的優點，已經成為目前資料庫發展的主流。

E. 資料庫的面向對象的設計方法和結構化的設計方法的區別

打個比方：
結構化的是設計好一個完整的桌子給你用，面向對象是設計桌子的組成零件，然後你自已拿回去裝。裝方的也行，裝圓的也行，三條腿也行，四條腿也行。

F. 面向對象建模—資料庫

可以的。
http://wenku..com/view/83aef893dd88d0d233d46a49.html

G. 資料庫面向對象模型的優缺點是什麼

1.優點

A重用性 利於開發速度 如果你想開發某個功能發現他實現起來很麻煩,這個時候有另一技術能很好的解決
時其優勢就發揮出來了

B,封裝性/抽象性:結構清晰 很標准 規范化 易於理解 可讀性更強

C.繼承 容易擴展,在大框架不變的情況下很容易就開發出適合自己的功能

2.缺點

A.執行速度會打折扣

H. 面向對象程序設計和資料庫開發課程設計

這個是二轉的吧，哈哈！去計算機高級論壇裡面有的！

I. 面向對象資料庫設計體現在哪些方面

採用那種方法來設計並沒有什麼規定，公司做的時間也不一定一直使用某種設計方法，之所以畫圖例就是為了：1，分析業務邏輯及流程。2，就是設計資料庫。做的時間不必死扣某種設計模式，以前我們做項目的時間也是各種圖都畫，但現在畫的用例圖是減之又減，主要考慮到開發周期和成本，每個模塊一張用例圖，但是一張用例圖基本上涵蓋了業務邏輯分析，流程分析，資料庫分析以及用例分析，做起來比較快，想試試的話，貼上郵箱

J. 資料庫中，設計一個對象關系數據模型

數據模型設計思考與實踐

李俊傑

概述

在當前的主要軟體應用項目中，資料庫在項目中的作用是極其重要的，因此作為項目基礎的數據模型的設計就顯得非常重要，不僅事關數據的存儲和使用，而且反映了對需求的理解和未來變化需求的適應性和擴展性，數據模型設計的好壞還影響存取效率和性能，同時也決定了項目的實現機制和擴展性，特別是對於分布式系統而言，數據的同步及網路通信的設計也非常重要。

數據的應用特性和分庫存儲設計

系統中的數據有著不同的應用特性，有的是靜態數據，如系統運行配置信息，在系統運行上線前必須初始化的，還有系統業務配置信息，也是在系統運行之初必須設置的，這些數據可能在系統下線都不會變化。有的是半靜態的數據，很少作更新處理，如一些產品定義數據只有在發布新的產品才會有所變化，其他時間一直處在休眠狀態。有的則是工作數據，在一個業務處理過程中會頻繁地進行更新，始終處於活躍期，會不斷地被訪問更新。

傳統的資料庫設計過程中，所有的數據放在一個資料庫中，好處是在數據存取時可最大限度地利用DBMS本身提供的功能來提高數據的存取效率。但從數據備份和數據管理的角度來看，就存在著一定的缺陷和問題。

按照數據的使用特性進行存儲管理根據其使用特性在實際應用中是有現實意義的，原因是：根據不同的數據應用特性進行分庫，可以有針對性地對不同的庫制定備份策略，在大型項目中數據量非常大，從數據安全和數據存儲管理方面考慮備份策略就非常有意義，另外分庫存儲設計提高了數據的訪問效率，因為可以針對業務數據的存取進行優化，對業務數據的訪問制定負載平衡策略，提高系統的訪問量和縮短系統的相應時間，當然提高系統的性能是一項復雜的系統工程，需要多方面的協作和優化，分庫存儲設計僅僅是其中之一。

文本型數據的代碼化和格式化

在系統的需求分析階段，有許多東西都是以文字描述的，設計人員要對這些內容龐雜的信息進行梳理和抽象，如何組織成為計算機能夠識別，且為實際系統應用中顯示操作人員所熟知的專業術語和行業術語，答案就是文本數據的代碼化和格式化。如單位性質（經濟分類）：00 其它企業單位，01 國有，02 集體，03 私營，04 個體。這樣，就可以在前台顯示文本，在資料庫相關表中存儲代碼，這樣有利於優化存儲，有利於需求的變更，如有些文本變化，只需更新相應的代碼表，並且針對統計分析需求就會非常容易。

還有代碼的版本的設計，如疾病代碼，不同時期採用不同版本的代碼，不同的行業採用不同版本，只須設計疾病版本表，疾病表（其中疾病版本號是外鍵）。

復雜的文本代碼化，如職業代碼，就可以分為職業大類，職業子類（其中職業大類代碼是外鍵），職業細類代碼（其中職業子類代碼是外鍵），從表的命名和外鍵的分布，顯然可以理解三個表的關系，另外同樣職業細類的代碼是「職業大類代碼」+「職業代碼子類」+「職業代碼細類序號」，如：

大類 子類 細類 代碼 說明

00 00 00 000000 無職業

00 00 01 000001 離退休

還有一種情況，即該類代碼只在一個表的一個欄位中使用，不據通用性，通常的設計是在Power Designer中列屬性的標准選項（standard checks） 中設置相關代碼，如理賠給付類型代碼：1 合同給付 ， 2 比例給付， 3 協議給付 ， 5 責任給付， 9 拒賠給付。

視圖的設計與使用

視圖是一種虛表，它依賴數據源的實表而存在，視圖的主要用途是針對數據安全方面考慮的，但在實際設計中，可以把常用的聯合查詢以視圖的形式設計在資料庫中，可以避免編程人員寫過多的資料庫sql語句，並且可以進行復雜邏輯處理、提高運算速度和節省存儲空間，同時也可以起到信息隱藏的目的，即你後台的資料庫表發生變化，只要視圖顯示的欄位不變，前台調用視圖就不用改變。特別是對你的資料庫不太了解的人員，其意義就更大了。

表欄位的靈活運用

欄位的借用，例如表中有兩個欄位，一個是code_type，一個是code。這樣根據code_type的不同，則code欄位中存儲不同的代碼。

表之間的虛依賴關系。例如一個表和依賴於兩個以上的表中的一個，那麼就有了這樣的情況。類似於欄位的借用，code_type的值不同，則code存儲的值是所依賴的不同的表的外鍵。

面向對象設計思想在數據模型設計中的作用

特別是對於應用系統，其需求往往是籠統和復雜的，首先分析需求不變和變化的部分，進而分析數據的相互關系，從頂到下，劃分其邏輯聯系，把相關的內容抽象成若干相互作用的對象，而每一個對象都有若干屬性，則每一屬性就可作為一個表所對應的欄位。還要澄清一個問題，數據模型（表）和對象並不是一一對應的關系，數據模型主要考慮數據存儲和數據之間的關系。而對象是數據和行為的結合體。表之間的關聯主要是主表和子表的關系，主鍵和外鍵的關系，但在對象設計時，有些表現為繼承關系，但大多數表現為聚合關系。在數據模型的設計中，常常使用中間表把多對多關系變成兩個一對多的關系。但在對象設計時就不會把中間表作為一個對象。

表和表之間的依賴關系，在對象設計中並不完全表示為繼承關系，而更多地表示為例如類型表（type），欄位有類型編碼（type_code），類型名稱（type_name）， 類型描述（type_dscr）；其子表如合同，在設計時把合同設計為一個類，而類型只是它的一個屬性，即合成關系。另外一種情況，合同表中設計一個類型欄位，然後根據該類型欄位，其更詳盡的屬性放到相關的子表中，類型不同，則需要不同的子表來描述其特性。這時就類似於繼承關系，但在面向對象設計中就會把合同設計成類，包括類型類介面屬性，類型類介面屬性的實現類則表示為合同子表的內容。

總之，數據模型的設計要綜合考慮諸多因素，例如提高資料庫的運行效率，必須從資料庫系統級優化、資料庫設計級優化、程序實現級優化等等，以上只是本人在數據模型設計中的體會和經驗，僅供參考。

努力，在於我熱愛我的事業，與中國的軟體一起走向成熟，走向世界。

聯系作者：[email protected]