SQLD 1과목

1과목 제1장.

1. 외개내 - 외부, 개념, 내부적 단계는 '데이터 베이스 구조'이자, '데이터 독립성 요소'
2. 외<->개 를 잇는건 '논리적 독립성', 개<->내를 잇는건 물리적 독립성으로, 상호 독립적인 두 개념을 연결시킴(=매핑)
3. 외개내에서 개념은 db에 저장되는 데이터와 사용자 관계 표현, 모든 사용자 관점 통합, 조직 전체 통합
4. thing = entity type(복수), entity
5. relationship = relationship(복수), pairing
6. attributes = attribute, attribute value
7. ERD = Entity Relationship Diagram
   1. entity는 사각형으로 표현
   2. 관계는 마름모로 표현
   3. 속성은 타원형으로 표현
   4. 순서 : entity 그리기 -> 배치 -> 관계 설정 -> 관계의 참여도 설정 -> 관계의 필수 여부 설정
8. 좋은 데이터모델의 특징 : 완전성 / 중복배제 / 업무규칙 / 의사소통 / 데이터 재사용 / 의사소통 / 통합성
9. entity(=개체=실체)란, 저장이 되기위한 어떤 것으로, 논리적 설계의 주체
   1. instance인스턴스는 entity안의 행 데이터를 의미(ex. 환자 엔티티의 이름들)
      
      1. 한개의 인스턴스는 2개 이상의 속성을 가짐
      2. 1개의 속성은 딱 1개의 속성값을 가짐
   2. 속성
      1. 개체가 관리하는 데이터의 최소 단위(ex. 책의 저자,제목..)
      2. 관계를 표현할 수 X 
      3. 또 다른 속성을 가질 수 X
      4. 파생속성은 다른 속성에 의존적이기에 적게 만드는 것이 좋음
      5. 분류방식 2가지, 1-특성에 따른 분류 : 기본/설계/파생 속성, 2-구성방식에 따른 분류 : 기본(PK)/외래(FK)/일반
      6. 속성이 가질 수 있는 범위를 '도메인'이라 한다.
         1. DTYPE, 크기, 제약 사항(NOT NULL) 지정
         2. 테이블 속성간 FK 제약조건은 지정하지 X
   3. 식별자
      1. 주식별자와 보조식별자는 같은 식별자이더라도 상황에 따라 다름
      2. 내부 식별자와 외부 식별자 중 외부 식별자는 다른 개체와의 연결자 역할을 해줄 수 있음
      3. 복합식별자와 대리 식별자 모두 식별자들을 합친 것 (대리 식별자는 새로운 식별자가 붙었다는 점에서 차이)
      4. 식별자는 보통 인덱스로 구현됨
      5. 인조 식별자 생성 기준 - 범용적인 값(쓰던 값 그대로), 일련번호같은건 대체하지 X, 편의성/단순성/체계성 확보, 내부적(관리)용으로만 사용
      6. ENTITY를 구분하는 논리적인 이름이자, 대표할 수 있는 속성이다.
      7. 한 ENTITY에는 유일한 식별자
      8. 특징(유,최,불,존) : 유일성(인스턴스를 유일하게 구분), 최소성(유일성을 만족하는 속성의 수는 최소), 불변성, 존재성(NULL x)
      9. 식별자와 비식별자
         1. 식별자는 자식이 부모의 기본키를 상속받아 기본키로 사용할 경우(null X)
         2. 비식별자는 부모의 속성을 받았을 때, 자식이 일반적인 속성으로만 사용하는 경우 -> 이 경우, 문제는 부모까지 Join해야해서 성능이 낮아지는 것
         3. 비식별자관계 설정 고려사항 순서
            1. 관계 분석 -> 관계의 강/약 분석 -> 자식테이블 독립pk필요 -> sql 복잡도 증가, 개발 생산성↓
            2. 위 순서에서 1) 관계가 약할 경우, 2) 독립 pk를 구성해야할 경우, 3) pk속성을 단순화해야할 경우, 비식별자 관계 설정을 고려하는 것
   4. 개체 정의서 : 완벽한 내용은 없지만, 아래의 항목들은 반드시 포함되어야 한다.

1. 1. 1. 개체 타입명 / 개체 타입 설명 / 개체 타입 구분
      2. 동의어/유의어
      3. 개체 구분별 속성
      4. 식별자
      5. 기타
   2. 개체의 특징
      1. 업무에서 필수 인가
      2. 식별자에 의해 식별 가능한가
      3. 2개 이상의 인스턴스로 구성되었는가
      4. 업무프로세스에 의해 이용됨
      5. 반드시 '속성' 포함
      6. 다른 ENTITY와의 관계가 최소 1개 있어야함
   3. 개체의 분류
      1. 유형 vs 개념 VS 사건 ENTITY (유 무형)
      2. 기본 vs 중심 vs 행위 ENTITY (발생 시점)
2. db 설계 순서는 요구 조건 분석 -> 개논물(개념,논리,물리) 설계 -> 구현
3. 개체 도출(이끌어 냄)
   1. 업무 기술서, 장표, 인터뷰
   2. 견학을 통해 실제 업무와의 차이 파악
   3. 기존 시스템의 산출물 이용
   4. dfd (data flow diagram)의 자료 저장소(data strore) 추출
   5. 업무를 재설계(brp)한 후 신규 업무에서 도출
