1. 관계대수
관계형 데이터 베이스에서 원하는 정봐와 그 정보를 검색하기 위해서 어떻게 유도하는가를 기술하는 절차적언어
종류 | 특징 | 기호 |
SELECT | 수평연산 | 시그마(σ) |
PROJECT | 수직연산 | 파이(π) |
JOIN | 공통속성으로 묶음 | ▷◁ |
DIVISION | 제외한 속성만 구함 | ÷ |
UNION(합집합) | ∪ | |
INTERSECTION(교집합) | ∩ | |
DIFFERENCE(차집합) | - | |
CARTESIAN PRODUCT(교차곱) | X |
2. 디자인 패턴
- 생성 패턴(Creational Patterns)은 객체 생성 과정에 중점을 둔 디자인 패턴입니다. 이러한 패턴을 사용하면 객체 생성 로직을 분리하여 코드의 유연성과 재사용성을 높일 수 있습니다. 생성 패턴의 주요 목표는 시스템이 어떤 구체 클래스를 사용하는지에 대한 정보를 숨기며, 객체를 생성하는 코드와 객체를 사용하는 코드를 분리하는 것입니다.
1. Singleton Pattern (싱글턴 패턴)
- 이 패턴의 목적은 특정 클래스에 대한 객체가 하나만 존재하도록 보장하고, 이를 쉽게 접근할 수 있는 전역 접근점을 제공하는 것입니다.
- 예: 데이터베이스 연결, 로거 등.
2. Factory Method Pattern (팩토리 메서드 패턴)
- 서브클래스가 구체 클래스를 생성할 것인지를 결정하게 하는 패턴입니다. 팩토리 메서드는 인스턴스 생성을 서브클래스에게 위임합니다.
- 예: GUI 라이브러리에서 플랫폼별 버튼이나 창을 생성할 때.
3. Abstract Factory Pattern (추상 팩토리 패턴)
- 여러 팩토리 메서드를 제공하여 관련된 객체 집합을 생성하는 패턴입니다.
- 예: 사용자 인터페이스 컴포넌트를 플랫폼별로 다르게 생성할 때.
4. Builder Pattern (빌더 패턴)
- 복잡한 객체를 단계별로 생성할 수 있는 패턴입니다. 사용자는 구체적인 내부 구조나 생성 과정을 알 필요 없이 원하는 객체를 얻을 수 있습니다.
- 예: 복잡한 문서, 메뉴, 차량 등의 객체 생성시.
5. Prototype Pattern (프로토타입 패턴)
- 기존 객체를 복제하여 새로운 객체를 생성하는 패턴입니다. 새로운 객체의 일부 속성이나 상태를 기존 객체와 공유할 때 유용합니다.
- 예: 객체 생성 비용이 높거나 시스템에 새로운 객체 인스턴스를 동적으로 추가하고 싶을 때.
- 구조 패턴(Structural Patterns)은 객체나 클래스의 구성 방식에 관련된 패턴입니다. 이 패턴들은 더 큰 구조나 체계를 형성하기 위해 객체와 클래스를 조합하는 방법을 제공합니다. 구조 패턴을 사용하면 상속을 통해 인터페이스를 확장하거나 기능을 추가하는 것보다 더 유연한 설계를 할 수 있습니다.
1. Adapter Pattern (어댑터 패턴)
- 두 개의 호환되지 않는 인터페이스를 함께 작동하게 하는 패턴입니다. 어댑터는 하나의 기존 클래스의 인터페이스를 다른 인터페이스로 변환합니다.
- 예: 다른 인터페이스를 가진 라이브러리들을 함께 사용할 때.
2. Bridge Pattern (브릿지 패턴)
- 구현과 추상화를 분리하여 독립적으로 변화할 수 있도록 하는 패턴입니다.
- 예: 그래픽스와 윈도우 시스템의 구현을 분리하는 경우.
3. Composite Pattern (컴포지트 패턴)
- 객체들을 트리 구조로 구성하여 전체-부분 계층을 표현하는 패턴입니다. 이를 통해 개별 객체와 복합 객체를 동일하게 취급할 수 있습니다.
- 예: 그래픽스에서 복합 도형이나 UI 구성요소에서 컨테이너와 항목 관리 등.
4. Decorator Pattern (데코레이터 패턴)
- 객체에 동적으로 새로운 책임을 추가하는 패턴입니다. 서브클래싱을 통한 확장보다 유연한 방법을 제공합니다.
- 예: 그래픽 윈도우나 텍스트 뷰어에 추가 기능을 부여하는 경우.
5. Facade Pattern (퍼사드 패턴)
- 복잡한 서브시스템에 대한 통합된 인터페이스를 제공하는 패턴입니다. 클라이언트가 서브시스템의 복잡성을 직접 다루지 않아도 되도록 중간에 퍼사드를 둡니다.
- 예: 컴퓨터 부팅 과정이나 복잡한 라이브러리의 간소화된 API 제공.
6. Flyweight Pattern (플라이웨이트 패턴)
- 많은 수의 비슷한 객체를 효과적으로 지원하기 위해 공유를 사용하는 패턴입니다. 상태를 객체 외부에 저장하여 메모리 사용량을 최소화합니다.
- 예: 그래픽스에서 많은 수의 동일한 객체(예: 나무)를 표현할 때.
7. Proxy Pattern (프록시 패턴)
- 다른 객체에 대한 대리자나 대행자 역할을 하는 객체를 제공하는 패턴입니다. 접근 제어, 지연 초기화, 로깅 등을 위해 사용됩니다.
- 예: 원격 객체 접근(Remote Proxy)이나 대용량 이미지의 지연 로딩(Lazy Loading) 등. - 행위 패턴(Behavioral Patterns)은 객체들 사이의 책임 분배와 상호 작용에 중점을 둔 디자인 패턴입니다. 이 패턴들은 객체 간의 상호 작용 및 책임을 명확하게 만들며, 유연하고 간결한 코드를 작성하도록 도와줍니다.
다음은 주요 행위 패턴에 대한 설명입니다:
1. Chain of Responsibility Pattern (책임 연쇄 패턴)
- 요청을 처리할 수 있는 여러 객체 사이에서 요청을 전달하는 패턴입니다. 요청을 처리하는 객체를 연결 리스트와 같이 연결하고, 요청을 체인에 전달하여 적절한 객체에서 처리하게 합니다.
- 예: GUI의 이벤트 핸들링, 로깅 프레임워크.
2. Command Pattern (커맨드 패턴)
- 요청을 객체로 캡슐화하는 패턴입니다. 이를 통해 사용자의 요청을 객체로 저장, 전달, 로그, 큐에 저장하거나 작업 취소(undo) 등의 연산을 지원합니다.
- 예: GUI 버튼 및 메뉴 항목, 큐에 기반한 작업 관리.
3. Interpreter Pattern (인터프리터 패턴)
- 주어진 언어에 대한 표현식을 해석하는 인터프리터를 정의하는 패턴입니다. 주로 간단한 언어나 도메인 특화 언어(DSL)를 해석할 때 사용됩니다.
- 예: SQL 해석기, 정규 표현식 엔진.
4. Iterator Pattern (이터레이터 패턴)
- 객체의 집합체 내부를 표현하지 않고도 그 집합체의 원소들을 순차적으로 접근할 수 있는 방법을 제공하는 패턴입니다.
- 예: 컬렉션 API, 리스트나 트리 구조의 순회.
5. Mediator Pattern (미디에이터 패턴)
- 객체들 사이의 상호 작용을 캡슐화하는 객체를 정의하는 패턴입니다. 이로써 하나의 객체가 다른 객체들과 직접적으로 상호 작용하는 것을 피하고, 미디에이터를 통해 상호 작용하도록 합니다.
- 예: 대화 상자의 GUI 컴포넌트 관리, 채팅방.
6. Memento Pattern (메멘토 패턴)
- 객체의 상태를 저장하고 이전 상태로 복원할 수 있는 기능을 제공하는 패턴입니다. 이를 통해 "되돌리기" 기능을 구현할 수 있습니다.
- 예: 텍스트 에디터의 undo 기능, 게임의 저장 및 로드.
7. Observer Pattern (옵저버 패턴)
- 객체의 상태 변화를 관찰하는 옵저버들에게 알림을 보내는 패턴입니다.
- 예: GUI 위젯, 이벤트 리스너, 뉴스 구독.
8. State Pattern (상태 패턴)
- 객체의 내부 상태에 따라 행동을 변경하는 패턴입니다. 이를 통해 객체가 내부 상태를 변경하는 것처럼 보이게 할 수 있습니다.
- 예: 네트워크 연결 상태, 문서의 편집 모드.
9. Strategy Pattern (전략 패턴)
- 알고리즘 계열을 정의하고, 각각을 캡슐화하여 교환해서 사용할 수 있게 하는 패턴입니다.
- 예: 정렬 알고리즘, 압축 알고리즘.
10. Template Method Pattern (템플릿 메서드 패턴)
- 알고리즘의 구조를 정의하며, 일부 단계를 서브클래스에서 구현할 수 있게 하는 패턴입니다.
- 예: 데이터 파싱, GUI의 렌더링 프로세스.
11. Visitor Pattern (방문자 패턴)
- 객체 구조에 작동하는 연산을 추가하는 패턴입니다. 이를 통해 구조를 변경하지 않고도 새로운 연산을 추가할 수 있습니다.
- 예: 문서 구조에서 특정 작업 수행, 컴파일러의 구문 트리 처리.
3. 명세기반 테스트 기법
명세기반 테스트 기법(Specification-based Testing Techniques)은 소프트웨어의 명세, 요구사항 또는 설계 문서를 기반으로 테스트 케이스를 도출하는 방식입니다. 이 방식에서 테스터는 주로 소프트웨어의 내부 구현을 고려하지 않고, 외부 동작이나 인터페이스에 중점을 둡니다.
명세기반 테스트 기법의 주요 목표는 요구사항이 올바르게 구현되었는지 확인하고, 문서화된 예외 조건 또는 오류 상황을 테스트하는 것입니다.
1. 등치 분할 테스트 (Equivalence Partitioning)
- 입력 값이나 출력 값의 범위를 유사한 동작 그룹으로 나눈 후, 각 그룹에서 대표값을 선택하여 테스트합니다.
- 예: 사용자 나이를 입력받는 경우, 0-12, 13-19, 20-59, 60 이상과 같이 구간을 나누고 각 구간의 대표 값을 사용하여 테스트할 수 있습니다.
2. 경계값 분석 (Boundary Value Analysis)
- 등치 분할에서 도출된 그룹의 경계값을 테스트합니다. 경계에서 오류가 발생할 확률이 높기 때문에, 이 기법은 효과적입니다.
- 예: 위의 사용자 나이를 기준으로 할 때, 12와 13, 19와 20, 59와 60과 같은 경계 값을 테스트합니다.
3. 결정 테이블 테스트 (Decision Table Testing)
- 복잡한 비즈니스 규칙이나 조건을 표현하기 위한 결정 테이블을 사용하여 테스트 케이스를 도출합니다.
- 예: 할인률이 다양한 조건(회원 등급, 구매 횟수, 프로모션 코드 사용 여부 등)에 따라 다르게 적용되는 경우, 이러한 조건들의 조합을 표로 나타내고 테스트 케이스를 도출합니다.
4. 상태 전이 테스트 (State Transition Testing)
- 소프트웨어나 시스템이 다양한 상태를 갖고, 그 상태 간에 전이가 발생하는 경우 사용합니다.
- 예: 로그인 프로세스에서 "로그인 전", "로그인 성공", "로그인 실패" 등의 상태와 그 사이의 전이를 테스트합니다.
5. 사용 사례 테스트 (Use Case Testing)
- 사용자와 시스템 간의 상호작용을 나타내는 사용 사례를 기반으로 테스트 케이스를 도출합니다.
- 예: 온라인 쇼핑몰에서 "상품 선택", "장바구니에 추가", "주문", "결제" 등의 사용 사례를 통해 테스트 케이스를 생성합니다.
4. 사회공학
컴퓨터 보안에 있어서, 인간 상호작용의 깊은 신뢰를 바탕으로 사람들을 속여 정상 보안 철차를 깨트리기 위한 비기술적인 시스템 침입수단을 이야기한다.
5. 다크 데이터
다크데이터(Dark Data)는 조직에서 수집하거나 생성되지만 일상의 비즈니스 활동에서 일반적으로 사용되지 않는 정보를 의미합니다. 이러한 데이터는 대개 저장되거나 백업되지만, 분석이나 처리가 이루어지지 않은 상태로 남아 있습니다.
1. 숨겨진 가치: 다크데이터는 종종 숨겨진 통찰력이나 정보를 포함하고 있어 올바르게 분석될 경우 비즈니스 가치를 제공할 수 있습니다.
2. 저장 비용: 데이터는 저장 공간을 차지하며 관리와 백업에 비용이 발생합니다. 사용되지 않는 데이터를 계속해서 저장하는 것은 불필요한 비용을 초래할 수 있습니다.
3. 보안 문제: 다크데이터는 종종 중요한 정보나 개인 식별 정보를 포함할 수 있습니다. 이 데이터의 존재나 위치를 잘 모르는 경우, 데이터 유출의 위험도 증가합니다.
4. 규제 및 준수 문제: 특정 산업군에서는 데이터 보관 및 관리에 관한 규제가 존재합니다. 다크데이터가 이러한 규제를 준수하지 않는 경우 법적 위험이 발생할 수 있습니다.
다크데이터의 발생 원인 중 하나는 빅데이터의 성장과 함께 조직이 수집하는 데이터의 양이 급격히 증가하여 모든 데이터를 적시에 처리하거나 분석하지 못하는 경우
6. SIEM( Security Information and Event Management )
SIEM은 "보안 정보 및 이벤트 관리"(Security Information and Event Management)를 나타내는 약어입니다. SIEM은 보안 경보, 로그 데이터, 그 밖의 보안 관련 정보를 집중적으로 수집, 저장, 분석, 그리고 보고하는 솔루션을 의미합니다. 이러한 기능을 통해 조직은 실시간으로 보안 사건을 모니터링하고, 사건에 대한 대응을 개선할 수 있습니다.
1. 로그 데이터 수집: 서버, 네트워크 장비, 보안 기기, 애플리케이션 등 다양한 소스로부터 로그 데이터를 수집합니다.
2. 로그 저장 및 정규화: 수집된 로그 데이터를 통합적으로 저장하고, 다양한 형식의 로그를 표준화된 형태로 변환합니다.
3. 이벤트 상관 분석: 다양한 이벤트 간의 연관성을 파악하여 복합적인 보안 위협을 탐지합니다.
4. 실시간 모니터링: 실시간으로 보안 사건을 모니터링하고, 위협이 감지되면 즉시 경보를 발생시킵니다.
5. 대시보드 및 보고: 보안 상태, 위협, 이벤트 등에 대한 정보를 시각적으로 제공하며, 주기적 또는 필요에 따른 보고서를 생성합니다.
6. 사건 대응: 보안 사건에 대한 대응 절차나 자동화된 조치를 제공합니다.
SIEM 시스템의 도입은 조직의 보안 상태를 지속적으로 모니터링하고 개선하기 위한 중요한 단계입니다. 하지만 SIEM 솔루션을 효과적으로 운영하기 위해서는 적절한 설정, 지속적인 유지 및 관리, 그리고 전문가의 지식이 필요합니다.
7. TurstZone
TrustZone은 ARM Holdings가 ARM 아키텍처 기반의 마이크로컨트롤러와 프로세서에 도입한 보안 확장 기술입니다. 이 기술은 하드웨어 수준에서 시스템을 '신뢰할 수 있는' 영역(Trusted)과 '신뢰할 수 없는' 영역(Non-Trusted)으로 분리하여, 중요한 데이터나 기능을 보호하려는 목적으로 설계되었습니다.
주요 특징 및 구성 요소는 다음과 같습니다:
1. 보안 상태: TrustZone은 하드웨어 수준에서 두 가지 보안 상태를 제공합니다.
- Secure World (신뢰 영역): 보안 관련 작업을 수행하는 영역입니다. 예를 들어, 암호화 키 관리, 디지털 권한 인증 등의 작업을 처리합니다.
- Non-Secure World (비신뢰 영역): 일반 애플리케이션과 OS가 실행되는 영역입니다.
2. 컨텍스트 전환: 프로세서는 신뢰 영역과 비신뢰 영역 간에 컨텍스트를 전환할 수 있습니다. 이러한 전환은 하드웨어 수준에서 이루어져 보안을 강화합니다.
3. 메모리 보호: TrustZone은 물리적 메모리 영역을 보안 및 비보안 영역으로 분할하여 서로 다른 영역의 접근을 제한합니다.
4. 입출력 보호: 하드웨어 리소스 및 주변 장치에 대한 접근도 TrustZone을 통해 제어할 수 있습니다. 이를 통해 보안이 중요한 작업을 안전하게 수행할 수 있습니다.
TrustZone은 모바일 디바이스뿐만 아니라 IoT 디바이스, 서버 및 클라우드 환경에서도 보안 기능을 강화하는 데 사용됩니다. 그러나 TrustZone만으로 완벽한 보안을 보장하는 것은 아니며, 다른 보안 기술과 조합하여 사용되어야 효과적인 보안을 제공할 수 있습니다.
8. Typosquatting
Typsquatting은 사용자가 일반적인 웹사이트의 URL을 잘못 입력할 때 이를 악용하는 사기 기법입니다. 이 기법에서 공격자는 인기 있는 웹사이트의 도메인 이름에서 약간의 변화(오타)를 주어 새로운 도메인을 등록합니다. 사용자가 이 오타를 저지를 확률이 있을 때, 공격자의 사이트로 리다이렉트되게 됩니다.
예를 들어, "example.com"이라는 웹사이트가 있다고 가정하면, Typsquatting을 시도하는 사람은 "exmaple.com" 또는 "exampl.com" 같은 유사한 도메인을 등록할 수 있습니다.
1.사기 및 피싱: 방문자를 속여서 개인 정보나 금융 정보를 획득하려고 합니다.
2. 광고 수익: 실수로 이동한 사용자에게 광고를 표시하여 수익을 얻습니다.
3. 무분별한 리다이렉션: 오타 도메인을 방문한 사용자를 다른 사이트로 리다이렉트하여 트래픽을 증가시킵니다.
4. 명성 훼손 또는 브랜드 피해: 경쟁 업체나 악의적인 사용자가 특정 브랜드 또는 기관의 명성을 훼손시키려 할 수 있습니다.
5. 도메인 판매: 명성 있는 브랜드나 기업이 오타 도메인을 구매하도록 유도하여 이를 고액으로 판매하려는 시도가 있을 수 있습니다.
사용자는 이러한 위협을 피하기 위해 항상 주의 깊게 웹사이트의 URL을 확인하고, 가능하다면 북마크를 사용하거나 검색 엔진을 통해 웹사이트에 접속하는 것이 좋습니다.
9. OS 스케듈링 기법
운영 체제의 스케줄링은 프로세스나 스레드를 어떻게, 언제 CPU에 할당할지 결정하는 기능입니다. 다양한 스케줄링 알고리즘이 있으며, 각각의 알고리즘은 특정 환경이나 목표에 따라 설계되었습니다.
다음은 주요 스케줄링 알고리즘에 대한 간략한 설명입니다:
1. First-Come, First-Served (FCFS)
- 가장 간단한 스케줄링 방법입니다.
- 프로세스가 도착한 순서대로 CPU를 할당받습니다.
- 단순하지만, 평균 대기 시간이 길어질 수 있습니다.
2. Shortest Job First (SJF):
- 다음에 실행될 작업 중에서 가장 짧은 실행 시간을 가진 작업을 선택합니다.
- 평균 대기 시간을 최소화하는 데 효과적입니다.
- 하지만 실행 시간이 긴 프로세스의 경우 별도의 조치가 없으면 CPU를 할당받지 못하는 문제가 발생할 수 있습니다.
3. Priority Scheduling:
- 각 프로세스에 우선순위를 부여하고, 높은 우선순위를 가진 프로세스부터 CPU를 할당합니다.
- 단, 우선순위가 낮은 프로세스가 계속 대기하는 starvation 문제가 발생할 수 있습니다.
4. Round Robin (RR):
- 각 프로세스에 일정 시간(타임퀀텀)만큼 CPU를 할당하고, 그 시간이 지나면 다음 프로세스에게 넘깁니다.
- 타임퀀텀 설정에 따라 응답 시간과 효율성이 달라집니다.
5. SRT(Shortest Remaining Time):
- 현재 실행중인 프로세스의 남은 시간과 준비상태 규에 새로도착한 프로세스의 실행 시간을 비교하여 가장 짧은 실행 시간을 요구하는 프로세스에게 CPU를 할당하는 기법으로, 시분할 시스템에 유용하다.
10. UML
UML(Unified Modeling Language)은 소프트웨어 공학에서 시스템을 시각화, 설계 및 문서화하기 위한 표준 모델링 언어입니다. UML은 객체 지향 디자인과 관련된 다양한 정보를 그래픽으로 표현할 수 있는 여러 종류의 다이어그램으로 구성되어 있습니다.
UML의 주요 목적은:
- 시스템의 아키텍처를 시각화하고 명세화함으로써 설계의 이해도를 높이기.
- 다양한 관점에서 시스템을 모델링하여 서로 다른 stakeholder의 요구사항을 만족시키기.
- 시스템 설계와 관련된 문서화를 향상시키기.
1. 클래스 다이어그램 (Class Diagram): 시스템의 정적 구조를 나타냅니다. 주로 클래스, 인터페이스, 그리고 이들 간의 관계를 표시합니다.
2. 시퀀스 다이어그램 (Sequence Diagram): 객체 간의 상호 작용을 시간 순서대로 나타냅니다. 주로 시스템의 행동을 표현할 때 사용됩니다.
3. 사용 사례 다이어그램 (Use Case Diagram): 시스템이 제공하는 기능과 사용자(또는 외부 시스템) 간의 상호 작용을 표시합니다.
4. 상태 다이어그램 (State Diagram): 객체의 생명 주기 내에서의 다양한 상태와 그 사이의 전이를 나타냅니다.
5. 활동 다이어그램 (Activity Diagram): 시스템 내의 워크플로우나 프로세스의 흐름을 나타냅니다.
6. 컴포넌트 다이어그램 (Component Diagram): 시스템의 물리적 구성 요소와 그들 간의 종속성을 표현합니다.
7. 배치 다이어그램 (Deployment Diagram): 소프트웨어가 물리적 하드웨어에 어떻게 배치되는지를 나타냅니다.
8. 객체 다이어그램 (Object Diagram): 시스템의 특정 시점에 존재하는 객체와 그들 간의 관계를 나타냅니다.
1. 클래스 (Class):
- 클래스는 객체 지향 시스템에서 개체나 개념을 모델링하는 기본 단위입니다.
- UML 클래스 다이어그램에서는 사각형으로 표시됩니다.
- 클래스는 일반적으로 이름, 속성(attributes), 그리고 메서드(methods) 세 가지 섹션으로 구성됩니다. 이름은 사각형의 맨 위에, 속성은 그 아래에, 메서드는 맨 아래에 위치합니다.
- 예: `Person` 클래스는 `firstName`, `lastName` 속성과 `getFullName()` 메서드를 가질 수 있습니다.
2. 인터페이스 (Interface):
- 인터페이스는 어떤 클래스가 가져야 할 동작을 정의하지만, 그 동작의 구체적인 구현을 포함하지 않습니다.
- UML 클래스 다이어그램에서는 일반적으로 사각형 위에 위치한 작은 원 모양의 고리로 표시됩니다.
- 인터페이스의 이름은 종종 이탤릭체로 표시됩니다.
- 클래스는 인터페이스를 구현(implement) 할 수 있습니다. 이러한 관계는 점선 화살표로 표시되며, 화살표는 구현하는 클래스에서 인터페이스로 향합니다.
3. 관계 (Relationship):
UML에서는 클래스와 인터페이스 간의 여러 종류의 관계를 모델링할 수 있습니다. 주요 관계 유형은 다음과 같습니다:
- 연관 (Association): 두 클래스 사이에 일반적인 관계를 나타냅니다. 연관 관계는 평범한 선으로 표시되며, 종종 관계의 방향, 이름, 다중성(multiplicity) 등의 추가 정보를 포함할 수 있습니다.
- 계승 (Inheritance)/일반화 (Generalization): 한 클래스가 다른 클래스로부터 속성과 동작을 상속받는 관계를 나타냅니다. 이 관계는 화살표가 있는 선으로 표시되며, 화살표는 하위 클래스(subclass)에서 상위 클래스(superclass)로 향합니다.
- 구현 (Implementation): 클래스가 인터페이스의 동작을 구현하는 관계를 나타냅니다. 점선 화살표로 표시되며, 화살표는 구현하는 클래스에서 인터페이스로 향합니다.
- 집합 (Aggregation): 하나의 클래스 객체가 다른 클래스 객체의 집합을 나타내는 경우에 사용됩니다. 빈 다이아몬드 모양으로 표시되는 선으로 나타냅니다.
- 합성 (Composition): 하나의 클래스 객체가 다른 클래스 객체를 포함하며, 포함되는 객체의 생명 주기가 포함하는 객체에 의존하는 관계를 나타냅니다. 채워진 다이아몬드 모양으로 표시되는 선으로 나타냅니다.
11. 관계해석
데이터베이스의 관계 해석(Relationship Interpretation)은 주로 엔터티 간의 관계를 분석하고 이해하는 과정을 말합니다. 관계형 데이터베이스에서는 이러한 관계를 통해 다양한 테이블 간의 연결을 표현하고 데이터를 조직화합니다.
데이터베이스 설계의 초기 단계에서는 엔터티 관계 다이어그램(Entity-Relationship Diagram, ERD)을 사용하여 시스템의 주요 엔터티와 그들 사이의 관계를 시각적으로 나타냅니다. ERD를 통해 관계를 해석하면 데이터베이스의 전체 구조와 동작을 이해하는 데 도움이 됩니다.
1. 엔터티 (Entity): 데이터베이스에서 저장하려는 정보의 단위나 개체입니다. 예를 들면, '학생', '강의', '도서' 등이 될 수 있습니다.
2. 속성 (Attribute): 엔터티의 특성을 나타냅니다. '학생' 엔터티의 경우 '학번', '이름', '전공' 등의 속성을 가질 수 있습니다.
3. 관계 (Relationship): 두 엔터티 사이의 연결을 나타냅니다. 예를 들어, '학생'과 '강의' 엔터티 사이에는 '수강한다'라는 관계가 존재할 수 있습니다.
4. 다중성 (Cardinality): 관계의 강도를 나타냅니다. 예를 들면, 한 학생이 여러 강의를 수강할 수 있고, 한 강의에는 여러 학생이 수강할 수 있습니다. 이러한 관계의 다중성은 '다대다'로 표현됩니다.
다중성의 주요 유형은:
- 일대일 (One-to-One): 한 엔터티 인스턴스가 다른 엔터티 인스턴스와 단 하나만 관련될 수 있습니다.
- 일대다 (One-to-Many) 또는 다대일 (Many-to-One): 한 엔터티 인스턴스가 다른 엔터티의 여러 인스턴스와 관련될 수 있습니다.
- 다대다 (Many-to-Many): 한 엔터티의 여러 인스턴스가 다른 엔터티의 여러 인스턴스와 관련될 수 있습니다.