[SQL] 자격증 준비 (2) 기본 용어 이해

요약 정리

미리 정리하고 들어가자면 

 

-테이블 (food_orders) → 엔터티 (음식 주문 관련 정보)
-컬럼 (restaurant_name, price) → 속성 (각각의 음식점 이름과 가격이라는 특성)
-행(레코드) (예: "어느 식당", 1000원) 가로줄 전체로 → 인스턴스 (이 행은 한 번의 음식 주문 정보를 나타냄)

 

이렇게 인거임!!

 

 

---

구체적으로 이해하기. 

1. 엔터티 이해하기:

엔터티란 업무에 필요한 정보를 저장하고 관리하기 위한 집합적인 명사 개념이에요.

 

쉽게 말해서, 어떤 시스템에서 다루는 주요 데이터를 나타내는 대상을 뜻해요. 우리가 어떤 프로그램을 만들 때, 그 프로그램에서 다룰 주요 정보를 엔터티로 표현한다고 할 수 있죠.

 

예를 들어, 직원 관리 프로그램을 만든다고 가정해봅시다. 이 프로그램에서 우리는 직원에 관한 정보를 저장하고 관리할 필요가 있어요. 그러면 '직원'이라는 정보는 엔터티로 정의할 수 있죠. 이 엔터티는 사실 하나의 집합적 개념으로, 프로그램 안에서는 "직원 정보"라는 의미로 사용돼요.

 

직원을 나타낼 때, 하나의 직원에 대해서 "직원", "사람", "근로자"라고도 부를 수 있지만, 데이터베이스에서 중요한 건 이 개념을 집합적으로 표현한 '직원'이라는 명사라는 점이에요. 여러 직원이 있을 수 있으니, 이를 하나의 집합으로 표현하는 게 바로 엔터티인 거죠.

 

엔터티의 중요한 점:
업무에 필요한 정보를 저장하는 데에 해당하는 집합적 명사를 엔터티로 정의합니다.
-
예를 들어, 대학생 관리 프로그램에서는 학생이라는 엔터티가 필요하고, 병원 관리 시스템에서는 환자라는 엔터티가 필요합니다. 즉, 각 프로그램의 목적에 따라 필요한 엔터티가 달라요.대학생 관리 프로그램에서는 환자라는 엔터티가 필요하지 않듯이, 엔터티는 특정 업무에 필요한 정보만을 다룬다는 점이 중요합니다.

 

이렇게 엔터티는 어떤 시스템이나 프로그램에서 중요한 정보를 집합적으로 표현한 개념으로, 우리가 다루고자 하는 주요 데이터를 정의하고 관리하는 핵심적인 역할을 합니다.

---

📌 인스턴스란? 그리고 엔터티의 특징까지 정리!

앞에서 엔터티가 "직원"처럼 업무에 필요한 데이터를 집합적인 명사 개념으로 표현한 거라고 했었던거 기억하나요?

그렇다면 여기서 말하는 인스턴스는 뭐냐면-,

엔터티 안에 들어있는 각각의 실제 데이터, 즉 개별적인 대상들을 말합니다!

 

예를 들어 "직원"이란 엔터티 안에 있는 A씨, B씨, C씨 각각은 다 하나의 인스턴스입니다.
A는 A의 정보대로, B는 B의 정보대로 저장되어 있겠죠?
이처럼 "직원"이라는 집합 안에 있는 개별 하나하나가 바로 인스턴스인 겁니다.

그냥 용어 정리일 수 있지만, 시험에도 꽤 잘 나오니까 이 개념 확실히 잡아두는 게 좋은데요.

 

-> 그럼, 엔터티의 특징은 뭐가 있을까?

엔터티를 제대로 잡으려면 아래 조건들을 만족해야 합니다

1️⃣ 업무에서 필요한 정보를 담고 있어야 함

엔터티는 그냥 아무 데이터나 저장하는 게 아닙니다.
예를 들어 직원 관리 프로그램이라면
"직원", "부서" 같은 정보는 업무상 필요하니까 엔터티가 될 수 있습니다.

반대로, 병원 정보는 필요 없겠죠? 그럼 그건 엔터티 대상 아님!

2️⃣ 요구사항에서 추출 가능해야 함

예를 들어, 어떤 직원이 “우리 직원 관리 프로그램엔 이름, 주소, 부서 같은 정보가 필요해요~”라고 말했다면,

그럼 우리는 이 요구사항 속에서
: "직원", "부서" 같은 업무상 필요한 엔터티를 추출해내야 하는 겁니다!

