woongs dogfoot

Database를 선택하는 방법

1. 읽기량/쓰기량 고려
2. 데이터 처리량 고려
3. 데이터 저장량
4. 데이터 저장 기간
5. 평균 객체 크기
6. 객체에 접근하는 방법
7. 확장이 가능한지?
8. 데이터 공급원은 어디인지?
9. 데이터 내구성이 있는지?
10. 지연시간에 관한 요구사항이 있는지?
11. 동시 사용자에 관한 요구사항이 있는지?
12. 데이터 모델이 뭔지?
13. 쿼리 방법이 뭔지?
14. 데이터 join이 많은지?
15. 정규화? 반정규화?
16. 유연성이 있는지?
17. reporting이 필요한지?
18. 관계형? NoSQL?
19. 라이선스 비용이 있는지?
    
    
    

• Database Types

1. RDBMS : RDS, Aurora
2. NoSQL : DynamoDB(JSON), ElastiCache(key-value), Neptune(Graphs), MongoDB(DocumentDB), Apache Cassandra(Keyspaces)
3. Object Store : S3, Glacier
4. Data Warehouse : Redshift(OLAP), Athena. EMR
5. Search : OpenSearch(JSON)
6. Graphs : Amazon Neptune
7. Ledger : Amazon Quantum Ledger Database
8. Time series : Amazon Timestream
   
   
   

RDS

1. PostgreSQL, MySQL, Oracle, SQL Server, MariaDB 지원
2. RDS 인스턴스 크기 및 EBS Volume Type/Size를 사전 지정해야 함
3. 스토리지에 대한 Auto-scaling 기능이 있음
4. 읽기 전용 복제본 지원
5. 고가용성 목적으로 Standby DB를 다중 AZ에 배치할 수 있음 (해당 DB엔 쿼리 실행 불가)
6. IAM을 통해 사용자 보안조치 가능 (사용자이름/비밀번호, 일부 사용자에게 IAM 인증 부여)
7. Security Groups을 통해 네트워크 보안
8. KMS를 통해 데이터 저장 보안
9. SSL을 통해 전송 데이터 보안
10. 최대 35일의 자동 백업 옵션 -> 해당 기간 내 새로운 DB로 복구 가능
11. 장기 보존 백업이 필요한 경우 DB Snapshot 이용 가능
12. 패치 작업 등을 위해 downtime이 있을 수 있음
13. RDS Proxy를 추가하여 RDS에 IAM 인증 추가
14. Secrets Manager와 통합하여 DB 자격증명 관리
15. RDS 인스턴스에 접근을 위한 사용자 지정옵션 있음 (Oracle / SQL Server)
16. 관계형 DB 및 OLTP를 저장하는데 활용
    
    
    

Aurora

1. PostgreSQL, MySQL 지원
2. 스토리지와 컴퓨팅이 구분됨
3. 기본 설정으로 3개 AZ에 6개의 인스턴스로 나누어 데이터를 저장함 -> 고가용성
4. 자동 자가복구 과정이 있음
5. 스토리지에 대한 Auto-scaling 기능이 있음 (읽기 전용 복제본도 가능)
6. DB Cluster가 구축되어 있기 때문에 어느 인스턴스에 접근하여 읽고 쓸지를 결정하기 위해 별도 endpoint가 필요 (writer endpoint, reader endpoint)
7. RDS와 동일한 Security/monitoring/maintenance 기능이 있음 -> 같은 엔진 활용
8. Aurora를 위한 백업 및 복구 기능이 있음
9. Aurora Serverless -> 예측할 수 없는 간헐적인 workload가 있을 때 용량을 별도로 계획하지 않아도 되기 때문에 유용함
10. Global DB를 위해 Aurora Global이 사용됨 -> 16개의 read전용 인스턴스가 각 region에 배포됨 -> 1초 미만의 실시간 스토리지 복제 -> 특정 region에 문제가 생겼을 때, 다른 region의 DB를 주요 region으로 승격시킬 수 있음
11. 머신러닝을 위한 Aurora Machine Learning 모듈이 있음
12. 테스트 DB 및 스테이징 DB를 위해 Aurora cloning 기능이 있음, snapshot을 복구하는 것보다 빠름 -> 새로운 cluster 구축
13. RDS보다 비용이 더 비싸지만, 더 유연성있고, 덜 관리하고, 더 좋은 성능, 더 많은 기능을 원하면 사용
    
    
    

ElastiCache

1. Redis / Memcached 두 종류
2. 캐싱작업에 활용
3. in-memory store
4. 1ms 미만의 읽기 성능을 제공
5. 캐싱을 위한 EC2 인스턴스가 프로비저닝 되어야 함
6. Redis에서는 Clustering 기능 제공 및 Multi-AZ, Sharding을 통한 읽기 전용 복제본 제공
7. IAM을 통한 접근 보안, Security Groups(네트워크 수준의 접근), KMS(데이터 저장), Redis Auth가 있음
8. RDS처럼 백업 및 Snapshot, point in time restore 기능 제공
9. app code가 ElastiCache를 사용하도록 수정 필요
10. Use Cases : key-value store, 빈번한 읽기, DB 쿼리 캐싱, 세션 데이터 저장 등
11. SQL 사용 불가
    
    
    

DynamoDB

