常用的資料庫需求分析的方法

Ⅰ 資料庫的需求分析方法

資料庫設計需求
1. 需求概述
建立完善的資料庫結構管理設備的基本參數、運行狀態和各種工作計劃。

資料庫的框架和結構必須根據設備和運行狀態而設計，方便提供強大的錄入、查詢、統計、分析和報表等各種功能操作，較好的反映平台業務的基本情況和運行狀況，滿足平台的基本要求。

2. 外部設計需求
2.1 標識符和狀態

資料庫表前綴：根據模塊名定義（如用戶模塊：sys_）

用戶名：root

密碼：待定

許可權：全部

有效時間：開發階段

說明：系統正式發布後，可能更改資料庫用戶/密碼。

2.2 使用它的程序

本系統主要利用java作為後端的應用開發工具，使用MySQL作為後台的資料庫， Linux或Windows均可作為系統平台。

2.3 約定

所有命名一定要具有描述性，杜絕一切拼音、或拼音英文混雜的命名方式。
字元集採用 UTF-8，請注意字元的轉換。
所有數據表第一個欄位都是系統內部使用主鍵列，自增欄位，不可空，名稱為：id，確保不把此欄位暴露給最終用戶。
除特別說明外，所有日期格式都採用date格式。
除特別說明外，所有欄位默認都設置不充許為空， 需要設置默認值。
所有普通縮影的命名都是表名加設置縮影的欄位名組合，例如用戶表User中name欄位設置普通所以，則縮影名稱命名方式為user_name_index。
2.4 專門指導

對本系統的開發者、使用這、測試員和維護人員，提出以下參考意見：

在使用資料庫時，首先要參考上面的約定內容，做好軟體的安裝以及表格的建立。
資料庫的輸入統一採用鍵盤。對於資料庫的使用許可權，請參考本系統其他相關文檔。
資料庫的後台管理員沒用等級差異，可根據實際情況添加刪除管理員。
2.5 支持軟體

操作系統： Linux / Windows

資料庫系統：MySQL

查詢瀏覽工具：Navicat Premium

命令行工具：mysql

注意：mysql 命令行環境下對中文支持不好，可能無法書寫帶有中文的 SQL 語句。

3. 結構設計需求
3.1 概念結構設計需求

概念資料庫的設計是進行具體資料庫設計的第一步，概念資料庫設計的好壞直接影響到邏輯資料庫的設計，影響到整個資料庫的好壞。

我們已經得到了系統的數據流程圖和數據字典，現在就是要結合數據規范化的理論，用一種模型將用戶的數據要求明確地表示出來。

概念資料庫的設計應該極易於轉換為邏輯資料庫模式，又容易被用戶所理解。概念資料庫設計中最主要的就是採用「實體-關系數據」模型來確定資料庫的結構。

數據是表達信息的一種重要的量化符號，是信息存在的一種重要形式。數據模型則是數據特徵的一種抽象。它描述的是數據的共性，而不是描述個別的數據。一般來說，數據模型包含兩方面內容：

數據的靜態特性：主要包括數據的基本結構、數據間的關系和數據之間的相互約束等特性。
數據的動態特性：主要包括對數據進行操作的方法。
在資料庫系統設計中，建立反映客觀信息的數據模型，是設計中最為重要的，也最基本的步驟之一。

數據模型是連接客觀信息世界和資料庫系統數據邏輯組織的橋梁，也是資料庫設計人員與用戶之間進行交流的共同基礎。概念資料庫中採用的實體-關系模型，與傳統的數據模型有所不同。「實體-關系」模型是面向現實世界，而不是面向實現方法的，它主要是用使用方便，因而在資料庫系統應用的設計中，得到了廣泛應用。「實體-關系」模型可以用來說明資料庫中實體的等級和屬性。

以下是實體-關系模型中的重要標識：

在資料庫中存在的實體；
實體的屬性；
實體之間的關系；
3.2 邏輯結構設計需求
物理結構設計需求

1）定義資料庫、表及欄位的命名規范：

