Secret

1. 데이터 베이스

  - 많은 사용자들은 보다 효율적인 데이터의 관리 뿐만 아니라 예기치 못한 사건으로 인한 데이터의 손상을 피하고, 필요시 필요한 데이터를 복구하기 위한 강력한 기능의 소프트웨어를 필요로 하게 되었고 이러한 기본적인 요구사항을 만족시켜주는 시스템을 DBMS(Database Management System)라고 한다.

가. 데이테베이스의 발전

  - 1960년대 : 플로우차트 중심의 개발 방법을 사용. 파일구조를 통해 데이터를 저장하고 관리

  - 1970년대 : 데이터베이스 관리기법이 처음 태동되었던 시기.

                   계층형(Hierarchical) 데이터베이스, 망형(Network) 데이터베이스 같은 제품들이 사용화 됨.

  - 1980년대 : 현재 대부분의 기업에서 사용되고 있는 관계형 데이터베이스가 사용용화 되었으며, Oracle, Sybase,

                    DB2와 같은 제품이 사용되었다.

  - 1990년대 : Oracle, Sybase, Informix, DB2, Teradata, SQL Server 외 많은 제품들이 보다 향상된 기능으로 정보

                   시스템의 확실한 핵심 솔루션으로 자리잡게 되었으며, 인터넷 환경의 급속한 발전과 객체지향 정보를

                   지원하기 위해 객체 관계형 데이터베이스로 발전하였다.

나 관계형 데이터베이스 (Relational Database)

2. SQL(Structured Query Language)

1. 내장함수 (BUILT-IN FUNCTION)

  - 데이터베이스를 설치하면 기본적으로 제공되는 함수

  - 단일행함수(Single-Row Function)

    : 함수는 입력되는 값이 아무리 많아도 출력은 하나만 된다는 M:1 관계

     단일행 내에 있는 하나의 값 또는 여러 값이 입력 인수로 표현될 수 있다.

   가)  단일행 함수의 종류  

  나) 단일행 함수의 중요한 특징

   - SELECT, WHERE, ORDER BY 절에서 사용 가능하다.

   - 각 행(Row)들에 대해 개별적으로 작용하여 데이터 값들을 조작하고, 각각의 행에 대한 조작 결과를 리턴한다.

   - 여러 인자(Argument)를 입력해도 단 하나의 결과만 리턴한다.

   - 함수의 인자(Argument)로 상수, 변수, 표현식이 사용 가능하고, 하나의 인수를 가지는 경우도 있지만 여러 개의 인수를 가질 수도 있다.

    - 특별한 경우가 아니면 함수의 인자로 함수를 사용하는 함수의 중첩이 가능하다.

 - 다중행함수(Multi-Row Function)

     - 집계형함수 (Aggregate Function)

     - 그룹함수(Group Function)

     - 윈도우함수(Windows Function)

2. 문자형함수

   - 문자데이터를 매개 변수로 받아들여서 문자나 숫자 값의 결과를 돌려주는 함수이다.

   - 몇몇 문자형 함수의 경우는 결과를 숫자로 리턴하는 함수도 있다.

   가. 단일행 문자형 함수의 종류

  나. 단일행 문자형 함수 사례

3. 숫자형 함수

4. 날짜형 함수

5. 변환형 함수

6. CASE 표현

7. NULL 관련 함수

1. 성능 데이터 모델링의 정의

  - 모델링 + 성능

  - 데이터베이스를 모델링할떄 성능까지 고려

  - 정규화만으로는 성능이 떨어질수 있으며, 반정규화 역정규화를 혼합해서 중복성을 이용하여 사용

 1. 분산 데이터베이스의 개요

   - 여러 곳으로 분산되어 있는 데이터베이스를 하나의 가상 시스템으로 사용할 수 있도록 한 데이터베이스

   - 논리적으로 동일한 시스템에 속하지만, 컴퓨터 네트워크를 통해 물리적으로 분산되어 있는 데이터들의 모임,

     물리적 SITE 분산, 논리적으로 사용자 통합 공유

   - 데이터베이스를 연결하는 빠른 네트워크 환경을 이용하여 데이터베이스를 여러지역 여러 노드로 위치시켜 사용성/성능

     등을 극대화 시킨 데이터베이스라고 정의할 수 있따.

2. 분산 데이터베이스의 투명성 (Transparency)

  1) 분할 투명성(단편화) : 하나의 논리적 Relation이 여러 단편으로 분할되어 각 단편의 사본이 여러 site에 저장

  2) 위치 투명성 : 사용하려는 데이터의 저장 장소 명시 불필요. 위치정보가 System Catalog에 유지되어야 함

  3) 지역사상 투명성 : 지역DBMS와 물리적 DB사이의 Mapping보장. 각 지역시스템 이름과 무관한 이름사용 가능

  4) 중복 투명성 : DB 객체가 여러 site에 중복 되어 있는지 알 필요가 없는 성질

  5) 장애 투명성 : 구성요소(DBMS, Computer)의 장애에 무관한 Transaction의 원자성 유지

  6) 병행 투명성 : 다수 Transaction 동시 수행시 결과의 일관성 유지. Time Stamp, 분산 2단계 Locking을 이용 구현

3. 분산 데이터베이스의 적용 방법 및 장단점

가. 분산 데이터베이스 적용방법

   - 업무의 흐름을 보고 업무 구성에 따른 아키텍처 특징에 따라 데이터베이스를 구성하는 것

   - 업무의 특징에 따라 데이터베이스 분산구조를 선택적으로 설계하는 능력이 필요

나. 분산 데이터베이스 장단점

4, 분산 데이터베이스의 활용 방향성

  - 업무적인 특징에 따라 분산 데이터베이스를 활용하는 기술이 필요함

5. 데이터베이스 분산구성의 가치

   - 통합된 데이터베이스에서 제공할 수 없는 빠른 성능을 제공

   - 네트워크 부하 및 트랜잭션 집중에 따른 성능 저하의 원인을 해결

