대여 횟수가 많은 자동차들의 월별 대여 횟수 구하기 Level. 3

🖍️ 풀이

1. where절 서브쿼리에서 8~10월 사이의 대여 횟수가 5회 이상인 자동차 ID를 추출
2. 그 아이디들 중 8~10월 기간의 월별 대여 횟수를 출력

😭 실수

틀린 코드에서 WHERE절 서브쿼리에서 '810월 사이의 대여횟수가 5 이상인 CAR_ID'를 추출하더라도 메인 쿼리에서 810월 날짜 조건을 안 걸어줘서 틀림

EX) ID가 1인 자동차의 8~10월 총 대여횟수가 6이고 7월 대여횟수가 5일 때, 메인 쿼리에서 날짜 조건을 걸어주지 않으면 7월 대여횟수도 출력될 수 있음

❌ 틀린 코드

SELECT TO_NUMBER(TO_CHAR(START_DATE, 'FMMM')) AS MONTH, CAR_ID, COUNT(TO_CHAR(START_DATE, 'FMMM')) AS RECORDS
FROM CAR_RENTAL_COMPANY_RENTAL_HISTORY
WHERE CAR_ID IN (SELECT CAR_ID FROM CAR_RENTAL_COMPANY_RENTAL_HISTORY
           WHERE TO_CHAR(START_DATE, 'MM') IN ('08', '09', '10')
           GROUP BY CAR_ID
           HAVING COUNT(CAR_ID) >= 5) -- 총 대여횟수가 5회이상인 자동차 중
GROUP BY TO_NUMBER(TO_CHAR(START_DATE, 'FMMM')), CAR_ID
HAVING COUNT(TO_CHAR(START_DATE, 'FMMM')) > 0
ORDER BY 1, 2 DESC

💻 정답 코드

SELECT TO_NUMBER(TO_CHAR(START_DATE, 'FMMM')) AS MONTH, CAR_ID, COUNT(TO_CHAR(START_DATE, 'FMMM')) AS RECORDS
FROM CAR_RENTAL_COMPANY_RENTAL_HISTORY
WHERE CAR_ID IN (SELECT CAR_ID FROM CAR_RENTAL_COMPANY_RENTAL_HISTORY
           WHERE TO_CHAR(START_DATE, 'MM') IN ('08', '09', '10')
           GROUP BY CAR_ID
           HAVING COUNT(CAR_ID) >= 5) -- 8~10월 사이 총 대여횟수가 5회이상인 자동차 중
AND TO_CHAR(START_DATE, 'MM') IN ('08', '09', '10') -- 8~10월 사이 기록만 출력
GROUP BY TO_NUMBER(TO_CHAR(START_DATE, 'FMMM')), CAR_ID
HAVING COUNT(TO_CHAR(START_DATE, 'FMMM')) > 0
ORDER BY 1, 2 DESC

• 서브쿼리는 단일행 또는 복수행 비교연산자와 함께 사용할 수 있음
• 서브쿼리는 SELECT, FROM, HAVING, ORDER BY, INSERT-VALUES, UPDATE-SET 절 등에서 사용 가능
• 서브쿼리에서는 ORDER BY 사용 불가능

단일행 서브쿼리

• 서브쿼리가 단일행 비교연산자와 함께 사용할 때는 서브쿼리의 결과 건수가 반드시 1건 이하여야함
  • 두 건 이상인 경우 오류 발생
  • 그룹 함수를 사용하는 경우 결과값이 1건이기 때문에 단일행 서브쿼리로써 사용 가능

다중행 서브쿼리

• 서브쿼리의 결과가 두 건 이상 반환될 수 있다면 반드시 다중행 비교연산자와 함께 사용해야함
  • IN: 서브쿼리의 임의의 값과 동일한 조건
  • ALL: 서브쿼리의 모든 값을 만족하는 조건
  • ANY: 서브쿼리의 어느 하나의 값이라도 만족하는 조건
  • EXISTS: 서브쿼리의 결과를 만족하는 값이 존재하는지 여부를 확인

다중 컬럼 서브쿼리

: 서브쿼리의 결과로 여러 개의 컬럼이 반환되어 메인쿼리의 조건과 동시에 비교되는 것

• 서브쿼리와 메인쿼리에서 비교하고자 하는 칼럼 개수와 위치가 동일해야함
• 오라클에서 지원
• SQL Server에서는 현재 지원하지 않음

연관 서브쿼리

: 서브쿼리 내에서 메인쿼리의 컬럼을 사용하는 서브쿼리

• 일반적으로 메인쿼리가 먼저 실행되어, 읽혀진 데이터를 서브쿼리에서 조건이 맞는지 확인할 때 사용

비연관 서브쿼리

: 서브쿼리가 메인쿼리의 컬럼을 가지고 있지 않은 서브쿼리

• 메인쿼리에 값을 제공하기 위한 목적

스칼라 서브쿼리

• SELECT 절에서 사용함
• 한 행, 한 컬럼만을 반환하는 서브쿼리

인라인뷰

• FROM 절에서 사용하는 서브쿼리
• 서브쿼리가 FROM 절에 사용되면 동적으로 생성된 테이블인 것 처럼 사용 가능
• SQL문이 실행될 때만 임시적으로 생성되는 동적인 뷰이기 때문에 데이터베이스에 저장되지 않음

: join 조건에서 동일한 값이 있는 행만 반환

• Cross, outer join과 같이 사용할 수 없음
• EQUI, NON EQUI JOIN은 모두 조건이 참인 행들만 반환하는 INNER 조인

EQUI JOIN

: 테이블 간에 두 컬럼 값이 정확하게 일치하는 경우에 사용되는 방법

• 대부분 PK-FK 관계 기반(아닌 경우 O)
• INNER JOIN에 참여하는 테이블이 N개 일때 필요한 조인 조건은 N-1개 이상
• 계층형, 망형 데이터베이스와 비교해서 관계형 데이터베이스의 큰 장점
• '=' 연산자를 사용해 표현

NON EQUI JOIN

: 테이블 간에 논리적인 연관관계를 가지고 있는 경우, 컬럼값이 서로 일치하지 않는 경우

• '='이 아니라 BETWEEN, >, <= 등을 사용해서 조인

NATURAL JOIN

: 두 테이블 간의 JOIN 조건에서 동일한 이름을 갖는 모든 칼럼에 대해 EQUI JOIN을 수행

• *on 절을 쓰지 않아도 *동일한 [칼럼값, 칼럼명, 도메인]에 대해 equi join을 수행
• 동일한 칼럼명이 없다면 결과가 추출되지 않음
• 칼럼명이 같으면 하나의 칼럼으로 처리해서 표시
• inner join을 사용하면 두 테이블의 칼럼이 모두 표시됨

USING

: NATURAL JOIN에서는 컬럼명이 같은 모든 컬럼에 대해 JOIN이 이루어지지만 USING 조건절을 사용하면 컬럼명이 같은 것들 중에서 원하는 컬럼에 대해서만 선택적으로 EQUI JOIN을 할 수 있음

• 조인 컬럼에는 ALIAS나 테이블명 같은 접두사를 붙일 수 없음

ON

• 컬럼들에 대해 ALIAS나 접두사를 명확하게 지정해야함
• ON 조인 서술부, WHERE 비조인 서술부를 분리해서 이해하기 쉬움
• 컬럼명이 다르더라도 조인 조건을 사용할 수 있음

