2020년 개정 정보처리기사 실기 족보 정리 (1)

 

 

2020년 개정 정보처리기사 실기 족보 정리 (2)

 

2020년 개정 정보처리기사 실기 족보 정리 (3)

 

 

테스트의 원칙

① 오류-부재의 궤변(Absense of Error Fallacy) : 아무리 많은 오류를 제거한다고 해도 사용자의 요구사항을 만족하지 못하는 프로그램은 품질이 높다고 말할 수 없음

 

② 살충제 패러독스(Pesticide Paradox) : 동일한 테스트 케이스를 반복 실행하면 더 이상 새로운 결함을 발견할 수 없으므로 주기적으로 테스트 케이스를 개선하여 테스트를 진행해야 함.

 

③ 파레토 법칙 : 소프트웨어 결함의 80%는 20%의 기능들이 가진다는 법칙

 

④ 낚시의 법칙 : 낚시 포인트 처럼 소프트웨어도 특정 위치에서 많은 결함이 발견된다는 법칙

 

⑤ 결함 집중(Detect Clustering) : 결함은 대부분 소수의 특정 모듈에 집중되어 있어 결함의 발견, 가시화, 제거, 예방 등을 효율적으로 진행할 수 있어야 함.

 

⑥ 완벽한 테스트는 불가능 : 반복적인 테스트로 잠재적인 오류를 줄일 수 있지만 모든 오류를 발견할 수는 없음. 완벽한 테스트는 불가능하므로 위험 분석 및 우선순위를 고려해 테스트를 진행해야 함.

 

⑦ 자신이 아닌 다른 개발자가 테스트 : 자신이 코딩한 소스 코드를 자신이 검토하여 오류를 발견하는 것 보다 제 3자가 소스크드를 검토하는 것이 오류를 발견할 확률이 높음.

 

 

애자일(Agile) 방법론

고객의 요구사항 변화에 민첩하고 유연하게 대응할 수 있도록 진행하는 것. 일정한 주기를 반복하면서 개발 과정이 진행된다. 소규모 프로젝트, 숙련된 개발자, 급변하는 요구사항에 적합함. XP, SCRUM, 기능 중심 개발(Feature-Driven Development), 경량 개발, kanban 등이 대표적임.

 

애자일 절차

계획 -> 개발 -> 승인테스트

 

COCOMO(Constructive Cost Model) 모델

보헴(Boehm)이 제안한 LOC에 의한 비용 산정방법. 비용 견적의 유연성이 높아 비용 산정에 널리 사용됨. 소프트웨어 성격에 따라 비용이 다르게 산정됨

 

종류

• Organic : 5만 라인 이하 소프트웨어 개발에 적합, 사무처리, 과학용, 업무용
• Semi-Detached : 30만 라인 이하 소프트웨어 개발에 적합. 운영체제, 데이터베이스 관리 시스템
• Embedded : 30만 라인 이상 초대형 규모 시스템 소프트웨어 개발에 적합. 신호제어, 우주항공, 실시간 처리 시스템

 

형상관리

개념

소프트웨어 개발의 전 과정에서 발생하는 산출물들의 버전을 관리하기 위한 활동.

 

특성

동일한 프로젝트를 여러 개발자가 동시에 개발이 가능하다. 사용자들의 불필요한 수정을 제한한다. 버전 관리를 통해 배포본 관리에 유용하다. 

 

절차

1) 형상식별 : 형상 관리 대상을 식별하고 이름과 관리 번호 부여

2) 변경제어(형상 통제) : 형상 항목의 변경 요구를 검토 승인하는 작업

3) 형상 상태 보고 : 형상의 식별, 통제, 감사 작업의 결과를 기록 및 관리하는 작업

 

 

요구사항 검토 방법

① 동료검토 : 2~3명 정도 검토 담당자가 수행. 요구사항 명세서 작성자가 다수의 이해관계자들에게 명세서 내용을 설명한다.

 

② 워크스루(Walk Through) : 검토 자료를 회의 전 배포한다. 짧은 시간 동안 회를 통해 오류를 검토함. 

 

③ 인스펙션(Inspection) : 소프트웨어 개발에 참여하지 않은 다른 전문가가 오류를 찾아내는 방법

 

④ 프로토타입 : 검증이 필요한 일부분에 대한 견본을 개발해 고객을 대상으로 시연하면서 요구사항 검증.

 

패키지 다이어그램

구조적 다이어그램의 한 종류로 모델 요소들을 그룹화한 패키지들의 관계를 표현한다. 

 

구조적 다이어그램의 종류

• 클래스 다이어그램
• 객체 다이어그램
• 배치 다이어그램
• 컴포넌트 다이어그램
• 복합체 구조 다이어그램

 

 

 

