이전까지 테이블이 만들어져 있다면 어떻게 테이블을 이용할까에 대해 배웠다면 지금부터는 테이블을 어떻게 만들 것인가를 배울 것이다.

데이터베이스 설계

• 데이터베이스 디자인 정의
  사용자의 요구사항으로부터 현실세계를 반영한 데이터베이스 구조를 도출해내는 과정

• 데이터베이스 생명 주기
  참고로 데이터베이스도 소프트웨어이다. 시스템 소프트웨어
  각 단계별로 제대로 끝내고 다음 단계로 가는 것이 중요하다.
  요구조건 분석 -> 설계 -> 구현 -> 운영 -> 감시 및 개선

• 데이터베이스 디자인 단계
  요구 사항 분석 -> 개념적 설계 -> 논리적 설계 -> 물리적 설계 -> 구현

• 요구사항 분석
  DB 사용환경 분석 후 대상 및 제한 조건 도출

• 개념적 설계
  분석 결과를 추상화된 표현 방식으로 기술
  개념적 스키마 생성

• 논리적 설계
  목표 DBMS 구조에 맞는 스키마 생성 -> 논리적 스키마 생성
  논리적 스키마 생성

• 물리적 설계
  목표 DBMS에 맞게 실제 컴퓨터에 저장되는 방식 설계 -> 물리적 스키마 생성
  물리적 스키마 생성

• 구현
  목표 DMBS의 DDL로 데이터베이스 생성, 트랜잭션 작성

• 데이터베이스 디자인 고려 사항
  충실성: 필요로 하는 모든 데이터를 표현
  단순성: 단순하고 이해하기 쉬운 구조로 표현
  중복의 최소화: 데이터의 중복을 최소화, 저장공간의 효율적 사용, 데이터 일관성 유지
  제약조건의 표현: 데이터가 갖추어야 할 조건을 표현제약조건의 표현: 데이터가 갖추어야 할 조건을 표현

개념적 설계

• 개념적 디자인의 개요
  업무에서의 엔티티와 관계들은 어떻게 되어 있는가?
  엔티티와 관계의 어떤 정보를 데이터베이스에 저장해야 하는가?
  어떤 무겨렁 제약 조건과 업무 규칙이 있는가?
  위와 같은 질문에 대한 답으로 만들어지는 것이 ER 모델이다.
  ER모델은 릴레이션 스키마로 맵핑이 가능하다.

• ER 모델을 이용한 개념적 디자인
  개념이 엔티티로 만들어져야 하는가 속성으로 적용되어야 하는가?
  -> 주소(광역시도-시군구-읍면동-숫자-(건물명-호수))를 엔티티로 만들것인가 속성으로 할 것인가를 결정하기 위해 어떻게 사용되는지 봐야 한다.
  사람 한 명이 여러 개의 주소를 가질 수 있다. 이때는 엔티티로 해야 한다. 왜냐하면 속성은 원자값을 가져야 하기 때문이다.
  주소의 각 서브 속성이 쿼리에서 중요할 경우 엔티티로 만드는 것이 좋다.
  위와 같이 사용 용도에 따라 결정해야 한다.
  개념이 엔티티로 표현되어야 하는가 릴레이션으로 표현되어야 하는가?
  개념의 관계가 이진 관계로 표현되어야 하는가 N진 관계로 표현되어야 하는가?

논리적 설계: ER to Relational

가장 기본적인 것은 엔티티를 테이블로 만드는 것이다.
테이블을 SQL문을 통해 물리적으로 구현한다.

• 관계를 테이블로 만들 때
  일반적으로 관계를 테이블로 만들 때는 양쪽에서 기본키를 가져와 자신의 속성으로 만드는 방법이다.
  이때 기본키는 외래키로 이루어진 복합키이다.
  ssn(외래키), did(외래키), since(속성) 이 예시이다.

• 1:1 관계 만드는 방법
  왼쪽 테이블의 기본키를 오른쪽 테이블의 속성으로 둔다.
  오른쪽 테이블의 기본키를 왼쪽 테이블의 속성으로 둔다.
  새로운 테이블을 만들고 왼쪽 오른쪽 테이블의 기본키를 복합 기본키로 둔다.
  두 테이블을 하나의 테이블로 합친다.

• 1:N 관계 만드는 방법
  1:1 관계 만드는 방법과 같다. 단 두 테이블을 하나의 테이블로 합치는 방법은 안된다.
  그리고 알고리즘적으로 N쪽에 1쪽의 기본키를 가져오는게 좋다.

• N:M
  N:M은 새로운 테이블을 만들 수 밖에 없다.