데이터 베이스 설계 도면
개념적 DB 설계 도구
DB 설계
개념적 설계 : 사람이 이해하기 쉽게 데이터의 관계를 개념적으로 시각화
개체-관계 데이터 모델 : 데이터를 개체 타입과 관계 타입으로 추상화
관계 타입
- 매핑
- 1:1 = 남자와 여자의 결혼 관계, 남자 입장에서 여자는 1, 여자 입장에서 남자는 1
- 1:n = 지도 교수와 학생, 지도 교수 입장에서는 학생은 n, 학생 입장에서는 지도 교수는 1
- n:m = 학생과 과목, 학생 입장에서는 과목은 n, 과목 입장에서는 학생은 m
- 참여
- 부분 참여
- 학생은 과목에 부분 참여, 학생은 듣고 싶은 과목이 없어서 등록을 안할 수 도 있다.
- 과목은 학생에 부분 참여, 과목은 인기가 없어서 학생에게 등록되지 않을 수 있다.
- 전체 참여
- 학생은 지도에 전체 참여, 학생이라면 반드시 지도 교수를 갖는다.
- 부분 참여
개념적 ERD : 개념적 DB 설계를 위한 시각화 도구
- 클래식 방식
- 개체 타입(사각형), 속성(타원형), 관계 타입(마름모), 부분 참여(얇은선), 전체 참여(굵은선)
- EX)
- Crow's Foot
- 관계는 마름모를 사용하지 않고 개체 타입을 선으로 직접 연결
- 매핑 정보
- crow's foot : n
- vertical bar : 1
- 참여 정보
- empty circle : 부분 참여(optional)
- bar : mandatory(전체 참여)
- 참여 정보가 클래식 방식과 조금 헤깔린다. 참여 정보가 반대편에 위치한다
- EX)
- 전체 참여 : Person이라는 정보가 있으면 Location이라는 정보도 반드시 같이 있다.(사람은 반드시 어떤 장소엥서 태어난다)
- 부분 참여 : Location이르는 정보가 있다 해서 반드시 Person이라는 정보도 같이 있지 않다.(어떤 장소는 사람이 한번도 태어난 적이 없을 수 있다)
- 조합
- (부분/전체참여 .. 매핑정보_1/n)
논리적 설계
컴퓨터에 저장한 데이터의 논리적 구조를 표현
관계 데이터 모델 : 데이터의 구조를 테이블로 구체화
변환 규칙을 이용하여 자동화
관계는 식별 관계와 비식별 관계로 구분
-
비식별 관계
- 관계가 튜플을 식별하는데 영향을 주지 않는다
- 즉 관계가 없어도 테이블에서 튜플 식별에 문제가 없다
- 자식 개체 타입에서 부모 개체 타입의 키를 참조하지만 이 키는 자식 개체 튜플의 유일성을 판별하는데 필요하지 않다.
- 자식 개체 타입은 식별 관계에 부분 참여함.
- 일반적으로 점선으로 표현
- 관계가 튜플을 식별하는데 영향을 주지 않는다
-
식별 관계
- 관계가 튜플을 식별하는데 영향을 준다
- 부모 개체 타입의 키 값이 있어야만 자식 개체 타입에서 튜플들을 식별 가능
- 자식 개체 타입은 식별 관계에 전체 참여함.
- 부모 개체 타입은 부모 테이블, 자식 개체 타입은 자식 테이블로 변환, 이때 개체 타입의 키는 변환된 테이블에서 PK로 정의
- 부모 테이블의 PK를 자식 테이블에 PK/FK로 추가
- 일반적으로 실선으로 표시
-
식별/비식별 관계의 매핑 정보는 일대일, 혹은 일대다 매핑
-
n:m 매핑을 표현할 수 없음
- 관계 모델은 테이블에 다중값 속성을 허용하지 않음
- 다대다 매핑은 두 개의 일대다 매핑으로 표현
개념적 ERD에서 논리적 ERD(관계 스키마)
고려사항
- 검색 효율성을 고려
- 관계의 개수가 작을수록 검색 연산이 효율적임. 성능을 생각 한다면 전체 관계의 개수를 줄이도록 지향
원칙
- 개체 타입 : 테이블로 변환
- 관계 타입 : 일대일, 일대다 관계는 관계 테이블로 변환하지 않고, FK를 추가함
- 다중값을 허용하지 않도록 주의
- 다대다 관계는 관계 테이블을 생성
PK-FK 관계의 표현
- 비식별 관계 : 점선
- 식별 관계 : 실선
- PK-FK 관계의 매핑과 참여 정보 : Crow's foot 표기법으로 시각화함.
비 식별관계, 개념점 설계 -> 논리적 설계
1) 개념적 설계
- FK 개념이 없음
2) 논리적 설계
- FK 개념 생김
- SSN 만으로 식별 가능하여서 비식별 관계
- 비식별 관계여서 점선
식별관계(n:m), 개념점 설계 -> 논리적 설계
1) 개념적 설계
2) 논리적 설계
- 개념적 설계에서 Employee가 Project에 부분 참여 하기 때문에 Works_on에도 부분 참여
- Projec가 Employee에 전체 참여 하기 떄문에 Works_on에도 전체 참여
- Works_on의 키들은 FK이자 PK이다. FK로 식별할 수 있기에 식별관계
- 식별관계여서 실선
- Employee가 있다고 해서 반드시 Works_on에 있는 것은 아니다(직원이라고 해서 반드시 일하고 있지 않다)
- Project가 있으면 반드시 Works_on에 있다(프로젝트가 생기면 반드시 일이 진행 중이다)
ETC
- 선이 연결 될때마다
- 관계가 생긴다
- PK/FK가 생긴다
- 관계를 표현하는 곳은 한군데만 표현한다. 바로 자식 테이블쪽
- 부모 테이블의 부분/전체 여부는 중요하지 않다. 실제 SQL 형태에는 영향을 주지 않는다.
- join 전에 select를 먼저 처리하여 튜플 갯수를 줄이는게 성능 면에서 좋다
EX)
-
참여
- 마름모 : 부분 참여
- 동그라미 : 자식테이블
- 아무것도 없음 : 전체 참여
-
관계
- 실선 : 식별관게
- 점선 : 비식별관계
- customers(테이블)은 employeeId(PK)를 salesRepId(FK)로 참조하고 있음
- customers는 employee에 부분참여(마름모)하고 있음
- 그래서 salesRepId는 NULL일 수 있음
- employees는 customers에게 부모 테이블임(동그라미)
- employees는 재귀 참조를 하고 있어서 테이블에서 나가서 다시 들어오는 선이 있음
- employeeId(PK)를 managerId(FK)로 참조하고 있음
- employee는 누군가의 manager일 수 있다.
- 동그라미가 managerId(FK) 자식 쪽이다
- 마름모가 employeeId(PK), 부모 쪽이다
- managerId 는 FK이고 FK는 자식 테이블에서 갖고 있으니까. NULL 가능
- customerId는 PK이자 FK이다. 식별 관계이다. 그래서 실선이다.
- 식별 관계에서는 자식 테이블을 둥글게 표현
-
products 입장에서 orerDetaills는 자식
-
orders 입장에서 orerDetaills는 자식
-
부모 자식 관계과 굉장히 쉽게 보여진다.
-
orderDetails의 PK/FK는 NULL일 수 없다
-
모두 실선이라서 전체 참여 관계이다.
-
1:N 관계는 그렇게 중요하지 않다. 자식쪽이 N일 것이기 때문에
mohadang