4. 2장 데이터베이스 설계 (database design) (4) - Logical Database Design

데이터 베이스 설계 단계 6개를 다시 가져와봤다

 

1. 요구사항 분석 (Requirements Analysis)

2. 개념적 데이터 베이스 설계 (Conceptual Database Design)

3. 논리적 데이터베이스 설계 (Logical Database Design)

4. 스키마 정제 (Schema Refinement)

5. 물리적 데이터베이스 설계 (Physical Database Design)

6. 애플리케이션 및 보안 설계 (Application and Securyt Design)

 

바로 앞 내용으로 2. conceptual database design을 마무리했다 (ER modeling)

이제 이렇게 설계한 ER modeling을 관계형 모델로 변환하는 방법을 배운다 == SQL 다루는법 배우는것!

 

Entity sets to tables

이렇게 디자인한 entity set은.... -> 동그라미 (attribute)가 column의 이름으로 들어간다!

CREATE TABLE Employees(
    ssn 	CHAR(11),
    name 	CHAR(20),
    lot 	INTEGER,
    PRIMARY KEY (ssn))

이런식으로 SQL문을 작성하면 만들 수 있다.

이 때 디자인에서 key로 만들어준것 (밑줄)은 PRIMARY KEY라고 이야기 해줘야한다!

이런 테이블을 생각할 수 있다.

 

Relationship Sets to Tables

그럼 관계는 어떻게 표현해야 할까?

-> 연결된 entity의 key를, FOREIGN KEY로 넣어준다.

    그리고 이런 FK를 모아서, PRIMARY KEY라고 해준다.

(work 관계를 생각해보자)

CREATE TABLE Work(
    ssn		CHAR(11),
    did		INTEGER,
    since	DATA,
    PRIMARY KEY (ssn, did),
    FOREIGN KEY (ssn)
    	REFERENCES Employees,
    FOREIGN KEY (did)
    	REFERENCES Departments)

일단, 속성들 전~~부 위에 선언해주고, 그 아래에 PK, FK가 어떻게 되는지 설명해준다.

    FK의 경우, 어떤 테이블에서 온건지도 명시해준다!

 

Key Constraints

만약 키제약이 있었으면 어떻게 해야할까? (화살표가 있는경우)

manage 관계만 생각해보자! key constraint란게, manage 관계에에서 부서는 한번만 들어갈 수 있다는 제약이었다

그러니까 그냥 PK를 부서id로 해주면된다.

CREATE TABLE manage(
    ssn		CHAR(11),
    did		INTEGER,
    since	DATE,
    PRIMARY KEY(did),
    FOREIGN KEY(did)
    	REFERENCE departments,
    FOREIGN KEY(ssn)
    	REFERENCE Employees)

 

이런경우, 그냥 부서에 꼭 한명씩 매니저가 딸려있는거니까 "매니저"를 하나의 속성처럼 생각해서

manage랑 department를 합쳐버려도 된다

CREATE Dep_mgr(
    did		INTEGER,
    dname	CHAR(20),
    budget	REAL,
    ssn		CHAR(11),
    since	DATE,
    PRIMARY KEY (did),
    FOREIGN KEY (ssn)
    	REFERENCE Employees)

이런식으로 말이다!

 

Participation Constraints

참여제약 (엔티티셋의 모든 구성원이 해당 관계에 한번이상 참여해야함) -> 굵은 선분으로 표현했음!

-> NOT NULL 이라고 표현해주면 된다! (절대 비면 안되니까)

=> 옹?? 테이블 하나로 합친걸로 표현해주었다.

CREATE Dep_mgr(
    did		INTEGER,
    dname	CHAR(20),
    budget	REAL,
    ssn		CHAR(11) NOT NULL,
    since	DATE,
    PRIMARY KEY (did),
    FOREIGN KEY (ssn)
    	REFERENCE Employees)

 

Weak ENtities

다른 엔티티에 의존해 식별되는 엔티티

ON DELETE CASCADE라는 옵션을 추가해준다

CREATE TABLE dpe_policy(
    pname	CHAR(20),
    age		INTEGER,
    cost	REAL,
    PRIMARY KEY (pname, ssn),
    FOREIGN KEY (ssn)
    	REFERENCE Employees
        ON DELETE CASCADE)

weak entity의 경우, 부모 엔티티가 삭제되면 이놈도 사라져야한다!

즉 사원 (ssn)이 사라지면, 부양가족도, 복지정책이라는 관계도 전부 사라진다.