[데이터베이스] ER 다이어그램 - (3) & 8-2 ER to RDB

*다른필기*

-p63
데이터모델에 쏘스 다큐먼트가 될수 있는 보고서들을 수집했다.
이것을 보고 설계할 것들 추론한다.

-p64
ex)경영대
성별,학과장에 따른 학생수,전화번호,과

-p65
컬리지하고 디파트먼트 사이에 관계를 정할 수 있다
비식별 관계라 점선
모든 단과대는 하나 이상의 디파트먼트가 있어야 된다
보고서를 통해서 이것들을 만들 수 있다.
질문
약한개체와 강한개체를 어떻게 구분하냐?
학생개체에 전화번호가 멀티벨류면 약한개체로 만들어야하고 식별관계가 되야겠죠?
약한개체가 멀티벨류에선 명확함.

근데 아까 또다른 예로
디파트먼트를 약한개체로 봤어요 여기선.
-65쪽
다만그게 칼리지와 1:n의 관계를 가진다.
반드시 강하거나 약하다는 정답은 없다
디자인 초이스로 가져오면 된다.
여기서 비식별관계의 약한개체로 봐도 별 문제가 안생겼다.

근데 예를 들어서 또 명확한 경우가 있죠?
아키타입 인스턴스에서는
음..
자동차라는 엔티티만 만들면 될줄알았는데
알고봤더니
자동차모델과 개개의 생산된 자동차를 구분하는게 알게되죠?
멀티에트리뷰트를 분리했듯이 분리하는건 반드시 약한개체다.

반드시 약한개체가 되는건 멀티벨류, 아키타입, 어쏘시에이션
그리고 이것들은 비식별관계일 확률이 높죠.

패턴에 따라서 명확하게 약한개체로 분류되는 경우가 있다.

-p66
ex)디파트먼트
학과장,전화번호,사무실
학과가 있고 학과에 소속 된 교수들이 있다는 걸 알 수가 있다
학과라는 엔티티와 교수라는 엔티티가 있다

-p67
한학과에 교수들이 소속되 있다
경우에 따라서 교수가 여러과에 소속 될 수있다

-p68
모든 교수는 한 학과에만 소속되야 된다하면 1:N관계가 발생

-p69
교수와 학과간에 n:M 이아니라 기간이 생기는 순간 association이 발생함
보통 교수와 과사이에 모 다대다이고
이렇게 교수와 학과에 세가지 유형으로 표현 할 수있다

-p70
어떤 학과에 학과장이 누구냐 표시하는 경우가 있다
학과에 학과장 반듯이 있어야 되니까 oval있고 교수가 반듯이 학과장일 필요없으니까 oval
strong한 관계

-p71
디파트먼트에 전공자 목록

-p72
전공이라는 엔티티가 생기고 전공인지 부전공인지 써줘야 된다
과목이 빠져있다
소프트웨어에서 개설한 과목은 아키 타입
개설 된 과목에 대한 엔티티가 따로 있어야 된다
*****기말고사
기말고사에 코스와 코스 인스턴스가 붙었을때 어떻게 더 추가가될지 만들어보자. 엔티티의 관계
*********

-p73
The Student Acceptance Letter
합격 통지서 같은거
입학하게 되면 졸업할때 까지 지도교수가 정해짐 

-p74
학생을 교수에 연결하지않고 appointment에 연결했다
appointment에 학과 교수의 정보가 들어가 있기 때문에
1:N에 관계이긴 하지만 advice에 대한 기간을 적는게 없다
엔티티가 추가되고 사이에 추가가 된다

------------------------------------------------------------------------------

각 엔티티는 무조건 테이블 하나로 간다
각 엔티티를 테이블로 만들고 엔티티 속성들이 필드로 정해짐
테이블을 봤으니까 릴레이션쉽을 전해준다
외래키를 통해 릴레이션쉽을 정해주고 strong/weak 설정
조인 에트리뷰트가 기본키와 외래키이다
미니멈 카디널리티 부분은 로직으로써 구현, 표현하지 않음(constraint로 표현 할 수도 있다)
엔티티에 식별자는 기본적으로 테이블에서 기본키로 가면 된다
기본키는 식별자를 그대로 가져가는 경우와 대체키를 만드는 경우가 있다
식별자가 너무 길거나 가변길이 숫자가 아닌경우 기본키로 쓰기에 좋지가 않다//가상의 에트리뷰트 추가하고 기본키로 사용
주소테이블이 있다고 할때, 이거의 기본키는 네가지가 합쳐져서 만들게 된다
하지만, 이렇게 합쳐서 할 경우 비효율적이다
엔티티에 식별자가 여러개의 엔티티의 조합으로 되있다면 가상의 엔티티를 만들고 지정

/*다른 필기
테이블 첫번째부터 간단하게 보겠습니다
엔티티의 식별자가 있었죠?
이 식별자는 기본적으로 테이블에서 기본키로 가면 됩니다
근데 대체키(surrogate키)를 가져가는 경우도 있다.

식별자가 너무 길거나, 숫자가아니거나, 가변길이인경우
기본키로 쓰기 좋지않기때문에
인티져같은 사용자에게는 무의미한 가상의 에트리뷰트를 추가하고 기본키로 사용
ex 주소테이블이 있다고 하면
그거의 기본키는 도,시티,동,번지 네가지 합쳐서 만들어짐. 
근데 이 네개를 합쳐서 기본키로 하면 비효율적
그래서 새로운 대체키인 인티져a_id를 추가하여 기본키로 지정함
또한, 도,시티,동,번지를 유니크하다고 표현해주자.
20190528 14시45분 사진찍음

constrainent같은 문법도 기본적으로 알아야하고
데이터타입도 이해하자


constrainent 종류중에서 가장 많이쓰는게
1. primary key 기본키로 지정하겠다
2. unique 모든 튜플에대해서 서로 다른값을 가진다
3. not null 언제든지 널값을 가질 수 없다
4. default 튜플을 insert할때 에트리뷰트값을 지정하지않으면 default의 지정된 값으로 저장된다.
*/

create table student (
sno int primary key.
sname varchar(50) not null,
dept varchar(30),
emeil varchar(50) unique,
enter_date datetime default now()
); 

insert into student(SNO, SNAME, EMAIL)
values(123, 'KIM', 'KIM@ABC.COM');//명시가 안되있어서 과는 null로 들어가고 
이메일 유니크 한지보고, 시간 시스템 시간 들어감

create table student( sno int primary key, sname varchar(50) not null, dept varchar(30), email varchar(50) unique, enter_date datetime default now());

 

insert into student (sno, sname, email) values (123,'KIM','Kim@naver.com');