4. 속성 후보 선정시, 원시 속성(원본)으로 보이는 후보는 버리지 않는다, 각 속성들을 적당한 데이터 그룹으로 나눠둔다. 
5. 관계
   1. 둘 이상의 개체를 연결 (1:1관계, 1:0 관계, 1:다 관계, 1:0관계는 단독으로 쓰이지는 않는다.)
   2. 다:다는 구현 X (종속성 판단, 정규화, 문서화가 불가능하기 때문)
      1. 대신, 새로운 관계개체로 관계 설정시 놓쳤던 규칙을 설정한다.(EX.1:다 2개로 나눔)
   3. 종속 관계
      1. 식별관계와 비 식별 관계
         1. 식별관계는 종속관계로, 주식별자가 주식별자에 쓰이는 경우
         2. 비식별 관계는 주식별자가 외래 식별자이거나 일반속성인 경우
   4. 중복 관계 : 위의 종속관계가 2번 이상 발생한 경우
   5. 재귀 관계 : 자기 자신을 다시 참조하는 관계 (속성 기준) (EX. 사원코드와 선임 사원코드에 같은 값이 있음)
   6. 배타 관계 : 개체의 특성을 분할하여, 통합한다. (EX. 제품과 상품의 같은 속성을 기준으로 관계 생성 -> 한 그룹으로 통합해서 관리 가능)
      1. 논리 합 : 개체 중복 가능
      2. 논리 곱 : 개체 중복 불가능
   7. 관계 = 관계명 + 차수(Cardinality) + 선택성(Optionality) 으로 구성
   8. 페어링이란 entity 안에 인스턴스가 개별적으로 관계를 갖는 것으로, 관계는 페어링의 집합이다.
   9. 관계 분류
      1. ERD - 존재,행위에 의한 관계로, 단일화된 표기법 사용
      2. UML - 연관(실선),의존(점선)관계로, 표기를 구분함
6. ER 다이어그램
   1. 논리 데이터 모델링 기법 중 가장 대중적
   2. 개체,속성,관계를 그림으로 설명
   3. 실제 변경이 거의 발생하지 않아서, 데이터 중심의 설계가 가능하다.
   4. 하나의 개체 -> 하나의 테이블 (x)
   5. 바커 표기법
      
      1. 개체는 soft box로 구현
      2. 개체명 아래 속성, 속성 왼쪽에는 * 또는 ○를 통해서 필수 여부 표현
      3. 실선은 반드시 존재, 점선은 선택적
      4. 개체 -> 선 -> 마크 순 해석
      5. 식별자는 개체 대표 속성
      6. 서브 타입은 슈퍼(상위)타입 안에 상자 형태로 구현, 공간이 절약되고 상호 배타적이다.(중복X)
         
         
   6. IE 표기법
      1. 개체를 각진 사각형으로 구현, 개체 명은 바깥쪽에 표기
      2. 속성은 * 와 같은 표기 x
      3. 위쪽에 구역을 나누어 식별자를 별도로 표기
         1. 실선과 점선을 한 라인에 동시 표현 가능 (단, 정보 공학 표기법에서는 둘 중 하나만 선택해야함)
      4. 서브타입 표현
         1. 배타적(0 또는 1) 
         2. 포괄적(1또는 M)
         3. 바커처럼 안에 표현하지 않고, 별도의 마크와 선을 이용
7. 두 ENTITY 사이 정의한 관계 체크
   1. 연관 규칙이 존재하는가?
   2. 정보의 조합이 발생하는가?
   3. 업무 기술서, 장표에 관계 연결을 가능케하는 VERB 가 존재하는가?
   4. 업무기술서, 장표에 관계 연결에 대한 '규칙'이 존재하는가?

---

1과목 제 2장. 데이터 모델링과 성능

1. 성능 데이터 모델링 
   1. 사전에 할수록 비용 절감
   2. 분석 설계 단게에서 best
   3. 순서는 정규화 -> db 용량 산정 -> transaction 유형 파악 -> 반정규화 -> pk/fk, 슈퍼/서브타입 등 조정 -> 성능관점에서 데이터 모델 검증
   4. 고려사항
      1. 정규화 (=중복 제거)
      2. 용량 산정 (전체적인 db의 transaction 유형과 양 분석)
      3. 물리적 데이터 모델링 - pk/fk 칼럼 순서 조정, fk 인덱스 생성 수행 -> 성능 ↑
      4. 이력 데이터 : 시간에 따라 반복적으로 발생시, 대량 데이터일 수 있다. 칼럼 추가하도록 설계하기
