3~6은 각각 다른 데이터가 아니다. 모두 서로 연관된 데이터다.

(실제 온라인 쇼핑몰의 DB를 기반으로 만들어진 문제)

1. 화살표의 방향을 보자. 참조하고 있는 대상을 가리키고 있다. 즉, Seller 테이블의 'UserID'는 User 테이블의 'UserID'를 참조하고 있다.

2. 그렇다면 1번은 PK가 되고, 2번과 3번은 PK, FK가 된다.
(내가 답을 제출할 때 생각했던 개념은, PK, FK로 지정해야 할 것 같긴 하지만 어차피 PK는 중복되지 않고, 자식 테이블은 부모 테이블의 PK를 참조만 하는 것이기 때문에 부모 테이블의 PK 개체 무결성 제약을 믿고 그냥 FK로만 사용하는게 관리상 이점이 있을거라 생각했다. 하지만 그럴 경우 문제가 정상적인 사용에서는 문제가 없지만 Consumer 테이블이나 Seller 테이블에 억지로 UserID가 중복되는 데이터를 밀어 넣을 경우 데이터가 망가지는 문제가 발생한다. 따라서 PK도 함께 지정해주는게 좋다고 한다.)

 

1. 여기서는 5번 Consumer 테이블의 UserID가 왜 PK, FK인지를 아는 것이 핵심이다. 대부분 3 ~ 6번 문제를 각각 분리된 문제로 생각했기 때문에 5번을 단순한 PK라고 답을 하게 된다. 하지만 위에 3번 문제를 보자. 저기 있는 Consumer 테이블이 여기 있는 Consumer 테이블이다.

 

1. 5번 문제도 4번 문제와 마찬가지다. 따라서 Seller 테이블의 UserID는 PK, FK가 된다.

2. 6번 문제에서도 마찬가지다. 위에서 정리한 개념들을 모두 종합하면, 1번은 PK, FK가 된다. (위에 3번 문제의 Consumer 테이블이다.)

    2번과 3번을 모두 PK로 할 경우 : 모든 유저는 각 상품에 댓글을 하나만 달 수 있다.
    2번만 PK로 할 경우 : 모든 유저는 각 상품에 댓글을 무제한으로 달 수 있다.
    3번만 PK로 할 경우 : 각 상품은 최초 댓글 작성자의 1개의 댓글만 달 수 있다. (작성자는 어떤 유저나 가능하다. 각 상품별 선착순일 뿐...)

    따라서 2번은 우선 User 테이블의 UserID를 참조했을 것이니 FK가 되고, 여기서는 PK로 지정하는 것이 가장 이상적이다.
    그리고 3번은 FK로만 지정하는 것이 가장 이상적이다.

    마지막으로 4번은 위 5번 문제에 의해 PK다.

+ Recent posts