프젝을 하려고 디비 설계를 하려는데.. 디비 수업을 들은지 너무 오래되어서 어떻게 해야할지 생각이 1도 나지 않는다 😅
대충 밍맹숭생 테이블을 짜겠는데 그래도 하는김에 제대로 해보자 싶어서 다시 정리해보자아아아 -.-~~
기본적 순서
- 업무 파악 (당연)
- 개념적 데이터 모델링 (Conceptual design)
데이터에 대한 개념적인 모델링을 의미한다. Entity Relation Diagram (ERD)를 그리는 과정 - 논리적 데이터 모델링 (logical design) -> 표로 전환한다
- 물리적 데이터 모델링 -> 실제 구현 (sql 코드)
Conceptual data modeling
entity
= 명사. 실제 세상에 독립적으로 존재하는 어떤 것. ex 사람, 차 ,집, 학생 ..
- weak entity : 직원의 부양가족처럼 직원 없이는 존재할수없는 엔티티. 반드시 상위 엔티티를 가짐
- key att이 없고 그대신 그 owner entity로 연결되어잇는 weak entity들을 구분하게해주는게 - partial key
- strong entity
Attribute
= 엔티티를 설명하는 특성들 ex)이름, 성별 , 주소, 직업 ..
분류기준 3개
- 쪼개지느냐 (분류 한번 더 되느냐)
- simple (atomic) attributes : 더이상 쪼개지지않는 att
- composite attributes : 더 작은 부분으로 쪼개질 수 ㅇ. hierarchy를형성함 ex) 장소-도로명, 건물이름, 주소 이런식으로 나뉘는거
- 개수가 몇개느냐
- single-valued attributes : 오직 값 1개 갖는 거 ex)나이 (나이여러개 뭐노 ㅋ)
- multivalued attributes : 여러 값을 갖는거 ex)폰 넘버(폰여러개일수잇자나. 값이 걍 여러개인거)
- 저장되느냐, 추측되느냐
- stored attributes : 진짜 db에 저장됨 ex)생일~
- derived attributes : 다른 att으로부터 derived될 수 있는거! 디비에 저장 xx ex)나이 (생일로부터 유추가능)
relation
= 동사
- 엔티티간의 관계를 나타낸 것 !
- degree = rel에 참여하는 entity type의 개수
- recursive relationship : 같은 entity type이 한 relation type에 두번 이상참여하는것, role name명시 필요
- relation도 att를 가질 수 있다
- 참여하는 entity들에 의해 특징이 부여될때, 그 특징을 나타낸다 (대부분 N:M 관계에 적합)
- relation type의 contraint
- cardinality ratio constraint =릴레이션인스턴스에 참여할 수 있는 최대 엔티티의 개수 !(몇대 몇 !) -> 1:1, 1:N, N:M
- participation constraint (Optional):entity가 존재하면, 다른 쪽 entity와 관련이 반드시 있어야 하는지 아닌지! 무조건 관계 맺어야 하는지
- total: 무조건 모든엔티티가 relationship참여
- partial: 참여안해도 o옵셔널하면
| 이 mandatory, o이 optional< 이 N을 의미=> 마지막꺼는 저자 댓글 1:N이고 저자는 필수 댓글은 optional임을 의미함
그렇게 그린게 ERD !
그걸 이제 Logical design을 해서 relational data model 로 맵핑한다