資料庫、表及欄位的命名要遵守可讀性原則。
資料庫、表及欄位的命名要遵守表意性原則。
資料庫、表及欄位的命名要遵守長名原則。
2）選擇合適的存儲引擎：
3）為表中的欄位選擇合適的數據類型。

4）建立資料庫結構

4. 運用設計需求
4.1 表名的命名規范

表名以英文單詞、單詞縮寫、簡寫、下劃線構成，總長度要求小於30位。

4.2 表欄位的命名規范

欄位名以英文單詞、單詞縮寫、簡寫、下劃線構成，總長度要求不超過30位。
欄位名以名詞或名詞短語，欄位採用單數形式。若表名由多個單片語成，則取各個單詞的縮寫組成，單詞縮寫間使用下劃線作為分隔。
若某個欄位是引用某個表的外鍵，則欄位名應盡量與源表的欄位名保持一致，一面混淆。
5. 安全保密設計需求
5.1 防止用戶直接操作資料庫的方法

通過把關鍵應用伺服器和資料庫伺服器進行分離，防止用戶對資料庫伺服器的直接操作，保證資料庫安全。

5.2 應用系統的用戶口令進行加密

在軟體系統中，對於數據的保護、業務操作的許可是通過識別用戶身份和許可權來完成的。用戶口令相比較，相同的話系統將該用戶的操作許可權分配給用戶，用戶再根據所分配的許可權對系統進行操作。

由以上過程可知，用戶口令在傳輸過程中容易被竊取泄漏，另外如果資料庫被非法進入則其中保存的口令能夠被非法查看。因此，在傳輸過程中和資料庫中的口令記錄欄位不應使用明文傳遞和保存，應該在口令被傳遞前對其明文口令使用有效的主流技術，對傳輸數據進行加密部分描述的加密演算法進行加密，在加密後傳輸到系統。系統將用戶提交的經過加密的口令數據保存的加密口令進行比較，相一致則進行後續操作。

Ⅱ 如何設計資料庫的需求分析

首先把你所做的項目的
業務邏輯
搞清楚，根據業務邏輯設計表。資料庫需求分析就是根據你的
項目需求
，把資料庫中的表，結構，關系，設計出來，並談寫利弊，說明
資料庫設計
的合理性。

Ⅲ 在建立系統的目標之前，為什麼必須分析問題的原因和結果

需求分析奠定了軟體工程和項目管理的基礎。我們在建造軟體系統這座大廈的時候，如果需求分析的基礎不夠堅實和牢固，那麼往往會導致軟體系統問題百出，甚至被馬上丟棄。在建造軟體系統的過程中，如果我們經常習慣地沿用一些不規范的方法，其後果便是產生一條鴻溝──開發者開發的與用戶所想得到的軟體存在著巨大的「期望差異」。 因此「需求」這個名詞的定義不僅僅是從用戶角度對系統外部行為的描述，以及從開發人員角度對系統內部特性的描述，其關鍵的一點是「需求」必須文檔化。