6. 분산 데이터베이스의 적용 기법

가. 테이블 위치 분산

  - 테이블의 구조는 변하지 않는다.

  - 다른 데이터베이스에 중복되어 생성되지 않는다.

  - 설계된 테이블의 위치를 각각 다르게 위치시키는 것이다.

  - 테이블별 위치 분산은 정보를 이용하는 형태가 각 위치별로 차이가 있을 경우에 이용한다.

  - 테이블의 위치가 각각 다르므로 테이블의 위치를 파악할수있는 도식화된 위치별 데이터베이스 문서가 필요함

나. 테이블 분할(Fragmentation) 분산

   - 단순히 위치만 다른 곳에 두는 것이 아니라 각각의 테이블을 쪼개어 분산하는 방법

  1) 수평분할 (Horizontal Fragmentation)

   - 특정 컬럼의 값을 기준으로 로우(Row)를 분리

   - 컬럼은 분리되지 않으며, 데이터를 한군데 집합시켜 놓아도 PK에 의해 중복발생이 일어나지 않음.

   - 각 지사별로 사용하는 Row가 다를 때 이용한다.

   - 각 지사에 존재하는 테이블에 대해 통합처리하는 경우 JOIN이 발생하여 성능저하가 예상되므로, 통합처리 프로세스가

     많지 않은 경우에만 이용

  2) 수직분할 (Vertical Fragmentation)

   - 특정 컬럼값을 기준으로 컬럼을 분리한다.

   - 로우(Row)단위로는 분리되지 않는다.

   - 컬럼을 기준으로 분할하였으므로 각각의 테이블에는 동일한 PK구조와 값을 가지고 있어야 한다.

   - 실제 프로젝트에는 이런 환경을 구성하는 사례는 드물다.

다. 테이블 복제(Replication) 분산

   - 동일한 테이블을 다른 지역이나 서버에서 동시에 생성하여 관리하는 유형

  1) 부분복제 (Segment Replication)

   - 본사의 데이터는 지사데이터의 합이 되는것.

   - 각 지사에서 데이터 처리가 용이하다.

   - 전체 데이터에 대한 통합처리도 본사에 있는 통합 테이블을 이용하게 되므로 여러 테이블에 조인이 발생하지 않는 빠

    른 작업수행이 가능해짐

   - 실제 프로젝트에서 많이 사용하는 데이터베이스 분산기법

   - 각 지사별로 업무수행이 용이하고 본사에 있는 데이터를 이용하여 보고서를 출력하거나 통계를 산정하는 등 다양한

     업무형태로 이용 가능

  2) 광역복제 (Broadcast Replication)

   - 통합된 테이블을 한군데에 가지고 있으면서 각 지사에도 본사와 동일한 데이터를 모두 가지고 있는 형태

   - 지사에 존재하는 데이터는 반드시 본사에 존재하게 된다.

   - 모든 지사에 있는 데이터양과 본사에 있는 데이터양이 다 동일하다.

   - 실제 프로젝트에서 많이 사용하는ㄷ ㅔ이터베이스 분산기법에 해당한다.

라. 테이블 요약(Summarization) 분산

  - 지역간에 또는 서버 간에 데이터가 비슷하지만 서로 다른 유형으로 존재

  - 요약의 방식에 따라 동일한 테이블 구조를 가지고 있으면서 분산되어 있는 동일한 내용의 데이터를 이용하여 통합된

    데이터를 산출하는 방식

  1) 분석요약 (Rollup Replication)

   - 각 지사별로 존재하는 요약정보를 본사에 통합하여 다시 전체에 대해서 요약정보를 산출하는 분산방식

   - 통합 통계데이터에 대한 정보제공에 용이한 분산방법

 2) 통합요약 (Consolidation Replication)

   - 각 지사별로 존재하는 다른 내용의 정보를 본사에 통합하여 다시 전체에 대해서 요약정보를 산출하는 분산방법.

  - 통합 데이터에 대한 정보제공에 용이한 분산방법이다.

7. 분산 데이터베이스를 적용하여 성능이 향상된 사례

 -  성능이 중요한 사이트에 적용해야 한다.

 - 공통코드, 기준벙보, 마스터 데이터 등에 대해 분산환경을 구성하면 성능이 좋아진다

 - 실시간 동기화가 요구되지 않을 때 좋다. 거의 실시간의 업무적인 특징을 가지고 있을때도 분산 환경을 구성할 수 있다.

 - 특정 서버에 부하가 집중이 될 때 부하를 분산할 때도 좋다.

 - 백업 사이트를 구성할 때 간단하게 분산기능을 적용하여 구성할 수 있다.

1. 슈퍼타입/서브타입 모델의 성능고려 방법

가. 슈퍼/서브타입 데이터 모델의 개요

   - Extended ER 모델이라고 부르는 이른바 슈퍼/서브타입 데이터 모델

   - 최근 데이터 모델링을 할 때 자주 쓰이는 모델링 방법

   - 업무를 구성하는 데이터의 특징을 공통과 차이점의 특징을 고려하여 효과적으로 표현할 수 있기 때문에 자주 쓰임

   - 공통의 부분을 슈퍼타입으로 모델링 하고 공통으로부터 상속받아 다른 엔터티와 차이가 있는 속성에 대해서는 별도의

     서브엔터티로 구분하여 업무의 모습을 정확하게 표현하면서 물리적인 데이터 모델로 변환을 할 때 선택의 폭을 넓힐 수

     있는 장점이 있다.

   - 논리적인 데이터 모델에서 이용되는 형태이고 분석단게에서 많이 쓰이는 모델

   - 물리적인 데이터 모델을 설계시에는 일정한 기준에 의해 변환을 해야함.

   - 아무런 기준없이 변환하는 것 자체가 성능이 저하될 수 있는 위험이 있음.

