借助noahweb的動作程式設計理念，在設計階段，系統設計人員無須考慮程式結構的設計，而是從程式流程以及資料庫結構開始入手。為了實現需求，資料庫的設計可謂及其重要，無論是「組」操作的概念，還是整套許可權管理系統的重用性，都在於資料庫的設計。
我們先來分析一下資料庫結構：
首先，action表（以下簡稱為「許可權表」），gorupmanager表（以下簡稱為「管理組表」），以及master表（以下簡稱為「人員表」），是三張實體表，它們依次記錄著「許可權」的資訊，「管理組」的資訊和「人員」的資訊。如下圖：
這三個表之間的關係是多對多的，乙個許可權可能同時屬於多個管理組，乙個管理組中也可能同時包含多個許可權。同樣的道理，乙個人員可能同時屬於多個管理組，而乙個管理組中也可能同時包含多個人員。如下圖：
由於這三張表之間存在著多對多的關係，那麼它們之間的互動，最好使用另外兩張表來完成。而這兩張表起著對映的作用，分別是「actiongroup」表（以下簡稱「許可權對映表」）和「mastergroup」表（以下簡稱「人員對映表」），前者映**許可權表與管理組表之間的互動。後者映**人員表與管理組表之間的互動。如下圖：
另外，還需要一張表來控制系統執行時左側選單中的許可權分欄，也就是「許可權分欄表」，如下圖：
根據上面的分析，我們進行資料庫結構設計，如下圖：
為了能夠進行良好的分析，我們將資料庫結構圖拆分開來，三張實體表的作用已經很清晰，現在我們來看一下兩張對映表的作用。
一 許可權對映表如下圖：
首先，我們來了解一下許可權對映表與管理組表以及許可權表之間的字段關聯。
看圖中的紅圈，先看gorupid欄位相關聯，這種關聯方式在實際資料庫中的表現如下圖：
如圖中所示，管理組表中「超級管理員」的groupid為1，那麼許可權對映表中groupid為1的許可權也就是「超級管理員」所擁有的許可權。
使用groupid欄位關聯，是為了查到乙個管理組能夠執行的許可權有哪些。但這些許可權的詳細資訊卻是action欄位關聯所查詢到的。
action欄位相關聯在資料庫中的表現如下圖：
通過這種關聯，才查詢到許可權對映表之中那些許可權的詳細資訊。綜合起來，我們就知道了乙個管理組可以執行的許可權有哪些，以及這些許可權的詳細資訊是什麼。
或許你會問，為什麼不使用actionid欄位相關聯呢？因為：
許可權表中的id欄位在經過多次的資料庫操作之後可能會發生更改。
許可權對映表中僅僅記錄著乙個管理組可以執行的許可權。
一旦許可權表中的id更改，那麼許可權對映表中的記錄��就更改了。
乙個管理組可以執行的許可權勢必將出錯，這是非常不希望的。
考慮到上面的情況，所以應該使用action欄位相關聯，因為：
在許可權表中，id可能發生變化，而action欄位卻是在任何情況下也不可能發生變化的。
許可權對映表中記錄的action欄位也就不會變。
乙個管理組可以執行的許可權就不會出錯了。
二 人員對映表如下圖：
我們來了解一下人員對映表與管理組表以及人員表之間的字段關聯，如下圖：
看圖中的紅圈部分，先看groupid欄位關聯，這種關聯方式在資料庫中的表現如下圖：
如圖，「超級管理員」組的groupid為1，我們再看人員對映表，admin屬於超級管理員組，而administrator屬於超級管理員組，同時也屬於管理員組。
使用這種關聯方式，是為了查到乙個管理組中的人員有誰。和上面一樣，人員的詳細資訊是靠id欄位（人員對映表中是masterid欄位）關聯查詢到的。
id欄位（人員對映表中是masterid欄位）關聯表現在資料庫中的形式如下圖：
乙個人員可能同時屬於多個「管理組」，如圖中，administrator就同時屬於兩個「管理組」。所以，在人員對映表中關於administrator的記錄就會是兩條。
這種關聯方式才查詢到管理組中人員的詳細資訊有哪些。綜合起來，才可以知道乙個管理組中的人員有誰，以及這個人員的詳細資訊。
再結合上面談到的許可權表和許可權對映表，就實現了需求中的「組」操作，如下圖：
其實，管理組表中僅僅記錄著組的基本資訊，如名稱，組id等等。至於乙個組中人員的詳細資訊，以及該組能夠執行的許可權的詳細資訊，都記錄在人員表和許可權表中。兩張對映表才真正記錄著乙個組有哪些人員，能夠執行哪些許可權。通過兩張對映表的銜接，三張實體表之間的互動才得以實現，從而完成了需求中提到的「組」操作。
我們再來看一下許可權分欄表與許可權表之間的互動。這兩張表之間的字段關聯如下圖：
兩張表使用了actioncolumnid欄位相關聯，這種關聯方式在資料庫中的表現如下圖：
如圖所示，通過這種關聯方式，我們可以非常清晰的看到許可權表中的許可權屬於哪個分欄。
現在，資料庫結構已經很清晰了，分配許可權的功能以及「組」操作都已經實現。下面我們再來分析一下需求中提到的關於許可權管理系統的重用性問題。
為什麼使用這種資料庫設計方式搭建起來的系統可以重用呢？
三張實體表中記錄著系統中的三個決定性元素。「許可權」，「組」和「人」。而這三種元素可以任意新增，彼此之間不受影響。無論是那種型別的業務系統，這三個決定性元素是不會變的，也就意味著結構上不會變，而變的僅僅是資料。
兩張對映表中記錄著三個元素之間的關係。但這些關係完全是人為建立的，需要變化的時候，只是對資料庫中的記錄進行操作，無需改動結構。
許可權分欄表中記錄著系統使用時顯示的分欄。無論是要新增分欄，修改分欄還是減少分欄，也只不過是操作記錄而已。
綜上所述，這樣設計資料庫，系統是完全可以重用的，並且經受得住「變更」考驗的。
總結：此套系統的重點在於，三張實體表牢牢地抓住了系統的核心成分，而兩張對映表完美地對映出三張實體表之間的互動。其難點在於，理解對映表的工作，它記錄著關係，並且實現了「組」操作的概念。而系統總體的設計是本著可以在不同的mis系統中「重用」來滿足不同系統的功能許可權設定。
附錄：許可權管理系統資料表的字段設計
下面我們來看看許可權管理系統的資料庫表設計，共分為六張表，如下圖：
action表：
action表中記錄著系統中所有的動作，以及動作相關描述。
actioncolumn表：
actioncolumn表中記錄著動作的分欄，系統執行時，左側選單欄提供了幾塊不同的功能，每一塊就是乙個分欄，每新增乙個分欄，該表中的記錄就會增加一條,相對應的，左側選單欄中也會新增機乙個欄。
actiongroup表：
actiongroup表記錄著動作所在的組。
groupmanager表：
groupmanager表記錄著管理組的相關資訊，每新增乙個管理組，這裡的記錄就會增加一條。
mastergroup表：
mastergroup表記錄著管理員所在的管理組，由於一名管理員可能同同時屬於多個組，所以該表中關於某一名管理員的記錄可能有多條。
master表：
master表記錄著所有管理員的資訊，每新增乙個管理員，該錶就會增加一條記錄。
使用者 角色 許可權資料庫設計
分類 linux 許可權管理 許可權管理，主要是人員和許可權之間的關係，但是如果讓人員直接和許可權打交道，那麼許可權的賦值 許可權的撤銷以及許可權的變動會非常的麻煩，這樣引入了，角色，給角色賦許可權，然後給使用者分配角色。這個設計主要涉及6張表，使用者表,用於儲存使用者的所有資訊 許可權表，用於儲存...
資料庫角色許可權
use database goexec sp addlogin name 新增登入 exec sp grantdbaccess n name exec sp addrolemember n db owner n name 新增db owner許可權 go 刪除測試使用者 exec sp revoke...
Oracle資料庫的使用者許可權及角色
每個oracle使用者都有乙個名字和口令,並擁有一些由其建立的表 檢視和其他資源。oracle角色 role 就是一組許可權 privilege 或者是每個使用者根據其狀態和條件所需的訪問型別 使用者可以給角色授予或賦予指定的許可權，然後將角色賦給相應的使用者。乙個使用者也可以直接給其他使用者授權。...