3. 데이터베이스 구축 - 물리 데이터베이스 설계(스토리지 ~ 데이터베이스 품질 검토)

103. 스토리지

: 단일 디스크로 처리할 수 없는 대용량의 데이터를 저장하기 위해 서버와 저장장치를 연결하는 기술

 

- 스토리지의 종류

1. DAS (Direct Attached Storage)

: 서버와 저장 장치를 전용 케이블로 직접 연결하는 방식

• 서버에서 저장장치를 관리
• 직접 연결 방식 -> 다른 서버에서는 접근 불가, 파일 공유 불가
• 저장 데이터가 적고 공유가 필요 없는 환경에 적합한 방식
• 장점
  
  • 저장 장치를 직접 연결해 빠른 속도 보장
  • 쉬운 설치 및 운영
  • 저렴한 초기 구축 및 유지보수 비용
• 단점
  • 낮은 확장성 및 유연성 

 

2. NAS (Network Attached Storage)

: 네트워크를 통해 서버와 저장 장치를 연결하는 방식

• 별도의 파일 관리 기능을 가진 NAS Storage가 내장된 저장 장치를 직접 관리
• Ethernet 스위치를 이용한 접근 -> 다른 서버도 접근 가능, 파일 공유 가능
• 장점
  • 장소에 구애받지 않고 저장장치에 쉽게 접근 가능
  • DAS에 비해 우수한 확장성 및 유연성
• 단점
  • 접속 증가 시 성능 저하 위험

 

3. SAN (Storage Area Network)

: 서버와 저장 장치를 연결하는 전용 네트워크를 별도로 구성하는 방식

• 광 채널(Fiber Channel) 스위치를 이용해 네트워크를 구성
• DAS의 빠른 처리와 NAS의 파일 공유의 장점을 혼합한 방식
• 높은 트랜잭션 처리에 적합한 방식
• 장점
  • 광케이블로 서버나 저장장치를 연결 -> 빠른 처리 속도
  • 저장장치 공유 -> 여러 저장 장치나 백업 장비 단일화 가능
  • 뛰어난 확장성, 유연성, 가용성
• 단점
  • 비싼 네트워크 구축 비용 

---

104. 논리 데이터 모델의 물리 데이터 모델 변환

: 논리적 설계 단계에서 설계한 엔티티, 속성, 식별자 등의 논리 데이터 모델을 테이블, 컬럼, 키 등의 물리 데이터 모델로 변환하는 과정

 

1) 엔티티 -> 테이블 변환

: 논리 데이터 모델인 엔티티를 물리 데이터 모델인 테이블로 변환

• 테이블 목록 정의서 : 엔티티에서 변환한 테이블 전체를 목록으로 요약, 관리하는 문서
• 변환 규칙

• 변환 시 고려 사항
  • 일반적으로 테이블 명칭은 엔티티 명칭과 동일하게 적용
  • 테이블 명칭은 소스 코드의 가독성을 위해 영문명 사용
  • 메타 데이터 관리 시스템 내에 등록된 단어 사용

※ 메타 데이터 관리 시스템 : 메타 데이터를 수집하고 사용자들에게 제공하는 시스템

 

2) 슈퍼타입/서브타입 -> 테이블 변환

: 논리 데이터 모델에서 이용되는 슈퍼 타입/서브 타입을 테이블로 변환

 

1. 슈퍼타입 기준 변환

: 서브 타입을 슈퍼 타입에 통합하여 하나의 테이블로 변환

• 서브타입의 속성이나 관계가 적은 경우 적용
• 통합된 테이블은 모든 서브 타입의 속성을 포함
• 장점
  • 데이터 접근이 용이
  • 뷰를 이용해 각각의 서브타입에만 접근 및 수정이 가능
  • 서브타입 구분이 없는 임의 집합 처리 용이
  • 조인이 필요하지 않아 수행 속도 증가
  • SQL 문장 구성이 단순함
• 단점
  • 테이블 컬럼 증가 -> 디스크 공간 증가
  • 처리마다 서브타입에 대한 구분이 필요한 경우 증가
  • 인덱스 크기 증가 -> 인덱스 효율 감소

- 슈퍼타입 '회원' 개체를 기준으로 서브타입인 '판매자'와 '구매자' 개체를 통합

- 통합된 테이블 '회원'은 '판매자'와 '구매자'의 속성을 모두 포함

 

 

2. 서브타입 기준 변환

: 슈퍼타입의 속성들을 각각의 서브타입에 추가하여 개별적인 서브타입 테이블을 생성

• 서브타입에 속성이나 관계가 많이 포함된 경우 적용
• 만들어진 각각의 서브타입 테이블들은 슈퍼타입의 속성을 포함
• 장점
  • 각 서브타입 속성들의 선택 사양이 명확한 경우 유리
  • 처리할 때마다 서브타입 유형 구분이 필요없음
  • 테이블당 크기가 작음 -> 전체 테이블 스캔 시 유리
• 단점
  • 수행 속도 감소
  • 복잡한 처리 SQL의 통합이 어려움
  • 부분 범위에 대한 처리가 어려움
  • 서브타입 테이블을 통합한 뷰는 수정이 불가, 조회만 가능
  • 식별자의 유지 관리가 어려움

