需求分析---場景
假設需要為公司設計一個人員管理系統，并為各級上司及全體員工配置設定系統登入賬号。有如下幾個要求：
1. 權限等級不同：公司上司登入後可檢視所有員工資訊，部門上司登入後隻可檢視本部門員工的資訊，員工登入後隻可檢視自己的資訊；
2. 通路權限不同：如公司上司登入後，可檢視員工薪水分布界面，而員工則不能看到；
3. 操作權限不同：如系統管理者可以在資訊釋出界面進行增删改查釋出資訊，而普通員工隻可以在資訊釋出界面進行檢視，不能修改、删除和新增。
功能分析
1. 登入一個系統，基本都需要使用者輸入使用者名、密碼；
2. 每個使用者的角色不同，則其通路權限一般也不同，如：
系統管理者：可以檢視所有界面；
普通使用者：隻能檢視部分界面。
3. 不同的使用者，即使可以檢視同樣的界面，但在該界面上可進行的操作權限也不同，如：
使用者1：可以在界面1上進行增删改查；
使用者2：隻可以在界面1上檢視，不具備增删改功能；
4. 不同使用者基本都對應不同角色，如：使用者1、使用者2分别對應管理者角色、操作員角色，角色之間也存在權限等級的差異，如：
角色1：對應省級管理者；==>可以檢視該省下的所有學校資訊；
==>可以檢視該市下的所有學校資訊；
==>可以檢視該縣下的所有學校資訊；
不管是省、市、縣哪個系統管理者，他們可通路的界面都是相同的（即通路權限相同），且在每個界面上可進行的操作權限也相同的，不同的是每個管理者角色可以通路的學校個數和學校範圍不同，這裡稱這種不同為：權限等級不同；
總結：
從上面的分析中，主要涉及到以下幾個概念：
1.角色：
如系統管理者角色，系統操作員角色，普通使用者角色；
不同的角色，其通路權限是不同的，即可通路的子產品（界面）集合是不同的；
角色的權限等級也不同，權限等級如：公司上司、部分上司、普通員工；
2. 子產品：（界面）
子產品就是指具體的界面，每個子產品上又有不同的操作，如增删改查；
3. 通路權限：确定角色可以通路的子產品（界面）集合；
4. 操作權限：确定可以在各子產品（界面）上進行的操作集合，如增删改查；
5. 權限等級：即确定角色可以通路的範圍，如：
角色1：權限等級為公司上司，則可以檢視公司所有員工資訊；
角色2：權限等級為部門上司，則隻可以檢視該部門所有員工資訊。
資料庫設計
總體模型：
1.子產品定義表：
子產品是分層級的，如：資訊管理-->聯系方式管理；
每個子產品都有上級子產品。
2. 角色定義表：
含有角色權限等級，用于為角色配置設定權限等級；
角色權限等級：是一個菜單選項，包括公司上司、部門上司、普通員工；
3.授權定義表：
用于給角色配置設定通路權限以及為每個子產品配置設定操作權限；
1個角色可以含有多個子產品，同樣1個子產品可以配置設定給多個角色，是以角色和子產品是多對多的關系；這種多對多的關系可以使用關系表來實作，即通過聯合主鍵和實作關系表：
表中含有字段“操作權限”，用于給每個界面配置設定操作權限，見下圖：
若該子產品有增删改查功能，則操作權限15，即二進制的“1111”，若該子產品隻有檢視功能，則操作權限為2，即二進制的“0010”，同樣的，“0111”表示該子產品有增、改、查功能；
4. 系統使用者表：
該表中“角色權限等級”--->應與“所屬角色”中的權限等級保持一緻，之是以該表中重複該字段，是為了友善查詢。
角色權限等級取值：
1. 公司上司：company_id不能為空；
company_id、dept_id不能為空；
company_id、dept_id、staff_id不能為空；
登入執行過程
1. 系統登入時，首先輸入使用者名、密碼；
2. 确定通路權限：
2.1 判斷該使用者的“角色編号”；
2.2 在“授權定義表”中根據該“角色編号”查找相應的子產品，找到的子產品集合即是通路權限；
3. 确定操作權限：
操作權限，即構成了每個子產品的操作權限；
4. 确定權限等級：
4.1 結合該使用者的“角色權限等級”+“公司辨別”+“部門辨別”+“員工辨別”，到員工資訊表中去查找相應員工，具體如下：
角色權限等級取值：
員工資訊表.公司辨別==該使用者.公司辨別>的所有使用者；
查找<員工資訊表.公司辨別==該使用者.公司辨別 &&
員工資訊表.部門辨別==該使用者.部門辨別>的所有使用者；
查找<員工資訊表.公司辨別==該使用者.公司辨別 &&
員工資訊表.部門辨別==該使用者.部門辨別 &&