나. 슈퍼/서브타입 데이터 모델의 변환

   - 성능이 저하되는 이뉴는 트랜잭션 특성을 고려하지 않고 테이블이 설계되었기 때문.

   1) 트랜잭션은 항상 일괄로 처리하는데 테이블은 개별로 유지되어 Union연산에 의해 성능이 저하될 수 있다.

   2) 트랜잭션은 항상 서브타입 개별로 처리하는데 테이블은 하나로 통합되어 있어 불필요하게 많은 양의 데이터가 집약되

      어 있어 성능이 저하되는 경우

   3) 트랜잭션은 항상 슈퍼+서브 타입을 공통으로 처리하는데 개별로 유지되어 있거나 하나의 테이블로 집약되어 있어

      성능이 저하되는 경우가 있다.

   - 트랜잭션이 빈번하게 처리되는 기준에 따라 테이블을 설계해야 성능저하 현상을 예방할 수 있다.

   - 물리적인 데이터모델로 변환하는 기준은 데이터 양과 해당 테이블에 발생되는 트랜잭션의 유형에 따라 결정된다.

   - 데이터양이 소량일 경우 1:1관계가 바람직하다

   - 데이터양이 대량일 경우 트랜잭션이 해당 테이블에 어떻게 발생되는지에 다라 3개지 변환방법을 참조하야한다.

다. 슈퍼/서브 타입 데이터 모델의 변환기술

   1) 개별로 발생되는 트랜잭션에 대해서는 개별 테이블로 구성

    - 공통으로 처리하는 슈퍼타입테이블인 당사자 정보를 미리 조회하고 원하는 내용을 클릭하면 거기에 따라서 서브타입

      인 세부적인 정보 즉 이해관계인, 매수인, 대리인에 대한 내용을 조회하는 형식

   2) 슈퍼타입+서브타입에 대해 발생되는 트랜잭션에 대해서는 슈퍼타입+서브타입 테이블로 구성

    - 대리인이 10만건, 매수인이 500만건, 이해관계인이 500만건일때, 그 중 대리인에 대한 처리가 개별적으로 많이 발생하

      는대 매수인과 이해관계인의 데이터까지 포함되어 있으므로 최대 10만건을 읽어 처리할 수 있는 업무가 최대 1천10만

      건을 읽어 처리하는 경우가 발생된다.

      이럴경우에는 슈퍼타입+각서브타입을 하나로 묶어 별도의 테이블로 구성하는 것이 효육적이다.

   3) 전체를 하나로 묶어 트랜잭션이 발생할 때는 하나의 테이블로 구성

   - 대리인 10만건, 매수은이 500만건, 이해관계인이 500만 건일때, 이를 항상 통합하여 처리한다고 하면 테이블을 하나로

     묶었을 때 각각의 속성별로 제약사항(NULL/NOT NULL, 기본값, 체크값)을 정확하게 지정하지 못할지라도 대용량이고

     성능향상이 필요하다면 하나의 테이블로 묶어서 만들어준다.

라. 슈퍼/서브타입 데이터 모델의 변환타입 비교 

2. 인덱스 특성을 고려한 PK/FK 데이터베이스 성능향상

가. PK/FK 컬럼 순서와 성능개요

   - 간단한것 같지만 실전 프로젝트에서는 아주 중요한 내용이 바로 PK순서이다.

   - 물리적인 데이터 모델링 단계에서는 스스로 생성된 PK순서 이외에 다른 엔터티로부터 상속받아 발생되는 PK순서까지

     항상 주의하여 표시하도록 해야한다.

   - PK순서를 결정하는 기준은 인덱스 정렬구조를 이해한 상태에서 인덱스를 효율적으로 이용할 수 있도록 PK순서를

     지정해야한다.

   - 앞쪽에 위치한 속성값이 가급적 '=' 아니면 최소한 범위 'BETWEEN''<>'가 들어와야 인덱스를 이용할수 있다.

   - FK에 대해서 반드시 인덱스를 생성하도록 하고 인덱스 칼럼의 순서도 조회의 조건을 고려하여 접근이 가장 효율적인

     칼럼 순서대로 인덱스를 생성하도록 주의해야 한다.

나. PK칼럼의 순서를 조정하지 않으면 성능이 저하 이유

  - 테이블의 주문번호가 가장먼저 정렬되고 그에 따라 주문일자가 정렬이 되고 마지막으로 주문목록코드가 정렬된다.

  - 이러한 정렬구조로 인해 데이터를 접근하는 트랜잭션의 조건에 따라 다른 인덱스 접근방식을 보여준다.

  - 인덱스의 정렬된 첫번째 컬럼에 비교가 되면 순차적으로 데이터를 찾아가지만 맨 앞에 컬럼이 제외된 상태에서 데이터

     를 죄회 할 경우 데이터를 비교하는 범위가 매우 넓어지게 되어 성능 저하를 유발하게 된다.

  - PK의 순서를 인덱스 특징에 맞게 고려하지 않고 바로 그대로 생성하게 되면, 테이블에 접근하는 트랜잭션의 특징에

    효율적이지 않은 인덱스가 생성되어 있으므로 익덱스의 범위를 넓게 이용하거나 Full Scan을 유발하게 되어 성능이

    저하된다고 정리할 수 있다.

다. PK순서를 잘못 지정하여 성능이 저하된 경우 - 간단한 오류

  - 입시마스터_I01 인덱스가 수험번호 + 년도 + 학기 중 수험번호에 대한 값이 where절에 들어오지 않으므로 full table

    scan이 발생. 성능저하

  - 년도와 학기에 대한 내용이 빈번하게 들어오므로 pk순서를 위와같이 변경함으로서 인덱스를 이용 가능하도록 한다.

라. PK순서를 잘못 지정하여 성능이 저하된 경우 - 복잡한 오류

  - 거래일자+사무소코드+출급기번호+명세표번호 순서.. 사무소코드가 '='으로 들어오고, 거래일자는 'BETWEEB'조회이므

    로 인덱스를 정상적으로 타나 효율은 떨어지는 CASE.

   - 즉, 넓은 범위를 스캔함으로서 인덱스는 타지만 성능은 저하되는 케이스

   - 사무소코드+거래일자로 구성된 인덱스의 경우 '='비교를 한 사무소코드가 인덱스 앞에 위치하여 범위가 좁아짐

   - 인덱스의 순서를 고려하여 모델의 PK순서를 거래일자+사무소코드+출급기번호+명세표번호 에서

    사무소코드 + 거래일자 + 출급기번호 + 명세표번호로 수정하여 성능을 개선한다.

