[SQL][Database] 관계형 데이터 모델링(part1,2)

 

데이터 모델링의 순서

업무파악 -> 개념적 데이터 모델링 -> 논리적 데이터 모델링 -> 물리적 데이터 모델링

 

관계형 데이터 베이스 : 정보를 표에 담는 것을 목표로 한다

 

즉, 데이터 모델링 : 복잡한 현실을 컴퓨터에 담는법

 

 

데이터 모델링의 순서

1. 업무파악 : 우리가 하려고 하는 일이 뭐냐 (기획서를 뱉는다)
2. 개념적 데이터 모델링 : 어떤 개념이 있고 어떻게 상호작용하는지를 파악 (ERD를 뱉는다)
3. 논리적 데이터 모델링 :  관계형 데이터 모델링에 맞는 표로써 개념을 전환하는 것 (표를 뱉는다)
4. 물리적 데이터 모델링 : 어떤 데이터 베이스제품을 선택할 것인지 (코드를 작성)

데이터 모델링이란

"데이터를 현실로 부터 뜯어내서 고도의 추상화 과정을 거쳐서 컴퓨터에 담는 것"

 

 

업무파악

실무자들과 정확한 소통이 중요하다

그래서 UI (User Interface)를 같이 그려보는 것이 좋다 -> 사람들이 기계를 작동할 때 사용하는 조작장치

 

우리의 생각을 일치시키는 것이 중요함

 

이 UI를 간편하게 그릴 수 있는 tool

 

 

KAKAO Oven

https://ovenapp.io/

OvenApp.io

실제로 현업에서도 많이 쓴다고 함

이런걸 할 수 있다

 

이러면 의사결정자들 서로의 생각을 동기화할 수 있다

또한 모델링과 UI를 같이 진행하면

UI가 모델링을 모델링이 UI를 검증하는 double check효과를 볼 수 있다

 

개념적 데이터 모델링

파악한 업무에서 개념을 뽑아내는 과정

 

사용하는 도구 : ERD

 

ERD(Entity Relationship Diagram)

이렇게 기획서를 쉽게 볼 수 있도록 해줌

 

세가지의 관점을 제공해줌

즉, 현실로 부터 개념을 인식하는 도구이며 다른 사람이 이해하기 쉽게 해주는 도구이다

 

또 다른 장점

ERD를 매우 쉽게 표로 바꿀 수 있다

https://app.diagrams.net/

Flowchart Maker & Online Diagram Software

이거 쓰면 ERD 쉽게 그릴 수 있다

 

관계형 데이터 베이스에는 둘중 어떤 모델이 더 잘 어울릴까? (아래의 모델)

왜??

관계형 데이터 베이스 (RDB)는 내포관계를 포함하지 않는다

또한 만일 내포관계를 구현했다고 해도

표의 column이 많을 때 글의 목록이 필요하다고 하면

위의 표를 전부다 가지고 와야한다 (메모리 낭비)

또한 중복이 발생할 수 있고 이를 처리할 수 없다

그래서 이런 식의 구조가 어울린다

 

장점

주제에 따라서 데이터를 그룹핑할 수있다

글에 대한 정보가 필요하다고 하면 글의 테이블만 가지고 오면된다 (메모리 효율적)

위와 같이 Join을 통해 언제든지 필요한 table을 합성해낼 수 있다.

 

ERD의 구성 요소

Entity -> table : attribute를 Grouping한 것 (네모)
Attribute -> column : 구체적인 데이터 (동그라미)
Relation -> PK(밑줄) ,FK : entity들 간의 관계 (마름모)
Tuple -> row

 

 

제일 먼저 할 일은 기획서에서 Entity를 찾아내는 것이다

1. Entity 

사람은 본능적으로 연관된 데이터를 묶는 능력이 있다...

표를 나타내기에 적합한 타이틀을 예상해보고 좋으면 그대로 쓰면 되고 아니면 수정하는 방식으로

 

 

2. Attribute

Entity 속에 구체적인 데이터가 무엇인지 찾는 것

여기서는 제목 본문이 attribute이다

저자 목록 같은 경우는 Select box 즉, 좀더 복합적인 속성이므로 별도의 entity로 독립시켰다

(이 경우는 Relation으로 이어나가야 한다)

 

 

Identifier : Entity에 있는 Attribute 중에서 대표 선수를 뽑는 것 (식별자)

-> 원하는 대상을 정확하게 타게팅할 수 있게 해줌

(이렇기 때문에 절대로 중복을 허용하지 않는다)

 

ERD 에서의 Identifier는 훗날 table의 PK(Primary key)가 된다

이런 경우는 user_id로 하는 게 좋아 보임

또한 이렇게 user_id 처럼

행이 추가될 때마다 자동으로 1씩 증가시켜서 중복되지 않는 값을 부여하는 방법도 있다(Artificial Key- 인조키)

-> 자연스럽게 만들어진 것 이 아니므로 "인조" < - > Natural Key (자연키)

다음과 같이

Candidate Key (후보키) : 식별자가 될 수 있는 후보들
Primary Key (기본키) : Candidate key들 중에서 우리가 선택한 key (ERD에서 밑줄)
Alternate Key (대체키) :Candidate key들 중에서 선택받지 못한 key
=> 이 Alternate key는 나중에 성능향상을 위해 secondary index로 사용

다음과 같이 직원 번호랑 부서 번호만으로는 행을 식별할 수 없다

(이럴 때는 중복키 (composite key)라는 것을 사용)

 

 

3. Relationship

다음과 같이 저자 table의 id를 가르키는 글 테이블의 저자 아이디는 Forign Key(외래키)라고 부른다.

즉, 관계형 데이터 베이스의 Relationship은 Primary key와 Foriegn key가 연결되면서 진행이 된다.