SQL 개발자 (SQLD) 데이터 모델링의 이해 핵심정리

IE 표기법에서는 엔터티 쪽 선 끝 모양이 '상대 인스턴스 하나에 이 엔터티가 몇 개 연결되는지'를 나타냅니다.

1. 사원 쪽 끝: 동그라미(0) + 까마귀발(여럿) → 한 부서에 사원이 0명 이상(없을 수도, 여러 명일 수도) 있습니다.
2. 부서 쪽 끝: 세로선 두 개(꼭 1) → 한 사원은 반드시 한 부서에 소속됩니다.

틀린 선지

• 한 사원은 여러 부서에 동시에 소속될 수 있다: 부서 쪽 끝에 까마귀발이 없으므로 한 사원은 부서 하나에만 소속됩니다.
• 한 부서에는 사원이 반드시 한 명 이상 있어야 한다: 사원 쪽 끝에 동그라미가 있으므로 사원이 없어도 되는 '선택' 관계입니다. 반드시 있으려면 동그라미 대신 세로선이 있어야 합니다.
• 한 사원은 부서에 소속되지 않아도 된다: 부서 쪽 끝은 세로선 두 개(꼭 1개)라서 모든 사원은 반드시 한 부서에 소속됩니다.

데이터 모델링은 개념적 → 논리적 → 물리적 순서로 진행합니다. 처음 단계인 개념적 데이터 모델링은 세부 속성보다 업무의 핵심 엔터티와 관계를 크게 그리는 단계라서 추상화 수준이 가장 높습니다. 뒤로 갈수록 점점 구체적이 됩니다.

틀린 선지

• 프로세스 모델링: 데이터가 아니라 업무 처리 흐름을 그리는 작업으로, 데이터 모델링 단계가 아닙니다.
• 논리적 데이터 모델링: 키·속성·관계를 자세히 정하고 정규화를 하는 단계로, 개념적 모델링보다 구체적입니다.
• 물리적 데이터 모델링: 테이블·인덱스·저장 공간까지 정하는 가장 구체적인 단계입니다.

물리적 데이터 모델링은 논리 모델을 실제 DBMS 에 만들 수 있게 바꾸는 마지막 단계입니다. 테이블과 컬럼의 데이터 형식, 인덱스, 저장 공간처럼 성능과 저장에 관한 것을 정합니다.

틀린 선지

• 개념적 데이터 모델링: 핵심 엔터티와 관계를 크게 그리는 첫 단계입니다.
• 논리적 데이터 모델링: 키·속성·정규화를 정하는 단계로, 아직 특정 DBMS 의 저장 구조까지는 정하지 않습니다.
• 외부 스키마 설계: 사용자마다 보는 화면(뷰)을 정하는 것으로, 저장 구조와는 거리가 멉니다.

속성은 만들어지는 방식에 따라 세 가지로 나뉩니다.

• 기본 속성: 업무에서 원래 가지고 있는 값 (예: 상품명, 단가)
• 설계 속성: 업무에는 없지만 설계하면서 만든 값 (예: 일련번호, 코드)
• 파생 속성: 다른 속성을 계산해서 얻는 값 (예: 총금액, 합계)

'주문 총금액'은 단가와 수량을 곱해 더한 값이므로 파생 속성입니다.

틀린 선지

• 기본 속성: 업무에서 원래 있는 값으로, 계산으로 얻지 않습니다.
• 복합 속성: 주소(시·구·동)처럼 여러 세부 속성으로 나눌 수 있는 속성을 말하며, 계산과는 관계없습니다.
• 설계 속성: 일련번호·코드처럼 설계자가 새로 만든 속성으로, 계산해서 얻는 값이 아닙니다.

관계를 나타내는 요소는 세 가지입니다.

• 관계명: 관계의 이름 (예: '소속된다')
• 관계 차수(Cardinality): 몇 개와 연결되는지 (1:1, 1:M, M:N)
• 관계 선택사양(Optionality): 연결이 꼭 있어야 하는지(필수), 없어도 되는지(선택)

틀린 선지

• 관계명(Membership): 관계에 붙이는 이름입니다.
• 관계 페어링(Pairing): 두 엔터티의 인스턴스가 각각 실제로 짝지어진 것을 뜻하며, 1:M 같은 개수 표현이 아닙니다.
• 관계 선택사양(Optionality): 상대 인스턴스가 반드시 있어야 하는지 아닌지를 나타냅니다. 개수를 나타내지 않습니다.