1. ms단위의 성능을 제공하는 Serverless NoSQL DB
2. provisioned capacity mode : 지정된 용량 범위 내에서 auto scaling, 점진적인 증감이 있을 떄 활용
3. on-demand capacity mode : 용량을 프로비저닝할 필요가 없음, 예측하기 어려운 workload에 따라 자동으로 scaling, 가파른 증감이 있을 때 활용
4. key-value 저장소 -> elastiCache 대체 가능
5. 세션 데이터를 저장하기 좋음 -> TTL 기능으로 일정 시간 뒤에 세션을 만료시킴
6. 고가용성 -> Multi-AZ, 읽기/쓰기 분리
7. DynamoDB와 완벽히 호환되는 캐싱 기능인 DAX cluster 제공 (ms단위의 읽기 성능)
8. 보안/인증/인가 등의 기능이 모두 IAM을 통해 이루어짐
9. DynamoDB Streams를 활성화하여 이벤트 처리 기능도 추가할 수 있음 (DynamoDB Streams : DB에 일어나는 변경사항을 감지하여 스트리밍) -> Lambda, Kinesis Data Streams등과 결합하여 이벤트 처리)
10. Global Tables 기능 제공 -> 다수 region에 걸친 active-active 복제 가능
11. 최대 35일의 자동 백업 옵션 (point in time restore 기능 활성화 필요) -> 자동백업 옵션을 활용하여 S3로 데이터를 내보내면, RCU사용없이 PITR window로 가능, S3에서 새로운 테이블로 가져올 때에도 WCU 사용없이 가능
12. 장기 보관을 위한 On-demand 백업 옵션
13. 빠르게 스키마를 변경하거나, 유연하게 변경해야할 때 유용
    
    
    

S3

1. key-value 형태로 저장 -> 큰 객체를 저장할 때 유용, 여러 개의 작은 객체를 저장할 때는 비효율
2. Serverless
3. 객체 최대 크기 5TB
4. Versioning 기능
5. 다양한 스토리지 지원, Storage tiers : S3 Standard, S3 Infrequent Access, S3 Intelligent, S3 Glacier + tier 전환을 위한 lifecycle policy
6. Versioing, Encryption, 복제, 영구삭제를 위한 MFA, logs 등의 기능들을 제공
7. IAM을 통한 접근 보안, 버킷에 대한 접근 권한인 S3 Bucket Policy, Access Point 생성, ACL, CORS, 객체 잠금 기능 등 보안기능 제공
8. Encryption : SSE-S3 (자체키 기반), SSE-KMS (관리할 수 있는 KMS키 기반), SSE-C, client-side 인증, TLS 전송보안
9. S3 객체에 대한 대량 처리가 필요할 때 -> S3 Batch (use case : 비암호화 객체 일괄 암호화 등)
10. 성능 : Multi-part upload (파일 병렬식 upload), S3 Transfer Acceleration, S3 Select (필요한 데이터만 검색)
11. Automation : S3 Event Notifications (SNS, SQS, Lambda 등과 결합 가능)
12. Use cases : 정적 파일, key-value 형태의 대량 file 저장소, 웹사이트 호스팅 등
    
    
    

DocumentDB (mongoDB)

1. DocumentDB는 MongoDB의 Aurora 버전
2. NoSQL DB
3. mongoDB 기반
4. JSON 데이터를 저장, 쿼리, 인덱스
5. 배포개념이 Aurora와 유사 -> 완전 관리형 DB, 3 AZ에 걸친 고가용성
6. 스토리지는 자동적으로 10GB까지 확장됨
7. 초당 수백만개의 요청을 작업하기 위해 scale될 수 있음
   
   
   

Amazon Neptune

• Graph 데이터셋의 예시 : Social Network -> 과정(데이터)들이 모두 연결됨
  1. 사용자는 친구를 팔로우
  2. 댓글을 게시
  3. 다른 사용자의 댓글을 좋아요
  4. 게시글을 공유
     
     
     

1. 완전 관리형 graph DB
2. like Social Network
3. 3 AZ에 걸쳐 최대 15개의 읽기전용 복제본을 가짐 -> 가용성이 높음
4. 고도로 연결된 데이터 셋을 사용하는 app에 적합
5. DB에 수십억 개의 관계를 저장
6. 그래프를 쿼리할 때의 지연시간은 ms단위
7. 위키피디아 지식 데이터와 같이 고도로 연결되어 있는 데이터에 적합 (추천 엔진, 소셜 네트워크 등)
   
   
   

Amazon Keyspaces (Apache Cassandra)

1. Apache Cassandra를 지원
2. Apache Cassandra : 오픈 소스의 NoSQL 분산 DB
3. Serverless
4. 완전 관리형, 확장성/가용성 높음
5. app 트래픽에 따른 Auto Scaling 기능 제공
6. 테이블 데이터는 여러 AZ에 걸쳐 세 번 복제됨
7. 쿼리 수행에는 CQL(Cassandra Query Language)가 사용됨
8. 지연시간 10ms
9. 초당 수천 건의 요청 처리
10. On-demand mode과 Provisioned mode with auto-scaling 두 가지 모드 지원 (DynamoDB와 동일)
11. 암호화, 백업, 최대 35일의 PITR 기능 제공
12. Use cases : IoT 장치 정보와 시계열 데이터 저장 등
    
    
    

Amazon QLDB