3. 물리적인 테이블에 FK제약이 걸려있지 않을 경우 인덱스 미생성으로 성능저하

   - 비록 수강신청 테이블에 있는 학사기준번호가 SQL WHERE절에 비교자로 들어오지는 않았지만 수강신청 테이블에서 상속받은 학사기준번호에 대해 인덱스를 생성하지 않으므로 인해 학사기준과 수강신청 테이블이 조인이 되면서 500만 건의 수강신청 테이블이 FULL TABLE SCAN이 발생되어 성능이 저하 됨.

    - 이때는 수강신청 테이블에 FK인덱스를 생성하여 성능을 개선할수 있음.

    - 물리적으로 학사기준과 수강신청이 연결되어 있지 ㅇ낳다고 하더라도 학사기준으로부터 상속받은 FK에 대해 FK인덱스를 생성함으로써 SQL문장이 조인이 발생할 때 성능저하를 예방할수 있다.

   - 물리적인 테이블에 FK제약 걸었을 때는 반드시 FK인덱스를 생성하도록 하고 FK제약이 걸리지 않았을 경우 FK인덱스를 생성하는 것을 기본정책으로 하되 발생되는 트랜잭션에 의해 거의 활용되지 않았을 때에만 FK인덱스를 지우는 방법으로 하는 것이 적절한 방법이 된다.

1. 식별자(Identifiedrs)의 개념

  -  여러 개의 집합체를 담고 있는 하나의 통에서 각각을 구분할 수 있는 논리적인 이름

  - 하나의 엔터티에 구성되어 있는 여러 개의 속성 중에 엔터티를 대표할 수 있는 속성을 의미

  - 반드시 하나의 유일한 식별자가 존재해야 한다.

  - Key     :  물리 데이터 모델링

    식별자 : 논리 데이터 모델링

2. 식별자의 특징

가.  주 식별자의 특징

  - 주 식별자에 의해 엔터티 내에 모든 인스턴스들이 유일하게 구분되어야 한다.

  - 주 식별자를 구성하는 속성의 수는 유일성을 맞고하는 최소의 수가 되어야 한다.

  - 지정된 주 식별자의 값은 자주 변하지 않는 것이어야 한다.

  - 주 식별자가 지정이 되면 반드시 값이 들어와야 한다.

  - 유일성 : 주식별자에 의해 엔터티 내에 모든 인스턴스들을 유일하게 구분함

     예) 사원번호가 주식별자가 모든 직원들에 대해 개인별로 고유하게 부여됨

  - 최소성 : 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 함

     예) 사원번호만으로도 고유한 구조인데 사원분류코드+사원코드로 식별자가 구성될 경우 부절한 주식별자 구조임

  - 불변성 : 주식별자가 한 번 특정 엔터티에 지정되면 그 식별자의 값은 변하지 않아야 함

     예) 사원번호의 값이 변한다는 의미는 이전기록이 말소가되고 새로운 기록이 발생되는 개념임

  - 존재성 : 주식별자가 지정되면 반드시 데이터 값이 존재(Null 안됨)

     예) 사원번호 없는 회사직원은 있을 수 없음

나. 외부식별자의 특징

  - 주식별자 특징과 일치 하지 않으며 참조무결성 제약조건 (Referential Intergrity)에 따른 특징을 가지고 있다

3. 식별자 분류 및 표기법

가. 식별자 분류

나. 식별자 표기법

1. 관계의 개념

가. 관계의 정의

   - 사전적인 의미 : 상호 연관성이 있는 상태

   - 엔터티의 인스턴스 사이의 논리적인 연관성으로서 존재의 형태로서나 행위로서 서로에게 연관성이 부여된 상태.

나. 관계의 패어링

  - 유의해야할 점

    관계는 엔터티 안에 인스턴스가 개별적으로 관계를 가지는 것(패어링)이 있고, 이것의 집합을 관계로 표현한다는 것.

    따라서 개별 인스턴스가 각각 다른 종류의 관계를 가지고 있다면 두 엔터티 사이에 두 개 이상의 관계가 형성 될수 있다.

2. 관계의 분류 

   - UML(Unified Modeling Language) 에는 클래스다이어그램의 관계중 연관관계(Association)와 의존관계

     (Dependency)가 있다.

   - 연관관계(Association)

     항상 이용하는 관계로 존재적 관계에 해당한다.

   - 의존관계(Dependency)

     상대방 클래스의 행위에 의해 관계가 형성될 때 구분하여 표현하는것.

3. 관계의 표기법 

가. 관계명(Membership) : 관계의 이름

  - 관계시작점(The Beginning)  : 관계가 시작되는 편

  - 관계끝점(The End) : 관계를 받는 편

  - 애매한 동사를 피한다.

   관계된다, 관련이 있다, 이다, 한다 등은 구체적이지 않아 어떤행위가 있는지 또는 어떤 상태가 존재하는지 파악할수 없음

  - 현재형으로 표현한다. ('수강을 신청했다', '강의를 할 것이다'라는 식으로 표현해서는 안된다)

나.  관계차수(Cardinality)

 1) 1:1(ONE TO ONE) 관계를 표시하는 방법

2) 1:M (ONE TO MANY) 관계를 표시하는 방법

3) M:M (MANY TO MANY)관계를 표시하는 방법 

다. 관계선택사양(Optionality) 

   - 필수참여 : 참여하는 모든 참여자가 반드시 관계를 가지는, 타 엔터티의 참여자와 연결이 되어야 하는 관계

   - 선택참여 : 목록은 주문이 될수도 있고 되지 않을수도 있는 반드시는 아닌 관계