CROSS JOIN

동일한 값이 없을 때 테이블간 생길 수 있는 모든 데이터의 조합 양쪽 집합의 N*M건의 데이터 조합이 발생

OUTER JOIN

SELECT *
FROM TABLE1 A, TABLE2 B
WHERE A.ID = B.ID(+)
=
SELECT *
FROM TABLE1 A LEFT OUTER JOIN TABLE2 B
ON (A.ID = B.ID)

LEFT OUTER JOIN

: 왼쪽에 쓰인 테이블 기준 오른쪽 데이터가 NULL이더라도 왼쪽에 있는 데이터는 모두 출력

RIGHT OUTER JOIN

: 오른쪽에 쓰인 테이블 기준

FULL OUTER JOIN

좌우 테이블의 모든 데이터를 읽어 조인

• LEFT, RIGHT 조인 결과를 합집합으로 처리한 결과와 동일(조인한 행들은 한번만 표시)

🔗 참고

join의 종류 및 차이점을 제대로 알자..! 조인

• 부모, 자식 간의 수직 관계를 트리 구조로 보여주는 쿼리
• 루트 노드의 LEVEL 값은 1임

START WITH

: 계층 구조 전개의 시작 위치를 지정 시작 행은 여기서 지정됨

CONNECT BY

: 부모, 자식 관계 지정

🖍️ CONNECT BY에 조건절을 사용하는 경우

START WITH절에서 필터링된 데이터는 결과목록에 포함되지만 이후 데이터들은 재귀적으로 모든 하위노드가 제거됨 ➡︎ where에 조건절을 사용하면 해당 조건을 만족하지 않는 데이터만 제거되지만 connect by에 사용하면 해당 노드의 하위 노드까지 제거

PRIOR

: PRIOR이 붙은 컬럼이 안붙은 컬럼을 찾아감

• CONNECT BY PRIOR 자식 컬럼 = 부모 컬럼: 순방향
• CONNECT BY PRIOR 부모 컬럼 = 자식 컬럼: 역방향

ORDER SIBLINGS

: 형제노드(동일 level) 사이에서 정렬 수행

📝 예제

문제. 정렬 순서상 3번째에 표시될 값은?

TAB1

풀이.

1. C2가 NULL인 행 부터 시작
2. [이전에 읽은 행의 C1값]이 [C2]인 행 읽기 ➡︎ 첫번째 행의 C1값인 1이 C2인 행 읽기 ➡︎ C2가 1인 행. 두번째, 세번째 행 읽기
3. 반복

C2가 NULL인 행: A C2가 1인 행: B, C C2가 2인 행: D

ORDER SIBLINGS BY로 정렬 후: A C B D

정답.

B

🔗 참고

[오라클, Oracle] 계층 쿼리 (hierarchical query) - 고급 주제 [Oracle]계층형 쿼리 사용법(START WITH, CONNECT BY PRIOR, ORDER SIBLINGS BY) SQL 자격검정 실전문제, 한국데이터산업진흥원

ROLLUP: 첫번째 인자에 대해 소그룹+전체 합계(순서상관) CUBE: 결합 가능한 모든 값에 대해 집계(순서 상관 x) GROUPING SETS: 입력된 인자에 대해 소계(순서 상관 x)

GROUPING

소계, 합계로 집계된 컬럼 값이 NULL이면 1, 아니면 0 반환

• CASE WHEN 같은 구문에서 사용

  SELECT 
    CASE GROUPING(상품ID) WHEN 1 THEN '모든 상품ID' ELSE 상품ID END AS 상품ID,
    CASE GROUPING(월) WHEN 1 THEN '모든 월' ELSE 월 END AS 월, 
    SUM(매출액) AS 매출액
  FROM 월별매출
  GROUP BY ROLLUP(상품ID, 월);

• 출력 시 NULL 대신 출력될 문자, 숫자들 지정할 때

ROLLUP

소그룹 간의 소계를 계산

• 인자가 여러개 전달되어도 첫번째 값에 대해서만 합계 계산
• 마지막 최종 소계도 계산
• 인자 순서에 따라 결과가 다름

  GROUP BY CUBE(컬럼1, 컬럼2)
  =
  GROUP BY 컬럼1, 컬럼2
  UNION ALL
  GROUP BY 컬럼1
  UNION ALL
  모든 집합 그룹 결과

CUBE

결합 가능한 모든 값에 대하여 다차원 집계 생성

• 정렬이 필요한 경우 ORDER BY 절에 명시적으로 정렬 칼럼을 표시해야함
• 인수의 순서가 바뀌면 정렬은 다를 수 있지만 결과는 같음 (모든 경우의 소계를 출력하기 때문)
• 2ᴺ개의 소계 생성(그룹핑 컬럼이 N개 일때)

  GROUP BY CUBE(컬럼1, 컬럼2)
  =
  GROUP BY 컬럼1, 컬럼2
  UNION ALL
  GROUP BY 컬럼1
  UNION ALL
  GROUP BY 컬럼2
  UNION ALL
  모든 집합 그룹 결과

GROUPING SETS

다양한 소계 집합을 만듦 표시된 인수들에 대한 개별 집계를 구함(소계가 필요한 것들만 넣음)

• 계층 구조가 아니라 평등한 관계 이므로 인수의 순서가 바뀌어도 결과는 같음 결과에 대한 정렬이 필요한 경우에는 ORDER BY 절에 명시적으로 정렬 칼럼이 표시되어야 함
• 전체 합계는 안보여줌. 소계만.

🔗 참고

SQL 집계함수 - ROLLUP, CUBE, GROUPING SETS

🖍️ NULL 아직 정의되지 않은 값 0(숫자) 이나 공백(문자)과는 다름

• NOT NULL 이나 PRIMARY KEY로 정의되지 않은 모든 데이터 유형은 NULL을 가질 수 있음
• NULL 값을 포함하는 연산의 경우 결과도 NULL
• 집계 함수의 통계 정보는 NULL 값을 가진 행을 제외하고 수행

  ✔️ 비교

  Count(): *NULL 값을 포함**한 행의 수 출력 Count(표현식): 표현식의 값이 NULL인 값을 제외한 행의 수 출력

  오라클

• NULL을 가장 큰 값으로 간주 ➡︎ 오름차순 정렬하면 마지막 순서
• ''(공백), NULL 모두 NULL로 취급

SQL Server

• NULL을 가장 작은 값으로 간주 ➡︎ 오름차순 정렬하면 제일 먼저 나옴
• ''(공백), NULL을 다르게 처리

NULL 관련 함수

1️⃣ NVL(a, b) - 오라클 / ISNULL(a, b) - SQL Server

a가 NULL 이면 b값 반환 a가 NULL이 아니면 a 자기 자신 반환

2️⃣ NULLIF(a, b)

a와 b가 같으면 NULL 반환 a와 b가 다르면 a값 반환

3️⃣ COALESCE(a, b, …)

a, b, … 중에서 NULL이 아닌 최초의 표현식 반환 모든 표현식이 NULL이라면 NULL 반환

✏️ 엔터티

엔터티의 특징

• 반드시 해당 업무에서 필요하고 관리하고자 하는 정보여야함