UI 설계 기본 원칙[직일효유]

1. 직관성 : 가급적 별다른 이해 없이 즉시 사용할 수 있어야 한다.
2. 일관성(학습성) : 기능 및 시각적 요소의 일치로 학습하기 용이해야 한다.
3. 효율성(유효성) : 사용자의 목적을 정확하고 빠르게 달성할 수 있어야 한다.
4. 유연성 : 사용자의 요구를 수용하고 실수를 수정할 수 있어야 한다.

 

재사용 모듈 설계 유의사항

결합도는 약하게, 응집도는 높게 구성되어야 한다.

 

누구나 쉽게 이해하고, 사용할 수 있도록 사용법이 공개되어야 한다.

 

공유도는 높이고, 제어도는 낮추어 설계되었는지 확인한다.

 

효과적인 제어를 위해 모듈 설계가 계층적으로 제시되어야 한다.

 

모듈은 유지보수가 용이하고 지나치게 제한적이지 않아야 한다.

 

결합도(Coupling) vs 응집도(Cohesion)

결합도 : 모듈 사이의 연관 관계에 의해 모듈이 서로를 의존하는 정도를 의미. 결합도가 약할수록 의존성이 약해지기 때문에 모듈의 독립성은 높아진다.

 

응집도 : 모듈의 내부 요소들이 밀접한 관계를 맺고 있는 정도를 의미한다. 응집도가 강할 수록 필요한 요소들로만 구성되기 때문에 독립성이 높아진다. 

 

 

소프트웨어 모듈 결합도(자스제외공내)

① 자료 결합도

가장 낮은 결합도, 모듈간 인터페이스로 전달되는 인수와 전달받는 매개변수를 통해서만 상호작용

 

② 스탬프 결합도

두 모듈이 동일한 자료구조를 부분적으로 공유하는 경우

 

③ 제어 결합도

모듈간 인터페이스로 값만 전달되는 것이 아니라 제어 요소를 전달하는 것. 모듈이 전달하는 제어 요소로 다른 모듈의 처리결과가 변경됨

 

④ 외부 결합도

두 모듈이 모듈 외부에 선언된 변수(전역변수)를 참조하는 경우. 외부 변수는 모든 모듈이 공통적으로 사용가능하기 때문에 문제 발생의 가능성이 높음

 

⑤ 공통(공유) 결합도

모듈이 다른 모듈의 내부 데이터를 참조하는 경우

 

⑥ 내용 결합도

가장 높은 결합도를 가짐. 모듈이 다른 모듈의 내부 기능과 데이터를 직접적으로 사용하는 경우

 

 

 

소프트웨어 모듈 응집도

① 기능적 응집도

가장 강한 응집도를 가짐. 모듈 내부의 모든 기능 요소들이 단일 문제를 해결하는데 수행되는 경우. 기본 라이브러리 모듈이 여기 속함.

 

② 순차적 응집도

모듈의 기능 수행 결과를 그 다음 기능 수행의 입력 데이터로 사용하는 경우

 

③ 교환적 응집도

모듈의 기능들이 동일한 입출력 데이터를 사용하여 서로 다른 기능을 수행하는 경우

 

④ 절차적 응집도

모듈의 기능들이 하나의 문제를 해결하기 위해 순차적으로 수행됨. 순차적 응집도와 달리 이전 기능의 출력 데이터를 현재 기능 입력데이터로 사용하지 않음

 

⑤ 시간적 응집도

각 기능들의 연관성은 없지만 특정 시기에 함께 처리해야 하는 기능들을 묶어 놓은 경우

 

⑥ 논리적 응집도

유사한 성격을 갖거나 특정 형태로 분류되는 처리 요소들로 모듈이 형성되는 경우

 

⑦ 우연적 응집도

가장 약한 응집도를 가짐. 모듈 내부의 각 구성 요소들이 서로 관련 없는 요소로만 구성된 경우

 

 

 

GoF 디자인 패턴

이 분야의 Gang of Four 인 에리히 감마, 리처드 헬름, 랄프 존슨, 존 블리시데스가 공동 집필한 책에서 제안한 디자인 패턴, 23가지 디자인 패턴을 정리하고 각각의 디자인 패턴을 5개의 생성 패턴, 7개의 구조 패턴, 11개의 행위 패턴으로 구분

 

 

GoF 디자인 생성 패턴

① Abstract Factory

관련이 있는 서브 클래스를 묶어 팩토리 클래스로 만들고 객체를 생성함. 여러 개의 클래스를 하나의 추상 클래스로 묶어 한 번에 교체할 수 있는 패턴

 

② Factory Method

객체를 생성하기 위한 인터페이스를 정의하여 어떤 클래스가 인스턴스화 될 것인지 서브 클래스가 결정하도록 하는 생성패턴. 서브 클래스가 인스턴스를 결정하도록 하고 책임을 위임하는 생성 패턴.

 

