•
어떤 개념이 엔터티가 될 수 있는지 6가지 조건으로 판정할 수 있다.
•
속성을 특성(기본/설계/파생)과 분해수준(단일/복합/다중값)으로 분류할 수 있다.
•
관계의 차수(1:1, 1:M, M:N) 와 선택사양(필수/선택) 을 ERD에서 읽어낼 수 있다.
•
M:N 관계를 교차 엔터티로 해소할 수 있고, 왜 해소해야 하는지 설명할 수 있다.
1. 엔터티 (Entity)
1) 정의
•
업무에서 관리해야 하는, 의미 있는 정보의 집합
•
저장되고 관리되어야 하는 "덩어리"
•
물리 모델에서는 대부분 테이블이 된다
구분 | 용어 (논리 모델) | 용어 (물리 모델/DB) |
집합 전체 | 엔터티 (Entity) | 테이블 (Table) |
한 건의 데이터 | 인스턴스 (Instance) | 행 (Row) |
각 항목 | 속성 (Attribute) | 컬럼 (Column) |
엔터티 PLAYER 를 표로 그려보면선수ID | 선수명 | 포지션 | 등번호 | ← 속성 (Attribute) | |
인스턴스 ① | 2012001 | 김철수 | GK | 1 | |
인스턴스 ② | 2012002 | 이영희 | FW | 9 | |
인스턴스 ③ | 2012003 | 박민수 | MF | 7 | |
 엔터티 = 표 전체 |
