[php] 通用權限管理資料庫設計

B/S系統中的權限比C/S中的更顯的重要，C/S系統因為具有特殊的客戶端，所以訪問用戶的權限檢測可以透過客戶端實現或透過客戶端+伺服器檢測實現，而B/S中，瀏覽器是每一台電腦都已具備的，如果不建立一個完整的權限檢測，那麼一個「非法使用者」很可能就能透過瀏覽器輕易存取B/S系統中的所有功能。因此B/S業務系統都需要有一個或多個權限系統來實現存取權限檢測，讓經過授權的使用者可以正常合法的使用已授權功能，而對那些未經授權的「非法使用者」將會將他們徹底的「拒於門外」。以下就讓我們一起了解如何設計可以滿足大部分B/S系統中對使用者功能權限控制的權限系統。

需求陳述

• 不同職責的人員，對於系統操作的權限應該是不同的。 優秀的業務系統，這是最基本的功能。
• 可以對「群組」進行權限分配。對於一個大企業的業務系統來說，如果要求管理員為其下員工逐一分配系統操作權限的話，是件耗時且不夠方便的事情。所以，系統中就提出了對「組」進行操作的概念，將權限一致的人員編入同一組，然後對該組進行權限分配。
• 權限管理系統應該是可擴充的。它應該可以加入任何具有權限管理功能的系統。就像是元件一樣的可以被不斷的重複使用，而不是每開發一套管理系統，就要針對權限管理部分重新開發。
• 滿足業務系統中的功能權限。 傳統業務系統中，存在著兩種權限管理，其一是功能權限的管理，而另一種則是資源權限的管理，在不同系統之間，功能權限是可以重用的，而資源權限則不能。

  關於設計

  以結構的動作程式設計概念，在設計階段，系統設計人員入手。為了實現需求，資料庫的設計可謂及其重要，無論是「群組」操作的概念，或是整套權限管理系統的重複使用性，都在於資料庫的設計。

  我們先來分析一下資料庫結構：

  首先，action表（首先，action表（表”

  ），gorupmanager表（T表） ，以及master表（

  以下簡稱為「人員表」），是三張實體表，它們依序記錄著「權限」的訊息，「管理群組」的資訊和「人員」的資訊。如下圖：

  這三個表之間的關係是多對多的，一個權限可能同時屬於多個管理組，一個管理組中也可能同時包含多個管理組中也可能同時包含多個管理組中也可能同時包含多個管理組中也可能同時包含多個管理組中也可能同時包含多個管理組中也可能同時包含多組權限。同樣的道理，一個人員可能同時屬於多個管理組，而一個管理組中也可能同時包含多個人員。如下圖：

  由於這三張表之間存在著多對多的關係，那麼它們之間的交互，最好使用另外兩張表來完成。而這兩張表起著映射的作用，分別是「actiongroup」表（以下簡稱「權限映射表」）

  和「mastergroup」表

  （以下簡稱「人員映射表」），前者映射了權限表與管理組表之間的互動。後者映射了人員表與管理組表之間的交互作用。如下圖：

  另外，還需要一張表來控制系統運行時左側選單中的權限分欄，也就是“分欄表”，如下圖：

  根據上面的分析，我們進行資料庫結構設計，如下圖：權限

  字段🎜

  

  為了能夠進行良好的分析，我們將資料庫結構分割開來，三張實體圖兩張映射表的作用。

  一 權限映射表 如下圖：

  首先，讓我們來了解一下與表關聯表權限組表與表關聯表

  與權限表

  。

  看圖中的紅圈，先看gorupid字段相關聯，這種關聯方式在實際資料庫中的表現如下：

  如圖所示，

  管理群組表中「超級管理員」的groupid為1，那麼權限映射表中groupid為1的權限也就是「超級管理員」所擁有的權限。

  使用groupid欄位關聯，是為了查到一個管理群組能夠執行的權限有哪些。但這些權限的詳細資訊卻是action字段關聯所查詢到的。

  action字段相關聯在資料庫中的表現如下圖：

  。的詳細資訊。綜合起來，我們就知道了一個管理群組可以執行的權限有哪些，以及這些權限的詳細資訊是什麼。

  

  或許你會問，為什麼不使用actionid欄位相關聯呢？因為：

  權限表

  中的id欄位在經過多次的資料庫操作之後可能會發生變更。

  權限映射表

  中僅記錄著一個管理群組可以執行的權限。
  • 一旦權限表中的id更改，那麼
  • 權限映射表
    中的記錄也就更改了。 一個管理群組可以執行的權限勢必將出錯，這是非常不希望的。
  • 考慮到上面的情況，所以應該使用action字段相關聯，因為：
  • 在在

    任何情況下也不可能發生變化的。

    權限映射表

    中記錄的action字段也就不會變。
    • 一個管理群組可以執行的權限就不會出錯了。
    • 二人員映射表 如下圖：

    • 人員表之間的欄位關聯，如下圖：

      id欄位關聯，這種關聯方式在資料庫中的表現如下圖：

      如圖，「超級管理員」群組的groupid為1，我們再看一次如圖，「超級管理員」群組的groupid為1，我們再看

      人員映射表，admin超級管理員組，而administrator屬於超級管理員組，同時也屬於管理員組。

      使用這種關聯方式，是為了查到一個管理組中的人員有誰。和上面一樣，人員的詳細資料是靠id欄位（

      人員映射表中是masterid欄位）關聯查詢到的。

      id欄位（人員映射表中是masterid欄位）關聯表現在資料庫中的形式如下圖：

      

      一個人員可能同時屬於多個“管理組”，如圖中，administrator就同時屬於兩個“管理組”。所以，在人員映射表中關於administrator的記錄就會是兩個。

      這種關聯方式才查詢到管理組中人員的詳細資料有哪些。綜合起來，才可以知道一個管理組的人員有誰，以及這個人員的詳細資料。

      再結合上面談到的權限表和權限映射表，就實現了需求中的「組」操作，如下圖：

      其實，管理組表

      中僅記錄著組的基本信息，如名稱，組id等等。至於一個群組中人員的詳細信息，以及該群組能夠執行的權限的詳細信息，都記錄在

      人員表和權限表中。兩張映射表才真正記錄一個群組有哪些人員，能夠執行哪些權限。透過兩張映射表的銜接，三張實體表之間的交互才得以實現，從而完成了需求中提到的「組」操作。 我們再來看看權限分欄表

      與

      權限表之間的互動。這兩張表之間的欄位關聯如下圖：

      兩張表使用了actioncolumnid欄位相關聯，這種關聯方式在資料庫中的表現如下圖

      如圖所示，透過這種關聯方式，我們可以非常清楚的看到

      權限表中的權限屬於哪個分欄。

      現在，資料庫結構已經很清晰了，分配權限的功能以及「群組」操作都已經實現。下面我們再來分析需求中提到的關於權限管理系統的重用性問題。

      為什麼使用這種資料庫設計方式搭建起來的系統可以重複使用呢？

      三張實體表中記錄著系統中的三個決定性元素。 “權限”，“群組”和“人”。而這三種元素可以任意添加，彼此之間不受影響。無論是那種類型的業務系統，這三個決定性元素是不會改變的，也意味著結構上不會改變，而變的只是資料。

      • 兩張映射表中記錄著三個元素之間的關係。
        但這些關係完全是人為創建的，需要變化的時候，只是對資料庫中的記錄進行操作，無需改變結構。
      • 權限分欄表中記錄系統使用時顯示的分欄
        。無論是要新增分欄，修改分欄或減少分欄，也只不過是操作記錄而已。
      • 綜上所述，這樣設計資料庫，系統是完全可以重用的，並且經受得住「變更」考驗的。 總結：

        此套系統的重點在於，三張實體表牢牢地抓住了兩張系統的核心成分，而兩張表張實體表之間的互動。其困難在於，理解映射表的工作，它記錄著關係，並且實現了「組」操作的概念。而係統總體的設計是本著可以在不同的MIS系統中「重複使用」來滿足不同系統的功能權限設定。

        附錄：權限管理系統資料表的欄位設計

        表如下圖：

        action表：

        

        actioncolumn表：

        

        actioncolumn表中記錄著幾列表中記錄著不同欄位的功能，每一塊功能運行時每塊功能的分列功能表中記錄著幾塊表中所記錄的功能，每塊功能，每塊功能的分欄功能分欄，每增加一個分欄，該表中的記錄就會增加一條,相對應的，左側選單欄中也會新增機一個欄。

        actiongroup表：

        

        action

        groupmanager表：

        

        ager

        man。

        mastergroup表：

        

        master關於某一位管理員的記錄可能有多筆。

        master表：

        

      🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜🎜（ 🎜🎜🎜🎜🎜🎜🎜 🎜 以上就介紹了[php] 通用權限管理資料庫設計，包含了面向的內容，希望對PHP教學有興趣的朋友有幫助。 🎜 🎜 🎜