모델링 개념과 개념적 데이터 모델링

2020. 10. 22. 20:27풀스택을 향하여 - 백엔드/MySQL

www.youtube.com/watch?v=1d38YZKCM88&list=PLuHgQVnccGMDF6rHsY9qMuJMd295Yk4sa

이 글은 생활코딩님의 '관계형 데이터 모델링' 유튜브 재생목록 영상들을 바탕으로 작성되었습니다.

 

모델링이란

어떤 목적을 가지고 진짜를 모방하는 

 

두개의 세계는 서로 다르기 때문에, 끊임없이 얼마나 차이가 날지를 확인해야 한다. 데이터를 표에 담기만 하면, 이용할 있다. 그러나 하나의 표에 데이터를 담는 것은 비효율적일 뿐만 아니라, 엄청나게 어렵다. 그렇기 때문에 모델이 필요하다.

 

 

모델링의 과정

업무파악 -> 개념적 데이터 모델링(ERD 그림) -> 논리적 데이터 모델링(ERD ) -> 물리적 데이터 모델링(코드 작성)

 

업무를 제대로 이해하고, 설명할 있어야 한다. 전체 업무의 과정과 필요한 데이터들을 명시할 있어야 한다. 업무 파악을 할때는 UI 직접 같이 그려보는 것이 좋다. 일을 의뢰한 사람과 같이 그려보는 만큼 좋은 것이 없다. 말만으로는, 상대방이 제대로 이해했는지를 파악하기 어렵다.

 

 

개념적 데이터 모델링

논리적 데이터 모델링과 물리적 데이터 모델링은 비교적 기계적이다. 개념적 데이터 모델링이 전체 과정에서 가장 중요하다고 있다.

 

 

개념적 모델링의 기능

 

현실에서 개념을 추출할 있게 해주는 필터이고, 특정 개념에 대해서 다른 사람들과 대화할 있게 해주는 언어로써 기능한다. 그리고 이를 ERD 라고 한다. ERD 정보(속성), 그룹(엔티티 - 개체), 관계로 이루어져 있다. ERD 매우 쉽게 표로 전환시킬 있다.

 

RDB 내포관계를 허용하지 않기 때문에 여러 개의 표를 묶는 식으로 만들어야 한다. 하나의 테이블은 중복과 비효율성이 발생하기 때문이다.

 

개체는 테이블로 전환된다.속성은 (column) 것이다. (참고로 행은 Tuple 이라고 부른다) 관계는 기본키와, 외래키로 관계가 표현된다. 기본키와 외래키가 물리적 모델링 단계에서는 JOIN 활용된다. 개체는 속성들을 가지는데, 각각의 개체들이 어떤 속성들을 가질지는 어플리케이션의 기능에 따라 다를 있다.

 

 

엔티티 정의

UI 옥상이고, 데이터베이스는 지하이다. UI 상에서 데이터 입력이 일어나면 데이터베이스를 변경시키고, 데이터 베이스가 변경되면 UI 변경된다. 보통 UI 쓰기 작업이 일어나는 곳에서 개체와 속성들을 많이 발견할 있다. ERD 상에서는 네모로 나타낸다.

 

속성 정의

ERD 상에서는 원으로 나타낸다. 선으로 개체(네모) 연결시켜준다.

 

식별자 지정

식별자는 대상을 고유하게 만들어주며, 대상을 타게팅이 가능하게 만들어준다. 그렇기 때문에, 값은 절대 중복이 발생해서는 안된다따라서 고유할 있는 값을 식별자로 지정한다. 보통 그런 값이 흔하지는 않기 때문에 인조키 혹은 대리키(주로 id) 사용하고는 한다.

 

조건들을 만족하는 속성들을 '후보키' 라고 부르는데, 여기서 식별자로서 선택된 속성을 '기본키'라고 부르고 선택되지 못한 후보키들을 '대체키'라고 부른다.

 

특수한 경우에 사용하는 것으로, '중복키' 있다. 명의 직원이 여러 부서에 속할 있는 경우와 같이, 하나의 속성() 중복되는 값이 있을 있다. 그러므로 이런 경우에는 직원번호도, 부서번호만으로는 식별자를 만들 없고, 둘을 합쳐야 식별자로서 역할을 있다. 이를 중복키(컴포짓 ) 라고 한다.

 

ERD 상에서는 식별자 기본키(Primary key) 밑줄을 친다.

 

엔티티간의 연결

연결은 외래키(Foreign Key) 이루어진다. ERD 상에서는 마름모를 이용해서 관계가 표시된다.

 

Cardinality

'기수' 라는 뜻이고, 1,2,3,4,5,….이런 숫자들을 의미한다. 다른 테이블의 행끼리 일대일 대응 관계, 일대다 대응관계, 다대다 대응관계를 가지고 있는지를 의미하는 개념이다.

 

일대일 관계는 ERD 상에서는 점을 잇는 선분이다

일대다 관계는 ERD 상에서 한점과 까마귀 발을 가진다.

다대다 관계는 ERD 상에서 두개의 까마귀 발을 가지는 선분이다.

 

다대다 관계는 RDBMS 상에서 구현할 없기 때문에, 테이블을 중간을 매개하는 별도의 테이블이 필요하다. 방향이 많이 헷갈릴 있다.

 

Optionality

옵션이란 있을 수도 있고, 없을 수도 있다는 의미이다. 유저가 무조건 댓글을 필요는 없기에, 유저들 중에는 작성한 댓글이 없는 유저들이 있을 있다. 이러면 댓글은 Optional 하다고 말한다. ERD 상에서는 Optional 테이블 쪽에 가깝게, 선분에 동그라미를 그려서 표현한다.

 

댓글의 경우엔, 무조건 저자를 가져야 한다. 이런 관계에서는 저자가 Mandatory 하다고 말한다. ERD 상에서는 Mandatory 개체에 가깝게 선분에 세로 선을 짧게 긋는다. 마찬가지로, 방향이 많이 헷갈릴 있다.