一份全面的「資料庫設計需求分析」是怎樣的?

2020-12-13 人人都是產品經理

本文筆者將與大家分析資料庫外部設計需求、結構設計需求、運用設計需求以及安全保密設計需求。

資料庫設計需求

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 邏輯結構設計需求

項目結構實體、實體屬性ER圖如下:

用戶權限實體、實體屬性ER圖如下:

進度計劃權限實體、實體屬性ER圖如下:

3.3 物理結構設計需求

1)定義資料庫、表及欄位的命名規範:

資料庫、表及欄位的命名要遵守可讀性原則。資料庫、表及欄位的命名要遵守表意性原則。資料庫、表及欄位的命名要遵守長名原則。2)選擇合適的存儲引擎:

3)為表中的欄位選擇合適的數據類型。

4)建立資料庫結構

4. 運用設計需求

4.1 表名的命名規範

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

4.2 表欄位的命名規範

欄位名以英文單詞、單詞縮寫、簡寫、下劃線構成,總長度要求不超過30位。欄位名以名詞或名詞短語,欄位採用單數形式。若表名由多個單詞組成,則取各個單詞的縮寫組成,單詞縮寫間使用下劃線作為分隔。若某個欄位是引用某個表的外鍵,則欄位名應儘量與源表的欄位名保持一致,一面混淆。

5. 安全保密設計需求

5.1 防止用戶直接操作資料庫的方法

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

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

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

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

通過以上措施和過程,證了加密口令即使被竊取仍無法得到原始口令。

5.3 對用戶進行權限識別和分級

在XXXXXX平臺中,不同的業務不同的人員處理,並且對於不同的操作人員其所能夠訪問的數據是不同的。

為了保障各功能模塊的授權使用和數據不被非法訪問,系統劃分了不同的操作權限和數據讀寫等級。系統管理人員可以方便、靈活的將這些權限登記分配給某一個或某一類用戶。

當用戶登陸時,系統在用戶身份驗證通過後取得用戶的權限,根據用戶權限顯示相應的功能菜單。當用戶對數據進行讀、寫、刪除後瀏覽操作時,系統判斷用戶對該數據的訪問權限確定是否允許該操作的執行。

本文由 @臥枕江山 原創發布於人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基於CC0協議

