이번 글에서는 데이터 생활을 하는데 알아두면 굉장히 유용한 모델링 용어 3가지에 대해서 알아보겠습니다.
엔티티(Entity), 속성(Attribute), 관계(Relationship), 데이터 분석을 하고 있는 분이라면 데이터 모델링에 관심이 없었어도 어디에선가 한두번은 들어본 용어들일 겁니다.
엔티티, 관계, 속성은 우리가 배우고 있는 모델링 방법론인 ER 모델(Entity-Relationship Model)의 근간이 되는 구성 요소들입니다. 매우 당연한 말이지만, ER 모델을 시각적으로 도식화한 ERD를 그리거나 읽을 때에도 이 개념들을 정확하게 알고 있어야 합니다.
처음 들었다면, 이제부터 알아나가면 되고요. 만약 어디선가 들어보긴 했는데 모호하게 알고 있었다면 이번 기회에 개념들을 명확하게 정리해봅시다.
엔티티(Entity)
엔티티는 사람마다, 책마다 정의가 조금씩 다른데요. 개인적으로는 정의부터 읽자면 너무 어렵더라고요. 예시를 먼저 보여드리겠습니다.
<상품>
상품 번호
카테고리
상품 이름
<회원>
회원 번호
회원 이름
이메일 주소
<주문>
주문 번호
주문 날짜
위에서 <상품>, <회원>, <주문>이 각각 엔티티입니다. 엔티티는 상품, 회원, 주문과 같이 업무를 구현하는데 근간이 되는 사물, 사람, 정보, 그리고 이것들을 기초로 해서 발생하는 계약이나 행위들을 성격이 유사한 것끼리 모아놓은 집합입니다.
💡
엔티티와 엔티티 타입(Entity Type)의 차이
우리가 일반적으로 얘기하는 엔티티는 사실 엔티티 타입입니다.
엔티티의 사전적인 의미는 “A thing with distinct and independent existence.” 입니다. 하나의 독립적인 존재라고 번역할 수 있는데요. 예를 들면, 윤선미라는 사람 1명이 엔티티예요. 이런 회원이 여러 명 있는 회원의 집합을 표현하려면 엔티티 타입이라고 부르는 게 정확합니다.
하지만 일반적으로는 엔티티와 엔티티 타입을 구분해서 사용하지 않고 엔티티라고 통칭합니다. 저도 앞으로 편하게 엔티티라고 부르겠습니다.
강한(Strong) 엔티티와 약한(Weak) 엔티티
엔티티를 분류하는 방법은 다양한데요. 여기에서는 한 가지만 소개하고 넘어가겠습니다. 엔티티는 다른 엔티티에 의존하지 않고 독립적으로 존재할 수 있는 강한 엔티티와, 다른 엔티티에 종속적인 약한 엔티티로 분류할 수 있습니다.
대표적인 예가 <상품>과 <상품 가격>입니다. 상품은 독립적으로 존재할 수 있기 때문에 강한 엔티티입니다. 하지만, 상품 가격은 상품에 종속되어 있어 약한 엔티티라고 부릅니다. 어떤 상품이 삭제되면, 상품 가격도 의미가 없어지죠. 약한 엔티티인 <상품 가격>은 상품 번호라는 <상품>의 주 식별자를 상속받아 외래 키로 사용합니다.
<상품>
상품 번호 (PK)
카테고리
상품 이름
<상품 가격>
상품 번호 (FK)
기간
상품 가격
속성(Attribute)
아래 <상품> 엔티티에서 ‘상품 번호’, ‘카테고리’, ‘상품 이름’을 속성이라고 부릅니다.
<상품>
상품 번호
카테고리
상품 이름
속성은 추상화(Abstraction)의 결과물입니다. 추상화는 복잡한 특성을 걷어내고 핵심만을 간추리는 일입니다.
Pablo Picasso, The Bull, 1945
예를 들어, 어떤 쇼핑몰의 상품 중에 아래와 같은 가습기가 있다고 생각해볼게요.
‘상품 번호’, ‘카테고리’, ‘상품 이름’이라는 속성으로 이 상품을 표현하면 ‘189028’, ‘소형 가전’, ‘윤남텍 간편세척 초음파 가습기’라고 표현할 수 있을 거예요.
상품 번호
카테고리
상품 이름
189028
소형 가전
윤남텍 간편세척 초음파 가습기
하지만 이 상품은 이것 외에도 색이 파랗다든지, 세척이 간편하다든지 하는 특성들도 가지고 있습니다. 그런데 왜 <상품> 엔티티에는 이 속성들을 저장하지 않을까요? 색상이나 편리 기능에 대해 정보를 제공하는 기능을 쇼핑몰이 제공하지 않고 있기 때문일겁니다. 이런 경우 파란 색상과 세척의 간편함이라는 특성을 데이터로 저장해놓을 필요가 없으니까요. 다른 말로 하면, 이 특성들이 <상품>이라는 엔티티가 사용되는 업무에 필요하지 않기 때문입니다.
지금까지 한 말들을 요약해볼게요. 속성이란 데이터의 특성을 서술하는 기준입니다. 이 기준은 추상화의 결과물인데, 추상화를 할 때에는 엔티티의 모든 면을 표현하는 것이 아니라 업무에 필요한 특성들만 담아 간결하게 표현합니다.
모델링과 데이터베이스에서 사용하는 용어를 구분하자
지금까지 엔티티, 속성에 대해 얘기해봤습니다. 모델링을 하는 단계에서 사물, 계약 등 개체를 성질이 비슷한 것끼리 모아놓은 집합을 엔티티, 개체의 특성을 서술하는 기준이 속성입니다.
흔히 모델링의 단계를 1. 개념 모델링, 2. 논리 모델링, 3. 물리 모델링으로 나누는데요. 각 단계의 차이점을 지금 자세하게 알 필요는 없지만 개념 모델링과 논리 모델링을 통해 도출한 엔티티와 속성이 물리 모델링 단계에서 비로소 테이블과 컬럼으로 실체화가 된다는 것 정도를 기억해두시면 좋겠습니다.
모델링 시리즈의 초반 글에서는 엔티티라고 얘기해야 하는 상황에서도 계속 테이블이라고 불렀어요. 엔티티보다는 테이블이라는 이름이 이 시리즈를 글을 읽는 분들에게 더 익숙했기 때문에, 쉽게 이해하시라고 일부러 그렇게 설명을 한건데요. 이제 엔티티, 속성이라는 용어를 배우셨으니까 ‘엔티티’, ‘속성’, ‘테이블’, ‘컬럼’이라는 용어들을 정확하게 사용하겠습니다.
여기에 앞으로 자주 사용할 용어를 하나 더 설명하자면 엔티티라는 집합의 구성 요소가 되는 개체 1개를 인스턴스라고 합니다. 인스턴스는 데이터베이스에서 데이터 1행이 됩니다.
개념 모델링, 논리 모델링
물리 모델링 (데이터베이스)
엔티티
테이블
속성
컬럼
인스턴스
데이터 1행
식별자(Identifier)
식별자는 조금 특별한 속성입니다. 많은 속성 중에서도 엔티티에서 개별 데이터(인스턴스, Instance)를 식별할 수 있게 만드는 속성을 식별자라고 부릅니다. 앞 글에서 다룬 기본 키(Primary Key, PK)가 식별자의 다른 이름입니다. 속성이 식별자가 되기 위해서는 4가지 조건을 만족해야 합니다.
유일성: <주문> 엔티티의 ‘주문 번호’ 속성처럼 개별 데이터를 구분할 수 있도록 유일한 값을 가져야 함
최소성: 데이터를 유일하게 식별할 수 있는 최소한의 속성 집합이어야 함
불변성: 값이 변하지 않아야 함
존재성: 반드시 데이터 값이 존재해야 함 (Null이 아니어야 함)
유일성, 최소성 조건은 후보 키 조건과 동일합니다. 우리는 여러 후보 키들 중 불변성, 존재성을 만족하는 키를 기본 키, 식별자로 사용합니다. 예를 들어, 아래와 같은 엔티티를 정의했다고 생각해봅시다. 4개의 속성 중 학번과 주민등록번호 둘 다 유일성과 최소성을 만족하는 후보 키입니다. 그렇다면 학번, 주민등록번호 중에 어떤 키를 기본 키로 설정하는게 좋을까요?
<학생>
학번
이름
학과
주민등록번호
주민등록번호는 변할 수도 있고, 존재하지 않을 수도 있습니다. 예를 들어, 성별 정정을 하면 주민등록번호를 바꿀 수 있습니다. 또 외국인이라면 주민등록번호가 없겠지요. 하지만 한 번 부여한 학번은 변하지도 않고, 학교의 학생이라면 반드시 존재합니다. 따라서 주민등록번호보다는 학번을 기본 키로 설정하는 것이 합리적입니다.
아래 예시에서 회원 1명이 여러개의 주문을 할 수 있기 때문에 회원과 주문의 관계는 일대다 관계입니다.
주문 인스턴스의 집합인 주문 엔티티와, 주문에 어떤 상품들이 속해있는지를 담고 있는 주문 상세 엔티티도 일대다관계입니다. 하나의 주문에 1개 또는 여러개의 상품이 속해있을 수 있기 때문입니다.
다대다(M:N) 관계
A 엔티티의 인스턴스 하나와 B 엔티티 인스턴스 여러개가 대응되고, 또 B 엔티티의 인스턴스 하나와 A 엔티티의 인스턴스 여러개가 대응 될 때 다대다 관계, M:N 관계라고 부릅니다. 1개의 강의가 여러 명의 수강생을 가질 수 있고, 수강생 1명이 여러개의 강의를 들을 수 있기 때문에 강의와 수강생의 관계는 M:N 관계입니다.
선택성(Optionality)
엔티티의 인스턴스에 대해 상대 엔티티에 정보가 존재하는지 여부를 나타냅니다. 양쪽 필수, 한쪽 필수, 양쪽 선택이 있을 수 있는데 하나하나 살펴보겠습니다.
한 엔티티의 인스턴스에 대해 상대 엔티티에 정보가 존재하고, 그 반대도 성립하는 경우입니다.
주문 엔티티가 있으면 반드시 주문 상세 엔티티도 1개 또는 그 이상 있을 수 있기 때문에 주문 상세 엔티티 측에는 One or many 표기를 해주었습니다. 주문 상세 인스턴스 1개에 주문 인스턴스는 반드시 1개만 대응되므로 주문 엔티티 측에는 One and only one 표기를 해주었습니다. 양쪽 모두 하나의 인스턴스에 대해 상대 엔티티에도 정보가 1개 이상 존재해야 하므로 양쪽 필수 관계입니다.
한쪽 필수(Mandatory - Optional)
한 엔티티의 인스턴스에 대해서는 상대 엔티티에 정보가 존재하지만, 그 반대는 성립하지 않는 경우입니다.
회원과 주문의 관계가 한쪽 필수 관계입니다. 주문을 한 사람은 반드시 회원에 정보가 있겠지만, 회원 중에는 주문을 하지 않은 회원이 있을 수 있으니까요. 주문 인스턴스 하나와 대응되는 회원 인스턴스는 반드시 1개여야 하므로 One and only one 에 표현을 했습니다. 또한, 회원 1명은 하나도 주문하지 않을 수 있지만 여러개의 주문도 할 수 있기 때문에 Zero or many 표기를 주문 엔티티에 붙여주었습니다. 주문 인스턴스는 회원 인스턴스와 반드시 대응되어야 하지만, 회원 인스턴스는 그렇지 않기 때문에 한쪽 필수 관계입니다.
양쪽 선택(Optional - Optional)
양쪽 모두 필수가 아닌 관계입니다. 요즘에는 로그인을 하지 않고도 물건을 살 수 있는 온라인 쇼핑몰들도 있는데요. 그런 경우 회원과 주문의 관계가 양쪽 선택 관계입니다.
주문은 1개의 회원 정보를 가지거나 그러지 않을 수 있기 때문에 Zero or one 표기를 해주었습니다. 회원 1명 당 주문은 여러개가 있을 수 있으므로 Zero or many 표기를 해주었습니다.
지금까지 얘기한 표기법을 체계적으로 정리해보면 아래와 같습니다. Mandatory는 1개 이상은 꼭 있다는 뜻이기 때문에 기호 ‘|’를 사용하고, Optional은 대응되는 것이 없을 수 있다는 의미로 기호 ‘O’을 사용한다고 생각하면 굳이 외우지 않아도 이해할 수 있습니다.
관계수(Cardinality)
선택성(Optionality)
표기
의미
One (-|-)
Mandatory (|)
-|-|-
One and only one
ㅤ
Optional (O)
-O-|-
Zero or one
Many (-<)
Mandatory (|)
-|-<
One or many
ㅤ
Optional (O)
-O-<
Zero or many
💡
관계 표기를 가장 쉽게 읽는 방법
무조건 박스와 먼 쪽부터 O, |, <를 각각 0, 1, 1 이상으로 읽으면 됩니다.
예를 들어, 주문 쪽 박스의 Crow’s foot을 읽어보면 O, < 입니다. 회원 인스턴스 하나 당 주문 인스턴스가 0개부터 1개 이상까지 관련될 수 있다는 것을 의미합니다. 회원 쪽 박스의 Crow’s foot은 |, | 입니다. 주문 인스턴스 하나 당 회원 인스턴스가 1개만 존재할 수 있음을 의미합니다.
마무리
지금까지 엔티티, 속성, 관계에 대해 다양한 이야기들을 나눠봤습니다. 하고싶은 얘기가 더 많았지만 이 정도만 알아도 기본은 안다고 하기에 충분합니다. 앞으로 엔티티, 속성과 테이블, 컬럼 용어를 구분하여 사용할 수 있게 되었습니다. 또 관계 표기를 쉽고 정확하게 읽을 수 있게 되었습니다.
다음 글에서는 이 내용을 바탕으로 ERD(Entity Relationship Diagram) 읽는 방법에 대해서 좀 더 자세하게 이야기를 해보겠습니다.
윤선미
