[데이터모델링]개념적인 설계에서 논리적인 설계로 나아가기

・개념적인 설계에서 논리적인 설계로 나아가기

-개념적인 설계에서 논리적인 설계로 맵핑을 해보자

-개념적 설계의 산출물인 er다이어그램은 인간이 이해하기 쉬운 것

-논리적 설계로 넘어가면서 점차 컴퓨터가 이해할 수 있는 모델들로 바꾸어야함

-논리적 모델로써 relational model을 사용함

-논리적 설계의 아웃풋은 relational schema

-개념적 설계에서 논리적 설계로 맵핑하는 과정은, db 설계 전반중 가장 정형화되고 기계적으로 가능함

-즉, 정해진 메뉴얼대로 하란대로만 하면됨. 이해하기 쉬움

・논리적 설계

-정의 : 개념적 설계의 아웃풋인 er다이아그램을 데이터베이스 관리 시스템에 매빙하는 것

-아웃풋은 relational schema

・용어설명을 통해 관계형 데이터베이스 알아보기

-테이블 네임 = 릴레이션 네임(테이블을 릴레이션이라고 부름) = (개념적 설계에서)엔티티 타입

-키어트리뷰트 = 기본키 = primary key(PK)

-관계(테이블 또는 릴레이션) : 흔히부르는 테이블이라는 이름으로 사용됨. 관계의 열은 어트리뷰트라고 하고, 행은 튜플이라고 부름

-튜플(레코드 또는 행) : 관계를 구성하는 각각의 행

-어트리뷰트(속성 또는 열)

-도메인 : 어트리뷰트가 취할 수 있는 같은 타입의 원자 값들의 집합. 예를 들어 나이라는 어트리뷰트에서 나이  를 integer 타입의 0~150으로 정한다면 각각 나이들의 집합이 도메인 

-후보키 :릴레이션에 이는 속성 중 유일성과 최소성을 만족하는 키로써, 후보키중 하나를 기본키로 사용함. 

-기본키(primary key) : 후보키 중에서 선정된 하나로 유일성과 최소성을 만족함. 기본키는 null값과 중복값이 인정되지 않음.

-슈퍼키 : 하나 이상의 어트리뷰트들의 합체로 이루어진 키. 

 예를 들어, 대학생 릴레이션에 이름과 학번이라는 어트리뷰트가 존재할 때 (이름+학번)을 하나의 키로 인정하고 사용함. 슈퍼키는 유일성을 가짐. (이름+학번)일 경우에 (이름+학번)이라는 키는 (학번)이라는 유일성을 가진 어트리뷰트 때문에 오직 하나만 존재할 것이기 때문. 

  그러나 슈퍼키는 최소성을 가지지 못함. 즉, (학번) 어트리뷰트만으로 각 튜플이 구분될 수 있는데, 굳이 학번에 이름을 합친(이름+학번)으로 해야하냐..

-외래키(foreign key) : 다른 릴레이션의 어트리뷰트를 참조해 연결해 주는 어트리뷰트를 외래키라고 함. 이때 외래키는 다른 릴레이션의 유일성을 가진 애트리뷰트를 참조해야함. 학생 릴레이션의 소속학과 애트리뷰트가 학과 릴레이션의 학과번호 애트리뷰트를 참조할 때, 학생 릴레이션의 소속학과 애트리뷰트는 외래키가됨

・관계형 데이터베이스의 제약조건

-★참조무결성 제약조건(referential integrity constraint) : 한 릴레이션에 있는 튜플이 다른 릴레이션에 있는 튜플을 참조하려면 반드시 참조되는 튜플이 해당 릴레이션 내에 존재해야 한다는 것.

 예를 들어, 학생 릴레이션의 소속학과 애트리뷰트에 5라는 튜플값이 존재한다고 하면, 이 외래키가 참조하는 학과 릴레이션의 학과번호 애트리뷰트에도 반드시 5가 존재해야한다.

-키제약조건 : 키 어트리뷰트의 값은 릴레이션 내의 각 투플을 유일하게 식별할수 있어야 한다.

-도메인 제약조건 : 각 애트리뷰트의 값은 반드시 도메인에 속하는 원자중 하나여야 한다.

-엔티티 무결성 제약조건 : 어떠한 기본키 값도 null을 가질 수 없다.

・제약조건 위배에 따른 처리

-삽입연산 : [201430010/곽나리/서울/5]를 학생 테이블에 넣고 싶은데, 참조하는 학과 테이블의 학과번호 애트리뷰트에서 5는 존재하지 않으므로 참조무결성 제약조건으로 인해 해당 데이터는 삽입될 수 없다.

-삭제연산 : 학과 테이블에서 2번(게임공학과)를 삭제하려고하면, 학과 테이블의 학과번호 애트리뷰트를 참조하고 있는 테이블이 존재하고 있기 때문에 삭제되지 않는다.(삭제해버릴시 참조무결성 제약조건을 위배함)

-수정연산 : 전요한의 소속학과를 5로 수정하려고 할 시 오류가 발생한다.