• 유일한 식별자에 의해 식별이 가능해야함
• 영속적으로 존재하는 인스턴스의 집합(⭐️두 개 이상!!)
• 업무 프로세스에 의해 이용되어야함
• 반드시 속성이 있어야함
• 다른 엔터티와 최소 한 개 이상의 관계가 있어야함

발생 시점에 따른 엔터티 분류

기본, 키 엔터티(Fundamental, Key Entity)

• 그 업무에 원래 존재하는 정보
• 다른 엔터티와 관계에 의해 생성되지 않고 독립적으로 생성할 수 있고 자신은 타 엔터티의 부모 역할을 함
• 주식별자를 상속받지 않고 자신의 고유한 주식별자를 가짐

  중심 엔터티(Main Entity)

• 기본 엔터티로부터 발생하고 그 업무에 있어서 중심적인 역할
• 데이터의 양이 많고 다른 엔터티와의 관계를 통해 많은 행위 엔터티를 생성

  행위 엔터티(Active Entity)

• 두 개 이상의 부모엔터티로부터 발생
• 자주 내용이 바뀌거나 데이터양이 증가
• 분석 초기 단계에서는 잘 나타나지 않음

✏️ 속성

속성의 특성에 따른 분류

• 기본속성(Basic Attribute): 사원이름, 고용일자 등 일반적인 속성

• 설계속성: 업무상 필요한 데이터 외에 데이터 모델링을 위해 업무를 규칙화하기 위해 속성을 새로 만들거나 변형하여 정의하는 속성, 부서 번호, 부서 이름 등
• 파생속성: 다른 속성에 영향을 받아 발생하는 속성(계산된 값), 가급적 적게 정의하는 것이 좋음

명칭 부여

• 해당 업무에서 사용하는 이름 부여

• 서술식 속성명은 사용하지 않음
• 약어 사용 제한
• 전체 데이터 모델에서 유일성을 확보하는 것이 좋음

도메인

각 속성이 가질 수 있는 값의 범위 엔터티 내에서 속성에 대한 데이터 타입과 크기, 제약사항을 지정하는 것

✏️ 관계

관계의 표현

ERD

• 존재와 행위 구분 X
• 단일화된 표기법 사용

  UML - 클래스 다이어그램

• 연관관계: 실선
• 의존관계: 점선

관계의 표기법

• 관계명(Membership): 관계의 이름

• 관계차수(Cardinality): 1:1, 1:M, N:M
• 관계선택사양(Optionality): 필수/선택 관계

관계 체크

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

• 두 엔터티 사이에 정보의 조합이 발생되는가?
• 업무기술서, 장표에 관계연결을 가능하게 하는 동사가 있는가?
• 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?

✏️ 식별자

식별자 분류

대표성 여부

• 주식별자(Primary) 부서번호, 사번, 주문번호 등
• 보조식별자(Alternate): 인스턴스를 구분할 수 있지만 대표성을 가지지 못해 참조 관계를 연결하지 못함 주민등록번호(사원 엔티티에서는 주민번호보다 사번이 주식별자로 적합함)

  스스로 생성 여부

• 내부식별자: 엔터티 내부에서 스스로 만들어짐
• 외부식별자(Foreign): 타 엔터티와의 관계를 통해 타 엔터티로부터 받아오는 식별자 사원엔터티의 부서번호(사원 엔터티와 부서 엔터티는 부서번호로 관계되어 있음)

  속성의 수

• 단일식별자: 하나의 속성으로 구성된 식별자
• 복합식별자: 둘 이상의 속성으로 구성된 식별자 사번과 수강일자 두 속성을 이용해 식별자 역할

  대체 여부

• 본질식별자: 업무에 의해 만들어지는 식별자 부서번호, 사번 등
• 인조식별자: 업무적으로 만들어지지는 않았지만 원조식별자가 복잡한 구성을 가지고 있어 인위적으로 만들어짐 주문번호(사번+주문일자+순번으로 처리하는 것이 복잡 ➡︎ 주문번호를 만들어 처리)

식별자 관계

부모의 주식별자가 자식엔터티의 주식별자로 상속되는 경우 실선 표현

문제점

• 식별자 관계만으로 연결될 경우 주식별자 속성이 지속적으로 증가하고 복잡성과 오류 가능성이 증가함

  식별자 연결을 고려하는 경우

• 자식 엔터티가 반드시 부모에게 종속되어야할 때
• 자식 주식별자 구성에 부모 주식별자가 필요할 때
• 상속받은 주식별자 속성을 타 엔터티에 이전 필요할 때
• 강한 연결관계를 표현할 때

비식별자 관계

부모로부터 속성을 받았지만 자식엔터티의 주식별자로 사용하지 않고 일반적인 속성으로 사용하는 경우 점선 표현

문제점

• 조인이 많아짐
• 복잡성이 증가하고 성능이 저하됨 (식별자로 설정한다면 바로 조회조건을 이용하여 조회할 수 있음)

  비식별자 연결을 고려하는 경우

• 약한 종속관계
• 자식 주식별자 구성을 독립적으로 구성해야할 때
• 자식 주식별자 구성에 부모 주식별자가 부분적으로 필요할 때
• 상속받은 주식별자 속성을 타 엔터티에 차단이 필요할 때
• 부모쪽의 관계참여가 선택 관계일 때
• 부모 없이 자식 엔터티의 인스턴스가 먼저 생성될 수 있는 경우
• 부모 인스턴스가 자식 인스턴스보다 먼저 소멸하는 경우
• 별도의 주식별자를 생성하는 것이 더 유리하다고 판단 되는 경우

🔗 참고

엔터티 - 참고 식별자 - 참고

데이터 모델링의 특징

• 현실 세계를 일정한 형식에 맞추어 표현하는 추상화의 의미를 가짐

• 시스템 구현 및 업무 분석, 업무 형상화 등을 위해 진행하는 사전단계의 작업으로서 데이터베이스 구축을 위한 사전작업의 의미가 있음
• 복잡한 현실을 제한된 언어나 표기법으로 이해하기 쉽게 하는 단순화의 의미를 가지고 있음
• 애매모호함을 배제하고 누구나 이해가 가능하도록 정확하게 현상을 기술하는 정확화의 의미를 가짐

데이터 모델링이란?

• 정보 시스템을 구축하기 위한 데이터 관점의 업무 분석 기법

• 현실세계의 데이터에 대해 약속된 표기법에 의해 표현하는 과정
• 데이터베이스를 구축하기 위한 분석/설계의 과정

데이터 모델링이 필요한 이유

• 업무 정보를 구성하는 기초가 되는 정보들에 대해 일정한 표기법에 의해 표현함

• 분석된 모델을 가지고 데이터베이스를 생성하여 개발 및 데이터관리에 사용하기 위함
• 데이터베이스를 구축하기 위한 용도를 위해 데이터모델링을 수행하고 업무에 대한 설명은 일정한 표기법으로 표현함
• 데이터 모델링 자체로서 업무의 흐름을 설명하고 분석하는 부분에 의미를 가지고 있음

데이터 모델링의 유의점

• 중복(Duplication) 여러 장소의 데이터베이스에 같은 정보를 저장하지 않도록함

