ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [데이터베이스개론] ch5. 관계 데이터 모델
    DB 2024. 7. 15. 02:42
    728x90

    관계 데이터 모델의 개념

    관계 데이터 모델의 기본 용어

    하나의 개체에 관한 데이터를 릴레이션(relation) 하나에 담아 데이터베이스에 저장

    relation : 파일 관리 시스템의 파일에 대응하는 개념

    •  속성(attribute)
      • 릴레이션의 열
      • 파일의 필드에 대응하는 개념
    • 튜플(tuple)
      • 릴레이션의 행
      • 파일의 레코드에 대응하는 개념
    • 도메인(domain)
      • 속성 하나가 가질 수 있는 모든 값의 집합
      • 관계 데이터 모델에서는 더는 분해할 수 없는 원자 값만 속성 값으로 사용가능
      • 특정 속성이 가질 수 있는 모든 원자 값의 모임
      고객 릴레이션에서 등급 속성의 값으로 vip, gold, silver 중 하나만 허용된다면 네 가지 값을 모아놓은 것이 등급 속성의 도메인이 된다. 이렇게 정의해두면 사용자가 속성 값을 입력하거나 수정할 때 데이터베이스 시스템이 적합성을 판단하여 네 가지 이외의 값은 허용하지 않음으로써 항상 올바른 값만 유지할 수 있다는 장점이 존재한다.데이터 타입을 도메인, 변수를 속성으로 생각하면 이해하기 쉽다.
    • 하지만 고객아이디, 고객 이름 같은 속성은 도메인을 정확히 정의하기 어렵다. 따라서 일반적으로 속성의 특성을 고려한 데이터 타입으로 정의한다. (CHAR(20), INT 등)
    • 널 값
      • 릴레이션에 있는 특정 투플의 속성 값을 모르거나 적합한 값이 없는 경우에는 null이라는 특별한 값을 사용할 수 있다.
      • null : 특정 속성에 해당되는 값이 없음을 나타냄
    • 차수(degree)
      • 하나의 릴레이션에서 속성의 전체 개수
      • 모든 릴레이션은 최소 1 이상의 차수를 유지해야하며 일반적으로 자주 변하지 않는다는 특징
    • 카디널리티(cardinality)
      • 하나의 릴레이션에서 투플의 전체 개수
      • 투플이 없는 릴레이션이 존재할 수 있으며, 투플이 삽입되거나 삭제될 수 있으므로 릴레이션의 카디널리티는 일반적으로 자주 변한다는 동적인 특징 존재

     

    릴레이션과 데이터베이스의 구성

    릴레이션은 릴레이션 스키마와 릴레이션 인스턴스로 구성

    • 릴레이션 스키마(relation schema) : 릴레이션의 이름과 릴레이션에 포함된 모든 속성의 이름으로 정의하는 릴레이션의 논리적 구조
      • 데이터베이스 관리 시스템이 내부적으로 데이터 정의어를 이용해 정의하지만, 아래와 같은 형태로 쉽게 표현
    릴레이션이름(속성이름1, 속성이름2,...,속성이름n)
    
    • 릴레이션이름(속성이름1, 속성이름2,...,속성이름n)
    • 릴레이션 내포(relation intension)라고도 부름
    • 릴레이션 인스턴스(relation instance) : 한 시점에 릴레이션에 존재하는 투플들의 집합
      • 릴레이션 스키마에서 정의하는 각 속성에 대응하는 실제 값으로 구성되어 있음
      • 데이터베이스 관리 시스템이 내부적으로는 데이터 조작어를 이용해 릴레이션 인스턴스의 투플을 검색하거나, 새로운 투플 삽입과 기존 투플 삭제 및 수정 수행
      • 릴레이션, 릴레이션 외연(relaion extension)이라고도 부름

    논리적 구조를 정의하는 릴레이션 스키마는 자주 변하지 않는다는 정적인 특징이 있는 반면, 릴레이션 인스턴스는 투플의 삽입, 삭제, 수정이 자주 발생한다는 동적인 특징 존재

    • 데이터베이스 스키마 : 데이터베이스를 구성하는 릴레이션들의 스키마를 모아놓은 것
    • 데이터베이스 인스턴스 : 한 시점에서 데이터베이스에 저장된 데이터 내용의 전체 집합

     

    릴레이션 특징

    관계 데이터 모델의 릴레이션에는 네 가지 중요한 특성이 있다.

     

    투플의 유일성 : 하나의 릴레이션에는 동일한 투플이 존재할 수 없다.

    • 하나의 릴레이션에 똑같은 투플이 있으면 안되고, 모든 투플에는 다른 투플과 구별되는 유일한 특성이 있어야 합니다.

    투플의 무순서 : 하나의 릴레이션에서 투플 사이의 순서는 무의미하다.

    • 투플 순서가 바뀐다고 다른 릴레이션이 될 수 없고, 순서와 상관없이 투플 내용이 같아야 같은 릴레이션입니다.

    속성의 무순서 : 하나의 릴레이션에서 속성 사이의 순서는 무의미하다.

    • 속성의 순서가 바뀌어도 다른 릴레이션이 될 수 없고, 순서와 상관없이 같은 속성들로 구성되어 있어야 같은 릴레이션입니다.

    속성의 원자성 : 속성 값으로 원자값만 가용할 수 있다.

    • 모든 속성 값은 더는 분해할 수 없는 하나의 값, 즉 원자 값만 가질 수 있습니다.
    • 다중 값을 허용하지 않음

     

    키의 종류

    투플을 유일하게 구별하기 위해 모든 속성을 이용하는 것보다 일부 속성만 이용하는 것이 효율성을 높일 수 있음

    릴레이션에 포함된 투플들을 유일하게 구별해주는 역할은 속성 또는 속성들의 집합인 키가 담당

    키는 관계 데이터 모델에서 중요한 제약조건을 정의함

    • 슈퍼키(super key) : 유일성의 특징을 만족하는 속성 또는 속성들의 집합
      • 유일성(uniqueness)은 키가 갖추어야 하는 기본 특성
      • 하나의 릴레이션에서 키로 지정된 속성 값은 투플마다 달라야 한다는 의미, 즉 키 값이 같은 투플은 존재할 수 없음
      고객 아이디는 유일하므로 슈퍼키가 가능
    • (고객아이디, 고객이름) 속성 집합도 슈퍼키가 가능하다 → 고객아이디를 포함하는 속성 집합은 모두 슈퍼키가 가능
    • 후보키(candidate key) : 유일성과 최소성을 만족하는 속성 또는 속성들의 집합
      • 하나의 속성으로 구성된 키는 최소성을 만족함
      • 투플을 유일하게 구별하기 위해 꼭 필요한 최소한의 속성들로만 이루어지므로 슈퍼키 중에서 최소성을 만족하는 것이 후보키가 된다.
      • 새로운 투플이 삽입되거나 기존 투플의 속성 값이 바뀌어도 유지되어야 한다.
    • 최소성(minimality) : 필요한 최소한의 속성들로만 키를 구성하는 특성
    • 기본키(primary key) : 여러 후보키 중에서 기본적으로 사용할 키
      • 데이터베이스 설계자나 관리자는 여러 후보키 중에서 기본적으로 사용할 키를 반드시 선택해야 한다.
      • 속성 이름에 밑줄이 그어진 것이 기본키
      • 기본키 선택 시 고려할 기준
        • 널 값을 가질 수 있는 속성이 포함된 후보키는 기본키로 부적합
          • 기본키는 투플을 식별하고, 릴레이션에서 원하는 투플을 찾기 위한 기본 접근 방법을 제공하므로 매우 중요
        • 값이 자주 변경될 수 있는 속성이 포함된 후보키는 기본키로 부적합
          • 기본키는 다른 투플과 구별되는 값을 가지고 널 값은 허용하지 않으므로 이를 확인하는 작업이 필요함. 그런데 값이 자주 변경되는 속성으로 구성된 후보키를 기본키로 선택하면 속성 값이 변경될 때마다 적합 여부를 판단해야하므로 번거롭다.
        • 단순한 후보키를 기본키로 선택
          • 자릿수가 적은 정수나 단순 문자열인 속성으로 구성, 구성하는 속성의 개수가 적은 후보키

     💡 기본키 선정 과정은 대학에서 학생회장을 선발하는 과정과 유사하다. 대학에 다니는 학생들(슈퍼키) 중에서 학생회장이 될 만한 자격을 갖춘 학생(후보키)을 추천한 다음, 지지를 가장 많이 받은 한 명의 학생(기본키)을 학생회장으로 임명하는 과정으로 이해하면 쉽다.

    • 대체키(alternate key) : 기본키로 선택되지 못한 후보키들

    • 외래키(foreign key) : 어떤 릴레이션에 소속된 속성 또는 속성 집합이 다른 릴레이션의 기본키가 되는 키
      • 다른 릴레이션의 기본키를 참조하는 속성의 집합
      • 참조하는 릴레이션 : 외래키를 가진 릴레이션
      • 참조되는 릴레이션 : 기본키를 가진 릴레이션
      • 외래키가 되는 속성과 기본키가 되는 속성의 이름은 달라도 되지만, 도메인은 같아야 한다.
      • 하나의 릴레이션에는 외래키가 어려 개 존재할 수도 있고, 외래키를 기본키로 사용할 수 있으며 외래키를 포함하여 기본키를 구성할 수 있다.
      • 자신의 기본키를 참조하도록 정의할 수 있음
      • 기본키를 참조하지만 기본키가 아니기 때문에 널 값을 가질 수 있음

     

    관계 데이터 모델의 제약

    관계 데이터 모델에서 정의하고 있는 기본 제약 사항은 키와 관련한 무결성 제약조건(integrity constraint)이다.

    무결성 : 데이터에 결함이 없는 상태, 즉 데이터가 정확하고 유효하게 유지된 상태

    목적 : 데이터베이스에 저장된 데이터의 무결성을 보장하고 데이터베이스 상태를 일관되게 유지하는 것’

    데이터베이스가 삽입, 삭제, 수정 연산으로 상태가 변하더라도 무결성 제약조건은 반드시 지켜져야 한다.

    권한이 있는 사용자의 잘못된 요구에 의해 데이터가 부정확해지지 않도록 보호하는 것

    데이터베이스의 상태를 일관성 있게 유지하기 위해서는 두 가지를 모두 만족시켜야 한다.

     

    개체 무결성 제약조건(entity integrity constraint)

    기본키를 구성하는 모든 속성은 널 값을 가지면 안된다는 규칙

    관계 데이터 모델에서는 릴레이션에 포함된 투플들을 유일하게 구별해주고, 각 투플에 쉽게 접근할 수 있도록 릴레이션마다 기본키를 정의합니다. 그런데 기본키를 구성하는 속성 전체나 일부가 널 값이 되면 투플의 유일성을 판단할 수 없어 기본키의 본래 목적을 상실하게 됩니다.

    위 사진은, 투플에서 기본키인 고객 아이디 속성의 값이 널입니다. 널 값은 아직 결정되지 않았거나 모르는 값을 의미하기 떄문에, 이 경우에는 정소화 고객과 정지영 고객의 아이디가 다른 고객의 아이디와 다른지를 판단하기 어렵습니다.

    개체 무결성 제약조건을 만족시키기 위해서는 새로운 투플이 삽입되는 연산과 기존 투플의 기본키 속성 값이 변경되는 연산이 발생할 때 기본키에 널 값이 포함되는 상황에서는 연산의 수행을 거부하면 된다.

    일반 사용자가 직접 수행하기 보다는 데이터베이스 관리 시스템이 자동으로 수행하므로 새로운 릴레이션을 생성할 때마다 기본키를 어떤 속성들로 구성할 것인지 데이터베이스 관리 시스템에 알려주면 된다.

     

    참조 무결성 제약조건(referential integrity constraint)

    외래키는 참조할 수 없는 값을 가질 수 없다는 규칙

    외래키는 다른 릴레이션의 기본키를 참조하는 속성이고 릴레이션 간의 관계를 표현하는 역할을 한다. 외래키가 자신이 참조하는 릴레이션의 기본키와 상관이 없는 값을 가지게 되면 두 릴레이션을 연관시킬 수 없으므로 외래키 본래의 의미가 없어진다.

    ⇒ 외래키는 자신이 참조하는 릴레이션에 기본키 값으로 존재하는 값, 즉 참조 가능한 값만 가져야 한다.

    ⇒ 주문번호가 1001인 cherry라는 주문고객의 속성 값은 현재의 고객 릴레이션에 존재하지 않는 고객아이디이다. 즉, 존재하지 않는 고객이 주문했다는 의미가 되므로 참조 무결성 제약조건을 위반한 예가 된다.

    만약 왜래키가 널 값인 경우에는 주문한 고객이 누구인지 모를 뿐, 고객 릴레이션에 존재하지 않는 고객이 주문한 것으로 판단하기 어렵다.

    💡 참조 무결성 제약조건을 만족시키려면 외래키가 참조 가능한 값만 가져야하지만, 널 값을 가진다고 해서 참조 무결성 제약조건을 위반한 것으로 판단해서는 안된다.

    💡 데이터베이스의 상태가 변해도 참조 무결성 제약조건을 만족시켜야 한다.

    데이터베이스 상태가 빈번하게 변경되는 경우 참조 무결성 제약조건을 계속 만족시키기가 쉽지 않다. 다행히 이러한 작업은 데이터베이스 관리 시스템이 자동으로 수행한다. 사용자는 새로운 릴레이션을 생성할 때마다 어떤 속성들이 오래키이고 어떤 릴레이션의 기본키를 참조하면 되는지 데이터베이스 관리 시스템에 알려주면 된다. 참조 무결성 제약조건을 위반하게 되는 경우에 원하는 처리방법도 알려주면 된다.

    728x90
Designed by Tistory.