17. ERD

 

 

지난 포스팅에서 DB Schema 에 대한 설명을 하면서 ERD와 비슷하다는 말을 한 적이 있었다. ERD란 DB Schema처럼 데이터베이스에 저장된 데이터들간의 관계를 다이어그램형식으로 표현한 그림이다. 사용하는 DB에 따라 이를 자동으로 만들어주기도 하는데 ERD Cloud라는 사이트를 이용하여 직접 원하는 ERD를 그려볼 수도 있다. 오늘은 그 두가지 방식중 ERD cloud에서 직접 작성한 내 ERD를 통해 이를 이해해보자!

---

E(Entity) R(Relationship) D(Diagram)

 Entity란 실체, 실재, 객체 라는 의미로 그냥 엔티티라고 부르며 받아들여진다. 즉 하나의 정보에 대한 속성같은 개념으로 받아들이면 편할 것 같다. Relationship이야 그냥 말그대로 관계를 뜻하고 다이어그램은 관계를 도식화한 그림이라고 보면 된다. 즉, 속성들의 관계를 도식화한 그림! 이라고 정리할 수 있겠다. 하나의 서비스를 구축할 때 먼저 ERD를 그려 이 서비스가 제공하는 정보들, 기능들에 대한 설명과 로직을 이 ERD를 통해 제작하고 구현하기 때문에 잘 짜여진 서비스를 만들기 위해서는 우선 치밀하고 빈틈없이, 논리적인 ERD를 먼저 그리는 것 부터 시작이다. 우리가 그림을 그릴때 밑그림이나 구도를 먼저 대충 잡고 디테일하게 완성시켜 나가듯이 개발작업 역시 동일하다고 보면 된다. 도안이 잘 나와야 완성본도 잘나오는 것 처럼! 물론 나중에 추가적인 부분이나 만들다 보니 잘못 짜여진 경우는 그때그때 수정해도 되지만 되도록이면 처음부터 로직을 잘 구성해 놓는게 추후에 편하겠지..

 

ERD 표기법

 ERD를 작성하기 위해 나는 ERD cloud 라는 서비스를 이용했다. 여기서 나이키 쇼핑몰을 참고한 신발 판매 사이트 ERD를 작성해보았다. 

 

아주 간단하게 구성해본 내 ERD

 

 아주 간단하고 짧은시간동안 작성한 ERD이기 때문에 세부적인 관계에 대해서는 손볼 곳이 좀 있으나 일단 표기법을 설명하기 위해 가져와보았다. 기본적으로 데이터간의 관계는 1 : 1 관계, 1 : N 관계, N : 1 관계 마지막으로 N : M 관계가 있다. 일대일, 일대다, 다대일, 다대다 관계라고 편히 부르기도 한다. 또한 각 데이터들을 이어줄때는 각각의 테이블을 다시 합쳐줄 수 있는 고유한 값 PK(Primary Key)가 존재하는데 즉, 지금 이렇게 흩어져있는 테이블을 사실은 PK를 찾아서 하나로 뭉쳐줄 수 있다. 하나의 테이블에는 하나의 PK만 존재하며 PK를 받아온 테이블에는 PK값을 FK(Foreign Key)로 지정하며 이를 통해 어떤 테이블의 PK값을 통해 연결되어 있는지 알 수 있다. 

 

우선 상품을 중심으로 서브카테고리 - 메인카테고리가 다대일 관계를 형성한다. 하나의 메인 카테고리 안에 여러 서브카테고리가 있고 또 그 중 하나의 서브카테고리에 여러개의 상품이 존재하기 때문이다.

 

예를들어 의류, 악세사리, 신발의 메인카테고리중 신발이라는 카테고리 안에 운동화, 슬리퍼, 농구화 등의 서브카테고리가 존재한다. 연결된 선을 잘 살펴보면 카테고리는 하나의 선에서 하위에 문어처럼 생긴 여러개의 작대기로 이어져 있다. 이는 1 : N 관계를 의미한다. 또한 문어처럼 0이 붙어있는 이유는 하위에 해당하는 데이터에 값이 존재하지 않아도 되는 즉 Nullable한 속성을 지니기 때문이다.

 

 

 

 

 

 

1 : N 관계로는 하나의 상품당 여러개의 이미지가 존재하므로 일대다 관계로 구성하였다. 위의 1 : N 관계를 역으로 연결한 선과 같다. (사실 당연하다 일대다나 다대일이나 반대의 의미이지 관계는 같으니까) 또한 여러장의 이미지 중에서 메인 이미지에 해당하는 값은 따로 분류해 주기 위해서 이를 구분지어주었고 TINYINT라는 속성을 통해 1,0의 값으로 메인여부를 판별할 수 있도록 하였다.

 

 

 

 

 

 

컬러와 사이즈는 각각 다양한 사이즈,컬러가 다양한 상품들과 매칭되므로 다대다 관계로 구성하였다. 다대다관계를 구성할 때 직접 연결하지 않고 중간 테이블을 두어 연결한 이유는 직접 연결할 경우에는 나중에 유지보수할 때 굉장히 복잡해지기 때문이라고 한다.

 

 

 

 

하나의 상품이 주문서 하나에 담기기 때문에 이를 1대1 관계에 두었는데 이는 어떻게 생각하느냐에 따라 좀 다른 부분이 있는것 같아서 헷갈렸다. 하지만 상품 하나를 주문할때 여러 회원이 분할해서 결제하지는 않으니까 1대1로 두는것이 맞는것 같다.

 

아무튼 내 ERD는 그래서 대충 이와같은 로직으로 구성되었고 이에 맞추어 실제로 코드도 작성해 보고 있다. 아직 미완성이긴하지만,, 몇개 안되는 내 ERD테이블조차 코드로 하나하나 구현하려니 쉽지않다 ㅠ