1. Quantum Ledger Database
2. Ledger : 금융 트랜잭션을 기록하는 장부
3. 완전 관리형, Serverless, 고가용성 (3개 AZ에 걸쳐 복제)
4. app 데이터의 시간에 따른 변경 내역을 검토하는 데 사용 -> 장부
5. DB에 데이터를 기록하면 삭제하거나 수정할 수 없음 -> 불변 시스템
6. QLDB Journal내에서 수정할 때마다 암호화 해시가 계산되어 추가됨 -> DB에서 삭제 불가, 수정본 추가방식(?)
7. 일반 ledger blockchain framework보다 2~3배 나은 성능
8. 관리형 블록체인과의 차이점은 QLDB는 탈중앙화 개념이 없음 -> Amazon 소유의 중앙 DB에서만 데이터 작성 가능

Amazon Timestream

1. 시계열 DB
2. 완전 관리형, 빠름, scale 가능, serverless
3. 시계열(timestream) : 시간정보를 포함하는 point의 모음
4. DB의 용량을 자동으로 확장/축소 가능
5. 매일 수조 건의 이벤트를 저장/분석 가능
6. 시계열 데이터에는 관계형 DB보다 시계열 DB를 활용하는 것이 속도나 비용측면에서 훨씬 이점
7. SQL에 호환
8. 최신 데이터는 메모리에 저장
9. 과거 데이터는 비용 효율적인 스토리지 계층에 저장
10. 시계열 분석 기능이 있어서 실시간으로 분석하고 패턴을 찾을 수 있음
11. 전송중 암호화, 저장 암호화를 지원
12. Use cases : IoT apps, 실시간 분석, 운영 app 등
    
    
    

• Architecture

SQLD 시험 준비

• 모델링의 정의

1. 정보시스템을 구축하기 위한 데이터 관점의 업무 분석 기법
2. 현실세계의 데이터에 대해 약속된 표기법에 의해 표현하는 과정
3. 데이터베이스를 구축하기 위한 분석/설계의 과정
   
   

• 모델링의 특징

1. 추상화 : 현실세계를 일정한 형식에 맞추어 표현
2. 단순화 : 복잡한 현실세계를 약속된 규약에 의해 제한된 표기법이나 언어로 표현하여 쉽게 이해할 수 있도록 하는 개념
3. 명확화 : 누구나 이해하기 쉽게 하기 위해 대상에 대한 애매모호함을 제거하고 정확하게 현상을 기술
   
   

• 모델링의 관점

1. 데이터 관점 : 업무가 어떤 데이터와 관련이 있는지 또는 데이터 간의 관계는 무엇인지?
2. 프로세스 관점 : 실제하고 있는 업무는 무엇인지 또는 무엇을 해야하는지?
3. 데이터와 프로세스의 상관 관점 : 업무가 처리하는 일의 방법에 따라 데이터는 어떻게 영향을 받고 있는지?
   
   

• 모델링이 중요한 이유

1. 파급효과 : 데이터 구조 변경 시, 영향도가 큼
2. 복잡한 정보 요구 사항의 간결한 표현 : 데이터 모델은 건축물로 비유하자면 설계 도면
3. 데이터 품질 : 아래는 유의할 점
   1. 중복 : 여러 장소에 같은 정보 저장 x
   2. 비유연성 : 데이터의 정의를 데이터의 사용 프로세스와 분리함으로서 영향도 줄임
   3. 비일관성 : ex. 신용상태에 대한 갱신 없이 고객의 납부 이력 정보를 갱신 => 납부이력정보와 신용상태는 동시에 갱신되어야 함
      
      

• 데이터 모델링의 3단계 : 아래로 내려갈수록 구체적, 위로 올라갈수록 추상적 => 보통 아래 순서대로 데이터 모델링이 진행됨

1. 개념적 데이터 모델링 : 추상화 수준이 높고 업무 중심적이고 포괄적인 수준의 모델링 진행. 전사적 데이터 모델링, EA 수립 시 많이 이용
2. 논리적 데이터 모델링 : 시스템으로 구축하고자 하는 업무에 대해 Key, 속성, 관계 등을 정확하게 표현, 재사용성이 높음
3. 물리적 데이터 모델링 : 실제로 데이터베이스에 이식할 수 있도록 성능, 저장 등 물리적인 성격을 고려하여 설계
   
   

• 데이터베이스 3단계 구조 : 화면과 데이터베이스 간의 독립성 유지를 위함

1. 외부 스키마 : 개개 사용자 단계로서 개개 사용자가 보는 개인적 DB 스키마
2. 개념 스키마 : 모든 사용자 관점을 통합한 조직 전체의 DB를 기술하는 것
3. 내부 스키마 : 물리적 장치에서 데이터가 실제적으로 저장되는 방법을 표현하는 스키마
   
   

• 데이터 모델링의 세 가지 요소

1. 업무가 관여하는 어떤 것 (Thins)
2. 어떤 것이 가지는 성격 (Attributes)
3. 업무가 관여하는 어떤 것 간의 관계 (Relationships)
   
   

• ERD 작업순서

1. 엔터티를 그린다.
2. 엔터티를 적절하게 배치한다.
3. 엔터티 간 관계를 설정한다.
4. 관계명을 기술한다.
5. 관계의 참여도를 기술한다.
6. 관계의 필수여부를 기술한다.
   
   

• 엔터티의 특징

1. 반드시 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다.
2. 유일한 식별자에 의해 식별이 가능해야 한다.
3. 영속적으로 존재하는 인스턴스의 집합이어야 한다.
4. 엔터티는 업무 프로세스에 의해 이용되어야 한다.
5. 엔터티는 반드시 속성이 있어야 한다.
6. 엔터티는 다른 엔터티와 최소 한 개 이상의 관계가 있어야 한다.
   
   