4. 관계의 정의 및 읽는 방법

가. 관계 체크사항

   - 두 개의 엔터티 사이에 관심있는 연관규칙이 존재하는가?

   - 두 개의 엔터티 사이에 정보의 조합이 발생되는가?

   - 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?

   - 업무기술서, 장표에 관계연결을 가능하게 하는 동사가 있는가?

나. 관계 읽기

  - 기준(Source) 엔터티를 한 개(One) 또는 각(Each)으로 읽는다.

  - 대상(Target) 엔터티의 관계참여도 즉 개수(하나, 하나 이상)를 읽는다.

  - 관계선택사양과 관계명을 읽는다.

1. 속성(Attribute)의 개념

  1) 사전적 의미 : 사물의 성질, 특징 또는 본질적인 성질. 그것이 없다면 실체를 생각할 수 없는 것

  2) 정의

   - 업무에서 필요로 한다

   - 의미상 더 이상 분리되지 않는다.

   - 엔터티를 설명하고 인스턴스의 구성요소가 된다.

2. 엔터티, 인스턴스와 속성, 속성값에 대한 내용과 표기법

가. 엔터티, 인스턴스, 속성, 속성값의 관계

  - 한 개의 엔터티는 두 개 이상의 인스턴스의 집합이어야 한다.

  - 한 개의 엔터티는 두 개 이상의 속성을 갖는다.

  - 한 개의 속성은 한 개의 속성값을 갖는다.

  - 속성은 엔터티에 속한 엔터티에 대한 자세하고 구체적인 정보를 나타내며 각각의 속성은 구체적인 값을 갖게된다.

나. 속성의 표기법 

3. 속성의 특징

  도출된 속성이 다음의 성질을 만족하지 못하면 적절하지 않은 속성일 확률이 높다.

  - 엔터티와 마찬가지로 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다.

  - 정규화 이론에 근간하여 정해진 주식별자에 함수적 종속성을 가져야 한다.

  - 하나의 속성에는 한 개의 값만을 가진다. 하나의 속성에 여러 개의 값이 있는 다중값일 경우 별도의 엔터티를 이용하여

    분리한다.

4. 속성의 분류

가. 속성의 특성에 따른 분류

  1) 기본속성 

   - 업무로부터 추출한 모든 속성이 여기에 해당하며 엔터티에 가장 일반적이고 많은 속성을 차지한다.

   - 코드성 데이터, 엔터티를 식별하기 위해 부여된 일련번호, 그리고 다른 속성을 계산하거나 영향을 받아 생성된 속성을

      제외한 모든 속성은 기본속성이다.

   - 주의점 : 업무로부터 분석한 속성이라도 이미 업무상 코드로 정의한 속성이 많다는 것

                 이러한 경우도 속성의 값이 원래 속성을 나타내지 못하므로 기본속성이 되지 않음.

  2) 설계속성

   - 업무상 필요한 데이터 이외에 데이터 모델링을 위해, 업무를 규칙화하기 위해 속성을 새로 만들거나 변형하여 정의하는

     속성

   - 대개 코드성 속성은 원래 속성을 업무상 필요에 의해 변형하여 만든 설계속성이고,

     일련번호와 같은 속성은 단일(Unique)한 식별자를 부여하기 위해 모델 상에서 새로 정의하는 설계속성이다.

  3) 파생속성

   - 다른 속성에 영향을 받아 발생하는 속성으로서 보통 계산된 값들이 이에 해당된다.

   - 다른 속성에 영향을 받기 때문에 프로세스 설계 시 데이터 정합성을 유지하기 위해 유의해야 할 점이 많다.

   - 파생속성은 가급적 적게 정의하는 것이 좋다.

   - 계산된 로직을 속성의 정의서의 기록함으로서 향후 속성값에 대한 검증 시 활용하기도 한다.

나. 엔터티 구성방식에 따른 분류 

   - PK(Primary Key) 속성 : 엔터티를 식별할 수 있는 속성

   - FK(Foreign Key)속성 :  다른 엔터티와의 관계에서 포함된 속성  

   - 일반속성 :  엔터티에 포함되어 있고 PK, FK에 포함되지 않은 속성

   - 복합속성 : 시,구,동,번지 등과 같은 여러 세부 속성들로 구성될 수 있는 속성

   - 단순속성 : 나이, 성별 등과 같이 더이상 다른 속성들로 구성될 수 없는 단순한 속성

   - 속성은 하나의 값을 가지고 있으나 동일한 성질의 여러 개의 값이 나타나는 경우가 있다.

      단일값 : 하나에 한개의 값을 가지는 경우

      다중값 : 하나에 여러개의 값을 가지는 경우

5. 도메인

   - 속성이 가질수 있는 값의 범위

6. 속성의 명명

  - 용어사전 : 속성 이름을 정확하게 부여하고, 용어의 혼란을 없애기 위함

  - 도메인정의 : 각 속성이 가지는 값의 범위를 명확하게 하기 위

  - 속성명 부여 원칙

   1. 해당 업무에서 사용하는 이름을 부여한다.

   2. 서술식 속성명은 사용하지 않는다.

   3 약어사용은 가급적 제한한다.

   4. 전체 데이터 모델에서 유일성 확보하는 것이 좋다

1. 엔터티의 개념

  - 우리말로 실체, 객체라고 번역하기도 함.

