『壹』 如何用powerdesigner設計資料庫
工具：
Sybase PowerDesigner 15.1
Microsoft sql Server 2005
第一步概要設計：
打開PowerDesigner軟體，設計「概念數據模型」(ConceptualData Model)：
點擊workspace 右鍵---》New—>Conceptual DataModel,
彈出如下界面：
設計表、表結構：
在設計屬性(欄位)的時候，三個字母(M、P、D)分別表示：
M：是否為空；(√表示不允許為空)
P：是否為主鍵；
D：是否在該軟體的視圖中顯示
第二步：物理設計
將「概念數據模型」設計的表轉換為「物理數據模型」(PhysicalData Model)，實際上是從「概要設計」轉換為「詳細設計」，即對表的具體實現。
將概要設計模板轉換為物理設計
選擇「Tools」-->「Generate Physical DataModel…」即可。
然後選擇你的DBMS.
點擊「確定」按鈕以後，就產生了對應「SQL Server 2005」資料庫的表、屬性、關系的具體實現。
這時就會有一個物理設計的模板出現，將你在概要設計時的實體都轉換成具體的表。
第三步：在SQL Server2005中手動創建資料庫（也可以用SQL創建庫，pd可以將我們的表設計都轉換成SQL）
需手動在SQL SERVER2005中創建您的數據！如：「Students「，此過程省略…
第四步：在數據源ODBC中配置用戶數據源
第五步：在SQL Server2005中自動創建表結構
首先：根據「物理數據模型」(Physical Data Model)自動建立相應的SQL語句：
其次：執行其創建的SQL語句文件，將數據表結構自動創建到SQL Server 2005資料庫中：
完成以上步驟後，刷新SQL Server 2005數據，將會看到你所創建的相關表結構。
另外生成單張表SQL語句可以：
在物理設計模板中，選擇表--》右鍵—》SQL Perview…
生成SQL創建庫和表，我喜歡懶人式，或者說拿給客戶時，客戶用的爽。。。
建立表的主外鍵關系：
使用PowerDesigner物理模型為建的關系表添加外鍵，有個原則就是主表的主鍵名稱必須和副表的外鍵名稱一致。
測試(僅測試，不含技術)
1.建主表user 2.建副表department
uid int primarykey did int primary key
namevarchar(32) uid int
2.對著模型右擊New->Reference
parent表為user表，child表為department
這樣就建立了關系，外建也自動建立了。
關於表關系的建立，本人也存疑，但有三種思路：
1、概要設計時設計好關系。（個人傾向於這種方式，有時間嘗試）
2、物理設計時設計好關系（筆者使用此方法，若表很多，關系復雜，此階段設計關系會很痛苦。偶深受其害！）
3、生產資料庫後，DBMS中建立關系（這種方式是筆者突發奇想，仔細思考，不建議採用這種方式，如果使用T-SQL重構資料庫，又得重建關系）
仔細思考過後，個人認為概要設計時，設計實體、實體必要屬性、實體與實體關系，然後在資料庫物理設計時詳細設計表屬性等內容。
『貳』 資料庫介面設計
你問的應該是資料庫邏輯結構設計吧？也稱作模式設計。可以參考以下網址：
http://www.360doc.com/content/10/0713/10/1712218_38668931.shtml
http://apps.hi..com/share/detail/10584525
『叄』 畢設題目是「基於面向對象軟體研究方法的資料庫介面設計」請高手們指點一下吧
類似ado.net之類吧。
比方說從資料庫讀取數據，一般操作順序是這樣一個過程：連接資料庫，選擇資料庫，輸入查詢命令，得到查詢數據集，提取數據，關閉資料庫連接。
經過ado.net的抽象之後，就分為若干對象：
連接對象，命令對象，數據集對象等等。這些對象提供了一些方法，用來實現操作資料庫的過程。就是這樣。
比如：
連接對象.connectstring = "abc.db"
連接對象.open()就相當於完成了資料庫的選擇與連接。
『肆』 前後端分離，關於介面文檔，後端是要先寫好介面文檔，再進行寫代碼開發，還是寫完代碼後再編寫介面文檔
1、先理清業務流程
2、定義前後端開發的介面規范。比如json的格式，url的格式
3、定義介面文檔，這里的介面文檔一般就是對應後台的實體reqVo（調用後台介面<控制器>訪問的實體）和返回給前台的respVo（前台調用介面的返回的實體）。注意一般respVo都會有在後台做一個統一的處理為ResultVo（這個規范在2中要定義好，比如：錯誤碼，錯誤描述，請求的url，請求時間，以及實體T<這個實體才是真正的respVo和業務相關,這個一般都是實體>）
4、定義介面文檔是在了解業務流、數據流基礎之上完成的。有了這個介面文檔（其實就是定義實體的過程和對應的json）前後端的開發基本按照這個文檔去開發。介面文檔會有版本迭代，一般放到svn上，供所有開發人員閱覽
5、現在一般系統用到的資料庫都不會是單純mysql了。還有redis，mongo、es等。這些個人感覺都是在十分了解業務的情況和系統架構下去設計的。後台運用這些工具去完成介面功能的實現已經系統功能和性能的實現。這個和介面文檔先後順序還真不好說，個人覺得都可以。
6、業務流-數據流-資金流。去了解和設計系統。
『伍』 怎樣設計一個SQL和ACCESS資料庫通用的介面
把SQL和ACCESS兩個連接都寫出來，簡單點用IF就行了，如果連接SQL不成功就去連接ACCESS
『陸』 基於版本全量更新介面用java怎麼寫，資料庫怎麼設計
基本全量問題我肯定好，具體的
『柒』 在C#ADO.NET WinForm+Sqlserver2005資料庫三層構架中怎麼設計介面:介面應在那個層定義和實現
Model層定義好跟表對應起來的實體類；
UI層發送指令到BLL層，BLL層可能根據UI層的指定會做一些邏輯處理(所以叫業務羅層，也就是跟業務邏輯相關的，都放在這里)，再最終調用DAL層，執行資料庫訪問。比如UI層用戶點擊注冊，要實現注冊功能，那麼你的業務邏輯層可能要對用戶的數據進行各種校驗，最終再把校驗通過的數據傳給DAL層來執行插入或者修改之類的資料庫操作。
DAL層執行資料庫交互(增刪改查之類)，而且只是純粹的資料庫操作，不做其他業務邏輯的處理，最多就增加一些對資料庫操作這塊的邏輯判斷。並返回操作的結果(DataReader/DataTable之類看你需要，一般如果查詢數據，返回DataReader是比較高效的方式)的到BLL層，BLL層將返回的數據轉換成實體類或者實體類的集合，當然，你也可以在DAL層就把資料庫查出來的數據轉換成對象，切記，如果是在BLL層轉換DataReader成對象，一定要記得關閉DataReader。最後BLL層再把對象反饋給UI層
而Common層就是執行一些跟業務邏輯和資料庫訪問都不太相乾的處理的，比如把各種實用的方法封裝起來放到這里，以備各種項目調用。
『捌』 數據介面
系統在運行中將用到大量的數據資料，必須在設計初始就明確各類數據標准以及各子系統的數據介面。根據各子系統設計的數據項需求及產生的成果數據項，確定各項數據的數據表，定義表結構，進行代碼設計，然後由資料庫系統實施，同時形成文檔，作為系統的數據標准，統一執行。
數據的分類、編碼設計、資料庫的設計、地圖制圖、數據錄入和質量檢驗，均遵循國家和行業主管部門的標准、規范、規程;如沒有統一的規范規程，則參照相關的規程進行規范化設計。系統有關的數據定義全部形成文檔，作為技術規范，統一使用。
各子系統在設計時應當明確與相關子系統的數據關系，提出相關子系統必須提交的數據表要求和系統運行過程中的提交時間，對應子系統按照該提交數據要求在系統中進行相應設計和開發，保證數據流動的通暢，這是基於數據的系統集成方案的關鍵，是數據平台介面設計的重要依據。系統間數據關系須形成文檔，作為系統間數據介面標准規范，統一執行。
數據關系與數據標准相輔相成，共同定義了數據平台與各個子系統之間的輸入、輸出介面。在數據介面設計中應重點考慮以下幾個方面:
(1)遙感數據與圖形數據的介面:利用圖形配准技術，予以解決。遙感數據是動態監測專題圖件產生的基礎，必須經過坐標配准，才能產生專題圖件。配准過程由遙感動態監測子系統執行，需要應用綜合資料庫中的地形圖數據。在配准後遙感數據與圖形數據的套合依據空間坐標進行。
(2)空間數據與屬性數據的介面:利用關鍵字建立聯系。在數據建庫過程中依據數據標准有關文檔規定建立圖形庫和屬性庫結構，確定關鍵欄位，同時定義關鍵欄位編碼方案，保證關鍵欄位唯一性。在數據採集過程中對關鍵欄位賦予代碼。系統維護過程中的數據採集也必須依據編碼方案對關鍵欄位賦值。在應用系統中使用時只需建立圖形庫與屬性庫間的關聯即可。
( 3) 子系統之間數據的介面: 各子系統之間數據的交換通過資料庫進行，所以子系統間數據介面本質上是子系統與後台資料庫的介面; 在建立資料庫時，已經由資料庫管理系統依據系統間數據關系建立了介面。
系統內數據關系包括:
數據管理與資料庫子系統接受業務處理與信息服務子系統錄入的有關基礎信息、遙感動態監測子系統輸入的遙感數據及各子系統產生的成果數據，為各子系統提供綜合基礎數據、專題數據和成果數據。
遙感動態監測子系統需要資料庫系統管理的遙感數據、地形圖數據和歷史專題數據。
生態專業分析子系統需要遙感動態監測子系統產生的專題圖件和綜合資料庫中的歷史專題圖件以及屬性資料。
業務處理與信息服務子系統需要資料庫子系統管理的綜合基礎數據和各專業應用子系統產生的成果數據。
『玖』 請教專家，做費用管理系統系統，資料庫開發工作，設計介面表應該注意什麼
做費用管理系統系統，資料庫開發工作，設計接確
『拾』 簡述一個資料庫應用系統的建立過程
資料庫建立過程包括六個主要步驟：
1．需求分析：了解用戶的數據需求、處理需求、安全和完整性需求。
2．概念設計：通過數據抽象，設計系統的概念模型，一般為e－r模型。
3．邏輯結構設計：設計系統的模式和外部模式，特別是關系模型的基本表和視圖。
4．物理結構設計：設計數據的存儲結構和訪問方法，如索引的設計。
5．系統實現：組織數據存儲，編寫應用程序，試運行。
6．運維：系統投入運行，進行長期維護。
(10)介面設計資料庫擴展閱讀：
資料庫設計技巧：
1．原始文檔與實體之間的關系
它可以是一對一、一對多、多對多。一般來說，它們是一對一的關系：也就是說，原始文檔只對應於一個實體，而且只對應於一個實體。在特殊情況下，它們可能是一對多或多對一的，其中一個原始文檔對應多個實體，或者多個原始文檔對應一個實體。
這里的實體可以理解為基本表。在明確了這些對應關系之後，這對於輸入介面的設計是非常有益的。
2．主鍵和外鍵
通常，實體不能同時沒有主鍵和外鍵。在e－r關系圖中，葉中的實體可以定義主鍵，也可以不定義主鍵（因為它沒有後代），但是它必須有外鍵（因為它有父鍵）。
主鍵和外鍵的設計在全局資料庫的設計中起著重要的作用。當全球資料庫的設計完成後，一位美國的資料庫設計專家說：「鑰匙，鑰匙無處不在，只有鑰匙」，這是他的資料庫設計經驗，也是他高度抽象的信息系統核心思想（數據模型）的體現。
因為：主鍵是實體的高度抽象，主鍵和外鍵對，表示實體之間的連接。
3．基本表的屬性
基表不同於中間表和臨時表，因為它有以下四個特點：
原子性。基表中的欄位沒有分解。
原始性。基表中的記錄是原始數據（底層數據）的記錄。
先驗性。所有輸出數據都可以從基表和代碼表中的數據派生出來。
穩定。表的基本結構比較穩定，表中的記錄保存時間較長。
一旦理解了基本表的性質，就可以在設計資料庫時將它們與中間表和臨時表區分開。