• 엔터티의 관계가 필요 없는 경우

1. 통계를 위한 엔터티
2. 코드를 위한 엔터티
3. 시스템 처리 시 내부 필요에 의한 엔터티
   
   

• 엔터티의 분류

1. 유무형에 따른 분류
   1. 유형엔터티 : 물리적인 형태가 있고 안정적이며 지속적으로 활용되는 엔터티 (ex. 사원, 물품, 강사)
   2. 개념엔터티 : 물티적인 형태가 없지만 관리해야 할 개념정 정보로 구분되는 엔터티 (ex. 조직, 보험상품)
   3. 사건엔터티 : 업무를 수행함에 따라 발생하는 엔터티 (ex. 주문, 청구, 미납)
2. 발생시점에 따른 분류
   1. 기본엔터티 : 다른 엔터티와의 관계에 의한 것이 아닌 독립적으로 생성이 가능하고 타 엔터티의 부모 역할이 되는 엔터티 (ex. 사원, 부서, 고객, 상품, 자재)
   2. 중심엔터티 : 기본엔터티로부터 발생되고 업무에서 중심적인 역할을 하는 엔터티 (ex. 계약, 사고, 예금원장, 청구, 주문, 매출)
   3. 행위엔터티 : 두 개 이상의 부모엔터티로부터 발생하고, 자주 내용이 바뀌거나 데이터 양이 증가하는 엔터티 (ex. 주문목록, 사원변경이력)
      
      

• 속성 : 업무에서 필요로 하는 인스턴스에서 관리하고자 하는 의미상 더이상 분리되지 않는 최소의 데이터 단위
  
  

• 속성의 특징

1. 반드시 해당 업무에서 필요하고 관리하고자 하는 정보여야 한다.
2. 정규화 이론에 근거하여 정해진 주식별자에 함수적 종속성을 가져야 한다.
3. 하나의 속성은 한 개의 값만을 가진다.
   
   

• 속성의 특성에 따른 분류

1. 기본속성 : 업무로부터 추출한 모든 속성
2. 설계속성 : 업무상 필요한 데이터 이외에 데이터 모델링 및 업무를 규칙화하기 위해 새로 만들거나 변형한 속성 (ex. 일련번호)
3. 파생속성 : 다른 속성에 영향을 받아 발생하는 속성, 보통 계산된 값들이 이에 해당, 가급적 적게 정의하는 것이 좋음.
   
   

• 관계 정의 시, 체크할 사항

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

• 식별자의 특징

1. 유일성 : 주식별자에 의해 엔터티 내에 모든 인스턴스들이 유일하게 구분되어야 한다.
2. 최소성 : 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수가 되어야 한다.
3. 불변성 : 지정된 주식별자의 값은 자주 변하지 않는 것이어야 한다.
4. 존재성 : 주식별자가 지정이 되면 반드시 값이 들어와야 한다.
   
   

• 식별자 분류

1. 대표성 여부
   1. 주식별자 : 엔터티 내에서 각 어커런스를 구분할 수 있고, 타 엔터티와 참조관계를 연결할 수 있는 식별자
   2. 보조식별자 : 엔터티 내에서 각 어커런스를 구분할 수 있지만, 대표성을 가지지 못해 참조관계 연결을 못하는 식별자
2. 스스로 생성 여부
   1. 내부식별자 : 엔터티 내부에서 스스로 만들어지는 식별자
   2. 외부식별자 : 타 엔터티와의 관계를 통해 타 엔터티로부터 받아오는 식별자
3. 속성 수
   1. 단일식별자 : 하나의 속성으로 구성된 식별자
   2. 복합식별자 : 둘 이상의 속성으로 구성된 식별자
4. 대체 여부
   1. 본질식별자 : 업무에 의해 만들어지는 식별자
   2. 인조식별자 : 업무적으로 만들어지지는 않지만 원조식별자가 복잡한 구성을 갖고 있기 때문에 인위적으로 만든 식별자
      
      

• 주식별자 도출 기준

1. 해당 업무에서 자주 이용되는 속성을 주식별자로 지정
2. 명칭, 내역 등과 같이 이름으로 기술되는 것들은 가능하면 주식별자로 지정하지 않는다.
3. 복합으로 주식별자로 구성할 경우 너무 많은 속성이 포함되지 않도록 한다.
   
   

• 식별자관계 : 부모로부터 받은 식별자를 자식엔터티의 주식별자로 이용하는 경우는 Null값이 오면 안되므로 반드시 부모엔터티가 생성되어야 자기 자신의 엔터티가 생성되는 관계

  • 문제점 : PK수 증가

• 비식별자관계 : 부모엔터티로부터 속성을 받았지만 자식엔터티의 주식별자로 사용하지 않고 일반적인 속성으로만 사용하는 관계

  • 문제점 : 부모엔터티의 PK조건으로 자식엔터티의 속성을 조회해야 할 때, 불필요한 join이 들어감
    
    

• 제1정규형 : 모든 속성은 반드시 하나의 값을 가져야 한다. (Ex. 연락처 = 02-123-4567, 010-1234-5678 => x)(ex. Entity : 주문번호/상품번호1/상품명1/상품번호2/상품명2/고객번호/고객명 => x)

  • 부모-자식 엔터티 관계형성으로 해결, 자식엔터티로 생성