2. 정규화
   1. 모델을 구조화, 개선시킴
   2. 중복 제거(즉, 동일한 속성을 합체) + 무결성을 지킴
   3. 성능은 1)조회, 2) 삽입, 수정, 삭제의 두 가지 측면 모두 고려
      1. 보통 조회 성능은 반정규화로 좋아지고, 나머지 성능은 정규화로 좋아짐
   4. 함수성 종속성이 있는 일반 속성을 의존자로, 입력/수정/삭제/이상 제거 
      1. ex. 결정자 = 주민번호, 종속자 = 이름, 주소, 출생지
   5. 한 테이블의 데이터 용량 최소화
   6. 정규화는 중복제거를 위해서 쪼개는 것임을 인지하자. (무결성 O)
   7. 중복된게 많아 보이면 1차 정규화 대상, 중복된게 안 보이면 1차 정규화 완료 = 2차 정규화 대상
   8. 1차 정규화
      1. " 한 데이터가 다중 값 혹은 반복 그룹을 가질 경우, 제1정규형 위배
      2. 2차 정규형 위배는
         1. 입력 이상 (EX. 주문이 발생하지 않으면, 음료 입력이 불가)
         2. 수정 이상 (EX. 음료명이 변경될 경우, 해당되는 주믄의 ROW DATA가 필요하다.
         3. 삭제 이상 (EX. 음료 삭제시, 주문까지 삭제된다.)
      3. 3차 정규화도 2차 정규화와 유사함
      4. 4차 정규화 : 다치 종속 제거 - 최소 하나의 다치종속만 존재하도록 개체를 분리
         1. EX. 성향이 '중립'인 학생을 찾으려고 하는데, 3명의 중복된 '길동'이 나타남. 
3. 반정규화
   1. 정규화된 entity, 속성, 관계에 대해 성능 향상, 단순화를 수행하기 위해 중복/통합/분해 수행
   2. 무결성이 깨질 수도 있다.(-)
   3. disk i/o 감소
   4. 긴 조인쿼리문으로 인한 성능 저하 해결
   5. 중복성의 원리를 이용해서, 데이터 조회시 성능 향상 (정규화도 조회의 성능을 향상시키기는 함)
   6. 정규화의 종속관계는 위반하지 않으면서, 데이터의 중복성을 증가시켜 조회 성능을 향상시킴
   7. 반정규화 적용 방법
      1. 대상 조사 - 범위 처리 빈도수 / 대량 범위 처리 /  통계성 process / 테이블 join 수
      2. 다른 방법 유도 가능 여부 먼저 검토 - view table / 클러스터링 / index 조정 / 응용 애플리케이션
      3. table, attribute, 관계를 반정규화
   8. TABLE 반정규화
      1. TABLE 병합 - 1:1 관계, 1:M 관계, 슈퍼/서브 타입
      2. TABLE 분할 - TABLE이 큰 경우 ,처리 범위 줄어듦 (수직 분할 / 수평 분할)
      3. 중복 TABLE 추가 - 동일한 테이블을 추가함으로써 중복 원격 조인 제거
      4. 통계 TABLE 추가 - 통계값을 미리 계산해서 저장하는 TABLE 추가
      5. 이력 TABLE 추가 - 마스터 테이블 레코드(=이력) 중복하여 이력테이블에 존재 (TRANSANCTION 발생 시점에 따라 복사)
      6. 부분 TABLE 추가 - 전체 컬럼 중 자주 이용하는 컬럼만 모아 별도의 테이블 형성 (부분COLUMN 추가는 없다.)
   9. COLUMN 반정규화
      1. 무결성 깨뜨릴 가능성 O
      2. 중복 COLUMN 추가 - 조인을 줄이기 위해서
         1. SELECT 비용은 줄어들지만
         2. UPDATE 비용은 늘어남
      3. 파생 COLUMN 추가 (ex. sum)
      4. 이력 table Column 추가 - 기능성 칼럼 추가 (ex. 시작 및 종료 일자)
      5. 기본 key에 의한 Column 추가 - 복합의 의미를 갖는 pk 단일 구성시 발생 -> 일반 속성으로 pk 추가
      6. 응용 시스템 오작동을 위한 Column 추가 - 이전 데이터를 임시적으로 중복 보관
   10. 관계 반정규화
       1. 무결성을 깨뜨릴 가능성 X
       2. 중복 관계 추가 - 여러 경로를 거친 Join을 방지하기 위해 추가적인 관계를 맺음 (->성능 개선)
   11. 대량 데이터에 따른 성능
       1. 성능 저하원인
          1. 한 테이블에 데이터 대량 집중
          2. 한 테이블에 여러 컬럼 존재
          3. 대량 데이터 처리되는 테이블 존재 
          4. 대량 데이터가 한 테이블에 존재 (인덱스 크기가 너무 큼)
          5. 컬럼이 많아질 경우 - 로우 체이닝, 로우 마이그레이션 발생
             1. 로우 체이닝 : 행 길이가 길어서, 2개이상 블록에 걸쳐 하나의 로우를 저장하는 형태, 한 row를 여러 chain처럼 / 1:1로 테이블을 분리해서 디스크 i/o를 ↓, 조회 성능 향상
             2. 로우 마이닝 : 데이터 블록에서 수정 발생시, 수정된 데이터를 해당 블록에 저장하지 못하고, 다른 블록에 빈 공간을 찾아 저장하는 방식
       2. 해결 방안
          1. 한 테이블에 많은 컬럼 -> 수직 분할 (column 단위 분할)
          2. 대량 데이터 저장 문제 -> 파티셔닝 / pk에 의한 table 분할 / 수평 분할 (row 단위 분할)
             1. 수직/수평 분할 절차
                1. data model 완성
                2. db 용량 산정
                3. 대량 데이터가 처리되는 table에 대해 transaction 처리 패턴 방식
                4. column / row 단위로 집중화된 처리가 발생하는지 분석해 table 분리
   12. 데이터 베이스 구조와 성능
       1. 슈퍼/서브 타입 데이터 모델
          1. 논리적 데이터 model에서 주로 이용
          2. 물리적 데이터 model로 설계시 문제
          3. 슈터 타입 : 공통 부분을 슈퍼타입으로 모델링
          4. 서브 타입 : 공통으로부터 상속받아 다른 entity와 차이가 있는 속성만 modeling
       2. db 성능 저하 원인 3가지
       3. 1. 전체를 일괄 처리, 테이블은 개별로 유지 -> union 연산에의한 성능 저하
          2. 전체를 슈퍼+서브 타입 공통 처리, 테이블은 개별로 유지 -> join에 의한 성능저하
          3. 서브타입만 개별로 처리, 테이블은 하나로 통합 -> 불필요하게 많은 데이터 집적
       4. 슈퍼/서브 타입 변환 기준
          
          1. 소량 데이터 - 1:1 관계 유지
          2. 대량 데이터 - 3가지 방법
             1. 전부 개별 테이블로 구성
             2. 슈퍼 + 서브 타입 테이블로 구성
             3. 하나의 테이블로 구성
       5. 슈퍼/서브 타입 데이터 모델 변환 기술
          1. one to one type (개별 테이블)
          2. plus type (슈퍼 + 서브 타입)
          3. single type (하나의 테이블)
       6. 쪼개질 수록 확장성, i/o 성능 향상 / join 성능, 관리 용이성은 저하
       7. 성능 저하 방지를 위해 알아야할 중요성
          
          1. 인덱스의 중요성 (효과적 접근경로 제공)
          2. pk / fk 설계 중요성 (접근경로 제공, 마지막 단계에 colum 순서 조정)
          3. pk 순서 중요성 (pk 이외에 상속되는 pk 순서도 중요)
          4. fk 순서 중요성 (join할 수 있는 수단이 됨, 조회 조건 고려해서 반드시 index 생성)
       8. 인덱스 범위 좁히기
          1. pk가 여러개일 때, where 절에서 사용하는 조건절 column이 우선순위
          2. equal 조건이 있는 column이 제일 앞으로 
          3. between, in 범위조건이 다음 순위
          4. 나머지 pk 아무렇게나 (id 값 상관 x)
       9. 위처럼 pk순서를 조정하지 않으면 성능이 저하된다.
          1. 조회조건(where)에 따라 인덱스 처리 범위가 달라지기 때문
          2. pk 순서를 인덱스 특징에 맞게 생성하지 않고, 자동으로 생성하면 table에 접근하는 transaction이 인덱스 범위를 넓게 하거나, full scan 유발하기 때문
       10. 물리적 table에 fk 제약이 없을 시
           1. 인덱스 미생성으로 인한 성능 저하
           2. 물리적으로 두 테이블 사이 fk 참조 무결성 관계를 걸어 상속받은 fk에 인덱스 생성
   13. 분산 데이터베이스
       1. 분산 DB는 빠른 네트워크 환경을 이용해 DB를 여러 지역, 여러 노드로 위치시켜 사용성, 성능을 극대화시킴
       2. 분산된 DB를 하나의 가상 시스템으로 사용할 수 있게 함
       3. 논리적으로는 동일한 하나의 시스템이고, 네트워크를 통해 물리적으로 분산된 DATA들의 모임
       4. 논리적으로 사용자 통합 및 공유
   14. 분산 데이터베이스의 투명성 여섯가지
       1. 분할 투명성(=단편화) : 1개의 논리적 관계를 여러 단편으로 분할, 사본을 여러 사이트에 저장
       2. 위치 투명성 : 사용할 DATA의 저장장소 알 필요 x
       3. 중복 투명성 : db 객체가 여러 site에 중복저장 되었는지 알 필요 X
       4. 장애 투명성 : 구성 요소의 장애에 무관하게 transaction 원자성 유지
       5. 병행 투명성 : 많은 트랜잭션을 동시 수행시 결과의 일관성 유지
       6. 지역 사상 투명성 : 지역 db ms와 물리 db 간에 mapping 보장 (각 지역이름과 무관한 이름 써도 됨)
   15. 분산 데이터베이스 적용법
       1. 단순 분산환경에서의 DB 구축이 목적이 아님!
       2. 업무의 특징에 따라 DB 분산 구조를 선택적으로 설계
   16. 분산 데이터베이스 활용 방향성 : 업무의 특징에 따라 위치 중심 / 업무 필요에 의한 분산 설계
       1. 장점 : 지역 자치성, 점증적 시스템 용량 ↑, 신뢰성/가용성/효용성/융통성, 빠른 응답 속도로 통신비용 절감, 시스템 규모의 적절한 조절, "통합된 DB에서 제공할 수 없는 빠른 데이터 처리 성능이 분산 DB의 가치"
       2. 단점 : 개발 비용, 잠재적 오류,처리비용 ↑, 설계/관리가 복잡, 불규칙한 응답속도, 데이터 무결성에 대한 위협
   17. 분산 데이터베이스 적용 기법
       1. TABLE 위치 분산 (물리적)
          1. 구조 변경 x
          2. 다른 db에 중복 테이블 생성되지 x
          3. 정보 이용 형태가 각 위치별 차이가 있을 경우에만 사용 (위치 = 서버 컴퓨터)
          4. TABLE 위치 파악을 위한 도식화된 위치별 DB문서 필요
       2. TABLE 분할 분산 (수평 분할)
          1. 특정 column 값 기준 행 단위 분리 (열, column은 X)
          2. Prime key에 의해 중복이 발생하지 X
          3. 데이터 수정 - 타 지사(X), 자 지사 데이터만 수정
          4. 각 지사 table 통합 처리 : join으로 인한 성능 저하 예상됨 -> 통합 처리 프로세스가 적을 때에만 수평 분할하기
          5. 데이터 무결성 보장 -> 데이터가 지사별로 별도로 존재하여 중복이 존재하지 X
          6. 지사별 DB를 운영하는 경우, 어떤 경우든지간에 DB 데이터들은 수평분할하여 존재함
       3. TABLE 복제 분산 (부분 복제)
          1. 마스터 DB에서 일부만 다른 서버로 복제
          2. 통합된 Table은 본사에 저장, 지사별로 각 지사에 해당하는 로우를 가짐
          3. 지사에 데이터 선 발생 -> 본사는 지사 데이터 통합
          4. 여러 테이블 join 없이 빠른 처리
          5. 각 지사별 처리 O, 전체 본사 통합 처리도 O
          6. 본사 데이터는 통계, 이동 등 수행 / 지사 데이터로는 지사별 빠른 업무 가능
          7. 다른 지역간 데이터 복제는 (실시간X) 배치 처리를 주로 이용
          8. DATA의 정합성 일치 어려움
       4. TABLE 요약 분산
          1. 광역 복제 
             1. 통합된 테이블을 본사에 저장하고, 각 지사에도 동일한 데이터 저장
             2. 본사에서 DATA 입력, 수정, 삭제 -> 이를 지사에서 사용한다는 점이 부분복제와의 차이점
             3. 본사와 지사간 특별한 제약 X
             4. 다른 지역간 데이터 복제는 (실시간 X) 배치처리를 주로 이용
          2. 통합 요약
             1. 각 지사별 존재하는 '다른 내용 정보'를 본사에 통합
             2. 각 지사는 타 지사와 다른 요약정보를 가짐
             3. 본사는 지사의 요약 정보를 통합해 재산출한 요약 정보를 가짐
   18. 분산 DB로 성능이 향상된 사례
       1. 분산 환경의 원리 이해 없이 DB 설계시, 성능저하가 많이 일어남. "복제 분산"원리 응용시, 성능 향상 가능

 

---

문제풀이 오답 - 1과목 제1장

1. 모델링은 현실세계를 일정한 형식에 맞추어 표현하는 추상화의 의미를 가질 수 있음
2. 모델링은 시스템 구현만을 위해 진행하는 사전단계 (X)
3. 모델링은 애매모호함을 배제하고 누구나 이해 가능하도록 정확하게 현상을 기술하는 정확화의 의미를 가짐
4. 모델링시 업무에 대한 설명은 별도의 표기법을 이용 (X)
5. 데이터 모델링 자체로서 업무의 흐름을 설명하고 분석하는 부분에 의미
6. 데이터 모델링 유의점 3가지 (하면 안되는 것)
   1. 중복 -> 여러 장소의 데이터 베이스에 같은 정보 저장 x
   2. 비유연성  -> 데이터의 정의를 데이터 사용 프로세스와 분리하여 유연성 높이기
   3. 비일관성 -> 데이터간의 상호 연관관계를 명확하게 정의
7. " 데이터의 정의를 데이터 사용 프로세스와 분리함으로써 데이터 모델링은 데이터의 작은 변화가 데이터베이스에 중대한 변화를 일으킬 수 있는 가능성을 줄인다." -> 의미하는 데이터 모델링의 유의점 = "비유연성"
8. " 전체 과정의 통합적 표현, 데이터와 그들간의 관계를 표현하는 스미카" -> 설명하는 스키마 구조="개념 스키마"
9. [고객(고객번호, 고객이름)] ------< [주문(고객번호[FK], 제품번호, 주문수량)]
   1. 한명의 고객은 여러 개의 제품 주문 가능, 주문은 할 수도 있고, 안할 수도 있음
   2. 주문에 데이터 입력시, 반드시 고객 데이터가 존재해야함
   3. 고객에 데이터를 입력할 떄에는 주문데이터가 존재하는 고객만을 입력할 수 있다.(X)
10. 일반적으로 ERD 작성 방법은 엔티티 도출 -> 엔티티 배치 -> 관계 설정 -> 관계명 기술 흐름으로 작업을 진행 (-> 관계의 참여도 기술 -> 관계의 필수여부 기술)
11. 관계의 명칭은 관계 표현에 있어서 매우 중요한 부분에 해당
12. 가장 중요한 엔티티를 오른쪽왼쪽상단에 배치하고, 추가 발생되는 엔티티를 왼쪽오른쪽 편과 하단에 배치 (X) 
13. S병원은 여러명의 환자가 존재, 각 환자에 대한 이름,주소 등을 관리해야한다. 엔티티는? = 환자
    1. 오답 : 병원 => 병원은 1개 뿐이다. / 이름,주소 => 속성이라서 엔티티가 될 수 없다.
14. 엔티티는 다른 엔티티와 관계가 있을 수 밖에 없다. 단, 통계성 엔티티나, 코드성 엔티티의 경우 관계 생략 가능
15. 속성이 없는 엔티티는 있을 수 없다. 반드시 속성을 가져야함
16. 객체 지향의 디자인 패턴에는 싱글턴패턴이 있어 하나의 인스턴스를 가지는 클래스가 존재한다. 이와 유사하게 엔티티는 한 개 두 개의 인스턴스를 가지는 것만으로 충분한 의미 부여 가능
17. 다른 엔티티로부터 주식별자를 상속받지 않고 자신의 고유한 주식별자를 가지며, 사원.부서.고객..등이 예가될 수 있는 엔티티는 -> 기본 엔티티(키 엔티티) 그 업무에 원래 존재하는 정보
18. 업무에서 필요로하는 인스턴스에서 관리하고자 하는 의미상 더 이상 분리되지 않는 최소의 데이터 단위는 '속성'이다.
19. 속성은 하나의 인스턴스에서 각각의 속성은 하나 이상의 속성값 하나의 속성 값을 가져야한다.
20. 속성도 집합이다.
21. 하나의 엔티티는 두 개이상의 속성을 갖는다.
22. 예금 분류(일반 예금, 특별 예금)의 원금, 예치기간, 이자율 관리, 또한 이자를 속성으로 관리 - 예를 들어 원금이 1000원이고, 예치기간이 5개월이며 이자율이 5.0%라는 속성을 관리하고 계산된 이자도 관리한다.
    1. 일반 예금은 코드 엔티티를 별도로 구분하고, 값에는 코드값만 포함한다. 
    2. 원금, 예치기간은 기본 속성
    3. 이자와 이자율은 파생속성 (X) 이자는 이자율에서 나온 파생속성이 맞지만, 이자율은 기본 속성
    4. 예금 분류는 설계 속성이다.
23. 조회할 때 빠른 성능을 낼 수 있도록 원래 속성의 값을 계산하여 저장할 수 있도록 만든 속성은 파생 속성
24. 주문이라는 엔티티가 있을 때, 단가라는 속성값의 범위는 100에서 10,000 사이의 실수 값이며 제품값이라는 속성은 길이가 20자리 이내의 문자열로 정의할 수 있다. => 설명하는 데이터 모델링의 개념은 '도메인'
25. 속성 명칭 부여시 직원 엔티티의 이름, 고객 엔티티의 이름과 같이 동일한 속성명을 사용하여 일관성 가지기(X)
26. 데이터 모델링의 관계에서 관계는 '존재에 의한 관계'와 '행위에 의한 관계'로 구분될 수 있으나, ERD에서는 관계를 연결할 때, 존재와 행위를 구분하지 않고 단일화된 표기법 사용
27. UML에는 클래스 다이어그램의 관계 중 '연관관계'와 '의존관계'가 있고, 이것은 실선과 점선의 표기법으로 다르게 표현이 된다.
28. 관계의 표기법은 관계명, 관계 차수, 식별성선택성의 3가지 개념을 사용한다.
29. 엔티티간의 관계에서, 1:1, 1:M과 같이 관계의 기수성을 나타내는 것은 Cardinality(=relationship degree=관계 차수)
30. 주식별자가 지정되면 값이 반드시 들어와야 한다.
31. [ 부서 ( 부서 번호 / 부서 명, 위치 ) --< [ 사원 ( 사번 / 부서 번호[FK] / 주민등록 번호) ]
    1. 사원 엔티티에서 식별자에 해당하는 특성은 - 주식별자, 단일식별자, 내부식별자 (인조 식별자X)
32. [ 사원 ( 이름 : VARCHAR(20) / 사원번호 : NUMBER(10) ] 은 부적절한 식별자, '이름'은 동명이인이 많기에 식별자로 적절하지 않다.
33. 명칭, 내역등과 같이 이름으로 기술되는 것은 주식별자로 지정해서는 안된다.
34. 비식별자 관계를 선택하는 기준
    1. 상호간에 연관성이 약할 경우, 비식별자 관계를 고려한다.
    2. 자식 테이블에서 독립적인 Primary Key의 구조를 가지기 원할 때, 비식별자 관계를 고려한다.
    3. 여러개의 엔티티를 하나로 통합하면서 각각의 엔티티가 갖고 있던 여러개의 개별 관계가 통합되는 경우
    4. 모든 관계가 식별자관계로 연결되면 sql where절에서 비교하는 항목이 증가되어, 복잡성이 증가되는 것을 방지하기위해 비식별자 관계를 고려한다. (단, 단순 sql문장의 복잡도를 낮추는 목적으로는 X)
    5. 부모 엔티티의 주식별자를 자식 엔티티에서 받아 손자 엔티티까지 흘려보내기 위해 비식별자 관계를 고려(X)
35. 식별자관계는 상속받은 주식별자 속성을 타 엔티티에 이전해야하고, 비식별자관계는 상속받은 주식별자 속성을 타 엔티티에 차단해야하며, 부모쪽의 관계 엔티티가 선택관계이다.
36. 엔티티별로 생명 주기를 다르게 관리할 경우, 예를 들어 부모 엔티티의 인스턴스가 자식 엔티티와 관계를 가졌으나, 자식만 두고 소멸될 수 있는 경우, 비식별자관계로 연결하는 것이 적합함, 부모 엔티티의 인스턴스가 자식 엔티티와 같이 이 소멸되는 경우는 비식별자 관계로 연결이 적합한경우가 X
37. 보조식별자는 대표성을 가지지 못해, 엔티티내에서 각 오커런스를 구분할 수 있는 구분자이나, 참조관계 연결은 X
38. 인조 식별자는 업무족으로 만들어지지 않지만(본질 식별자는 업무적으로 만들어짐) 원조 식별자가 복잡한 구성을 가지고 있기 때문에, 인위적으로 만든 식별자이다.

 

---

문제풀이 오답 - 1과목 제 2장

1. 성능 데이터 모델링이란 설치 단계의 데이터 모델링때부터 성능과 관련된 사항이 데이터 모델링에 반영될 수 있도록 하는 것
2. 성능저하된 결과를 대상으로 데이터 모델보다는 문제발생 시점의 SQL을 중심으로 집중하여 튜닝 (X, 모델링과 무관)
3. 데이터 모델은 성능을 튜닝하면서 변경이 될 수 있다는 특징이 있다.
4. 데이터의 증가가 빠를수록 성능 저하에 따른 성능개선 비용은 증가한다.
5. 분석/설계 단계에서 성능을 고려한 데이터모델링을 수행할 경우, 성능 저하에 따른 Rework 비용을 최소화할 수 있는 기회를 가지게 된다.
6. 정규화 수행 -> 용량 산정 -> 트랜잭션 유형 파악 -> 용량,트랜잭션 유형에 따라 "반정규화" 수행 -> 이력 모델 조정, PK/FK 조정, 슈퍼타입,서브타입 조정 -> 성능관점에서 데이터 모델 검증
7. 데이터 모델링의 정규화는 항상 조회 성능저하를 나타낸다.(X)
8. 이력 데이터는 시간에 따라 반복적으로 발생되어 대량 데이터일 가능성이 높아, 특별히 성능을 고려하여 칼럼 추가
9. 아래와 같은 보관금원장 엔티티에서 관서에 대한 정보가 반정규화 되어 있기 때문에, 관서정보를 조회할 때 성능저하가 발생하고 있다. ==> 아래 : [ 관서 번호, 납부자 번호 / 관리점 번호, 관서명, 상태, 관서 등록일자, 직급명, 통신번호 ]  / 함수 종속성(FD) : [관서 번호, 납부자번호] -> [직급명, 통신번호] / [관서 번호] -> [관리점 번호, 관서명, 상태, 관서등록일자]
   1. .정규화 테이블(관서 번호, 관리점 번호, 관서명, 관서 등록일자)로 스키마가 분리된 상태이다.
   2. 1차 정규화가 완료되어, 2차 정규화가 필요하다.
10. 다음 중 '일자별 매각 물건' 엔티티에 대한 설명으로 가장 적절한 것은? ==> "일자별 매각물건" [매각 물건번호[FK], 매각일자 / 매각시간, 매각장소, 최저매각가격, 물건상태코드] & "매각일자 매각내역" [매각 일자 / 총 매각금액, 총 유찰 금액, 총 매각물건수, 총 유찰물건 수] 
    
    1. 매각 시간과 장소는 매각일자에만 종속된 것인데, 두 가지 주식별자에 속해있다. 따라서, 2차 정규화 대상이다.
    2. 2차 정규화로 "매각 일자"를 주식별자로 하고, 매각 시간과 매각 장소 속성을 포함하는 매각 기일 엔티티(매각시간+매각장소)로 독립시킨다.
    3. 2차 정규화가 필요한 엔티티로서 매각기일과 일자별 매각 물건으로 1:1 관계가 될 수 있다.
    4. 2차 정규화를 하면, 특정 장소에서 이루어진 매각내역을 조회하고자 할 때, 100만건의 일자별 매각 내역 데이터를 모두 읽어 ...~ 할 필요 없이, 매우 적은 수의 매각 기일 엔티티에서 특정 장소에 해당하는 매각일자들을 찾아 매각일자별 매각내역과 1:1로 바로 조인하면 되기 대문에 I/O를 현저하게 감소시킬 수 있어 성능 향상 효과
11. 동일한 유형의 속성이 칼럼단위로 반복되는 경우, 다음과 같은 전제조건이 있을 때 나타날 수 있는 현상은? => 전제 조건 : 유형기능 분류코드에 해당하는 속성들은 분포도가 양호하며, sql where절에서 각각의 값이 상수값으로 조건 입력될 수 있는 특징을 가진다. 
    1. 반복적인 속성값(ex. a유형기능분류코드1,b유형분류코드2,c유형....)은 속성의 '원자성'을 위배, 1차 정규화 대상이다.
    2. 유형 기능 분류코드 각각에 대하여 개별로 index를 모두 생성할 경우, 입력/수정/삭제 때 성능이 저하되므로 제1차 정규화를 수행한 후 인덱스를 적용하는 것이 좋다.
12. 컬럼 단위에서 중복되는 경우(EX. 장기재고1개월수량, 장기재고2개월수량...), 1:M관계인 두 개의 엔티티로 분리해야한다. -> 1차 정규화가 필요한 엔티티로서 일재고와 일재고상세로 1:M관계가 될 수 있다.(O)
13. "수강지도"엔티티 [학번, 과목코드 / 성적, 지도교수명, 학과명] & 함수 종속성 - 1. 학번||과목 번호 -> 성적 2. 학번 -> 지도교수명, 3. 학번->학과명
    1. 위와 같이 수강지도 엔티티를 만들 경우, 주식별자 PK에 대해 반복되는 그룹이 존재하지 않기 때문에 1차 정규형에 해당한다.
    2. 부분함수 종속의 규칙을 갖고 있어, 2차 정규형은 위반한 상태, 2차 정규화 대상이다.
14. 반정규화 정보에 대한 재현의 적시성으로 반정규화를 판단한다. 예를 들어, 빌링의 잔액은 다수테이블에 대한 다량의 조인이 불가피하므로, 데이터 제공의 적시성 확보를 위한 필수 반정규화 대상이다.
15. 반정규화 고려시, 탐색 대상 데이터의 크기로 판단한다.(X)
16. 파티션, 데이터 클러스터링 등 다양한 물리적 기법으로 다량의 데이터에 대한 인덱스를 활용한 탐색으로 인한 random처리의 특성으로 생긴 성능 저하를 개선시킬 수 있다. 
17. RDBMS는 현재 레코드 기준으로 이전 또는 이후의 레코드에 대한 접근이 원천적으로 불가능하지만, Window function으로 가능하기에, 반정규화를 하지 않아도 해당 데이터접근이 가능하다.
18. 반정규화 테이블은 집계 테이블 이외에도 다수 테이블 키 연결 테이블 등 다양한 곳에 적용
19. FK에 대한 속성을 추가하여 조인 성능을 높인다 -> 반정규화 기법이 아니라, 그냥 관계 연결시 나타나는 현상이다.
20. 칼럼에 대한 반정규화 기법
    1. 중복 칼럼을 추가(조인이 감소됨)
    2. 파생칼럼 추가(조회 성능 향상)
    3. 이력테이블에 기능 칼럼 추가(최신 값을 처리하는 이력의 특성 고려)
21. 반정규화 대상 조사 - 범위 처리 빈도수 조사, 대량의 범위 처리 조사, 통계성 프로세스 조사, 테이블 조인 개수
22. 아래의 주문, 주문목록, 제품에 대한 데이터모델과 이를 조회하는 SQL문에서 조회를 빠르게 수행하기위한 반정규화 방법은? [ 주문 (주문번호) ] ---< [ 주문목록 (주문번호 FK), 제품번호(FK) ] >--- [ 제품 (제품번호, 단가) ]  
    1. 주문 엔티티에 단가를 합한 계산된 칼럼을 추가하도록 한다. 
    2. 제품 엔티티에 단가를 합한 계산된 칼럼을 추가하도록 한다. => 이렇게 할시, 해당 제품에 여러 주문이 포함될 수 있어 특정 주문번호만의 단가합계 금액을 갖고있을 수 없다. 
    3. 주문목록 엔티티에 단가를 합한 계산된 칼럼을 추가하도록 한다. => 위처럼 할시 하나의 주문에 포함된 제품 번호마다 동일한 합계 금액을 반복적으로 저장하게 되어, 일관성 문제가 발생하기 때문이다.
    4. 제품 엔티티에 최근값 여부에 대한 칼럼을 추가한다. => 빠른 조회를 위한 반정규화 수행과 무관함
23. 공급자별로 최근에 변경된 전화번호, 메일주소, 위치와 공급자 이름을 같이 조회할 때, 이 값들을 공급자 테이블에 반정규화로 갖고있는 경우에 비해서 조회 성능이 저하된다. (반정규화가 조회성능을 높여주기 때문에, 안하면 할 때보다 당연히 성능이 저하될 것)
24. 가장 빈번하게 조회되는 값인 최근 변경값에 해당하는 전화번호, 메일주소, 위치를 반정규화하여 조회성능을 향상시킬 수 있다.
25. 번호,메일,위치에 대한 가장 최근에 변경된 값을 알기위해서 최신여부라는 속성을 추가한다면 최근 값을 찾기위한 조회 성능 저하를 예방할 수 있다.
26. 조회성능을 위해서는 하나의 테이블로 통합하여 번호,메일,위치 등이 변경될 경우 전체 속성이 계속 발생되는 이력의 형태로 설계될 수 있다. => 이럴경우 조회에 대한 성능은 향상되나, 과도한 데이터가 한 테이블에 발생하게 되어 용량이 너무 커지는 단점이 있다.
27. 하나 테이블에 많은 컬럼을 가지고 있으면 조인이 발생되지 않아 여러 개 테이블일 때에 비해 성능이 항상 우수하다고 할 수 있다.(X)
28. 로우 체이닝이 발생할정도로 한 테이블에 많은 칼럼이 존재할 경우, 조회 성능저하가 발생할 수 있다. 한 테이블 내에서 칼럼의 위치를 조정하면 디스크 i/o가 줄어들어 조회 성능을 향상시킬 수 있다.(X) => 데이터가 주로 채워지는 칼럼을 앞쪽에 위치, 채워지지 않고 NULL 상태로 존재하는 칼럼들은 뒤쪽에 모아둠으로써 로우의 길이를 어느정도 감소시킬 수 있으나, NULL 칼럼에 후에 더 많은 데이터가 채워질 경우, 더 많은 로우체인이 발생할 가능성이 있다.
29. 로우체이닝이 발생할 정도로 한 테이블에 많은 칼럼들이 존재할 경우, 조회 성능저하가 발생할 수 있다. 트랜잭션이 접근하는 칼럼유형을 분석하여 1:1로 테이블을 분리하면(사용빈도에 따라 분리), 디스크 I/O가 줄어들어 조회 성능을 향상시킬 수 있다.
30. 대량의 데이터 처리하는 방법 1) 인덱스 조정하기 2) 클러스터링 3) 파티셔닝(부분적인 테이블로 분리)
31. 슈퍼/서브 타입 데이터 모델의 변환 기술 
    1. 개별로 발생되는 트랜잭션에 대해서는 개별 테이블로 구성
    2. 슈퍼 타입 + 서브 타입에 대해 발생되는 트랜잭션에 대해서는 슈퍼타입+서브타입 테이블로 구성
    3. 전체를 하나로 묶어 트랜잭션이 발생할 때는 하나의 테이블로 구성