가. 정의

   - 변별할 수 있는 사물 (Peter Chen (1976))

   - 데이터베이스 내에서 변별 가능한 객체 (C.J Date(1986))

   - 정보를 저장할 수 있는 어떤 것 (James Martin(1989)

   - 정보가 저장될 수 있는 사람, 장소, 물건, 사건 그리고 개념 등 (Thomas Bruce(1992))

나.  정의된 것의 공통점

   - 엔터티는 사람, 장소, 물건, 사건, 개념 등의 명사에 해당한다.

   - 엔터티는 업무상 관리가 필요한 관심사에 해당한다.

   - 엔터티는 저장이 되기 위한 어떤 것(Thing)이다.

다. 엔터티란?

   - 업무에 필요하고 유용한 정보를 저장하고 관리하기 위한 집합적인 것(Thing)

   - 업무 활동상 지속적인 관심을 가지고 있어야 하는 대상

   - 그 대상들간에 동질성을 지닌 인스턴스들이나 그들이 행하는 행위의 집합

   - 눈에 보이지 않는 것(Thing)이 엔터티로 도출되는 경우가 많다.

   - 인스턴스의 집합

2. 엔터티와 인스턴스에 대한 내용과 표기법

      - 엔터티 = 과목, 강사, 사건

      - 인스턴스 = 수학, 영어

3. 엔터티의 특징

가. 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 함

나. 유일한 식별자(Unique Identifier)에 의해 식별이 가능해야 함

   - 어떤 엔터티건 임의의 식별자(일련번호)를 부여하여 유일하게 만들 수 있다.

   - 엔터티 인스턴스만의 고유한 이름이 필요함. (사원번호, 주민등록번호)

다. 영속적으로 존재하는 인스턴스의 집합이어야 함

   - 한개가 아니라 두개 이상이라는 집합개념

   - 인스턴스가 한 개 밖에 없는 회사, 병원 엔터티는 집합이 아니므로 엔터티 성립이 안됨.

라 엔터티는 업무 프로세스에 의해 이용되어야 함

   - 업무 프로세스에 의해 이용되지 않는 엔터티는 그 업무의 엔터티가 아님

마. 엔터티는 반드시 속성이 있어야 함

  - 속성이 존재하지 않는 오브젝트는 엔터티가 될 수 없다.

바. 엔터티는 다른 엔터티와 최소 한 개 이상의 관계가 있어야 함.

   - 엔터티가 관계가 없으면, 잘못된 엔터티이거나 관계가 누락되었을 가능성이 크다.

   - 관계를 생략하여 표현해야 하는 경우

      통계를 위한 엔터티의 경우

      코드를 위한 엔터티의 경우

      시스템 처리시 내부 필요에 의한 엔터티(트랜잭션 로그테이블 등)

4. 엔터티의 분류

가. 유무형에 따른 분류

  1) 유형엔터티(Tangible Entity) : 물리적인 형태가 있고 안정적이며 지속적으로 활용되는 엔터티.

                                              업무로부터 엔터티를 구분하기가 가장 용이하다. (사원, 물품, 강사 등)

  2) 개념엔터티(Conceptual Entity) : 물리적인 형태는 존재하지 않고 관리해야 할 개념적 정보로 구분이 되는 엔터티

                                                 (조직, 보험상품 등)

  3) 사건엔터티(Event Entity) : 업무를 수행함에 따라 발생되는 엔터티로서 비교적 발생량이 많으며 각종 통계자료에

                                         이용될수 있다. (주문, 청구, 미납)

나. 발생시점에 따른 분류

  1) 기본엔터티 : 그 업무에 원래 존재하는 정보로서 다른 엔터티와 관게에 의해 생성되지 않고 독립적으로 생성이

                       가능하고 자신은 타 엔터티의 부모의 역활을 하게 된다. 다른 엔터티로부터 주식별자를 상속받지

                       않고 자신의 고유한 주식별자를 가지게 된다. (사원, 부서, 고객, 상품, 자재 등)

 2) 중심엔터티 : 기본엔터티로부터 발생되고 그 업무에 있어서 중심적인 역활을 한다. 데이터의 양이 많이 발생되고

                  다른 엔터티와의 관계를 통해 많은 행위엔터티를 생성한다. (계약, 사고, 예금원장, 청구, 주문, 매출 등)

 3) 행위엔터티 : 두 개 이상의 부모엔터티로부터 발생되고 자주 내용이 바뀌거나 데이터양이 증가된다. 분석초기

                     단계에서는 잘 나타나지 않으며 상세 설계단계나 프로세스와 상관모델링을 진행하면서 도출될 수

                     있다. (주문목록, 사원변경이력 등)

다. 엔터티 분류 방법의 예 

5. 엔터티의 명명

  - 가능하면 현업업무에서 사용하는 용어를 사용한다.

  - 가능하면 약어를 사용하지 않는다.

  - 단수명사를 사용한다.

  - 모든 엔터티에서 유일하게 이름이 부여되어야 한다.

  - 엔터티 생성의미대로 이름을 부여한다.

1. 모델링의 이해 

가. 모델링의 정의

  사람이 살아가면서 나타날 수 있는 다양한 현상은 사람, 사물, 개념 등에 의해 발생된다고 할 수 있으며 모델링은 이것을 표기법에 의해 규칙을 가지고 표기하는 것 자체를 의미한다. 즉 모델을 만들어가는 일 자체를 모델링으로 정의 할 수 있다.

나. 특징

 - 추상화 : 현실세계를 일정한 형식에 맞추어 표현을 한다는 의미

 - 단순화 : 복잡한 현실세계를 약속된 규약에 의해 제한된 표기법이나 언어로 표현하여 쉽게 이해할수있도록 하는 것

 - 명확화 : 누구나 이해하기 쉽게 하기 위해 대상에 대한 애매모호함을 제거하고 정확하게 현상을 기술하는 것

다. 모델링의 세 가지 관점

 - 데이터관점 : 업무가 어떤 데이터와 관련이 있는지 또는 데이터간의 관계는 무엇인지에 대해서 모델링 하는 방법

   (What, Data)

 - 프로세스관점 : 업무가 실제하고 있는 일은 무엇인지 또는 무엇을 해야 하는지를 모델링 하는 방법

  (How, Process)

 - 데이터와 프로세스의 상관관점 : 업무가 처리하는 일의 방법에 따라 데이터는 어떻게 영향을 받고 있는지 모델링하는 방법 (Interaction)

2. 데이터 모델의 기본 개념의 이해