• 비유연성(Inflexibility) 데이터의 정의를 데이터의 사용 프로세스와 분리
• 비일관성(Inconsistency) 데이터간의 상호 연관관계를 명확하게 정의함

데이터 모델링 분류

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

• 논리적 데이터 모델링 시스템을 구축하고자 하는 업무에 대해 key 속성, 관계 등을 정확하게 표현 재사용성이 높음 정규화, 트랜잭션 인터페이스, 참조 무결성 규칙 정의 등
• 물리적 데이터 모델링 실제로 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적인 성격을 고려하여 설계 플랫폼 종속적

데이터 독립성

• DBMS의 목적

• 하위 단계의 데이터 구조가 변경되어도 상위 단계에 영향을 미치지 않는 속성
• 데이터 종속성: 데이터가 변경되면 응용 프로그램이 수정되어야함
• 데이터 중복성: 데이터의 일관성 문제 발생

논리적 데이터 독립성

• 응용 프로그램에 영향을 주지 않고 데이터베이스의 논리적 구조를 변경할 수 있음
• DBMS가 하나의 논리적 데이터 구조를 가지고 많은 응용 프로그램이 각각 요구하는 다양한 형태의 논리적 구조로 맵핑 시킬 수 있는 능력이 있을 때 가능
• 개념 스키마가 변경되어도 외부 스키마에 영향을 미치지 않도록 함
• 외부스키마에 영향을 미치지 않으면서 개념스키마에 적용되는 제약조건들을 변경 가능

  물리적 데이터 독립성

• 응용 프로그램이나 데이터베이스의 논리적 구조에 영향을 미치지 않고 데이터의 물리적 구조를 변경할 수 있는 능력
• 하나의 논리적 구조로부터 여러가지의 상이한 물리적 구조를 지원할 수 있는 맵핑 능력이 있을 때 가능
• 내부 스키마가 변경되어도 외부/개념 싀마가 영향을 받지 않도록 함

데이터베이스 스키마 구조 3단계

외부스키마

• 데이터베이스 사용자 그룹별 view 기술
• 각 사용자가 보는 개인적 DB 스키마
• 사용자나 응용프로그래머가 접근하는 DB 정의
• 복수개의 스키마로 구성

  개념스키마

• DB에 저장되는 데이터와 그들간의 관계를 표현하는 스키마
• 모든 사용자 관점을 통합한 조직 전체 관점의 통합적 표현
• 개체, 관계성, 제약조건 등을 나타내는데 중점(ER 모델)
• 자세한 물리적 저장장치는 감추고 데이터베이스의 골격에 관심

  내부스키마

• 데이터베이스의 물리적 저장구조 기술
• 물리적 저장장치에서 데이터가 실제적으로 저장되는 방법을 표현
• 개발자 관점

ERD

• 피터첸에 의해 만들어짐

• 관계의 명칭은 관계 표현에 있어 매우 중요한 부분
• 가장 중요한 엔터티를 왼쪽 상단에서부터 배치함

  작성 순서

1. 엔터티 그림
2. 엔터티 배치
3. 엔터티 간 관계 설정
4. 관계명 기술
5. 관계도 (관계차수) 기술
6. 필수 여부 기술

• DDL
• Rollback 불가능
• Auto Commit
• 테이블이 사용한 모든 저장공간 초기화
• 테이블 정의 자체를 완전히 삭제(스키마도 삭제)

TRUNCATE

• DDL(일부 DML 성격)
• Rollback 불가능
• Auto Commit
• 테이블이 들어있던 모든 행 삭제
• 저장 공간을 재사용*할 수 있음
• 스키마 정의는 유지하고 데이터만 삭제

DELETE

• DML
• Commit 이전 Rollback 가능
• 사용자 Commit
• 모두 DELETE해도 저장공간은 초기화되지 않음
• 데이터만 삭제

책 시나공 2023 정보처리기사 필기

공부 기간 2024/1/8 ~ 2024/2/19 2024/2/20 필기 시험

한주에 한과목 공부하고 마지막주에는 기출문제 풀기

📚 공부

시나공 1, 2, 3, 4, 5과목 순서대로 공부 (다시 돌아간다면 1, 2, 5, 3, 4로 공부할 것 같다) 한 과목 끝나면 인터넷 검색해서 해당 과목 기출 풀어서 지식 상태 확인하기

1, 2과목 🦶🏻🧊

출제율 A, B인 챕터는 벨로그에 정리 C, D는 눈으로 한번 제대로 읽고 넘어가기

1, 2과목이 다 너무 이론적인 내용이라 2월 첫째주 까지도 2과목 공부하고 있었다..(이때까진 발등에 🔥도 없었음 ㅎㅎ)

3, 4과목 🦶🔥

3, 4과목에는 SQL이나 c, java python등 익숙한 언어와 코드들이 많이 나와서 크게 정리할 부분은 없었지만 빈출인 이론 내용들은 그래도 벨로그에 정리했다

5과목 🦶🔥🔥🔥🔥

시험 2, 3일 전에 처음 펴봤다 보안 등 모르는 내용이라 그런지 주제들이 너무 방대하게 다가와서 공부하기가 좀 힘들뻔 했지만 1, 2과목만 빠르게 읽고 바로 기출문제로 넘어갔다

5과목에서 생각보다 새로운 주제들이 너무 많이 등장해서 2일 만에 공부하기엔 좀 벅차긴 했다.. 사실 5과목은 1, 2장만 공부하고 들어갔는데 85점이나 나왔슴,, 선택과 집중,,!

시험 하루 전

사실 하루 전까지도 5과목 공부를 하고 있었다,, 저녁 부터 자기 전까지 쉬엄쉬엄 모의고사 3개를 돌렸는데 다 안정권(?) 점수가 나왔어서 그래도 큰 걱정은 없었다

특히 시나공에 있는 2022 기출 문제들은 점수가 너무 잘나오고 문제 자체도 연습하면서 풀었던 문제들이랑 너무 비슷해서 점수가 잘나왔었다

마지막에 푼 시나공 최종점검 모의고사는 이전에 풀어봤던 기출 내용이랑 느낌이 조금 달라서 점수가 형편 없게 나왔지만 저정도가 실제로 내가 받을 점수가 아닐까.. 생각했다

📝 시험 후기

준비물 필기구, 신분증

수험표는 안들고 갔다 사람들이 수험 번호만 알아가면 된다 이러던데 자리 배치도에 이름+수험번호로 써줘서 사실 수험번호도 몰랐어도 될뻔 했지만 그래도 알아가기! 핸드폰으로 찍어가는게 젤 좋은듯

시험 후기 가채점 결과는 65, 55, 85, 95, 85점 평균 77점으로 (2과목 빼고)넉넉하게 통과했다

기출 문제랑 비슷한 문제들도 많이 보였는데 공부를 꼼꼼하게 안해서 그런지 헷갈리는 문제도 많았다.. 후후ㅏ하 그래서 2과목에서 탈탈 털렸나보다

시험 풀 때 느낌은 딱 최종점검 모의고사 풀 때의 느낌이었다. 처음보는 문제들이 너무 많아서,,! (기출을 많이 안풀어봐서 그렇게 느꼈던건가..^^)

그리고 막 넘어갔던 4과목에서도 c언어 포인터에서 헤맸는데 95점이나 나와서 깜짝놀랬다..;;,,,? 그래도 1학년 때 엉엉 울면서 포인터 했던게 나도 모르는 깊숙한 곳에 남아있긴 한가보다