• 제2정규형 : 엔터티의 일반속성은 주식별자 전체에 종속적이어야 한다. (Ex. 상품명은 오직 주식별자인 상품번호에 의해서만 결정된다, 주식별자가 상품번호 1개임을 가정)

  • M:M 관계형성으로 해결

• 제3정규형 : 엔터티 일반속성 간에는 서고 종속적이지 않는다. (Ex. 고객번호는 주문번호에 종속, 고객명은 고객번호에 종속=>고객명은 주문번호에 종속 ==> 이행 종속성이므로 제3정규형 위반)

  • 부모-자식 엔터티 관계형성으로 해결, 위 예제에서는 고객을 부모엔터티로 생성
    
    

• 반정규화 : 성능을 위해 데이터 중복을 허용, 정규화의 반대

  • 성능이 향상될 수 있는 경우 : 잦은 조회 쿼리의 join 횟수가 많은 경우
  • 성능이 저하될 수 있는 경우 : 불필요한 UPDATE로직이 추가될 수 있음
    
    

• 계층형 데이터 모델 : 엔터티의 인스턴스간 계층이 존재할 때의 데이터 모델

1. 데이터 조회 시, 셀프조인 발생
   
   

• Null 속성의 이해

1. Null 값의 연산은 언제나 Null
2. 집계함수는 Null 값을 제외하고 처리한다.
   
   

• SQL의 종류

1. 데이터 조작어 (DML) : SELECT, INSERT, UPDATE, DELETE
2. 데이터 정의어 (DDL) : CREATE, ALTER, DROP, RENAME
3. 데이터 제어어 (DCL) : GRANT, REVOKE
4. 트랜잭션 제어어 (TCL) : COMMIT, ROLLBACK
   
   

• 합성연산자 : || 또는 CONCAT(string1, string2)
  
  

• 단일행 함수의 종류

1. 문자형 함수 : LOWER, UPPER, ASCII, CHR/CHAR, CONCAT, SUBSTR/SUBSTRING, LENGTH/LEN, LTRIM, RTRIM, TRIM
2. 숫자형 함수 : ABS, SIGN, MOD, CEIL/CEILING, FLOOR, ROUND, TRUNC, SIN, COS, TAN, EXP, POWER, SQRT, LOG, LN
3. 날짜형 함수 : SYSDATE/GETDATE, EXTRACT/DATEPART, TO_NUMBER(TO_CHAR(d, ‘YYYY’|’MM’’|DD’))/YEAR|MONTH|DAY
4. 변환형 함수 : (CAST, TO_NUMBER, TO_CHAR, TO_DATE)/(CAST, CONVERT)
5. NULL 관련 함수 : NVL/ISNULL, NULLIF, COALESCE
   
   

• ASCII <-> CHR/CHAR

• LTRIM : 첫 문자부터 확인해서 지정 문자가 나타나면 해당 문자를 제거 (디폴트는 공백)

• TRIM : 문자열에서 머리말, 꼬리말 또는 양쪽에 있는 지정 문자를 제거 (디폴트는 both)

• MOD : 숫자를 나누어 나머지 값을 리턴 (%로 대체 가능)

• SIGN : 숫자가 양수인지, 음수인지 0인지를 구별

• TRUNC : 숫자를 소수 m자리에서 잘라서 버림 (디폴트는 0)

• POWER : 숫자의 거듭제곱 값을 리턴

• EXTRACT/DATEPART : 날짜 데이터에서 연월일 데이터를 출력
  
  

• CASE 표현

1. CASE (표현식) WHEN 기준값1 THEN 값1 WHEN 기준값2 THEN 값2 ELSE 디폴트값 END
2. Oracle 한정 : DECODE(표현식, [기준값1, 값1, 기준값2, 값2, … , 디폴트값]) : 표현식이 기준값1이면 값1을, 기준값2이면 값2를 리턴하고, 부합하는 기준값이 없을 경우, 디폴트값 리턴
   
   

• NULLIF(식1, 식2) : 식1이 식2의 결과와 같을 경우 null, 다를 경우 식1 리턴
  
  

• 연산자의 우선순위

1. 괄호
2. 비교 연산자, SQL 연산자
3. NOT 연산자
4. AND
5. OR
   
   

• 집계함수의 종류

1. COUNT(*) : NULL 값을 포함한 행의 수를 출력
2. COUNT(표현식) : 표현식의 값이 NULL 값인 것을 제외한 행 수를 출력
3. STDDEV : 표준 편차를 출력
4. VARIANCE/VAR : 분산을 출력
   
   

• 집계함수는 WHERE 절에 올 수 없다.

• GROUP BY는 NULL을 무시한다.

• GROUP BY 보다 WHERE 절이 먼저 수행된다.

• HAVING 절은 GROUP BY 절의 기준 항목이나 소그룹의 집계함수를 이용한 조건을 표시할 수 있다.
  
  

• SELECT 문장 실행 순서

1. FROM
2. WHERE
3. GROUP BY
4. HAVING
5. SELECT
6. ORDER BY
   
   

• EQUI JOIN : 두 테이블 간에 칼럼 값들이 서로 정확하게 일치하는 경우에 사용되는 방법

• Non EQUI JOIN : 두 개의 테이블 간에 논리적인 연관 관계는 갖고 있으나, 칼럼 값들이 서로 일치하지 않는 경우에 사용 (등호가 아닌 부등호나 BETWEEN 사용)

