데이터베이스 정리

Minu Jeong·2022년 8월 10일

데이터베이스

데이터베이스를 사용하는 이유

데이터베이스가 존재하기 이전에는 파일 시스템을 이용하여 데이터를 관리하였습니다. (현재도 부분적으로 사용되고 있음) 데이터를 각각의 파일 단위로 저장하며 이러한 일들을 처리하기 위한 독립적인 애플리케이션과 상호 연동이 되어야 한다. 이 때의 문제점은 데이터 종속성 문제와 중복성, 데이터 무결성입니다.

데이터베이스의 특징
1. 데이터의 독립성
  - 물리적 독립성 : 데이터베이스 사이즈를 늘리거나 성능 향상을 위해 데이터 파일을 늘리거나 새롭게 추가하더라도 관련된 응용 프로그램을 수정할 필요가 없습니다.
  - 논리적 독립성 : 데이터베이스는 논리적인 구조로 다양한 응용 프로그램의 논리적 요구를 만족시켜줄 수 있습니다.
2. 데이터의 무결성
  - 여러 경로를 통해 잘못된 데이터가 발생하는 경우의 수를 방지하는 기능으로 데이터의 유효성 검사를 통해 데이터의 무결성을 구현하게 됩니다.
3. 데이터의 보안성
  - 인가된 사용자들만 데이터베이스나 데이터베이스 내의 자원에 접근할 수 있도록 계정 관리 또는 접근 권한을 설정함으로써 모든 데이터에 보안을 구현할 수 있습니다.
4. 데이터의 일관성
  - 연관된 정보를 논리적인 구조로 관리함으로써 어떤 하나의 데이터만 변경했을 경우 발생할 수 있는 데이터의 불일치성을 배제할 수 있습니다. 또한 작업 중 일부 데이터만 변경되어 나머지 데이터와 일치하지 않는 경우의 수를 배제할 수 있습니다.
5. 데이터의 중복 최소화
  - 데이터베이스는 데이터를 통합해서 관리함으로써 파일 시스템의 단점 중 하나인 자료의 중복과 데이터의 중복성 문제를 해결할 수 있습니다.

인덱스를 사용하는 이유와 장단점

인덱스
- 테이블 색인 성능을 향상시키기 위해서 사용합니다.
- 하나 혹은 여러 개의 컬럼에 대해 설정할 수 있습니다.
- 인덱스는 데이터베이스 메모리를 사용하여 테이블 형태로 저장되므로, 개수와 저장 공간은 비례합니다.
  - 자주 사용되고 고유한 값 위주로 인덱스를 설정해줘야 합니다.
장점
- 카디널리티, 선택도, 활용도, 중복도를 고려하여 생성한 인덱스로 테이블의 빠른 색인이 가능합니다.
  - 컬럼 값의 중복 수치를 나타내는 지표를 "카디널리티(Cardinality)"라 합니다.
    - 카디널리티가 높을 수록 인덱스 설정에 좋은 컬럼입니다.
      -> 컬럼 값의 중복 정도가 낮을수록 좋습니다.
    - "학생" 테이블에 "학번" / "이름" 컬럼이 있을 때, 유니크한 값인 "학번"보다 동명이인이 있는 "이름"의 중복 정도가 높습니다. "이름" 컬럼을 카디널리티가 낮다고 할 수 있습니다.
    - "학번" 컬럼은 카디널리티가 높기 때문에, 인덱스 설정에 좋은 컬럼입니다.
  - 데이터에서 특정 값을 잘 선택할 수 있는 지표를 "선택도(Selectivity)"라 합니다.
    - 선택도가 낮을 수록 인덱스 설정에 좋은 컬럼입니다.
    - 5% ~ 10% 가 일반적으로 적당합니다.
    - 선택도의 계산 방법은 다음과 같습니다.
      - 컬럼의 특정 값의 row 수 / 테이블의 총 row 수 * 100
      - 컬럼의 값들의 평균 row 수 / 테이블의 총 row 수 * 100
    - 선택도는 필드값을 지정했을 때, 선택되는 레코드 수를 테이블 전체 레코드 수와 나눈 비율입니다.
  - 선택 컬럼이 실제 작업에서 얼마나 활용되는지에 대한 값은 "활용도"라 합니다.
    - 활용도가 높을수록 인덱스 설정에 좋은 컬럼입니다.
      - 수동 쿼리 조회, 로직과 서비스에서 쿼리를 처리할 때 WHERE 절에서 자주 활용되는지를 통해 판단할 수 있습니다.
  - 중복되는 인덱스 여부가 있는지에 대한 값을 "중복도"라 합니다.
    - 중복도가 없을수록 인덱스 설정에 좋은 컬럼입니다.
      - 인덱스도 테이블 형태로 생성되고 속성을 가집니다. 이 속성이 다를 때 같은 컬럼이라 할지라고 중복으로 인덱스 설정이 가능합니다.
      - 같은 컬럼에 중복 인덱스 설정이 되어 있더라도, SQL 자체 연산이 빠른 쪽으로 데이터를 조회합니다. 다만, 인덱스도 결국 메모리의 일부를 사용하기 때문에 필요없는 항목은 삭제하는 것이 좋습니다.
