1. 결과물
2. Modeling 근거
1. 계속 같이 사용되지 않는 정보와 재사용 되는 정보는 나누어서 Table에 저장
- 음료의 사진, 설명은 데이터를 불러올 때가 있고 불러오지 않을 때가 있으니 나누어서 저장
- 음료의 영양정보는 재사용 됨으로 나누어서 저장
2. Many-to-Many, One-to-Many 관계로 분류 할 수있는 정보는 Table 분류
- 음료(many)-카레고리(one)의 관계과 음료(many)-알러지요인(many)의 관계는 나누고, many-to-many관계는 중간에 Relation 넣어주기
3. 고민🤷♂️
모델링을 하면서 근거를 세우고 모델링을 하는 과정속에서 많은 고민이있었다.
Q. Description 같이 음료와 일대일 관계를 유지하지만 쓰일때가 있고 안쓰일때가 있는 정보를 어떻게 관리해야 할까?
A. 스타벅스 페이지의 음료를 영양정보로 검색하는 창을 보면 Description, img는 사용하지 않을 때가 있는데 음료와 같은 table에 넣는다면 자원의 낭비가 있을 것!Q. Description 같은 테이블은 굳이 음료를 가르키는 FK를 가질 필요가 없이 PK=FK가 되면 안될까
A. PK=FK가 하면 안되는 방법은 아니지만 외래키는 여러번 불려올 수 있고, 데이터가 확장 될 것을 고려하여 PK=FK로 만들지 않고, 음료를 가르키는 FK속성인 열을 추가로 만든다Q. 위의 방법대로 만들면 딱 지금의 스타벅스 페이지 에서는 효율적으로 데이터를 불러 올 수 있는데, 데이터가 확장 되거나 또는 페이지가 변하거나 할 때에는 모델리을 또 다시 바꿔주어야 해서 비효율적이지 않을까..? 그리고 데이터의 관계에 대해서 초점을 맞춰보면 description을 나누지 않는것이 좋지 않을까...?
3. 문제점 및 보완
- img는 나중에 상품의 사진이 추가 될 가능성(데이터의 확장)이 있기에 Table 분리
- 모델링은 딱 모델링만 보아도 정보를 쉽게 알 수 있도록 굳이 나누지 않아도 되는 one-to-one관계는 나누지 않는다.
- 이 DB를 갖고 웹 페이지에서만 활용하는 것이 아니고 데이터 분석, 다른 페이지에서 사용 등 여러가지 방면으로 사용 할 수 있기 때문에 많은 Table분할을 하지 않도록!!
4. Conclusion
데이터 모델링을 실제로 해보면서 많은 고민의 시간을 가졌다. 이렇게 하면 어떨까 저렇게 하면 어떨까 스스로에게 질문을 던졌고, 그 질문에 대답하기 위해 이유를 찾았다. 또한 내가 작성한 모델링이 근거있는 모델링이 될 수 있도록 근거에 대해서 많은 고민을 했다. 고민을 하다보면 A가 충족이 되면 B가 충족이 되지 않고 B를 충족하면 C를 충족하지 못하는 경우가 발생했다...! 모델링은 정답이 없기에 자주 연습하면서 효과적인 모델링의 방법을 찾아야 하며, 이러한 실습이 나중에 프로젝트, 현업에 가서 데이터모델을 구상하는데 큰 도움이 될 것 같다.
느리더라도 정확하게 알고가자🔥
20.08.10 위코드 2주차 화요일
