[자격증] 정보처리기사 실기 : 4강 데이터 입출력 구현 (논리 데이터 저장소 확인하기, 물리 데이터 저장소 확인하기)

 정보

• 업무명     : 정보처리기사 실기 : 4강 데이터 입출력 구현 (논리 데이터 저장소 확인하기, 물리 데이터 저장소 확인하기)

• 작성자     : 이상호

• 작성일     : 2020-05-09

• 설   명      :

• 수정이력 :

 

 

 내용

[논리 데이터 저장소 확인하기]

[1] 논리 데이터모델 검증

• 일반적으로 시스템 개발은 데이터 관점과 프로세스 관점의 두가지로 진행되는데, 개념 모 델링을 통해 개발 범위를 파악하고, 업무 중심의 분석(논리 데이터 모델링, 분석 모델링)단계를 거쳐 개발하고자 하는 환경을 고려한 설계(물리 데이터 모델링, 설계 모델링)단계로 구체화되어 개발(데이터베이스 구축, 애플리케이션 개발)단계로 진행된다. 

 

 

[2] 데이터 모델의 개요 

• 1. 데이터 모델링 정의 

  • 기업의 정보 구조를 실체(Entity)와 관계(Relation)를 중심으로 명확하고 체계적으로 표현하여 문서화하는 기법을 말한다. 

• 2. 데이터 모델링 목적 

  • (1) 연관 조직의 정보요구에 대한 정확한 이해를 할 수 있다. 

  • (2) 사용자, 설계자, 개발자 간에 효율적인 의사소통 수단을 제공한다. 

  • (3) 데이터 체계 구축을 통한 고품질 S/W와 유지보수 비용의 감소효과를 기대할 수 있다. 

  • (4) 신규 또는 개선 시스템의 개발 기초를 제공한다

• 3. 데이터 모델링 특성 

  • (1) 데이터 중심 분석을 통한 업무 흐름 파악이 용이하다. 

  • (2) 데이터 무결성을 보장할 수 있다 

  • (3) 데이터의 공유를 통한 중복을 제거하고 일관성 있는 정보를 제공받을 수 있다.

 

[3] 데이터 모델링 절차

• 데이터 모델링은 개념 모델링, 논리 모델링, 물리 모델링을 통해 데이터베이스를 구축하는 일련의 절차를 거쳐 진행된다. 

 

• 1. 개념 데이터 모델링

  • 전사의 정보요건을 표현한 상위수준의 모델로서,

  • (1) 주요 엔터티타입, 기본 속성, 관계, 주요 업무기능 등을 포함한다.

  • (2) 모든 업무 영역을 포함하고, 주제 영역에 포함되는 중심 엔터티타입 간의 관계를 파 악하여 주요 업무 규칙을 정의한다. 

  • (3) 논리 데이터 모델의 기초가 된다.

 

• 2. 논리 데이터 모델링 

  • 개념모델로부터 업무영역의 업무 데이터 및 규칙을 구체적으로 표현한 모델로서, 

  • (1) 모든 업무용 엔터티타입, 속성, 관계, 프로세스 등을 포함한다. 

  • (2) 모든 업무 데이터를 정규화(Normalization) 하여 모델링한다. 

  • (3) 모든 업무 규칙과 관계를 완전하고 정확하게 표현한다. 

  • (4) 성능 혹은 기타 제약 사항과는 독립적인 모델로서, 특정 DBMS로부터 독립적이라 할 수 있다. 

 

• 3. 물리 데이터 모델링

  • 설계단계에서 시스템의 설계적 및 정보 요건을 정확하고 완전하게 표현한 모델로서, 

  • (1) 데이터베이스 생성을 위한 물리 구조로 변환한다. 

  • (2) 시스템 설계 요건 반영을 위한 아래와 같은 오브젝트를 추가한다. 

    • (가) 설계용 엔터티 타입 

    • (나) 설계용 속성 

  • (3) 설계와 성능을 고려한 조정을 수행한다. 

    • (가) 적용 DBMS 특성 고려

    • (나) 엔터티 타입의 분리 또는 통합 검토

    • (다) 반정규화(Denormalization)

    • (라) 관계의 해제 

  • (4) 적용 DBMS에 적합한 성능조정을 수행한다 

    • (가) 인덱스 추가 및 조정 

    • (나) 테이블 스페이스 조정 

    • (다) 인덱스 스페이스 조정

 