• OUTER JOIN : 조인 조건이 안맞아도 데이터를 조회하려고 할 때 사용되는 방법 (LEFT, RIGHT가 있음, 값이 없을 경우 NULL)
  
  

• FROM 절의 JOIN 형태

1. INNER JOIN : 조인 조건을 만족하는 행들만 반환
2. NATURAL JOIN : 두 테이블 간에 동일한 이름을 갖는 모든 칼럼들에 대해 EQUI JOIN 수행
3. USING 조건절 : NATURAL JOIN에서 USING 조건절을 활용하여 원하는 칼럼에 대해서만 선택적으로 EQUI JOIN 수행
4. ON 조건절 : JOIN 조건 설정, 칼럼명이 달라도 JOIN 가능
5. CROSS JOIN : 두 테이블간 JOIN 조건이 없는 경우 생길 수 있는 모든 데이터의 조합 (M * N 건의 데이터 조합 발생)
6. OUTER JOIN
   
   

• 동작하는 방식에 따른 서브 쿼리 분류

1. 비연관 서브 쿼리 : 서브 쿼리가 메인 쿼리 컬럼을 갖고 있지 않는 형태의 서브 쿼리다. 메인 쿼리에 값을 제공하기 위한 목적으로 주로 사용한다.
2. 연관 서브 쿼리 : 서브 쿼리가 메인 쿼리 칼럼을 갖고 있는 형태의 서브 쿼리다. 일반적으로 메인 쿼리가 먼저 수행돼 읽혀진 데이터를 서브 쿼리에서 조건이 맞는지 확인하고자 할 때 주로 사용한다. 서브 쿼리 내에 메인 쿼리 칼럼이 사용된 서브 쿼리
   
   

• 반환되는 데이터의 형태에 따른 서브 쿼리 분류

1. Single Row 서브 쿼리 : 서브 쿼리의 실행 결과가 항상 1건 이하인 서브 쿼리, 단일 행 비교 연산자와 함께 사용 (ex. =, < 등)
2. Multi Row 서브 쿼리 : 서브 쿼리의 실행 결과가 여러 건인 서브 쿼리, 다중 행 비교 연산자와 함께 사용 (ex. In, all, exists 등)
3. Multi Column 서브 쿼리 : 서브 쿼리의 실행 결과로 여러 칼럼을 반환
   
   

• 다중 행 비교 연산자

1. IN : 서브 쿼리의 결과에 존재하는 임의의 값과 동일한 조건
2. ALL : 서브 쿼리의 결과에 존재하는 모든 값을 만족하는 조건
3. ANY : 서브 쿼리의 결과에 존재하는 어느 하나의 값이라도 만족하는 조건
4. EXISTS : 서브 쿼리의 결과가 존재하는지 여부를 확인하는 조건
   
   

• 뷰 사용의 장점

1. 독립성 : 테이블 구조가 변경돼도 뷰를 사용하는 응용 프로그램은 변경하지 않아도 된다.
2. 편리성 : 복잡한 질의를 뷰로 생성함으로써 관련 질의를 단순하게 작성할 수 있다.
3. 보안성 : 숨기고 싶은 정보는 빼고 생성하여 사용자에게 정보를 감출 수 있다.
   
   

• 집합연산자

1. UNION : 개별 SQL 문의 결과에 대해 합집합 연산을 수행
2. UNION ALL : 개별 SQL 문의 결과에 대해 합집합 연산을 수행하며, 중복된 행도 그대로 표시
3. INTERSECT : 개별 SQL 문의 결과에 대해 교집합 연산을 수행
4. EXCEPT : 개별 SQL 문의 결과에 대해 차집합 연산을 수행
   
   

• ROLLUP : GROUP BY 칼럼의 GROUP 별 집계 (TOTAL) 수행 및 GROUP 정렬, 상세 칼럼도 정렬이 필요할 경우, ORDER BY 도 병행 사용

• GROUPING : 소계가 계산된 결과에는 1이 표시됨, 그렇지 않은 경우는 0이 표시됨

• GROUPING SETS : GROUP BY 모든 칼럼에 대해 GROUPING 수행, 칼럼 순서가 바껴도 조회결과는 같음 (ex. GROUP BY GROUPING SETS (A, B) : count(A) + count(B) 개의 칼럼 조회)
  
  

• WINDOW FUNCTION SYNTAX : SELECT WINDOW_FUNCTION (ARGUMENTS) OVER ([PARTITION BY 칼럼] [ORDER BY 절] [WINDOWING 절]) FROM 테이블명;

1. ARGUMENTS : 함수에 따라 0 ~ N개의 인수가 지정될 수 있다.
2. PARTITION BY 절 : 전체 집합을 기준에 의해 소그룹으로 나눌 수 있다.
3. ORDER BY 절 : 어떤 항목에 대해 순위를 지정할지 ORDER BY 절을 기술한다.
4. WINDOWING 절 : WINDOWING 절은 함수의 대상이 되는 행 기준의 범위를 강력하게 지정할 수 있다.
   
   

• RANK : ORDER BY를 포함한 QUERY 문에서 특정 항목에 대한 순위를 구하는 함수, PARTITION 포함 시, 특정 컬럼별로 RANK가 지정됨

• DENSE_RANK : RANK 함수와 유사하나 동일한 순위를 하나의 건수로 취급

• ROW_NUMBER : RANK나 DENSE_RANK 함수와는 다르게 동일한 값이라도 고유한 순위를 부여