가. 데이터 모델링의 정의

 - 정보시스템을 구축하기 위해, 해당 업무에 어떤 데이터가 존재하는지 또는 업무가 필요로 하는 정보는 무엇인지를

   분석하는 방법

 - 기업 업무에 대한 종합적인 이해를 바탕으로 데이터에 존재하는 업무규칙(Business Rule)에 대하여 참 또는 거짓

   을 판별할 수 있는 사실(사실명제)을 데이터에 접근하는 방법(How), 사람(Who), 전산호와는 별개의 관점에서 이를

   명확하게 표현하는 추상화 기법

나. 데이터 모델이 제공하는 기능

 - 시스템을 현재 또는 원하는 모습으로 가시화하도록 도와준다

 - 시스템의 구조와 행동을 명세화 할 수 있게 한다.

 - 시스템을 구축하는 과정에서 결정한 것을 문서화한다.

 - 다양한 영역에 집중하기 위해 다른 영역의 세부 사항은 숨기는 다양한 관점을 제공한다.

 - 특정 목표에 따라 구체화된 상세 수준의 표현방법을 제공한다.

3. 데이터 모델링의 중요성 및 유의점

가. 파급효과 (Leverage)

   - 시스템 구축이 완성되가는 시점에서의 데이터 모델 변경은 엄청난 파급효과를 발생시킨다.

   - 데이터 구조변경에 따른 표준영향분석, 응용영향분석등 많은 영향 분석이 일어난다.

   - 변경해야할 데이터 형태에 따른 영향도는 차이가 있겠지만, 구조 변경으로 인한 일련의 변경작업은 전체 시스템

     구축 프로젝트에서 큰 위험요소이다.  따라서, 데이터 설계는 그만큼 중요하다

나. 복잡한 정보 요구사항의 간결한 표현 (Conciseness)

  - 데이터 모델은 구축할 시스템의 정보 요구사항과 한계를 가장 명확하고 간결하게 표현할 수 있는 도구이다

다. 데이터 품질 (Data Quality)

  -  데이터는 중요한 자산이며, 기간이 오래될수록 활용가치는 더 커진다.

  -  그러나, 데이터의 정확성이 떨어진다면? 데이터의 활용가치는 떨어지게 된다.

      따라서 데이터 모델링을 할때는 다음을 유의하여 데이터 품질을 높여야 한다.

  - 중복 ( Duplication)

   데이터 모델은 같은 데이터를 사용하는 사람, 시간, 장소를 파악하는데 도움을 준다. 이러한 지식응용은 데이터베이

   스가 여러 장소에 같은 정보를 저장하는 잘못을 하지 않도록 한다.

 - 비유연성 (Inflexibility)

  데이터 모델을 어떻게 설계했느냐에 따라 사소한 업무변화에도 데이터 모델이 수시로 변경됨으로써 유지보수의

  어려움을 가중시킬 수 있다. 데이터의 정의를 데이터의 사용 프로세스와 분리함으로써 데이터 모델링은 데이터 혹은

  프로세스의 작은 변화가 애플리케이션과 데이터베이스에 중대한 변화를 일으킬 수 있는 가능성을 줄인다.

 - 비일관성 (Inconsistency)

  데이터의 중복이 없더라도 비일관성은 발생한다. 예를 들어 신용 상태에 대한 갱신 없이 고객의 납부 이력정보를

  갱신하는 것이다. 개발자가 다른 데이터와 모순되다는 고려 없이 일련의 데이터를 수정할 수 있기 때문이다. 데이터

  모델링을 할 때 데이터와 데이터간 상호 연관 관계에 대한 명확한 정의는 이러한 위험을 사전에 예방할 수 있도록

  해준다

4. 데이터 모델링의 3단계 진행 

가. 개념적 데이터 모델링 (Conceptual Data Modeling)

   추상화 수준이 높고 업무중심적이고 포괄적인 수준의 모델링 진행. 전사적 데이터 모델링, EA수립시 많이 이용

나. 논리적 데이터 모델링 (Logical Data Modeling)

   시스템으로 구축하고자 하는 업무에 대해 Key, 속성, 관계 등을 정확하게 표현, 재사용성이 높음

다. 물리적 데이터 모델링 (Physical Data Modeling)

   실제로 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적인 성격을 고려하여 설계.

5. 프로젝트 생명주기 (Life Cycle)에서 데이터 모델링

6. 데이터 모델링에서 데이터독립성의 이해

가. 데이터 독립성 필요성

  - 유지보수 비용증가

  - 데이터 중복성 증가

  - 데이터복잡도 증가

  - 요구사항 대응 저하

  - 데이터독립성을 확보시 얻는 효과

   - 각 View의 독립성을 유지하고 계층별 View에 영향을 주지 않고 변경이 가능

   - 단계별 Schema에 따라 데이터 정의어(DDL)와 데이터 조작어(DML)가 다름을 제공.

나. 데이터베이스 3단계 구조

 ANSI/SPARC의 3단계 구성의 데이터독립성 모델은 외부단계와 개념적 단계, 내부적 단계로 구성된 서로 간섭되지 않는 모델을 제시

다. 데이터독립성 요소

라. 두 영역의 데이터독립성

마. 사상(Mapping)

 상호 독립적인 개념을 연결시켜주는 다리를 뜻한다.

7. 데이터 모델링의 중요한 세가지 개념

가. 데이터 모델링의 세 가지 요소

  1) 업무가 관여하는 어떤 것 (Things)

  2) 어떤 것이 가지는 성격(Attributes)

  3) 업무가 관여하는 어떤 것 간의 관계(Relationships)

나. 단수와 집합(복수)의 명명

8. 데이터 모델링의 이해관계자

가. 이해관계자의 데이터 모델링 중요성 인식

   우리가 구축하려는 시스템 대부분을 데이터에 기반한, 데이터가 중심에 있는 정보시스템을 구축하기 때문에 정보

시스템의 핵심에 있는 데이터베이스 설계를 잘못했을 때 미치는 영향력은 모든 프로그램, 시간에 따라 입력되는 모든