32. 전제조건이 '세 테이블은 함께 조회하는 경우가 대부분이고, 아직 시스템을 오픈하지 않았다'라는 것은
    1. 전체를 하나로 묶어 조회하는 트랜잭션이 대부분이라는 것이고(3번에 해당, 하나의 테이블로 구성)
    2. 따라서 나뉘어진 세 테이블을 하나의 테이블로 구성해야한다. (나뉘어져있을 경우, UNION / UNION ALL 에서 성능 저하 발생)
    3. 하나의 테이블로 통합하되, 1) PK체계나 2) 일반 속성에 각 사건을 구분할 수 있도록 구분자 부여하기
33. "현금 출금기 실적" [ 거래일자, 사무소코드, 출금기 번호, 명세표 번호 / 건수, 금액 ] 
    
    1. 여기서 데이터 조회시 SELECT 건수,금액 FROM 현금출급기실적 WHERE 거래일자 BETWEEN '20140701' AND '20140702' AND 사무소코드 = '000368' 으로 입력했다면,
    2. 사무소 코드가 '='으로 상수값이 들어왔고, 거래 일자가 범위 'BETWEEN'으로 들어왔기 때문에, PK의 순서를 사무소코드+거래일자+출급기번호+명세표번호 로 바꾸고, 인덱스를 생성하는 것이 성능에 유리하다.
    3. 상수 값으로 EQUAL 조건으로 조회되는 칼럼이 맨 앞에 오기 때문 
    4. 범위 조회하는 유형의 칼럼이 그 뒤에.
