비즈니스 시스템에서 사용자 권한 관리를 구현합니다
B/S 시스템의 권한은 C/S의 권한보다 더 중요합니다. C/S 시스템에는 특수 클라이언트가 있으므로 액세스 사용자의 권한 감지는 클라이언트 또는 클라이언트 + 서버 감지를 통해 구현할 수 있습니다. B/S에서는 모든 컴퓨터에서 브라우저를 이미 사용할 수 있습니다. 완전한 권한 탐지가 설정되지 않은 경우 "불법 사용자"는 브라우저를 통해 B/S 시스템의 모든 기능에 쉽게 액세스 할 수 있습니다. 따라서 B/S 비즈니스 시스템은 액세스 권한 감지를 구현하기 위해 하나 이상의 권한 시스템이 있어야하므로 승인 된 사용자는 공인 기능을 정상적으로 및 법적으로 사용할 수 있으며 무단 "불법 사용자"는 완전히 "거부"합니다. 대부분의 B/S 시스템에서 사용자 기능 권한의 제어를 충족 할 수있는 권한 시스템을 설계하는 방법을 살펴 보겠습니다.
요구 사항 명세서
• 책임이 다른 직원은 시스템 운영에 대해 다른 권한이 있어야합니다. 우수한 비즈니스 시스템, 이것은 가장 기본적인 기능입니다.
• 그룹에 권한을 할당 할 수 있습니다. 대기업의 비즈니스 시스템의 경우 관리자에게 시스템 운영 권한을 직원에게 하나씩 할당하도록 요청하는 것은 시간이 많이 걸리고 불편합니다. 따라서 시스템은 "그룹"에서 운영하는 개념을 제안하고 동일한 그룹에 일관된 권한을 가진 사람들을 구성한 다음 그룹에 권한을 할당합니다.
• 권한 관리 시스템은 확장 가능해야합니다. 권한 관리 기능으로 모든 시스템에 가입 할 수 있어야합니다. 구성 요소와 마찬가지로 개발 된 모든 관리 시스템에 대한 권한 관리 부품을 재개발하는 대신 지속적으로 재사용 할 수 있습니다.
• 비즈니스 시스템에서 기능적 권한을 충족하십시오. 기존 비즈니스 시스템에는 두 가지 유형의 권한 관리가 있습니다. 하나는 기능적 권한 관리이고 다른 하나는 자원 권한 관리입니다. 다른 시스템 간에는 기능적 권한을 재사용 할 수 있지만 리소스 권한은 할 수 없습니다.
디자인에 대해
Noahweb의 액션 프로그래밍 개념의 도움으로 설계 단계에서 시스템 설계자는 프로그램 구조의 설계를 고려할 필요가 없지만 프로그램 흐름 및 데이터베이스 구조부터 시작하십시오. 요구 사항을 실현하려면 데이터베이스의 설계가 매우 중요합니다. "그룹"운영의 개념이든, 전체 권한 관리 시스템 세트의 재사용 성이든 데이터베이스 설계에 있습니다.
먼저 데이터베이스 구조를 분석하겠습니다.
먼저, 액션 테이블 ( 이하 "권한 테이블"이라고 함 ), Gorupmanager 테이블 ( 이하 "관리 그룹 테이블이라고 함 ) 및 마스터 테이블 ( 이하"인사 테이블이라고 함 )은 "관리 그룹"의 정보를 기록하는 세 가지 엔터티 테이블, "관리 그룹"의 정보를 기록하는 세 가지 엔터티 테이블입니다. 아래 그림과 같이 :
이 세 테이블 사이의 관계는 다수입니다. 한 번의 허가는 동시에 여러 관리 그룹에 속할 수 있으며, 하나의 관리 그룹은 동시에 여러 권한을 포함 할 수도 있습니다. 마찬가지로, 사람은 동시에 여러 관리 그룹에 속할 수 있으며 관리 그룹은 동시에 여러 직원을 포함 할 수도 있습니다. 아래 그림과 같이 :
이 세 테이블 사이에는 다량의 관계가 있기 때문에 다른 두 테이블을 사용하여 상호 작용을 완료하는 것이 가장 좋습니다. 이 두 테이블은 매핑 역할, 즉 "ActionGroup"테이블 (이하 "권한 매핑 테이블") 및 "마스터 그룹"테이블 (이하 "인사 매핑 테이블"이라고 함)을 재생합니다. 전자는 권한 테이블과 관리 그룹 테이블 사이의 상호 작용을지도합니다. 후자는 인사 테이블과 관리 그룹 테이블 사이의 상호 작용을지도합니다. 아래 그림과 같이 :
또한 아래 그림과 같이 시스템 실행 시간의 왼쪽 메뉴에서 권한 열을 제어하기 위해 테이블도 필요합니다.
위의 분석을 기반으로 아래 그림과 같이 데이터베이스 구조 설계를 수행합니다.
권한 관리 시스템 데이터 테이블 필드 디자인을 보려면 여기를 클릭하십시오.
좋은 분석을 수행하기 위해 데이터베이스 구조 차트를 분할합니다. 세 엔티티 테이블의 역할은 이미 매우 명확합니다. 이제 두 개의 매핑 테이블의 역할을 살펴 보겠습니다.
권한 매핑 테이블은 다음과 같습니다.
먼저 권한 매핑 테이블 과 관리 그룹 테이블 과 권한 테이블 사이의 현장 연관성을 살펴 보겠습니다.
그림에서 빨간 원을 보면 먼저 Gorupid 필드의 연관성을보십시오. 실제 데이터베이스 에서이 연관 방법의 성능은 다음과 같습니다.
그림과 같이, 관리 그룹 테이블 의 "Super Administrator"그룹은 1이므로 권한 매핑 테이블 에서 GroupId의 허가는 "슈퍼 관리자"가 소유 한 권한입니다.
GroupId Field Association을 사용하여 관리 그룹이 실행할 수있는 권한을 찾으십시오. 그러나 이러한 권한의 자세한 정보는 Action Field Association에서 찾을 수 있습니다.
데이터베이스의 조치 필드의 동작은 다음과 같습니다.
이 연관성을 통해서만 권한 매핑 테이블 의 해당 권한에 대한 자세한 정보를 찾을 수 있습니다. 요약하면, 우리는 관리 그룹이 실행할 수있는 권한과 이러한 권한의 세부 사항을 알고 있습니다.
어쩌면 당신은 왜 ActionID 필드를 사용하여 연관시키지 않습니까? 왜냐하면:
• 권한 테이블의 ID 필드는 여러 데이터베이스 작업 후에 변경 될 수 있습니다.
• 권한 맵 테이블은 한 관리 그룹이 실행할 수있는 권한 만 기록합니다.
• 권한 테이블의 ID가 변경되면 권한 맵 테이블의 레코드도 변경됩니다.
• 관리 그룹이 실행할 수있는 권한에 오류가 발생하며 이는 매우 바람직하지 않습니다.
위의 상황을 고려할 때 작업 필드는 다음과 같은 이유가 있어야합니다.
• 권한 테이블에서 ID가 변경 될 수 있지만 어떤 상황에서도 조치 필드가 변경 될 수 없습니다.
• 권한 맵 테이블에 기록 된 액션 필드는 변경되지 않습니다.
• 관리 그룹이 실행할 수있는 권한에 오류가 없습니다.
2 인 매핑 테이블은 다음과 같습니다.
아래 그림과 같이 인사 매핑 테이블 , 관리 그룹 테이블 및 인사 테이블 간의 현장 연관성에 대해 알아 보겠습니다.
그림의 빨간 원 부분을보고 먼저 GroupId Field Association을보십시오. 이 연관 방법은 아래 그림과 같이 데이터베이스에서 수행됩니다.
그림과 같이, "슈퍼 관리자"그룹의 그룹은 1입니다. 인사 매핑 테이블을 살펴 보겠습니다. 관리자는 슈퍼 관리자 그룹에 속하되고 관리자는 슈퍼 관리자 그룹에 속하며 관리자 그룹에 속합니다.
이 협회 방법은 관리 그룹에 누가 있는지 알아내는 데 사용됩니다. 위와 같이, 사람의 자세한 정보는 ID 필드 ( 인사 매핑 테이블 의 MasterId 필드)와 관련하여 쿼리됩니다.
ID 필드 ( 인사 매핑 테이블 의 MasterId 필드)는 아래 그림과 같이 데이터베이스와 관련이 있습니다.
사람은 동시에 여러 "관리 그룹"에 속할 수 있습니다. 그림에서 볼 수 있듯이 관리자는 동시에 두 "관리 그룹"에 속합니다. 따라서 인사 매핑 테이블 의 관리자에 대한 두 가지 레코드가 있습니다.
이런 식으로 만 관리 그룹의 직원의 자세한 정보를 쿼리 할 수 있습니다. 그것을 결합함으로써 우리는 누가 관리 그룹에 있는지,이 직원의 자세한 정보를 알 수 있습니다.
위에서 언급 한 권한 테이블 및 권한 매핑 테이블을 결합하여 요구 사항의 "그룹"작업은 아래 그림과 같이 실현됩니다.
실제로, 관리 그룹 테이블은 그룹의 사람들의 세부 사항과 그룹이 실행할 수있는 권한의 세부 사항과 관련하여 그룹의 기본 정보 만 기록하며, 인사 테이블 및 권한 테이블 에 기록됩니다. 두 개의 매핑 테이블 만 실제로 그룹의 사람들이 어떤 사람인지, 어떤 권한을 실행할 수 있는지 기록합니다. 두 맵핑 테이블의 연결을 통해서만 세 엔티티 테이블 사이의 상호 작용을 실현하여 요구 사항에 언급 된 "그룹"작업을 완료 할 수 있습니다.
권한 열 테이블 과 권한 테이블 사이의 상호 작용을 살펴 보겠습니다. 이 두 테이블 사이의 필드는 다음과 같습니다.
두 테이블은 ActionColumnid 필드를 사용하여 연결합니다. 데이터베이스의 관계 방법은 다음 그림에 나와 있습니다.
그림과 같이,이 연관 방법을 통해, 권한 테이블 의 권한이 속한 어떤 열이 있는지 명확하게 확인할 수 있습니다.
이제 데이터베이스 구조가 매우 명확하며 권한을 할당하는 기능 및 "그룹"작업이 구현되었습니다. 요구 사항에 언급 된 권한 관리 시스템의 재사용 문제를 분석하겠습니다.
이 데이터베이스 설계 방법을 사용하여 구축 된 시스템을 재사용 할 수있는 이유는 무엇입니까?
시스템의 세 가지 결정적인 요소가 3 개의 엔티티 테이블에 기록됩니다. "권한", "그룹"및 "사람". 이 세 가지 요소는 서로의 영향을받지 않고 마음대로 추가 할 수 있습니다. 어떤 유형의 비즈니스 시스템이든,이 세 가지 결정적인 요소는 변경되지 않으므로 구조가 변경되지 않지만 데이터 만 변경됩니다.
세 요소 사이의 관계는 두 맵핑 테이블에 기록됩니다. 그러나 이러한 관계는 사람이 완전히 만들어집니다. 변경이 필요한 경우 구조를 변경하지 않고 데이터베이스의 레코드에서만 작동합니다.
권한 열 테이블은 시스템이 사용될 때 표시된 열을 기록합니다 . 열을 추가하거나 열을 수정하거나 열을 줄이려면 작업 레코드 일뿐입니다.
요약하면, 이러한 방식으로 데이터베이스를 설계하여 시스템을 완전히 재사용 할 수 있으며 "변경"테스트를 견딜 수 있습니다.
요약 :
이 시스템의 핵심은 세 가지 물리적 테이블 이 시스템의 핵심 구성 요소를 단단히 파악하고 두 개의 맵핑 테이블이 세 가지 물리적 테이블 사이의 상호 작용을 완벽하게 매핑한다는 것입니다. 어려움은 매핑 테이블의 작업을 이해하는 데 있습니다.이 작업은 관계를 기록하고 "그룹"작업의 개념을 구현합니다. 시스템의 전반적인 설계는 다른 MIS 시스템에서 "재사용"하여 다른 시스템의 기능적 권한 설정을 충족하는 것입니다.
충수:
권한 관리 시스템 데이터 테이블의 현장 설계
아래 그림과 같이 6 개의 테이블로 나뉘어 진 허가 관리 시스템의 데이터베이스 테이블 설계를 살펴 보겠습니다.
액션 테이블 :
액션 테이블은 시스템의 모든 작업 및 작업 관련 설명을 기록합니다.
ActionColumn 테이블 :
ActionColumn 테이블은 액션 열을 기록합니다. 시스템이 실행될 때 왼쪽 메뉴 표시 줄은 여러 가지 기능을 제공합니다. 각 블록은 열입니다. 각 열이 추가되고 테이블의 한 레코드가 추가됩니다. 이에 따라 새 열이 왼쪽 메뉴 표시 줄에 추가됩니다.
ActionGroup 테이블 :
ActionGroup 테이블은 액션이 위치한 그룹을 기록합니다.
GroupManager 테이블 :
GroupManager 테이블은 관리 그룹에 대한 관련 정보를 기록합니다. 추가 된 각 관리 그룹에 대해 여기에 한 레코드가 추가됩니다.
마스터 그룹 테이블 :
마스터 그룹 테이블은 관리자가 위치한 관리 그룹을 기록합니다. 관리자는 동시에 여러 그룹에 속할 수 있으므로 표에 관리자에 대한 여러 레코드가있을 수 있습니다.
마스터 테이블 :
마스터 테이블은 모든 관리자의 정보를 기록합니다. 추가 된 각 관리자에 대해 테이블에 레코드가 추가됩니다.
Java의 위의 일반 권한 관리 설계 (권장)는 내가 공유하는 모든 콘텐츠입니다. 나는 당신이 당신에게 참조를 줄 수 있기를 바랍니다. 그리고 당신이 wulin.com을 더 지원할 수 있기를 바랍니다.