需求的類型
軟體需求包括三個不同的層次──業務需求、用戶需求和功能需求。 除此之外，每個系統還有各種非功能需求。
業務需求（BusinessRequirement）表示組織或客戶高層次的目標。業務需求通常來自項目投資人、購買產品的客戶、實際用戶的管理者、市場營銷部門或產品策劃部門。業務需求描述了組織為什麼要開發一個系統，即組織希望達到的目標。使用前景和范圍（vision and scope）文檔來記錄業務需求，這份文檔有時也被稱作項目輪廓圖或市場需求（project charter 或 market requirement）文檔。 用戶需求（UserRequirement）描述的是用戶的目標，或用戶要求系統必須能完成的任務。用例、場景描述和事件響應表都是表達用戶需求的有效途徑。也就是說用戶需求描述了用戶能使用系統來做些什麼。
功能需求（Functional Requirement）規定開發人員必須在產品中實現的軟體功能，用戶利用這些功能來完成任務，滿足業務需求。功能需求有時也被稱作行為需求（behavioral requirement），因為習慣上總是用「應該」對其進行描述：「系統應該發送電子郵件來通知用戶已接受其預定」。功能需求描述是開發人員需要實現什麼。
非功能需求（Non-functional Requirement） 定義了軟體產品為滿足用戶業務需求而必須具有的除功能需求以外的特性。包括系統的完整性（聯機幫助、 數據管理、用戶管理、軟體發布管理、在線升級等）、性能、可靠性、可維護性、可擴充性、對技術和業務的適應性等。
需求分析的任務
1 解決的問題
1) 齊全、准確地找出目標系統全部的功能、性能、限制； 2) 找出全部的輸入流、輸出流； 3) 找出所有的加工；
4) 產生完整的分層的DFD、數據字典、加工的描述； 5) 補充的意見。
2 綜合要求
確定對系統的綜合要求，系統功能要求，系統性能要求，運行要求，將來可能提出的要求。
3 任務
圖1為需求分析任務圖，需求分析階段要完成的具體明確的最終任務就是形成一份經開發方和用戶認可或達成共識的軟體需求分析文檔（需求規格說明書、修改後的項目開發計劃、初步的用戶手冊、確認測試計劃、數據要求說明書）。這個文檔能清晰准確地說明系統將要開發什麼，能夠規定出詳細的技術需求，包括所有面向用戶、面向機器和其它軟體系統的介面。可以說需求文檔在開發過程中一直起指導作用。
為了更好地完成軟體開發第一階段的需求分析任務，提高質量，需求管理是必不可少的。
需求管理的目的是在客戶與開發方之間建立對需求的共同理解，維護需求與其他工作成果的一致性，並控制需求的變更，主要體現在跟蹤和控制需求變更管理。需求管理是開發工作有效進行的保證，是一種很高層次的系統行為，涉及整個開發過程和產品本身。
需求分析的方法
需求分析方法由對軟體問題的信息域和功能域的系統分析過程及其表示方法組成，大多數的需求分析方法是由信息驅動的。信息域具有三種屬性： 信息流、信息內容和信息結構。
常用的需求分析方法有：面向數據流的結構化分析方法（SA），面向數據結構的Jackson方法（JSD），面向數據結構的結構化數據系統開發方法（DSSD），面向對象的分析方法（OOA）等。選擇那種方法要根據哪些資源在什麼時間對開發人員有效，不能盲目套用。這里著重闡述面向數據流的結構化分析方法（SA）。
面向數據流的結構化分析方法
面向數據流的結構化分析方法（Structured Analysis，簡稱SA），是面向數據流進行需求分析的方法，是需求分析使用最多的方法之一。 SA也是一種建模活動，該方法使用簡單易讀符號，根據軟體內部數據傳遞、變換的關系，自頂向下逐層分解，描繪出滿足功能要求的軟體模型。適用於數據處理類型軟體的需求分析，這一方法除了簡單，容易掌握之外，還能和設計階段的結構化設計（SD）銜接，從而取得良好的設計結果。
自頂向下逐層分解的分析策略
SA方法的基本手段：「分解」和「抽象」。這是系統開發技術中控制復雜性的兩種手段。它先將系統「抽象」成一個模型，此模型是有輸入和輸出並有系統名稱的盒子，然後打開這個盒子，對它進行逐層分解，直到能被理解，可以實現為止。因此分析的策略是自頂向下，逐層加細，由抽象到具體的過程。如圖2。
結構化分析方法使用工具
SA方法利用圖形等半形式化的描述方式表達需求，簡明易懂，用它們形成需求規格說明書中的主要部分。描述工具是
1) 數據流圖：描述系統由哪幾部分組成，各部分之間有什麼聯系等等。 2) 數據字典：定義了數據流圖中每一個圖形元素。
3) 描述加工邏輯的結構化語言、判定表、判定樹：詳細描述數據流圖中不能被再分解的每一個加工。
由於分析中的主要依據是數據傳遞及數據變換所形成的數據流，所以結構化分析一般採用的方法是使用數據流圖的分析方法，最終結果是產生需求規格說明書，該文檔包括一套數據流圖，對數據流圖中的成分進行定義的一本數據字典及對加工邏輯的描述。
結構化分析步驟
用結構化分析方法進行系統需求分析的具體步驟是： 1) 了解當前系統的工作流程，獲得當前系統的物理模型。通過對當前系統的詳細調查，了解當前系統的工作過程，同時收集資料、文件、數據、報表等，將看到的、聽到的、收集到的信息和情況用圖形描述出來。也就是用一個模型來反映自己對當前系統的理解，如畫系統流程圖。
2) 抽象出當前系統的邏輯模型。物理模型反映了系統「怎麼做」的具體實現，去掉物理模型中非本質的因素，抽取出本質的因素，構造出當前系統的邏輯模型，反映了當前系統「做什麼」的功能。
3) 建立目標系統的邏輯模型。分析、比較目標系統與當前系統邏輯上的差別，明確目標系統到底要「做什麼」，從而從當前系統的邏輯模型導出目標系統的邏輯模型。
4) 作進一步補充和優化。為了對目標系統做完整的描述，還需要對得到的邏輯模型做一些補充。
說明目標系統的人機界面。
說明至今尚未詳細考慮的細節（包括出錯處理、系統的啟動與結束、系統的輸入/輸出和系統性能方面的需求等）。
其他（系統特有的其他必須滿足的性能和限制，也需要用適當的形式做出書面記錄。 分析階段結束時，系統分析員必須和用戶再次認真地審查系統文件，爭取在系統開始設計之前，盡可能地發現其中存在的一些錯誤並及時糾正，直至用戶確認這個模型表達了他們的要求後，系統文件（軟體需求規格說明書等）才作為用戶和軟體開發人員之間的「合同」而最後得到確定。
結構化分析方法的優缺點
1) 優點： 結構化分析方法是軟體需求分析中公認的、有成效的、技術成熟的、使用廣泛的一種方法，它較適合於開發數據處理類型軟體的需求分析，該方法利用圖形等半形式化工具表達需求，簡明易讀，也易於使用，為後一階段的設計、測試、評價提供了有利條件。 2) 缺點：① 傳統的SA方法主要用於數據處理方面的問題，主要工具DFD體現了系統「做什麼」的功能，但它僅是一個靜態模型，沒有反映處理的順序，即控制流程。因此，不適合描述實時控制系統。② 上世紀60年代末出現的資料庫技術，使許多大型數據處理系統中的數據都組織成資料庫的形式，SA方法使用DFD在分析與描述「數據要求」方面是有局限的，DFD應與資料庫技術中的實體聯系圖(ER圖)結合起來(如同IDEF0功能模型與IDEF1信息模型相結合一樣)。ER圖能增加對數據存儲的細節以及數據與數據之間，數據與處理過程之間關系的理解，還解決了在DD中所包含的數據內容表示問題，這樣才能較完整的描述用戶對系統的需求。③ 對於一些頻繁的人機交互的軟體系統，如飛機訂票、銀行管理等系統，用戶最關系的是如何使用它，輸入命令、操作方式、系統響應方式、輸出格式等都是用戶需求的重要方面，DFD不適合描述人機界面系統的需求，SA方法往往對這一部分用自然語言作補充。④ 描述軟體需求的精確性有待提高。 5 需求的變更
在開發項目過程中，用戶隨時會提出一些新的需求，要求開發方解決，這些需求的提出，有時在開發階段中有時在開發階段後。這種在需求分析的兩個相鄰子階段中，或者在迭代周期的需求分析中，後一段或周期的需求分析結果與前一次不一致，我們把這種不一致稱為需求變更。產生需求變更的原因主要有以下幾個方面：1) 在需求分析階段，開發方與用戶的溝通不夠。在需求分析階段，開發方與用戶沒有很好的交流，開發方就根據用戶提供的大概信息，自己推導出用戶的需求。通過這種需求分析得出的需求往往會和用戶的實際需求相差甚遠，導致用戶提出更改需求。2) 項目的實施周期過長。隨著時間的推移，用戶對整個系統的了解也越來越深入。他們會對模塊的界面、功能和性能方面提出更高更多的要求。3) 技術更新過快。由於技術的快速更新， 企業可能引進一些新的設備， 而這些設備可能就會與我們的目標系統有直接的關系， 由於這一變化可能發生在解決用戶原先問題之前或者之中，那麼開發方不得不加入這一新的需求。[3]
為了盡可能地避免發生需求變更，以及保證需求分析的高穩定性，可以採用以下方法：1) 分工明確，系統分析員和程序員各有不同的職責。系統分析員處在用戶和程序員之間，溝通用戶和開發人員的認識和見解。系統分析員一方面要協助用戶對所開發的軟體提出需求，另一方面還要和程序員充分交換意見，探討其合理性和實現的可能性。如圖3所示，系統分析員在需求分析階段起著重要的作用。
2) 開發方與用戶進行協作和交流。在用戶提出需求變更時系統分析員應該認真聽取用戶的要求並加以整理和分析。分析需求變更的原因並提出可行的替代方案；同時向用戶說明這些需求變更會對整個項目的開發帶來的不良後果。3) 合同約束。由於需求變更可能會對整個項目產生影響，所以，開發方和用戶在簽定項目合同時，可以對需求變更增加一些相關的合同條款。4) 建立需求文檔並進行版本控制。需求分析的最終成果是一份客戶和開發方對所開發的產品達成共識的系統文檔。有了這份文檔， 即使開發方人員的角色有所變動，也不會對需求分析的前期工作有所影響。對每次的需求變更都用一個新的版本來標識。5) 需求評審和設立需求基線。為了讓開發方詳細了解用戶的需求，讓不同人員從不同的角度對需求進行驗證，作為需求的提出者（用戶方），在需求評審過程中，往往能提出許多有價值的意見，同時，也是對需求進行最後確認的機會，可以有效減少需求變更的發生。需求在通過正式評審和批准之後，應該確定需求基線，進一步的需求變更將在此基線的基礎上，依照項目定義的變更過程進行。設置需求基線可以將變更引起的麻煩減至最小。