34. 분산 데이터베이스 장단점
    1. 장점 : 지역 자치성, 점증적 시스템 용량 확장, 신뢰성과 가용성, 효용성과 융통성, 각 지역 사용자의 요구 수용 증대, 시스템 규모의 적절한 조절 ...
    2. 단점 : 소프트웨어 개발 비용, 오류의 잠재성 증대, 처리 비용의 증대..
35. "학사 기준" [ 학사기준번호 / 년도, 학기, 특이사항 ] --<"수강 신청" [강의 번호, 학번 / 학사기준번호FK, 성명, 연락처1, 연락처2, 등록년도, 감면코드] (**두 테이블은 조인하여 정보를 조회할 업무가 많음)
    1. 학사 기준번호는 부모테이블에 모두 인덱스가 존재하나 ,수강신청과 조인에 의한 성능 저하 예방을 위해 상속받아 생긴 수강신청에도 학사기준번호 칼럼에 대한 별도의 인덱스가 필요하다.
    2. 데이터 모델에서는 관계를 연결하고 데이터베이스에 FK제약조건 생성을 생략하는 경우에도 데이터의 조인관계가 필요하므로, 학사기준번호에 대한 인덱스를 생성할 필요가 있다.
       1. 관계에 따라 관련 인스턴스 간에 일관성을 보장하기 위해 설계된 제약조건 구현을 위한 지원 가능
36. 분산설계가 필요한 경우
    1. 공통 코드, 기준정보 등 마스터 데이터는 분산 데이터베이스에 복제 분산 적용
    2. 실시간 업무적인 특성을 갖고있을 때 분산 데이터베이스를 사용하여 구성할 수 있다.
    3. 백업 사이트를 구성할 때 간단하게 분산 기능을 적용하여 구성할 수 있다.
    4. global single instance(gsi) *통합된 db구조 를 구성할 때 분산 데이터베이스를 활용하는 것이 좋다.(X)

---

day 06 2과목 정리 시작, 문풀 시작
day 07, day 08 2과목 정리