③ Builder

많은 인수를 가진 복잡한 객체를 단계적으로 생성하는 것에 초점을 두는 생성패턴. 생성 단계를 캡슐화 하여 구축 공정을 동일하게 이용하도록 하는 패턴.

 

④ Prototype

성능 향상을 위해 기존 객체를 복사하여 중복 객체를 생성하는 생성 패턴. 

 

⑤ Singleton

클래스가 오직 하나의 인스턴스만 가지도록 하는 패턴. 여러 동일한 인스턴에 의해 성능이 저하되지 않도록 하는 패턴. Private로 접근을 제한하고, static으로 정적 변수를 선언함.

 

 

GoF 디자인 구조 패턴

여러 객체를 모아 구조화시키는 패턴. 객체에 접근할 수 있는 인터페이스와 새로운 기능을 제공함.

 

① Adapter

서로 다른 인터페이스로 인해 함께 사용하지 못하는 클래스를 함께 사용하도록 하는 패턴. 

 

② Bridge

하나의 계층에 복잡하게 존재하는 클래스들을 기능 클래스와 구현 클래스로 분리하여 두 클래스를 연결함. 

 

③ Composite

복합 객체와 단일 객체를 동일하게 취급하거나 다룰 수 있는 패턴. 여러개의 클래스를 모아서 마치 하나의 클래스처럼 취급함. 트리 형태 구조를 다룰 때 유용함.

 

④ Decorator

소스를 변경하지 않고 독립적인 기능을 확장하도록 하는 패턴. 객체에 부가적인 기능을 동적으로 추가할 때 사용함.

 

⑤ Facade

복잡한 시스템을 구조화하여 쉽게 사용할 수 있도록 하는 패턴. 클라이언트와 복잡한 서브 시스템 사이에 위치하며, 단순화된 하나의 인터페이스를 제공함. 클래스간의 의존 관계가 줄어들고 복잡성이 낮아짐.

 

⑥ Flyweight

대량의 유사한 작은 객체들을 공유하여 메모리를 가볍게 유지시키는 데 유용하다. 자주 사용하는 같은 데이터나 코드를 중복 생성하지 않도록 관리하는 저장소를 만들어 필요할 때마다 불러와 사용함.

 

⑦ Proxy

다른 객체로 접근하는 것을 통제하기 위해 객체의 대리자를 제공하는 패턴. 한정된 자원을 가지고 서비스 요청이 폭주하는 시간에도 안정되고 빠르게 유지하기 위한 웹툰 서비스 등에 이용함. 

 

 

 

 

GoF 디자인 행위 패턴

기능의 구체적인 알고리즘을 정의하는 패턴. 큰 작업을 여러개의 객체로 분리한 방법을 제공함. 

 

① Chain of Responsibility

문제 처리를 담당하는 여러 기능을 두고 순서대로 처리해 나가는 패턴. 

 

 

② Command

요청 자체를 객체화(캡슐화)하여 클라이언트에 매개변수로 넘길 수 있게 하는 패턴. Composite 패턴을 이용해 여러 명령어의 구성이 가능함. 

 

③ Interpreter

간단한 언어의 문법을 정의, 문장을 구성, 문장을 해석하는 방법을 제시함. 매개 변수를 사용해 여러 가지 다른 요구사항을 처리할 수 있음.

 

④ Iterator

내부 데이터 구조를 노출하지 않고 어떤 객체 집합에 속한 원소들을 순차적으로 접근할 수 있도록 하는 패턴. 트리 자료구조에서 자료형의 객체를 순차적으로 접근하려 할 때 사용하는 패턴. 

 

⑤ Mediator

여러 객체 간 통신 복잡성을 줄이기 위해 사용되는 패턴. 복잡한 상호작용 관계를 단순화 시킬 수 있다. 서로 다른 클래스 간의 모든 통신을 처리하고 약한 결합으로 코드를 쉽게 유지 관리 할 수 있는 중재자 클래스를 제공함.

 

⑥ Memento

객체의 상태를 저장해뒀다가 복원해야 할 경우 사용하는 패턴. 캡슐화의 원칙을 지키면서 객체의 내부 상태를 파악하고 객체의 상태를 저장해둔 상태로 다시 복구할 수 있게 한다. 이전의 상태값을 보관해야 하므로 오버헤드가 발생함.

 

⑦ Observer

1대다 관계의 오브젝트에 대해 감시하고 있다가 특정 객체의 상태가 변하면 다른 모든 객체에게 그 사항을 알리고 필요한 경우 자동적으로 수정이 이뤄지도록 하는 패턴. 다른 객체에 의존하지 않으면서 데이터 변경을 통보하고자할 때 유용함.

 

