1. 소프트웨어 공학
1.1 소프트웨어 개발 방법론의 종류
소프트웨어 개발 방법론 | 설명 |
구조적 방법론 | 시스템을 기능 단위로 분할(divide)하고, 정복 방식(conquer)으로 각 기능을 개발 후 통합한 방법론 |
정보공학 방법론 | 정보 시스템 개발을 위해 관리 절차와 작업 기반을 체계화한 방법론 |
객체 지향 방법론 | 객체를 기반으로 시스템을 분석하고 설계하는 방법론 |
컴포넌트 기반 방법론 | 재사용 가능한 컴포넌트를 조립하여 새로운 응용프로그램을 구성하는 방법론 |
애자일 방법론 | 절차보다 사람 중심, 변화에 유연하고 신속하게 대응하여 시스템을 개발하는 방법론 |
제품 계열 방법론 | 공통기능을 정의하여 여러 제품군에서 재사용 가능하도록 설계하는 방법론 |
1.2 리팩토링의 목적
리팩토링의 목적은 외부 동작을 그대로 유지하면서
① 코드 구조를 정리하여 유지 보수성을 높이고,
② 요구사항 변경에 잘 적응할 수 있도록 시스템의 유연성을 강화하며,
③ 중복을 제거하고 모듈화를 통해 개발 생산성을 향상시키고,
④ 깔끔한 설계로 품질을 개선하고 버그를 조기에 발견할 수 있도록 하는 것이다.
리팩토링(Refactoring)이란,
소프트웨어의 외부 기능은 유지하고, 내부 코드 구조를 개선하여 소프트웨어의 유지 보수성을 향상시키는 방법이다.
1.3 LOC 기법
소프트웨어 규모 및 비용을 추정하기 위한 상향식 비용 산정 기법
각 기능별로 원시 코드 라인수(LOC)의 비관치, 낙관치, 기대치를 측정하여 LOC 예측치를 구하고,
이를 바탕으로 비용을 산정하는 기법이다.
결과 | 공식 |
예측치 | 예측치 = (낙관치 + 4*기대치 + 비관치) / 6 |
노력(월) | 노력 = 예측치 / (개발자 1인당 월 생산성) |
개발 기간(월) | 개발 기간 = 노력 / 투입인원 |
비용 | 비용 = 노력 * 인건비 단가 |
생산성 | 생산성 = LOC / 노력 |
1.4 UML 관계 표현
UML 관계표현 |
설명 | 표시 |
포함관계 | 전체/부분 객체 라이프 타임 의존적 | ![]() |
단방향 연관관계 | 한쪽은 알지만 반대쪽은 상대방의 존재 모름 | ![]() |
일반화 관계 | 상속관계를 표현하며 하위 모듈이 상위 모듈보다 더 구체적인 개념을 가진다 | ![]() |
집합관계 | 클래스 사이 전체나 부분이 같은 관계로, 서로 독립적 | ![]() |
양방향 연관관계 | 양쪽 클래스가 서로의 존재를 인식 | ![]() |
의존 관계 | 연관관계와 같으나 짧은 시간 동안 유지됨 | ![]() |
실체화 관계 | 책입 집합 인터페이스와 실제로 실현한 클래스들의 사이를 표현 | ![]() |
1.5 UML 다이어그램 ⭐️
다이어그램 분류 | 종류 | 예시 |
구조 다이어그램 (클객컴배복패) |
클래스 다이어그램 : 클래스의 정적 구조를 표현, 클래스 간 관계 표현 |
![]() |
객체 다이어그램 : 객체 정보 표현 |
![]() |
|
컴포넌트 다이어그램 : 컴포넌트 구조 사이의 관계 표현 |
![]() |
|
배치 다이어그램 : 물리 구조 표현 |
![]() |
|
복합체 구조 다이어그램 : 복합 구조의 클래스와 컴포넌트 내부 구조 표현 |
![]() |
|
패키지 다이어그램 : 패키지 관계 표현 |
![]() |
|
행위 다이어그램 (유활상순상) |
Use Case 다이어그램 : 사용자 관점에서 시스템 행위 표현 |
![]() |
활동 다이어그램 : 업무 처리(연산) 과정을 표현 |
![]() |
|
상태 다이어그램 : 객체가 어떻게 변화하는지 표현 |
![]() |
|
순차다이어그램 : 시스템 동작을 정형화 |
![]() |
|
상태머신 다이어그램 : 객체의 생명주기를 표현 |
![]() |
1.6 UML 구성 요소
UML 구성요소 : 사물, 관계, 다이어그램 (사관다)
1.7 결합도와 응집도 ⭐️
모듈화는 모듈 간 결합도는 최소화하고, 응집도는 최대화하는 것이 목표이다.
결합도 : 외부 모듈과의 상호 의존성을 나타내는 정도
결합도의 유형 (자스제외공내) | 설명 |
자료 결합도 (Data Coupling) |
- 단순한 파라미터만 전달하여 상호작용할 때 발생 |
스탬프 결합도 (Stamp Coupling) |
- 복합 데이터 구조(객체, 배열)등을 통째로 전달할 때 발생 |
제어 결합도 (Control Coupling) |
- 제어 플래그나 호출 방식 등으로 모듈 제어 흐름을 전달할 때 발생 |
외부 결합도 (Exernal Coupling) |
- 외부 시스템이나 데이터 포멧, 프로토콜, 장치 인터페이스를 모듈 간 공유할 때 발생 |
공통 결합도 (Common Coupling) |
- 전역 변수를 여러 모듈이 공유하고 갱신할 때 발생 |
내용 결합도 (Content Coupling) |
- 한 모듈이 다른 모듈의 내부 코드를 직접 참조하거나 수정할 때 발생 |
응집도 : 모듈 내부 구성 요소 간 연관 정도
응집도의 유형 (기순통절시논우) | 설명 |
기능적 응집도 (Functional Cohesion) |
- 하나의 모듈이 단일한 목적을 수행하는 요소만 포함하는 경우 |
순차적 응집도 (Sequential Cohesion) |
- 모듈의 일부의 출력이 다음 부분의 입력으로 사용되는 경우 |
교환적 응집도 (Communication Cohesion) |
- 모듈 내부 요소들이 같은 데이터를 처리하거나 동일한 입출력을 사용하는 경우 |
절차적 응집도 (Procedural Cohesion) |
- 일정한 순서에 따라 실행되어야 하는 절차들을 모아둔 경우 |
시간적 응집도 (Temporal Cohesion) |
- 특정 시점(초기화, 종료 등)에 수행되는 작업을 묶어둔 경우 |
논리적 응집도 (Logical Cohesion) |
- 같은 논리적 분류에 속하지만 실제 기능은 다른 작업을 모아둔 경우 |
우연적 응집도 (Coincidential Cohesion) |
- 별 다른 논리적 연관 없이 우연히 묶인 경우 |
결합도 낮음(좋은 품질)에서 높음(낮은 품질)의 순서 : 자<스<제<외<공<내
응집도 높음(좋은 품질)에서 낮음 (낮은 품질)의 순서 : 기>순>교>절>시>논>우
1.8 디자인 패턴 ⭐️
구분 | 종류 | 설명 |
생성 패턴 추빌팩프싱 |
추상팩토리 (Abstract Factory) |
관련있는 객체들을 그룹으로 생성하여 추상적으로 표현 - 연관성이 있는 객체 군이 여러개 있을 경우 이들을 묶어 추상화하고, 어떤 구체적인 상황이 주어지면 팩토리 객체에서 집합으로 묶은 객체 군을 구현화하는 생성 패턴 |
빌더 (Builder) |
객체의 생성 과정과 표현 방법을 분리하여 다양한 객체를 생성할 수 있다 | |
팩토리 메소드 (Factory Method) |
객체 생성 책임을 하위 클래스에게 위임하여, 어떤 클래스의 인스턴스를 생성할지 서브클레스가 결정하도록 하는 것 | |
프로토타입 (Prototype) |
원본 객체(프로토타입)을 복제하여 새로운 객체로 생성하는 것 | |
싱글톤 (Singleton) |
하나의 인스턴스만 생성되고, 하나의 객체를 여러 프로세스가 동시에 참조할 수 없다 | |
구조 패턴 어브컴데 퍼플프 |
어댑터 (Adaptor) |
불일치하는 인터페이스끼리 호환되도록 연결해주는 중간자 역할을 수행 |
브리지 (Bridge) |
추상화와 구현을 분리하여 독립적으로 변화 가능하도록 구조를 분리 | |
컴포지트 (Composite) |
여러 객체를 가진 복합, 단일 객체를 구분 없이 다룰 때 사용 | |
데코레이터 (Decorator) |
객체에 기능을 동적으로 확장해주는 패턴 | |
퍼싸드 (Facade) |
서브 클래스들의 기능을 간편하게 사용할 수 있도록하는 패턴 | |
플라이웨이트 (Flyweight) |
공유가능한 상태를 객체 간에 공유하여 메모리를 절약하는 구조 | |
프록시 (Proxy) |
객체에 대한 접근을 제어하거나 대리 역할을 수행하는 대리인 객체를 제공 | |
행위 패턴 | 책임 연쇄 (Chain of Responsibility) |
요청을 여러 핸들러에 순차적으로 전달하며, 적절한 핸들러가 처리하도록 한다 |
커맨드 (Command) |
요청에 각종 명령어들을 추상, 구체 클래스로 분리하여 단순화함 | |
인터프리터 (Interpreter) |
언어의 문법 표현을 정의하는 패턴 | |
반복자 (Iterator) |
동일한 인터페이스를 사용하도록하는 패턴 - 반복 프로세스를 캡슐화하여 클라이언트 코드에서는 컬렉션의 구체적인 구현에 종속되지 않도록 한다. |
|
중재자 (Mediator) |
서로의 존재를 모르는 상태에서도 협력할 수 있게 하는 패턴 | |
매멘토 (Mementor) |
객체의 내부 상태를 외부에 저장하여 필요시 해당 상태로 복원할 수 있는 패턴 | |
옵저버 (Observer) |
관찰대상의 변화를 탐지하는 패턴 - 한 객체의 상태가 바뀌면 그 객체에 의존하는 다른 객체들에게 연락이 가서 자동으로 내용이 갱신되는 방식 |
|
상태 (State) |
객체의 상태에 따라 동일한 요청에 대해 다른 행동을 수행하도록 상태별로 동작을 분리하는 패턴 | |
전략 (Starategy) |
알고리즘을 캡슐화하여 클라이언트에 영향 받지 않는 독립적인 알고리즘을 선택하는 패턴 | |
템플릿 메소드 (Template Method) |
알고리즘의 기본 뼈대는 슈퍼클래스에서 정의하고 세부 단계는 서브클래스가 구현 | |
방문자 (Visitor) |
필요할 때마다 해당 클래스에 방문하여 처리하는 패턴 |
1.9 럼바우 객체 지향 분석 / 객체 모델링기법
구분 (객동기) |
종류 | |
객체 모델링 | information | 객체 다이어그램 |
동적 모델링 | dynamic | 상태 다이어그램 |
기능 모델링 | function | 자료 흐름도 |
1.10 SOLID 원칙
구분 | 설명 | |
단일 책임의 원칙 | SRP, Single Responsibility Principle | - 모든 클래스는 하나의 책임만 가져야 한다 |
개방-폐쇄의 원칙 | OCP, Open Closed Priciple | - 확장에 개방, 수정에는 폐쇄적이어야 한다 |
리스코프치환 원칙 | LSP, Liskov Substitution Principle | - 부모 클래스를 자식 클래스로 대체 가능해야 한다 |
인터페이스 분리 원칙 | ISP, Interface Segregation Principle | - 클라이언트는 사용하지 인터페이스에 영향을 받으면 안된다 |
의존 역전 원칙 | DIP, Dependency Inversion Principle | - 변하기 어렵고 변화 빈도가 낮은 것에 의존한다 |
1.11 릴리즈 노트의 주요 항목 작성
항목 | 포함 내용 |
헤더 (Header) |
문서명, 제품명, 릴리즈 날짜와 버전, 문서 버전 등의 기본 정보 |
개요 (Overview) |
제품 및 이번 릴리즈에서의 변화에 대한 간략한 설명 |
목적 (Purpose) |
릴리즈의 주요 목적과 새로운 기능 및 버그 수정 내용 소개 |
이슈 요약 (Issue Summary) |
수정된 버그 또는 새기능에 대한 간단한 설명 |
재현 항목 (Steps to Reproduce) |
버그 발생 시 재현을 위한 단계를 기술 |
수정 개선 내용 (Resolution) |
문제 해결 또는 개선된 기능에 대한 요약 설명 |
사용자 영향도 (End-User Impact) |
버전 변화로 인한 최종 사용자 측면의 영향 및 행동 기술 |
소프트웨어 지원 영향도 (Support Impacts) |
운영,지원 절차나 프로세스 변경 시 영향을 받는 사항 |
노트 (Notes) |
설치, 업그레이드 항목, 관련 문서 등의 추가 참조 설명 |
면책 조항 (Disclaimers) |
라이선스, 불법 복제 방지, 자사 정책 등 법적 고지 사항 |
연락 정보 (Contact Info) |
사용자 지원 문의처, 연락처 정보 |
1.12 형상관리
소프트웨어 형상관리(SCM, Software Configuration Management)
소프트웨어 개발 단계의 각 과정에서 만들어지는 모든 프로그램, 프로그램을 설명하는 문서, 데이터 등을 관리하는 것이다.
형상관리 기능 (식통감기) | 설명 |
형상 식별 | - 형상관리 대상에 이름과 관리 번호 부여 - 계층 구조로 구분하여 수정 및 추적이 용이하게 하도록 하는 작업 |
형상 통제 | - 식별된 형상 항목에 대한 변경 요구를 검토 - 현재의 기준선이 잘 반영되도록 조정하는 작업 - 형상 항목의 버전 관리를 위한 형상통제위원회 운영 |
형상 감사 | - 기준선의 무결성을 평가하기 위해 확인, 검증, 검열 과정을 통해 공식적으로 승인하는 작업 |
형상 기록 | - 형상의 식별, 통제, 감사, 작업의 결과를 기록, 관리하고 보고서를 작성하는 작업 |
형상 관리 항목
구분 | 설명 | 종류 |
저장소 구분 | 로컬 버전 관리 시스템 | RCS |
중앙 집중형 버전 관리 시스템 | CVS, SVN, Clear Case | |
분산형 버전 관리 시스템 | Git | |
소스 공개 유형 | 오픈소스 툴 | SVS, SVN |
상용 버전 관리 툴 | PVCS, Clear Case |
1.13 사용자 인터페이스(UI) 기본 원칙
인터페이스 기본 원칙 (직유학연) | 설명 |
직관성 | 누구나 쉽게 이용하고 사용할 수 있어야 한다 |
유효성 | 사용자의 목적을 정확하고 완벽하게 달성해야 한다 |
학습성 | 누구나 쉽게 배우고 익힐 수 있어야 한다 |
유연성 | 사용자의 요구사항을 최대로 수용하고 실수를 최소화 한다 |
1.14 UI의 종류
UI 종류 | 설명 | |
CLI | Command Line Interface | 텍스트 형태로 이루어진 인터페이스 |
GUI | Graphical User Interface | 마우스를 선택하여 작업하는 그래픽 환경의 인터페이스 |
NUI | Natural User Interface | 사용자의 말이나 행동으로 기기를 조작하는 인터페이스 |
VUI | Voice User Interface | 사람의 음성으로 기기를 조작하는 인터페이스 |
OUI | Organic User Interface | 사물과 사용자 간의 상호작용을 위한 인터페이스 |
1.15 EAI 유형
유형 | 기능 | |
Point-to-Point | ![]() |
미들웨어 없이 point to point로 연결하는 통합방식 |
Hub & Spoke | ![]() |
❶ 단일 접점인 허브 시스템을 통해 데이터 전송하는 중앙 집중형 방식 ❷ 허브에 장애 발생 시 시스템 전체에 영향 |
Message Bus | ![]() |
❶ 미들웨어를 배치하여 처리하는 방식 ❷ 대용량 데이터 처리에 유리 |
Hybrid | ![]() |
❶ Hub&Spoke와 Message Bus의 혼합 형태 ❷ 그룹 내 : Hub&Spoke 그룹 간 : Message Bus ❸ 데이터 병목 현상 최소화 |
2. 데이터베이스
2.1 트랜잭션의 특징
트랜잭션의 특징 (ACID) | 설명 |
원자성 (Atomicity) |
- 더이상 분해되지 않는 작업의 최소 단위 - 작업이 모두 성공하던지 모두 실패하던지 해야함 |
일관성 (Consistency) |
- 트랜잭션 실행 후 항상 일관된 상태를 유지해야 함 |
독립성 / 격리성 (Isolation) |
- 동시에 실행되는 트랜잭션이 다른 트랜잭션에 영향을 주지 못해야 함 |
영속성 / 지속성 (Duration) |
- 트랜잭션이 커밋되면 장애가 발생하더라도 결과는 DB에 반영되어야 함 |
2.2 데이터베이스 정규화와 비정규화 + 함수 종속성
정규화란? (Nomalization)
중복 데이터를 제거하고, 데이터의 일관성과 무결성을 유지하기 위해 테이블을 작은 단위로 분리하는 과정
비정규화란? (Denomalization)
정규화된 데이터 모델을 성능 개선이나 사용 편의성을 위해 다시 중복되도록 통합하거나 속성을 추가하는 과정
데이터베이스 정규화 단계 | 설명 |
1정규형 (1NF) |
- 원자 값으로 구성 |
2정규형 (2NF) |
- 부분 함수 종속 제거 - 완전 함수적 종속 관계 |
3정규형 (3NF) |
- 이행 함수 종속 제거 |
보이스-코드 정규형 (BCNF) |
- 결정자 함수이면서 후보키가 아닌 것 제거 |
4정규형 (4NF) |
- 다치(다중 값) 종속 제거 |
5정규형 (5NF) |
- 조인 종속 제거 |
함수 종속성 | 설명 |
함수적 종속 (Functional Dependency) |
- X → Y일 때, X의 값이 Y를 유일하게 결정하는 경우 - 학번 → 이름 : 학번이 이름을 유일하게 결정 |
완전 함수 종속 (Full Function Dependency) |
- 기본키가 여러 속성으로 이루어져 있을 때, 모두 필요해서 Y가 결정되는 경우 - {학생 ID, 과목 ID} → 성적 : 둘 중 하나의 값 만으로는 성적을 결정할 수 없음 |
부분 함수 종속 (Partial Functional Dependency) |
- 기본키의 일부 속성만으로 Y를 결정하는 경우 - {학생 ID, 과목 ID} 중 과목 ID 만으로 과목명이 결정 |
이행 함수 종속 (Transitive Dependency) |
- X → Y이고 Y → Z이면 X → Z가 성립할 경우 - 직원ID → 부서 → 부서명 → 직원ID → 부서명 |
2.3 비즈니스 연속성 계획(BCP)
BCP(Business Continuity Plan)이란?
재해나 사고가 나도 핵심 업무를 계속 유지하기 위한 기업의 대응 계획
핵심 용어 | 설명 |
BIA 비즈니스 영향 분석 (Business Impact Analysis) |
- 재해가 나면 어떤 영향을 미칠지 분석하는 과정 |
RTO, 복구 시간 목표 (Recovery Time Objective) |
- 업무 중단 시점부터 복구되어 가동하기까지 걸려야하는 시간 |
RPO, 복구 시점 목표 (Recovery Point Objective) |
- 멈췄을 때 어디까지의 데이터는 복구 되어야 하는지 기준 목표 |
DRP, 재해 복구 계획 (Disaster Recovery Plan) |
- 장기 중단을 대비한 구체적 복구 계획 |
DRS, 재해 복구 시스템 (Disaster Recovery System) |
- 복구를 위한 백업 센터, 장비, 인력 등 자원 시스템 |
2.4 DB 설계 절차
단계 (요개논물구) | 설명 |
요구사항 분석 | - 무엇을 저장하고 어떤 기능을 제공할 것인지 파악하는 단계 - 사용자가 필요로 하는 데이터와 처리 요구사항을 수집 |
개념적 설계 | - 요구사항을 바탕으로 데이터 개체들 간의 관계들을 모델링 - ER 다이어그램을 주로 사용 |
논리적 설계 | - 개념적 설계를 바탕으로 논리적 모델을 설계 - 스키마 설계, 트랜잭션 인터페이스를 설계하는 정규화를 수행 |
물리적 설계 | - 인덱스, 파티션, 저장소 구조 등을 정의 - 특정 DBMS의 특성 및 성능을 고려하여 데이터베이스 저장 구조로 변환하는 과정으로 결과로 나오는 명세서는 테이블 저의서 등이 있음 |
구현 | - SQL문을 실행하여 데이터베이스를 실제로 생성 |
스키마란?
데이터베이스의 구조와 제약조건에 관한 전반적인 명세를 기술한 것
2.5 관계 대수 연산자
구분 | 연산자 | 설명 |
선택 (Selection) |
σ (시그마) |
- 조건에 맞는 튜플(행)을 선택 |
투사 (Projection) |
π (파이) |
- 원하는 속성(열)만 추출 |
합집합 (Union) |
∪ | - 두 릴레이션의 모든 튜플을 합침 |
차집합 (Difference) |
− | - (R − S) : R에는 있고, S에는 없는 튜플 |
교차곱 (Cartesia Product) |
× | - 두 릴레이션의 모든 조합 |
조인 (Join) |
⋈ | - 조건에 맞는 두 릴레이션의 튜플을 합침 |
나누기 (Division) |
÷ | - (R ÷ S) : S의 모든 값과 관련된 R의 튜플만 선택 |
2.6 데이터베이스 회복 기법
구분 | 분류 | 설명 |
로그 기반 회복 | 지연 갱신 회복 기법 | - 트랜잭션 커밋 전까지 DB 반영을 지연 - Redo만 사용 (Undo 불필요) |
즉각 갱신 회복 기법 | - 트랜잭션 중간에도 DB 반영 - Redo + Undo 모두 사용 |
|
체크포인트 회복 기법 | - 주기적으로 체크포인트를 수행하여 로그 스캔 범위를 줄이고 회복 성능을 향상 | |
그림자 페이징 회복 기법 | - 기존 페이지는 수정하지 않고, 그림자페이지를 복제 및 수정하여 커밋시 포인터만 갱신 - 장애시 롤백 없이 즉시 일관된 상태로 복구 |
2.7 데이터베이스 보안의 3대 요소
데이터베이스 보안의 3요소 (무기가) | 설명 |
무결성 (Integrity) |
- 데이터가 정확하고 안전하게 유지되며, 승인되지 않은 수정이나 손실이 방지됨을 보장 |
기밀성 (Confidentiality) |
- 권한 없는 사용자의 정보접근을 차단하여 데이터 비공개를 보장 |
가용성 (Availability) |
- 인가 받은 사용자는 필요한 시점에 언제든지 데이터를 사용할 수 있음을 보장 |
2.8 테이블 구성 요소
구분 | 설명 |
릴레이션 (Relation) |
- 테이블 자체를 의미 - 행과 열로 이루어진 데이터 집합 |
튜플 (Tuple) |
- 릴레이션 하나의 행을 의미 - 개체에 대한 속성 값들의 집합 |
속성 (Attribute) |
- 릴레이션의 열에 해당 - 튜플이 가지는 데이터 항목의 이름과 도메인 |
카디널리티 (Cardinality) |
- 릴레이션 튜플(행)의 수 - 테이블에 저장된 레코드의 개수 |
차수 (Degree) |
- 릴레이션의 속성(열)의 수 - 테이블에 정의된 컬럼의 개수를 뜻한다 |
2.9 데이터모델 구성요소
데이터모델 구성요소 | 설명 |
연산 | - 데이터베이스에 저장된 실제 데이터를 처리하는 작업에 대한 명세로서 데이터베이스를 조작하는 기본 도구에 해당 |
구조 | - 논리적으로 표현된 객체 타입들 간의 관계로서 데이터 구성 및 정적 성질을 표현 |
제약 조건 | - 데이터베이스에 저장될 수 있는 실제 데이터의 논리적인 제약 조건을 의미 |
2.10 서버 접근 통제 유형
구분 | 설명 |
임의적 접근통제 (DAC, Discretionary Access Control) |
- 시스템에 대한 접근을 사용자/그룹의 신분 기반으로 제한하는 방법 |
강제적 접근통제 (MAC, Mandatory Access Control) |
- 시스템 정보의 허용등급을 기준으로 사용자가 갖는 접근 허가 권한에 근거하여 시스템에 대한 접근을 제한하는 방법 |
역할 기반 접근통제 (RBAC, Role Based Access Control) |
- 중앙 관리자가 사용자와 시스템의 상호관계를 통제하며 조직 내 맡은 역할에 기초하여 자원에 대한 접근을 제한하는 방법 |
2.11 병행 제어 기법
구분 | 설명 |
로킹 (Locking) |
- 데이터 항목에 공유 또는 베타적 락을 걸어 트랜잭션 간 동시 접근을 제어 - 접근한 데이터에 대한 연산을 마칠 때까지 접근을 제한 |
낙관적 검증 (OCC, Optimistic Concurrency Control) |
- 트랜잭션 실행 후에 충돌 여부를 검증 - 충돌이 없으면 커밋하고 충돌 시 롤백하여 재시도하는 방식 |
타임스탬프 순서 (TO, Timestamp Ordering) |
- 각 트랜잭션에 타임스탬프를 부여하여 읽기, 쓰기, 우선순위를 결정 - 순서에 맞지 않는 접근 시 즉시 중단 또는 지연시켜 병행성을 제어 |
다중 버전 동시성 제어 (MVCC, Multiversion Concurrency Control) |
- 쓰기 시 새로운 버전을 생성하고, 읽기는 스냅샷 버전을 참조 - 락 없이 동시 접근할 수 있도록하여 읽기 쓰기 병행성을 향상시킴 |
2.12 데이터베이스 파일 조직
유형 | 설명 |
순차 파일 (Sequential File) |
- 레코드를 삽입된 순서 또는 특정 키 순서대로 연속 저장함 |
인덱스 파일 (Indexed File) |
- <값, 주소> 쌍으로 구성되는 데이터 구조를 활용하여 데이터에 접근 - 자기 디스크에서 주로 활용한다. |
해싱 파일 (Hashed File) |
- 해시 함수로 키를 주소로 매핑해 해당 디스크 블록에 직접 접근 |
2.13 데이터베이스 이상 현상
구분 | 설명 |
삽입 이상 | - 정보 저장 시 해당 정보의 세부 정보를 입력해야 하는 경우 |
삭제 이상 | - 정보 삭제 시 원치 않는 다른 정보가 같이 삭제되는 경우 |
갱신 이상 | - 중복 데이터 중에서 특정 부분만 수정되어 중복된 값이 모순을 일으키는 경우 |
2.14 키 및 제약조건
구분 | 설명 | 특징 요약 |
슈퍼키 | - 데이터 베이스에서 튜플 검색이나 정렬의 기준이 되는 속성 | - 유일성 |
후보키 | - 슈퍼키 중 최소성을 만족하는 속성 집합 | - 유일성 + 최소성 |
기본키 | - 후보키 중 하나를 선택하여 NOT NULL + 유일성을 보장한 키 | - 후보키 + NOT NULL |
대체키 | - 기본키로 선택되지 않은 다른 후보키 - UNIQUE 제약을 통해 유일성 유지 |
- 기본 키 외 후보키, UNIQUE 제약 |
외래키 | - 다른 릴레이션의 기본키나 후보키를 참조하여 참조무결성을 보장 | - 다른 테이블 키 참조, 참조 무결성 |
복잡키 | - 둘 이상 속성의 조합으로 구성된 키 | - 여러 속성 조합으로 구성된 키 |
2.15 E-R 다이어그램
기호 | 기호 이름 | 의미 |
![]() |
사각형 | 개체 Entity |
![]() |
마름모 | Relationship |
![]() |
타원 | Attribute |
![]() |
실선 | 개체 타입과 속성을 연결 |
2.16 스키마의 종류
구분 | 설명 |
개념 스키마 (전체적인 논리적 구조) |
- 데이터베이스의 전체적인 논리적 구조 - 모든 응용 프로그램이나 사용자들이 필요로 하는 데이터를 종합한 조직 전체의 데이터베이스 |
내부 스키마 (저장 장치 관점의 구조) |
- 물리적 저장장치의 입장에서 본 데이터 구조 - 실제로 저장될 레코드의 형식, 저장 데이터 항목의 표현 방법, 내부 레코드의 물리적 순서를 나타냄 |
외부 스키마 (사용자 관점의 논리적 구조) |
- 사용자나 응용 프로그래머가 각자 필요로 하는 데이터베이스의 논리적 구조를 정의한 것 |
2.17 데이터베이스 무결성의 종류
무결성(Integrity)이란?
데이터베이스에서 항상 일관성을 갖고 데이터의 유효성, 정확성, 안정성을 유지할 수 있도록 제약조건을 두는 특성이다
구분 | 설명 |
개체 무결성 (Entity Integrity) |
- 기본 테이블의 기본키를 구성하는 어떤 속성도 Null 값이나 중복 값을 가질 수 없다 |
참조 무결성 (Referential Integrity) |
- 외래키 값은 Null 이거나 참조 릴레이션의 기본키 값과 동일해야 한다 |
도메인 무결성 (Domain Integrity) |
- 주어진 속성 값이 정의된 도메인에 속한 값이어야 한다 |
사용자 정의 무결성 (User-Defined Integrity) |
- 속성 값들이 사용자가 정의한 제약 조건에 만족해야 한다 |
키 무결성 (Key Integrity) |
- 하나의 릴레이션에는 적어도 하나의 키가 존재해야 한다 |
Null 무결성 | - 릴레이션의 특정 속성 값이 Null이 될 수 없도록 한다 |
관계 무결성 (Relationship Integrity) |
- 릴레이션에 어느 한 튜플의 삽입 가능 여부 - 한 릴레이션과 다른 릴레이션의 튜플들 사이의 관계에 대한 적절성 여부 |
고유 무결성 (Unique Integrity) |
- 릴레이션의 특정 속성에 대해 각 튜플이 갖는 속성 값들이 서로 달라야 한다 |
2.18 조인(Join)의 종류
조인(Join)이란?
데이터베이스에서 2개 이상의 테이블을 연결하여 원하는 데이터를 추출하는 방법이다.
구분 | 설명 | 예시 |
내부 조인 (Inner Join) |
- 교집합 개념 - 두 테이블에서 공통 데이터만 조회 |
학생과 반이 일치하는 데이터 조회 |
외부 조인 (Outer Join) |
- 공통데이터 + 없는 데이터 조회 - Left Join, Right Join, Full Join |
학생과 반이 일치하는 데이터 조회 + 기준 테이블 데이터를 모두 포함 |
교차 조인 (Cross Join) |
- 두 테이블의 모든 조합을 반환하는 조인 - 데카르트 곱 (Cartesian Product) |
첫 번째 테이블의 모든 행 * 두 번째 테이블의 모든 행 조합 |
세타 조인 (Theta Join) |
- 비교 연산자를 사용하여 조회 | `WHERE 학생.나이 >= 교실. 최소나이` 특정 나이 이상인 학생을 조회 |
동등 조인 (Equivalent Join) |
- 비교 연산자 중 = 연산자를 사용하여 조회 - 내부 조인과 비슷하나 중복 표시 가능 |
`학생.반 = 교실.반` 학생과 반이 일치하는 데이터 조회 |
자연 조인 (Natural Join) |
- 공통된 컬럼을 자동으로 찾아 조인 - 중복 컬럼 없음 |
반이 공통 속성일 때, 자동으로 조인 |
세미 조인 Semi Join) |
- 특정 조건을 만족하는 데이터만 조회 | 반이 존재하는 학생만 조회 |