아무튼 4월엔 이제 실기 공부 슬쩍 해야지.. 그전에 취업했다면 더 좋은 일이겠지만..

¹ 소프트웨어 개발 표준의 개요

🖍️ 개발 단계에서 수행하는 품질 관리에 사용되는 국제 표준 ISO/IEC 12207, CMMI, SPICE

² ISO/IEC 12207

🖍️ ISO 국제표준화기구에서 만든 표준 소프트웨어 생명 주기 프로세스 개발, 운영, 유지보수 등을 체계적으로 관리하기 위한 소프트웨어 생명 주기 표준을 제공

• 기본 생명 주기 프로세스: 획득, 공급, 개발, 운영, 유지보수
• 지원 생명 주기 프로세스: 품질 보증, 검증, 확인, 활동 검토, 감사, 문서화, 형상 관리, 문제 해결 프로세스
• 조직 생명 주기 프로세스: 관리, 기반 구조, 훈련, 개선 프로세스

³ CMMI(Capability Maturity Model Integration)

🖍️ 소프트웨어 개발 조직의 업무 능력 및 조직의 성숙도를 평가하는 모델 카네기멜론 대학교 SW공학연구소에서 개발

• 초기, 관리, 정의, 정량적 관리, 최적화 5단계로 구분

• 초기: 정의된 프로세스 없음

• 관리: 규칙화된 프로세스

• 정의: 표준화된 프로세스

• 정량적 관리: 예측 가능한 프로세스

• 최적화: 지속적 개선 프로세스

⁴ SPICE(Software Process Improvement and Capability dEtermination)

🖍️ 정보 시스템 분야에서 소프트웨어의 품질 및 생산성 향상을 위해 소프트웨어 프로세스를 평가 및 개선하는 국제 표준 공식 명칭은 ISO/IEC 15504

SPICE의 목적

• 프로세스 개선을 위해 개발 기관이 스스로 평가하는 것
• 기관에서 지정한 요구조건의 만족여부를 개발 조직이 스스로 평가하는 것
• 계약 체결을 위해 수탁 기관의 프로세스를 평가하는 것

6단계로 구분

0. 불완전(Incomplete): 프로세스가 구현되지 않거나 목적을 달성하지 못한 단계
1. 수행(Performed): 프로세스가 수행되고 목적이 달성된 단계
2. 관리(Managed): 정의된 자원의 한도 내에서 그 프로세스가 작업 산출물을 인도하는 단계
3. 확립(Estabilished): 소프트웨어 공학 원칙에 기반하여 정의된 프로세스가 수행되는 단계
4. 예측(Predictable): 프로세스가 목적 달성을 위해 통제되고, 양적인 측정을 통해서 일관되게 수행되는 단계
5. 최적화(Optimizing): 프로세스 수행을 최적화하고, 지속적인 개선을 통해 업무 목적을 만족시키는 단계

¹ 수학적 산정 기법의 개요

🖍️ 상향식 비용 산정 기법 경험적 추정 모형, 실험적 추정 모형 이라고도 함 개발 비용 산정의 자동화를 목표로 함

• 과거 유사한 프로젝트를 기반으로하여 경험적으로 유도된 것
• COCOMO, Putnam, 기능 점수(FP) 모형 등이 있음

² COCOMO 모형 개요

보헴이 제안한 것 원시 프로그램의 규모인 LOC(원시 코드 라인 수)에 의한 비용 산정 기법

• LOC를 예측한 후 이를 소프트웨어 종류에 따라 다르게 책정되는 비용 산정 방정식에 대입하여 비용을 산정
• 비교적 작은 규모의 프로젝트들을 통계 분석한 결과를 반영한 모델이므로 중소 규모 소프트웨어 프로젝트 비용 추정에 적합
• 같은 규모라도 프로젝트 성격에 따라 비용이 다르게 산정됨
• 비용 산정 결과는 프로젝트를 완성하는데 필요한 노력으로 나타남(Man-Month)

³ COCOMO의 소프트웨어 개발 유형

소프트웨어의 복잡도 혹은 원시 프로그램의 규모에 따라 조직형, 반분리형, 내장형으로 분류

조직형(Organic Mode)

기관 내부에서 개발된 중소규모의 소프트웨어로 일과라 자료 처리나 과학 기술 계산용, 비즈니스 자료 처리용으로 5만 라인 이하의 소프트웨어를 개발하는 유형

• 사무 처리용, 업무용, 과학용 응용 소프트웨어 개발에 적합

반분리형(Semi-Detached Mode)

조직형과 내장형의 중간형 트랜잭션 처리 시스템이나 운영체제, 데이터베이스 관리 시스템등의 30만 라인 이하의 소프트웨어를 개발하는 유형

• 컴파일러, 인터프리터와 같은 유틸리티 개발에 적합

내장형(Embedded Mode)

초대형 규모의 트랜잭션 처리 시스테이나 운영체제 등의 30만 라인 이상의 소프트웨어를 개발하는 유형

• 신호기 제어 시스템, 미사일 유도 시스템, 실시간 처리 시스템 등의 시스템 프로그램 개발에 적합

⁴ Putnam 모형

소프트웨어 생명 주기의 전 과정 동안에 사용될 노력의 분포를 가정해주는 모형

• 푸트남이 제안
• 생명 주기 예측 모형
• 시간에 따른 함수로 표현되는 Rayleigh-Norden 곡선의 노력 분포도를 기초로 함
• 대형 프로젝트의 노력 분포 산정에 이용됨
• 개발 기간이 늘어날수록 프로젝트 적용 인원의 노력이 감소

⁵ 기능 점수(FP) 모형

알브레히트가 제안

1. 소프트웨어의 기능을 증대시키는 요인별로 가중치를 부여
2. 요인별 가중치를 합산하여 총 기능 점수를 산출
3. 총 기능 점수와 영향도를 이용하여 기능 점수를 구함
4. 이를 이용해서 비용 산정

• 발표 초기보다 최근에 그 유용성과 간편성으로 비용 산정 기법 가운데 최선의 평가를 받고 있음
• 소프트웨어 기능 증대 요인
  • 자료 입력(입력 양식), 정보 출력(출력 보고서), 명령어(사용자 질의 수), 데이터 파일, 필요한 외부 루틴과의 인터페이스

¹ 정규화의 개요

🖍️ 함수적 종속성 등의 종속성 이론을 이용하여 잘못 설계된 관계형 스키마를 더 작은 속성의 세트로 쪼개어 바람직한 스키마로 만들어가는 과정

• 하나의 종속성이 하나의 릴레이션에 표현될 수 있도록 분해해가는 과정
• 차수가 높아질수록 만족시켜야할 제약 조건이 늘어남
• 논리적 설계 단계에서 수행
• 논리적 처리 및 품질에 큰 영향을 미침
• 일관성, 정확성, 단순성, 비중복성, 안정성 등 보장
• 정규화 수준이 높을수록 유연한 데이터 구축이 가능하고 데이터 정확성이 높아짐
• 물리적 접근이 복잡하고 너무 많은 조인으로 인해 조회 성능이 저하됨

² 정규화의 목적