• FIRST_VALUE : 파티션별 윈도우에서 가장 먼저 나온 값 (SQL_SERVER (x))

• LAST_VALUE : 파티션별 윈도우에서 가장 나중에 나온 값 (SQL_SERVER (x))

• LAG : 파티션별 윈도우에서 이전 몇 번째 행의 값 (SQL_SERVER (x))

• LEAD : 파티션별 윈도우에서 이후 몇 번째 행의 값 (SQL_SERVER (x))

• RATIO_TO_REPORT : 파티션 내 전체 SUM(칼럼) 값에 대한 행별 칼럼 값의 백분율을 소수점으로 구할 수 있음 (SQL_SERVER (x))

• PERCENT_RANK : 파티션별 윈도우에서 제일 먼저 나오는 것을 0으로, 제일 늦게 나오는 것을 1로 해, 값이 아닌 행의 순서별 백분율을 구한다. (SQL_SERVER (x))

• CUME_DIST : 파티션별 윈도우의 전체 건수에서 현재 행보다 작거나 같은 건수에 대한 누적백분율을 구한다. 결과 값은 > 0 & <= 1 (SQL_SERVER (x))

• NTILE : 파티션별 전체 건수를 ARGUMENT 값으로 N 등분한 결과, N개씩 그룹이 나누어짐
  
  

• TOP (Expression) [PERCENT] [WITH TIES] : SQL Server 한정

1. Expression : 반환할 행 수를 지정하는 숫자
2. PERCENT : 쿼리 결과 집합에서 처음 Expression%의 행만 반환
3. WITH TIES : ORDER BY 절이 지정된 경우에만 사용, TOP N(PERCENT)의 마지막 행과 같은 값이 있는 경우 추가 행이 출력되도록 지정 가능
   
   

• ROW LIMITTING절 (ORDER BY 절 다음에 기술)

1. Syntax1 : [OFFSET offset {ROW | ROWS}]
2. Syntax2 : [FETCH {FIRST | NEXT} [{row count | percent PERCENT}] {ROW | ROWS} {ONLY | WITH TIES}]
3. OFFSET offset : 건너뛸 행의 개수를 지정
4. FETCH : 반환할 행의 개수나 백분율을 지정
5. ONLY : 지정된 행의 개수나 백분율만큼 행을 반환
6. WITH TIES : 마지막 행에 대한 동순위를 포함해서 반환
   
   

• Oracle 계층형 질의
  SELECT …
  FROM 테이블
  WHERE condition
  AND condition
  START WITH condition
  AND condition
  CONNECT BY [NOCYCLE] condition
  AND condition
  [ORDER SIBLINGS BY column, column, …]

1. START WITH : 계층 구조 전개의 시작 위치를 지정하는 구문
2. CONNECT BY : 다음에 전개될 자식 데이터를 지정하는 구문
3. PRIOR : CONNECT BY절에 사용되며, 현재 읽은 칼럼을 지정, (FK) = PRIOR (PK) 형태를 사용하면 부모 데이터에서 자식 데이터 방향으로 전개하는 순방향 전개, (PK) = PRIOR (FK) 형태를 사용하면 반대로 자식 데이터에서 부모 데이터 방향으로 전개하는 역방향 전개
4. NOCYCLE : 데이터를 전개하면서 이미 나타났던 동일한 데이터가 전개 중에 다시 나타나는 사이클이 발생 시, 런타임 오류가 발생. NOCYCLE을 추가하면 오류를 발생시키지 않고 사이클이 발생한 이후의 데이터를 전개하지 않는다.
5. ORDER SIBLINGS BY : 형제 노드 사이에서 정렬을 수행
6. WHERE : 모든 전개를 수행한 후에 지정된 조건을 만족하는 데이터만 추출
   
   

• 계층형 질의에서 사용되는 가상 칼럼

1. LEVEL : 루트 데이터이면 1, 그 하위 데이터이면 2다. 리프(Leaf) 데이터까지 1씩 증가한다.
2. CONNECT_BY_ISLEAF : 전개 과정에서 해당 데이터가 리프 데이터이면 1, 그렇지 않으면 0이다.
3. CONNECT_BY_ISCYCLE : 전개 과정에서 자식을 갖는데, 해당 데이터가 조상으로서 존재하면 1, 그렇지 않으면 0
   
   

• 계층형 질의에서 사용되는 함수

1. SYS_CONNECT_BY_PATH : 루트 데이터부터 현재 전개할 데이터까지의 경로를 표시
2. CONNECT_BY_ROOT : 현재 전개할 데이터의 루트 데이터를 표시
   
   

• PIVOT절 : 행을 열로 회전

• UNPIVOT절 : 열을 행으로 회전
  
  

• 정규표현식 POSIX 연산자