-> 엔터티가 컬럼인 듯

3️⃣ 식별자가 있어야 함 (유일한 구분자)

엔터티 안의 인스턴스를 서로 구분할 수 있어야 합니다.
예를 들어 "이름"만으로는 사람을 구분하기 어려워. 동명이인 있을 수 있으니까!

하지만 "주민등록번호"나 "사번"처럼 유일하게 구분 가능한 정보,
즉 식별자가 있다면 OK!

-> inner join, left join 를 쓸 때 두가지 테이블을 결합해 정보를 뽑아낼 때 기준으로 삼는 컬럼을 식별자라고 하는 듯.

4️⃣ 인스턴스가 2개 이상이어야 함

이건 무슨 말이냐면, 엔터티는 집합이라고 했잖아요?
근데 집합인데 안에 데이터가 하나밖에 없다? 이상합니다.

예를 들어 전 세계에 병원이 딱 하나밖에 없다면,
병원이라는 건 "집합" 개념이 아니니까 엔터티가 될 수 없죠.

그러니까 2개 이상의 인스턴스가 존재해야만 엔터티가 되는 거랍니다.

5️⃣ 속성도 2개 이상 필요함

속성은 이름, 주소, 연락처 같은 구체적인 정보들입니다.
하나만 있는 건 데이터로써 정보성이 약하니까 2개 이상은 있어야 의미 있음.

요약하면!
업무에 필요해야 하고, 요구사항에서 뽑아내야 하며, 유일한 식별자가 존재하고, 인스턴스랑 속성도 최소 2개 이상 있어야 진짜 '엔터티'입니다!

---

🧩 엔터티의 분류 다시 정리하기

💡 1. 유무형 기준

✅ 유형 엔터티

• 현실에서 눈에 보이는 실체가 있는 존재
• 예: 직원, 강사, 고객, 술(!) 등

→ 눈으로 보고, 손으로 만질 수 있는 애들.
“물리적인 형태가 있다”가 핵심 포인트.

✅ 무형 엔터티

• 개념적이고, 눈에 보이지 않지만 중요한 정보
• 예: 부서, 감옥, 직급, 과목

→ 실체는 없지만, 업무상 관리해야 하는 대상들.
시험에서는 “이건 무형 엔터티일까요?” 식으로 물을 수 있어.

✅ 사건 엔터티

• 업무 수행 중 발생하는 정보
• 예: 강의, 주문, 대출, 예약 등

→ 예시:
‘직원(유형)’이 ‘과목(무형)’을 가르치면,
그 행위로 생기는 게 ‘강의(사건)’라는 엔터티!

→ 시험에서 가끔 "다음 중 사건 엔터티가 아닌 것은?" 형태로 출제된다고 합니다

🔔 핵심 요약:

• 유형 = 현실 존재
• 무형 = 개념적 정보
• 사건 = 업무 중 발생

---

⏰ 2. 발생 시점 기준

✅ 기본(키) 엔터티

• 업무 요구사항에서 가장 먼저 등장하는 정보
• 독립적으로 생성 가능 (다른 데이터 없어도 됨)
• 예: 직원, 부서, 고객, 상품

→ “직원 관리 시스템 만듭시다” 할 때,
가장 먼저 생각나는 애들이 기본 엔터티임.

→ **주 식별자(Primary Key)**도 보통 기본 엔터티에 먼저 생김 (나중에 배울 내용!)

---

✅ 중심 엔터티

• 기본 엔터티들이 무언가 ‘행동’을 하면서 생긴 정보
• 예: 주문, 대출, 수강신청 등

→ 예를 들어, “직원이 고객에게 대출을 해줬다”면
직원과 고객은 기본이고, ‘대출’이라는 중심적인 정보가 새로 생긴다.

→ 시험에선 중심 엔터티를 “기본 엔터티에서 파생된 업무의 중심”이라고 표현할 수 있음.

---

✅ 행위 엔터티

• (이건 아직 수업에서 안 나왔을 수도 있지만 미리 짧게 언급해두자면)
  중심 엔터티를 더 세분화해서 설명하는 보조적인 엔터티

→ 예: 주문 상세, 수강 과목 내역 등

---

🎯 시험 포인트

• “유형/무형/사건” → 실체의 성격
• “기본/중심/행위” → 발생 시점
  → 분류 기준이 다르니까, 헷갈리면 분류 기준부터 확인하기!

---

🎯 행위 엔터티란?

📌 정의