軟體架構（software
architecture）是一系列相關的抽象模式，用於指導大型軟體系統各個方面的設計。 軟體架構是一個系統的草圖。軟體架構描述的對象是直接構成系
統的抽象組件。各個組件之間的連接則明確和相對細致地描述組件之間的通訊。在實現階段，這些抽象組件被細化為實際的組件，比如具體某個類或者對象。在面向
對象領域中，組件之間的連接通常用介面_(計算機科學)來實現。
軟體體系結構是構建計算機軟體實踐的基礎。與建築師設定建築項目的設計原則和目標，作為繪圖員畫圖的基礎一樣，一個軟體架構師或者系統架構師陳述軟體構架以作為滿足不同客戶需求的實際系統設計方案的基礎。
軟體構架是一個容易理解的概念，多數工程師（尤其是經驗不多的工程師）會從直覺上來認識它，但要給出精確的定義很困難。特別是，很難明確地區分設計和構架：構架屬於設計的一方面，它集中於某些具體的特徵。
在「軟體構架簡介」中，David Garlan 和 Mary Shaw
認為軟體構架是有關如下問題的設計層次：「在計算的演算法和數據結構之外，設計並確定系統整體結構成為了新的問題。結構問題包括總體組織結構和全局控制結
構；通信、同步和數據訪問的協議；設計元素的功能分配；物理分布；設計元素的組成；定標與性能；備選設計的選擇。
但構架不僅是結構；IEEE Working Group
on Architecture 把其定義為「系統在其環境中的最高層概念」。構架還包括「符合」系統完整性、經濟約束條件、審美需求和樣式。它並不僅注
重對內部的考慮，而且還在系統的用戶環境和開發環境中對系統進行整體考慮，即同時注重對外部的考慮。
在Rational Unified Process 中，軟體系統的構架（在某一給定點）是指系統重要構件的組織或結構，這些重要構件通過介面與不斷減小的構件與介面所組成的構件進行交互。
從和目的、主題、材料和結構的聯繫上來說，軟體架構可以和建築物的架構相比擬。一個軟體架構師需要有廣泛的軟體理論知識和相應的經驗來事實和管
理軟體產品的高級設計。軟體架構師定義和設計軟體的模塊化，模塊之間的交互，用戶界面風格，對外介面方法，創新的設計特性，以及高層事物的對象操作、邏輯
和流程。
一般而言，軟體系統的架構（Architecture）有兩個要素：
它是一個軟體系統從整體到部分的最高層次的劃分。
一個系統通常是由元件組成的，而這些元件如何形成、相互之間如何發生作用，則是關於這個系統本身結構的重要信息。
詳細地說，就是要包括架構元件（Architecture Component）、聯結器（Connector）、任務流（Task-flow）。
所謂架構元素，也就是組成系統的核心"磚瓦"，而聯結器則描述這些元件之間通訊的路徑、通訊的機制、通訊的預期結果，任務流則描述系統如何使用這些元件和
聯結器完成某一項需求。
建造一個系統所作出的最高層次的、以後難以更改的，商業的和技術的決定。
建造一個系統之前會有很多的重要決定需要事先作出，而一旦系統開始進行詳細設計甚至建造，這些決定就很難更改甚至無法更改。顯然，這樣的決定必定是有關系統設計成敗的最重要決定，必須經過非常慎重的研究和考察。
對於較大的通常應用應該使用框架，可能節省不少時間.。能使你很輕松的開發出一款軟體來。