단점
- 인덱스를 관리하기 위한 추가 작업이 필요합니다.
  - INSERT : 새로운 데이터에 대한 인덱스를 추가
  - DELETE : 삭제하는 데이터의 인덱스를 사용하지 않는다는 작업 수행
  - UPDATE : 기존의 인덱스를 사용하지 않음 처리, 갱신된 데이터에 대한 인덱스 추가
- 인덱스는 별도의 메모리 공간에 저장되기 때문에, 추가 저장 공간이 필요합니다.
- 잘 못 사용하는 경우 오히려 검색 성능이 저하됩니다.
  - 장점에 언급한 4가지 항목 (카디널리티, 선택도, 활용도, 중복도)를 고려하지 않고 생성한 경우 오히려 성능이 낮아질 수 있습니다.
인덱스를 사용하면 좋은 케이스
- 데이터의 range가 넓고 중복이 적을수록, 조회가 많거나 정렬된 상태가 유용한 컬럼에 사용하는 것이 좋습니다.
  - 규모가 큰 테이블
  - 삽입(INSERT), 수정(UPDATE), 삭제(DELETE) 작업이 자주 발생하지 않는 컬럼
  - WHERE나 ORDER BY, JOIN 등이 자주 사용되는 컬럼
  - 데이터의 중복도가 낮은 컬럼

트랜잭션

트랜잭션이란, 데이터베이스의 상태를 변화시키는 하나의 논리적인 작업 단위라고 할 수 있으며, 트랜잭션에는 여러개의 연산이 수행될 수 있습니다.
트랜잭션은 수행중에 한 작업이라도 실패하면 전부 실패하고, 모두 성공해야 성공이라고 할 수 있습니다.

ACID

ACID는 트랜잭션이 안전하게 수행된다는 것을 보장하기 위한 성질입니다.
- Atomicity(원자성): 트랜잭션의 연산은 모든 연산이 완벽히 수행되어야 하며, 한 연산이라도 실패하면 트랜잭션은 실패해야 합니다.
- Consistency(일관성): 트랜잭션은 유효한 상태로만 변경될 수 있습니다.
- Isolation(고립성): 트랜잭션은 동시에 실행될 경우 다른 트랜잭션에 의해 영향을 받지 않고 독립적으로 실행되어야 합니다.
- Durability(내구성): 트랜잭션이 커밋된 이후에는 시스템 오류가 발생하더라도 커밋된 상태로 유지되는 것을 보장해야 합니다.
  -> 일반적으로 비휘발성 메모리에 데이터가 저장되는 것을 의미합니다.

트랜잭션 격리 수준(Transaction Isolation Levels)

READ UNCOMMITTED: 다른 트랜잭션에서 커밋되지 않은 내용도 참조할 수 있습니다.
READ COMMITTED: 다른 트랜잭션에서 커밋된 내용만 참조할 수 있습니다.
REPEATABLE READ: 트랜잭션에 진입하기 이전에 커밋된 내용만 참조할 수 있습니다.
SERIALIZABLE: 트랜잭션에 진입하면 락을 걸어 다른 트랜잭션이 접근하지 못하게 합니다.
-> 성능이 매우 저하됩니다.

정규화

정규화 과정을 거치는 이유
한 릴레이션에 여러 엔티티의 애트리뷰트들을 혼합하게 되면 정보가 중복 저장되며, 저장 공간을 낭비하게 된다. 또 중복된 정보로 인해
갱신 이상이 발생하게 됩니다. 동일한 정보를 한 릴레이션에는 변경하고, 나머지 릴레이션에서는 변경하지 않은 경우 어느 것이 정확한지 알 수 없게 되는 것이다. 이러한 문제를 해결하기 위해 정규화 과정을 거치게 됩니다.

갱신 이상
- 삽입 이상(insertion anomalies) : 원하지 않는 자료가 삽입된다든지, 삽입하는데 자료가 부족해 삽입이 되지 않아 발생하는 문제점을 말합니다.
- 삭제 이상(deletion anomalies) : 하나의 자료만 삭제하고 싶지만, 그 자료가 포함된 튜플 전체가 삭제됨으로 원하지 않는 정보 손실이 발생하는 문제점을 말합니다.
- 수정(갱신)이상(modification anomalies) : 정확하지 않거나 일부의 튜플만 갱신되어 정보가 모호해지거나 일관성이 없어져 정확한 정보 파악이 되지 않는 문제점을 말합니다.

정규화는 무엇인가요?
관계형 데이터베이스에서 중복을 최소화하기 위해 데이터를 구조화하는 작업입니다. 좀 더 구체적으로는 불만족스러운 나쁜 릴레이션의 애트리뷰트들을 나누어서 좋은 작은 릴레이션으로 분해하는 작업을 말합니다. 정규화 과정을 거치게 되면 정규형을 만족하게 됩니다. 정규형이란 특정 조건을 만족하는 릴레이션의 스키마의 형태를 말하며 제 1 정규형, 제 2 정규형, 제 3 정규형, … 등이 존재합니다.

