IS-A 관계를 데이터베이스에 어떻게 매핑합니까?

다음을 고려하세요:

entity User
{
    autoincrement uid;
    string(20) name;
    int privilegeLevel;
}

entity DirectLoginUser
{
    inherits User;
    string(20) username;
    string(16) passwordHash;
}

entity OpenIdUser
{
    inherits User;
    //Whatever attributes OpenID needs... I don't know; this is hypothetical
}

다른 종류의 사용자 (직접 로그인 사용자 및 OpenID 사용자)는 IS-A 관계를 표시합니다. 즉, 두 유형의 사용자는 모두 사용자입니다. 이제 RDBMS에서이를 나타낼 수있는 몇 가지 방법이 있습니다.

방법 하나

CREATE TABLE Users
(
    uid INTEGER AUTO_INCREMENT NOT NULL,
    name VARCHAR(20) NOT NULL,
    privlegeLevel INTEGER NOT NULL,
    type ENUM("DirectLogin", "OpenID") NOT NULL,
    username VARCHAR(20) NULL,
    passwordHash VARCHAR(20) NULL,
    //OpenID Attributes
    PRIMARY_KEY(uid)
)

두 번째 방법

CREATE TABLE Users
(
    uid INTEGER AUTO_INCREMENT NOT NULL,
    name VARCHAR(20) NOT NULL,
    privilegeLevel INTEGER NOT NULL,
    type ENUM("DirectLogin", "OpenID") NOT NULL,
    PRIMARY_KEY(uid)
)

CREATE TABLE DirectLogins
(
    uid INTEGER NOT_NULL,
    username VARCHAR(20) NOT NULL,
    passwordHash VARCHAR(20) NOT NULL,
    PRIMARY_KEY(uid),
    FORIGEN_KEY (uid) REFERENCES Users.uid
)

CREATE TABLE OpenIDLogins
(
    uid INTEGER NOT_NULL,
    // ...
    PRIMARY_KEY(uid),
    FORIGEN_KEY (uid) REFERENCES Users.uid
)

세번째 방법

CREATE TABLE DirectLoginUsers
(
    uid INTEGER AUTO_INCREMENT NOT NULL,
    name VARCHAR(20) NOT NULL,
    privlegeLevel INTEGER NOT NULL,
    username VARCHAR(20) NOT NULL,
    passwordHash VARCHAR(20) NOT NULL,
    PRIMARY_KEY(uid)
)

CREATE TABLE OpenIDUsers
(
    uid INTEGER AUTO_INCREMENT NOT NULL,
    name VARCHAR(20) NOT NULL,
    privlegeLevel INTEGER NOT NULL,
    //OpenID Attributes
    PRIMARY_KEY(uid)
)

데이터베이스의 다른 곳에서 사용자에 대해 간단한 조인을 수행 할 수 없기 때문에 세 번째 방법이 잘못된 방법이라고 거의 확신합니다.

내 실제 예는 다른 로그인 예를 가진 사용자가 아닙니다. 일반적인 경우에이 관계를 모델링하는 방법에 관심이 있습니다.

방법 2는 올바른 방법입니다.

기본 클래스는 테이블을 가져온 다음 하위 클래스는 추가 필드와 기본 테이블에 대한 외래 키 참조만으로 자체 테이블을 가져옵니다.

Joel 이이 답변에 대한 의견에서 제안한 것처럼 사용자는 키를 입력하는 각 하위 유형 테이블에 유형 열을 추가하여 사용자가 직접 로그인 또는 OpenID 로그인을 가질 수 있지만 둘 다 (또는 둘다는 아님)를 보장 할 수 있습니다. 루트 테이블에. 각 하위 유형 테이블의 유형 열은 해당 테이블의 유형을 나타내는 단일 값을 갖도록 제한됩니다. 이 열은 루트 테이블에 외래 키가 지정되므로 한 번에 하나의 하위 유형 행만 동일한 루트 행에 연결할 수 있습니다.

예를 들어 MySQL DDL은 다음과 같습니다.

CREATE TABLE Users
(
      uid               INTEGER AUTO_INCREMENT NOT NULL
    , type              ENUM("DirectLogin", "OpenID") NOT NULL
    // ...

    , PRIMARY_KEY(uid)
);

CREATE TABLE DirectLogins
(
      uid               INTEGER NOT_NULL
    , type              ENUM("DirectLogin") NOT NULL
    // ...

    , PRIMARY_KEY(uid)
    , FORIGEN_KEY (uid, type) REFERENCES Users (uid, type)
);

CREATE TABLE OpenIDLogins
(
      uid               INTEGER NOT_NULL
    , type              ENUM("OpenID") NOT NULL
    // ...

    PRIMARY_KEY(uid),
    FORIGEN_KEY (uid, type) REFERENCES Users (uid, type)
);

(다른 플랫폼에서는 CHECK대신에 제약 조건을 사용합니다 ENUM.) MySQL 은 복합 외래 키를 지원 하므로이 기능 이 효과적입니다.

NULL사용 가능한 열의 공간을 낭비하고 있지만 사용 방법은 사용자 유형에 따라 다르지만 하나는 유효합니다 . 저장할 유형의 사용자 유형을 확장하도록 선택하고 해당 유형에 추가 열이 필요하지 않은 경우 도메인을 확장 ENUM하고 동일한 테이블을 사용할 수 있다는 장점이 있습니다 .

세 번째 방법은 사용자를 참조하는 모든 쿼리가 두 테이블을 모두 확인하도록합니다. 또한 외래 키를 통해 단일 사용자 테이블을 참조 할 수 없습니다.

그들은 지명 될 것입니다

1. 단일 테이블 상속
2. 클래스 테이블 상속
3. 콘크리트 테이블 상속 .

모두 합법적 인 용도로 사용되며 일부 라이브러리에서 지원됩니다. 가장 적합한 것을 찾아야합니다.

테이블이 여러 개인 경우 데이터 관리가 응용 프로그램 코드에 더 많이 사용되지만 사용되지 않은 공간은 줄어 듭니다.