[Database] 개념적 데이터 모델링(Conceptual Data Modeling)

[Database] 개념적 데이터 모델링(Conceptual Data Modeling)

 

 

 

1. 데이터 모델링이란?

 

앞의 글에서 예시를 든 치킨집 예시를 다시 살펴보자.

2022.07.27 - [IT 지식/Database] - [Database] 개발 세계에서 데이터베이스란 무엇일까?

 

정말 치킨집 정보를 데이터베이스로 관리하고자 한다면, 어떤 과정을 거쳐야 할까?

IT 지식 기반으로 생각하지 않아도, 우리는 어떤 카테고리, 어떤 기준을 가지고 치킨집의 정보를 분할할지를 직감적으로 떠올리게 된다. 또한 우리에게 필요한 정보를 기반으로 카테고리를 생각한다는 것이다. 예를 들어 우리가 필요한 정보가 "저렴한" 치킨집이라면, 그것만 알려면 항목으로 상호명과 메뉴, 가격만 있으면 된다. 그렇지만 저렴한 치킨집의 전화번호까지 알고 싶다면, 전화번호라는 항목을 추가해야 한다.

 

이런 항목들을 생각하고 나면 그 사이의 '관계'에 대해 생각하게 된다. 각 항목별로 관계가 있을 수도 있고, 관계형 데이터베이스처럼 여러 개의 표로 관리한다고 하면, 그 표 별로도 관계가 있을 수도 있다.

 

이런 과정들을 통해서 하나의 데이터베이스를 컴퓨터 언어로 다룰 수 있을 정도로 만드는 것이 '데이터 모델링'이다.

처음에는 추상적인 개념으로 분할을 하고, 이것들을 단순화해서 우리는 명확하게 그 관계를 나타낼 수 있다.

 

어떤 데이터가 존재하는지, 어떤 정보를 원하는지를 생각하고, 각각의 데이터와 테이블 간의 관계도로 설계하고 이것들을 개발 및 데이터 관리에 사용하는 전체적인 과정이 데이터 모델링이라고 할 수 있겠다.

 

 

✏️ 참고 : 데이터 모델링의 순서

개념적 데이터 모델링 -> 논리적 데이터 모델링 -> 물리적 데이터 모델링

 

 

2. 개념적 데이터 모델링(Conceptual Data Modeling)

 

개념적 데이터 모델링의 개념을 살펴보기 위해서는 개체(Entity)를 제대로 알고 가야한다. 개체란, 그룹핑할 카테고리와 같다. 구체적인 데이터를 지칭하는 개념은 아니다. 예를 들어, 우리가 글을 '게시판'을 만든다고 했을 때, 글과 저자, 댓글이라는 게시판의 구성요소가 있다. 바로 그것이 개체로 지칭할 수 있는 것들이다.

 

글이라는 개체 안에는 저자ID, 제목, 내용 등의 데이터들이 들어갈 수 있다. 이처럼 어떤 데이터들을 포괄할 수 있는 개념이 개체, Entity이다. 하나의 디렉터리 같은 것이라고 보면 된다.

 

그럼 저자ID, 제목, 내용과 같은 데이터 수준의 것들은 뭐라고 부를까? 이것들은 '속성(Attribute)'이라고 부른다. 나중에 어떤 표의 column, 열의 항목이 될 것들이다.

 

 

그럼 우리는 회의를 해야 한다. 현실세계에서 추상적인 개념들을 가지고 만들어야 할 데이터들, 버려야 할 데이터들을 선별하고 중요도를 판별해야 한다. 그 기준은 회사 또는 사용자의 정보 요구에 필요한 지, 필요하지 않은 지 일 것이다.

 

데이터 모델링에 있어서 어떤 프로젝트를 같이 하는 사람들이라면, 이 회의는 반드시 모두 참여해야 한다. 기획서에서 다 같이 Entity를 찾고, 그것을 공유하고 어떤 기준으로 분리할지를 UX/UI 디자이너부터 서버 관리자까지 모두 알아야 하는 것이다. 그래야 탈선 없이 모두 같은 방향을 향해 걸어가고, 같은 기준의 데이터를 쌓는 일을 할 수 있을 것이다. 

 

 

 

 

3. 개체-관계 다이어그램(E-R Diagram)

 

1) ERD란?

 

개념적 데이터 모델링을 하는 단계는 엔티티(Entity)와 그들 간의 관계를 발견하고, 그것을 표현하는 것이 주목적이 된다.