[4] 논리 데이터 모델링 개요

• 1. 논리 데이터 모델링 정의 

  • (1) 데이터베이스 개발 과정의 첫 단계로 전략수립 및 분석 단계에서 실시한다.

  • (2) 데이터 구조에 대한 논리적 정의단계로서 정확한 업무 분석을 통한 자료의 흐름을 분석하여 현재 사용 중인 양식, 문서, 장표를 중심으로 자료항목을 추출하여 추출된 엔터티(Entity)와 속성(Attribute)들의 관계(Relation)를 구조적으로 정의하는 단계이다. 

    • (가) 엔터티: 관리할 대상이 되는 실체 

    • (나) 속성: 관리할 정보의 구체적 항목 

    • (다) 관계: 엔터티간의 대응관계

 

• 2. 논리 데이터 모델링 특성 

  • (1) 논리적 데이터 모델링 시 요구사항을 충분히 수집하지 않으면 다음 단계의 요구사항 변경에 따른 많은 비용이 발생한다. 

  • (2) 모든 이해당사자들과 의사소통의 보조자료로서 E-R 모델을 활용한다. 

  • (3) 논리적 모델은 H/W나 S/W에 독립적이다.

 

• 3. 정규화(Normalization) 

  • (1) 정의 

    • 중복성을 최소화하고 정보의 일관성을 보장하기 위한 개념 

  • (2) 목적 

    • (가) 데이터 중복 배제로 데이터 관리 편의성 제고 및 자료 저장 공간의 최소화 

    • (나) 데이터 모형 단순화 

    • (다) 데이터 구조의 안정성 및 무결성 유지 

    • (라) 속성의 배열상태 검증 

       

    • (마) 엔터티와 속성의 누락 여부 검증 수단 

    • (바) 자료검색과 추출의 효율성을 추구

• (3) 특징 

  • (가) 어떠한 관계구조가 바람직한 것인지, 바람직하지 못한 관계를 어떻게 분해하여야 하는지에 관한 구체적인 판단기준을 제공 

  • (나) 정규화된 데이터 모델은 정확성, 일치성, 단순성, 비중복성, 안정성 보장 

• (4) 유형 

  • (가) 제1정규화 

    • 1) 반복되는 속성이나 Group 속성 제거 

    • 2) 새로운 실체와 1:N의 관계 추가 

    • 3) 모든 속성은 반드시 하나의 값을 가져야 함(반복형태가 있어서는 안됨)

  • (나) 제2정규화 

    • 1) 주식별자에 완전하게 종속되지 않는 속성 제거 

    • 2) 불완전 함수적 종속(Non Fully Dependency) 제거 

    • 3) 모든 속성은 반드시 UID전부에 종속되어야 함(UID일부에만 종속되어서는 안됨) 

  • (다) 제3정규화 

    • 1) 비식별자에 종속되는 속성 제거 

    • 2) 주식별자에 이행종속(Transitive Dependency) 되는 속성 제거 

    • 3) UID가 아닌 모든 속성 간에는 서로 종속될 수 없음(속성간 종속성 배제)

  • (라) 제4정규화 

    • 1) 실제로 거의 고려되지 않는 정규화 

    • 2) 주식별자에 다가종속(Multi-Valued Dependency)되는 속성을 두가지 이상 두지 않음 

    • 3) 2차 정규화된 테이블은 다대다 관계를 가질 수 없음 4) 어떠한 관계구조가 바람직한 것인지, 바람직하지 못한 관계를 어떻게 분해하 여야 하는지에 관한 구체적인 판단기준을 제공

• (4) 정규화 수준에 따른 장단점 

  • 정규화 수준이 높을수록, 

  • (가) 장점 

    • 1) 유연한 데이터 구축이 가능 

    • 2) 데이터의 정확성 높아짐 

  • (나) 단점 

    • 1) 물리적 접근이 복잡 

    • 2) 길이가 짧은 데이터 생성으로 과도한 조인 발생

 

