04. 관계형 데이터베이스 모델링 [ERD]

모델링이란,
문제를 현실로 부터 뜯어내,
고도의 추상화 과정을 거친 후, 컴퓨터라는 새로운 현실로 옮겨담는 것

다음 유튜브 강의를 듣고 내용을 요약해 작성했다. 

 

[생활코딩 - "RDB모델링법"]

https://www.youtube.com/watch?v=zZmRQHgLhMo&list=PLuHgQVnccGMDF6rHsY9qMuJMd295Yk4sa&index=2

https://opentutorials.org/module/4134/25270

 

[오용철의 데이터베이스 모델링]

https://www.youtube.com/channel/UCF5CqIVuw0S05ihUIb-HtAA/videos

 

[생활코딩 강의의 실습링크]

normalization 실습 

denormalization 실습

---

RDB

: 관계형 데이터베이스

• 내포관계를 허용하지 않음

 

데이터 모델링 단계

1. 업무파악
2. 개념적 데이터모델링 : 구성하는 것들의 개념적 의미 파악
3. 논리적 데이터모델링 : key, entity 간의 관계 파악
4. 물리적 데이터모델링 : 사용할 DB선택, 코드로 구성

---

ERD

: Entity Relationship Diagram

구성요소	DB요소	table구성	표현(diagram)	예시
그룹	Entity	table	□	댓글
정보	Attribute	column(열)	○	작성일, 작성자, 댓글본문
관계	Relation	PK / FK / JOIN	◇	작성한다, 속하다

• Tuple - row
• 꿀팁 : 기획서 UI에서, "읽기"화면보다 "쓰기"화면에서, Entity를 찾아내기 쉬움
• PK(Primary Key) 기본키
• FK(Foriegn Key) : 다른 table에서 같은 attribute를 key로 사용할 때 외래 키(foriegn key)라고 한다.

---

Identifire 식별자

고유하게 구분하는 것 ___ ex) user_id

• 후보키(candidate key) : attribute 중, '고유한' 속성을 갖고 있어, identifire로 쓰일 자격을 갖춘 attribute 다음과 같이 두가지로 구성된다.
  1. 기본키(primary key)
  2. 대체키(alternate key) 후보키 중, identifier로 쓰일 '1.기본키'를 제외한 나머지는 모두 '2.대체키' 라고 지칭
  • 후보키가 없을 경우, 인위적으로 identifire 용 attribute를 만들어주어야 함!
  • ERD에서, 밑줄 친 것이 identifier
• 중복키(composite key) : attribute 중, 2개 이상 함께 사용해야만 '고유한' 속성을 갖는 attribute ex) 서울_14반, 제2부서_1번직원
• 외래키 (foriegn key) : 한 table의 primary키가 다른 table의 attribute와 같아, 관계가 연결될 때 이를 foriegn 키라고 한다.

---

Relationship

1. Cardinality : 기수,(1,2,3,...)

1:1 관계 - 1:n 관계 -< n:m 관계 >-<

1. Optionality :

필수적 mandatory | 선택적 Optional o

---

유용한 프로그램

• .drawio : ERD 다이어그램 그리기 툴
• erd.yah.ac : entity relational 선택 Helper 프로그램. (선택을 도와줌)
• ermaster.sourceforge.net : '3.논리적 데이터모델링' Helper 프로그램. (eclipse 내에서 실행)

---

3. 논리적 데이터모델링

• foriegn 키가 없는 table을 먼저 만들기 !
• foriegn 키는 중복이라고 생각하지 않음

Mapping table

: n:n관계의 두 table을 이을 때, attribute에 해당하는 값이 2 개 이상인 문제가 발생함. 이를 해결하기 위해, mapping table을 이용한다.

---

4. 물리적 데이터 모델링

• find slow query : DB에서, 여러개의 query 중 병목 현상이 발생하는(느려지는) 쿼리를 찾을 수 있는 방법(db마다 다름)
• DB 성능 향상시키는 방법

1. denormalization (역정규화, 반정규화) : 대신 치뤄야될 대가가 많음 (거의 안 씀)
2. index : 행에 대한 읽기성능 비약적으로 향상, 단, 쓰기 성능 ↓ (저장공간, 시간 많이 소비)
3. application 영역에서 cache(저장영역) 사용하기. → DB 부하 줄임

• cache에 '입력에 따른 실행결과'를 따로 저장함으로써, 'index로 인한 쓰기 성능 저하(2번 방법)'를 막음

---

denormalization (역정규화)

• normalization : write를 위해 read의 성능을 희생하는 것 (table이 여러개로 쪼개짐)
• denormalization :
• 단, normalization을 한다고 해서, 반드시 성능이 떨어지는 것은 아님!
• 반드시, normalization이 denormalization 보다 우선시 되어야 함
• 법칙 이아닌, -> 임의로 본인이 고치는 과정임. 즉 이 아래의 과정은 역정규화 사례들로만 봐주길!

1. JOIN 을 줄이기 -> 성능 향상 : 전부 normalization을 해버려, 원하는 row에 대응되는 다른 attribute(cul)을 찾는데에 join이 너무 많이 사용된다면 부하가 걸리므로, 차라리 table에 중복을 허용해서 (denormalization) attribute를 함께 쓰고, join을 줄임
2. Group by 를 줄임 : 각 author가 글을 몇개 썼는지 알기 위해, attribute 를 추가해 topic이 db에 추가 될 때마다, counting을 함
   • 단, 이 count값을 항상 유지해야하기 때문에, 더 무겁고 가벼운 정도를 따져서 적용시켜야됨
3. table을 column 기준으로 쪼개기 : 유독 용량이 큰 attribute는, 해당 attribute를 PK와 함께 다른 table로 쪼갬 -> 그럴경우, 용량 큰 attribute에 항상 접근할 필요가 없으므로 성능 향상
   • 각 쪼갠 table 1, 2를 다른 computer에 따로 저장해 분산(서버분리)하면 성능 향상도 가능 ('샤딩' ??? )

table을 row 기준으로 쪼개기 : data가 너무많은 경우, 범위별로 쪼개기 가능 (read 수월) 4. 관계의 역정규화 (지름길 생성) : FK 추가를 통해 JOIN을 줄임 1이랑 비슷

---