- 서브타입인 '판매자'와 '구매자' 개체별로 테이블을 생성

- 만들어진 각각의 테이블은 슈퍼타입인 '회원'의 속성을 모두 포함

 

 

3. 개별타입 기준 변환

: 슈퍼타입과 서브타입들을 각각의 개별적인 테이블로 변환

• 만들어진 슈퍼타입 테이블과 서브타입 테이블 간에는 1:1 관계가 성립
• 개별타입 기준 변환을 적용하는 경우
  • 전체 데이터에 대한 처리가 빈번
  • 서브타입의 처리가 대부분 독립적
  • 통합하는 테이블의 컬럼 수가 많음
  • 트랜잭션이 주로 슈퍼타입에서 이루어짐
  • 슈퍼타입의 처리 범위가 넓고 처리가 빈번하게 발생 -> 단일 테이블 클러스터링이 필요
• 장점
  • 저장 공간 소모가 적음
  • 슈퍼타입, 서브타입 각각의 테이블 정보만 조회하는 경우 문장 작성이 용이
• 단점
  • 슈퍼타입, 서브타입의 정보를 함께 처리하면 매번 조인 연산이 발생해 성능 저하

- 슈퍼타입인 '회원'과 서브타입인 '판매자'와 '구매자'를 각각 테이블로 변환

 

3) 속성 -> 컬럼 변환

: 논리 데이터 모델인 속성을 물리 데이터 모델인 컬럼으로 변환

• 변환 규칙

• 변환 시 고려 사항
  • 속성과 컬럼은 표준화된 약어를 통해 가능한 한 명칭을 일치
  • 컬렴명에 SQL 예약어 사용을 피함
  • 컬럼명은 가독성을 위해 가능한 짧게 지정
  • 복합 단어를 컬럼명으로 지정할 때는 표준을 사용
  • 컬럼 정의 후 row에 해당하는 샘플 데이터를 작성하여 컬럼의 정합성 검증

 

4) 관계 -> 외래 키 변환

: 논리 데이터 모델에서 정의된 관계를 기본 키와 이를 참조하는 외래 키로 변환

 

- 개체 A:B의 관계에 따라 

• 1:1 관계 : A(B)의 기본 키를 B(A)의 외래 키로 추가하여 표현
• 1:M 관계 : A의 기본 키를 B의 외래 키로 추가하여 표현
• M:N 관계 : 릴레이션 A와 B의 기본 키를 모두 포함하는 교차 릴레이션을 생성하여 표현
• 1:M 순환 관계 : 테이블 내에 자신의 기본 키를 참조하는 외래 키 컬럼을 추가하여 표현

 

5) 관리 목적의 테이블/컬럼 추가

: 논리 데이터 모델에는 존재하지 않지만 데이터베이스의 관리 또는 수행 속도 향상을 위해 물리 데이터 모델에 테이블, 컬럼 등을 추가

 

6) 데이터 타입 선택

: DBMS의 물리적 특성 및 성능을 고려하여 논리적 데이터 모델의 데이터 타입을 물리적 데이터 타입으로 변환

• 데이터의 길이와 최적의 데이터 타입 선택
• Oracle에서 자주 사용되는 데이터 유형
  • CHAR : 고정 길이 문자열 (최대 2000Byte)
  • VARCHAR2 : 가변 길이 문자열 (최대 4000Byte)
  • NUMBER : 38자릿수까지의 숫자
  • DATE : 날짜

---

105. 물리 데이터 모델 품질 검토

: 물리 데이터 모델 설계 및 데이터베이스 객체 생성 후 개발 단계로 넘어가기 전에 이해관계자들이 모여 물리 데이터 모델의 품질을 검토

• 물리 데이터 모델은 시스템 성능에 직접적인 영향을 미치므로 면밀한 검토필요
• 데이터베이스의 성능 향상과 오류 예방이 목적
• 모든 이해 관계자가 동의하는 검토 기준 필요
• 품질 검토 기준에 따라 각 물리 데이터 모델의 구성 요소에 대한 검토 항목 작성 (테이블, 컬럼, 무결성 제약 조건, etc)

 

- 물리 데이터 모델 품질 기준

• 정확성 : 요구사항, 업무 규칙, 표기법 등에 따라 정확하게 표현되었음
• 완전성 : 데이터 모델 구성 요소를 누락 없이 정의하고 요구사항을 누락 없이 반영함
• 준거성 : 데이터 표준, 표준화 규칙, 법적 요건 등을 정확히 준수함
• 최신성 : 최근의 이슈나 현행 시스템, 최신의 업무 변화 등을 반영함
• 일관성 : 표현상 일관성을 유지함
• 활용성 : 작성된 모델을 사용자가 쉽게 이해 및 사용할 수 있고, 업무 변화에도 데이터 구조 변화가 최소화될 수 있음

- 물리 데이터 모델 품질 검토 순서

1. 데이터 품질 정책 및 기준 확인
2. 물리 데이터 품질 특성에 따라 품질 기준 작성
3. 품질 기준에 따라 체크리스트 작성
4. 논리 데이터 모델과 물리 데이터 모델 비교
5. 품질 검토 수행
6. 작성한 체크리스트 내용을 종합하여 품질 검토 보고서 작성