[리펙토링 데이터베이스] 데이터베이스 냄새와 관리

 지금 필요로 하는 기술과 관련하여, 항상 일을 한 단계 발전시킬 수 있는 것을 선택해야 한다. 그러한 측면에서 프로그래머는 TDD, 리팩토링, AMDD와 이러한 작업을 쉽게 해주는 새로운 개발용 도구를 수용해야 한다.

 소프트웨어 프로세스 또는 방법론들은 모두 점진적이다. 점진적 방법에서는 한 번에 대규모로 배포하기 보다 일련의 작은 배포로써 시스템을 구축해 간다. 작은 배포와 함께 코드 리펙토링이라는 작업을 통해 점진적으로 코드를 개선해 나간다.

 데이터베이스에서도 점진적 방법을 사용할 수 있다. 코드 리펙토링에서 볼 수 있는 코드 냄새를 데이터베이스에 적용하여 데이터베이스 냄새를 알아보자.

 

 

데이터베이스 냄새

1. 다목적 컬럼 - 하나의 컬럼이 여러 가지 목적으로 사용된다면, 그 목적에 맞게 사용될 수 있도록, 값을 검사하는 여분의 코드가 존재한다. 예로 어떤 컬럼이 고객일 경우 고객의 생일을 저장하고, 직원일 경우 직원의 고용일을 저장하도록 사용된 경우다. 더 안 좋은 것은 지금 지원하고 있는 기능에 의해 제한되는 경우다. 예로 직원의 생일은 어떻게 저장할 것인가?
2. 다목적 테이블 - 테이블이 여러 가지 타입의 엔터티를 저장하기 위해 사용된다면 결함이 있는 디자인이다. 일반적인 Customer 테이블이 개인과 법인에 대한 모든 정보를 저장하도록 사용된 경우다. 이 때의 문제점은 개인과 법인은 서로 다른 데이터 구조를 갖는다는 것이다. 즉 개인은 이름과 성을 가지지만, 법인은 단순히 법적 이름만 갖는다. 일반적인 Customer 테이블은 다른 것은 그렇지 않을지 모르겠지만 몇 가지 고객 유형에 대해 NULL 값인 컬럼을 가지게 된다.
3. 중복 데이터 - 중복 데이터는 데이터가 여러 장소에 저장될 때, 데이터의 불일치가 발생할 가능성이 있기 때문에 데이터베이스 운영상 심각한 문제이다.
4. 너무 많은 컬럼을 가진 테이블 - 테이블이 너무 많은 컬럼을 가지게 될 때는 테이블의 응집도가 떨어지게 된다. Customer 테이블은 몇 개의 전화번호(자택, 직장, 핸드폰 등)를 담고 있다. 이 같은 경우는 Address와 PhoneNumber테이블을 추가하여 이러한 구조를 정규화할 필요가 있다.
5. 너무 많은 행을 가진 테이블
6. 스마트 컬럼 - 스마트 컬럼은 데이터 내의 다른 위치별로 다른 개념을 나타낸다. 예를 들어 고객 ID처음 4자리는 고객의 본점 코드를 나타낸다. 이렇듯 더욱 세분화된 정보(본점 ID)로 컬럼을 파싱해야 하기 때문에 고객 ID는 스마트 컬럼이다. 또 다른 예로 XML, JSON이 있다.
7. 제약조건의 불일치 - NotNull, 의미없는 default 설정

 

 

데이터베이스 관리

데이터베이스 리팩토링이 가능하려면 형상관리 제어 시스템 하에 다음 항목들을 저장할 필요가 있다.

1. 데이터베이스 스키마를 생성할 데이터 정의 언어(DDL) 스크립트
2. 데이터 모델 파일 (ERD)
3. 테스트 데이터 생성 스크립트

 

데이터베이스 리팩토링 분류

1. 구조적
   • 한 테이블에서 다른 테이블로 컬럼을 이동
   • 다목적 컬럼을 각기 하나의 목적을 가진 여러 개의 컬럼으로 분리
2. 데이터 품질
   • 데이터베이스 내에 담겨진 정보의 질을 향상
   • 컬럼을 NULL 혀용안함으로 설정하여 컬럼이 항상 어떤 값을 갖도록 보장
3. 참조무결성
   • 참조된 행이 다른 테이블 내에 존재하고 있음을 보장하며 해당 행이 적절히 삭제되어 더 이상 필요하지 않다는 것을 보장하는 변경, 두 개의 엔터티 및 데이터베이스 외부에서 예전에 구현된 쿠드 사이의 케스케이딩 삭제를 활성화 시키는 트리거를 추가
4. 아키텍처적
   • 데이터베이스와 상호작용하는 외부 프로그램을 전체적으로 개선시키는 변경, 공용 코드 라이브러리에 있는 기존 자바 오퍼레이션을 데이터베이스에 있는 저장 프로시저로 대체 저장 프로시저화 함으로서 비 자바 애플리케이션에서도 사용이 가능하게 한다.