⑧ State

객체 자신의 내부 상태에 따라 기능을 변경하도록 하는 패턴. 특정 메소드가 객체의 상태에 따라 다른 기능을 수행함. 

 

⑨ Strategy

클래스별로 캡슐화되어 있는 객체들을 상호교환이 가능하도록 하는 패턴. 다형성을 이용해 특정 객체에 종속되지 않으면서 알고리즘에 대한 확장, 변형이 용이하다. 

 

⑩ Template Method

알고리즘에 대한 골격을 정의하고, 구체적인 단계는 서브 클래스에서 정의하는 패턴. 기본 개념은 상속 관계와 오버라이딩을 활용한 재정의. 

 

①①Vistor

기존 클래스를 수정하지 않고도 새로운 기능을 추가 가능하게 하는 패턴. 멤버 변수와 멤버 메소드를 다른 클래스로 분리하여 서로 간 호출하게 한다. 

 

 

재해 복구 시스템(DRS : Disaster Recovery System)

RTO(Recovery Time Objective) : 복구 목표 최대 허용 시간

 

RPO(Recovery Point Objective) : 복구 목표 최대 허용 시점

 

 

EAI(Enterprise Application Integration)

서로 다른 기종의 시스템 간 연동을 가능하게 해주는 전사적 애플리케이션 통합 환경

어댑터를 이용해 메시지 변환이 가능함. 서로 다른 코드나 프로토콜을 사용하는 시스템 간 통신이 가능함.

 

① Point-to-Point : 미들웨어 없이 애플리케이션 간 직접 연결하는 방식

 

② Hub & Spoke : 단일 접점인 허브 시스템을 통해 데이터를 전송하는 중앙 집중형 방식. 허브에 장애가 발생하면 전체 시스템에 영향을 받는다.

 

③ Message Bus(ESB : Enterprisse Service Bus) : 애플리케이션 사이에 미들웨어(버스)를 두어 처리하는 방식. 별도의 어댑터가 필요치 않으며, 서비스 버스라는 백본(중심이 되는 중요한 통신 회선)을 이용해 통신하는 방식. 미들웨어를 통해 통합되므로 뛰어난 확장성, 대용량 처리가 가능함. 

 

 

XML vs JSON

① XML(eXensible Markup Language) : 특수한 목적을 갖는 마크업 어어를 만드는데 사용되는 다목적 마크업 언어. 데이터베이스와 연결되어 다양한 데이터 처리가 가능함.

 

② JSON(JavaScript Object Notation) : 기존의 XML을 대체하는 독립적인 개방형 표준방식. 보편적으로 AJAX 기술에서 많이 사용됨. 

 

 

SOAP(Simple Object Access Protocol)

웹 서비스에서 사용되는 보편적이고 확장성 있는 XML기반 메시지 프로토콜. HTTP, HTTPS, SMTP등을 통해 전송됨. 

 

 

UDDI(Universal Description Discover and Integration)

필요한 웹 서비스를 찾을 수 있는 웹 서비스 레지스트리. 플랫폼 독립적인 기술로 개발된 범용적이고 통합적인 업무용 레지스트리. 검색 엔진처럼 UDDI에서 웹 서비스 정보를 검색해 사용함.

 

 

WSDL(Web Services Description Language)

웹 서비스를 기술하기 위한 표준 형식. 웹 서비스에서 제공되는 기능들의 사용 방법을 XML 기반으로 설명해주는 언어. 웹 서비스명, 제공 위치, 메시지 포맷, 프로토콜 정보 등 웹 서비스에 대한 상세 정보를 기술한 파일.

 

 

릴리즈 노트

소프트웨어와 함께 배포되어 최종 사용자에게 전달되는 문서. 소프트웨어의 정보와 변경 사항을 기록, 설명함. 전체적인 버전 관리를 체계적으로 관리할 수 있다. 

 

 

화이트박스(White Box) 테스트

모든 소스 코드의 논리적인 경로를 테스트 케이스로 설계하는 방법. 코드의 제어 구조 설계 절차에 초점을 맞춰 테스트 케이스를 설계함. 테스트 과정 초기에 진행하는 테스트. 소스 코드의 모든 문장을 한 번 이상 테스트 수행하며, 선택/반복 등의 분기점을 테스트한다. 

 

기초경로 테스트, 제어구조 검사등을 수행함.

 

제어 구조 검사

• 조건 검사 : 소스 코드의 논리적 조건을 테스트
• 루프 검사 : 소스 코드의 반복 구조를 중점적으로 테스트
• 데이터 흐름 검사 : 소스 코드의 변수 정의, 사용을 중점적으로 테스트

 

블랙박스(Black Box) 테스트

