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:N (교수-학생. 교수하나에 학생 여러명. 1:N으로 적는다)
- N:M
-participation constraint
:entity가 존재하면, 다른 쪽 entity와 관련이 반드시 있어야 하는지 아닌지!
- total : 모든 엔티티가 relationship에 참여해야함
- partial : 참여안해도 ok (부분만 참여)