02. relational model, 관계형 모델

Instances of Branch and Staff Relations

필드 Field : 열, column : 가장 작은 단위의 데이터 : 엔터티의 속성을 나타냄

Attribute 특성 : 엔티티를 설명하는 특성

데이터베이스에서 필드와 특성은 본직적으로 같은 것이다. 엔터티의 특수한(고유한) 성질.

레코드 Record : 튜플 tuple : 행 row : 논리적으로 연관된 필드의 집합

여러 레코드가 모여 하나의 테이블을 만든다.

테이블 table : 파일 file : 서로 연관된 레코드의 집합

엔터티 entity : 현실세계에 존재하는 것을 데이터베이스 상에 표현하기 위해 사용하는 추상적인 개념

고객을 관리하기 위해 사용하는 데이터베이스에서 ID, 나이, 클래스 라는 정보를 통해 고객이라는 엔터티(객체)를 표현하며, 구분할 수 있다.

레코드는 실제 데이터베이스 상에 저장되어 있는 값들의 모임, 엔터티는 현실 세계에 존재하는 객체를 표현하기 위해 비유적으로 사용된다.

스키마 schema : 전체적인 데이터베이스의 골격 구조를 나타내는 일종의 도면. 데이터베이스의 엔터티와 그 엔터티 간의 관계를 정의한다. e,g. 어떤 타입의 데이터가 어느 위치에 적재되어야 하는지, 다른 테이블이나 엔터티와 어떤 관계를 맺는지를 정의

기본키

• 키는 값이 꼭 있어야한다.
• 구분을 위해 고유값을 가져야한다.
  • NULL이거나 중복되면 안된다.
    • 모호함이 생기면 무결성이 깨지기 때문
• 레코드를 상징하는 값이어야한다. (대표성)
• 기본키에는 기본적으로 인덱스가 생성되어 검색 효율이 좋다. (자주 참조하는 속성)
• 테이블간의 연결고리가 되므로 비교 속도가 빨라야 한다. (가급적 짧은 속성)

조건을 만족하는 필드를 후보키, Candidate key라고 하고 한 테이블에 여러 후보키가 있다. 이 중 레코드를 가장 잘 대표하는 키 하나를 골라 기본키, Primary key, PK로 선정한다. 기본키를 선정하는 절대적인 규칙은 없으며 상황에 따라 달라 테이블 설계자가 여러 요인을 분석하여 잘 선택하면 된다.

DBMS는 기본키를 특별하게 관리한다. NULL금지와 중복 방지는 물론, 인덱스를 생성하여 검색 속도를 높인다. 기본키는 검색시 조건문에 활용하며 테이블간의 관계를 구성하는 연결고리로 사용한다. 따라서 기본키에 대해 인덱스를 생성해두면 조회 및 갱신 속도가 극적으로 향상된다.

관계 키

• 슈퍼키
  • 관계 내에서 튜플을 고유하게 식별하는 속성 또는 속성 집합
  • 수퍼(super)는 테이블의 행을 식별하는 여러 키의 단일 그룹입니다.
• 후보 키
  • 관계 내에서 적절한 부분 집합이 슈퍼 키가 되지 않도록 슈퍼키(K)
  • R의 각 튜플에서 K의 값은 그 튜플을 고유하게 식별한다.
  • 고유성(환원성)을 갖는 K의 적절한 부분 집합은 없다.
  • SQL에서 테이블에서 튜플을 고유하게 식별하는 속성 집합입니다. 반복 특성이 없는 슈퍼 키입니다.
• 후보 키의 속성
  • 고유한 값을 포함해야 합니다.
  • SQL의 후보 키에는 여러 속성이 있을 수 있습니다.
  • null 값을 포함할 수 없습니다.
  • 고유성을 보장하기 위해 최소 필드를 포함해야 합니다.
  • 테이블에서 각 레코드를 고유하게 식별
• 기본 키
  • 관계 내에서 튜플을 고유하게 식별하기 위해 후보 키가 선택됨
• 기본 키 정의 규칙
  • 두 행의 기본 키 값이 같을 수 없습니다.
  • 모든 행이 기본 키 값을 갖습니다.
  • 기본 키 필드는 null일 수 없습니다.
  • 외부 키가 기본 키를 참조하는 경우 기본 키 열의 값을 수정하거나 업데이트할 수 없습니다.