개념 :명세서를 기반으로 구현된 기능을 테스트 케이스로 설계하는 방법, 소프트 웨어 인터페이스에서 실행되며 기능 테스트라고 함. 기능 / 인터페이스 / 데이터 접근 / 성능 오류를 발견하기 위해 테스트 후반부에 적용.

 

블랙박스 테스트 종류

• 동치(동등) 분할 검사(Equivalence Partitioning Testing) : 입력 조건에 유효한 값과 무효한 값을 균등하게 하여 테스트 케이스를 설계함
• 경계값 분석(Boundary Value Analysis) : 입력 조건의 경계에서 오류가 발생할 확률이 높다는 점을 이용해 입력 조건의 경계값을 테스트 케이스로 설계함
• 원인-효과 그래프 검사(Cause-Effect Graphing Testing) : 입력 데이터간 관계와 출력에 미치는 영향을 분석해 효용성이 높은 테스트 케이스를 설계
• 오류 예측 검사(Error Guessing) : 과거의 경험이나 확인자의 감각에 의존하여 테스트 케이스를 설계
• 비교 검사(Comparison Testing) : 여러 버전의 프로그램에 동일한 테스트 자료를 제공해 테스트 하는 기법

 

 

V-모델

애플리케이션 테스트와 소프트웨어 개발 단계를 연결하여 표현한 것. 소프트웨어 개발 단계에 따라서 단위테스트, 통합테스트, 시스템테스트, 인수테스트 순으로 진행됨

 

 

 

 

단위 테스트(Unit Test)

코딩이 완료된 직후 소프트웨어 설계의 최소 단위인 모듈(함수, 프로시저 등)이나 컴포넌트에 초점을 맞춰 테스트하는 것. 모듈의 기능 수행 여부를 판정하고, 내부에 존재하는 논리적인 오류를 검출함. 

 

① 명세기반 테스트 : 목적 및 실행코드 기반의 블랙박스 테스트를 진행함.

 

② 구조기반 테스트 : 프로그램 내부 구조 및 복잡도를 검증하는 화이트박스 테스트를 진행함.

 

 

통합 테스트(Integration Test)

소프트웨어 각 모듈 간 인터페이스 관련 오류 및 결함을 찾아내기 위한 테스트 단계. 단위 테스트가 끝난 단위 프로그램이 설계 단계에서 제시한 구조 및 기능과 동일하게 구현되었는지에 대한 차이를 확인하는 단계.

 

① 하향식 통합 테스트 : 프로그램의 상위모듈에서 하위 모듈로 통합하면서 테스트 진행. 깊이 우선 통합법이나 넓이 우선 통합법을 사용해 아래 단계로 이동. 테스트 초기부터 사용자에게 시스템 구조를 시각화 할 수 있음. 주요 제어 모듈의 하위(종속) 모듈은 스텁(Stub)으로 대체함

 

② 상향식 통합 테스트 : 프로그램의 하위 모듈에서 상위 모듈로 통합하면서 테스트하는 기법. 주요 제어 모듈의 상위 모듈에 종속되어 있는 하위 모듈의 그룹을 클러스터로 결합하여 진행한다. 상위 모듈에서의 데이터 입출력을 확인하기 위한 더미 모듈(드라이버)를 사용. 

 

 

시스템 테스트(System Test)

개발된 소프트웨어가 해당 컴퓨터 시스템에 완벽하게 수행되는가를 점검하는 테스트. 

 

① 기능적 요구사항 : 시스템이 요구하는 기능과 서비스에 대한 요구사항. 명세서 기반의 블랙박스 테스트를 진행한다.

 

② 비기능적 요구사항 : 기능적 요구사항에서 다루지 못한 품질적 요소를 다룸. 객관적으로 측정 가능하고, 제약사항은 현실적으로 구현 가능한 수준이어야 함. 목적 기반 테스트는 기능이 품질 검증이므로 화이트 박스 테스트 진행

 

 

인수 테스트(Acceptance Test)

개발이 완료된 소프트웨어에 대해 사용자 요구사항 충족 여부를 사용자가 직접 테스트하는 것. 인수 테스트 단계에서 소프트웨어가 문제 없으면, 사용자는 소프트웨어를 인수하고 프로젝트 종료.

 

① 알파 테스트 : 개발자의 장소에서 사용자가 직접 테스트 진행. 통제된 환경에서 테스트 진행. 사용자와 개발자가 함께 확인하면서 테스트 기록.

 

② 베타 테스트 : 다수의 사용자에게 제한되지 않은 환경에서 프로그램을 오류 발견시 개발자에게 통보하는 방식의 테스트 방법

 

 

테스트 오라클(Test Oracle)