1. . : 모든 문자와 일치 (newline 제외)
2. | : 대체 문자를 구분
3. \ : 다음 문자를 일반 문자로 취급
4. ^ : 문자열의 시작
5. $ : 문자열의 끝
6. ? : 0회 또는 1회 일치 (greedy : 패턴 최소 일치)
7. ?? : 0회 또는 1회 일치 (nongreedy : 패턴 최대 일치)
8. * : 0회 또는 그 이상의 횟수로 일치 (greedy : 패턴 최소 일치)
9. *? : 0회 또는 그 이상의 횟수로 일치 (nongreedy : 패턴 최대 일치)
10. + : 1회 또는 그 이상의 횟수로 일치 (greedy : 패턴 최소 일치)
11. +? : 1회 또는 그 이상의 횟수로 일치 (nongreedy : 패턴 최대 일치)
12. {m} : m회 일치 (greedy : 패턴 최소 일치)
13. {m}? : m회 일치 (nongreedy : 패턴 최대 일치)
14. {m,} : 최소 m회 일치 (greedy : 패턴 최소 일치)
15. {m,}? : 최소 m회 일치 (nongreedy : 패턴 최대 일치)
16. {,m} : 최대 m회 일치 (greedy : 패턴 최소 일치)
17. {,m}? : 최대 m회 일치 (nongreedy : 패턴 최대 일치)
18. {m,n} : 최소 m회, 최대 n회 일치 (greedy : 패턴 최소 일치)
19. {m,n}? : 최소 m회, 최대 n회 일치 (nongreedy : 패턴 최대 일치)
20. (expr) : 괄호 안의 표현식을 하나의 단위로 취급
21. [char…] : 문자 리스트 중 한 문자와 일치
22. [^char…] : 문자 리스트에 포함되지 않은 한 문자와 일치
23. [-] : [0-9] [a-z] [A-Z] [a-zA-Z] [0-9a-zA-Z] [0-9a-fA-F]
24. \d : 숫자
25. \D : 숫자가 아닌 모든 문자
26. \w : 숫자와 영문자(underbar 포함)
27. \W : 숫자와 영문자가 아닌 모든 문자(underbar 제외)
28. \s : 공백 문자
29. \S : 공백 문자가 아닌 모든 문자
    
    

• REGEXP_SUBSTR : 문자열에서 일치하는 패턴을 반환

• REGEXP_LIKE : 문자열이 패턴과 일치하면 TRUE, 아니면 FALSE 반환

• REGEXP_REPLACE : 일치하는 패턴을 replace_string으로 변경한 문자로 반환

• REGEXP_SUBSTR : 일치하는 패턴의 문자만을 반환

• REGEXP_INSTR : 일치하는 패턴의 시작 위치를 정수로 반환

• REGEXP_COUNT : 일치하는 패턴의 횟수를 반환
  
  

• MERGE : 새로운 행을 입력하거나, 기존 행을 수정하는 작업을 한번에 할 수 있음
  
  

• 트랜잭션의 특성

1. 원자성 : 트랜잭션에서 저으이된 연산들은 모두 성공적으로 실행되던지 아니면 전혀 실행되지 않은 상태로 남아 있어야 한다.
2. 일관성 : 트랜잭션이 실행되기 전의 데이터베이스 내용이 잘못 돼 있지 않다면 트랜잭션이 실행된 이후에도 데이터베이스의 내용에 잘못이 있으면 안된다.
3. 고립성 : 트랜잭션이 실행되는 도중에 다른 트랜잭션의 영향을 받아 잘못된 결과를 만들어서는 안된다.
4. 지속성 : 트랜잭션이 성공적으로 수행되면, 그 트랜잭션이 갱신한 데이터베이스의 내용은 영구적으로 저장된다.
   
   

• COMMIT or ROLLBACK 이전 상태

1. 이전 상태로 복구 가능
2. 현재 사용자는 SELECT 문장으로 결과를 확인할 수 있다.
3. 다른 사용자는 현재 사용자가 수행한 명령의 결과를 볼 수 없다.
4. 변경된 행은 잠금(LOCKING)이 설정돼서 다른 사용자가 변경할 수 없다.
   
   

• SQL Server에서의 트랜잭션

1. AUTO COMMIT : SQL Server의 기본 방식, DBMS가 트랜잭션을 컨트롤하는 방식, 명령어가 성공적으로 수행되면 자동으로 COMMIT 수행, 오류가 발생하면 자동으로 ROLLBACK 수행
2. 암시적 트랜잭션 : Oracle과 같은 방식, 트랜잭션의 시작은 DBMS가 처리, 트랜잭션의 끝은 사용자가 명시적으로 COMMIT 또는 ROLLBACK 처리
3. 명시적 트랜잭션 : 트랜잭션의 시작과 끝을 모두 사용자가 명시적으로 지정하는 방식
   
   

• SAVEPOINT : 저장점(SAVEPOINT)를 지정하면 ROLLBACK할 때 트랜잭션에 포함된 전체 작업을 롤백하는 것이 아니라, 현 시점에서 SAVEPOINT까지 트랜잭션의 일부만 롤백할 수 있다.
  
  

• 제약조건의 종류

1. PRIMARY KEY : 테이블에 저장된 행 데이터를 고유하게 식별하기 위한 기본키를 정의한다.
2. UNIQUE : 테이블에 저장된 행 데이터를 고유하기 식별하기 위한 고유키를 정의한다.
3. NOT NULL : NULL값의 입력을 금지한다.
4. CHECK : 입력할 수 있는 값의 범위 등을 제한한다.
5. FOREIGN KEY : 관계형 데이터베이스에서 테이블 간의 관계를 정의하기 위해 기본키를 다른 테이블의 외래키로 복사하는 경우 외래키가 생성된다.
   
   

• Oracle에서 제공하는 유저들

1. SCOTT : Oracle 테스트용 샘플 계정
2. SYS : 백업 및 복구 등 데이터베이스 상의 모든 관리 기능을 수행할 수 있는 최상위 관리자 계정
3. SYSTEM : 백업, 복구 등 일부 관리 기능을 제외한 모든 시스템 권한을 부여받은 DBA 계정