• 데이터 구조의 안정성 및 무결성 유지
• 어떤 릴레이션도 데이터베이스 내에서 표현 가능하게 만듦
• 효과적인 검색 알고리즘을 생성할 수 있음
• 데이터 중복을 배제하여 이상(Anomaly)의 발생 방지
• 자료 저장 공간의 최소화
• 데이터 삽입 시 릴레이션을 재구성할 필요성을 줄임
• 데이터 모형의 단순화 가능
• 속성의 배열 상태 검증 가능
• 개체와 속성의 누락 여부 확인 가능
• 자료 검색과 추출의 효율성 추구

³ 이상의 개념 및 종류

정규화를 거치지 않으면 데이터베이스 내에 데이터들이 불필요하게 중복되어 릴레이션 조작 시 예기치 못한 곤란한 현상이 발생하는 것

• 삽입 이상(Insertion Anomaly): 릴레이션에 데이터를 삽입할 때 의도와는 상관없이 원하지 않은 값들도 함께 삽입되는 현상

• 삭제 이상(Deletion Anomaly): 한 튜플을 삭제할 때 의도와는 상관없는 값들도 함께 삭제되는 연쇄가 일어나는 현상

• 갱신 이상(Update Anomaly): 튜플에 있는 속성값을 갱신할 때 일부 튜플의 정보만 갱신되어 정보에 모순이 생기는 현상

⁴ 정규화의 원칙

• 정보의 무손실 표현 -> 하나의 스키마를 다른 스키마르 변환할 때 정보의 손실이 있어서는 안됨
• 분리의 원칙 -> 하나의 독립된 관계성은 하나의 독립된 릴레이션으로 분리시켜야함
• 데이터의 중복성이 감소되어야함

⁵ 정규화 과정

1️⃣ 1NF 릴레이션에 속한 모든 도메인이 원자값만으로 되어있는 정규형 즉, 릴레이션의 모든 속성 값이 원자값으로만 되어있는 정규형

• 릴레이션의 모든 속성이 단순 영역에서 정의됨

2️⃣ 2NF 릴레이션이 1NF이고 기본키가 아닌 모든 속성이 기본키에 대하여 완전 함수적 종속을 만족하는 정규형 *함수적 종속: 데이터들이 어떤 기준값에 의해 종속되는 것 x에따라 y가 결정될때 y가 x에 함수 종속적임, x➔y로 표현

3️⃣ 3NF 릴레이션이 2NF이고 기본키가 아닌 모든 속성이 기본키에 대해 이행적 종속을 만족하지 않는 정규형 A➔B, B➔C 일때, A➔C를 만족하는 관계

• 무손실 조인 또는 종속성 보존을 저해하지 않고도 항상 3NF를 얻을 수 있음

🅱️ BCNF 릴레이션 R에서 결정자가 모두 후보키인 정규형

• 3NF에서 후보키가 여러 개 존재하고 서로 중첩되는 경우에 적용하는 강한 제3정규형
• BCNF가 종속성을 보존하는 것은 아님
• BCNF의 제약 조건
  • 키가 아닌 모든 속성은 각 키에 대하여 완전 종속해야함
  • 키가 아닌 모든 속성은 그 자신이 부분적으로 들어가 있지 않은 모든 키에 대하여 완전 종속 해야함
  • 어떤 속성도 아닌 키가 아닌 속성에 대해서는 완전종속할 수 없음

4️⃣ 4NF 릴레이션에 다치 종속이 성립하는 경우 R의 모든 속성이 A에 함수적 종속 관계를 만족하는 정규형

5️⃣ 5NF 릴레이션의 모든 조인 종속이 R의 후보키를 통해서만 성립되는 정규형

💡 관계대수 vs 관계해석 💡

¹ 관계대수의 개요

🖍️ 관계형 데이터베이스에서 원하는 정보와 그 정보를 검색하기 위해서 어떻게 유도하는가를 기술하는 절차적인 언어

² Select

• 선택 조건을 만족하는 튜플의 부분집합을 구하여 새로운 릴레이션 만듦

• 수평 연산
• σ

³ Project

• 속성 리스트에 제시된 속성 값만을 추출하여 새로운 릴레이션을 만드는 연산

• 중복이 발생하면 중복이 제거됨
• 수직 연산자
• 𝝿

⁴ Join

• 두개의 릴레이션을 하나로 합쳐서 새로운 릴레이션을 만드는 연산

• 차수: 두 릴레이션 차수의 합
• join의 결과는 교차곱을 수행한다음 select를 수행한 것과 같음
• ⨝

⁵ Division

• R의 속성이 S의 속성 값을 모두 가진 튜플에서 S가 가진 속성을 제외한 속성만을 구하는 연산

• ÷

⁶ 일반 집합 연산자

• Union, Intersection, Difference, Cartesian Product

⁷ 관계해석(Relational Calculus)

• 관계 데이터 모델의 제안자인 코드가 수학의 술어해석에 기반을 두고 관계 데이터베이스를 위해 제안
• 관계 데이터의 연산을 표현하는 방법
• 원하는 정보를 정의할 때는 계산 수식을 사용
• 원하는 정보가 무엇이라는 것만 정의하는 비절차적 특성
• 튜플 관계해석, 도메인 관계해석
• 관계해석과 관계대수는 관계 데이터베이스를 처리하는 기능과 능력면에서 동등하며, 관계대수로 표현한 식은 관계해석으로 표현할 수 있음
• ∃
• ∀

💡 키 개념, 종류 💡 무결성 종류

키

¹ 키의 개념

🖍️ 조건에 만족하는 튜프를 찾거나 순서대로 정렬할 때 튜플들을 서로 구분할 수 있는 기준이 되는 애트리뷰트

² 후보키 Candidate Key

• 튜플을 유일하게 식별하기 위해 사용하는 속성들의 부분집합
• 기본키로 사용할 수 있는 속성들
• 모든 릴레이션에는 반드시 하나 이상의 후보키가 존재
• 후보키는 모든 튜플에 대해서 유일성과 최소성을 만족시켜야함
  • 유일성(Unique): 하나의 키 값으로 하나의 튜플만을 유일하게 식별할 수 있어야함
  • 최소성(Minimality): 모든 레코드들을 유일하게 식별하는데 꼭 필요한 속성으로만 구성되어야함

³ 기본키 Primary Key

• 후보키 중에서 특별히 선정된 Main Key
• 중복된 값을 가질 수 없음
• 널 값을 가질 수 없음

⁴ 대체키 Alternate Key

• 후보키가 둘 이상일 때 기본키를 제외한 나머지 후보키
• 보조키 라고도 함

⁵ 슈퍼키 Super Key

• 릴레이션을 구성하는 모든 튜플들 중 슈퍼키로 구성된 속성의 집합과 동일한 값은 없음
• 슈퍼키는 유일성은 만족하지만 최소성은 만족시키지 못함

⁶ 외래키 Foreign Key

• 다른 릴레이션의 기본키를 참조하는 속성 또는 속성들의 집합
• 참조되는 릴레이션의 기ㅣ본키와 대응되어 릴레이션 간에 참조 관계를 표현하는데 중요한 도구
• 외래키로 지정되면 참조 릴레이션의 +

무결성

¹ 무결성

🖍️ 데이터베이스에 저장된 데이터 값고 그것이 표현하는 현실 세계의 실제 값이 일치하는 정확성

