TIL_19 | [DB] DataBase와 starbucks Modeling

'데이터베이스(DB)가 뭐야?!'라고 물어본다면 말문이 턱! 막히겠지만, 우리는 빅테이터, 데이터베이스 등등 비슷한 단어를 엄청 많이 듣고 살며 엄청 익숙한 단어 중 하나인것은 사실인 것 같다.

과연 DB는 무엇일까?!

DB는 한마디로 컴퓨터 시스템에 저장된 정보 또는 데이터의 집합을 의미

왜 필요할까?

컴퓨터에 Application에서는 데이터가 메모리 상에서 존재한다. 메모리에 존재하는 데이터는 보존이 되지 않기 때문에 애플리케이션을 종료하면 메모리에 있던 데이터가 다 없어진다!

이러한 점(데이터가 다 날라가는...😂)을 막기 위해 DB를 이용한다!

어떻게 DB를 조작할까?

보통 DB는 DBMS(DataBase Management System)라고 불리는 것으로 제어한다. (Oracle, MySQL 등..)

깊이 들어가면 select, insert, update 등등.. 많은것이 있지만.. 오늘은 겉만 핥고 가도 충분!!👌

어떤 종류가 있어?

• 관계형 데이터베이스
• 비관계형 데이터베이스

관계형 데이터베이스

이름 그대로 관계형 데이터 모델에 기초를 둔 데이터베이스 시스템을 말한다. 관계형 데이터란 데이터를 서로 상호관련성을 가진 형태로 표현한 데이터를 말한다.

Primary Key (Id)	name	field
1	code_sign	fullstack
2	tory	Frontend

• 위와 같은 테이블 형태로 만들어 지는것이 관계형 데이터 베이스이다.
• 각각의 테이블은 컬럼(column)과 로우(row)를 가지고 있다.
• 각 로우는 저만의 고유키(Primary Key)를 가지고 있다.
• 이 Primary key를 이용하여 해당 로우를 인용(reference)하게 된다.

그리고 이러한 관계형 데이터베이스의 관계는 연결된 형태에 따라 총 3가지로 나눌 수 있다.

• one to one
• one to many
• many to many

❓테이블들을 연결?
일단 테이블을 연결하기 위해 Foreign Key(외부키)라는 개념을 사용하여 주로 연결한다.

연결 이유는 하나의 테이블에 모든 정보를 다 넣으면 동일한 정보들이 불필요하게 중복되어 저장되기 때문!
바꿔말하자면,

• 중복된 데이터를 저장하지 않음으로 디스크를 더 효율적으로 쓰고,
• 서로 같은 데이터이지만 부분적으로만 내용이 다른 데이터가 생기는 문제가 없어진다.
  -> normalization(정규화)라고 한다!😎

안전해?! (feat.트랜잭션)

물론! 안전하다!

예시를 하나 들자면,
내가 이 글을 보고 있는 분께 1억을 준다고 가정하자. (어디까지나 가정!!)

그럼 계좌이체의 실행 순서는

1. 내 계좌에서 돈을 인출한다.
2. 당신께 돈을 입금한다.
3. 완료 메세지(알림 or 메세지)를 보낸다.

근데 만약, 1번까지만 실행되고, 2번을 처리하는 과정에서 오류가 나서 내 돈 1억만 날라간 상황이라면?! 당연히 안되기 때문에 트랜잭션(Transaction)이라는 개념이 존재한다. (휴...😭)

트랜잭션(Transaction)이란 일련의 작업들이 마치 하나의 작업처럼 취급되어서 모두 다 성공하거나 아니면 모두 다 실패하는걸 이야기한다.

트랜잭션의 수행 보장! ACID🙌

ACID는 데이터베이스 트랜잭션이 안전하게 수행된다는 것을 보장하기 위한 성질을 가리키는 약어이다.

• 원자성(Atomicity)
• 일관성(Consistency)
• 고립성(Isolation)
• 지속성(Durabillity)

이렇게 4가지가 있는데, 해당 속성과 비관계형에 대해서는 나중에 따로 블로깅하겠다!(꼭...🤣🔫)

---

그래서 오늘은 Starbucks의 음료에 대해 Modeling을 해보았다..(쉽지 않았다...🔥)

Starbucks Modeling

우리팀이 정말 있는 머리 없는 머리 쥐어짜서 열심히 만들었지만... 이미지에서 보다 시피 엄청난 지적의 향연들..💣💣💣

해결과정...

처음에 짰을때 Aquery ERD tools에서 짰었는데

1. 아니, 도대체 하나의 테이블에서 Foreign이 한개 이상 뻗어나가지 않는 거에서 멘붕...
2. 화살표의 관계를 그럼 거꾸로 해서 받을 생각을 하니 멘붕
3. 그래서 '하나의 hub 테이블에서 모든 정보를 받아버리자!'라고 생각
4. 하나의 음료는 카테고리와 알러지를 두개 이상 받을 수 있으니 모두다 컬럼에 써서 'Y'/'N'으로 설정하면 되겠지!

그래서.. 왜 틀린건데??

1. 화살표가 도착한 테이블이 '받는것'이 아닌 뻗어온 테이블을 참조한다는 의미!
2. 카테고리 테이블과 알러지 테이블을 각각 써주는 것이 아닌, 컬럼은 name으로 하고, A메뉴가 2개의 알러지 정보를 가진다면 알러지 테이블에 A메뉴에 대한 데이터가 2개 넣으면 된다!👍👍

애초에 생각과 이해가 잘못된 모델...
하지만!
모르기 때문에 성장할 수 있는것처럼, 이제부터라도 DB열등생에서 DB우등생이 되면 된다!!

(근데 왜 자꾸 눈물이... 옾눞룸곡....)

Today, Learned

배운점

• 관계형에 따른 분류(one to one 등...) 특히 1:n, n:n!!
• 테이블의 화살표 방향에 따른 뜻!
• 'Y'/'N'으로 나누고 싶은 Boolean이라면 TINYINT를 쓰기!
• 그리고 그런 이름은 앞에 is_ or has_를 붙여주기!
• 테이블의 이름은 복수형으로
• 테이블의 이름과 같은 컬럼 이름은 지양하자.
• 가격같은 경우엔 DECIMAL 자료형을 이용!

느낀점

• DB는... 말할땐 쉽지만.. 짤때는 어렵다...
• 복습겸 쿠팡을 짜보려 했지만... 머리가 너무 아프다...
• 이 복잡한 녀석을 사로잡기 위해 오늘도 블로깅!!!!!!!!!(제발 잡혀라!!)

오늘의 한마디

열등생은... 우등생이 되기 위한 과정일뿐...!!!!! (내 존재 화이팅🔥)