생코_관계형 데이터 모델링

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

 

업무파악은 고객을 통해서 개발자가 알아낼 업무이다.

이때 주의할 것은 고객은 일을 잘 이해하는 가이다

단순히 일을 잘한다는 것은 일을 이해하지 못하더라도 익숙해져 있어서

이해를 덮어버리고 하는 것일 수 있기 때문이다.

 

문제는 컴퓨터에게 일을 맡기려면 익숙함만으로는 전달할 수 없다.

우리는 업무를 이해해야 한다.

 

이때 업무를 이해하는 방법으로는 UI를 설계하여 고객과 대화하는 것이 최선이다.

 

논리-물리 모델링은 실제 개발자가 테이블 만드는 작업들이다.

 

이때 개념적 데이터 모델링을 잘하면 논리-물리 모델링은 규칙적이고 기계적인 일이다.

 

논리~물리 모델링을 할줄 알아야 개념 모델링을 할 수 있다.

 

개념 모델링은 고객의 업무를 개발자의 관점으로 옮기는 것이라 할 수 있다.

 

 

Attribute는 구체적인 것. 글 속의 제목, 내용 등이다. 후에 Column이 된다.

Enttity는 저자, 글, 데이터와 같이 구체적인게 그룹핑 된 것이다. 이것은 후에 Table이 된다.

Relation은 관계를 나타내었다. 저자와 글은 쓰다 관계, 글과 댓글은 소속관계 등. 후에 PK, FK가 된다.

참고로.. Tuple은 Row(행)에 대응된다.

 

 

FK :  외래에 있는 테이블과 연결할 때 사용하는 키 : 외래키 : Foreign Key

 

Cardinality .. 1:1, 1:N, N:M

Optionality : 예를들어 저자와 댓글 관계에서, 저자는 댓글을 작성할수도 안할수도 있지만,

댓글은 일단 존재한다면 그 댓글을 작성한 저자는 반드시 존재한다.

 

o Mapping Rule

Attribute -> Column

Enttity -> Table

Relation -> PK, FK

 

 

1:1 관계에서 누구에게 FK를 줄것인가..

 

저자와 휴면 저자 테이블이 있다면..

휴면저자는 저자가 누군지 알아야 하지만, 역은 그렇지 않다.

혼자서 잘 지내는 저자테이블은 부모테이블,

혼자서 잘 지낼 수 없는 의존하고 있는 테이블은 자식테이블이다.

저자엔 PK, 휴면저자에 FK를 설치한다.

 

N:M을 처리하려면

매핑 테이블을 만들자!

각각의 PK를 FK로 갖는 테이블 ! 인터페이스테이블 비슷한것

 

제 3정규형까지가 산업적으로 많이 사용된다.

 

1정규형님

 

위 컬럼 title과 tag는 서로 N:M 관계이다.

이런관계에서 ... selec~ fr~ where tag= 'free' ?? 안돼지 !

이래서 1정규형님을 부르는 것이여~~ ^^ (아 물결표 쓰면 아재랫는디)

이것을 Atomic하게 만들자. 유니크하게 샤르륵.

 

생코형 감사합니다

위처럼 mapping테이블을 만들어주면된다.

 

 

 

2정규형님

 

저렇게 하나의 쌍을 이루는 데이터 로우가 있다.

 

 

아래처럼 해당 컬럼들에 해당하는 로우만 따로, 테이블을 분리시킨다.

 

 

3정규형님

 

위와같이 딱봐도 중복되어 있는 애들이 있다. author_ 등의 컬럼

 

아래와 같이 테이블을 빼주자.

 

 

 

.....정규햄 2랑 3이 머가 다른지 모르겠다

 

짜슥..

 

 

 

정규화를 한다는 것..

쓰기의 편리함을 위하여 읽기의 편함과 성능을 포기하는 것..

편함을 왜포기?.. 테이블 봤을때 뙇! 하고 안보여.. 코드값, ID 외우는게 아니면

성능은 왜포기?.. join 자체가 비싼 비용이여!!

 

대게 보통 정규화는 한다.

역정규화는 그 이후에 성능 등의 이유로 하는 것이다.

역정규화를 하더라도 정규화를 해놓고서 생각해보자.