테스트 결과가 올바른지 판단하기 위해 사전에 정의된 참 값을 대입하여 비교하는 기법 및 활동. 결과를 판단하기 위해 테스트 케이스에 대한 예상 결과를 계산하거나 확인한다.

 

테스트 오라클 특징

① 제한된 검증 : 테스트 오라클은 모든 테스트 케이스에 적용할 수 없음.

 

② 수학적 기법 : 테스트 오라클의 기대값을 수학적 기법으로 산출

 

③ 자동화 기능 : 테스트 대상 프로그램의 실행, 결과 비교, 커버리지 측정 등을 자동화

 

 

테스트 오라클 종류

① 참(True) 오라클 : 모든 테스트 케이스의 입력 값에 대해 기대 결과를 제공하는 오라클로, 발생되는 모든 오류를 검출 할 수 있음.

 

② 샘플링(Sampling) 오라클 : 특정한 몇몇 테스트 케이스의 입력값들에 대해서만 기대 결과를 제공하는 오라클.

 

③ 추정(Heuristic) 오라클 : 샘플링 오라클을 개선한 오라클로, 특정 테스트 케이스의 입력값에 대한 기대 결과를 제공하고, 나머지 입력값들에 대해서는 추정으로 처리하는 오라클.

 

④ 일관성 검사(Consistent) 오라클 : 애클리케이션의 변경이 있을 때 테스트 케이스의 수행 전과 후의 결과 값이 동일한지를 확인하는 오라클.

 

 

정적 분석 도구(테스트 자동화 도구 유형)

프로그램을 실행하지 않고, 코딩 표준, 코딩 스타일, 코드 복잡도 및 기타 결함 등을 발견하기 위해 사용. 테스트를 수행하는 사람이 작성된 소스 코드를 이해하고 있어야만 분석이 가능.

 

 

성능 측정 지표

① 처리량(Throughput) : 정해진 시간에 처리할 수 있는 연산, 트랜잭션의 수

 

② 응답시간(Response Time) : 명령이 입력된 후 응답 출력이 개시될 때 까지의 시간.

 

③반환시간(Turnaroung Time) : 사용자가 데이터 및 명령을 입력한 시점부터 트랜잭션 처리 후 결과의 출력이 완료할 때 까지 걸리는 시간.

 

④ 자원 사용율(Resource Usage) : 트랜잭션을 처리하는 동안 사용하는 CPU 사용량, 메모리 사용량, 네트워크 사용량.

 

 

스키마(Schema)

데이터베이스의 구조와 제약조건에 대한 명세를 기술한 것. 데이터베이스를 구성하는 데이터 객체, 객체의 성질과 관계, 객체들이 가지는 데이터들의 관한 제약조건에 대한 정의를 총칭하는 것. 데이터베이스 관리 시스템의 특성과 구현 환경을 고려한 데이터 구조. 외부, 개념, 내부의 3단계 논리적 구조로 구성.

 

외부 스키마

프로그래머나 사용자의 입장에서 본 데이터베이스의 모습을 구현한 것. 특정 개인이나 특정 응용 프로그램에 한정된 논리적 데이터 구조. 일반적으로 View를 통해 데이터베이스 내용 중 사용자가 필요한 정보만 볼 수 있도록 함.

 

개념 스키마

모든 응용 프로그램과 사용자들이 필요로 하는 데이터베이스 전체를 정의한 것. 데이터에 대한 접근 권한, 보안 정책, 무결성 규칙들을 포함. 데이터를 통합한 조직 전체의 데이터베이스 구조를 논리적으로 정의한 것.

 

내부 스키마

물리적인 저장 장치의 입장에서 본 데이터베이스의 모습을 나타낸 것. 실제로 데이터베이스에 저장될 레코드의 형식을 정의하고 데이터 항목의 표현 방법, 내부 레코드의 물리적 순서 등의 데이터 처리에 대한 제약사항을 정의한 것.

 

 

데이터 모델링의 구성요소

① 논리적 구조 : 논리적으로 표현된 데이터 구조

 

② 연산 : 데이터 구조에서 삽입, 삭제, 변경하는 기능

 

③ 제약조건 : 데이터 구조에서 허용할 수 있는 관계를 명세

 

 

 

데이터 모델링 절차(개념적 설계, 논리적 설계, 물리적 설계)

 

① 개념적 설계

- 정보 내용에 대한 요구 조건을 만족시키면서 쉽게 이해할 수 있는 정보구조를 설계하는 단계. 

- 개체 타입간의 관계를 이용해 현실 세계를 표현하는 방법으로 E-R 모델이 대표적.

- 데이터 모델의 골격을 정의하는 상위 수준으 모델, 주요 개체 타입, 기존 속성, 관계, 주요 업무 기능등을 포함.

- 주제 영역을 도출해 해당 주제 영역의 핵심 개체를 추출하고 개체간 관계를 정의.