Ⅳ 在資料庫設計需求分析的結果採用什麼描述

在資料庫設計需求分析的結果描述方法如下。
1、在需求分析中，通過自頂向下，逐步分解的方法分析系統，分析的結果採用數據流程圖進行圖形化的描述。

Ⅳ 數據處理的常用方式

數據分析與處理方法：
採集
在大數據的採集過程中，其主要特點和挑戰是並發數高，因為同時有可能會有成千上萬的用戶來進行訪問和操作，比如火車票售票網站和淘寶，它們並發的訪問量在峰值時達到上百萬，所以需要在採集端部署大量資料庫才能支撐。並且如何在這些資料庫之間進行負載均衡和分片的確是需要深入的思考和設計。
統計/分析
統計與分析主要利用分布式資料庫，或者分布式計算集群來對存儲於其內的大量數據進行普通的分析和分類匯總等，以滿足大多數常見的分析需求，在這方面，一些實時性需求會用到EMC的GreenPlum、Oracle的Exadata，以及基於MySQL的列式存儲Infobright等，而一些批處理，或者基於半結構化數據的需求可以使用Hadoop。統計與分析這部分的主要特點和挑戰是分析涉及的數據量大，其對系統資源，特別是I/O會有極大的佔用。
導入/預處理
雖然採集端本身會有很多資料庫，但是如果要對這些大量數據進行有效的分析，還是應該將這些來自前端的數據導入到一個集中的大型分布式資料庫，或者分布式存儲集群，並且可以在導入基礎上做一些簡單的清洗和預處理工作。也有一些用戶會在導入時使用來自Twitter的Storm來對數據進行流式計算，來滿足部分業務的實時計算需求。導入與預處理過程的特點和挑戰主要是導入的數據量大，每秒鍾的導入量經常會達到百兆，甚至千兆級別。
挖掘
與前面統計和分析過程不同的是，數據挖掘一般沒有什麼預先設定好的主題，主要是在現有數據上面進行基於各種演算法的計算，從而起到預測的效果，從而實現一些高級別數據分析的需求。比較典型演算法有用於聚類的K-Means、用於統計學習的SVM和用於分類的NaiveBayes，主要使用的工具有Hadoop的Mahout等。該過程的特點和挑戰主要是用於挖掘的演算法很復雜，並且計算涉及的數據量和計算量都很大，還有，常用數據挖掘演算法都以單線程為主。

