[php] 보편적 권리 관리 데이터베이스 설계

C/S 시스템보다 B/S 시스템의 권한이 더 중요합니다. C/S 시스템에는 특별한 클라이언트가 있기 때문에 클라이언트 또는 클라이언트를 통해 접근 사용자 권한 감지를 구현할 수 있습니다. 클라이언트 + 서버 감지를 통해 구현됩니다. B/S에서는 모든 컴퓨터에 브라우저가 있습니다. 완전한 권한 감지가 이루어지지 않으면 "불법 사용자"가 브라우저를 통해 모든 기능에 쉽게 접근할 수 있습니다. B/S 시스템에서. 따라서 B/S 비즈니스 시스템에는 액세스 권한 감지를 구현하기 위한 하나 이상의 권한 시스템이 필요합니다. 이를 통해 승인된 사용자는 승인된 기능을 정상적으로 합법적으로 사용할 수 있으며 승인되지 않은 "불법 사용자"는 완전히 "차단"됩니다. 대부분의 B/S 시스템에서 사용자 기능 권한 제어를 만족시킬 수 있는 권한 시스템을 설계하는 방법을 살펴보겠습니다.

요구 사항

• 시스템 운영에 대한 권한은 달라야 합니다. 훌륭한 비즈니스 시스템, 이것이 가장 기본적인 기능입니다.
• 권한은 "그룹"에 할당할 수 있습니다. 대기업 비즈니스 시스템의 경우 관리자가 직원에게 시스템 운영 권한을 하나씩 할당하도록 요구하는 것은 시간이 많이 걸리고 불편합니다. 따라서 시스템은 "그룹"에서 작동하고 동일한 권한을 가진 사람들을 동일한 그룹으로 정리한 다음 해당 그룹에 권한을 할당한다는 개념을 제시합니다.
• 권한 관리 시스템은 확장 가능해야 합니다. 권한 관리 기능이 있는 모든 시스템에 추가할 수 있어야 합니다. 구성 요소와 마찬가지로 관리 시스템이 개발될 때마다 권한 관리 부분을 다시 개발하지 않고 지속적으로 재사용할 수 있습니다.
• 비즈니스 시스템에서 기능 권한을 만나보세요. 기존 비즈니스 시스템에는 두 가지 유형의 권한 관리가 있습니다. 하나는 기능 권한 관리이고, 다른 하나는 서로 다른 시스템 간에 재사용할 수 있는 리소스 권한 관리입니다.

  디자인에 대하여

  NoahWeb의 액션 프로그래밍 개념의 도움으로 설계 단계에서 시스템 설계자는 프로그램 구조의 설계를 고려할 필요가 없으며 프로그램 흐름과 데이터베이스 구조부터 시작합니다. 요구사항을 실현하기 위해서는 데이터베이스의 설계가 매우 중요합니다. "그룹" 운영의 개념이든 전체 권한 관리 시스템의 재사용성이든 모두 데이터베이스.

  먼저 데이터베이스 구조를 분석해 보겠습니다.

  먼저 액션 테이블(이하 "권한 테이블"), 그룹 관리자 테이블(이하 "경영진 테이블"), 마스터 테이블(이하 "인사 테이블") )은 "권한" 정보, "관리 그룹" 정보, "인사" 정보를 차례로 기록하는 세 개의 엔터티 테이블입니다. 아래와 같이

  

  이 세 테이블의 관계는 다대다입니다. 권한은 동시에 여러 관리 그룹에 속할 수 있으며 관리 그룹에는 동시에 여러 권한이 포함될 수도 있습니다. 마찬가지로 한 사람은 동시에 여러 관리 그룹에 속할 수 있으며, 관리 그룹에는 동시에 여러 사람이 포함될 수도 있습니다. 아래와 같이

  

  이 세 가지에는 차이가 있기 때문입니다. 테이블 다대다 관계가 있으므로 두 테이블 간의 상호 작용은 다른 두 테이블을 사용하는 것이 가장 좋습니다. 이 두 테이블은 "actiongroup" 테이블(이하 "권한 매핑 테이블")과 "mastergroup" 테이블(이하 "직원 매핑 테이블")이라는 매핑 역할을 합니다. ) 전자는 권한 테이블과 관리 그룹 테이블 간의 상호 작용을 매핑합니다. 후자는 인사 테이블과 관리 그룹 테이블 간의 상호 작용을 매핑합니다. 아래와 같이

  

  또한 테이블이 필요합니다. . 시스템 실행 시 왼쪽 메뉴의 권한 열, 즉 "권한 열 테이블"을 아래와 같이 제어합니다.

  

  위의 분석을 바탕으로 아래와 같이 데이터베이스 구조를 설계합니다.

  여기를 클릭하세요. 권한 관리 시스템 데이터 보기 테이블 필드 디자인

  

  좋은 분석을 수행하기 위해 데이터베이스 구조 다이어그램을 분할했습니다. 세 엔터티 테이블의 기능은 이미 매우 명확합니다. 이제 두 매핑 테이블의 기능을 살펴보겠습니다.

  권한 매핑 테이블 은 아래와 같습니다.

  먼저 권한 매핑 테이블, 관리 그룹 테이블, 권한 테이블 간의 필드 연관을 살펴보겠습니다.

  

  사진 속 빨간 원을 보세요 먼저 보세요 Gorupid 필드 Correlation에서 실제 데이터베이스에서 이 상관 방법의 성능은 다음과 같습니다.

  

  그림과 같이 관리 그룹 테이블에서 "최고 관리자"의 그룹 ID는 1이고, 권한 매핑 테이블에서는 그룹 ID가 1인 권한이 있습니다. 은 ""최고관리자"가 가지고 있는 권한입니다.

  groupid 필드 연결을 사용하는 것은 관리 그룹이 실행할 수 있는 권한을 알아내는 것입니다. 그러나 이러한 권한에 대한 자세한 정보는 작업 필드 연결을 통해 쿼리됩니다.

  데이터베이스에서 이와 연관된 작업 필드는 다음과 같이 작동합니다.

  

  이 연관을 통해 권한 매핑 테이블에 있는 해당 권한의 세부 정보를 쿼리할 수 있습니다. . 종합해보면, 관리 그룹이 수행할 수 있는 권한과 이러한 권한의 세부 사항이 무엇인지 알 수 있습니다.

  actionid 필드를 사용하여 연결하는 것이 어떨까요? 이유:

  • 권한 테이블 의 id 필드는 여러 데이터베이스 작업 후에 변경될 수 있습니다.
  • 권한 매핑 테이블에는 관리 그룹이 실행할 수 있는 권한만 기록됩니다.
  • 권한 테이블의 ID가 변경되면 권한 매핑 테이블의 레코드도 변경됩니다.
  • 관리 그룹이 실행할 수 있는 권한은 잘못될 수밖에 없으며 이는 매우 바람직하지 않습니다.

    위의 상황을 고려할 때 액션 필드를 사용하여 연결해야 하는 이유는 다음과 같습니다.

    • 권한 테이블에서 ID는 변경될 수 있지만 작업 필드는 어떠한 경우에도 변경할 수 없습니다.
    • 권한 매핑 테이블에 기록된 작업 필드는 변경되지 않습니다.
    • 관리 그룹이 실행할 수 있는 권한은 잘못되지 않습니다.

      2인 매핑 테이블은 아래와 같습니다.

      사람 매핑 테이블과 관리 그룹 테이블과

      을 살펴보겠습니다.

      인사 테이블 간의 현장 연관성은 다음과 같습니다. 아래 표시:

      

      사진을 보세요 빨간색 원 부분을 먼저 보면 groupid 필드 협회의 데이터베이스 성과는 다음과 같습니다.

      

      그림과 같이 "최고 관리자" 그룹의 그룹 ID는 1입니다. 직원 매핑을 살펴보겠습니다. 테이블. Admin은 최고 관리자 그룹에 속하고, 관리자는 최고 관리자 그룹에 속합니다.

      이 상관 방법을 사용하는 것은 관리 그룹에 누가 있는지 알아내는 것입니다. 위와 같이 id 필드(person 매핑 테이블의 masterid 필드)와 연관시켜 담당자의 상세정보를 조회하게 된다.

      id 필드(사람 매핑 테이블의 masterid 필드)는 데이터베이스에 다음 형식으로 표시됩니다. 다음 그림 중 :

      

      한 사람이 동시에 여러 "관리 그룹"에 속할 수 있습니다. 사진, 관리자 동시에 두 개의 "관리 그룹"에 속해 있습니다. 따라서 인사 매핑 테이블에는 관리자에 대한 두 개의 기록이 남게 됩니다.

      이 상관 방법을 사용하면 관리 그룹에 속한 사람들의 세부 정보를 쿼리할 수 있습니다. 이를 종합하면 관리 그룹에 누가 속해 있는지, 해당 인물에 대한 자세한 정보를 알 수 있습니다.

      위에서 언급한 권한 테이블과 권한 매핑 테이블을 결합하여 " 요구 사항의 그룹" 작업은 아래와 같이 구현됩니다.

      

      사실 관리 그룹 테이블에는 이름, 그룹 ID 등 그룹의 기본 정보만 기록되어 있습니다. 그룹에 속한 사람들의 세부정보와 그룹이 수행할 수 있는 권한의 세부정보는 인사표와 권한표에 기록됩니다. 두 개의 매핑 테이블은 실제로 그룹에 속한 사람과 이들이 수행할 수 있는 권한을 기록합니다. 두 개의 매핑 테이블의 연결을 통해 세 개의 엔터티 테이블 간의 상호 작용이 구현될 수 있으며 요구 사항 에 언급된 "그룹" 작업이 완료됩니다.

      권한 열 표와 권한 표 상호작용. 이 두 테이블 간의 필드 관계는 다음과 같습니다.

      

      두 테이블은 actioncolumnid 필드를 사용하여 연관되어 있습니다. 데이터베이스에서 이 연결의 성능은 다음과 같습니다.

      

      그림과 같이 이러한 상관관계 방식을 통해 권한 테이블의 권한이 어느 열에 속하는지 매우 명확하게 알 수 있습니다.

      이제 데이터베이스 구조가 매우 명확해지고 권한 할당 기능과 "그룹" 작업이 구현되었습니다. 다음으로 권한 관리 시스템 요구사항에 언급된 재사용성 문제를 분석해 보겠습니다.

      왜 이런 데이터베이스 설계 방식으로 구축한 시스템을 재사용할 수 있나요?

      • 세 개의 엔터티 테이블은 시스템의 세 가지 결정적인 요소를 기록합니다. "권한", "그룹" 및 "사람". 이 세 가지 요소는 서로 영향을 주지 않고 마음대로 추가할 수 있습니다. 어떤 비즈니스 시스템이든지 이 세 가지 결정적인 요소는 변하지 않습니다. 즉, 구조는 변하지 않고 데이터만 변한다는 의미입니다.
      • 두 매핑 테이블은 세 요소 간의 관계를 기록합니다. 그러나 이러한 관계는 완전히 인위적으로 생성되어 변경이 필요한 경우 구조를 변경하지 않고 데이터베이스의 레코드만 작동합니다.
      • 권한 열 테이블에는 시스템 사용 시 표시되는 열이 기록됩니다. 열을 추가하든, 열을 수정하거나, 줄이든 그것은 단지 작업 기록일 뿐입니다.

        요약하자면, 데이터베이스를 이런 식으로 설계하면 시스템이 완전히 재사용 가능하고 견딜 수 있습니다. "변경" 테스트.

        요약:

        이 시스템의 핵심 즉, 세 개의 엔티티 테이블은 시스템의 핵심 구성 요소를 확실하게 포착하고, 두 개의 매핑 테이블은 세 개의 엔터티 테이블 간의 상호 작용을 완벽하게 매핑합니다. 관계를 기록하고 "그룹" 작업의 개념을 구현하는 매핑 테이블의 작동을 이해하는 데 어려움이 있습니다. 시스템의 전반적인 디자인은 다양한 시스템의 기능적 권한 설정을 충족하기 위해 다양한 MIS 시스템에서 "재사용"될 수 있다는 아이디어를 기반으로 합니다.

        부록:

        권리관리 시스템 데이터 테이블 현장 설계

        다음과 같이 6개의 테이블로 나누어진 권한 관리 시스템의 데이터베이스 테이블 디자인을 살펴보겠습니다.

        작업 테이블:

        

        액션 테이블에는 시스템 내 모든 액션과 액션에 관련된 설명이 기록됩니다.

        액션 열 테이블:

        

        액션 컬럼 테이블은 시스템이 실행 중일 때 여러 가지 기능을 제공합니다. 각 컬럼은 컬럼이 추가될 때마다 테이블에 기록됩니다. 하나를 추가하면 왼쪽 메뉴 표시줄에 새 열이 추가됩니다.

        액션 그룹 테이블:

        

        actiongroup 테이블에는 해당 액션이 위치한 그룹이 기록됩니다.

        그룹 관리자 테이블:

        

        groupmanager 테이블에는 관리 그룹이 추가될 때마다 여기에 하나의 레코드가 추가됩니다.

        마스터 그룹 테이블:

        

        마스터 그룹 테이블에는 관리자가 속한 관리 그룹이 기록됩니다. 관리자는 동시에 여러 그룹에 속할 수 있으므로 테이블에는 관리자에 대한 레코드가 여러 개 있을 수 있습니다.

        마스터 테이블:

        

        마스터 테이블에는 모든 관리자의 정보가 기록됩니다. 관리자가 추가될 때마다 테이블에 기록이 추가됩니다.

      위 내용은 내용의 측면을 포함하여 [php] 범용 권한 관리 데이터베이스 디자인을 소개한 내용이 PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.