- 논리 데이터 모델의 기초가 됨. ERD(E-R Diagram)을 설계하는 단계

- 개념 스키마 모델링 : 요구 분석 단계에서 나온 결과를 데이터를 중심으로 ERD 등으로 DBMS에 독립적인 표현으로 명세하는 과정

 

② 논리적 설계

- 개념 데이터 모델을 상세화하여 논리적인 데이터 집합, 관리 항목, 관계를 정의하는 단계

- 전체 데이터 모델링 과정에서 가장 핵심이 되는 과정.

- 개념 데이터 모델에서 만들어진 개념적 구조를 컴퓨터에 저장할 수 있는 논리적 구조로 변환하는 단계

- 목표 DBMS에 맞는 데이터베이스 스키마 및 트랜잭션 인터페이스를 설계.

- 비즈니스 영역 업무 데이터 및 규칙을 구체적으로 표현한 모델. 모든 업무용 개체, 속성, 관계, 프로세스 등을 포함.

- 관계 표현 방법에 따라 RDBMS, HDBMS, NDBMS로 나뉨.

- 모든 업무 데이터를 정규화하여 모델링 함.

- 논리적 설계 3단계
    1) 논리적 데이터베이스 구조로 매핑
    2) 트랜잭션 인터페이스를 설계
    3) 스키마의 평가 및 최적화

 

③ 물리적 설계

- 논리 데이터 모델을 DBMS의 특성 및 성능을 최대한 고려하여 구체화 하는 단계

- 논리 데이터 모델을 바탕으로 데이터베이스에 포함될 저장 레코드 양식, 데이터 구조, 응답 시간, 저장 공간 등을 설계

- 물리적 설계 3단계
    1) 레코드 분석 및 형식 설계
    2) 저장 레코드 등을 클러스터링
    3) 접근 경로 설계

 

 

이상 현상(Anomaly)

잘못된 스키마 설계로 인해 릴레이션에 예기치 못한 현상이 발생된 경우

 

① 삭제 이상 : 특정 튜플을 삭제할 때, 관련된 정보도 함께 삭제하지 않으면 삭제가 불가능한 상태.

② 삽입 이상 : 특정 튜플을 삽입할 때, 관련되지 않은 정보도 함께 삽입하지 않으면 삽입이 불가능한 상태.

③ 갱신 이상 : 특정 데이터를 갱신할 때, 데이터의 불일치가 발생하는 상태

 

 

정규화(Normalization)

- 데이터 모델링의 단계 중 가장 중요한 단계. 논리 데이터 모델링을 상세화 하는 단계.

- 정확성, 일치성, 단순성, 비중복성, 안정성 보장하는 단계

- 하나의 릴레이션에 하나의 의미만 존재할 수 있도록 릴레이션을 분해하는 과정. 

 

정규화 목적

- 중복되는 튜플 없이 효과적인 데이터 표현 및 저장이 가능하도록 구성.

- 비교적 간단한 연산자로 효과적인 연산이 가능하도록 구성.

- 새로운 데이터에 의해 릴레이션이 영향을 받지 않도록 구성.

- 데이터 검색과 추출 등의 효율성을 높여 DBMS의 성능 향상에 기여하도록 구성. 

 

정규화 필요성

- 저장 공간을 최소화

- 불일치 최소화

- 자료구조 안정화

- 이상현상 방지

 

정규화 과정 *

① 비정규형 : 정규화가 전혀 진행되지 않은 상태

② 제1정규형 : 도메인이 원자값만 가지도록 분해한 상태

③ 제2정규형 : 부분 함수 종속을 제거한 상태

④ 제3정규형 : 이행적 함수 종속을 제거한 상태

⑤ 보이스 코드 정규형 : 결정자가 후보키가 아닌 종속을 제거한 상태

⑥ 제4정규형 : 다치 종속을 제거한 상태

⑦ 제5정규형 : 후보키를 통하지 않은 조인종속을 제거한 상태

 

 

데이터 정의어(DDL)

 - 논리적, 물리적인 데이터베이스를 정의하거나 수정할 목적으로 사용하는 명령어

 - 테이블의 구조를 정의하거나 수정할 목적으로 사용하는 명령어

 - 데이터베이스 관리자(DBA)가 사용하는 언어

 - 명령어가 수행되면 이전 상태로 돌릴 수 없음

 

 

데이터 조작어(DML)

 - 데이터를 검색, 삽입, 갱신, 삭제 할 수 있도록 지원하는 명령어

 - 사용자와 DBMS간 인터페이스 제공

 - 일반 사용자 및 응용 프로그래머가 사용하는 언어

 - 트랜젝션 제어어로 실행전 상태로 복귀 가능한 명령어

 

 