데이터, 그리고 그 데이터베이스에 발생되는 모든 트랜잭션에 영향을 미칠 수 밖에 없게 된다.

  Bachmann은 '프로그래머는 데이터집합의 탐색자이다'라고 하였다. 그만큼 데이터에 대한 중요성을 높게 평가하는 것이다.

나. 데이터 모델링의 이해관계자

 -  누가 데이터 모델링에 대해 연구하고 학습해야 하는가?

    1. 정보시스템을 구축하는 모든사람(전문적으로 코딩만하는 사람포함)

    2. IT기술에 종사하거나 전공하지 않았더라도 해당 업무에서 정보화를 추진하는 위치에 있는 사람

9. 데이터 모델의 표기법인 ERD의 이해

가. 데이터 모델 표기법

  - 1976년 Peter Chen이 Entity-Relationship Model(E-R Model)이라는 표기법을 만듬.

  - 이 표기법은 데이터 모델링에 대한 이론을 배울 때 많이 활용되고 있음.

  - DAP 관련 자격에서는 Barker표기법을 적용

  - IE /Barker 표기법 가장 많이 사용되며, 상호간 기술적으로 전환이 가능하기 때문에 한가지만 정확하게 알고 있어

   도 다른 표기법을 이해하는데 큰 어려움이 없음

나. ERD(Entity Relationship Diagram) 표기법을 이용하여 모델링하는 방법

 1) ERD 작업순서

   1. 엔터티를 그린다

   2. 엔터티를 적절하게 배치한다.

   3. 엔터티간 관계를 설정한다.

   4. 관계명을 기술한다.

   5. 관계의 참여도를 기술한다.

   6. 관계의 필수여부를 기술한다.

 2) 엔터티 배치

     - 좌에서 우로, 위에서 아래

    - 가장 중요한 고객과 주문을 좌측 상단에 배치

    - 주문에 따른 출고 및 재고를 주문의 아래에 차례로 배치

    - 업무 흐름의 중심이 되는 엔터티(주문,출구,주문목록,출고목록)를 중앙에 배치

    - 중심 엔터티와 관계있는 엔터티(창고, 고객, 사원,재고)를 주위에 배치

 3) ERD 관계의 연결

   - 서로 관련있는 엔터티간의 관계를 설정

   - 초기에는 모두 PK로 속성이 상속되는 식별자 관계를 설정

   - 중복관계, Cycle 관계 등을 유의

 4) ERD 관계명의 표시

   - 관계이름은 현재형을 사용

   - 지나치게 포괄적인 용어는 사용하지 않음

   - 실무에서는 생략해도 무방 - 관계명이 없어도 ERD의 흐름을 알 수 있다.

 5) ERD 관계 관계차수와 선택성 표시

10. 좋은 데이터 모델의 요소

가. 완전성 (Completeness)

   업무에서 필요로 하는 모든 데이터가 데이터 모델에 정의되어 있어야 한다.

나. 중복배제 (Non-Redundancy)

   하나의 데이터베이스 내에 동일한 사실은 반드시 한 번만 기록하여야 한다. (예 = 나이, 생년월일 (중복))

   저장공간의 낭비, 중복 관리되고 있는 데이터의 일관성을 유지하기 위한 추가적인 데이터 조작 등이 대표적으로

   낭비되는 비용이라 볼 수 있다.

다. 업무규칙(Business Rules)

  Business Rules(업무규칙)을 데이터 모델에 표현하고 이를 해당 데이터 모델을 활용하는 모든 사용자가 공유할 수

  있도록 제공

  데이터 아키텍처에서 언급되는 논리데이터모델(Logical Data Model)에서 이러한 요소들이 포함되어야 함은 매우

  중요

 해당 데이터 모델을 사용하는 모든사용자(개발자,관리자 등)가 해당 규칙에 대해서 동일한 판단을 할수 있어야한다.

라. 데이터 재사용 (Data Reusability)

 - 통합성

  과거 시스템은 각각의 업무 영역별 데이터 별도 관리

  전사적 관점에서 공통데이터를 도출하고 이를 전 영역에서 사용하기 적절한 형태로 설계하여야 한다.

  이러한 통합 데이터 모델이어야 데이터 재사용성을 향상시킬 수 있다.

 - 독립성

  과거 시스템은 데이터 모델이 별도로 없이 어플리케이션의 부속품 정도로 여겨졌다. 이경우 데이터는 각각의 업무 프로세스에 종속적일수밖에 없고 중복데이터 발생, 일관성 저하, 재사용성이 떨어지게 된다. 따라서 데이터가 어플리케이션에 독립적으로 설계되어야만 데이터 재사용성을 향상시킬 수 있다.

 - 확장성, 유연성

  정보시스템은 비즈니스 변화에 대해 최적의 적응을 요구한다.

  비즈니스 변화에 유연하게 대처하고 확장이 용이한 데이터 설계가 필요하다

  확장성, 유연성이 떨어질 경우 작은 업무 변경에도 시스템 기반이 흔들리게 된다.

 - 합리적 균형이 있으면서도 단순하게 분류하는 것

  예를 들면, 동일한 계약 업무를 수행하기 위한 테이블이 A보험사는 10개, B보험사는 100개라면?

   A사의 데이터 모델은 단순하지만 새로운 업무환경 변화에 대해서 확장성을 가지고 있다.

   B사는 업무환경 변화(신규상품출현 등)에 적응하지 못하고 데이터 모델의 한계로 테이블 갯수를 늘려왔다.

   간결한 모델의 전제조건은 통합.

마. 의사소통 (Communication)

  - 데이터 모델은 대상 업무를 데이터 관점에서 분석하고 설계하여 나오는 최종 산출물이다.

  - 분석과정에서 도출되는 수많은 업무 규칙들은 최대한 자세하게 표현되어야 한다.

  - 모든 관련자들이 데이터 모델을 통해 의사소통을 할 수 있도록 자세하게 기술해야 한다.

바. 통합성(Intergration)

  - 조직 전체에서 한번만 정의되고 이를 여러 다른영역에서 참조, 활용하는것이다.