• 4. 모델 작성 기법 

  • (1) 엔터티들은 정렬하여 배열한다. 

  • (2) 업무흐름의 진행 순서와 관련된 엔터티는 진행순서를 고려하여 좌에서 우, 상에서 하 로 중심에 배열한다. 

  • (3) 중심에 배열된 엔터티와 관계를 가진 엔터티를 가까이 배열한다. 

  • (4) 관계는 사선이 아닌 수직, 수평선을 사용한다. 

  • (5) 공간을 활용하여 복잡해 보이지 않도록 배열한다. 

  • (6) 교차선이 생기거나 관계선이 너무 길지 않도록 배열한다. 

  • (7) 관계있는 엔터티끼리 그룹핑한다.

 

[물리 데이터 저장소 설계하기]

[1] 물리 데이터 모델 설계

• 물리 데이터 모델링은 논리모델을 적용하고자 하는 기술에 맞도록 상세화해 가는 과정이다. 

• 따라서 앞으로 기술되는 내용은 특정 적용기술이나 DBMS를 전제할 수밖에 없기 때문에 시장 점 유율을 고려하여 범용적으로 활용되는 기술과 제품을 선택하여야 한다. 

• 앞으로 제시되는 내용은 시장에서 대부분 활용되고 있는 관계형 데이터베이스(RDBMS)의 오라클 데이터베이스를 기준으로 제시한다. 

 

[1] 반정규화(Denormalization) 개념

• 1. 정의 

  • 정규화에 충실하여 모델링을 수행하면 종속성, 활용성은 향상되나 수행속도가 증가하는 경우가 발생하여 이를 극복하기 위해 성능에 중점을 두어 정규화하는 방법 

• 2. 특징 

  • (1) 데이터 모델링 규칙에 얽매이지 않고 수행한다. 

  • (2) 시스템이 물리적으로 구현되었을 때 성능향상을 목적으로 한다.

• 3. 사용 시기 

  • (1) 정규화에 충실하였으나 수행속도에 문제가 있는 경우 

  • (2) 다량의 범위를 자주 처리해야 하는 경우 

  • (3) 특정범위의 데이터만 자주 처리하는 경우 

  • (4) 처리범위를 줄이지 않고는 수행속도를 개선할 수 없는 경우 

  • (5) 요약 자료만 주로 요구되는 경우 

  • (6) 추가된 테이블의 처리를 위한 오버헤드를 고려하여 결정 

  • (7) 인덱스의 조정이나 부분범위처리로 유도하고, 클러스터링을 이용하여 해결할 수 있는 지를 철저히 검토 후 결정

 

[2] 반정규화(Denormalization) 유형

• 1. 중복 테이블 추가 

  • (1) 용도 

    • (가) 다량의 범위를 자주 처리하는 경우 

    • (나) 특정 범위의 데이터만 자주 처리되는 경우 

    • (다) 처리범위를 줄이지 않고는 수행속도를 개선할 수 없는 경우 

  • (2) 방법 

    • (가) 집계 테이블의 추가 활용하고자 하는 집계정보를 위한 테이블을 추가하고, 각 원본테이블에 트리거를 등록시켜 생성하여 활용하는데, 이때  트리거의 오버헤드에 유의해야 한다. 

    • (나) 진행 테이블의 추가 이력관리 등의 목적으로 사용되며 활용도가 좋아지도록  기본키를 적절히 설정하여 야 한다. 

    • (다) 특정 부분만을 포함하는 테이블 추가 거대한 테이블의 특정 부분만을 사용하는 경우  자주 사용되는 부분으로 새로운 테 이블 생성하여 활용한다. 

 

• 2. 테이블 조합 

  • (1) 용도 대부분 처리가 두 개 이상의 테이블에 대해 항상 같이 일어나는 경우에 활용한다.

  • (2) 방법 해당 테이블을 통합하여 설계한다. 

  • (3) 고려사항 

    • (가) 데이터 액세스가 보다 간편하지만 Row수가 증가하여 처리량이 증가하는 경우가 발생될 수 있으므로 이를 고려해야 한다. 

    • (나) 입력, 수정, 삭제 규칙이 복잡해질 수 있음에 유의해야 한다. 

    • (다) Not Null, Default, Check 등의 Constraint를 완벽히 설계하기 어려운 점이 있다.

 