• 무결성 제약조건은 데이터베이스에 들어잇는 데이터의 정확성을 보장하기 위해 부정확한 자료가 데이터베이스 내에 저장되는 것을 방지하기 위한 제약조건

² 개체 무결성(Entity Integrity, 실체 무결성)

• 기본 테이블의 기본키를 구성하는 어떤 속성도 널값이나 중복값을 가질 수 없다

³ 도메인 무결성(Domain Integrity, 영역 무결성)

• 주어진 속성 값이 정의된 도메인에 속한 값이어야한다는 규정

⁴ 참조 무결성(Referential Integrity)

• 외래키 값은 널이거나 참조 릴레이션의 기본키 값과 동일해야함
• 참조할 수 없는 외래키 값을 가질 수 없음

⁵ 사용자 정의 무결성

• 속성 값들이 사용자가 정의한 제약 조건에 만족해야한다는 규정

⁶ 데이터 무결성 강화

• 데이터 베이스 구축 과정에서 무결성을 정의해야함

애플리케이션

• 데이터 생성, 수정, 삭제 시 무결성 조건을 검증하는 코드를 데이터를 조작하는 프로그램 내에 추가
• 코드를 이용한 복잡한 규칙 등을 검토하는 무결성 검사는 데이터베이스에서 수행하기 어려우므로 애플리케이션 내에서 처리

• 장점: 사용자 정의 같은 복잡한 무결성 조건의 구현 가능
• 단점: 소스 코드에 분산되어 있어 관리가 힘들고 개별적인 시행으로 인해 적정성 검토가 어려움

데이터베이스 트리거

• 트리거 이벤트에 무결성 조건을 실행하는 절차형 SQL 추가

• 장점: 통합 관리 가능, 복잡한 요구조건의 구현 가능
• 단점: 운영 중 변경이 어렵고 사용상 주의가 필요함

제약 조건

• 데이터베이스에 제약조건을 설정하여 무결성 유지

• 장점: 통합 관리 가능, 간단한 선언으로 구현 가능, 변경 용이, 오류 데이터 발생 방지
• 단점: 복잡한 제약 조건의 구현과 예외적인 처리가 불가능

💡

¹ E-R 모델

🖍️ 개념적 데이터 모델의 가장 대표적

• 개체 타입과 관계 타입으로 현실세계 표현
• 개체(Entity), 관계(Relationship), 속성(Attribute)
• 특정 DBMS를 고려한 것은 아님

² E-R 다이어그램

☐: 사각형 - 개체 ◇: 마름모 - 관계 ⃝: 타원 - 속성 ◎: 이중 타원 - 다중값 속성(복합 속성) 밑줄 타원 - 기본키 속성 복수 타원 - 복합 속성 (성명: 성 + 이름) 관계 - 개체 간 관계에 대한 대응수를 선 위에 기술 선 - 개체와 속성 연결

💡 설계 단계별 특징(순서, 대표 작업)

¹ 데이터베이스 설계

🖍️ 사용자의 요구를 분석하여 그것들을 컴퓨터에 저장할 수 있는 데이터베이스의 구조에 맞게 변형한 후 특정 DBMS로 데이터베이스를 구현하여 일반 사용자들이 사용하게 하는 것

² 데이터베이스 설계 시 고려 사항

• 무결성: 삽입, 삭제, 갱신 등의 연산 후에도 데이터가 정해진 제약 조건을 항상 만족해야함
• 일관성: 데이터들 사이나, 특정 질의에 대한 응답이 처음부터 끝까지 변함없이 일정해야함
• 회복: 시스템에 장애가 발생했을 때 장애 발생 직전의 상태로 복구할 수 있어야함
• 보안: 불법적인 데이터 노출 또는 변경이나 손실로부터 보호할 수 있어야함
• 효율성: 응답시간의 단축, 시스템의 생산성, 저장 공간의 최적화 등이 가능해야함
• 데이터베이스 확장: DB운영에 영향을 주지 않으면서 지속적으로 데이터를 추가할 수 있어야함

³ 데이터베이스 설계 순서

요구조건 분석 ➡︎ 개념적 설계 ➡︎ 논리적 설계 ➡︎ 물리적 설계 ➡︎ 구현

⁴ 요구조건 분석

필요한 용도 파악

• 사용자에 따른 수행 업무와 필요한 데이터의 종류, 용도, 처리 형태, 흐름, 제약 조건 등 수집
• 수집된 정보를 바탕으로 요구 조건 명세 작성

⁵ 개념적 설계(정보 모델링, 개념화)

정보의 구조를 얻기 위해 현실 세계의 무한성과 계속성을 이해 다른 사람과 통신하기 위해 현실 세계에 대한 인식을 추상적 개념으로 표현하는 과정

• 개념 스키마 모델링, 트랜잭션 모델링 병행 수행
• 요구조건 명세를 DBMS에 독립적인 ER다이어그램으로 작성
• DBMS에 독립적인 개념 스키마 설계

⁶ 논리적 설계(데이터 모델링)

현실 세계에서 발생하는 자료를 컴퓨터가 이해하고 처리할 수 있는 물리적 저장장치에 저장할 수 있도록 변환하기 위해 특정 DBMS가 지원하는 논리적 자료 구조로 변환시키는 과정

• 개념 스키마를 평가 및 정제하고 DBMS에 따라 서로 다른 논리적 스키마를 설계하는 단계
• 트랜잭션의 인터페이스 설계
• 관계형 DB라면 테이블을 설계하는 단계
• 종속적인 논리 스키마 설계

⁷ 물리적 설계(데이터 구조화)

논리적 구조로 표현된 데이터를 디스크 등의 물리적 저장장치에 저장할 수 있는 물리적 구조의 데이터로 변환하는 과정

• 다양한 DB 응용에 대해 처리 성능을 얻기 위해 DB파일의 저장 구조 및 액세스 경로를 결정
• 저장 레코드의 양식, 순서, 접근 경로, 조회가 집중되는 레코드와 같은 정보를 사용하여 데이터가 컴퓨터에 저장되는 방법을 묘사 🖍️ 고려할 사항: 트랜잭션 처리량, 응답 시간, 디스크 용량, 저장 공간의 효율화

⁸ 데이터베이스 구현

논리적 설계와 물리적 설계 단계에서 도출된 데이터베이스 스키마를 파일로 생성하는 과정

• 특정 DBMS의 DDL을 이용하여 데이터베이스 스키마를 기술한 후 컴파일, 빈 DB파일 생성
• 데이터 입력
• 응용 프로그램을 위한 트랜잭션 작성
• 데이터베이스 접근을 위한 응용 프로그램 작성

💡

¹ 인터페이스 구현 검증

🖍️ 인터페이스가 정상적으로 문제없이 작동하는지 확인

• 구현 검증 도구와 감시 도구를 이용하여 인터페이스의 동작 상태 확인

² 인터페이스 구현 검증 도구

xUnit

• 같은 테스트 코드를 여러 번 작성하지 않게 도와줌
• 테스트마다 예상 결과를 기억할 필요가 없게 하는 자동화된 해법을 제공하는 단위 테스트 프레임워크

STAF

