이게 바로 개막장 ERD다.

ERD가 뭘까!?

 

Entity Relationship Diagram : 개체-관계 다이어그램

DB 모델링 하는 과정에서 테이블간의 관계를 설명해주는 다이어그램이다.

• Entity : 테이블을 구성하는 객체의 구성성분 (DB에서는 칼럼이 될것이다.)
• Relationship : 관계를 의미하는데 1 대 1 / 1 대 다 / 다 대 다 로 구성되어있다.

**ERM이란 Entity Relationship Modelling 을 의미한다.

실제로 내가 짠 erd 이다

Starbucks 메뉴들에 관하여 ERD를 짠 것이다.

위에것은 내가 짠것이고 모범답안은 아래에 있다.

 

차이점을 보며 중요한것들을 알아보자

 

1. 각각의 네이밍은 어떤사람이 봐도 알아볼 수 있게 지어야한다.

 

ERD관련해서 질문하러갔을때 상태는 신상을 sinsang으로 지어 놓고 카테고리는 cat 이런식이였다.

개발자가 아니라 마케터가 ERD를 봐도 어떤것에 대한 데이터인지 알수 있도록 네이밍을 지어야 한다.

 

2.ERD의 네이밍컨벤션 역시 일관되게 사용하여야한다.

실제 이 ERD의 데이터 테이블과 칼럼네임들은 프로젝트시 변수명으로 이용되기에 네이밍컨벤션 역시 신경써야한다.

 

3.테이블 이름은 복수형태로

테이블이란 다수의 데이터들이 모여있는곳이다.Beverage테이블에는 라떼,아메리카노 등 여러 음료가 들어있기에 결국 복수인것이다.

이렇게 테이블이름을 복수형태로 나타낸다면 복수형태의 네임은 테이블네임이란것을 직관적으로 알 수 있다.

 

4.float and decimal

둘다 소숫점 자리 숫자지만 decimal이 근사치가아닌 정확한 그 값에 대해 다룬다.

주식,영양정보,의학 같이 사람의 목숨,건강 혹은 돈과 직결된것에 대한 데이터들은 decimal로 다루는게 좋을것 같다.

 

5.확장성이란 미리 만들어 놓는것이 아니다.

ERD에 텀블러 사용여부 속성을 만들어놓으면 나중에 사이렌오더 기능을 추가할때 DB수정없이 할수 있을것이라고 생각했다.

이게 확장성인 줄 알았지만 이건 그저 불필요한 리소스를 낭비하게하는 것 일뿐이었다.

 

스타벅스 만들다가 아마존 만들뻔한 ERD

개막장 ERD 탄생 배경

아메리카노와 에스프레소는 영양성분이 똑같다.

즉 영양성분과 일대일이 아닌 다대일 관계가 성립할 수 있다고 생각하였고 그를 뒷받침 하기 위한 근거를 하나 더 찾았다.

바로 음료 + 잔을 동시에 같이 판매하는것이다. 보통이경우에 벤티 or 그란데 사이즈와 똑같은 용량을 제공하며

특별한 잔 or 텀블러에 음료를 같이 담아서 하나의 상품으로써 판매하는것이다.

이에대해 멘토님에게 질문하였는데 이런 답변이 돌아왔다.

"beverages 테이블은 상품이 아닌 음료 그 액체에 대한 정보입니다. 그런 접근이라면 items라는 테이블을 만들어 거기에서 잔에대한 속성을 새로 파서 다루는게 좋을것 같습니다."

이를 기반으로 그러면 items 테이블을 만들고 상품은 breads & beverages만 다루어서 ERD를 짜보도록 하였다.



 

그래서 짠게 저따구다!

주말에 열심히해서 다시 블로깅해야겠다 :(