본문 바로가기

이론/DB

[DB] 데이터베이스 모델링, E-R 다이어그램

E-R 다이어그램

 

 

교수라고 하는 개체 타입의 키는 교수번호이다. 

 

relation관계를 지도, 강의, 과목 세 개로 잡아주고 있다. 

 

지도라는 관계는 1:N의 카디널리티를 가진다. 한명의 교수가 여러명의 학생을 지도한다. 

 

교수와 과목은 강의라는 1:N관계를 가지는데, 교수 한명이 여러 과목을 강의할 수 있다. 

 

DB강의가 두번 강의 하는 것을 표현하지 않았다. 한 교수가 한 과목을 강의한다로 표현한 거다. 

 

과목은 강의가 한 번만 있어야 한다. 위 시스템은 현 시스템과 맞지 않다.  

 

 

 

이렇게 해야 한 강의가 과목이 여러 개 있다는 것을 표현할 수 있다. 

 

기말고사에 , requirement에 따라 E-R다이어그램을 그리고 테이블로 관계형 데이터베이스로 변환하는 것이 50점이다. 

 

다원관계: 두개가 아니라 여러개의 개체가 동시에 하나에 연결되었을때를 표현한 관계이다. 

 

현실적으로 다원관계는 쓰지 않는 것이 좋다. 다 binary 관계로 쪼개낼 수 있는데 이렇게 표현하는 것이 좋다 .

 

<< 안좋은 예 >> 

 

 

 

 

 

 

<<좋은 예>

 

 

 

다중 관계: 두 개체 사이에 여러 개의 관계 존재 가능

 

대출은 당연히 키 애트리뷰트가 대출 번호이다. 상환은 키 애트리 뷰트를 정하는 방식을 두가지로 한다. 

 

1) 상환번호를 붙여서 얘가 애트리뷰트가 되는 것이다. 

 

2) 상환이 대출에 의존적이니까 대출번호를 가져다가 대출번호와 상환번호를 묶어서 애트리뷰트로 만드는 것이다.

- weak 엔티티가 strong엔티티를 덧붙여서 키를 만들었을 때, 식별 관계 타입이라고 한다.  

 

상환 번호같은 것을 구별자라고 한다. 

 

 

 

키 애트리뷰트는 밑줄을 그어준다. 

 

유도애트리뷰트는 평균과 비슷하게 유도된 애트리뷰트이다. 

 

 

대출 상환은 식별관계로 만든것이다. 대출번호를 가져다 쓰겠다는 얘기다. 

 

대출은 상환이 없어도 된다. 일부 대출은 대출상환 관계에 부분참여하므로 1줄이다. 

 

상환은 전체 참여이기때문에 두줄이다. 

 

대출번호는 키이기때문에 실선 밑줄, 상환번호는 구별자이므로 점선 밑줄이다. 


E-R모델링한 것을 데이터베이스로 변환시켜야한다. **

 

E-R다이어그램을 관계형 데이터모델로 바꾸자. E-R다이어그램은 개념적 데이터 모델이다. 

 

개념적 데이터 모델링은 도메인의 이해가 중요하다. 

 

교수와 과목간의 관계는 1:N의 관계, 과목과 강의가 1:N의 관계이다. 

 

관계는 카디널리티 측면이 제일 중요하다.

 

1:1, 1:N이 중요하다. 1쪽에 있는 기본키를 외래키로 가져다 붙이면 된다.( 테이블이 추가되지 않기때문에)

 

교수와 학생간의 관계 지도는 1:N이다. 아까 만든 학생 테이블에 교수번호를 넣어주고 거기다가 지도 교수번호라고 적당히 붙여주자. 

 

기본적으로 관계를 테이블로 만든 경우 교수번호와 학생번호 가져다가 쓰면 된다. 

 

이방법도 naive하지만 맞다. 

 

1:1이나 1:N은 새로운 테이블 안만들고 1쪽에 있는 기본키를 n쪽에 외래키로 붙여준다. (골든룰)

 

과목 테이블에다가 교수 번호를 과목 교수번호라고 따로 집어넣고, 강의시간, 강의 장소를 애트리뷰트로 따로 넣자. 

 

등록 테이블처럼 n:m인 경우 새로운 테이블을 만들어주고, 양쪽에 있는 기본키를 가져다가 외래키로 가져다둔다. (골든룰)

 

디자인 초이스이기 때문에 naive한 방법, 골든 룰에 의한 방법 둘 다 맞다. 

 

사용자와 아이템 사이의 관계 1:N이다. (아이템은 중복해서 가질수 없기 때문에) 

'이론 > DB' 카테고리의 다른 글

[DB] 데이터베이스 ER 다이어그램 - (2)  (0) 2019.05.21
[DB] 데이터베이스 ER 다이어그램 - (1)  (0) 2019.05.17
[DB] SQL - (4) View  (0) 2019.05.03
[DB] SQL - (3)  (0) 2019.04.30
[DB] SQL - (2)  (0) 2019.04.19