사람은 참 추상화를 잘 하는 것 같다. 그중 대표적인 게 그림이다. 그림을 그리면, 시각적으로 정보를 공유할 수 있고, 또한 영속적으로 남길 수 있게 된다.

 

개발 세계에서는 이 그림을 엔티티-관계 다이어그램(E-R Diagram)이라고 한다. 이 그림을 그리는 동시에  DBMS에 독립적인 개념 스키마와 트랜잭션 인터페이스를 설계하기도 한다.

DBMS : Database Management System. DB를 관리하고 운영하는 소프트웨어. MySQL, 오라클, MariaDB 등이 있다.

스키마 : 개체의 특성을 나타내는 속성(Attribute)과 속성들의 집합으로 이루어진 개체(Entity), 개체 사이에 존재하는 관계(Relation)에 대한 정의와 이들이 유지해야 할 제약조건들을 기술한 것.

트랜잭션 인터페이스 : 데이터의 CRUD를 안전하게 처리할 수 있는 인터페이스

 

2) ERD 그리는 방법

 

ERD는 아래와 같이 생겼다.

저자, 글, 댓글을 Entity로 하고, 각 Entity별로 Attribute를 가지고 있는 구조이다.

각 도형과 선, 그리고 엔티티 사이의 선을 보면 작게 선위에 도형으로 표시된 것을 볼 수 있다. 이를 자세하게 풀어서 설명해보고자 한다.

 

 

 

단선은 표시하지 않았지만, 1:1 관계를 나타낸다. 삼지창 모양은 1:N 또는 N:N 관계를 나타내며, 선 위의 동그라미와 선은 옵션 관계를 나타낸다(옵션 관계는 아래의 Optionaliy에서 자세히 살펴본다).

 

이런 식으로 A가 B를 어떻게 원하는지, 어떤 Relation이 들어있는지를 알려주는 것이 ER Diagram이다.

 

 

4. Cardinality, Optionality

 

카디널리티, 옵셔널리티는 두 Entity 타입 간의 관계를 표현한다. 양방향으로 표시하거나 단선으로 표시한다. 위의 그림을 참조하면 되겠다.

 

1) Cardinality

 

Entity 간의 수적인 관계를 명시하는 표현이다. 1:1의 관계에 있는지, 1:N의 관계에 있는지, N:M의 관계에 있는지 등을 나타낸다. 

 

 

(1) 1:1의 관계

 

담임 - 반 이라는 개체 관계가 있다고 하자. 담임은 반을 한 반만 담임해야 하고, 반에 담임은 한 명만 배정된다. 이럴 때, 두 개체는 1:1의 관계를 가진다고 한다. ERD에서 두 개체 사이는 '단선'으로 표시된다.

 

 

(2) 1:N의 관계

 

윗 그림의 저자 - 댓글 관계를 보자. 저자는 댓글을 여러 개 쓸 수 있지만, 댓글은 저자가 한 명일 수밖에 없다. 이런 관계를 1:N의 관계라고 한다. ERD에서는 여러 개 가질 수 있는 개체에 삼지창 모양으로 선을 표현한다. 위의 그림의 네 번째 도형을 보면 표시되어 있다.

 

 

(3) N:M의 관계

 

윗 그림의 저자 - 글 관계를 보자. 일반적으로는 성립할 수 없지만, 글이 수정이 가능하고, 여러 명의 공동 저자가 가능하다고 했을 때, 하나의 글은 여러 저자를 가질 수 있고, 한 작가는 여러 개의 글을 쓸 수 있다. 이 경우 N:M의 관계가 성립한다. 위의 그림의 다섯 번째 도형을 보면 표시되어 있다. 

 

N:M 관계의 경우, 직접 테이블을 활용하여 데이터를 사용하기 어렵다. 연결 테이블을 통해 1:N의 관계로 테이블을 바꾸어준 후(컨버팅) 그 안의 데이터를 사용한다.

 

 

2) Optionaliy

 

개체 간의 관계에서 '필수'와 '선택'을 표시할 수 있는 것이다. 위의 그림의 저자 - 댓글 관계를 보자. 저자는 댓글을 쓸 수 있다. 하지만 댓글은 저자가 있어야 한다. 그렇기 때문에 댓글은 저자에 의존하게 된다. 이 경우, Option의 O를 따서, 의존하는 개체 앞에 O를 쓰고, 독립적인 개체 앞에 선을 그어 표시한다. 개체 간의 옵션적인 관계를 나타낼 때 이러한 ERD 표시를 한다. 위의 그림에서 여섯 번째 도형을 보면 표시되어 있다.