• 3. 테이블 분할 

  • (1) 용도 

    • (가) 칼럼의 사용빈도의 차이가 많은 경우 

    • (나) 각각의 사용자가 각기 특정한 부분만 지속적으로 사용하는 경우 

    • (다) 상황에 따라 SUPER-TYPE을 모두 내려 SUB-TYPE 별로 분할하거나 SUPER-TYPE만 은 따로 테이블을 생성하는 경우 

  • (2) 방법 

    • (가) 수직 분할 칼럼별 사용빈도의 차이가 많은 경우 자주 사용되는 칼럼들과 그렇지 않은 칼럼으 로 분류하여 테이블을 분할하는 방법이다. 

    • (나) 수평 분할 특정 범위별 사용 빈도의 차이가 많은 경우 해당 범위 별로 테이블을 분할하는 방 법이다

  • (3) 고려사항 

    • (가) 특정 칼럼 또는 범위를 사용하지 않는 경우 수행속도에 많은 영향이 있음을 고 려해야 한다. 

    • (나) 기본키의 유일성 관리가 어려워진다. 

    • (다) 액세스 빈도나 처리할 데이터양이 적은 경우는 분할이 불필요함을 고려하여야 한다. 

    • (라) 분할된 테이블은 오히려 수행속도를 나쁘게 하기도 함에 유의하여야 한다. 

    • (마) 데이터 프로세싱 관점이 아니라 검색에 중점을 두어 결정하여야 한다.

 

• 4. 테이블 제거 

  • (1) 용도 테이블 재정의나 칼럼의 중복화로 더 이상 액세스 되지 않는 테이블 발생할 경우

  • (2) 방법 해당 테이블을 삭제한다. 

  • (3) 고려사항 

    • (가) 관리 소홀로 인해, 누락 시 유지보수 단계에서 많이 발생하는 현상임을 고려해야 한다. 

    • (나) 유지보수 단계에서 초기 설계 시 예상하지 못했던 새로운 요구사항이 증가하게 되면 눈앞의 해결에만 급급하여 테이블의 추가나 변경이 함부로 일어나게 되어 시스템은 일관성과 통합성이 무너지게 된다는 사실을 간과해서는 안된다.

 

• 5. 칼럼의 중복화 

  • (1) 용도 

    • (가) 자주 사용되는 칼럼이 다른 테이블에 분산되어 있어 상세한 조건에도 불구하고 액세스 범위를 줄이지 못하는 경우 

    • (나) 대량 데이터에서 Row별 연산 결과를 얻고자 할 때 성능향상을 위한 파생 (Derived) 칼럼을 추가할 경우 

    • (다) 기본키의 형태가 적절하지 않거나 너무 많은 칼럼으로 구성된 경우

    • (라) 정규화 규칙에 얽매이지 않으면서 성능향상을 목적으로 한 반정규화(Denomalization) 를 통한 중복 데이터를 허용하는 경우 

  • (2) 방법 필요한 해당 테이블이나 칼럼을 추가한다. 

  • (3) 고려사항 

    • (가) 테이블 중복과 칼럼의 중복을 고려한다. 

    • (나) 데이터 일관성 및 무결성에 유의해야 한다. 

    • (다) SQL Group Function을 이용하여 해결 가능한지 검토한다. 

    • (라) 저장공간의 지나친 낭비를 고려해야 한다

 

물리 데이터저장소 구성

• 물리 데이터 모델링은 논리모델을 적용하고자 하는 기술에 맞도록 상세화해 가는 과정이다.

• 따라서 앞으로 기술되는 내용은 특정 적용기술이나 DBMS를 전제할 수 밖에 없기 때문에 시장 점유율을 고려하여 범용적으로 활용되는 기술과 제품을 선택하여야 한다.

• 앞으로 제시되는 내용은 시장에서 대부분 활용되고 있는 관계형 데이터베이스(RDBMS)의 오라클 데이터베이스를 기준으로 제시한다

 

[1] 테이블 제약조건

• 실무에서 주로 사용하는 테이블 제약조건으로는 다음 두가지가 있다. 

