이미 소장하고 있다면 판매해 보세요.
|
2007년 졸트 Productivity 상 수상
|
|
1장 진화적 데이터베이스 개발
1.1 데이터베이스 리팩토링 1.2 진화적 데이터 모델링 1.3 데이터베이스 회귀 테스트 1.4 데이터베이스 아티팩트 형상관리 1.5 개발자 샌드박스 1.6 진화적 데이터베이스 개발 기술의 장애물 1.7 무엇을 배웠나 2장 데이터베이스 리팩토링 2.1 코드 리팩토링 2.2 데이터베이스 리팩토링 2.3 데이터베이스 리팩토링의 분류 2.4 데이터베이스 냄새 2.5 어떻게 데이터베이스 리팩토링을 적합하게 할 것인가 2.6 데이터베이스 스키마를 보다 쉽게 리팩토링하기 2.7 무엇을 배웠나 3장 데이터베이스 리팩토링 프로세스 3.1 데이터베이스 리팩토링이 적절한지 검증한다 3.2 가장 적절한 데이터베이스 리팩토링을 선택한다. 3.3 원본 데이터베이스 스키마는 더 이상 지원되지 않음을 표시한다. 3.4 리팩토링 전, 후는 물론 리팩토링 도중에도 테스트를 한다 3.5 데이터베이스 스키마를 변경한다 3.6 소스 데이터 마이그레이션(Migration) 3.7 외부 액세스 프로그램을 리팩토링한다 3.8 회귀 테스트를 실행한다 3.9 작업한 내용에 대해 버전 관리를 한다. 3.10 리팩토링이 끝났음을 알린다. 3.11 무엇을 배웠나 4장 프로덕션으로 배포하기 4.1 샌드박스 사이의 효과적인 배포 4.2 데이터베이스 리팩토링의 번들화 4.3 배포 윈도우 스케줄링 4.4 시스템 배포 4.5 더 이상 지원되지 않는 스키마 제거 4.6 무엇을 배웠나 5장 데이터베이스 리팩토링 전략 5.1 작은 변경사항이 적용하기 더 쉽다 5.2 개개의 리팩토링은 유일하게 식별되어야 한다 5.3 여러 개의 작은 변경으로 큰 변화를 구현한다 5.4 데이터베이스 설정 테이블을 유지한다 5.5 뷰나 배치 작업보다 트리거를 통한 동기화를 사용한다 5.6 충분한 과도기를 가진다 5.7 데이터베이스 ‘변경 관리 위원회’ 전략을 단순화한다 5.8 다른 팀과의 협의 과정을 단순화한다 5.9 데이터베이스 접근을 캡슐화한다 5.10 데이터베이스 환경설정을 쉽게 할 수 있도록 한다 5.11 SQL 문장의 중복을 피한다 5.12 데이터베이스 자산을 형상관리 시스템하에 둔다 5.13 정치를 숙지한다 5.14 무엇을 배웠나 6장 구조적 리팩토링 구조적 리팩토링 구현의 일반적인 고려사항 컬럼 제거 테이블 제거 뷰 제거 계산된 컬럼 도입 대리 키 도입 컬럼 병합 테이블 병합 컬럼 옮기기 컬럼명 바꾸기 테이블명 바꾸기 뷰 이름 바꾸기 LOB 형식을 테이블로 대체 일대다 관계를 연관 테이블로 바꾸기 대리키를 자연키로 바꾸기 컬럼 분할 테이블 분할 7장 데이터 품질 리팩토링 데이터 품질 리팩토링 구현시 일반적인 문제 룩업 테이블 추가 표준 코드 적용 표준 타입 적용 키 통합 전략 컬럼 제약조건 제거 기본값 제거 NULL 값을 허용하지 않는 제약조건 제거 컬럼 제약 조건 도입 일반 형식 도입 기본 값 도입(Introduce Default Value) NULL 값을 허용하지 않는 컬럼 만들기 데이터 옮기기 형식 코드의 속성 플래그화 8장 참조무결성 리팩토링 외래키 제약조건 추가 계산된 컬럼을 위한 트리거 추가 외래키 제약조건 삭제 캐스캐이딩 삭제 물리적 삭제 논리적 삭제 이력 데이터를 위한 트리거 9장 아키텍처적 리팩토링 CRUD 메서드 추가 미러 테이블 추가 읽기 메서드 추가 뷰를 이용한 테이블 캡슐화 계산된 메서드 도입 인덱스 도입 읽기 전용 테이블 도입 데이터베이스에서 마이그레이션 하는 메서드 데이터베이스로 마이그레이션하는 메서드 뷰로 메서드 대체 메서드로 뷰 대체 공식 데이터 소스 사용하기 10장 메서드 리팩토링 10.1 인터페이스 변경 리팩토링 10.1.1 매개변수 도입(Add Parameter) 10.1.2 메서드 매개변수화(Parameterize Method) 10.1.3 매개변수 제거(Remove Parameter) 10.1.4 메서드 이름변경(Rename Method) 10.1.5 매개변수 순서 변경(Reorder Parameters) 10.1.6 매개변수를 명시적 메서드로 바꾸기(Replace Parameter with Explicit Methods) 10.2 내부적인 리팩토링(Internal Refactorings) 10.2.1 조건식 통합(Consolidate Conditional Expression) 10.2.2 조건절의 분해(Decompose Conditional) 10.2.3 메서드 추출(Extract Method) 10.2.4 변수 도입(Introduce Variable) 10.2.5 제어 플래그 제거(Remove Control Flag) 10.2.6 중개자 제거(Remove Middle Man) 10.2.7 매개변수 이름 변경(Rename Parameter) 10.2.8 리터럴을 참조 테이블로 대체(Replace Literal with Table Lookup) 10.2.9 중첩된 조건절을 단위별 조건절로 대체(Replace Nested Conditional with Guard Clauses) 10.2.10 임시 변수 분리(Split Temporary Variable) 10.2.11 알고리즘 대체(Substitute Algorithm) 11장 변환 데이터 추가(Insert Data) 새로운 칼럼 도입(Introduce New Column) 새로운 테이블 도입(Introduce New Table) 뷰 추가(Add View) 데이터 변경(Update Data) 부록 데이터 모델링을 위한 UML 표시법 용어 정리 참고 & 추천 도서 찾아 보기 |
|
리팩토링(마틴 파울러 1999)은 소스코드를 조금씩 변경하는 것으로 그 디자인을 개선하고 그렇게 함으로써 기존보다 쉽게 작업할 수 있도록 하는 훈련된 방법이다. 리팩토링의 핵심적인 관점은 소스코드의 행위적 의미를 유지하는 것이다 -리팩토링 시 소스코드의 어떠한 추가나 삭제도 없다. 다만 그 질을 향상시킨다. 리팩토링 예는 getPersons() 오퍼레이션을 getPeople()로 이름을 변경하는 것이다. 이런 리팩토링을 구현하려면 오퍼레이션의 정의를 수정하고 나서, 애플리케이션 코드 전체에 걸쳐 이 오퍼레이션의 모든 호출을 변경하여야 한다. 리팩토링은 코드가 수정 전처럼 아무 문제 없이 다시 실행될 때까지는 끝난 것이 아니다.
이와 비슷하게, 데이터베이스 리팩토링은 데이터베이스 스키마를 간단히 변경하여 그 디자인을 개선하되, 그것의 행위와 정보의 의미는 모두 원래대로 유지하는 것이다. 테이블과 뷰 정의 같은 데이터베이스 스키마의 구조적 관점이나, 저장 프로시저와 트리거 같은 함수적 관점 중 하나를 리팩토링할 수 있다. 데이터베이스 스키마를 리팩토링할 때는 스키마 자체를 뜯어 고쳐야 할 뿐만 아니라, 해당 스키마에 종속성을 가진(커플링된) 비지니스 애플리케이션이나 데이터 추출 같은 애플리케이션 또한 재작성되어야 한다. 데이터베이스 리팩토링은 코드 리팩토링보다 그 구현이 훨씬 더 어렵기에 매우 신중해야 한다. 데이터베이스 리팩토링은 2장에서 자세하게 설명하며, 3장에서는 데이터베이스 리팩토링을 수행하는 프로세스에 대해 설명한다. ...... [ 1.1 데이터베이스 리팩토링] 중에서 |