Ⅵ 如何做好資料庫需求分析

資料庫設計

1、資料庫需求分析

1）針對超市進銷存管理系統，分別對采購部門、銷售部門和庫存保管部門進行詳細的調研和分析，總結出如下的需求信息：

商品按類管理，所以需要有一商品類型信息。

商品必須屬於一個商品類型。

如果一個商品類型存在商品，或存在下級商品類型，則該類型不可刪除。

需要記錄供應商品信息。

在涉及商品數量的地方，要給出相應的單位。

商品銷售信息單中要包含登記商品銷售數量、單價等信息。

在進貨信息中要包含商品供應商等信息。

商品報損要有報損原因。

進貨、銷售、報損操作要有相應操作員信息。

只有管理員登錄之後才可以使用系統。

默認的管理員不可以刪除。

進貨、銷售、庫存、報損信息都要可以添加、修改、刪除、分類查找。

當進行進貨、銷售和報損操作後，能相應更新庫存。

需要對進貨、銷售、庫存、報損進行分析，總結熱門商品。

2）經上述系統功能分析和需求總結，考慮到將來功能的擴展，設計如下的數據項和數據結構：

商品類型信息，包括數據項有：商品類型編號、商品類型名稱等。

商品信息，包括的數據項有：商品編號、商品名稱、商品介紹、庫存量等。

