ER 다이어그램 (Feat. 카카오 T)
안녕하세요! 미니입니다. 오랜만에 글을 남기는 것 같습니다. 프로젝트를 수행하고, 교육 듣고 바쁘게 지낸 것 같습니다.
오늘은 데이터베이스를 설계할 때 많이 사용하는 E-R 다이어그램을 설명하고, 프로젝트 수행했던 경험을 공유해보려고 합니다.
ERD란?
시스템의 엔티티들이 무엇이 있는지 어떤 관계가 있는지 나타내는 다이러그램이다. 즉, 현실 세계에서 발생하는 요구사항을 시스템이 이해할 수 있는 수준으로 나타내는 것을 의미한다.
E-R 다이어그램은 Peter Chen에 의해서 소개되었습니다. 해당 논문은 네트워크 모델, Entity-Set과 같은 모델들과 비교하여 엔티티와 관계에 초점을 가지는 데이터 모델링 방법으로 ER다이어그램을 소개했습니다.
Entity, Relationship
Entity (엔터티)
엔터티는 데이터베이스 설계에서 가장 기본적인 개념 중 하나로, 실세계에서 구별 가능하며 독립적인 존재를 의미합니다. 엔터티는 다음과 같은 주요한 특징들이 있습니다.
- 구별 가능성 : 엔터티는 다른 엔터티와 구별될 수 있어야 합니다. 엔터티가 고유의 식별자를 통해 식별될 수 있음을 의미합니다.
- 독립적인 존재 : 독립적으로 존재할 수 있으며, 다른 엔터티와의 관계와는 무관하게 그 자체로 의미를 갖는다.
Relationship (관계)
관계는 두 개 이상의 엔터티 간의 의미 있는 연관성을 나타냅니다. 즉, 엔터티와 엔터이 간의 상호작용이나 연결을 정의하며, ER 모델에서 중요한 구성 요소 중 하나입니다. 관계는 다음과 같은 주요 특징들이 있습니다.
- 다중성 : 관계에 참여하는 엔터티가 가질 수 있는 인스턴스의 수를 나타냅니다. (1:1, 1:N, N:1, N:N)
- 관계 집합 : 동일한 유형의 관계들의 집합입니다.
- 차수 : 관계에 참여하는 엔터티의 수를 표현한다.
Attribute (속성)
엔터티나 관계의 특성을 나타내는 요소로, 각 엔터티 또는 관계가 가지는 데이터를 구체적으로 정의합니다. 속성은 세부 정보를 표현하는 데 사용된다.
카카오 T 예시
팀원들과 함께 ER 다이어그램 작성 프로젝트를 수행하면서 학습하고, 어려웠던 점을 중점으로 작성해보려고 합니다.
프로젝트 선정
처음으로 프로젝트를 위해 팀원 모두가 한장소에 모이게 되었습니다. 자기소개도 하고, 잠시 친해지는 시간을 가지고 난 후 프로젝트 주제 선정을 수행했습니다. 팀원들 모두, 새로운 시스템을 구성하는 것보다는 기존에 서비스되고 있는 대규모 애플리케이션의 ERD를 작성해보자고 했습니다. 모두 학습의 의지가 컸기 때문에 다양한 서비스 아이디어가 나왔다.
대규모의 서비스를 모두 작성하는 것보다는 각 서비스에서 중요한 비즈니스에 대해서 추리는 과정을 거쳤다. 많은 서비스들 중에서 카카오 T와 같은 배차 시스템을 구성하는 것은 어떻게 구성했을 지에 대한 의문을 가지게 되었고, 차량의 위치 데이터에 대해서 궁금했기 때문에 카카오 T 서비스를 선택하게 되었다.
엔티티, 관계 설정
카카오 T에서 택시 서비스를 중점으로 ERD 작성을 위해서 엔터티와 관계를 설정하는 과정을 거치게 되었다. 우리가 택시를 부르는 과정을 생각해본다면, 손님인 우리는 배차를 신청하고, 기사님은 출발점과 도착점을 통해서 배차를 잡는 과정을 거치게 됩니다.
이런 과정을 생각해본다면, 주요 엔터티는 손님 과 기사 가 됩니다. 관계는 배차 신청 과 배차 완료 가 될 것입니다. 사용자 관리에서는 사용자가 사용하는 결졔 수단에 대한 정보가 추가적으로 필요하다고 판단했고, 기사 관리를 위해서 기사가 사용하는 차량에 대한 정보가 필요하다고 판단했습니다.
배차 시스템 ERD
배차 시스템을 구성할 때, 실 생활에서 어떤 순서의 작업이 이루어지는 지 먼저 파악했습니다.
- 손님이 출발지와 도착지를 입력 후에 배차를 신청한다.
- 기사는 손님이 등록한 배차를 확인한 후, 원하는 배차를 선택한다.
다음과 같이 복잡한 절차를 가지는 프로세스를 하나의 테이블에 표현하는 것과 분리해서 표현하는 것에 대해서 갑론을박이 있었다. 많은 데이터를 적재하는 것은 시스템 상의 과부하가 발생할 수 있는 가장 큰 원인된다고 생각했고, 현실 세계를 반영하기 위해서는 배차를 신청하는 프로세스와 배차를 잡는 프로세스가 존재한다고 생각했습니다.
사용자 결제 수단
사용자는 하나의 카드만 등록하는 것이 아니라 다수의 카드를 등록할 수 있다. 그렇기 때문에 1:N의 관계를 가지게 됩니다. 하지만, 가족 계정 관계를 추가하면서 N : N의 관계를 가지는 것이 아닌지에 대해서 혼란스러웠습니다. 이 부분은 가족 계정을 어떻게 관리하는 지에 따라 변경된다고 판단했습니다. (가족 계정은 가족에 필요한 카드를 사용할 수 있도록 합니다.)
사용자 계정은 가족 계정을 생성한 사람의 회원 번호를 추가하고, 이에 포함되는 회원 번호를 추가하도록 했다. 그렇기 때문에 기본적으로는 1:N의 관계를 가지도록 하고, 서버 측 구현을 통해서 가족 계정에 대한 카드도 함께 보여 줄 수 있도록 구현했습니다.
물리적 모델링
이런 다양한 상황들을 함께 고민하면서 ERD를 구성했고, 물리적 모델링까지 구현했습니다.
문자열 처리
물리적 모델링을 수행하면서 데이터를 효율적으로 저장하기 위해서 어떤 데이터 타입을 사용하는 적이 적절할지 고민했습니다. 문자열에 대해서 중점적으로 생각했고, 고정된 문자열 길이를 가지는 데이터는 Char를 구성하고, 가변적인 데이터의 길이는 VarChar를 구성했습니다.
위치 데이터
택시 기사가 영업을 시작할 수 있는 구간이 제한되기 때문에 지역의 위치를 포함할 수 있는 Polygon 데이터 타입을 사용하여서 물리적 모델링을 수행했습니다.
결제 데이터
결제 테이블에서 카드 번호를 저장하는 과정에서 결제 수단 내의 데이터와 직접적으로 참조하는 것은 보안의 목적에서 벗어난다고 판단하여서 외래키를 설정하지는 않았습니다. 또한, 데이터의 마스킹을 추가하도록 했습니다.
아쉬운 점
- 카드 번호, 주민등록번호 등 민감한 정보 보안성 강화
- 택시 차량 위치 데이터 수집 (NoSQL)
- 데이터 백업 및 장애 처리
- 서버측에서 가족 계정 내 데이터도 함께 삭제
다음과 같이 아쉬운 부분들이 있었지만, 프로젝트를 잘 마무리했다. 마지막에 제출 링크를 찾지 못해서 패닉이 오긴했지만, 1분 남기고 제출을 완료했습니다. ㅎㅎ (다음부터는 먼저 꼭 체크하기!!!)
후기
이어드림 교육을 들으면서 첫번째 프로젝트를 수행하게 되었다. 많은 부분에서 팀원들과 커뮤니케이션에 부족한 부분이 있었던 것 같다고 생각이 든다. 팀원의 기분을 생각해서 말하지 못한 점들이 있어서 그렇게 느꼈다. 하지만, 팀원 모두가 함께 열정적으로 프로젝트를 참여했다는 생각이 들었다. 팀원들 모두 직접 무엇인가를 수행하고 싶어했기 때문이다. 좋은 팀원들을 만나게 되어서 프로젝트를 잘 마무리했다고 생각이 들었습니다. 기술적으로 많은 부분에서 부족했기 때문에 추후에 필요한 부분을 지속적으로 수정하려고 합니다.