한 줄 정리엔터티 = 표 전체, 인스턴스 = 표의 한 줄, 속성 = 표의 한 칸(열)2) 엔터티가 되기 위한 6가지 조건 
# | 조건 | 뜻 | 위반 예시 |
1 | 업무에서 필요로 하는 정보여야 한다 | 우리 업무가 실제로 쓰는가? | 축구 DB에 '주식 시세' |
2 | 유일한 식별자로 식별 가능해야 한다 | 한 건을 콕 집어낼 수 있는가? | 이름만 있는 선수 목록(동명이인 구분 불가) |
3 | 인스턴스가 2개 이상이어야 한다 | 한 건짜리는 엔터티가 아님 | '우리 회사' 엔터티 (1건뿐) |
4 | 업무 프로세스에 이용되어야 한다 | 아무도 안 쓰면 만들 필요 없음 | 등록만 하고 조회도 안 하는 표 |
5 | 반드시 속성을 포함해야 한다 | 속성 없는 엔터티는 없음 | 이름만 있고 관리항목이 없는 표 |
6 | 다른 엔터티와 최소 1개 이상의 관계가 있어야 한다 | 홀로 떠 있으면 안 됨 | 아무 테이블과도 연결 안 된 표 |
6번의 예외 (기출 함정)
아래 세 가지는 관계가 없어도 엔터티로 인정합니다.
통계성 엔터티 / 코드성 엔터티 / 시스템에서 내부 필요에 의해 생성한 엔터티3) PLAYER 는 6가지 조건을 만족하는가?
# | 조건 | PLAYER 실제 데이터 | 판정 |
1 | 업무에 필요한 정보 | 축구 구단 업무의 핵심 대상 |  |
2 | 유일한 식별자 | PLAYER_ID 480건 모두 서로 다름 | |
3 | 인스턴스 2개 이상 | 선수 480명 | |
4 | 업무 프로세스에 이용 | 선수 등록·이적·출전 관리에 사용 | |
5 | 속성 보유 | 선수명·포지션·등번호 등 13개 | |
6 | 최소 1개 이상의 관계 | TEAM 과 1:M 관계 | |
4) 조건 ② 를 왜 이름으로 만족시킬 수 없는가
"선수명(PLAYER_NAME)을 식별자로 쓰면 안 될까?" — 데이터로 판정해 봅시다.
항목 | 값 |
전체 선수 수 | 480명 |
서로 다른 선수명의 개수 | 476개 |
차이(중복 건수) | 4건 |
실제 중복되는 이름
선수명 | 인원수 |
김정우 | 2명 |
이강진 | 2명 |
… | … |
결론: 이름은 유일하지 않으므로 식별자가 될 수 없습니다.
그래서 실제 모델에서는 인위적인 PLAYER_ID 를 만들어 식별자로 삼았습니다.
→ 이것을 인조 식별자(Artificial Key) 라고 부릅니다.5) 엔터티의 분류
엔터티는 두 가지 기준으로 나눕니다. 시험에는 이 두 기준이 섞여서 출제됩니다.
기준 | 종류 | 판별 요령 |
유무형 | 유형 / 개념 / 사건 | 만질 수 있으면 유형, 눈에 안 보이면 개념, "~했다"는 일 이면 사건 |
발생시점 | 기본 / 중심 / 행위 | FK가 하나도 없으면 기본, FK가 있으면 중심, 여러 엔터티가 합쳐졌으면 행위 |
6) 실습 스키마 전수 분류
판별 기준: 그 엔터티가 외래키(FK)를 몇 개 갖고 있는가?
엔터티 | FK 개수 | 유무형 분류 | 발생시점 분류 | 판단 근거 |
STADIUM | 0개 | 유형 엔터티 | 기본 엔터티 | 만질 수 있고, 아무에게도 의존하지 않음 |
TEAM | 1개 | 개념 엔터티 | 중심 엔터티 | 팀은 만질 수 없는 '조직' 개념 / 경기장에 의존 |
PLAYER | 1개 | 유형 엔터티 | 중심 엔터티 | 사람은 만질 수 있음 / 팀에 의존 |
SCHEDULE | 1개 + 팀 참조 2개 | 사건 엔터티 | 행위 엔터티 | 경기가 '열린다'는 사건 / 홈팀·원정팀 2개 팀이 만나 발생 |
2. 속성 (Attribute)
1) 정의와 기본 개념
•
엔터티가 관리하는 더 이상 쪼갤 수 없는 최소의 데이터 단위
•
하나의 속성은 하나의 값(원자값) 만 가진다
•
도메인(Domain): 그 속성이 가질 수 있는 값의 범위
속성 | 도메인 (가질 수 있는 값의 범위) |
POSITION | { GK, DF, MF, FW } — 실제 데이터에 나타나는 값은 이 4가지뿐 |
HEIGHT | 100 ~ 250 사이의 정수 |
SOLAR | { 1(양력), 0(음력) } |
2) 특성에 따른 분류 (기본 / 설계 / 파생)
종류 | 정의 | 예시 | 특징 |
기본 속성 (Basic) | 업무에서 원래 존재하는 속성 | 선수명, 키, 몸무게, 급여 | 가장 많은 비중 |
설계 속성 (Designed) | 업무에는 없지만 설계하면서 만든 속성 | 선수ID, 팀ID, 상품코드 | 주로 코드성 속성 |
파생 속성 (Derived) | 다른 속성으로부터 계산되어 나온 속성 | 연봉(=월급×12), 합계, 평균 | 가급적 적게 만들어야 함 |
EMP 테이블로 세 가지를 구분해 보면
컬럼 | 분류 | 이유 |
ENAME (사원명) | 기본 속성 | 업무에 원래 존재 |
SAL (급여) | 기본 속성 | 업무에 원래 존재 |
EMPNO (사원번호) | 설계 속성 | 구분하려고 인위적으로 만든 코드 |
SAL × 12 (연봉) | 파생 속성 | 계산으로 만들어짐 (테이블에 저장 안 함) |
파생 속성이 위험한 이유 (시험 단골)
원본이 바뀌었는데 파생 값을 갱신하지 않으면 데이터가 서로 안 맞습니다(= 01강의 비일관성).
그래서 원칙은 "저장하지 말고 필요할 때 계산하라" 입니다.3) 파생 속성 계산의 NULL 함정 ★★ 매년 나옵니다
상황: 실제 연봉 = (월급 + 커미션) × 12 로 계산하려고 한다.
-- ❌ 잘못된 계산: NULL이 하나라도 끼면 전체가 NULL이 된다
SELECT ENAME, SAL, COMM, (SAL + COMM) * 12 AS 연봉 FROM EMP;
-- ✅ 올바른 계산: NVL(값, 대체값) 으로 NULL을 0으로 바꾼 뒤 계산
SELECT ENAME, SAL, COMM, (SAL + NVL(COMM, 0)) * 12 AS 연봉 FROM EMP;
SQL
복사
두 계산의 결과 비교
사원명 | 급여 | 커미션 |  (SAL+COMM)*12 | (SAL+NVL(COMM,0))*12 |
SMITH | 800 | (NULL) | (NULL) | 9,600 |
ALLEN | 1600 | 300 | 22,800 | 22,800 |
KING | 5000 | (NULL) | (NULL) | 60,000 |
시험 포인트NULL은 '값이 없음'이지 '0'이 아닙니다.NULL이 포함된 사칙연산의 결과는 무조건 NULL 입니다.
HR 계정에서는 commission_pct 가 비율이므로 salary * 12 * (1 + NVL(commission_pct, 0)) 형태가 됩니다.4) 구성 방식에 따른 분류 (PK / FK / 일반)
종류 | 뜻 | 실습 스키마 예시 |
PK 속성 (기본키) | 인스턴스를 식별하는 속성 | PLAYER.PLAYER_ID |
FK 속성 (외래키) | 다른 엔터티와의 관계를 나타내는 속성 | PLAYER.TEAM_ID |
일반 속성 | 그 외 나머지 | PLAYER.HEIGHT, PLAYER.NICKNAME |
5) 분해 수준에 따른 분류 (단일 / 복합 / 다중값)
종류 | 정의 | 실습 스키마 예시 | 조치 |
단일 속성 | 하나의 의미만 가짐 | HEIGHT, WEIGHT | 그대로 사용 |
복합 속성 | 여러 의미로 분해 가능 | ADDRESS(주소) | 업무 필요에 따라 분해해서 관리 |
다중값 속성 | 한 속성에 여러 값 | 선수의 전화번호 여러 개 | 반드시 별도 엔터티로 분리 |
6) 복합 속성을 미리 분해해 두면 무엇이 좋은가
TEAM 테이블은 전화번호를 DDD(지역번호) + TEL(국번) 으로 나눠 관리합니다.
팀명 | DDD | TEL | 합치면 |
성남일화천마 | 031 | 123-4567 | 031-123-4567 |
수원삼성블루윙즈 | 031 | 987-6543 | 031-987-6543 |
분해해서 저장 (실제 설계) | 한 칸에 저장 | |
"경기도(031) 팀만 조회" | WHERE DDD = '031' → 인덱스 사용 O | WHERE TEL LIKE '031%' → 느림 |
지역번호만 변경 | 해당 컬럼만 수정 | 문자열을 잘라 붙여야 함 |
필요하면 합치기 | DDD || '-' || TEL 로 언제든 가능 | — |
7) 다중값 속성은 왜 반드시 제거해야 하는가
나쁜 설계 — 한 칸에 연락처를 콤마로 이어 붙였다선수ID | 선수명 | 연락처 |
2012001 | 김철수 | 010-1111-1111, 02-222-2222 |
2012002 | 이영희 | 010-3333-3333 |
# | 문제점 | 구체적으로 |
1 | 검색 불가 | "02-222-2222 쓰는 선수 찾기" → LIKE 검색뿐 (느리고 부정확) |
2 | 구조 변경 강제 | 번호가 4개로 늘면 컬럼 길이를 또 늘려야 함 |
3 | 수정 곤란 | 번호 하나만 고치려면 문자열을 잘라 붙여야 함 |
좋은 설계 — 별도 엔터티로 분리 (= 제1정규화)[선수]
선수ID | 선수명 |
2012001 | 김철수 |
2012002 | 이영희 |
[선수연락처]
선수ID | 번호순번 | 번호종류 | 전화번호 |
2012001 | 1 | 휴대폰 | 010-1111-1111 |
2012001 | 2 | 자택 | 02-222-2222 |
2012002 | 1 | 휴대폰 | 010-3333-3333 |
한 행에 값 하나만 들어가므로 WHERE 전화번호 = '02-222-2222' 로 정확하고 빠르게 검색됩니다.
시험 포인트"한 속성에 값이 여러 개 = 다중값 속성 = 제1정규형 위반 = 별도 엔터티로 분리"
이 연결고리를 통째로 외우세요. (04강 정규화와 직결)8) 속성명 작성 규칙
•
해당 업무에서 사용하는 이름을 부여
•
서술식 이름은 사용 금지 (선수가입년도 → 가입년도 
)
→ 가입년도 )•
약어 사용은 가급적 지양
•
전체 모델에서 유일한 이름을 사용 (같은 뜻이면 같은 이름)
3. 관계 (Relationship)
1) 정의와 분류
•
엔터티와 엔터티 사이의 연관성
•
ERD에서는 선(線) 으로 표현
분류 | 뜻 | 예시 |
존재 관계 | 그냥 존재 자체로 맺어진 관계 | 부서 ─ 사원 (사원은 부서에 소속되어 존재) |
행위 관계 | 어떤 행위(사건) 로 인해 생긴 관계 | 고객 ─ 주문 (주문이라는 행위로 연결) |
두 관계 모두 ERD 표기법은 똑같습니다. 구분은 개념적인 것뿐입니다.2) 관계를 표기하는 3요소
요소 | 질문 | 표기 |
관계명 | "무슨 관계인가?" | 선 위에 동사로 기술 (예: 소속된다 / 소속시킨다) |
관계 차수 | "몇 개와 연결되나?" | 1:1, 1:M, M:N |
관계 선택사양 | "없어도 되나?" | 필수(●) / 선택(○) |
관계는 항상 양쪽에서 읽습니다 (기출 단골)•
팀 입장: "한 팀은 여러 선수를 소속시킨다." (1 → M)
•
선수 입장: "한 선수는 하나의 팀에 소속된다." (M → 1)
3) 관계 차수 (Cardinality) 3종 비교
차수 | 의미 | 실습 스키마 예시 | 물리 구현 방법 |
1 : 1 | 양쪽 모두 한 건씩 | STADIUM  TEAM (한 경기장의 홈팀은 하나) | 한쪽에 FK + UNIQUE |
1 : M | 한쪽이 여러 건 | TEAM → PLAYER (한 팀에 선수 여러 명) | M쪽에 FK |
M : N | 양쪽 모두 여러 건 | 팀 팀 (경기를 통해) | 그대로는 불가 → 해소 필요 |
1:M 관계를 데이터로 확인 — 팀 1건에 선수 여러 건이 매달려 있다
팀명 | 소속 선수 수 |
수원삼성블루윙즈 | 35명 |
성남일화천마 | 33명 |
… | … |
4) 관계 선택사양 (필수 / 선택)
이 개념이 2과목의 OUTER JOIN과 직결되므로 반드시 이해하고 넘어가야 합니다.
선택사양 | 뜻 | FK 컬럼의 NULL 허용 | 조인 방식 |
필수 (Mandatory) | 반드시 상대가 있어야 함 | NOT NULL | INNER JOIN으로 충분 |
선택 (Optional) | 상대가 없어도 됨 | NULL 허용 | OUTER JOIN 필요 |
5) 선택적 관계가 조회 결과를 바꾸는 장면 ★★
상황: EMP.MGR(관리자)는 NULL 허용 = 선택적 관계. 사장(KING)은 관리자가 없습니다.
-- ❌ INNER JOIN : 관리자가 없는 KING이 결과에서 사라진다 → 13건
SELECT E.ENAME AS 사원, M.ENAME AS 관리자
FROM EMP E, EMP M
WHERE E.MGR = M.EMPNO;
-- ✅ OUTER JOIN : 관리자가 없어도 사원은 모두 보여준다 → 14건
SELECT E.ENAME AS 사원, M.ENAME AS 관리자
FROM EMP E, EMP M
WHERE E.MGR = M.EMPNO(+); -- (+): 데이터가 부족한 쪽에 붙인다 (Oracle 전용 표기)
SQL
복사
결과 비교
사원 | 관리자 | INNER JOIN | OUTER JOIN |
SMITH | FORD | 포함 | 포함 |
ALLEN | BLAKE | 포함 | 포함 |
KING | (NULL) | 누락 | 포함 |
총 건수 | 13건 | 14건 |
시험 포인트 — 모델링(1과목)과 조인(2과목)이 여기서 만납니다"관계가 선택적(Optional)이다"= "FK에 NULL이 있을 수 있다"= "INNER JOIN 하면 행이 누락된다"= "OUTER JOIN 을 써야 한다"4. M:N 관계의 해소
1) 왜 M:N은 그대로 둘 수 없는가?
•
관계형 데이터베이스는 M:N 관계를 직접 저장할 수 없습니다.
•
FK는 컬럼 하나에 값 하나만 담을 수 있는데, M:N은 양쪽 모두 값이 여러 개이기 때문입니다.
•
그래서 논리 모델에는 M:N이 존재할 수 있지만, 물리 모델에는 존재할 수 없습니다.
해소 전 — 표현할 방법이 없다
팀ID | 팀명 | 상대팀ID |
K01 | 성남일화천마 | K02, K03, K04, … |
한 팀은 여러 팀과 경기하고, 그 상대 팀도 여러 팀과 경기합니다.
TEAM 에 "상대팀ID" 컬럼을 만들면 한 칸에 여러 팀을 넣어야 함 = 다중값 속성
해소 후 — 가운데에 새 엔터티를 놓는다
핵심
M:N 하나를 1:M 두 개로 쪼갭니다. 가운데 새로 생긴 엔터티를
교차 엔터티 / 연관 엔터티 (associative entity) 라고 부릅니다.
이 교차 엔터티는 대부분 행위 엔터티입니다.2) 우리 실습 스키마의 SCHEDULE 이 바로 그 교차 엔터티다
경기일자 | 홈팀ID | 원정팀ID | 홈팀득점 | 원정팀득점 |
20120303 | K01 | K02 | 2 | 1 |
20120304 | K03 | K04 | 0 | 0 |
•
HOMETEAM_ID, AWAYTEAM_ID — TEAM 을 가리키는 FK가 두 개
•
HOME_SCORE, AWAY_SCORE — 관계 자체가 갖는 속성을 저장할 자리가 생겼다 (교차 엔터티의 장점!)
3) 교차 엔터티를 양쪽 모두와 조인하기 ★★
핵심 함정: 같은 TEAM 테이블을 역할이 다르므로 두 번 조인해야 합니다.
SELECT S.SCHE_DATE, H.TEAM_NAME AS 홈팀, S.HOME_SCORE,
A.TEAM_NAME AS 원정팀, S.AWAY_SCORE, ST.STADIUM_NAME
FROM SCHEDULE S, TEAM H, TEAM A, STADIUM ST -- TEAM 을 H(홈) / A(원정) 로 두 번
WHERE S.HOMETEAM_ID = H.TEAM_ID -- ① 교차 엔터티 → 홈팀
AND S.AWAYTEAM_ID = A.TEAM_ID -- ② 교차 엔터티 → 원정팀
AND S.STADIUM_ID = ST.STADIUM_ID; -- ③ 교차 엔터티 → 경기장
SQL
복사
경기일자 | 홈팀 | 홈득점 | 원정팀 | 원정득점 | 경기장 |
20120303 | 성남일화천마 | 2 | 수원삼성블루윙즈 | 1 | 성남종합운동장 |
테이블 4개(S, H, A, ST) → 조인 조건 3개 (01강의 N-1 규칙)
같은 테이블이라도 역할이 다르면 다른 별칭으로 여러 번 조인할 수 있습니다.4) M:N 해소 요약
해소 전 | 해소 후 | |
관계 | 팀 M : N 팀 | 팀 1:M 경기일정 M:1 팀 |
엔터티 수 | 1개 | 2개 (교차 엔터티 추가) |
관계 자체의 속성(득점 등) | 저장할 곳 없음 | 교차 엔터티에 저장 |
물리 구현 | 불가능 | 가능 |
5. 출제 포인트 한눈에 정리
# | 꼭 외울 것 | 핵심 |
1 | 엔터티 조건 6가지 | 업무필요 / 유일식별 / 인스턴스 2개↑ / 프로세스이용 / 속성보유 / 관계보유 |
2 | 관계 없이도 엔터티인 예외 | 통계성 · 코드성 · 시스템 생성 엔터티 |
3 | 유무형 분류 | 유형 / 개념 / 사건 |
4 | 발생시점 분류 | 기본 / 중심 / 행위 (기본은 FK 없음) |
5 | 속성 특성 분류 | 기본 / 설계 / 파생 (파생은 최소화) |
6 | 파생 속성 계산 | NULL이 끼면 결과는 NULL → NVL 필수 |
7 | 속성 분해 분류 | 단일 / 복합 / 다중값(반드시 분리) |
8 | 관계 표기 3요소 | 관계명 / 차수 / 선택사양 |
9 | 관계 차수 | 1:1 / 1:M / M:N(물리 모델엔 없음) |
10 | 선택사양 = 선택 | FK NULL 허용 → OUTER JOIN 필요 |
11 | M:N 해소 | 교차(연관) 엔터티 추가 → 1:M 두 개로 분해 |
6. 확인 문제
Q1. 엔터티가 갖추어야 할 조건으로 옳지 않은 것은?
① 업무에서 필요로 하는 정보여야 한다
② 유일한 식별자로 식별이 가능해야 한다
③ 인스턴스가 반드시 1개만 존재해야 한다
④ 다른 엔터티와 최소 1개 이상의 관계가 있어야 한다
정답 보기
Q2. 다음 중 파생 속성에 해당하는 것은?
① 사원의 이름
② 사원번호
③ 월급여 × 12로 계산한 연봉
④ 입사일자
정답 보기
Q3. 아래 데이터의 문제점과 해결 방법을 쓰시오.
선수ID | 선수명 | 보유자격증 |
2012001 | 김철수 | 1급코치, 심판2급, 트레이너 |
2012002 | 이영희 | 1급코치 |
정답 보기
Q4. M:N 관계에 대한 설명으로 옳지 않은 것은?
① 논리적 데이터 모델에서는 표현할 수 있다
② 물리적 데이터 모델에서도 그대로 구현할 수 있다
③ 해소하면 1:M 관계 두 개로 분해된다
④ 해소 시 생기는 엔터티를 교차(연관) 엔터티라 한다
정답 보기