DB 03 - ER model -> conceptual modeling

0. 디자인 프로세스

1. miniworld설정 후 요구사항 분석~ (who? system analyst)

2. conceptual design ; 디비의 골격을 결정함 (사람이봤을때의 디자인) (DBMS이해불가) conceptual design - er model!!

-high-level data model

3. logical design (data model mapping) ; DBMS가 이해가능! 

- 여기까지만 해도 ok. dbms에 원하는 골격 알려줄수 ㅇ logical(conceptual?) schema

4. physical design (internal schema) - 여기까지 하면 물리적으로 더 잘 돌릴 수 있ㄱㅔ 되겠죠?

 

ER모델

; er모델로 conceptual design(개념적 디자인)을 하는 것. -> ER다이어그램으로 표현 가능

(컨셉츄얼 스키마를 디자인함)

 

* 엔티티 타입(정의같은거), 거기에 att들이 있음 - 이건 schema

거기에 값들어있는거 = entity - 이건 instance

이 엔티티들의 모음 = entity set

 

*entity = 명사, rel = 동사 !! 

 

<entity>

실제 세상에 독립적으로 존재하는 어떤 것. ex 사람, 차 ,집, 학생 ..

 

weak entity type

: key att가 없는 entity type (자기가 가진 att로는 key를 형성할 수 없다)

ex) 부양가족 entity type - att: 부양 가족 이름, 성함, 성별, 관계 (-> 이름은 겹칠수도 있어서 여긴 키 att로 설정할 수 있는게 없음)

- identifying owner 

: weak entity type를 구분해주는 entity (구분시에 사용되는 entity)

ex)부양 가족에서는 직원 entity type이 됨

-> att이 다 같은 부양가족 entity가 두개 있는데, 이는 이 부양가족과 가족인 직원의 entity로 이 두 entity를 구분하게 됨

- identifying relationship type

: weak entity type과 그거의 identifying owner를 연결하는 relationship ^^ 

-> 항상 total participation constraint를 가지고 있다 !! (weak는 무조건 total 이여야함!!)

- partial key

: owner entity에 연결되어 있는 weak entity를 구분할 수 있게 해주는 거 

( 같은 entity밑에 있는 위크 엔티티들을 구분하게 해주는 키)

ex)부양가족 거기서는 name이 partial key가 되겠지요?

 

 

<attribute>

엔티티를 설명하는 특성들 ex)이름, 성별 , 주소, 직업 ..

분류기준 3개

1. 쪼개지느냐 (분류 한번 더 되느냐)

• simple (atomic) attributes : 더이상 쪼개지지않는 att
• composite attributes : 더 작은 부분으로 쪼개질 수 ㅇ. hierarchy를형성함 ex) 장소-도로명, 건물이름, 주소 이런식으로 나뉘는거

2. 개수가 몇개느냐

• single-valued attributes : 오직 값 1개 갖는 거 ex)나이 (나이여러개 뭐노 ㅋ)
• multivalued attributes : 여러 값을 갖는거 ex)폰 넘버(폰여러개일수잇자나. 값이 걍 여러개인거)

3. 저장되느냐, 추측되느냐

• stored attributes : 진짜 db에 저장됨 ex)생일~
• derived attributes : 다른 att으로부터 derived될 수 있는거! 디비에 저장 xx ex)나이 (생일로부터 유추가능) 

domain

: att에 할당될 수 있는 가능한 값들의 집합 (가능한 값들 범위)

ex) age attributed의 domain : 20~70

 

key attribute

: 모든 entity마다 다른 값을 가지는 att. 이걸로 entity를 구분한다 !!

무조건 지켜져아하는 개념입니다 디비 설계할때 설정해놓고 지킵니다 보고 유추하는게 아닙니다

ex)student entity의 학번 ,,

종류

a. multiple att can be a key ! - 두개 이상의 att이 합쳐져서 key의 역할을 할 수 있다 (두개가 합쳐져야만 키가 됨) 

b. can have more than two keys! - 그냥 두개이상의 키가 존재가능하다 (개수)

<relationship>

: 엔티티간의 관계를 나타낸 것 !

(relation type (정의같은거) : rel instances의 집합. 동사 하나로 나타내지고 엔티티 타입이 참여하는 것, relation instance는 엔티티간의 관계 (하나하나. 하나의 객체))

degree

: rel에 참여하는 entity type의 개수 

ex) binary(2개-거의 대부분), ternary(3개)

ternary 예시

rolename

: 각 rel에서 엔티티의 역할을 명시하는 것

ex) workfor rel에서 departmant=일하게해주는 장소 , employee=일하는ㅅㅏ람

* 서로 다른 두개의 entity가 rel에 참여하면 rolename 굳이 안써도 됨. 너무 분명하기 때매

-> recursive면 무조건 써야됨!

 

recursive relationship

: 같은 entity type이 한 relation type에 다른 역할로 두번이상 참여하는 것 ^^

-> 무조건 role name 명시해야함!! 

이런식으로

attributes of relationship type

: rel타입도 att를 가질 수 있따 !! (없어도 당근 ㄱㅊ^^)

-참여하는 entity들에 의해 특징이 부여될 때, 그 특징을 나타낸다

-> 대부분 M:N관계에 적합함

(왜냐면 1:1 / 1:N에서는 하나와 대응되는 친구에게 해당 성질을 밀어 넣을 수 있으니까 !!)

ex. 직원-부서에서는 부서하나에 직원여러명-> 1:N

여기에 startDate를 rel att로 설정할 수도 있지만, 부서 하나와 대응되는 직원 entity에 이 att를 밀어넣을 수 ㅇ !!

* 1:1일 때 하나에 밀어넣을 때, 되도록 total 인 쪽에 하는게 좋음 (partial이면 해당 릴레이션이 없는애도 잇는거니까, 해당 rel att는 null이됨! 이건 별로좋지아늠)

 

constraints on relationship types 

- cardinality ratio constraint

=릴레이션인스턴스에 참여할 수 있는 최대 엔티티의 개수 !(몇대 몇 !) (최대라서 관계맺고잇는애는 0개여도 ㅇㅋ)

- binary relationship 의 cardinality ratios의 세가지 타입

1. 1:1
2. 1:N (교수-학생. 교수하나에 학생 여러명. 1:N으로 적는다)
3. N:M

-participation constraint

:entity가 존재하면, 다른 쪽 entity와 관련이 반드시 있어야 하는지 아닌지!

• total : 모든 엔티티가 relationship에 참여해야함
• partial : 참여안해도 ok (부분만 참여)