商品單位信息，包括單位編號、單位名稱等。

供應商信息，包括供應商名稱、介紹等。

進貨信息，包括進貨商品、數量、單位、單價、進貨時間經手人等。

銷售信息，包括銷售商品、數量、單位、單價、登記時間等。

報損信息，包括報損商品、數量、單位、原因、登記時間等。

管理員信息，包括管理員賬號、密碼、是否是默認賬號等。

2、資料庫概念結構設計

本系統根據以上的設計規劃出的實體有：商品類型信息實體、商品信息實體、商品單位信息實體、供應商信息實體、進貨信息實體、銷售信息實體、報損信息實體和管理員信息實體。

Ⅶ 資料庫設計的基本步驟

資料庫設計的基本步驟
按照規范設計的方法，考慮資料庫及其應用系統開發全過程，將資料庫設計分為以下6個階段
1.需求分析
2.概念結構設計
3.邏輯結構設計
4.物理結構設計
5.資料庫實施
6.資料庫的運行和維護
在資料庫設計過程中，需求分析和概念設計可以獨立於任何資料庫管理系統進行，邏輯設計和物理設計與選用的DAMS密切相關。
1.需求分析階段（常用自頂向下）
進行資料庫設計首先必須准確了解和分析用戶需求（包括數據與處理）。需求分析是整個設計過程的基礎，也是最困難，最耗時的一步。需求分析是否做得充分和准確，決定了在其上構建資料庫大廈的速度與質量。需求分析做的不好，會導致整個資料庫設計返工重做。
需求分析的任務，是通過詳細調查現實世界要處理的對象，充分了解原系統工作概況，明確用戶的各種需求，然後在此基礎上確定新的系統功能，新系統還得充分考慮今後可能的擴充與改變，不僅僅能夠按當前應用需求來設計。
調查的重點是，數據與處理。達到信息要求，處理要求，安全性和完整性要求。
分析方法常用SA(Structured Analysis) 結構化分析方法，SA方法從最上層的系統組織結構入手，採用自頂向下，逐層分解的方式分析系統。
數據流圖表達了數據和處理過程的關系，在SA方法中，處理過程的處理邏輯常常藉助判定表或判定樹來描述。在處理功能逐步分解的同事，系統中的數據也逐級分解，形成若干層次的數據流圖。系統中的數據則藉助數據字典（data dictionary，DD）來描述。數據字典是系統中各類數據描述的集合，數據字典通常包括數據項，數據結構，數據流，數據存儲，和處理過程5個階段。
2.概念結構設計階段（常用自底向上）
概念結構設計是整個資料庫設計的關鍵，它通過對用戶需求進行綜合，歸納與抽象，形成了一個獨立於具體DBMS的概念模型。
設計概念結構通常有四類方法：
自頂向下。即首先定義全局概念結構的框架，再逐步細化。
自底向上。即首先定義各局部應用的概念結構，然後再將他們集成起來，得到全局概念結構。
逐步擴張。首先定義最重要的核心概念結構，然後向外擴張，以滾雪球的方式逐步生成其他的概念結構，直至總體概念結構。
混合策略。即自頂向下和自底向上相結合。
3.邏輯結構設計階段（E-R圖）
邏輯結構設計是將概念結構轉換為某個DBMS所支持的數據模型，並將進行優化。
在這階段，E-R圖顯得異常重要。大家要學會各個實體定義的屬性來畫出總體的E-R圖。
各分E-R圖之間的沖突主要有三類：屬性沖突，命名沖突，和結構沖突。
E-R圖向關系模型的轉換，要解決的問題是如何將實體性和實體間的聯系轉換為關系模式，如何確定這些關系模式的屬性和碼。
4.物理設計階段
物理設計是為邏輯數據結構模型選取一個最適合應用環境的物理結構（包括存儲結構和存取方法）。
首先要對運行的事務詳細分析，獲得選擇物理資料庫設計所需要的參數，其次，要充分了解所用的RDBMS的內部特徵，特別是系統提供的存取方法和存儲結構。
常用的存取方法有三類：1.索引方法，目前主要是B+樹索引方法。2.聚簇方法（Clustering）方法。3.是HASH方法。
5.資料庫實施階段
資料庫實施階段，設計人員運營DBMS提供的資料庫語言（如sql）及其宿主語言，根據邏輯設計和物理設計的結果建立資料庫，編制和調試應用程序，組織數據入庫，並進行試運行。
6.資料庫運行和維護階段
資料庫應用系統經過試運行後，即可投入正式運行，在資料庫系統運行過程中必須不斷地對其進行評價，調整，修改。