• 두 개 이상의 엔터티(기본/중심)로부터 발생된 엔터티
• 업무상 더 세분화된 정보가 필요할 때 등장

📌 예시

• 직원이 고객에게 ‘주문’을 받았다 → 이건 중심 엔터티
• 근데 그 주문이 여러 번 있었고, 각각의 이력이 필요하다? → 이때 등장하는 게 바로 행위 엔터티!

✅ 즉, 업무 히스토리나 기록/로그처럼
더 자세한 이력, 상세 내역을 표현할 필요가 생겼을 때
등장하는 게 ‘행위 엔터티’다!

---

🧠 엔터티 명명 규칙 (시험에 출제된 적 있음!)

1. 협업 용어 사용

• ❌ 사람 → ✅ 고객
• ❌ 전봇대 → ✅ 전주

→ 현업에서 사용되는 용어와 일치시켜야 혼란이 없음!

---

2. 약어 사용 지양

• ❌ 일매목 (일별 매출 목록)
• ✅ 일별 매출 목록

→ 약어는 쓰는 사람만 알아보니까, 시험에서도 풀네임을 기본 원칙으로 본다.

---

3. 단수 명사 사용

• ❌ 직원들, 주문내역들
• ✅ 직원, 주문내역

→ 엔터티 자체가 데이터의 집합이기 때문에,
굳이 복수형 쓸 필요 없음. 단수로 가독성 UP!

---

4. 유일한 이름 부여

• ❌ 직원 (중복된 이름 두 번 쓰면 안 됨)
• ✅ 직원, 고객, 부서, 대출 등 각각 유일하게 구분되어야 함

→ 같은 이름 두 번 쓰면 어떤 데이터인지 구분 안 됨 = 실무에서도 에러 발생

---

5. 의미에 맞는 이름 부여

• ❌ 연락처
• ✅ 직원 연락처 목록 / 고객 연락처 목록

→ 엔터티는 집합이니까,
‘누구의 데이터를 저장하는 건지’ 명확하게 표현해야 함!

---

🧪 시험 포인트 총정리

*내용주의할 점

 

행위 엔터티	2개 이상 엔터티에서 파생, 이력/기록 중심
협업 용어	현실에서 쓰는 말 기준으로 명명
약어 금지	풀네임 사용!
단수형 사용	직원들 ❌ → 직원 ✅
이름 유일성	같은 이름 중복 금지
의미 기반 이름	연락처 ❌ → 직원 연락처 목록 ✅

 

 

 

---

 

 

🧩 속성이란?

📌 정의

• 업무상 관리하기 위해 더 이상 나눌 수 없는 최소의 데이터 단위
• 엔터티가 가지는 공통적인 특징

예를 들어:

‘직원’이라는 엔터티 → 공통 속성: 이름, 주민번호, 전화번호, 부서코드, 입사일 등
✅ 공통성 + 최소 단위 = 속성!

---

⛔ 주의할 점

• ❌ 이름나이 → 속성은 하나씩 따로!
  → ✅ 이름 / ✅ 나이 ← 이렇게 따로따로 쪼개줘야 함
• ❌ 나이: 29, 30 → 하나의 속성에 값은 하나만!
  → 다중 값 저장하면 데이터 무결성 깨짐.
  → 나중에 ‘정규화’ 파트에서도 중요하게 다뤄짐!

---

🧱 엔터티 - 인스턴스 - 속성 관계

개념설명

엔터티	공통 속성을 가진 정보 집합 (ex. 직원)
인스턴스	엔터티의 한 개별 객체 (ex. 직원 김형석)
속성	엔터티의 공통 정보 단위 (ex. 이름, 나이, 연봉 등)

---

📌 관계 정리

1. 하나의 엔터티는 2개 이상의 인스턴스를 가진다.
   → 집합이기 때문. 1명만 저장하려면 굳이 DB 필요 없음!
2. 하나의 엔터티는 2개 이상의 속성을 가진다.
   → 이름 하나만 저장하면 의미 없음. 최소한 두 개 이상은 있어야 데이터 관리가 됨.
3. 속성은 인스턴스를 설명한다.
   → 직원 emp003의 이름은 김형석, 나이는 27, 연봉은 4700
   → 이런 식으로 속성이 인스턴트를 설명함.
4. 하나의 속성에는 하나의 속성값만 저장해야 한다.
   → ✔️ 나이: 27
   → ❌ 나이: 27, 28

---

🧪 시험에 나올 포인트 요약

포인트체크

 