• 대체 키
  • 기본 키로 선택되지 않은 후보 키
• 외부 키
  • 일부(아마도 동일) 관계의 후보 키와 일치하는 한 관계 내의 속성 또는 속성 집합

무결성 관리

무결성, integrity : 데이터가 결함없이 완벽한 상태

• 클라이언트 : 입력할 정보에 꼭 맞는 컨트롤로 오입력을 원천 차단
• 서버 : DBMS가 규칙을 기억하고 있다가 비정상 데이터의 입력을 거부

서버에서는 속성으로 규칙을 선언하는 형태여서 단순한 점검만 가능하며 섬세한 처리는 한계가 있다. 적용 범위에 따라 다음 세가지로 나눌 수 있다.

• 컬럼 무결성 : 컬럼 하나에 저장되는 원자적인 값을 점검하며 도메인 무결성이라고도 한다. 타입 지정, 널 허용 여부, 체크, 기본값등의 제약이 있다.
• 엔터티 무결성 : 레코드끼리 중복값을 가지지 않도록 하여 유일한 식별자를 관리한다. 예를 들어 주민등록번호가 같은 두 명이 존재하지 않아야한다. 기본키, 유니크 제약등이 있다.
• 참조 무결성 : 테이블간의 관계를 구성하는 키가 항상 유효하도록 관리하며 외래키 제약으로 관리한다. 이쪽 테이블에 참조하는 정보가 반드시 저쪽 테이블에 존재해야 한다.

무결성을 유지하는 가장 기본적인 수단은 차입이며 데이터의 물리적인 포맷을 강제한다.

제약(constraint) : 조건을 위반하는 데이터를 방지하여 완전성을 보장하는 규칙

• 제약이 없으면 아무 데이터나 자유롭게 입력할 수 있지만 무결성이 쉽게 깨진다.
• NULL 허용
  • 널은 아무것도 입력되어 있지 않은 것이며 알 수 없거나 결정되지 않은 특수한 상태를 위미한다.
  • 필드의 널 허용 속성은 널상태가 존재하는 지를 지정한다.
  필드 선언 제일 뒤에 NULL이라고 작성하면 NULL을 서용한다는 뜻이고 NOT NULL이라고 작성하면 널을 허용하지 않는다는 뜻이다.널 허용 속성은 데이텁이스의 성능을 저해하는 주범이다. 항상 널 상태를 감안하여 필드값이 존재하는지 점검해야하고 보통의 값과는 다루는 방식이 달라 느릴 수 밖에 없다.
• NULL 허용 여부를 생략하면 DBMS의 디폴트 허용 여부를 따른다.

널 허용 대신 기본값을 사용하는 것이 성능상 유리하다.

• 기본값
• 기본값 : 필드값을 지정하지 않을 때 자동으로 입력할 값

관계대수

• 합집합, UNION
  • 릴레이션끼리 덧셈
• 차집합, difference
  • 릴레이션끼리 뺄셈
• 교집합, intersection
  • 릴레이션간의 교집합
• 곱집합, cartesian product
  • 릴레이션끼리의 대전표를 조합하는 연산
• 선택, SELECTION
  • 튜플(행)의 추출
• 투영, PROJECTION
  • 속성(열)의 추출
• 결합, JOIN
  • 릴레이션끼리 교차결합하여 계산된 곱집합에서 결합조건을 만족하는 튜플을 추출하는 연산

Designing the Database

설계

설계 단계에서는 분석 문서를 참조하여 구현 방법을 결정한다. 비즈니스 로직에 따라 실세계의 사물을 테이블로 정의하고 관계를 설정하는 작업을 모델링이라고 한다.

엔터티, Entity

: 정보에 해당하는 모든 실체이며 전산화의 대상

e.g. 고객, 상품, 날짜, 가격, 구매, 가입, 대여 ….

업무의 흐름을 분석하여 사물과 동작은 엔터티로 추출한다. 이때 보통 엔터티는 하나의 테이블로 구체화한다. 다음으로 엔터티를 구성하는 속성을 정의하는데 엔터티를 잘 관찰하면 어떤 속성이 있는지 조사하고 업무에 필요한 정보를 추출할 수 있다. 속성은 테이블의 필드로 구체화한다. 다음으로 추출한 속성 중에 엔터티를 대표하는 기본키를 설정한다. 레코드끼리 구분 가능한 고유성이 있고 자주 검색하는 속성을 선정해야 한다.