Ⅷ 資料庫報告的需求分析一般是寫些什麼內容的

e-r圖：

E-RE-R圖也即實體-聯系圖(EntityRelationshipDiagram)，提供了表示實體型、屬性和聯系的方法，用來描述現實世界的概念模型。

E-R方法

E-R方法是「實體-聯系方法」（Entity-RelationshipApproach）的簡稱。它是描述現實世界概念結構模型的有效方法。

構成E-R圖的基本

構成E-R圖的基本要素是實體型、屬性和聯系，其表示方法為：·實體型(Entity)：具有相同屬性的實體具有相同的特徵和性質，用實體名及其屬性名集合來抽象和刻畫同類實體;在E-R圖中用矩形表示，矩形框內寫明實體名；比如學生張三豐、學生李尋歡都是實體。如果是弱實體的話，在矩形外面再套實線矩形。·屬性(Attribute)：實體所具有的某一特性，一個實體可由若干個屬性來刻畫。在E-R圖中用橢圓形表示，並用無向邊將其與相應的實體連接起來；比如學生的姓名、學號、性別、都是屬性。如果是多值屬性的話，再橢圓形外面再套實線橢圓。如果是派生屬性則用虛線橢圓表示。·聯系(Relationship)：聯系也稱關系，信息世界中反映實體內部或實體之間的聯系。實體內部的聯系通常是指組成實體的各屬性之間的聯系；實體之間的聯系通常是指不同實體集之間的聯系。在E-R圖中用菱形表示，菱形框內寫明聯系名，並用無向邊分別與有關實體連接起來，同時在無向邊旁標上聯系的類型（1:1，1:n或m:n）。比如老師給學生授課存在授課關系，學生選課存在選課關系。如果是弱實體的聯系則在菱形外面再套菱形。

[編輯本段]作E-R圖的步驟

⑴確定所有的實體集合⑵選擇實體集應包含的屬性⑶確定實體集之間的聯系⑷確定實體集的關鍵字，用下劃線在屬性上表明關鍵字的屬性組合⑸確定聯系的類型，在用線將表示聯系的菱形框聯繫到實體集時，在線旁註明是1或n(多）來表示聯系的類型

2.例子如圖：

需求分析：

寫

背景，目的，技術，可行性之類的：