엔터티가 되려면 업무에 필요해야 하고, 식별자가 있어야 하며, 인스턴스(실제 값의 한 건)가 두 개 이상 모여야 하고, 속성과 다른 엔터티와의 관계를 가져야 합니다. 인스턴스가 하나뿐이라면 굳이 엔터티로 만들 필요가 없으므로 이 설명이 틀렸습니다.

틀린 선지

• 업무에 필요하고 관리하고자 하는 정보여야 한다: 옳은 설명입니다. 업무와 상관없는 것은 엔터티가 되지 않습니다.
• 다른 엔터티와 최소 한 개 이상의 관계를 가져야 한다: 옳은 설명입니다. (통계·코드성 엔터티 같은 예외는 있습니다)
• 유일한 식별자로 각 인스턴스를 구별할 수 있어야 한다: 옳은 설명입니다.

주식별자는 네 가지 특징을 가져야 합니다.

• 유일성: 주식별자로 모든 인스턴스를 하나씩 구별할 수 있다
• 최소성: 유일성을 지키는 범위에서 속성 수가 가장 적다
• 불변성: 한번 정한 값이 바뀌지 않는다
• 존재성: 값이 반드시 있어야 한다(NULL 불가)

속성의 수를 최소로 한다는 것은 최소성입니다.

틀린 선지

• 유일성: 인스턴스를 하나씩 구별할 수 있어야 한다는 뜻으로, 속성 수와는 다른 이야기입니다.
• 불변성: 주식별자 값이 자주 바뀌면 안 된다는 뜻입니다.
• 존재성: 주식별자 값이 비어 있으면(NULL) 안 된다는 뜻입니다.

속성 하나에는 값이 하나만 들어가야 합니다. 한 사원에게 자격증이 여러 개 있으면, 자격증을 따로 엔터티로 만들고 사원과 1:M(한 사원 : 여러 자격증) 관계로 연결하는 것이 바른 방법입니다. 이것이 제1정규화의 생각과 같습니다.

틀린 선지

• 자격증 속성 하나에 쉼표로 이어서 모두 넣는다: 한 칸에 여러 값을 넣는 것은 원자값 원칙을 어깁니다.
• 자격증1·자격증2·자격증3 처럼 속성을 여러 개 만든다: 자격증이 4개인 사원은 넣을 수 없고, 빈칸이 많이 생기며 조회도 어렵습니다(반복 그룹).
• 자격증 속성을 파생 속성으로 바꾼다: 파생 속성은 계산으로 얻는 값이라 이 문제와 관계없습니다.

식별 관계는 부모의 주식별자가 자식의 주식별자 일부가 되는 관계입니다. 그래서 식별 관계가 여러 단계 이어지면 아래 자식일수록 주식별자 속성이 늘어나 키가 길고 복잡해집니다. '줄어든다'는 설명이 틀렸습니다. 이런 문제를 막으려고 적절한 곳에서 비식별 관계로 끊습니다.

틀린 선지

• 부모 없이도 자식 인스턴스가 생길 수 있다면 비식별 관계를 검토한다: 옳은 설명입니다. 부모와의 관계가 약하거나 선택적일 때 비식별 관계를 씁니다.
• IE 표기법에서 식별 관계는 실선, 비식별 관계는 점선으로 나타낸다: 옳은 설명입니다.
• 비식별 관계에서는 부모의 주식별자가 자식의 일반 속성(외래키)이 된다: 옳은 설명입니다.

IE 표기법에서 실선은 식별 관계, 점선은 비식별 관계입니다.

1. 주문 — 주문상세: 실선입니다. 주문번호(FK)가 주문상세 상자의 가로선 위(주식별자)에 있으므로 식별 관계이고, 주문상세의 주식별자는 (주문번호, 상품번호)입니다.
2. 고객 — 주문: 점선입니다. 고객번호(FK)가 주문 상자의 가로선 아래(일반 속성)에 있으므로 비식별 관계입니다.
3. 주문상세 쪽 선 끝은 세로선 + 까마귀발(1개 이상)이므로 한 주문에는 주문상세가 반드시 하나 이상 있습니다.

틀린 선지

• 한 주문에는 주문상세가 하나도 없어도 된다: 주문상세 쪽 끝에 동그라미가 아니라 세로선이 있으므로 1개 이상(필수)입니다.
• 주문상세의 주식별자는 상품번호 하나뿐이다: 주식별자 칸에 주문번호(FK)와 상품번호 두 개가 있으므로 두 속성을 합친 복합 식별자입니다.
• 고객과 주문은 식별 관계이며, 고객번호가 주문 주식별자의 일부이다: 고객과 주문은 점선(비식별 관계)이고, 고객번호는 주문의 일반 속성입니다.