• 1. Delete Constraint 참조된 기본키의 값이 삭제될 경우의 처리내용을 정의한다. 

  • (1) Cascade: 참조한 테이블에 있는 외부키와 일치하는 모든 Row가 삭제된다. 

  • (2) Restricted: 참조한 테이블에 있는 외부키에 없는 것만 삭제 가능하다. 

  • (3) Nullify: 참조한 테이블에 정의된 외부키와 일치하는 것을 Null로 수정한다.

• 2. Update Constraint 참조된 기본키의 값이 수정될 경우의 처리내용을 정의한다. 

  • (1) Cascade: 참조한 테이블에 있는 외부키와 일치하는 모든 Row가 수정된다. 

  • (2) Restricted: 참조한 테이블에 있는 외부키에 없는 것만 수정가능하다. 

  • (3) Nullify: 참조한 테이블에 정의된 외부키와 일치하는 것을 Null로 수정한다.(해당 칼럼이 Null을 허용할 경우만)

 

[2] 인덱스 설계

• 1. 인덱스 적용 기준 

  • (1) 인덱스 칼럼의 분포도가 10 ~ 15% 이내인 경우

  • (2) 분포도가 범위 이상이더라도 부분처리를 목적으로 하는 경우 

  • (3) 입출력 장표 등에서 조회 및 출력 조건으로 사용되는 칼럼인 경우 

  • (4) 인덱스가 자동 생성되는 기본키와 Unique키의 제약조건을 사용할 경우

 

 

• 2. 인덱스 칼럼 선정 

  • (1) 분포도가 좋은 칼럼은 단독적으로 생성하여 활용도를 향상시킨다. 

  • (2) 자주 조합되어 사용되는 칼럼은 결합 인덱스로 생성하여 활용한다. 

  • (3) 결합 인덱스는 구성되는 칼럼순서 선정(사용빈도, 유일성, Sort,...)에 유의해야 한다. 

  • (4) 가능한 한 수정이 빈번하지 않은 칼럼을 선정한다. 

• 3. 설계 시 고려사항 

  • (1) 새로 추가되는 인덱스가 기존 액세스 경로에 영향을 미칠 수 있음에 유의한다. 

  • (2) 지나치게 많은 인덱스는 오버헤드로 작용한다. 

  • (3) 인덱스는 추가적인 저장공간이 필요함을 고려해야 한다. 

  • (4) 넓은 범위를 인덱스 처리 시 오히려 전체 처리보다 많은 오버헤드를 발생시킬 수 있 음에 유의해야 한다. 

  • (5) 인덱스와 테이블 데이터의 저장 공간을 적절히 분리될 수 있도록 설계해야 한다.

 

[3] 뷰 설계

• 1. 뷰 속성 

  • (1) REPLACE: 뷰가 이미 존재하는 경우 재생성 

  • (2) FORCE: 기본 테이블의 존재 여부에 관계 없이 뷰 생성 

  • (3) NOFORCE: 기본 테이블이 존재할 때 만 뷰 생성 

  • (4) WITH CHECK OPTION: Sub-Query 내의 조건을 만족하는 행만 변경

  • (5) WITH READ ONLY: DML 작업 불가

• 2. 뷰 설계 시 고려사항 

  • (1) 최종적으로는 테이블을 액세스하는 것이므로 사용에 따라 수행속도에 문제가 발생할 수 있다. 

  • (2) 뷰 내의 SELECT 문의 조건은 가능한 한 최적의 액세스 경로를 사용할 수 있도록 하거나 그럴 수 없다면 뷰를 사용한 SQL의 WHERE 절에서는 반드시 양호한 액세스 경로 가 되도록 하여야 한다.

 

[4] 클러스터 설계

• 1. 적용 기준 

  • (1) 분포도가 넓을수록 오히려 유리(인덱스의 단점을 해결)한 기법 

  • (2) 액세스 기법이 아니라 액세스 효율 향상을 위한 물리적 저장 방법 

  • (3) 분포도가 넓은 테이블의 클러스터링은 저장 공간의 절약 가능 

  • (4) 다중(일반적으로 6) 블록 이상의 테이블에 적용 

  • (5) 대량의 범위를 자주 액세스하는 경우 적용 

  • (6) 인덱스를 사용한 처리 부담이 되는 넓은 분포도에 활용 

  • (7) 여러 개의 테이블이 번번히 조인을 일으킬 때 활용 

  • (8) 반복 칼럼이 정규화에 의해 어쩔 수 없이 분할된 경우 활용

