데이터베이스 개체

Database Entity
데이터베이스에서 관리하고자 하는 실세계의 대상을 추상화한 것. 데이터 모델링에서는 엔터티라고 부른다.

데이터베이스 개체는 데이터베이스 설계에서 중요한 개념으로, 독립적으로 식별될 수 있는 객체 또는 데이터를 표현하는 실제 실체를 의미한다. 개체는 데이터베이스에서 관리하고자 하는 실세계의 대상을 추상화한 것이다. 각 개체는 속성을 가지며, 데이터베이스에서 이를 테이블로 구현할 수 있다.

다른 말로, 현실 세계에서 존재하는 대상 중 데이터베이스에 저장할 필요가 있는 것들을 의미한다. 예를 들어, 사람, 제품, 주문 등이 데이터베이스에서 개체로 표현될 수 있다. 개체는 데이터베이스에서 고유하게 식별될 수 있는 것이 특징이다.

특징

고유성: 각 개체는 기본 키(Primary Key)를 통해 고유하게 식별된다. 예를 들어, 학생 개체는 학생 ID로, 제품 개체는 제품 ID로 식별될 수 있다.
속성(Properties): 개체는 여러 속성을 가지며, 속성은 개체의 특징을 나타낸다. 예를 들어, 학생 개체는 이름, 나이, 학년 등의 속성을 가질 수 있다.
독립성: 개체는 데이터베이스에서 독립적으로 존재할 수 있으며, 다른 개체와 관계를 가질 수 있다.

예시

학생(Student):
- 속성: 학생 ID, 이름, 나이, 전공
- 설명: 학생은 데이터베이스에서 관리할 주요 개체 중 하나이며, 고유한 학생 ID로 식별될 수 있다.
코스(Course):
- 속성: 코스 ID, 코스명, 학점, 교수명
- 설명: 코스는 대학에서 제공하는 수업 정보를 담은 개체이다. 코스 ID를 통해 각 코스를 고유하게 식별할 수 있다.
주문(Order):
- 속성: 주문 ID, 고객명, 주문일, 배송지
- 설명: 주문은 고객이 제품을 구매할 때 생성되는 정보로, 주문 ID로 고유하게 식별된다.

엔터티 용어

SQLD 등 데이터 모델링 분야에서는 개체를 주로 엔터티(Entity)라고 부른다. 엔터티는 같은 성격을 가진 대상의 집합이고, 그 집합에 속한 개별 대상 하나하나를 인스턴스(Instance)라고 한다. 인스턴스가 가지는 성질이 속성이다.

엔터티: 사원
인스턴스: 사번 1001 김철수, 사번 1002 이영희, …
속성: 사번, 이름, 입사일자, 부서코드

모델링 용어와 데이터베이스 용어

데이터 모델링(논리)	관계형 모델(이론)	데이터베이스(물리)
엔터티(Entity)	릴레이션(Relation)	테이블(Table)
인스턴스(Instance)	튜플(Tuple)	행(Row)
속성(Attribute)	애트리뷰트(Attribute)	칼럼(Column)
식별자(Identifier)	키(Key)	기본키(PK) 제약
관계(Relationship)	참조 관계	외래키(FK) 제약
도메인(Domain)	도메인	데이터 타입, CHECK·NOT NULL 제약

엔터티의 특징

데이터 모델링에서는 어떤 대상이 엔터티가 되려면 다음 조건을 만족해야 한다고 본다. 조건을 만족하지 못하면 엔터티가 아니라 다른 엔터티의 속성이거나, 모델에 넣지 않아도 되는 대상일 가능성이 높다.

특징	설명
업무에 필요한 정보	해당 업무에서 필요하고 관리하고자 하는 정보여야 한다. 같은 '환자'라도 병원 시스템에는 필요하지만 일반 쇼핑몰에는 필요 없다.
식별 가능	유일한 식별자로 인스턴스를 구별할 수 있어야 한다.
인스턴스의 집합	영속적으로 존재하는 인스턴스가 두 개 이상이어야 한다. 인스턴스가 하나뿐인 대상(예: 회사 자신의 정보 한 건)은 집합이라 보기 어렵다.
업무 프로세스에서 이용	업무 프로세스가 그 엔터티를 생성·조회·수정·삭제하는 등 실제로 이용해야 한다. 이용하는 프로세스가 없다면 잘못 도출되었거나 프로세스 분석이 빠진 것이다.
속성 보유	반드시 속성을 가져야 한다. 식별자 외에 속성이 하나도 없다면 엔터티로 보기 어렵다(단, 관계 엔터티는 두 엔터티의 주식별자만 상속받아 속성으로 가질 수 있다).
관계 보유	다른 엔터티와 최소 한 개 이상의 관계가 있어야 한다.

관계 보유 조건의 예외: 통계성 엔터티(집계 결과를 따로 저장한 것), 코드성 엔터티(여러 엔터티가 공통으로 쓰는 코드 목록), 시스템 처리용 내부 엔터티(트랜잭션 로그 등)는 관계를 그리면 모델이 지나치게 복잡해지므로 관계를 생략할 수 있다.

엔터티의 분류

SQLD 출제 범위에서 쓰는 분류다.

유무형에 따른 분류

분류	설명	예
유형 엔터티	물리적 형태가 있고 안정적이며 지속적으로 활용되는 엔터티	사원, 물품, 강사
개념 엔터티	물리적 형태는 없지만 관리해야 할 개념적 정보에서 도출되는 엔터티	조직, 보험상품
사건 엔터티	업무를 수행하면서 발생하는 엔터티. 발생량이 많고 각종 통계 자료에 이용된다.	주문, 청구, 미납