데이터 제어어(DCL)

 - 여러 사용자가 데이터를 공유할 수 있도록 병행 제어를 수행하는 명령어

 - 데이터 무결성을 유지하면서 여러 규정이나 제약조건등을 기술하기 위한 명령어

 - 사용자별로 데이터베이스에 접근할 수 있는 권한을 부여하거나 회수하여 보안을 유지하는 명령어

 - 데이터 베이스 관리자가 사용하는 언어

 

 

트랜잭션(Transaction)

 - 한 개 이상의 데이터베이스를 조작하는 논리적인 연산의 집합.

 - 하나 이상의 SQL을 포함

 - 분해할 수 없는 최소 단위의 작업. 회복의 기준

 

 

트랜잭션 특징 [원 일 고 지]

① 원자성 : 트랜잭션의 연산은 모두 실행되거나 모두 실행되지 않아야 함.

 

② 일관성(무결성) : 트랜잭션을 마친 후 동일하게 오류가 발생되지 않아야 함.

 

③ 고립성(독립성) : 트랜잭션 실행 중 다른 트랜잭션에 영향을 받지 않아야 함

 

④ 지속성(영속성) : 트랜잭션의 결과는 항상 유지, 보존되어야 함

 

 

회복 즉시갱신 vs 지연갱신

① 즉시 갱신 : 트랜잭션의 결과를 그 즉시 데이터베이스에 반영. 문제가 발생하면 로그에 있는 갱신 이전의 데이터로 데이터베이스를 복원하여 회복

 

② 지연 갱신 : 갱신 결과를 로그에 기록해 두었다가 트랜잭션이 완료되면 한 번에 데이터베이스에 반영

 

 

파티션닝(partition)

대용량의 테이블을 논리적인 단위의 작은 테이블로 나누어 성능 저하 방지 및 관리를 용이하게 하는 것.

 

파티션 유형

① 범위(Range) 분할 : 지정한 칼럼 값을 기준으로 분할

 

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

 

③ 조합(Composite) 분할 : 범위 분할 후 해시 분할로 다시 분할

 

④ 목록(List) 분할 : 분할할 항목을 관리자가 직접 지정

 

 

반정규화(De-Normalization)

정규화된 엔티티, 속성, 관계를 시스템의 성능 향상과 개발 운영의 단순화를 위해 중복, 통합, 분리 등을 수행하는 데이터 모델링 기법. 완벽한 수준의 정규화를 진행하면 일관성, 안전성은 증가할지 모르지만, 성능이 느려질 수 있기 때문에 성능 향상을 위해 릴레이션을 통합, 분할, 추가하는 과정.

 

 

분산 데이터베이스 관리 시스템 목표

① 위치 투명성(Location Transparency) : 액세스 하려는 데이터베이스의 실제 위치를 알 필요 없이 데이터베이스의 논리적 명칭만으로만 액세스할 수 있는 성질. 

 

② 중복 투명성(Replication Transparency) : 중복된 데이터 유무와 저장 위치 등에 대한 정보를 사용자가 인지할 필요가 없어야 한다는 성질

 

③ 분할 투명성(Fragmentation Transparency) : 전역 스키마가 어떻게 분할되어 있는지 알 필요 없이 전역 질의를 여러 개의 단편 질의로 변환해 주는 성질. 

 

④ 장애 투명성(Failure Transparency) : 분산된 물리적 환경에서 특정 시스템이나 네트워크에 장애가 발생해도 데이터 무결성이 보장되는 성질

 

⑤ 병행 투명성(Concurrency Transparency) : 분산 데이터베이스와 관련된 다수의 트랜잭션들이 동시에 실현되더라도 그 트랜잭션의 결과는 영향을 받지 않는다는 성질

 

 

데이터 웨어하우스(Data Warehouse)

정보의 효율적인 분석과 신속한 비즈니스 의사결정을 위한 데이터베이스 환경. 기업의 정보 자산을 효율적으로 활용하기 위한 하나의 패러다임. 데이터의 시계열적 축적과 통합을 목표로 하는 기술의 구조적, 통합적 환경.

 

 

데이터 마이닝(Data Mining)

방대한 데이터 속에서 상관관계를 분석하고, 데이터 웨어하우스에서 유용하고 가능성 있는 정보 및 정보간 패턴을 발견하기 위한 기법.

 

 

하둡(Hadoop)

오픈소스 기반의 분산 컴퓨팅 플랫폼. 일반 PC들로 가상화된 대형 스토리지를 형성함. 필수 핵심 구성요소로 맵리듀스와 하둡 분산 파일 시스템을 포함. 

 

 

 

2020년 개정 정보처리기사 실기 족보 정리 (2)

 

2020년 개정 정보처리기사 실기 족보 정리 (3)