• 2. 클러스터 설계시 고려사항 

  • (1) 검색 효율은 높여 주나 입력, 수정, 삭제 시는 부하가 증가함을 고려하여야 한다. 

  • (2) Union, Distinct, Order by, Group by가 빈번한 칼럼이면 고려해 보아야 한다. 

  • (3) 수정이 자주 발생하지 않는 칼럼은 고려 대상이다. 

  • (4) 처리 범위가 넓어 문제가 발생하는 경우는 단일 테이블 클러스터링을, 조인이 많아 문제가 발생되는 경우는 다중 테이블 클러스터링을 고려하여야 한다. 

 

[5] 파티션 설계

• 1. 파티션 종류 

  • (1) 범위분할(Range Partitioning): 지정한 열의 값을 기준으로 분할 

  • (2) 해시분할(Hash Partitioning): 해시 함수에 따라 데이터를 분할

  • (3) 조합분할(Composite Partitioning): 범위분할에 의해 데이터를 분할한 다음 해시 함수를 적용하여 다시 분할 

• 2. 장점 

  • (1) 데이터 액세스 범위를 줄여 성능 향상 

  • (2) 전체 데이터의 훼손 가능성이 감소 및 데이터 가용성 향상 

  • (3) 각 분할 영역을 독립적으로 백업하고 복구가능 

  • (4) Disk Striping로 I/O 성능을 향상(Disk 컨트롤러에 대한 경합의 감소) 

• 3. 파티셔닝 순서 

  • (1) 파티션의 종류 결정 

  • (2) 파티션 키의 선정 

    • (가) I/O 분산을 어떻게 할 것인가를 고려하여 선정한다. 

    • (나) 액세스 유형에 따라 파티셔닝이 이루어질 수 있도록 파티션 키를 선정한다. 

    • (다) 이력 데이터의 경우, 생성주기 또는 소멸주기가 파티션과 일치하도록 한다. 

  • (3) 파티션 수의 결정 

 

[6] 디스크 구성 설계

• 1. 정확한 용량을 산정하여 디스크 사용의 효율을 높인다. 

• 2. 업무량이 집중되어 있는 디스크를 분리하여 설계함으로써 집중화된 디스크에 대한 입출 력 부하를 분산한다. 

• 3. 입출력 경합을 최소화하여 데이터의 접근 성능을 향상시킨다. 

  • (1) 테이블 객체를 위한 테이블 스페이스와 인덱스 객체를 위한 테이블스페이스를 분리 구성한다. 

  • (2) 테이블 스페이스와 템포러리 스페이스를 분리 구성한다. 

  • (3) 테이블을 마스터 테이블과 트랜잭션 테이블로 분류한다. 

• 4. 시스템의 구성(Disk의 구성)에 따라 테이블스페이스의 개수와 사이즈 등을 결정한다. 

• 5. 파티션 할 테이블은 별도로 분류한다

 

[연습문제]

• 데이터 모델링 목적이 아닌  것은?

  • (1) 연관 조직의 정보요구에 대한 정확한 이해를 할 수 있다. 

  • (2) 사용자, 설계자, 개발자 간에 효율적인 의사소통 수단을 제공한다. 

  • (3) 데이터 체계 구축을 통한 고품질 H/W와 유지보수 비용의 감소효과를 기대할 수 있다. 

  • (4) 신규 또는 개선 시스템의 개발 기초를 제공한다

 

• 데이터 모델링의 종류가 아닌것은?

  • s/w 모델링

  • 개념 모델링

  • 논리 모델링

  • 물리 모델링

 

 참고 문헌

[논문]

• 없음

[보고서]

• 없음

[URL]

• 없음

 

 문의사항

[기상학/프로그래밍 언어]

• sangho.lee.1990@gmail.com

[해양학/천문학/빅데이터]

• saimang0804@gmail.com

 

 

 

 

 

 

 

본 블로그는 파트너스 활동을 통해 일정액의 수수료를 제공받을 수 있음