발생 시점에 따른 분류

분류	설명	예
기본 엔터티(키 엔터티)	다른 엔터티에 의존하지 않고 독립적으로 생성되며, 자신만의 주식별자를 가진다. 다른 엔터티의 부모 역할을 한다.	사원, 부서, 고객, 상품
중심 엔터티(메인 엔터티)	기본 엔터티로부터 발생하며 업무의 중심 역할을 한다. 데이터 양이 많고, 다른 엔터티와 관계를 통해 행위 엔터티를 만든다.	계약, 사고, 청구, 주문, 매출
행위 엔터티	두 개 이상의 부모 엔터티로부터 발생하며, 내용이 자주 바뀌거나 양이 늘어난다. 상세 설계나 프로세스와 상관 모델링을 하면서 도출된다.	주문목록, 사원변경이력

엔터티 명명 규칙

가능하면 현업에서 사용하는 용어를 쓴다.
약어는 되도록 쓰지 않는다.
단수 명사를 쓴다. '사원들'이 아니라 '사원'이다.
모든 엔터티에서 유일한 이름이어야 한다.
엔터티가 생성되는 의미대로 이름을 붙인다. 예를 들어 고객이 제품을 주문할 때 생기는 엔터티라면 '고객제품'이 아니라 '주문'으로 짓는다.

개체와 관계(Entity vs Relationship)

개체(Entity)는 데이터를 저장할 수 있는 독립적인 실체를 의미한다.
관계(Relationship)는 두 개체 간의 연결을 의미한다. 예를 들어, 학생과 코스는 "수강"이라는 관계를 가질 수 있다. 이때, "수강"은 학생과 코스 사이의 관계를 나타낸다.
관계의 종류(1:1, 1:N, M:N)와 표기는 데이터베이스 관계 유형, 데이터베이스 카디널리티 문서를 참고한다.

약한 개체(Weak Entity)

일반적인 개체와는 달리, 약한 개체(Weak Entity)는 고유하게 식별될 수 없으며, 다른 개체에 의존해야만 존재할 수 있다. 예를 들어, 주문 개체에 속한 "주문 항목"은 "주문" 개체 없이는 독립적으로 존재할 수 없다.

정확히는 약한 개체도 자기 속성만으로는 식별되지 않을 뿐, 부모의 식별자와 결합하면 식별된다. 주문 항목은 (주문 ID, 항목 순번)으로 식별되며, 이처럼 부모의 식별자가 자식의 식별자에 포함되는 관계를 SQLD에서는 식별 관계라고 한다. 자세한 내용은 데이터베이스 식별자 참고.

약한 개체 예시

주문 항목(Order Item):
- 속성: 주문 항목 ID, 상품명, 수량, 가격
- 설명: 주문 항목은 고유하게 식별될 수 없으며, 반드시 주문 ID에 의존해야 한다. 이를 통해 각 주문에 포함된 여러 상품 항목을 관리할 수 있다.

강한 개체(Strong Entity)

데이터베이스 개체란 일반적으로 강한 개체를 의미한다. "강한 개체"라는 표현은 약한 개체가 아닌 개체를 구분하여 부르기 위한 표현으로, 비교하고 구분해야 하는 상황이 아니면 독립적으로 잘 쓰이진 않는 말이다.

슈퍼타입과 서브타입

여러 엔터티가 공통 속성을 많이 가지고 일부 속성만 다를 때, 공통 부분을 슈퍼타입(Supertype) 엔터티로, 다른 부분을 서브타입(Subtype) 엔터티로 나누어 표현한다. 예를 들어 '고객'을 슈퍼타입으로 두고 '개인고객'(생년월일)과 '법인고객'(사업자번호)을 서브타입으로 둔다. 이 관계를 데이터베이스 ISA 관계라고도 한다.

배타적(Exclusive) 관계: 슈퍼타입의 인스턴스가 서브타입 중 하나에만 속한다. 고객은 개인고객이거나 법인고객 중 하나다.
포괄적(Inclusive) 관계: 슈퍼타입의 인스턴스가 여러 서브타입에 동시에 속할 수 있다.
물리 모델로 바꿀 때는 슈퍼타입과 서브타입을 각각 테이블로 만들거나, 서브타입마다 슈퍼타입 속성을 합쳐 테이블로 만들거나, 하나의 테이블로 통합하는 방법 중에서 데이터 양과 조회 방식에 맞춰 고른다.

시험 포인트

엔터티의 특징 중 맞지 않는 것을 고르는 문제: 인스턴스는 두 개 이상, 반드시 속성 보유, 최소 한 개 이상의 관계(통계·코드성 엔터티는 예외)
발생 시점 분류에서 예시 구분: 기본(사원·부서·고객·상품), 중심(주문·계약·매출), 행위(주문목록·변경이력)
유무형 분류에서 예시 구분: 유형(사원·물품), 개념(조직·보험상품), 사건(주문·청구)
엔터티는 집합, 인스턴스는 그 원소다. 엔터티–테이블, 인스턴스–행, 속성–칼럼의 대응을 기억한다.
엔터티 이름은 단수 명사, 현업 용어, 전체 모델에서 유일

같이 보기

참고 문헌

Chen, P. P. (1976). "The Entity-Relationship Model—Toward a Unified View of Data". ACM Transactions on Database Systems, 1(1), 9–36. doi:10.1145/320434.320440
Codd, E. F. (1970). "A Relational Model of Data for Large Shared Data Banks". Communications of the ACM, 13(6), 377–387. doi:10.1145/362384.362685
한국데이터산업진흥원 – SQL 개발자(SQLD) 시험 과목