속성은 더 이상 나눌 수 없는 최소 단위	✅
속성은 엔터티의 공통적 특징	✅
속성은 하나의 값만 저장	✅
속성은 인스턴스를 설명	✅
‘이름나이’ 같이 묶으면 안 됨	✅
속성이 2개 이상 있어야 의미 있음	✅

 

---

 

🧩 식별자란?

📌 정의

• 엔터티 안의 인스턴스를 유일하게 구별해주는 속성(들)의 집합
• 식별자는 절대 중복되면 안 됨
• 보통 **PK(Primary Key, 기본키)**로 설정됨

예시로 설명하면:

직원이라는 엔터티에 4명의 인스턴스가 있고
이름으로 구별하려 했더니 김태우가 두 명이야? → ❌ 식별자 불가
직원 ID(emp_id)로 구분하자 → ✅ 식별자 가능

👉 회원가입 시 아이디 중복 체크가 바로 이 개념과 같음.
→ abc123을 누가 이미 쓰고 있다? → 이건 중복된 식별자! → ❌
→ 따라서 식별자는 고유하고, 중복 없이 유일해야 함

---

🧩 속성의 분류 (특성 기준)

분류설명예시시험 포인트

기본 속성	업무 요구사항으로부터 직접 추출된 속성	이름, 주민등록번호, 전화번호 등	⭐ 일반적
설계 속성	설계 시 추가된 임의 속성 (규칙화 목적)	부서 코드 001, 002 등	⭐ 출제 자주
파생 속성	다른 속성으로부터 계산된 값	부서별 연봉 합계, 나이 (생년월일 기반) 등	❗ 실무에선 지양

📌 파생 속성이 지양되는 이유

• 데이터가 추가될 때마다 모든 관련 데이터 갱신 필요
• 유지보수 어려움 (계산 자동화가 필요해짐)

---

🧩 속성의 명명 규칙

규칙설명

 

현업 용어 사용	실제 업무에서 사용하는 용어 그대로 사용
약어 지양	생략하지 말고 풀어쓰기 (ex. tel → 전화번호)
명사형 사용	‘오늘 배송된 상품’ ❌ → ‘배송 상품’ ✅
전체 모델에서 속성명 유일하게 설정	예: 직원.연락처 / 고객.연락처 → 이름 충돌 피하기

📌 참고:

• 실무에서는 속성명 유일 규칙을 엄격히 지키지 않기도 함
  → 하지만 병합되거나 통합 DB 구성 시 충돌 위험 있음

---

🧩 구성 방식에 따른 분류

이건 PK/SK/FK 등 키 개념과 연결되므로,
여기선 식별자 = PK 개념만 가볍게 기억해두고
→ 나중에 외래키(FK), 대체키(SK)랑 함께 설명하면 더 잘 이해됨!

---

🧠 요약 포인트

키워드한 줄 요약

 

식별자	인스턴스를 유일하게 식별하는 속성
기본 속성	실제 업무에서 필요로 하는 데이터
설계 속성	관리 편의성을 위해 설계자가 만든 코드성 속성
파생 속성	다른 속성으로부터 계산되어 나온 값 (지양)
속성 명명 규칙	현업 용어, 명사형, 약어 지양, 전체 모델 내 유일성 고려

 

 

---

 

🧩 도메인이란?

📌 정의

도메인(Domain) =
👉 하나의 속성이 가질 수 있는 값의 범위와 형태(타입)

📌 쉽게 말하면?

속성 = "이름"이라는 칸
도메인 = "이름 칸에는 어떤 값이 들어갈 수 있는가?"를 정하는 규칙

---

📝 예시로 이해하기

속성도메인 정의

나이	정수만 가능, 0~120까지
이름	문자열만 가능, 최대 5자
전화번호	숫자만 가능, 11자리 (010 포함)
생년월일	날짜 형식(yyyy-mm-dd)

즉, 도메인은

• 데이터 입력 시 허용되는 값의 범위,
• 데이터가 따라야 할 형식,
• 입력 가능 여부 등을 제한/검사해주는 규칙이야!

---

💡 실무에서 도메인이 중요한 이유

• 잘못된 값이 들어가는 걸 방지 (ex. 나이에 '스물다섯' ❌)
• 일관된 형식 유지 가능
• 유효성 검사(validation)와 연계됨

---

🧠 기억 포인트

항목정리

도메인이란	속성이 가질 수 있는 값의 범위
목적	입력 오류 방지, 데이터 일관성 유지
예시	나이 = 0~120, 이름 = 문자 5자 이내 등