• 서비스 호출 및 컴포넌트 재사용 등 다양한 환경을 지원하는 테스트 프레임워크
• 크로스 플랫폼, 분산 소프트웨어 테스트 환경을 조성할 수 있도록 지원
• 분산 SW의 경우 각 분산환경에 설치된 데몬이 프로그램 테스트에 대한 응답을 대신함
• 데몬: 사용자의 직접적인 개입 없이 특정 상태가 되면 자동으로 동작하는 시스템 프로그램
• 테스트가 완료되면 이를 통합하고 자동화하여 프로그램 완성

FitNesse

• 웹 개반 테케 설계, 실행, 결과 확인 등을 지원하는 테스트 프레임워크

NTAF

• FitNesse의 장점인 협업 기능 + STAF의 재사용 및 확장성
• NHN(Naver)의 테스트 자동화 프레임워크

Selenium

• 다양한 브라우저 및 개발 언어를 지원하는 웹 애플리케이션 테스트 프레임워크

watir

• Ruby를 사용하는 애플리케이션 테스트 프레임워크

³ 인터페이스 구현 감시 도구

🖍️ APM을 사용하여 감시(모니터링) APM 유형 두가지

• 리소스 방식(Nagios, Zabix, Cacti)
• 엔드투엔드 방식(VisualVM, 제니퍼, 스카우터 등)

💡 💡

¹ 인터페이스 보안

• 인터페이스는 시스템 모듈 간 통신 및 정보 교환을 위한 통로로 사용되므로 충분한 보안 기능을 갖추지 않으면 시스템 모듈 전체에 악영향을 줄 수 있음

² 인터페이스 보안 취약점 분석

• 기능이 수행되는 각 구간들의 구현 현황ㅇ을 확인하고 각 구간에 어떤 보안 취약점이 있는지 분석
• 송수신 영역의 구현 기술 및 특징 등을 구체적으로 확인
• 영역별로 발생할 수 있는 보안 취약점을 시나리오 형태로 작성

³ 인터페이스 보안 기능 적용

네트워크 영역

• 인터페이스 송수신 간 스니핑 등을 이용한 데이터 탈취 및 변조 위협을 방지하기 위해 네트워크 트래픽에 대한 암호화를 설정
• 암호화는 인터페이스 아키텍처에 따라 IPSec, SSL, S-HTTP 등 다양한 방식 적용

애플리케이션 영역

• SW 개발 보안 가이드를 참조하여 애플리케이션 코드 상의 보안 취약점을 보완하는 방향으로 애플리케이션 보안 기능 적용

데이터베이스 영역

• 데이터베이스, 스키마, 엔티티의 접근 권한과 프로시저, 트리거 등 DB 동작 객체의 보안 취약점에 보안 기능을 적용
• 개인 정보 등은 암호화나 익명화 등 데이터 자체의 보안 방안도 고려

스니핑

• 네트워크의 중간에서 남의 패킷 정보를 도청하는 해킹 유형

• 수동적 공격

• 네트워크 내의 패킷들은 대부분 암호화가 되어있지 않아 스니핑 같은 기법에 당하기 쉬움

⁴ 데이터 무결성 검사 도구

🖍️ 시스템 파일의 변경 유무를 확인하고 파일이 변경되었을 경우 이를 관리자에게 알려주는 도구

• 허가받지 않은 내부 사용자들이 시스템에 침입하면 백도어를 만들어놓거나 시스템 파일을 변경하여 자신의 흔적을 감추는데 무결성 검사 도구를 이용하여 이를 감지할 수 있음
• 해시함수를 이용하여 현재 파일 및 디렉토리의 상태를 DB에 저장한 후 감시하다가 현재 상태와 DB의 상태가 달라지면 관리자에게 변경 사실을 알려줌
• Tripwire, AIDE, Samhain, Claymore, Slipwire, Fcheck

💡 외계인 코드 개념, 클린 코드 작성 원칙 💡 소스 코드 품질 분석 도구

¹ 소스 코드 최적화

🖍️ 나쁜 코드를 배제하고 클린 코드로 작성하는 것

• 클린 코드: 누구나 쉽게 이해하고 수정 및 추가할 수 있는 단순, 명료한 코드

• 나쁜 코드

  • 프로그램의 로직이 복잡하고 이해하기 어려운 코드
  • 스파게티 코드: 코드의 로직이 서로 복잡하게 얽혀 있는 코드
  • 외계인 코드: 아주 오래되거나 참고문서 또는 개발자가 없어 유지보수 작업이 어려운 코드

• 나쁜 코드를 클린 코드로 수정하면 애플리케이션의 성능이 개선됨

⭐️ 클린 코드 작성 원칙

• 가독성
  • 누구든지 코드를 쉽게 읽을 수 있도록 작성
  • 쉬운 용어 사용, 들여쓰기 기능 사용
• 단순성
  • 코드를 간단하게 작성
  • 한 번에 한 가지를 처리하도록 작성
  • 클래스, 메소드, 함수 등을 최소 단위로 분리
• 의존성 배제
  • 코드가 다른 모듈에 미치는 영향을 최소화
  • 코드 변경시 다른 부분에 영향이 없도록 작성
• 중복성 최소화
  • 코드의 중복 최소화
  • 중복된 코드는 삭제하고 공통된 코드 사용
• 추상화
  • 상위 클래스/메소드/함수에서는 간략하게 애플리케이션의 특성을 나타내고 상세 내용은 하위에서 구현

² 소스 코드 최적화 유형

• 클래스 분할 배치: 하나의 클래스는 하나의 역할만 수행하도록 응집도를 높이고 크기를 작게 작성

• 느슨한 결합: 인터페이스 클래스를 이용하여 추상화된 자료구조와 메소드를 구현함으로써 클래스 간의 의존성을 최소화

• 코딩 형식 준수: 코드 작성 시 다음 형식 준수

  • 줄 바꿈 사용
  • 개념적 유사성이 높은 종속 함수 사용
  • 호출하는 함수는 선배치, 호출되는 함수는 후배치
  • 지역 변수는 각 함수의 맨 처음에 선언

• 좋은 이름 사용: 변수나 함수 이름은 기억하기 좋은 이름, 발음 쉬운 용어, 접두어 사용 등 기본적인 이름 명명 규칙을 정의하고 규칙에 맞는 이름 사용

• 적절한 주석문 사용: 소스 코드 작성 시 앞으로 해야 할 일을 기록하거나 중요한 코드를 강조할 때 주석문 사용

³ 소스 코드 품질 분석 도구

• 메모리 누수 현상, 스레드 결함 등을 발견하기 위해 사용하는 분석 도구

정적 분석 도구

• 작성한 소스 코드를 실행하지 않고 코딩 표준, 코딩 스타일, 결함 등을 확인
• 비교적 개발 초기의 결함을 찾는데 사용
• 개발 완료 시점에서는 개발된 소스 코드의 품질을 검증하는 차원에서 사용
• 자료 흐름, 논리 흐름을 분석하여 비정상적인 패턴을 찾을 수 있음
• 코딩의 복잡도, 모델 의존성, 불일치성 등 분석 가능
• 종류: pmd, cppcheck, SonarQube, checkstyle, ccm, cobertuna 등

동적 분석 도구

• 소스 코드를 실행하여 코드에 존재하는 메모리 누수, 스레드 결함 등 분석
• 종류: Avalanche, Valgrind 등