201. 애자일 방법론
- XP (eXtreme Programming)
- 의사소통 개선과 즉각적인 피드백에 의한 단순한 코딩으로 SW 품질을 높이기 위한 방법론
- 1~3주 반복 (iteration)
- 5가지 가치 : 용기, 단순성, 의사소통, 피드백, 존경
- 12개 실천 항목
- SCRUM
- 매일 정해진 시간에 정해진 장소에서 짧은 시간의 개발을 하는 팀을 위한 프로젝트 관리 중심의 방법론
- 30일마다 동작 가능한 제품을 제공하는 스프린트를 중심으로 하고 있음
- 백로그 : 제품과 프로젝트에 대한 요구사항
- 스프린트 : 30일 단위의 짧은 개발 기간으로 분리하여 반복적 수행
- 스크럼 미팅 : 매일 스크럼 미팅으로 (15정도) 오늘과 내일의 해야 할 일의 계획 수립
- 스크럼 마스터 : 프로젝트 리더, 스크럼 수행 시 문제 인지 및 이를 해결하려고 노력하는 사람
- Lean
- 린 시스템의 품질 기법을 소프트웨어 개발 프로세스에 적용하여 프로세스의 낭비 요소를 제거 후 결과를 측정, 성과를 분석하여 소프트웨어의 품질을 향상 시키는 개발 방법론
- 7가지 원칙 : 낭비 제거, 품질 내재화, 지식 창출, 늦은 확정, 빠른 인도, 사람 존중, 전체 최척화
- FDD (Feature Driven Development)
- 개발을 상품이나 서비스 단위가 아니라 신규 기능 단위로 하는 개발방법론
- 기능별로 수행해야 하는 매우 구체적이고 짧은 단계의 작업
- 하나의 기능 개발을 위해 전체 팀에서 필요한 내용을 중재하고 전체 시스템의 흐름을 정의할 수 있는 아키텍트의 역할 필요
- 각 개발 컴포넌트별 코디네이션이 중요
- feature 마다 2주 정도의 반복 개발 실시
- Peter Coad가 제창한 방법론
- UML을 이용한 설계 기법과도 밀접한 관련이 있음
202. 요구사항 명세 기법
- 정형 명세 기법
- 기법 : 수학적 기반, 모델링 기반
- 종류 : Z, VDM, Petri-Net (모형 기반), CSP, CCS, LOTOS (대수적 방법)
- 장점 : 시스템 요구 특성 명확, 명세 간결, 명세/구현의 일치성
- 단점 : 낮은 이해도, 이해 관계자의 부담 가중
- 비정형 명세 기법
- 기법 : 상태, 기능, 객체 중심 명세 기법
- 종류 : FSM (Finite state machine), Decision Table, ER 모델링, State Chart (SADT), UseCase-사용자 기반 모델링
- 장점 : 명세작성 이해 용이, 의사전달 방법 다양성
- 단점 : 불충분한 명세 기능, 모호성
204. CASE 도구
- CASE 도구의 개념
- 계획수립에서부터 요구분석, 설계, 개발, 유지보수에 이르는 소프트웨어 생명주기 전 과정을 자동화할 수 있도록 지원하는 자동화 도구
- 1970년대부터 현재까지 지속적으로 발전하고 있으며, 등장 배경에 따르면 소프트웨어 산업 측면에서는 소프트웨어 위기 극복 방안으로 등장하게 되었고, 정보시스템 관리 측면에서는 요구사항의 관리 효과 극대화, 재사용성 및 생산성 확대를 위해 등장
- CASE 도구의 분류
- Upper CASE : 계획수립, 요구분석, 기본설계 단계를 지원, 다이어그램으로 표현
- Middle CASE : 상세 설계 작업을 지원, 화면 / 출력 등의 작성을 지원
- Lower CASE : 시험, 유지보수 작업을 지원, 소스코드와 시스템 명세서를 획득
- I-CASE : 위 세 가지의 통합, Rational ROSE, COOL 등이 국내에서 사용
- CASE 도구의 구성
- Diagram 작성 도구 : 소프트웨어 명세서 정의, 설계 결과의 표현
- 설계 분석기 : 설계 명세서의 정확성, 일치성, 모호성에 대한 검사
- 코드 생성기 : 명세서로부터 프로그래밍 언어로 된 모듈의 코드 생성
- Repository : CASE 도구의 중심, SDLC동안 정보 저장
- 프로젝트 관리 지원 도구
- 재공학 도구 : 기존 시스템의 설계 명세서 작성 지원
- Prototyping 도구 : 초기 UI 작성 지원
207. 객체지향 설계 원칙
- 단일 책임 원칙
- 클래스의 메서드가 해야 하는 것, 할 수 있는 것, 해야 하는 것을 잘할 수 있는 것으로 여러 개의 작업을 많이 할당하지 말아야 한다는 원칙
- 객체는 주어진 작업을 다른 객체가 아닌 자신만이 수행할 수 있어야 함
- 해당 원칙을 준수하게 되면 응집도는 높아지고, 결합도는 낮아지게 됨
- 개방 폐쇄의 원칙
- 기존의 코드를 변경하지 않으면서 기능을 추가할 수 있어야 함
- 클래스를 변경하지 않고도 그 클래스를 둘러싼 환경을 변경할 수 있는 설계가 되어야 함
- 클래스 자체를 변경하지 않고도 둘러싼 환경을 바꿀 수 있도록 설계해야 한다는 원칙
- 리스코프 교체의 원칙
- 부모 클래스와 자식 클래스 사이의 행위가 일관성이 있어야 함
- 부모 클래스의 인스턴스를 자식 클래스의 인스턴스로 대체해도 프로그램의 의미는 변화되지 않음
- 서브타입은 언제나 자신의 기반 타입으로 교체할 수 있어야 한다는 원칙
209. 소프트웨어의 사용자 인터페이스 개발 시스템
- 소프트웨어 개발 현장 : 생산성 향상을 위해 상용 및 오픈소스 기반의 다양한 사용자 인터페이스 개발 도구를 활용
- 사용자 인터페이스 요소 (화면 구성 컴포넌트 : Input Box, Select Box, Check Box, Text Box, Radio Button, Button 등)들의 입력 값에 대해 검증할 수 있어야 함
- 적절한 필터링 기능을 통해 에러 및 에러 메시지를 처리할 수 있어야 함
- 사용자 인터페이스 개발을 위해 도움 기능과 프롬프트 기능을 제공해야 함
- 개발 생산성 향상을 위해 다양한 기능을 제공하므로 UI 개발 시스템의 기능을 일반화하거나 특정한다는 것이 무의미할 수도 있을 것
- 소스코드 분석 및 오류 복구 기능 : Back-End 프로그램의 컴파일러가 하는 역할 - 사용자 인터페이스 개발 시스템의 기능과는 거리가 멈
213. 자료사전
- 자료 사전의 개념
- 자료 흐름도의 대상이 되는 모든 자료에 대한 기본 사항을 더 자세히 정의하기 위해 사용되는 도구
- 자료 사전 기호를 사용하여 자료들에 대한 규칙을 정함
- 자료 흐름을 구성하는 자료 항목, 자료에 대한 의미, 자료 저장소를 구성하는 자료 항목, 자료 원소의 단위 및 값을 가지고 있음
- 자료 사전 기호
- = : 자료 정의 - A는 ~로 구성되어 있다
- + : 자료의 연결 - A와 B의 연결
- ( ) : 자료의 생략 - 없어도 되는 자료
- [ | ] : 자료의 선택 - A 이거나 B
- { } : 자료의 반복
- ** : 자료의 설명
- 자료 사전 작성 시 고려할 사항
- 갱신하기 쉬워야 함
- 이름으로 정의를 쉽게 찾을 수 있어야 함
- 정의하는 방식이 명확해야
214. XP의 12가지 실천사항
- Planning game (Planning Process)
- 사용자 스토리를 이용해서 다음 릴리즈의 범위를 빠르게 결정
- 비즈니스 우선순위와 기술적 평가 결합
- Small/Short releases
- 필요한 기능들만 갖춘 간단한 시스템을 빠르게 릴리즈
- 고객이 소프트웨어가 어떻게 돌아가는지 아주 짧은 (약 2주) 사이클로 볼 수 있도록 자주 새로운 버전 배포 유지
- Metaphor
- 공통의 name system (의사 소통 및 공통 개념 공유)
- 전체 개발 프로세스에 걸쳐서 시스템의 동작에 대한 전체 그림을 표현하는 것, 이해하기 쉬운 스토리로 이루어짐
- Simple Design
- 당장 필요하지 않은 디자인 배제
- 항상 가능한 가장 간결한 디자인 상태 유지
- TDD (Test Driven Development)
- 개발자 먼저 단위 테스트, 실제 코드를 작성하기 전에 먼저 작성함으로써 자신이 무엇을 해야하는지 스스로 깨우침
- 고객은 기능 테스트를 작성하여 요구사항이 모두 반영되었는지를 확인
- Refactoring (Design Improvement)
- 프로그램 기능은 변경 없이 중복/복잡성 제거, 커뮤니케이션 향상, 단순화, 유연성 추가 등을 통해 시스템 재구성
- Pair Programming
- 두 사람이 함께 프로그램 (Driver / Partner)
- 모든 프로그래밍은 하나의 컴퓨터에 2명의 프로그래머가 같이 공동작업 진행
- Collective Code Ownership
- 팀의 모든 프로그래머가 소스코드에 대해서 공동 책임을 지는 것
- 시스템에 있는 코드는 누구든지 언제라도 수정 가능
- CI (Continuous Integration)
- 컴포넌트 단위로 혹은 모듈 단위로 나누어서 개발된 소스코드들은 하나의 작업이 끝날 때마다 지속적으로 통합되고 동시에 테스트
- 40-hour week (Sustainable Pace)
- 일주일에 40시간 이상을 일하지 말도록 규칙으로 정하고 2주를 연속으로 오버타임하지 않도록 함
- Whole Team
- 개발 효율성을 위해 고객을 프로젝트에 상주시킴
- 고객은 스토리를 명확하게 해주고, 중요한 비즈니스 결정사항에 대해 명확한 답을 제공해주는 역할
- Coding Standard
- 팀원들 간 커뮤니케이션을 향상시키기 위해서는 코드가 표준화된 관례에 따라 적성되어야 함
215. DFD (자료 흐름도)
- 자료 흐름도의 개념
- 자료 흐름 그래프, 버블 차트
- 도형화된 도구를 이용해 정형화된 분석 절차에 따라 사용자 요구사항을 파악하고 문서화하는 분석 기법
- 시스템의 처리 과정을 자료의 흐름에 중점을 두어 기술하는 분석용 도구
- 시각적으로 업무, 데이터의 흐름을 쉽게 볼 수 있어 프로그램 구현에 도움이 됨
- 자료 흐름도의 구성 요소
- 처리 (process)
- 입력된 자료를 출력으로 변환하는 것
- 프로세스
- 원 안에 처리 명칭을 기술
- 자료 흐름 (data flow)
- 발생지, 종착지, 처리 및 저장소 사이에서 자료의 흐름을 나타냄
- 화살 표 위에 자료의 명칭 기술
- 자료 저장소 (data store)
- 시스템 상의 자료 저장소를 나타냄
- 평행 선 안에 자료 저장소 명칭을 기술
- 단말기 (terminator)
- 시스템에 필요한 자료가 입력되는 발생지와 시스템에서 처리된 자료가 출력되는 종착지 또는 외부에 존재하는 사람이나 조직을 나타냄
- 사각형 안에 발생지나 종착지 명칭 기술
- 처리 (process)
216. 코드화 방법의 종류
- 표의(유의) 숫자 코드 (Significant Digit Code)
- 대상 자료의 물리적인 수치 값, 중량, 면적, 용량, 거리, 광도 등을 코드에 적용시켜 코드화하는 방법 (유효 숫자 코드)
- 장점 : 항목코드에 의미를 없앤 수치만 넣어 기억하기 쉬움
- 단점 : 항목의 자릿수가 많아 전산 처리에 불편
- 블록 코드 (구분 코드) (Block Code)
- 공통성이 있는 것끼리 블록으로 구분
- 각 블록 내에서 일련번호를 부여하는 방법
- 적은 자릿수로 많은 항목을 표시할 수 있음
- 예비코드를 사용할 수 있어 항목의 추가가 용이
- 공통된 특성별로 분류 및 집계 용이
- 장점 : 짧은 자릿수로 다양하고 많은 내용을 구분해서 표시 가능, 추가가 용이
- 단점 : 코드가 커지면 코드 관리가 어려움
- 순서 코드 (Sequence Code)
- 코드화 대상 항목을 어떤 일정한 배열로 일련 번호를 배당하는 코드
- 항목 수가 적고 장래에 다시 작성하는 일이 없는 항목에 적합한 코드화 방법
- 자료의 가나다 순, 크기순, 발생순, 높이순 등 일정 순서대로 코드를 부여하는 가장 단순한 방법
- 장점
- 단순하고 이해하기 쉬움
- 발생 순서대로 코드 부여시 확장성이 좋음
- 자릿수가 짧으며 공간의 낭비가 적고 뒷부분에 추가 가능
- 단점
- 명확한 분류 기준이 없음 : 코드 분류가 어려움
- 누락된 자료 삽입이 어려움 : 융통성이 적음
- 중간 자료의 삭제가 어렵고 항목 수가 많을 경우 코딩이 어려움
- 10진 분류 코드 (Decimal Code)
- 그룹 분류 코드를 응용하여 코드화 대상 항목을 분류하고 번호를 부여
- 10진수만을 코드 번호로 사용함으로서 각 분류마다 한 자리만 허용
- 장점 : 무한대로 확장 가능, 추가가 쉬움
- 단점 : 자릿수가 길어지면 코드 크기 추정이 어려워 비효율적
- 그룹 분류 코드 (Group Classification Code)
- 대상 항목을 분류 기준에 따라 대/중/소 분류로 나누고 각 분류 안에서 번호를 순차적으로 부여 (각 자릿수가 특정한 의미를 가짐으로 분류 기능이 좋음)
- 장점 : 각 자릿수가 특정한 의미를 가짐으로 분류 기능이 좋아 전산 처리에 가장 적합
- 단점 : 코드 자릿수가 증가하면 효율성이 떨어짐
- 블록 순서 코드 (Block Sequence Code)
- 코드화 할 대상의 공통 특징을 중심으로 그룹(집단)으로 분류하고 그룹(집단) 안에서 순서대로 번호를 부여
- 끝자리 분류 코드 (Final Digit Code)
- 필요한 분류 기능을 기존 코드로 수행하기 어려운 경우에 사용
- 코드 끝에 한 자리를 추가하여 항목을 분류
- 연상 코드 (Mnemonic Code)
- 코드 값을 보면 어떤 대상을 의미하는지 연상할 수 있게 코드를 부여, 대상의 약어를 코드에 포함시킴
- 지명, 나라, 제품 이름, 회사 이름 등에 주로 사용
- 코드화 대상의 명칭이나 약어 등을 코드에 일부를 넣어서 대상을 외우기 쉽도록 생성하는 코드
- 합성 코드 (combined Code)
- 두 개 이상의 코드를 조합하여 만든 코드 방식
- 대상의 의미를 정확하고 빠르게 전달하기 위하여 다른 코드 체계를 보조
218. 소프트웨어의 설계 구조
- 상위 설계
- 아키텍처 설계
- 예비 설계
- 인터페이스 정의 : 시스템 수준에서의 소프트웨어 구성 컴포넌트들 간의 관계로 구성된 시스템의 전체적인 구조와 시스템 구조도
- 사용자 인터페이스 설계 : 외부 파일 및 DB 설계도 (레코드 레이아웃, ERD), 화면 및 출력물 레이아웃 등
- 하위 설계
- 모듈 설계 (상세 설계)
- 자료 구조 설계 : 시스템의 각 구성 요소들의 내부 구조, 동적 행위 등을 결정
- 알고리즘 설계 : 각 구성 요소의 제어와 데이터들 간의 연결에 대한 구체적인 정의를 하는 것
219. 아키텍처 패턴
- 파이프-필터 패턴 (Pipe-filter pattern)
- 데이터 스트림을 생성하고 처리하는 시스템에서 사용할 수 있음
- 각 처리 과정은 필터 컴포넌트에서 이루어지며, 처리되는 데이터 파이프를 통해 흐름
- 파이프는 버퍼링 또는 동기화 목적으로 사용될 수 있음
- 연속한 필터들은 어휘 분석, 파싱, 의미 분석, 그리고 코드 생성을 수행
- 계층화 패턴 (Layered pattern)
- N-티어 아키텍처 패턴
- 하위 모듈들의 그룹으로 나눌 수 있는 구조화된 프로그램에서 사용할 수 있음
- 각 하위 모듈들은 특정한 수준의 추상화를 제공
- 각 계층은 다음 상위 계층에 서비스를 제공
- 일반적인 정보 시스템에서 공통적으로 볼 수 있는 계층 4가지
- 프레젠테이션 계층 (Presentation layer) : UI 계층
- 애플리케이션 계층 (Application layer) : 서비스 계층
- 비즈니스 논리 계층 (Business logic layer) : 도메인 계층
- 데이터 접근 계층 (Data access layer) : 영속 계층
- 모델-뷰-컨트롤러 패턴 (Model-View-Controller pattern)
- MVC 패턴
- 대화형 애플리케이션의 3 부분으로 나누어 구성
- 모델 : 핵심 기능과 데이터를 포함
- 뷰 : 사용자에게 정보를 표시 (하나 이상의 뷰가 정의될 수 있음)
- 컨트롤러 : 사용자로부터 입력을 처리
- 정보가 사용자에게 제공되는 방식과 사용자로부터 받아들여지는 방식에서 정보의 내부적인 표현을 분리하기 위해 나뉘며, 이는 컴포넌트를 분리하며 코드의 효율적인 재사용을 가능케 함
- 브로커 패턴 (Broker pattern)
- 분리된 컴포넌트들로 이루어진 분산 시스템에서 사용
- 컴포넌트들은 원격 서비스 실행을 통해 서로 상호 작용을 할 수 있음
- 브로커 컴포넌트는 컴포넌트 간의 통신을 저정하는 역할
- 서버는 자신의 기능들(서비스 및 특성)을 브로커에 넘겨주고, 클라이언트가 브로커에 서비스를 요청하면 브로커는 클라이언트를 자신의 레지스트리에 있는 적합한 서비스로 리디렉션
- 피어 투 피어 패턴 (Peer-to-peer pattern)
- 피어 : 각 컴포넌트, 클라이언트로서 피어에게 서비스를 요청할 수도 있음
- 서버로서 각 피어에게 서비를 제공할 수도 있음
- 클라이언트 또는 서버 혹은 둘 모두로서 동작할 수 있음
- 시간이 지남에 따라 역할이 유동적
- 이벤트-버스 패턴 (Event-bus pattern)
- 이벤트를 처리
- 이벤트 소스, 이벤트 리스너, 채널, 이벤트 버스의 4가지 주요 컴포넌트들을 갖음
- 소스는 이벤트 버스를 통해 특정 채널로 메시지를 발행
- 리스너는 특정 채널에서 메시지를 구독, 이전에 구독한 채널에 발행된 메시지에 대해 알림을 받음
- 클라이언트-서버 패턴 (Client-server pattern)
- 하나의 서버와 다수의 클라이언트로 구성
- 서버 컴포넌트는 다수의 클라이언트 컴포넌트로 서비스를 제공
- 클라이언트가 서버에 서비스를 요청하면 서버는 클라이언트에게 적절한 서비스를 제공하며 서버는 계속 클라이언트로부터의 요청을 대기
- 마스터-슬레이브 패턴 (Master-slave pattern)
- 마스터와 슬레이브로 구성
- 마스터 컴포넌트는 동등한 구조를 지닌 슬레이브 컴포넌트들로 작업을 분산
- 슬레이브가 반환한 결과 값으로부터 최종 결과 값을 계산
225. 네트워크 영역에 적용되는 보안 프로토콜
- IPSec
- 통신 세션의 각 IP패킷을 암호화하고 인증하는 안전한 인터넷 프로토콜 통신을 위한 인터넷 프로토콜 스위트
- 통신 세션의 개별 IP 패킷을 인증하고 암호화함으로써 처리
- SSL
- 전송 계층 보안
- 컴퓨터 네트워크에 통신 보안을 제공하기 위해 설계된 암호 규약
- 인터넷과 같이 TCP/IP 네트워크를 사용하는 통신에 적용
- 통신 과정에서 전송 계층 종단간 보안과 데이터 무결성 확보
- 3.0 버전부터 TLS로 표준화
- S-HTTP
- 웹상에서 네트워크 트래픽을 암호화하는 주요 방법 중 하나
229. 인터페이스 구현 검증 도구
- xUnit : Java(Junit), C++(Cppunit), .Net(Nunit) 등 다양한 언어를 지원하는 단위 테스트 프레임
- STAF : 서비스 호출, 컴포넌트 재사용 등 다양한 환경을 지원하는 테스트 프레임 워크
- FitNesse : 웹 기반 테스트 케이스 설계, 실행, 결과 확인 등을 지원하는 테스트 프레임 워크
- NTAF : Naver 테스트 자동화 프레임 워크, STAF와 FitNesse를 통합
- Selenium : 다양한 브라우저 지원 및 개발 언어를 지원하는 웹 애플리케이션 테스트 프레임 워크
- watir : Ruby 기반 웹 애플리케이션 테스트 프레임 워크
231. 데이터 독립성을 위한 3단계 스키마 구조
- 외부 스키마 (External Schema)
- 각 사용자나 응용 프로그래머가 접근하는 데이터베이스
- 하나의 데이터베이스에 여러 개의 외부 스키마 존재 설명
- 특징 : 여러 개 존재, 서브 스키마, 뷰
- 개념 스키마 (Conceptual Schema)
- 범 기관적 입장에서 데이터베이스
- 모든 응용시스템과 사용자 필요로 하는 데이터를 통합한 데이터베이스
- 모든 개체, 관계, 제약조건, 접근 권한, 보안, 무결성 규칙 포함
- 특징 : 하나만 존재
- 내부 스키마 (Internal Schema)
- 저장 장치 측면에서의 데이터베이스 저장 구조
- 내부 레코드 형식, 인덱스 유무, 내부 레코드 순서 등
- 특징 : 물리적 스키마
232. 트리 순회 방법
- 전위 순회 (Pre-Order) : (Root), Left, Right
- 중외 순회 (In-Order) : Left, (Root), Right
- 후위 순회 (Post-Order) : Left, Right, (Root)
235. 빌드 자동화 도구
- Jenkins의 특징
- 쉬운 설치 : Jenkins, war 파일로 제공. "java -jar jenkins.war" 명령어로 설치 끝
- 친숙한 GUI : 웹기반 GUI를 통해 쉽게 전체적인 설정 변경이 가능, 잘못된 내용은 바로 체크하여 inline help를 제공
- 저장소 부하 감소 : 버전 관리 도구에서 빌드에 사용될 목록만 따로 추출하여 변경 생성할 수 있는 기능을 제공, 전체 빌드로 인한 저장소 부하 감소 가능
- 실시간 피드백 : RSS 또는 e-mail을 통해 실시간으로 빌드 실패 내역에 대해 담당자에게 통지 가능
- 분산 빌드 : 여러 대의 컴퓨터를 통해 분산 빌드나 테스트가 가능
- 3rd party 플러그인 : 젠킨스는 타 도구의 통합을 지원, 데이터베이스 / 개발도구와의 통합, 테스트 도구와의 통합
- Gradle 의 특징
- 오픈 소스
- 여러 가지 언어의 빌드 환경을 구성할 수 있음
- 주로 안드로이드 개발 환경에서 빌드 자동화 도구로 사용
- C++, Swift, Objective- C, Haskell, Scala 등의 언어도 플러그인을 설정하면 빌드가 가능
- groovy를 사용해서 만든 DSL
- 스크립트 : Projects와 tasks로 구성
- 빌드는 하나 이상의 projects로 구성, 각 project는 하나 이상의 task들로 구성
238. 해싱 함수 기법
- 계수 분석 : 키 값을 구성하는 숫자의 분포를 파악하여 분포가 비교적 고른 자리부터 필요한 자리만큼 선택하여 레코드 주소를 결정하는 방법
- 제산법 : 키를 임의의 양의 정수로 나눈 나머지를 그 키의 레코드를 저장하는 주소로 결정하는 방법
- 중간 제곱법 : 키 값을 제곱한 값의 중간 부분 값을 선택하여 레코드 주소로 결정하는 방법
- 폴딩법 (중첩법) : 키를 여러 부분으로 나누고 나누어진 각 부분의 값을 모두 더하거나 보수를 취해 더하여 레코드 주소를 결정하는 방법, 길이를 동일하게 여러 부분으로 나누고 더하거나 XOR하여 주소 이동
- 기수 변환 : 주어진 키 값을 어떤 특정한 진법의 수로 간주하여 다른 진법으로 변환한 후 레코드 주소를 구하는 방법
- 숫자 분석 : 각 숫자의 분포를 이용해서 균등한 분포의 숫자를 선택해서 사용하는 방법
- 무작위 방법 : 난수를 발생, 탐색을 위한 해시의 경우 충돌이 발생하면 다음 난수를 이용 방법
242. CRUD 매트릭스
- CRUD 매트릭스의 개념
- 프로세스와 엔티티의 상관관계를 이용하여 구축된 데이터베이스 시스템을 검증하는 방법
- CRUD 매트릭스의 분석 절차
- 모든 엔티티 목록을 나열하고 각각의 프로세스가 해당 엔티티에 대하여 생성(C), 조회(R), 변경(U), 삭제(D) 하는가에 대한 여부 표기
구분 엔티티(1) 엔티티(2) 엔티티(3) 엔티티(4) 프로세스(1) C RUD 프로세스(2) R C 프로세스(3) RU C R 프로세스(4) R RUD C
- 모든 엔티티 목록을 나열하고 각각의 프로세스가 해당 엔티티에 대하여 생성(C), 조회(R), 변경(U), 삭제(D) 하는가에 대한 여부 표기
- CRUD 매트릭스 작성 후 점검 항목
- 모든 엔티티 타입에 CRID가 한 번 이상 표기되었는가
- 모든 엔티티 타입에 C가 한 번 이상 존재하는가
- 모든 엔티티 타입에 R이 한 번 이상 존재하는가
- 모든 단위 프로세스가 하나 이상의 엔티티 타입에 표기가 되었는가
- 두 개 이상의 단위 프로세스가 하나의 엔티티 타입을 생성하는가 -> 로직의 검토 대상
245. 정규화
- 관계형 데이터베이스 설계 시 중복을 최소화하도록 데이터를 구조화하는 프로세스로 제대로 조직되지 않은 테이블들과 관계들을 작고 잘 조직된 테이블과 관계들로 나누는 무손실 분해를 포함
- 정규화의 수행 목적
- 하나의 테이블에서의 데이터 삽입, 삭제, 변경이 정의된 관계들로 인하여 데이터베이스의 나머지 부분들로 전파되게 하는 것
- 어떤 관계라도 데이터베이스 내에서 표현이 가능하도록 만드는 것
- 관계에서 바람직하지 않은 삽입, 삭제, 갱신 이상이 발생하지 않도록 하는 것
- 새로운 형태의 데이터가 삽입될 때 관계를 재구성할 필요성을 줄임
- 보다 간단한 관계 연산에 기초하여 검색을 보다 효율적으로 함
- 정규화의 원칙
- 무손실 표현 : 같은 의미의 정보 유지를 하면서 더 바람직한 구조를 만듦
- 자료의 중복성 감소 : 중복되는 정보는 삭제하거나 통합
- 분리의 원칙 : 독립적인 관계는 별개의 릴레이션으로 표현하고 릴레이션 각각에 대해 독립적 조작이 가능
- 이상현상의 종류
- 삽입 이상 : 불필요한 데이터를 함께 삽입하지 않으면 데이터를 삽입하는 것이 불가능
- 수정(갱신) 이상 : 중복된 데이터 가운데 일부만 수정되어 데이터의 불일치가 발생
- 삭제 이상 : 어떤 데이터를 삭제하면 유용한 데이터도 함께 삭제가 됨
247. UPDATE 명령어
- 한 테이블에 들어 있는 튜플(행)들의 컬럼 값을 수정할 때 사용
- 표준 형식 : UPDATE 테이블 명 SET 컬럼명 = 값 또는 식[, ...] WHERE 조건;
- WHERE 조건 생략 시 모든 레코드가 변경되므로 사용 시 주의
248. 데이터베이스 키
- 데이터베이스 키의 개념
- 조건에 만족하는 튜플을 찾거나 순서대로 정렬할 때 튜플(행)들을 서로 구분할 수 있는 기준이 되는 속성들
- 데이터베이스 키의 특징
- 유일성 (Uniqueness)
- 하나의 키 값으로 하나의 튜플만을 유일하게 식별할 수 있어야 함
- 기본 키, 후보 키, 슈퍼 키
- 최소성 (Minimality)
- 속성의 집합인 키가 릴레이션의 모든 튜플을 유일하게 식별하기 위해 꼭 필요한 속성들로 구성된 것을 의미
- 기본 키, 후보 키
- 유일성 (Uniqueness)
- 데이터베이스 키의 종류
- 후보 키 (Candiate Key)
- 릴레이션을 구성하는 속성들 중에서 튜플을 유일하게 식별할 수 있는 하나 또는 몇 개의 속성의 집합
- 유일성과 최소성을 모두 만족
- 기본 키 (Primary Key)
- 릴레이션의 유일한 식별자 (유일성, 최소성 모두 만족)
- 기본 키로 지정된 속성은 같은 값을 갖지 못함
- 후보 키 중에서 선정된 키로 중복값을 가질 수 없음
- Not null, Unique, 외래 키로 참조될 수 있음
- 대체 키 (Alternate Key)
- 후보 키가 둘 이상 되는 경우에 기본 키로 선택되지 못한 후보 키들
- 후보 키 = 기본 키 + 대체 키
- 슈퍼 키 (Super Key)
- 유일성만 있고 최소성이 없는 속성의 집합
- 외래 키 (Foreign Key)
- 한 테이블의 키 중 다른 테이블의 튜플을 식별할 수 있는 키
- 후보 키 (Candiate Key)
'자격증 > 정보처리기사' 카테고리의 다른 글
[정보처리기사 필기] 2022 기사패스 정보처리기사 기출문제 상세풀이 800제 : 301 ~ 350 오답정리 (0) | 2025.04.09 |
---|---|
[정보처리기사 필기] 2022 기사패스 정보처리기사 기출문제 상세풀이 800제 : 251 ~ 300 오답정리 (0) | 2025.04.08 |
[정보처리기사 필기] 2022 기사패스 정보처리기사 기출문제 상세풀이 800제 : 151 ~ 200 오답정리 (0) | 2025.04.02 |
[정보처리기사 필기] 2022 기사패스 정보처리기사 기출문제 상세풀이 800제 : 101 ~ 150 오답정리 (0) | 2025.04.01 |
[정보처리기사 필기] 2022 기사패스 정보처리기사 기출문제 상세풀이 800제 : 51 ~ 100 오답정리 (0) | 2025.03.31 |