相關焦點

  • 一份全面的「需求分析說明書」是怎樣的?
    撰寫目的本需求分析說明書主要以剖析的方式對「XXXXXXX管理平臺」做全面細緻的用戶需求分析,明確所要研發的系統應具有的模塊、功能與界面內的詳細需求,以供業主能夠確認項目的基本功能和具體性能,和業主達成一個立場,從而形成一致的理解和確定,是系統分析人員及後續的系統設計人員能夠更加清楚地了解用戶的具體需求,使得後面的設計、研發工作的基礎。
  • 一份全面的「數據需求分析」是怎樣的?
    筆者結合自己的案例,以獨到的見解說明了一份全面的數據需求分析應該包括:數據描述、邏輯描述、數據詞典、數據採集。針對數據需求分析模塊,我有自己的見解和分析方式。在這裡拿一段以前所做的案例分享給大家,寫得不好,其中也有很多欠缺之處,願朋友們看過之後能夠給出很好的批評,咱們在這裡相互學習、共同進步!
  • 一份全面的「實施規劃詳細方案說明書」是怎樣的?
    1.4.4 建築信息化的實施總則系統全面採用瀏覽器技術實現,遵循BIM理念進行系統架構設計。採用整體規劃,逐步實施的的原則。充分考慮企業現有系統和平臺系統間的資料庫結構優化、接口的工作。重點突破,根據企業實際需求,將首先選擇最主要的功能進行開發,起到以點帶面的效果。
  • 海研全球資料庫使用分析報告
    海研全球項目資料庫作為一種新產品,意圖打造學術交叉領域和細分領域的完整科研「生態鏈」,為科研工作者獲取意向領域的立項概況與競爭情報提供了數據來源。為了檢驗此產品的真實性能,我們首先考察了人機界面的基本功能,包括用戶的註冊流程是否簡單易行以及課題申報、科研項目、企業需求的細分領域檢索是否功能健全,能夠得到怎樣的結果,是否清晰直觀。
  • 高峽:數據倉庫下資料庫設計模式變遷
    【IT168資料庫大會現場報導】2014年4月10日-12日,第五屆中國資料庫技術大會(DTCC 2014)在北京五洲皇冠國際酒店拉開序幕。今天是12日下午的專場8:數據倉庫設計和管理。
  • 天貓面試真題:如何進行資料庫設計?
    在軟體開發的過程中,資料庫設計是非常重要的,它需要根據需求分析設抽象出 E-R 圖,邏輯結構設計,資料庫選型,物理設計,實施及運維。下面就聊聊那些年資料庫設計的那些事。數資料庫設計基本步驟需求分析階段要進行資料庫設計首先要了解用戶需求,參與到用戶需求分析中去,需求分析常用 SA(Structured Analysis:結構化分析方法)強調開發方法的結構合理性以及所開發軟體的結構合理性的軟體開發方法,是生命周期法的繼承與發展,是生命周期法與結構化程序設計思想的結合。
  • 資料庫設計經驗談
    一個成功的管理系統,是由:[50% 的業務 + 50% 的軟體] 所組成,而 50% 的成功軟體又有 [25% 的資料庫 + 25% 的程序] 所組成,資料庫設計的好壞是一個關鍵。如果把企業的數據比做生命所必需的血液,那麼資料庫的設計就是應用中最重要的一部分。有關資料庫設計的材料汗牛充棟,大學學位課程裡也有專門的講述。
  • UML:需求分析與設計的利器
    本文筆者將為大家總結一些在需求分析與設計階段會常用的到的UML圖,並且對每一個UML圖進行了詳細講解。其實不然,我認為:UML可以很有效的幫助產品經理或產品設計師進行前期的產品需求分析與產品的設計。在我們梳理項目的業務流程時就會用到活動圖,在我們整理系統功能時就會用到用例圖,在我們與客戶面對面進行溝通調研時用例圖、活動圖、順序圖等UML可以使得溝通變得更加順暢。將UML應用在項目需求分析和設計時,會使得它的學習門檻大大降低,而且也不一定需要掌握開發知識。
  • Access資料庫表設計步驟
    大家好,上節介紹了Access資料庫表中常見的概念,Access資料庫中表的部分主要難點就在於表的設計,本節主要是串聯一下Access資料庫中表設計時的大概步驟,只先了解即可,具體的內容部分後面根據分解的知識點展開講解。在創建資料庫時,首先要簡單分析明確建立資料庫的目,即分析資料庫中需要管理的內容。可以羅列一些需要用到的欄位。
  • 超全面!阿里設計師教你寫好一份設計文檔
    信息架構分析(包括Site Map、Experience Map、Flow等)、Framework框架設計、Wireframe線框圖和Mockup視覺稿等。前期的時候覺得沒什麼,後來就感覺到了問題,這樣很容易過早地陷入對視覺細節的糾纏,設計到一半忘了最初的設計目標,有時花了很多精力糾結一個模塊交互or視覺設計的好壞,後來卻發現整個模塊都沒有存在意義,已經背離了最初的業務目標與設計目標,根本不是用戶想要的東西;或者場景考慮不全面,設計完一個模塊後放到整體裡充滿矛盾,結果需要花更多精力來進行補救,導致進度Delay或只能上線充滿問題的版本等。
  • 數易軒:圖資料庫的定義是什麼?圖資料庫如何設計
    除了具有查詢語言接口外,還可以通過應用程式接口(API)訪問一些圖資料庫。圖資料庫與圖計算引擎不同。圖資料庫是轉換關係 OLTP 資料庫的技術。而圖計算引擎在 OLAP 中用於批量分析。由於主要技術公司在使用專有圖資料庫方面的成功以及開源圖資料庫的引入,圖資料庫在 2000 年代引起了相當大的關注。
  • 一份全面的用例描述是怎樣的?
    用例描述反映了系統分析員對用戶需求的理解,要達到能夠完全理解用戶需求的目標以及實現系統良好運轉的期許,例圖和文字描述相結合才是最完整的用例描述。根據以上說法,用例圖和文字描述相結合才是完整的用例描述,或者將其叫做能夠形成一種多元化多角度多層面融合的需求分析方陣(比如:用例矩陣),用例矩陣的形成也許會更加能夠表現出需求的直觀性。
  • 如何結合分析需求,設計數據埋點?
    沒有正確答案,只有最能夠幫助你衡量需求效果的方案。c.最後,還要設計出既全面又多維的屬性和屬性值,來幫助從多個維度描述一個埋點,以支撐後續各種角度的分析需求。圍繞4W1H完善埋點屬性的設計,並撰寫埋點文檔。除了支撐數據指標的計算需求外,還要能夠支撐實際工作中可能出現的分析需求。
  • 需求溝通與分析:需求溝通分析的三個步驟
    文章主要分享了關於需求溝通以及需求分析的幾個問題,希望通過本篇文章能夠給各位帶來些啟發和幫助。問:需求溝通分析有幾步?答:三(sán)步。質疑|是否要做這個需求?如何思考是否要接某個需求,可以在心裡問自己這樣幾個問題。首先,這個需求是否合理?這就需要作為設計師的我們儘可能全面的理解需求的背景、用戶群、使用頻次、上線預期效果等。把這些疑問拋出與產品同學深入交流,其實也是為了試探產品經理是否對需求考慮清楚。
  • 雲計算下一個戰場是資料庫 青雲QingCloud:用戶需求就是下一個產品
    青雲QingCloud資料庫產品經理王文謹在接受記者採訪時表示,與目前市場上眾多雲資料庫服務走大而全的路線不同,青雲更關注客戶的需求,"用戶的需求就是我們的下一個產品。  Gartner將這一變化歸因為,企業正將新應用向雲轉移,對數據存儲和計算分析的能力要求不斷加強。雲資料庫天然具備雲上靈活性,能夠提供強大的創新能力、豐富多樣的產品體系、經濟高效的部署方式和按需付費的支付模式。  但隨著移動網際網路、物聯網技術的迅猛發展,海量數據噴發,對資料庫提出了完全不同的需求。更為重要的環境變因是,All in Cloud成大趨勢。
  • 通用權限管理設計【資料庫結構設計】
    二,初步分析用戶和角色說到權限管理,首先應該想到,當然要設計一個用戶表這樣設計看起來沒什麼問題。是的,如果沒有加入新的關係的話,這樣是已經可以滿足大部分的需求了。不同的應用場合,你可能會想出不同的需求,提了一個新的需求以後,可能會發現原來的設計沒方法實現了,於是還要添加一個新的表。
  • 萬裡資料庫的極致性能是怎樣煉成的?
    分布式架構奠定萬裡資料庫的高性能基礎萬裡資料庫在架構設計和技術研發上就非常注重產品性能。我們的CPU等硬體設備相比之前有了很大的進步,兼容性較好,在功能上基本可以滿足需求,但客觀來說在性能、能耗、穩定性等方面還會有差距,這時候就需要通過軟體來彌補。
  • 為什麼雲原生+分布式是資料庫的未來?
    2020 雲棲大會期間,阿里巴巴正式成立雲原生技術委員會,同時推出了雲原生多模資料庫Lindorm、雲原生分布式資料庫PolarDB-X、雲原生數據倉庫AnalyticDB(ADB)、雲原生數據湖分析等一系列重磅自研雲原生資料庫產品。此舉也標誌著阿里雲資料庫全面進入了雲原生+分布式時代。
  • 「一二三」,做好B端客戶需求分析
    這種情況下,B端產品經理只有在做頂層設計時,就幫目標客群把SaaS產品價值的ROI測算清楚,才能保證做出來的產品既切中客戶真實需求,又在目標客群的付費能力之內,進而支撐銷售和客服團隊把SaaS產品賣出去。 然後,這條公式要怎樣使用呢?
  • 面試遇到資料庫設計,再也不怕了 | 14 個實用的資料庫設計技巧,一次性教給你!
    主鍵與外鍵的設計,在全局資料庫的設計中,佔有重要地位。當全局資料庫的設計完成以後,有個美國資料庫設計專家說:「鍵,到處都是鍵,除了鍵之外,什麼也沒有」,這就是他的資料庫設計經驗之談,也反映了他對信息系統核心(數據模型)的高度抽象思想。因為:主鍵是實體的高度抽象,主鍵與外鍵的配對,表示實體之間的連接。3.