1. 제 1 정규형

애트리뷰트의 도메인이 오직 원자값만을 포함하고, 튜플의 모든 애트리뷰트가 도메인에 속하는 하나의 값을 가져야 합니다. 즉, 복합 애트리뷰트, 다중값 애트리뷰트, 중첩 릴레이션 등 비 원자적인 애트리뷰트들을 허용하지 않는 릴레이션 형태를 말합니다.

2. 제 2 정규형

모든 비주요 애트리뷰트들이 주요 애트리뷰트에 대해서 완전 함수적 종속이면 제 2 정규형을 만족한다고 볼 수 있습니다.
완전 함수적 종속이란, X -> Y 라고 가정했을 때, X 의 어떠한 애트리뷰트라도 제거하면 더 이상 함수적 종속성이 성립하지 않는 경우를 말합니다. 즉, 키가 아닌 열들이 각각 후보키에 대해 결정되는 릴레이션 형태를 말합니다.

3. 제 3 정규형

어떠한 비주요 애트리뷰트도 기본키에 대해서 이행적으로 종속되지 않으면 제 3 정규형을 만족한다고 볼 수 있습니다.
이행 함수적 종속이란, X - >Y, Y -> Z의 경우에 의해서 추론될 수 있는 X -> Z의 종속관계를 말한다. 즉, 비주요 애트리뷰트가 비주요 애트리뷰트에 의해 종속되는 경우가 없는 릴레이션 형태를 말합니다.

4. BCNF(Boyce-Codd) 정규형

여러 후보 키가 존재하는 릴레이션에 해당하는 정규화 내용입니다. 복잡한 식별자 관계에 의해 발생하는 문제를 해결하기 위해 제 3 정규형을 보완하는데 의미가 있습니다. 비주요 애트리뷰트가 후보키의 일부를 결정하는 분해하는 과정을 말합니다.

정규화의 장단점

장점
- 데이터베이스 변경 시 이상 현상(Anomaly) 제거 위에서 언급했던 각종 이상 현상들이 발생하는 문제점을 해결할 수 있습니다.
- 데이터베이스 구조 확장 시 재 디자인 최소화 정규화된 데이터베이스 구조에서는 새로운 데이터 형의 추가로 인한 확장 시, 그 구조를 변경하지 않아도 되거나 일부만 변경해도 됩니다. 이는 데이터베이스와 연동된 응용 프로그램에 최소한의 영향만을 미치게 되며 응용프로그램의 생명을 연장시킵니다.
- 사용자에게 데이터 모델을 더욱 의미있게 제공 정규화된 테이블들과 정규화된 테이블들간의 관계들은 현실 세계에서의 개념들과 그들간의 관계들을 반영합니다.
단점
- 릴레이션의 분해로 인해 릴레이션 간의 연산(JOIN 연산)이 많아집니다. 이로 인해, 질의에 대한 응답 시간이 느려질 수 있습니다.
  - 데이터의 중복 속성을 제거하고 결정자에 의해 동일한 의미의 일반 속성이 하나의 테이블로 집약되므로 한 테이블의 데이터 용량이 최소화되는 효과가 있습니다. 따라서, 정규화된 테이블은 데이터를 처리할 때 속도가 빨라질 수도 있고 느려질 수도 있는 특성이 있습니다.

정규화 단점의 대응책

조회를 하는 SQL 문장에서 조인이 많이 발생하여 이로 인한 성능저하가 나타나는 경우에 반정규화를 적용하는 전략이 필요합니다.

반정규화(De-normalization, 비정규화)
반정규화는 정규화된 엔티티, 속성, 관계를 시스템의 성능 향상 및 개발과 운영의 단순화를 위해 중복 통합, 분리 등을 수행하는 데이터 모델링 기법 중 하나입니다. 디스크 I/O 량이 많아서 조회 시 성능이 저하되거나, 테이블끼리의 경로가 너무 멀어 조인으로 인한 성능 저하가 예상되거나, 칼럼을 계산하여 조회할 때 성능이 저하될 것이 예상되는 경우 반정규화를 수행하게 됩니다. 일반적으로 조회에 대한 처리 성능이 중요하다고 판단될 때 부분적으로 반정규화를 고려하게 됩니다.

반정규화의 대상
- 자주 사용되는 테이블에 액세스하는 프로세스의 수가 가장 많고, 항상 일정한 범위만을 조회하는 경우
- 테이블에 대량 데이터가 있고 대량의 범위를 자주 처리하는 경우, 성능 상 이슈가 있을 경우
- 테이블에 지나치게 조인을 많이 사용하게 되어 데이터를 조회하는 것이 기술적으로 어려울 경우
반정규화 과정에서 주의할 점
- 반정규화를 과도하게 적용하다 보면 데이터의 무결성이 깨질 수 있습니다.
- 입력, 수정, 삭제의 질의문에 대한 응답 시간이 늦어질 수 있습니다.

Minu Jeong

사용자에게 유용한 서비스를 만들고싶어요 :)

이전 포스트

세션 / 쿠키 / JWT 인증 방식에 대하여

다음 포스트