2014-05-25 4 views
0

(웹 기반 응용 프로그램 시나리오)데이터베이스 설계

나는 다음과 같은 조건이 주어진 문제를 해결하기 위해 노력하고 있어요 :

  1. 사용자 테이블과 user_contact 테이블이 있어야한다 모든 정보가 들어 있습니다. 직원과 환자는 세부 정보를 상속 받아 환자 테이블을 성 및 이름과 직원 테이블로 중복시키는 것을 제거합니다.

  2. 환자 테이블이 family_id에 의해 참조되어 가족 구성원을 그룹화하는 패밀리 테이블이 있습니다.

지금. 나는 다음 조건에서 혼란 스럽다.

계정은 환자 당이 아니라 가족 당 발행된다. 한 가족의 환자가 동일한 사용자 이름과 암호를 사용합니다. 가족에 사용자 이름과 암호 속성을 넣으면 직원의 사용자 이름과 암호도 입력해야합니다. 나는 항상 테이블에서 중복을 피하도록 가르쳐왔다. 나는 마지막 조건을 위해 테이블을 구성하는 데 정말로 어려움을 겪고있다.

어떻게 해결할 수 있습니까? Account라는 테이블을 작성하고 속성 (ID, 사용자 이름, 암호)을 가지고 그것을 family 테이블과 staff 테이블에서 외래 키로 참조해야합니까?

또는

은 내가 속성 (ID, 사용자 이름, 암호, staff_id, family_id, 유형)과 테이블라는 이름의 계정을 만들어야합니다. 이 설계에서는 staff_id 또는 family_id 중 하나의 속성이 참조 된 상위 테이블에 대한 값이 없으므로 항상 제약 조건을 반환하는 null이 될 것이므로 이것이 좋은지 잘 모르겠습니다.

또는이 옵션을 사용하면 더 좋은 방법이 있습니다.

도움을 주시면 감사하겠습니다.

답변

1

필자는 항상 테이블에서 중복을 피하도록 가르쳐 왔습니다.

당신은 잘 가르쳐졌습니다.

암호 테이블을 만드십시오.

Password 
-------- 
User ID 
Password 
Account or Staff value 
Account or Staff ID 

암호 는 소금과 암호화해야합니다. 이 값은 ID가 가족 권한이있는 계정인지 아니면 스태프 권한이있는 스태프인지를 알려줍니다.

두 개 이상의 값이 필요하다면 Value 클래스를 만들어야합니다.

Value 
----- 
Value ID 
Value Name 

아마도 값 권한 클래스 일 수 있습니다.

Value Permission 
---------------- 
Value ID 
Permission ID 

Permission 
---------- 
Permission ID 
Permission 

이것은 응용 프로그램에 너무 미세 할 수 있습니다.

기억하십시오.각 테이블에 키, 전체 키 및 키와 관련된 값이 포함되어 있으면 수천 개의 테이블을 만들 수 있으므로 Codd에 도움이됩니다.

+0

감사합니다. @ Gilbert는 암호가 암호화되고 소금에 절식되어야한다고 지적했습니다. 추가 테이블 "Account"를 추가하여 사용자 이름을 저장 한 다음 password_id – MLDS

+0

을 참조 할 것입니다. 암호 테이블의 기본 키가 user_id 인 경우. 사용자가 가족 구성원 인 경우 (성이 동일한 다른 사용자가 등록 된 상태) 나는 그때 문제가 발생할 것이라고 생각합니다. 계정 ID를 사용자 테이블에 참조하는 것이 더 나은가? 이 경우 사용자의 모든 계정은 계정 ID – MLDS

+0

으로 식별 할 수 있습니다. @MLDS : 가족에 한 명의 사용자 ID가 있다고 생각했습니다. 계정 ID라고하면 그럴 수 있습니다. –

1

잘못 정의되거나 잠재적으로 유체 요구 사항을 처리하는 데 가장 적합한 데이터베이스 구조가 무엇인지 확실하지 않을 때마다 가장 좋은 방법은 관심있는 각 항목 (유형 또는 유형)을 엔티티/테이블로 처리하는 것입니다 .

귀하의 경우 계정이 있습니다. 일부 계정은 직원에게 할당됩니다. 일부 계좌는 가족에게 할당됩니다. 앞으로 가족 계좌가 다른 종류의 개인이나 그룹에 배정 될 수 있습니까? 무엇을하든, 계정에는 항상 사용자 ID 및 암호와 같은 안정된 속성이 있습니다. 그러므로 계정 테이블을 만드십시오.

그런 다음 다른 엔티티와 계정을 연결하는 방법을 알아야합니다. 제 생각에는 가족 테이블과 직원 테이블이 서로 다른 점을 지적하기를 원할 것입니다. 그것이 가장 합리적인 것입니다. 최소한 상사가 직원이나 가족 당 여러 계정을 허용하는 새로운 요구 사항에 대해 알려줄 때까지 ...

+0

여기에 조금 혼란스럽게해서 죄송합니다. 나는 단지 설명하기를 원합니다. 내 가족 테이블과 직원 테이블에 자신의 계정을 참조하는 foreign_key_account를 포함해야합니까? 그리고, 나는 그들의 세부 사항과 사용자 테이블이 있습니다. 계정 테이블을 사용자 테이블에 연결하는 것이 더 좋습니까? – MLDS

+0

@MLDS - 예, family 테이블과 staff 테이블 각각에 'account_id'가 있습니다. 'USER' 테이블 대'ACCOUNT' 테이블에 관해서는, 실제로 구별하는지 여부에 대해 신중히 생각하십시오. 한 명의 실제 사용자 (사용자)가 잠재적으로 많은 계정을 열 수 있습니다. 그러나 귀사는 _ 실제적으로 실제 사용자와 로그인을 구별하고 싶습니까? 나는 대부분의 조직이 사람들에 대해 정말로 신경 쓰지 않는다는 것을 발견했다. 내가 참여한 대부분의 장소는 로그인 ID에서 실제로 멈 춥니 다. USER와 ACCOUNT를 하나의 테이블로 결합하고자 할 수 있습니다. –

+0

그건 원래 내가 한 일이었습니다. 그러나 요구 사항을 준수하기 위해 모든 환자가 단일 계정을 가지고있는 것은 아닙니다. 그들이 가족 그룹에 속하면 같은 계정을 갖게됩니다. – MLDS