관계, relation

: 엔터티 간의 연결 형태, 관계형 DB의 특징을 결정하는 핵심

e.g. 1:1, 1:N, M:N

엔터티는 독립적으로 존재하지 않고 업무적으로 서로 연관된다. 고객이 상품을 ‘주문한다’에서 주문한다 가 관계이며 엔터티간의 연관성을 결정한다.

1 : 1 관계

: 양쪽 테이블의 인스턴스를 하나씩 연결

e.g. 남녀의 결혼 관계, (1)엔터티 정보가 너무 많아 테이블을 분할할 때

(1) 필드가 너무 많으면 가독성도 떨어지고 레코드가 커져 성능도 떨어진다. 따라서 자주 참조하는 정보와 그외의 정보들로 분할하면 성능이 향상된다. 이때 분할한 두 레코드의 짝을 찾을 수 있는 연결고리가 필요하다. 관계형 DB에서 레코드의 순서는 의미가 없어 순서로 연결할 수 없기 때문에 양쪽에 똑같은 키를 만들어두면 연결 관계를 알 수 있다. 학번이라는 외래키를 두면 상세 정보를 알고 싶을 때 학생 테이블의 학번을 조사한 후 학생의 상세 테이블로 가서 학번이 같은 레코드를 참조할 수 있다.

1 : 다 관계

: 하나의 인스턴스에 상대 테이블의 다수의 인스턴스가 연결

가장 흔하게 존재하는 관계

e.g. 부서와 직원

다 : 다 관계

: 양쪽의 엔터티가 서로 복수개의 엔터티로 연결된다.

e.g. 학생과 과목,

관계형 DB로는 다:다 관계를 표현할 수 없어 두 개의 1:다 관계로 변환하여 표현한다. 학생과 과목의 경우 학생과 과목 사이에 수강 엔터티를 삽입하여 두 개의 다:1, 1:다 관계로 변환한다.

모델링의 목적

데이터 구조를 중복없이 효율적으로 디자인하는 것이며 이를 위해 하나의 테이블을 여러개로 분할한다. 이때 분할된 테이블끼리의 연관성은 관계를 통해 설정하며 관계는 외래키 제약에 의해 구체화된다.

1. 기획

어떤 프로그램을 누가 어떻게 작성할지 계획을 세우며, 요구 기능, 예산, 개발 기간을 결정한다.

2. 분석

DB 응용 프로그램은 원래 사람이 하던 일을 전산화하는 것이다. 따라서 현실 세계의 수작업을 면밀히 분석하는 업무 파악부터 한다. 업무의 개요와 목적, 수행 방법, 규칙과 절차 등의 비즈니스 로직을 문서로 정리한다.

고도의 전문 지식이 필요한 경우는 개발자와 실무자가 함께 분석한다.

3. 설계

분석 문서를 참조하여 구현 방법을 결정한다. 규모에 맞는 하드웨어와 소프트웨어를 선정하고 업무에 필요한 사물을 추출한다.

비즈니스 로직에 따라 실세계의 사물을 테이블로 정의하고 관계를 설정하는 작업을 모델링이라고 한다. 최소의 비용으로 최적의 성능을 내는 것이 목적이다.

엔터티 정의 → 속성 정의 → 식별자 선정 → 관계 설정 → 정규화

모델링은 건축의 설계도에 해당한다. 구현 과정이 신속 정확하려면 모델링이 완벽해야 한다. 설계의 품질에 따라 수십억짜리 장비를 얼마나 활용할 수 있는지가 결정된다.

4. 구현

모델링한 데이터를 테이블로 구체화하고 효율적인 운영을 위한 인덱스, 프로시저 등을 정의한다.

데이터를 실제 사용하고 입출력하는 클라이언트 응용 프로그램을 개발하고 사용자를 위한 설명서와 유지, 보수를 위한 문서까지 작성한다.

5. 테스트 & 수정 (유지보수)

• 하나 이상의 관계를 바탕으로 연산한다.
• 연산한 결과, 반환되는 것 또한 관계이다.
• 연산을 중첩 구조로 실행해도 상관없다.