⑴ PowerDesigner是什麼
PowerDesigner是建模工具。SQL，oracle是資料庫。
PowerDesigner的主要功能（1） DataArchitect這是一個強大的資料庫設計工具，使用DataArchitect 可利用實體-關系圖為一個信息系統創建"概念數據模型"－CDM（Conceptual Data Model）。並且可根據CDM 產生基於某一特定資料庫管理系統（例如：Sybase System 11）的"物理數據模型"-PDM(Physical Data Model)。還可優化PDM，產生為特定DBMS 創建資料庫的SQL 語句並可以文件形式存儲以便在其他時刻運行這些SQL 語句創建資料庫。另外，DataArchitect還可根據已存在的資料庫反向生成PDM，CDM 及創建資料庫的SQL腳本。（2） ProcessAnalyst這部分用於創建功能模型和數據流圖，創建"處理層次關系"。（3） AppModeler為客戶/伺服器應用程序創建應用模型。（4） ODBC Administrator此部分用來管理系統的各種數據源。
具體怎麼用，你可以下載一個PowerDesigner軟體，到網上找點相關的教材。
⑵ 數據建模的如何進行
概念建模
數據建模大致分為三個階段，概念建模階段，邏輯建模階段和物理建模階段。其中概念建模和邏輯建模階段與資料庫廠商毫無關系，換言之，與MySQL，SQL Server，Oracle沒有關系。物理建模階段和資料庫廠商存在很大的聯系，因為不同廠商對同一功能的支持方式不同，如高可用性，讀寫分離，甚至是索引，分區等。
概念建模階段
實際工作中，在概念建模階段，主要做三件事：
1. 客戶交流
2. 理解需求
3. 形成實體
這也是一個迭代，如果先有需求，盡量去理解需求，明白當前項目或者軟體需要完成什麼，不明白或者不確定的地方和客戶及時交流，和客戶double confirm過的需求，落實到實體（Package）；但是好多時候我們需要通過先和客戶交流，進而將交流結果落實到需求，之後進一步具體到實體；本文可能會涉及到一些來自於EA（Enterprise Architect 7.1）建模術語，（EA中將每個實體視為一個Package）。這里並不對各種建模工具進行比較，如Visio，EA，PowerDesigner， ERWin等；其實作為員工的我們選擇性很少，公司有哪個產品的Licence，我們就用哪個吧。
舉例說明：在一個B2C電子商務網站中，這樣的需求再普通不過了：客戶可以在該網站上自由進行購物！我們就以這個簡單例子，對其進行細分，來講解整個數據建模的過程，通過上面這句話，我們可以得出三個實體：客戶，網站，商品；就像Scrum（敏捷開發框架的一種）中倡導的一樣每個Sprint，都要產出確確實實的東西，OK，概念建模階段，我們就要產出實體。客戶和商品（我們將網站這個實體扔掉，不需要它。）
在創建這兩個實體（Package）的時候，我們記得要講對需求的理解，以及業務規則，作為Notes添加到Package中，這些信息將來會成為數據字典中非常重要的一部分，也就是所謂的元數據。BTW，EA或者其他建模工具應該都可以自動生成數據字典，只不過最終生成的格式可能不太一樣。如在Customer這個Package的Notes上，我們可以這樣寫，用戶都要通過填寫個人基本信息以及一個郵箱來注冊賬戶，之後使用這個郵箱作為登錄帳號登錄系統進行交易。
在概念建模階段，我們只需要關注實體即可，不用關注任何實現細節。很多人都希望在這個階段把具體表結構，索引，約束，甚至是存儲過程都想好，沒必要！！因為這些東西使我們在物理建模階段需要考慮的東西，這個時候考慮還為時尚早。可能有的人在這個階段擔心會不會丟掉或者漏掉一些實體?也不用擔心，2013年好多公司都在採用Scrum的開發模式，只要你當前抽象出來的實體滿足當前的User Story，或者當前的User Story裡面的實體，你都抽象出來了，就可以了！如果你再說，我們User Story太大，實體太多，不容易抽象，那就真沒辦法了，建議你們的團隊重新開Sprint 計劃會議。
邏輯建模
邏輯建模階段
對實體進行細化，細化成具體的表，同時豐富表結構。這個階段的產物是，可以在資料庫中生成的具體表及其他資料庫對象（包括，主鍵，外鍵，屬性列，索引，約束甚至是視圖以及存儲過程）。我在實際項目中，除了主外鍵之外，其他的資料庫對象我都實在物理建模階段建立，因為其他資料庫對象更貼近於開發，需要結合開發一起進行。如約束，我們可以在web page上做JavaScript約束，也可以在業務邏輯層做，也可以在資料庫中做，在哪裡做，要結合實際需求，性能以及安全性而定。
針對Customer這個實體以及我們對需求的理解，我們可以得出以下幾個表的結構，用戶基本信息表（User），登錄賬戶表（Account），評論表（Commnets,用戶可能會對產品進行評價），當然這個案例中我們還會有更多的表，如用戶需要自己上傳頭像（圖片），我們要有Picture表。
針對產品實體，我們需要構建產品基本信息表（Proct），通常情況下，我們產品會有自己的產品大類（ProctCategory）甚至產品小類（ProctSubCategory），某些產品會因為節假日等原因進行打折，因為為了得到更好的Performance我們會創建相應ProctDiscount表，一個產品會有多張圖片，因此產品圖片表（ProctPicture）以及產品圖片關系表（ProctPictureRelationship），（當然我們也可以只設計一張Picture表，用來存放所有圖片，用戶，產品以及其他）有人說產品和圖片是一對多的關系，不需要創建一個關系表啊?是的，我認為只要不是一對一的關系，我都希望創建一個關系表來關聯兩個實體。這樣帶來的好處，一是可讀性更好，實現了實體和表一一對應的關系，二是易於維護，我們只需要維護一個關系表即可，只有兩列（ProctID和PictureID），而不是去維護一個Picture表。
客戶進行交易，即要和商品發生關系，我們需要Transaction表，一個客戶會買一個或者多個商品，因為一筆Transaction會涉及一個或多個Procts，因此一個Transaction和ProctDiscount之間的關系（ProctDiscount和Proct是一一對應的關系）需要創建，我們稱其為Item表，裡面保存TransactionID以及這筆涉及到的ProctDiscountID（s），這里插一句，好多系統都需要有審計功能，如某個產品歷年來的打折情況以及與之對應的銷售情況，我們這里暫不考慮審計方面的東西。
就這樣，我們根據需求我們確定下來具體需要哪些表，進一步豐富每一個表屬性（Column），當然這裡面會涉及主鍵的選取，或者是使用代理鍵（Surrogate Key），外鍵的關聯，約束的設置等細節，這里筆者認為只要能把每個實體屬性（Column）落實下來就是很不錯了，因為隨著項目的開展，很多表的Column都會有相應的改動。至於其他細節，不同資料庫廠商，具體實現細節不盡相同。關於主鍵的選取多說一句，有的人喜歡所有的表都用自增長ID作為主鍵，而有的人希望找到唯一能標識當前記錄的一個屬性或者多個屬性作為主鍵；自增長ID作為代理主鍵，對於將來以多個類似當前Transaction System作為數據源，構建數據倉庫的時候，這些自增長ID主鍵會是一個麻煩（多個系統中，相同表存在大量主鍵重復）；使用一個屬性或多個屬性作為作為主鍵，不管主鍵是可編輯的，讀寫效率是我們必須考慮得。所以並沒有一個放之四海而皆準的原則，筆者只是給大家推薦一些考慮的因素。
物理建模
物理建模階段
EA可以將在邏輯建模階段創建的各種資料庫對象生成為相應的SQL代碼，運行來創建相應具體資料庫對象（大多數建模工具都可以自動生成DDL SQL代碼）。但是這個階段我們不僅僅創建資料庫對象，針對業務需求，我們也可能做如數據拆分（水平或垂直拆分），如B2B網站，我們可以將商家和一般用戶放在同一張表中，但是針對PERFORMANCE考慮，我們可以將其分為兩張表；隨業務量的上升，Transaction表越來越大，整個系統越來越慢，這個時候我們可以考慮數據拆分，甚至是讀寫分離（即實現MASTER-SLAVE模式，MYSQL/SQLSERVER可以使用Replication，當然不同存儲引擎採用不同的方案），這個階段也會涉及到集群的事情，如果你是架構師或者數據建模師，這個時候你可以跟DBA說，Alright,I am done with it,now is your show time.
相信大家都知道範式，更有好多人把3NF奉為經典，3NF確實很好，但是3NF是幾十年前提出來的，那個時候的數據量以及訪問頻率和2012年完全不是一個數量級的；因此我們絕對不能一味地遵守3NF；在整個數據建模過程中，在保證數據結構清晰的前提下，盡量提高性能才是我們關注的要點，因此筆者大力倡導數據適當冗餘!
上面筆者是結合一些實際例子表達自己對數據建模的觀點，希望對讀著有用。在數據建模過程中，不要希望一步到位將資料庫設計完整，筆者不管是針對data warehouse還是Transactional Database設計，從來沒有過一次成功的經歷。隨著項目的進行，客戶和開發團隊對業務知識與日增長，因此原來的設計也在不斷完善中。畢竟，數據建模或者設計資料庫不是我們的最終目的，我們需要的是一個健壯，性能優越，易擴展，易使用的軟體!
⑶ 海量資料庫解決方案的作者簡介
作者：（韓國）李華植 譯者：鄭保衛 蓋國強
李華植
代表韓國的資料庫技術先驅
集基於EA(Enterprise Architecture)的數據架構(Data Architecture)
方法論之大成
在韓國最早提出了數據專家顧問的概念
現任EN-CORE CONSULTING總經理及代表顧問
曾在韓國Oracle公司擔任200多家企業的技術顧問
論文：《構建海量數據系統時的RDB Performance問題解決方案》
書籍：《Data Modeling&Database Design》(1995)
《Oracle Server Tuning}(1995)
《海量資料庫解決方案》(1996)
《海量資料庫解決方案Ⅱ》(1998)
《數據架構解決方案I》(2003)
譯者簡介：
鄭保衛，於韓國國立釜慶大學信息工學系獲得工學博士，現任職於韓國最權威的資料庫公司EN-CORE CONSULTING，並兼任企業研究所研究員及資料庫電子商務研究所主要研究員。研究方向包括數據模型設計、海量資料庫解決方案、數據架構、基於資料庫技術的專家智能系統、ITA/EA（Infomation Technology Architecture/Enterprise Architecture）。
蓋國強（網名Eygle），Oracle ACE總監，恩墨科技創始人，ITPUB論壇超級版主，遠程DBA服務的倡導者和實踐者，致力於以技術服務客戶。著有《深入解析Orade》、《循序漸進Oracle》、《深入淺出Oracle》等書：從2010年開始，致力於《OracleDBA手記》的撰寫與編輯工作，並與張樂奕共同創立了ACOUG用戶組，在國內推進公益自由的Oracle技術交流活動。張樂奕（網名Kamus），恩墨科技技術總監，Oracle ACE，ITPUB資料庫管理版版主。他曾先後於北京某大型軟體公司、外資電信企業、咨詢公司任首席DBA。後任職於北京甲骨文軟體系統有限公司，高級顧問。他熱切關注Oracle資料庫及其他相關技術，對於Oracle資料庫RAC及高可用解決方案具有豐富的實踐經驗，長於資料庫故障診斷、資料庫性能調優。他還是各類技術會議的熱心分享者，2010年3月創建ACOUG用戶組。
崔華（網名Dbsnake），2004年開始從事DBA工作，在Oracle的安裝、升級、開發、性能調整、故障處理方面有豐富的經驗，對Oracle的體系結構具有深入了解：深入理解Oracle的內存結構、物理存儲（各種塊格式）、鎖機制、優化機制等：深入了解Oracle的備份恢復機制，熟悉Oracle的各種備份方法，能夠處理各種情況下的復雜數據恢復情況。
崔華也是熱心的技術分享者，多次在ACOUG的活動上與技術愛好者分享技術心得。
⑷ 如何在EA中自定義數據類型
對於編程語言和資料庫語言，EA都有預定義的數據類型。在某些情況下，可能需要修改預定義類型，或是增加新的數據類型。方法如下。
I.
在何處修改或新增數據類型
修改或新增數據類型的菜單路徑為：Settings > Code Datatypes 或 Settings
> Database Datatypes。
II. 如何新增一個數據類型
1.
選擇要新增數據類型的語言（Proct Name）。
2.
點擊「新增（New）」按鈕，並填入新增數據類型信息。
3.
單擊「保存（Save）」按鈕。
III.
如何修改一個預定義數據類型
如果直接修改預定義數據類型，會提示「This data type already
exists.」，所以只能通過迂迴方式修改：
1.
修改類型名，如把「VARCHAR」改成「VARCHAR2」，然後再修改其它信息並保存。
2.
恢復類型名，如將「VARCHAR2」改回「VARCHAR」並保存。
⑸ 如何將A資料庫中某表中的數據插入B資料庫的表中
A：將之前備份的數據文件再現有的數據文件中還原；還原時注意重新選擇資料庫恢復的路徑；
B：如果需要被插入數據的表中有欄位表示為自動增長，那麼需要將自動增長設置為「否」；單擊表右鍵「設計」--標示規范--改為否；
C：在B資料庫中執行此語句： insert into dbo.workflow_filesign select * from A.dbo.workflow_filesign where =；
比如：insert into dbo.workflow_filesign select * from test.dbo.workflow_filesign where user_id=148 ；test為備份還原的資料庫，被插入的資料庫為EASOA；將資料庫test中的workflow_filesign的表數據插入 EASOA資料庫中的workflow_filesign表中；
⑹ ea中從資料庫設計轉化的erd圖連接線不顯示
是ER圖。
E-R圖也稱實體-聯系圖(EntityRelationshipDiagram)。提供了表示實體類型、屬性和聯系的方法。用來描寫敘述現實世界的概念模型。實體就是看的見摸得著或者能被人感知接受認可的客觀存在。
EA一般指美國藝電公司。美國藝電公司（ElectronicArts，NASDAQ：ERTS，簡稱EA），是全球著名的互動娛樂軟體公司。
⑺ 軟體詳細設計說明書
面向對象軟體設計說明書模板
1 概述
1.1 系統簡述
對系統要完成什麼，所面向的用戶以及系統運行的環境的簡短描述，這部分主要來源於需求說明書的開始部分。
1.2 軟體設計目標
這部分論述整個系統的設計目標，明確地說明哪些功能是系統決定實現而哪些時不準備實現的。同時，對於非功能性的需求例如性能、可用性等，亦需提及。需求規格說明書對於這部分的內容來說是很重要的參考，看看其中明確了的功能性以及非功能性的需求。
這部分必須說清楚設計的全貌如何，務必使讀者看後知道將實現的系統有什麼特點和功能。在隨後的文檔部分，將解釋設計是怎麼來實現這些的。
1.3 參考資料
列出本文檔中所引用的參考資料。（至少要引用需求規格說明書）
1.4 修訂版本記錄
列出本文檔修改的歷史紀錄。必須指明修改的內容、日期以及修改人。
2 術語表
對本文檔中所使用的各種術語進行說明。如果一些術語在需求規格說明書中已經說明過了，此處不用再重復，可以指引讀者參考需求說明。
3 用例
此處要求系統用用例圖表述（UML），對每個用例（正常處理的情況）要有中文敘述。
4 設計概述
4.1 簡述
這部分要求突出整個設計所採用的方法（是面向對象設計還是結構化設計）、系統的體系結構（例如客戶/伺服器結構）以及使用到的相應技術和工具（例如OMT、Rose）
4.2 系統結構設計
這部分要求提供高層系統結構的描述，使用方框圖來顯示主要的組件及組件間的交互。最好是把邏輯結構同物理結構分離，對前者進行描述。別忘了說明圖中用到的俗語和符號。
4.2.1 頂層系統結構
4.2.2 子系統1結構
4.2.3 子系統2結構
4.3 系統界面
各種提供給用戶的界面以及外部系統在此處要予以說明。如果在需求規格說明書中已經對用戶界面有了敘述，此處不用再重復，可以指引讀者參考需求說明。如果系統提供了對其它系統的介面，比如說從其它軟體系統導入/導出數據，必須在此說明。
4.4 約束和假定
描述系統設計中最主要的約束，這些是由客戶強制要求並在需求說明書寫明的。說明系統是如何來適應這些約束的。
另外如果本系統跟其它外部系統交互或者依賴其它外部系統提供一些功能輔助，那麼系統可能還受到其它的約束。這種情況下，要求清楚地描述與本系統有交互的軟體類型（比如某某某資料庫軟體，某某某EMail軟體）以及這樣導致的約束（比如只允許純文本的Email）。
實現的語言和平台也會對系統有約束，同樣在此予以說明。
對於因選擇具體的設計實現而導致對系統的約束，簡要地描述你的想法思路，經過怎麼樣的權衡，為什麼要採取這樣的設計等等。
5 對象模型
5.1 系統對象模型
提供整個系統的對象模型，如果模型過大，按照可行的標准把它劃分成小塊，例如可以把客戶端和伺服器端的對象模型分開成兩個圖表述。
對象圖應該包含什麼呢？
在其中應該包含所有的系統對象。這些對象都是從理解需求後得到的。要明確哪些應該、哪些不應該被放進圖中。
所有對象之間的關聯必須被確定並且必須指明聯系的基數（一對一、一對多還是多對多，0..1，*，1..*）。聚合和繼承關系必須清楚地確定下來。每個圖必須附有簡單的說明。
可能經過多次反復之後才能得到系統的正確的對象模型。
6 對象描述
在這個部分敘述每個對象的細節，它的屬性、它的方法。在這之前必須從邏輯上對對象進行組織。你可能需要用結構圖把對象按子系統劃分好。
為每個對象做一個條目。在系統對象模型中簡要的描述它的用途、約束（如只能有一個實例），列出它的屬性和方法。如果對象是存儲在持久的數據容器中，標明它是持久對象，否則說明它是個臨時對象（transient object）。
對每個對象的每個屬性詳細說明：名字、類型，如果屬性不是很直觀或者有約束（例如，每個對象的該屬性必須有一個唯一的值或者值域是有限正整數等）。
對每個對象的每個方法詳細說明：方法名，返回類型，返回值，參數，用途以及使用的演算法的簡要說明（如果不是特別簡單的話）。如果對變數或者返回值由什麼假定的話，Pre-conditions和Post-conditions必須在此說明。列出它或者被它調用的方法需要訪問或者修改的屬性。最後，提供可以驗證實現方法的測試案例。
6.1 子系統1中的對象
6.1.1 對象：對象1
用途：
約束：
持久性：
6.1.1.1 屬性描述：
1. 屬性：屬性1
類型：
描述：
約束：
2. 屬性：屬性2
6.1.1.2 方法描述：
1. 方法：方法1
返回類型：
參數：
返回值：
Pre-Condition：
Post-Condition：
讀取/修改的屬性：
調用的方法：
處理邏輯：
測試例：用什麼參數調用該方法，期望的輸出是什麼……
7 動態模型
這部分的作用是描述系統如何響應各種事件。例如，可以建立系統的行為模型。一般使用順序圖和狀態圖。
確定不同的場景（Scenario）是第一步，不需要確定所有可能的場景，但是必須至少要覆蓋典型的系統用例。不要自己去想當然地創造場景，通常的策略是描述那些客戶可以感受得到的場景。
7.1 場景（Scenarios）
對每個場景做一則條目，包括以下內容：
場景名：給它一個可以望文生義的名字
場景描述：簡要敘述場景是干什麼的以及發生的動作的順序。
順序圖：描述各種事件及事件發生的相對時間順序。
7.1.1 場景：場景1
描述：
動作1
動作2
7.2 狀態圖
這部分的內容包括系統動態模型重要的部分的狀態圖。可能你想為每個對象畫一個狀態圖，但事實上會導致太多不期望的細節信息，只需要確定系統中一些重要的對象並為之提供狀態圖即可。
7.2.1 狀態圖1：
8 非功能性需求
在這個部分，必須說明如何處理需求文檔中指定的非功能性需求。盡可能客觀地評估系統應付每一個非功能性的需求的能力程度。如果某些非功能性需求沒有完全在設計的系統中實現，請務必在此說明。另外，你也需要對系統將來的進化作一個估計並描述本設計如何使系統能夠適應這些可預見的變化。
9 輔助文檔
提供能幫助理解設計的相應文檔。
10 詞彙索引
文章錄入
⑻ 求個資料庫，要求 設計題目： 設計一個資料庫系統，要求包含3個實體，1個聯系。 簡要說明該系統設計的用戶
可以憑借Baihi告知我們你的題目
有空能處理你無法解決的題目
如果你有更進一步的要求也能告訴我們
ES:\\
交易提醒:預付定金有風險
交易提醒:網路名中包含聯系方式勿輕信