-
노션을 그대로 옮긴 것이기에 이미지와 토글이 제대로 안 먹음.
-
수정할 생각은 없음.. notion을 보면 되기
-
하는 이유 : DB는 면접대비 SQL은 코테대비 SQL 면접에서 판서로 작성해보라고도 했음. 억울해서 배워야함.
-
참고 : 학부때의 강의자료
<https://github.com/kkminseok/DB_SQL_Review>
-
KB국민은행 기출에서 truncate()가 나옴.
-
개념
-
제 1장 데이터베이스 시스템
- 데이터베이스 정의 : 조직체의 응용 시스템들이 공유해서 사용하는 운영 데이터(operational data)들이 구조적으로 통합된 모임.
- 데이터 와 정보 : 데이터는 프로그램과 질의에 의해 정보로 변환.
테이블에 ('홍길동', '김철수', '박영희' 등..)데이터가 있을 때 어떠한 질의(목적)를 통해 '홍길동'을 받게 되면 그 것을 정보 라고한다.
-
데이터베이스의 특징 :
- 여러 사용자에 의해 동시에 사용됨.
- 모든 데이터가 중복을 최소화하면서 통합됨.
- 데이터베이스는 한 조직체의 운영 데이터뿐만 아니라 그 데이터에 관한 설명(**데이터베이스 스키마 또는 메타 데이터)**까지 포함.
- 프로그램과 데이터 간의 독립성이 제공됨.
-
데이터베이스 관리 시스템(DBMS: Data Base Management System)
- 데이터베이스를 정의하고, 질의어를 지원하고, 리포트를 생성하는 등의 작업을 수행하는 소프트웨어(MYSQL Workbench ,등)
-
데이터베이스 스키마 = 내포(intension)
- 전체적인 데이터베이스 구조, 자주바뀌지 않음. DB의 모든 가능한 상태를 미리 정의
-
데이터베이스 상태 = 외연(extension)
- 특정 시점의 DB 내용을 의미하며, 시간이 지남에 따라 계속해서 바뀜.
--데이터베이스 스키마 DEPARMENT(DEPTNO, DEPTNAME,FLOOR) -- 이처럼 초기에 아예 설정하는 것을 말하는 듯. -- 데이터베이스 상태는 DELETE 등의 조작을 통해 바뀐 테이블의 그 시점을 말하는 듯.
-
데이터베이스 시스템(DBS)의 구성 요소 : 응용 프로그램, 사용자, DBMS, DB, 시스템 카탈로그
-
데이터베이스 :
- 조직체의 응용 시스템들이 공유해서 사용하는 운영 데이터들이 통합된 모임
- 시스템 카탈로그와 저장된 DB로 구분 가능.
- 시스템 카탈로그는 저장된 DB의 스키마 정보를 유지
-
DBMS :
- 소프트웨어, 데이터베이스 언어라고 부르는 특별한 프로그래밍 언어를 한 개 이상 제공, SQL은 여러 DBMS에서 제공되는 사실상의 표준 데이터베이스 언어
-
하드웨어 :
- DB는 디스크와 같은 보조 기억 장치에 저장, 정보를 찾기 위해서는 디스크의 블록들의 주기억장치로 읽어 들임. 계산, 비교 연산들을 수행하기 위해서는 중앙 처리 장치가 사용됨.
- DBMS 자체도 주기억 장치에 적재되어 실행되어야 한다.
-
데이터베이스 시스템의 요구사항 :
- 많다.
- 데이터 독립성
- 효율적인 데이터 접근
- 데이터에 대한 동시 접근
- 백업과 회복
- 중복을 줄이거나 제어하며 일관성 유지
- 데이터 무결성
- 데이터 보안
- 쉬운 질의어
- 다양한 사용자 인터페이스
- 많다.
- 화일 시스템 :
- 1960년대부터 사용됨. 기본요소는 순차적인 레코드들.
- 한 레코드는 연관된 필드의 모임.
- 화일을 접근하는 방식이 응용 프로그램 내에 상세하게 표현되므로 데이터에 대한 응용 프로그램의 의존도가 높다.
- 단점
- 데이터가 많은 화일에 중복해서 저장된다.
- 다수 사용자들을 위한 동시성 제어x
- 검색 하려는 질의어조차 쉽지 않다.
- 보안 문제
- 회복기능 없음.
- 독립성이 없어서 유지보수 비용이 크다.
- 질의 절차가 복잡하여 생산성 저하
- 데이터의 공유와 융통성 부족
- 위의 단점을 보완한 것이 DBMS를 사용한 DB관리 그 중 중요한 것이 데이터 독립성!!
- DBMS 장점
- 중복성과 불일치가 감소
- 시스템을 개발 및 유지비용 감소
- 표준화를 시행하기 용이
- 보안 향상
- 무결성 향상
- 요구사항 식별 가능
- DB 회복 기능
- DB 공유와 동시성 기능 제공.
- DBMS 단점
- 하드웨어, DBMS 자체의 구입 비용
- 교육 비용
- 비밀과 프라이버시 노출 등 단점 존재할 수 있다.
- 오버헤드가 너무크거나 응용이 단순하고 잘 정의 되어있거나.. 즉, DBMS를 사용하지 않는 것이 이득일 경우가 있다.
-
데이터 모델 :
- 데이터베이스의 구조를 기술하는데 사용되는 개념들의 집합인 구조. 이 구조 위에서 동작하는 연산자들, 무결성 제약조건들.
- 사용자에게 내부 저장 방식의 세세한 사항은 숨기면서 데이터에 관한 직관적인 뷰를 제공
-
데이터 모델의 분류 :
- 고수준, 개념적 데이터 모델 : 엔티티-관계(ER), 객체지향 데이터 모델
- 표현 데이터 모델 : 계층 데이터 모델, 네트워크 데이터 모델, 관계 데이터 모델(Relational data model)
- 저수준 또는 물리적인 데이터 모델 : ISAM, VSAM 등
-
계층 DBMS → 네트워크 DBMS → 관계 DBMS → 객체 관계 DBMS
↘ ↗
객체지향 프로그래밍 → 객체지향 DBMS
-
계층 DBMS
1960년 후반 최초 계층 DBMS 등장 (IBM사의 IMS)
트리구조 기반
장점 : 어떤 유형의 응용에 대해서는 빠른 속도와 높은 효율성 제공
단점 : 그냥 구짐. 알아봤자 뭐해.
-
네트워크 DBMS
1960년대 초에 최초의 네트워크 DBMS인 IDS를 개발
레코드들이 노드로, 레코드들 사이의 관계가 간선으로 표현되는 그래프를 기반으로 하는 네트어크 데이터 모델 사용.
-
관계 DBMS
1970년대 IBM 연구소에서 제안.
장점 : 모델이 간단하여 이해하기 쉬움. 사용자는 자신이 원하는 것만 명시하고, 데이터가 어디에 있는지, 어떻게 접근해야 하는지는 DBMS가 결정.
EX) 오라클, MS SQL SERVER, SYBASE, DB2, INFORMIX 등
-
객체 지향 DBMS
1980년대 후반 등장. 객체지향 프로그래밍 패러다임을 기반.
장점 : 데이터와 프로그램을 그룹화하고, 복잡한 객체들을 이해하기 쉬움. 유지와 변경이 용이
EX) ONTOS, OpenOOB, GemStone, ObjectStore, Versant,O2 등
-
객체 관계 DBMS
1990년대 후반에 제안.
EX) 오라클, INFORMIX, Universal Server 등
- 데이터 정의어(DDL : Data Definition Language) - CREATE,ALTER,DROP
- 데이터 조작어(DML : Data Manipulation Language) - 절자적 언어와 비절차적 언어로 나뉘는데, 관계 DBMS에서 사용되는 SQL은 비절차적 언어. 대부분의 데이터 조작어는 SUM, COUNT 와같은 내장 함수를 갖고 있다. SELECT, UPDATE, DELETE, INSERT
- 데이터 제어어(DCL : Data Control Language) - 사용자는 데이터 제어어를 사용하여 데이터베이스 트랜잭션을 명시하고 권한을 부여하거나 취소.
- 데이터베이스 관리자(DBA : Database Administrator)
- 조직의 여러 부분의 상이한 요구를 만족시키기 위해서 일관성 있는 DB 스키마를 생성하고 유지하는 사람.
- 역할
- 데이터베이스 스키마 생성 및 변경
- 무결성 제약조건 명시
- 사용자 권한 허용, 취소 역할 관리
- 저장 구조와 접근 방법(물리적 스키마) 정의
- 백업과 회복
- 표준화 시행
- 응용 프로그래머
- 데이터베이스 위에서 특정 응용(인사 관리 등)이나 인터페이스를 구현하는 사람.
- 이들이 작성한 프로그램은 최종 사용자들이 반복해서 수행하므로 기작성 트랜잭션 이라부름.
- 최종 사용자
- 질의하거나 갱신하거나 보고서를 생성하기 위해서 데이터베이스를 사용하는 사람.
- 데이터베이스 설계자
- 데이터베이스 설계를 담당.
- 오퍼레이터
- DBMS가 운영되고 있는 컴퓨터 시스템과 전산실을 관리하는 사람.
- 현재 대부분의 사용 DBMS 구현에서 사용되는 일반적인 아키텍처는 1978년에 제안된 ANSI/SPARC 아키텍처
- 외부 단계, 개념 단계, 내부 단계로 나뉨.
- 외부 단계 : 사용자의 뷰. 서로 다른 뷰가 제공될 수 있음.
- 개념 단계 : 사용자 공동체의 뷰. 데이터베이스마다 오직 한 개의 개념 스키마가 존재. 물리적인 구현은 고려하지 않으면서 조직체 전체에 관한 스키마 포함.
- 내부 단계 : 물리적 또는 저장 뷰. 실제의 물리적인 데이터 구조에 관한 스키마.
- 데이터 독립성 : 상위 단계의 스키마 정의에 영향을 주지 않으면서 어떤 단계의 스키마 정의를 변경할 수 있음을 의미.
- 논리적 데이터 독립성 : 개념 스키마의 변화로부터 외부 스키마가 영향을 받지 않음을 의미
- 물리적 데이터 독립성 : 내부 스키마의 변화가 개념적 스키마에 영향을 미치지 않으며, 따라서 외부 스키마에도 영향을 미치지 않음을 의미
- 참고 : 데이터 정의어 컴파일러, 질의 처리기, 런타임 데이터베이스 관리기, 트랜잭션 관리, 데이터베이스 API,
- 중앙 집중식 데이터베이스 시스템 - 하나의 컴퓨터 시스템에서 운영됨.
- 분산 데이터베이스 시스템 - 네트워크로 연결된 여러 사이트에 데이터베이스 자체가 분산되어 있음. 사용자는 다른 사이트에 저장된 데이터베이스에도 접근할 수 있다.
- 클라이언트 - 서버 데이터베이스 시스템 - PC 또는 워크스테이션처럼 자체 컴퓨팅 능력을 가진 클라이언트를 통해 데이터베이스 서버를 접근.
- 장점은 데이터베이스를 보다 넓은 지역에서 접근할 수 있다. 단점은 보안이 다소 취약할 수 있다.
- 2층 모델(2-tier model) : 클라이언트와 데이터베이스 서버가 직접 연결됨.
- 3층 모델(3-tier model) : 클라이언트와 데이터베이스 서버 사이에 응용 서버가 추가됨.
-
제 2장 관계 데이터 모델과 제약조건
- 가장 개념이 단순한 데이터 모델의 하나
- IBM 연구소의 E.F Codd가 1970년에 관계 데이터 모델을 제안함.
- 선언적인 질의어를 통한 데이터 접근을 제공
- 사용자는 원하는 데이터(what)만 명시하고, 어떻게 이 데이터를 찾을것인가(how)는 명시할 필요가 없음.
- 릴레이션, 레코드=투플, 애트리뷰트
- 카디날리티(행들의 수), 차수(열들의 수)
- 도메인 : 한 애트리뷰트에 나타날 수 있는 값들의 집합.
- 널값 : '알려지지 않음' , '적용할 수 없음'을 나타내기 위해 널값을 사용.
- 릴레이션 스키마 : 릴레이션의 이름과 릴레이션의 애트리뷰트들의 집합. 내포라고 함.
- 릴레이션 인스턴스 : 릴레이션에 어느 시점에 들어 있는 투플들의 집합. 외연.
- 수퍼 키, 후보 키, 기본 키, 대체 키, 외래 키
- 수퍼 키
- 한 릴레이션 내의 특정 투플을 고유하게 식별하는 하나의 애트리뷰트 또는 애트리뷰트들의 집합.
- 투플들을 고유하게 식별하는데 꼭 필요하지 않은 애트리뷰트들을 포함할 수 있음.
- 후보 키
- 각 투플을 고유하게 식별하는 최소한의 애트리뷰트들의 모임.
- 후보 키도 두 개 이상의 애트리뷰트로 이루어질 수 있으며 이런 경우에 복합 키라고 부름.
- 기본 키
- 한 릴레이션에 후보 키가 두 개 이상 있으면 설계자 또는 데이터베이스 관리자가 이들 중에서 하나를 기본 키로 선정.
- 대체 키
- 기본 키가 아닌 후보 키
- 외래 키
- 어떤 릴레이션의 기본 키를 참조하는 애트리뷰트
- 데이터 무결성
- 데이터의 정확성 또는 유효성을 의미
- 도메인 제약조건
- 각 애트리뷰트 값이 반드시 원자값
- 애트리뷰트 값의 디폴트 값, 가능한 값들의 범위 등을 지정할 수 있음.
- 데이터 형식을 통해 값들의 유형을 제한하고, CHECK 제약 조건을 통해 값들의 범위를 제한할 수 있음.
- 기본 키와 엔티티 무결성 제약조건
- 기본 키가 각 투플들을 식별하기 위하여 사용되기 때문에 릴레이션의 기본키를 구성하는 어떤 애트리뷰트도 널값을 가질 수 없다는 제약조건.
- 대체 키에는 적용되지 않음.
- 외래 키와 참조 무결성 제약조건
- 관계 데이터베이스가 릴레이션들로만 이루어지고, 릴레이션 사이의 관계들이 다른 릴레이션의 기본 키를 참조하는 것을 기반으로 하여 묵시적으로 표현되기 때문에 외래 키의 개념이 중요.
- 무결성 제약조건의 유지
- 데이터베이스에 대한 갱신 연산은 삽입 연산, 삭제 연산, 수정 연산으로 구분함.
- 참조 무결성 제약조건을 만족시키기 위해서 DBMS가 제공하는 옵션
- 제한 : 위배를 야기한 연산을 단순히 거절
- 연쇄 : 참조되는 릴레이션에서 투플을 삭제하고, 참조하는 릴레이션에서 이 투플을 참조하는 투플들도 삭제.
- 널값 : 참조되는 릴레이션에서 투플을 삭제하고, 참조하는 릴레이션에서 이 투플을 참조하는 투플들의 외래 키에 널값을 삽입
- 디폴트값 : 널값 대신 디폴트를 넣는다는 것.
-
제 3장 오라클(스킵)
-
제 4장 관계 대수와 SQL
- 관계 해석
- 원하는 데이터만 명시하고 질의를 어떻게 수행할 것인가는 명시하지 않는 선언적인 언어.
- 관계 대수
-
어떻게 질의를 수행할 것인가를 명시하는 절차적 언어.
-
관계 대수는 상용 관계 DBMS들에서 널리 사용되는 SQL의 이론적인 기초
-
실렉션 연산자
- 실렉션 조건(프레디키트)을 만족하는 투플들의 부분 집합을 생성함.
-
프로젝트 연산자
- 한 릴레이션의 애트리뷰트들의 부분 집합
- 결과로 생성되는 릴레이션은 <애트리뷰트 리스트>에 명시된 애트리뷰트들만 가짐.
-
집합 연산자
- 합집합, 교집합, 차집합, 카디션 곱 연산자
- 카디션 곱 : R과 S의 투플들의 모든 가능한 조합으로 이루어진 릴레이션.
-
조인 연산자
- 두 개의 릴레이션으로부터 연관된 투플들을 결합하는 연산자
- 세타 조인, 동등 조인, 자연 조인, 외부 조인, 세미 조인
- 세타 조인 : 카디션 곱 조인 조건을 적용한 결과
- 동등 조인 : 세타 조인 중에서 비교 연산자가 =인 조인
-
관계 대수의 한계
- 집단 함수 지원안함. 정렬 못 함. 데이터베이스 수정 불가능.
-
외부 조인
-
- 관계 해석
-
제 4장 관계 대수와 SQL(2)
- 관계 데이터 모델은 집합을 기반을 두고 있어 테이블 내에 동일한 튜플을 허용하지 않지만 SQL은 이를 허용함.
- 자신이 원하는 바(what)만 명시하며, 원하는 것을 처리하는 방법(how)은 명시할 수 없음.
- 데이터 정의어
- DROP, ALTER ADD, CREATE ON
- 중첩 질의(nested query)
- 질의의 WHERE 또는 FROM절에 다시 (SELECT ....) 형태로 포함된 SELECT문
- 부질의라고도 한다.
- 중첩 질의를 포함하는 질의를 외부 질의라고 부른다.
- 외부 질의의 WHERE절에서 IN, ANY, ALL, EXISTS와 같은 연산자를 사용해야 한다.
- 상관 중첩 질의
- 중첩 질의의 WHERE절에 있는 프레디키트에서 외부 질의에 선언된 릴레이션의 일부 애트리뷰트를 참조하는 질의
- 데이터 조작어 : INSERT, DELETE, UPDATE
- 트리거
- 명시된 이베튼가 발생할 때마다 DBMS가 자동적으로 수행하는, 사용자가 정의하는 문(프로시저)
- 트리거를 이벤트-조건-동작(ECA) 규칙이라고도 부름.
- Event Condition Action
- 주장
- 트리거는 제약조건을 위반했을 때 수행할 동작을 명시하는 것이고, 주장은 제약조건을 위반하는 연산이 수행되지 않도록 함.
- 내포된 SQL
- SQL이 호스트 언어의 완전한 표현력을 갖고 있지 않기 대문에 모든 질의를 SQL로 표현할 수 없음.
- 호스트 언어에 포함되는 SQL문을 내포된 SQL이라 부름.
- 데이터 구조가 불일치하는 문제(impedance mismatch 문제)
-
제 5장 데이터베이스 설계와 ER 모델
-
개념적 데이터베이스 설계와 물리적 데이터베이스 설계로 구분
-
개념적은 실제로 데이터베이스를 어떻게 구현할 것인가와는 독립적으로 정보 사용의 모델을 개발하는 과정
-
물리적은 데이터베이스 설계에서는 물리적인 저장 위치와 접근 방식을 다룸.
-
개념적은 엔티티, 관계, 프로세스, 무결성 제약조건 등을 나타내는 추상화 모델을 구축
- 엔티티 : 서로 구분이 되면서 조직체에서 데이터베이스에 나타내려는 객체를 의미
- 관계 : 두 개 이상의 엔티티들 간의 연관을 나타냄.
- 프로세스 : 관련된 활동을 나타냄.
- 무결성 제약조건 : 데이터의 정확성과 비즈니스 규칙을 의미.
-
개념적 수준의 모델
- 특정 데이터 모델과 독립적으로 응용 세계를 모델링할 수 있도록 함.
- 인기 있는 개념적 수준의 모델은 엔티티-관계(ER)모델
- ER 모델과 같은 개념적인 데이터 모델이 사상될 수 있는 다수의 구현 데이터 모델이 존재.
- 구현 단계에서 사용되는 세 가지 데이터 모델 : 관계 데이터 모델, 계층 데이터 모델, 네트워크 데이터 모델
-
데이터베이스 설계의 주요 단계
- 요구사항 분석, 개념적 설계, DBMS의 선정, 논리적 설계, 스미카 정제, 물리적 설계와 튜닝 등 여러 작업들로 이루어짐.
- 요구사항 수집과 분석 : 인터뷰, 설문 조사 등이 시행.
- 개념적 설계
- 한 조직체에서 사용되는 정보의 모델을 구축하는 과정
- 완성된 개념적 스키마는 ER다이어그램으로 표현됨.
- 논리적 설계
- 데이터베이스 관리를 위해 선택한 DBMS의 데이터 모델을 사용하여 논리적 스키마를 생성함.
- 관계 데이터베이스 스키마를 더 좋은 관계 데이터베이스 스키마로 변환하기 위해서 정규화 과정을 적용.
- 물리적 설계
- 처리 요구사항들을 만족시키기 위해 저장 구조와 접근 경로 등을 결정함.
- 트랜잭션 설계
- 트랜잭션은 완성될 데이터베이스에서 동작할 응용 프로그램
- 데이터베이스 스키마는 트랜잭션에서 요구하는 모든 정보를 포함해야 함.
- 검색, 갱신, 혼합 등 세 가지 유형으로 구분하여 입력과 출력, 동작 등을 식별한다.
-
P.P Chen이 제안.
-
실세계를 엔티티, 애트리뷰트, 엔티티들 간의 관계로 표현함.
-
쉽게 관계 데이터 모델로 사상됨.
-
기본적인 구문으로는 엔티티, 관계, 애트리뷰트가 있고, 기타 구문으로는 카디날리티 비율, 참여 제약조건 등이 있다.
-
엔티티
- 하나의 엔티티는 사람, 장소, 사물, 사건 등과 같이 독립적으로 존재하면서 고유하게 식별이 가능한 실세계의 객체
-
강한 엔티티 타입
- 엔티티 타입내에서 자신의 키 애트리뷰트를 사용하여 고유하게 엔티티들을 식별할 수 있는 엔티티 타입
-
약한 엔티티 타입
- 키를 형성하기에 충분한 애트리뷰트들을 갖지 못한 엔티티 타입
- 이 엔티티 타입이 존재하려면 소유 엔티티 타입이 있어야 함.
- 소유 엔티티 타입의 키 애트리뷰트를 결합해야만 고유하게 약한 엔티티 타입의 엔티티들을 식별할 수 있음.
-
애트리뷰트
- 하나의 엔티티는 연관된 애트리뷰트들의 집합으로 설명됨.
- 여러 애트리뷰트가 동일한 도메인을 공유할 수 있다.
- ER 다이어그램에서 기본 키에 속하는 애트리뷰트는 밑줄을 그어 표시함. 타원형으로 나타냄. 애트리뷰트와 엔티티 타입은 실선으로 연결.
-
단순 애트리뷰트
- 더 이상 다른 애트리뷰트로 나눌 수 없는 애트리뷰트
-
복합 애트리뷰트
- 두 개 이상의 애트리뷰트로 이루어진 애트리뷰트
-
단일 값 애트리뷰트
- 각 엔티티마다 정확하게 하나의 값을 갖는 애트리뷰트
- ER 다이어그램에서 단순 애트리뷰트와 동일하게 표현됨.
-
다치 애트리뷰트
- 각 엔티티마다 여러 개의 값을 가질 수 있는 애트리뷰트
- ER 다이어그램에서 이중선 타원으로 표현함
-
저장된 애트리뷰트
- 다른 애트리뷰트와 독립적으로 존재하는 애트리뷰트
- ER 다이어그램에서 단순 애트리뷰트와 동일하게 표현됨.
-
유도된 애트리뷰트
- 다른 애트리뷰트의 값으로부터 얻어진 애트리뷰트
- 관계 데이터베이스에서 릴레이션의 애트리뷰트로 포함시키지 않는 것이 좋다.
- ER 다이어그램에서 점선 타원으로 표현한다.
-
약한 엔티티 타입
- 약한 엔티티 타입에게 키 애트리뷰트를 제공하는 엔티티 타입을 소유 엔티티 타입 또는 식별 엔티티 타입이라고 부른다.
- ER 다이어그램에서 이중선 직사각형으로 표기
- 부분 키 : 부양가족의 이름처럼 한 사원에 속한 부양가족 내에서는 서로 다르지만 회사 전체 사원들의 부양가족들 전체에서는 같은 경우가 생길 수 있는 애트리뷰트.
-
관계와 관계 타입
- ER 다이어그램에서 다이아몬드로 표기
-
차수
- 관계로 연결된 엔티티 타입들의 개수를 의미
-
카디날리티
- 카디날리티 비율은 한 엔티티가 참여할 수 있는 관계의 수를 나타냄.
- 관계 타입에 참여하는 엔티티들의 가능한 조합을 제한함.
- 1:1 관계, 1:N 관계, M:N 관계
-
역할
- 관계 타입이 의미를 명확하게 하기 위해 사용됨.
-
전체 참여와 부분 참여
- 전체 참여는 어떤 관계에 엔티티 타입의 모든 엔티티들이 관계 타입 R에 의해서 어떤 엔티티 타입의 어떤 엔티티와 연관되는 것을 의미.
- 부분 참여는 어떤 관계에 엔티티 타입의 일부 엔티티만 참여하는 것을 의미.
-
ER 모델의 또 다른 표기법
- 새발(crow-feet) 표기법
-
-
제 6장 물리적 데이터베이스 설계
- 논리적인 설계의 데이터 구조를 보조 기억장치상의 화일로 사상함.
- 사용자가 원하는 데이터를 검색하기 위해서 DBMS는 디스크 상의 데이터베이스로부터 사용자가 원하는 데이터를 포함하고 있는 블록을 읽어서 주기억 장치로 가져온다.
- 전형적인 블록 크기는 4,096바이트
- 각 화일은 고정된 크기의 블록들로 나누어져서 저장된다.
- 자기 디스크
- 각 면마다 디스크 헤드가 있다.
- 각 판은 트래고가 섹터로 구분된다.
- 여러 개의 디스크 면 중에서 같은 지름을 갖는 트랙들을 실린더라고 부른다.
- 디스크에서 임의의 블록을 읽어오거나 기록하는데 걸리는 시간은 탐구시간(seek time), 회전 지연 시간(rotational delay), 전송 시간(transfer time)의 합.
- 입출력은 컴퓨터 시스템에서 가장 속도가 느린 작업이므로 입출력 횟수를 줄이는 것이 DBMS의 성능을 향상하는데 매우 중요하다.
- 버퍼는 디스크 블록들을 저장하는데 사용되는 주기억 장치 공간이다.
- 운영 체제에서 버퍼 관리를 위해 흔히 사용되는 LRU 알고리즘은 데이터베이스를 위해 항상 우수한 성능을 보이진 않는다.
-
BLOB(Binary Large Object)
- 이미지, 동영상 등 대규모 크기의 데이터를 저장하는데 사용된다.
-
고정 길이 레코드
- 레코드 i를 접근하기 위해서는 n*(i-1)+1의 위치에서 레코드를 읽음.
- 종류
- 히프 파일
- 순차 파일
- 인덱스된 순차 화일
- 직접 파일
- 히프 파일(비순서 파일)
- 가장 단순한 파일 조직
- 일반적으로 삽입된 순서대로 화일에 저장.
- 좋은 성능을 유지하기 위해서 히프 파일을 주기적으로 재조직할 필요가 있다.
- 순차 파일
- 레코드들이 하나 이상의 필드 값에 따라 순서대로 저장딘 파일
- 레코드들이 일반적으로 레코드의 탐색 키 값의 순서에 따라 저장됨.
- 탐색 키는 순차 파일을 정렬하는데 사용되는 필드
- 삽입 연산은 오래 걸릴 수 있다.
- 삭제 연산은 삭제된 레코드가 빈 공간으로 남기기 때문에 주기적으로 순차 화일을 재조직해야한다.
- 탐색에 효율적
- 인덱스된 순차 파일은 인덱스를 통해서 임의의 레코드를 접근할 수 있는 파일.
- 인덱스는 데이터 파일과는 별도의 파일에 저장된다.
- 인덱스의 크기는 데이터 파일의 크기에 비해 훨씬 작다.
- 하나의 파일에 여러 개의 인덱스를 정의할 수 있다.
- 인덱스가 정의된 필드를 탐색 키라고 부른다.
- 탐색 키의 값들은 후보 키처럼 각 투플마다 반드시 고유하지는 않다.
- 기본 인덱스(primar index)
- 탐색 키가 데이터 파일의 기본 키인 인덱스를 기본 인덱스라고 부른다.
- 기본 인덱스는 기본 키의 값에 따라 정렬된 데이터 파일에 의해 정의된다.
- 각 릴레이션마다 최대한 한 개의 기본 인덱스를 가질 수 있다.
- 클러스터링 인덱스(clustering index)
- 탐색 키 값에 따라 정렬된 데이터 파일에 대해 정의된다.
- 보조 인덱스(secondary index)
- 한 파일은 기껏해야 한 가지 필드들의 조합에 대해서만 정렬될 수 있다.
- 보조 인덱스는 탐색 키 값에 따라 정렬되지 않은 데이터 파일에 대해 정의 된다.
- 희소 인덱스와 밀집 인덱스의 비교
- 희소 인덱스는 각 데이터 블록마다 한 개의 엔트리를 갖고, 밀집 인덱스는 각 레코드마다 한 개의 엔트리를 가진다.
- 레코드의 길이가 블록 크기보다 훨씬 작은 일반적인 경우에는 희소 인덱스의 엔트리 수가 밀집 인덱스의 엔트리 수보다 훨씬 적다.
- 다단계 인덱스
- 인덱스 자체가 클 경우에는 인덱스를 탐색하는 시간도 오래 걸릴 수 있다.
- 가장 상위 단계 인덱스를 마스터 인덱스라고 부른다.
- 마스터 인덱스는 한 블록으로 이루어지기 때문에 주기억 장치에 상주할 수 있다.
- 대부분 다단계 인덱스는 b+트리를 사용한다.
- 인덱스의 장점과 단점
- 인덱스는 검색 속도를 향상시키지만 인덱스를 저장하기 위한 공간이 추가로 필요하고 삽입, 삭제, 수정 연산의 속도는 저하 시킨다.
- 소수의 레코드들을 수정하거나 삭제하는 연산의 속도는 향상된다.
- 릴레이션이 매우 크고, 질의에서 릴레이션의 투플들 중에 일부(2%~4%)를 검색하고, WHERE절이 잘 표현되었을 때 성능에 도움이 된다.
- 질의 튜닝을 위한 추가 지침
- DISTINCT절의 사용을 최소화하라.
- GROUP BY절과 HAVING절의 사용을 최소화하라.
- 임시 릴레이션의 사용을 피하라.
- SELECT * 대신 SELECT절에 애트리뷰트 이름들을 구체적으로 명시하라.
-
제 7장 릴레이션 정규화
-
부주의한 데이터베이스 설계는 제어할 수 없는 데이터 중복을 야기하여 여러가지 갱신 이상을 유발한다.
-
정규화는 주어진 릴레이션 스키마를 함수적 종속성과 기본 키를 기반으로 분석하여, 원래의 릴레이션을 분해함으로써 중복돠 세 가지 갱신 이상을 최소화한다.
-
갱신 이상(update anomaly)
- 수정 이상(modification anomaly)
- 반복된 데이터 중에 일부만 수정하면 데이터의 불일치가 발생
- 삽입 이상(insertion anomaly)
- 불필요한 정보를 함께 저장하지 않고는 어떤 정보를 저장하는 것이 불가능.
- 삭제 이상(deletion anomaly)
- 유용한 정보를 함께 삭제하지 않고는 어떤 정보를 삭제하는 것이 불가능.
- 릴레이션 분해
- 하나의 릴레이션을 두 개 이상의 릴레이션으로 나누는 것.
- 정규화의 종류
- 제 1정규형
- 제 2정규형
- 제 3정규형
- BCNF
- 제 4정규형
- 제 5정규형
- 정규화 이론의 핵심.
- 결정자(determinant)
- 어떤 애트리뷰트의 값은 다른 애트리뷰트의 값을 고유하게 결정할 수 있다.
- A가 B를 결정한다 라고 할 때 A → B로 표기
- 함수적 종속성
- 만일 애트리뷰트 A가 애트리뷰트 B의 결정자이면 B가 A에 함수적으로 종속한다고 말한다.
- 완전 함수적 종속성(FFD : Full Functional Dependency)
- 주어진 릴레이션 R에서 애트리뷰트 B가 애트리뷰트 A에 함수적으로 종속하면서 애트리뷰트 A의 어떠한 진부분 집합에도 함수적으로 종속하지 않으면 애트리뷰트 B가 애트리뷰트 A에 완전하게 함수적으로 종속한다고 말한다. 여기서 애트리뷰트 A는 복합 애트리뷰트이다.
- 이행적 함수적 종속성(transitive FD)
- 한 릴레이션의 애트리뷰트 A, B, C가 주어졌을 때 애트리뷰트 C가 이행적으로 A에 종속한다는 것의 필요 충분 조건은 A → B ^ B → C가 성립.
-
하나의 릴레이션을 두 개 이상의 릴레이션으로 나누는 것.
-
릴레이션을 분해하면 중복이 감소되고 갱신 이상이 줄어드는 장점이 있는 반면에, 바람직하지 않은 문제들을 포함하여 몇 가지 잠재적인 문제들을 야기할 수 있다.
-
무손실 분해(lossless decomposition)
- 분해된 두 릴레이션을 조인하면 원래의 릴레이션에 들어 있는 정보를 완전하게 얻을 수 있다.
- 여기서 손실이란 정보의 손실을 뜻한다.
- 즉 정보의 손실이란 원래의 릴레이션에 들어 있는 정보보다 적거나 많은 것을 말한다.
-
제 1정규형
- 모든 애트리뷰트가 원자값만을 갖는다.
- 모든 애트리뷰트에 반복 그룹(repeating group)이 나타나지 않으면 제 1정규형을 만족한다.
-
제 2정규형
- 제 1정규형을 만족하면서, 어떤 후보 키에도 속하지 않는 모든 애트리뷰트들이 R의 기본 키에 완전하게 함수적으로 종속하는 것. (부분 함수적 종속성 제거)
-
제 3정규형
- 제 2정규형을 만족하면서, 키가 아닌 모든 애트리뷰트가 릴레이션의 기본 키에 이행적으로 종속하지 않는 것.
-
BCNF
- 제 3정규형을 만족하면서, 모든 결정자가 후보 키어야한다.
-
제 4정규형
- 제 BCNF을 만족하면서 MVD(다치종속 제거)한 것.
-
제 5정규형
- 제 4정규형을 만족하면서, 조인종속을 제거한 것.
- 때로 데이터베이스 설계자는 응용의 요구 사항에 따라 데이터베이스 설계의 일부분을 역정규화함으로써 데이터 중복 및 갱신 이상을 대가로 치르면서 성능상의 요구를 만족시키기도 한다.
- 역정규화는 보다 낮은 정규형으로 되돌아가는 것을 말한다.
- 수정 이상(modification anomaly)
-
-
제 8장 뷰와 시스템 카탈로그
- 뷰 : 관계 데이터베이스 시스템에서 데이터베이스의 보안 메커니즘, 데이터독립성을 높이기 위해 사용.
- 시스템 카탈로그 : 시스템내의 객체(릴레이션, 뷰, 인덱스, 사용자 등)에 관한 정보를 포함. 따라서 적절히 이용하면 원하는 릴레이션을 데이터베이스에서 찾고, 해당 릴레이션에 어떤 애트리뷰트들이 있고, 데이터타입이 뭔지를 알 수 있다.
-
ANSI/SPARC 3단계 아키텍처에서 외부 뷰는 특정사용자가 보는 데이터베이스 구조. 가상의 릴레이션을 의미
-
기존의 기본 릴레이션에 대한 SELECT문의 형태로 정의된다.
-
스냅샷(snapshot)
- 어느 시점에 SELECT문의 결과를 기본 릴레이션의 형태로 저장해 놓은 것.
- 그렇기에 실제 릴레이션과 다른 정보를 가질 수 있다.
CREATE VIEW 뷰이름 [(애트리뷰드(들))] AS SELECT문 [WITH CHECK OPTION];
- 참고로 SELECT절 안에, 산술식 또는 집단 함수가 사용되거나 조인이 포함되거나 다른 릴레이션의 애트리뷰트의 이름이 같은 경우 뷰 정의 시 애트리뷰트 이름을 명시해야함.
-
뷰를 통해 데이터에 접근하는 경우 SQL문이 기본 릴레이션에 대한 동등한 질의로 바뀐다.
- 장점
- 복잡한 질의를 간단하게 나타낼 수 있다.
- 데이터 무결성을 보장하는데 활용.
- 데이터 독립성을 제공한다.
- 데이터 보안 기능을 제공.(기본 릴레이션에 직접접근하지 않으므로)
- 동일한 데이터에 대한 여러 가지 뷰를 제공. → 사용자들의 그룹이 각자 특정한 기준에 따라 데이터를 접근하도록 함.
- 뷰를 통해 기본 릴레이션을 갱신이 가능하지만 불가능한 경우가 있다.
- 기본 릴레이션의 기본 키가 포함되지 않은 뷰
- 뷰에 포함되지 않은 애트리뷰트에 'NOT NULL'이 지정된 경우
- 집단 함수가 포함된 뷰
- 조인으로 정의된 뷰
- 데이터베이스의 객체와 구조들에 관한 모든 데이터를 포함.
- 메타데이터라고 한다. 또한, 데이터 사전, 시스템 테이블이라고도 불린다.
- 문법 검사, 존재하는 데이터를 확인, 데이터 타입, 권한 확인 등..
- 질의 최적화도 진행한다. 가장 비용이 적게 드는 방법을 찾는다.
- 릴레이션에 관한 정보를 유지하는 릴레이션이 있다. 또한, 애트리뷰트에 관한 정보를 유지하는 릴레이션이 있다.
- 어떤 사용자도 시스템 카탈로그를 직접 갱신할 수 없다.
- 릴레이션마다 투플의 크기, 수, 블록의 채우기 비율, 블록킹 인수, 릴레이션 크기 저장
- 뷰마다 뷰의 이름과 정의를 저장
- 애트리뷰트마다 데이터 타입, 크기, 상이한 값들, 값의 범위, 선택율을 저장.
- 사용자마다 접근할 수 있는 릴레이션과 권한을 저장
- 인덱스마다 인덱스된 애트리뷰트, 클러스터링 인덱스 여부, 높이 등을 저장.
- 오라클의 경우 주기적으로 명령어(ANALYZE)를 통해 정보값들을 갱신해줘야함.
-
제 9장 트랜잭션
- 많은 사용자들이 동시에 데이터베이스의 서로 다른 부분 또는 동일한 부분을 접근하면서 데이터베이스를 사용하는데 이 부분에서 동시성 제어를 해줘야 한다.
- 동시성 제어(concurrency control)
- 동시에 수행되는 트랜잭션들이 순차적으로 수행하였을 때와 같도록 보장하는 것.
- 데이터 일관성을 유지.
- 회복(recovery)
- 데이터베이스를 갱신하는 도중에 시스템이 고장 나도 데이터베이스의 일관성을 유지.
-
트랜잭션의 특성(ACID 특성)
- 원자성(Atomicity)
- 한 트랜잭션 내의 모든 연산들이 완전히 수행되거나 수행되지 않아야함.
- 일관성(Consistency)
- 어떤 트랜잭션이 수행되기 전에 데이터베이스가 일관된 상태를 가졌다면 트랜잭션이 수행된 후에 데이터베이스는 또 다른 일관된 상태를 가져야함.
- 도중에 일시적으로 일관된 상태를 갖지 않을 수 있다.
- 고립성(Isolation)
- 한 트랜잭션이 데이터를 갱신하는 동안 이 트랜잭션이 완료되기 전까지는 어떤 트랜잭션도 접근하지 못 함.
- DBMS는 응용들의 요구사항에 따라 다양한 고립 수준을 제공
- 지속성(Durability)
- 일단 한 트랜잭션이 완료되면 이 트랜잭션이 갱신한 것은 그 후에 시스템에 고장이 발생하더라도 손실되지 않는다.
- 트랜잭션의 완료(commit)
- 트랜잭션에서 변경하려는 내용이 데이터베이스에 완전하게 반영
- 트랜잭션의 철회(abort)
- 트랜잭션에서 변경하려는 내용이 일부만 반영된 경우 원자성을 보장하기 위해, 트랜잭션이 갱신한 사항을 트랜잭션이 수행되기 전의 상태로 되돌림.
- 직렬 스케줄(serial schedule)
- 여러 트랜잭션들의 집합을 한 번에 한 트랜잭션씩 수행
- 비직렬 스케줄(non - serial schedule)
- 여러 트랜잭션들을 동시에 수행
- 직렬가능(serializable)
- 비직렬 스케줄의 결과가 어떤 직렬 스케줄의 수행 결과와 동등함.
- 동시성 제어를 하지 않고 다수의 트랜잭션을 동시에 수행할 때 생길 수 있는 문제
- 갱신 손실 : 수행 중인 트랜잭션이 갱신한 내용을 다른 트랜잭션이 덮어 써버려서 갱신이 무효화 됨.
- 오손 데이터 읽기 : 완료되지 않은 트랜잭션이 갱신한 데이터를 읽음
- 반복할 수 없는 읽기 : 한 트랜잭션이 동일한 데이터를 두 번 읽을 때 서로 다른 값을 읽는 것.
- 로킹(locking)
- 로크(lock)는 데이터베이스 내의 각 데이터 항목과 연관된 변수
- 각 트랜잭션이 수행을 시작하여 데이터 항목을 접근할 때마다 요청한 로크에 관한 정보는 로크 테이블(lock table) 등에 유지.
- 트랜잭션에서 데이터 항목을 접근할 때 로크를 요청
- 접근을 끝낸 후에 로크를 해제(unlock)함.
- 갱신 목적 접근 : 독점 로크(X-lock) 요청
- 읽기 목적 접근 : 공유 로크(S-lock) 요청
- 2단계 로킹 프로토콜
- 로크를 요청하는 것과 로크를 해제하는 것이 2단계로 이루어짐.
- 로크 확장 단계가 지난 후에 로크 수축 단계에 들어감.
- 로크를 한 개라도 해제하면 로크 수축 단계에 들어감.
- 로크 확장 단계(1단계)
- 트랜잭션이 데이터 항목에 대하여 새로운 로크를 요청할 수 있지만 보유하고 있던 로크를 하나라도 해제할 수 없다.
- 로크 수축 단계(2단계)
- 로크를 해제할 수 있지만 새로운 로크를 요청할 수 없다.
- 로크 포인트(lock point)는 한 트랜잭션에서 필요로 하는 모든 로크를 걸어놓은 시점.
- 데드록(deadlock)
- 2단계 로킹 프로토콜에서는 데드록이 발생할 수 있다.
- 두 개 이상의 트랜잭션들이 서로 상대방이 보유하고 있는 로크를 요청하면서 기다리고 있는 상태.
- 팬텀 문제(phantom problem)
- 만약 트랜잭션 T1이 select, T2가 insert이고 T3가 select라면 T1과 T3의 수행결과가 다르게 나타는 것을 팬텀문제라고 한다.
- 원자성 보장과, 데이터베이스 지속성을 보장하기 위해 필요.
- 재해적 고장과 비해재적 고장으로 저장 장치가 고장날 수 있다.
- 재해적 경우 데이터베이스를 백업해 놓은 자기 테이프를 기반으로 회복한다.
- 비재해적 경우 로그를 기반으로 한 즉시 갱신, 지연 갱신, 그림자 페이징 등 여러 알고리즘이 존재한다. 대부분 즉시 갱신 방식을 사용한다.
- 로그를 사용한 즉시 갱신
- 안전 저장 장치에 저장된 로그를 통해 회복.
- 이중 로그 : 로그를 두 개의 디스크에 중복해서 저장.
- 트랜잭션의 완료점(commit point)
- 한 트랜잭션의 데이터베이스 갱신 연산이 모두 끝나고 데이터베이스 갱신사항이 로그에 기록되었을 때
- 로그 먼저 쓰기(WAL : Write - Ahead - Logging)
- 트랜잭션이 데이터베이스를 갱신하면 주기억 장치의 데이터베이스 버퍼에 갱신 사항을 기록하고, 로그 버퍼에는 이에 대응하는 로그 레코드를 기록.
- 일반적으로 체크포인트를 10~20분마다 한 번씩 수행.
- 체크포인트를 할 때
- 트랜잭션들을 일시적으로 중지
- 로그 버프를 디스크에 강제 출력, 데이터베이스 버퍼를 디스크에 강제로 출력
- 로그 레코드를 로그 버퍼에 기록한 후 디스크에 강제로 출력
- [checkpoint] 로그 레코드를 로그 버퍼에 기록한 후 디스크에 강제로 출력
- 체크포인트 시점에 수행 중이던 트랜잭션들의 대한 정보도 함께 기록
- 일시적으로 중지된 트랜잭션의 수행을 재개
-
고립 수준
- 고립 수준은 한 트랜잭션과 다른 트랜잭션이 고립되어야 하는 정도를 나타낸다.
- 수준이 낮으면 동시성은 높아지지만 데이터 정확성은 떨어진다. 높으면 반대
- 응용의 성격에 따라 고립 수준을 바꿀 수 있고, 그에 따른 로킹 동작이 달라진다.
- READ UNCOMMITED
- 가장 낮은 고립 수준
- 트랜잭션 내의 질의들이 공유 로크를 걸지 않고 데이터를 읽는다. 따라서 오손 데이터를 읽을 수 있다.
- 갱신하려는 데이터에 대해서는 독점 로크를 걸고, 트랜잭션이 끝날때까지 보유한다.
- READ COMMITED
- 읽으려는 데이터에 대해 공유 로크를 건다. 읽기가 끝난 후에 로크를 해제한다.
- 따라서 이전에 읽은 값과 다른 값을 읽는 경우가 생길 수 있따.
- 갱신하려는 데이터에 대해서는 독점 로크를 걸고, 트랜잭션이 끝날때까지 보유한다.
- PL/SQL의 디폴트 값이다.
- REPEATABLE READ
- 질의에서 검색되는 데이터에 대해 공유 로크를 걸고, 트랜잭션이 끝날때까지 보유한다.
- 동일한 질의 시 값이 항상 동일하게 유지된다.
- 갱신하려는 데이터에 대해서는 독점 로크를 걸고, 끝날때까지 보유한다.
- SERIALIZABLE
- 가장 높은 수준의 고립
- 질의에서 검색되는 투플들 뿐만 아니라 인덱스에 대해서도 공유로크를 걸고 끝날때까지 보유한다.
- 외에는 REPEATABLE RAED와 같다.
- 원자성(Atomicity)
-
-
SQL(문제푼 것, 다같이 풀어보아요. ㅎ
leetcode 175(Eazy) - Combine Two Tables 문제 :
<https://leetcode.com/problems/combine-two-tables/>
leetcode 176(Eazy) - Second Highest Salary
<https://leetcode.com/problems/second-highest-salary/>
leetcode 181(Eazy) - Employees Earning More Than Their Managers
<https://leetcode.com/problems/employees-earning-more-than-their-managers/>
leetcode 182(Eazy) - Duplicate Emails
기본 문법
-
SELECT, count(), DISTINCT
기본 질의어
SELECT first_name FROM employees.employees;
결과
count() - 데이터의 갯수를 센다.
- ()안에 *가 있을 경우 전체 행을 가져오고
- ()안에 컬럼명을 넣을 시 해당 컬럼의 갯수를 가져온다
- NULL인 데이터는 제외하고 계산한다.
SELECT count(first_name) FROM employees.employees; --별칭을 주면 다르게 이름 가능--
결과
DISTINCT - 중복제거
SELECT count(distinct first_name) FROM employees.employees;
결과
-
WHERE(<, >, ≥, ≤, <>는 ≠, Like, BETWEEN, IN, AND, OR , NOT)
특이점으로 BETWEEN은 (x,y] 표기법이다. → x초과 y이하
NOT 뒤에 조건이 오는 것.
SELECT * FROM employees.employees where emp_no = 10001; SELECT * FROM employees.employees where emp_no > 10500; SELECT * FROM employees.employees where emp_no < 10500; SELECT * FROM employees.employees where emp_no >= 10500; SELECT * FROM employees.employees where emp_no <= 10500; SELECT * FROM employees.employees where emp_no <> 10500; SELECT * FROM employees.employees where emp_no BETWEEN 10000 and 10100; SELECT * FROM employees.employees where last_name LIKE('Facello'); SELECT * FROM employees.employees where emp_no IN (10001,10005); SELECT * FROM employees.employees where last_name = 'Facello' or last_name = 'Simmel'; SELECT * FROM employees.employees where last_name = 'Facello' or first_name = 'Bezalel'; SELECT * FROM employees.employees where NOT last_name = 'Facello'; SELECT * FROM employees.employees where last_name = 'Facello' and (emp_no > 14900 or emp_no < 10100); SELECT * FROM employees.employees where NOT last_name = 'Facello' and NOT emp_no > 20000;
BETWEEN 결과 :
...
-
Order by - ASC(오름차순), DESC(내림차순)
SELECT * FROM employees.employees order by last_name; SELECT * FROM employees.employees order by last_name DESC; SELECT * FROM employees.employees order by last_name, first_name; SELECT * FROM employees.employees order by last_name, first_name DESC;
-
INTO
INSERT INTO table_name (column1, column2, column3, ...) VALUES (value1, value2, value3, ...); //전체가 아닌 몇개만 값을 지정하고 테이블에 추가하고 싶을때 사용 INSERT INTO table_name VALUES (value1, value2, value3, ...); //전체 값을 지정하고 테이블에 추가하고 싶을때 사용
-
NULL
SELECT * FROM employees.employees WHERE first_name IS NULL; SELECT * FROM employees.employees WHERE first_name IS NOT NULL;
-
UPDATE
UPDATE table_name SET column1 = value1, column2 = value2, ... WHERE condition; --키 안전조건 때문에 예제는.. UPDATE employees.employees SET employees.first_name = 'kms' WHERE employees.last_name = 'Facello';
-
DELETE
DELETE FROM table_name WHERE condition;
-
SELECT + TOP ,MYSQL에서는 LIMIT
-- 기본 문법 SELECT column_name(s) FROM table_name WHERE condition LIMIT number; -- 예제 SELECT * FROM employees.employees WHERE emp_no > 10005 LIMIT 3; --emp_no가 10005을 넘는 데이터를 위에서 3개의 데이터만 출력
-
Min(), Max()
SELECT MAX(employees.birth_date), MIN(employees.birth_date) AS min_emp_birth FROM employees.employees WHERE employees.emp_no > 10500; -- emp_no이 10500을 넘는 것중 birth_date가 제일 큰 값, 제일 작은 값을 찾아 보여준다. 작은 값의 이름은 min_emp_birth로 한다.
-
Count(), Sum(), AVG()
-- COUNT() function : 조건에 맞는 row의 갯수 -- The AVG() : numeric colum의 평균 값 출력 -- The SUM() : numeric colum의 총합 출력 -- date형식도 되는데 원하는 값이 나오지는 않는다. -- 예제 SELECT COUNT(emp_no), AVG(emp_no), SUM(emp_no), AVG(birth_date), SUM(birth_date), COUNT(birth_datE) FROM employees.employees;
-
Like operator, NOT LIKE
% : 0개나 1개의 문자를 의미
_ : 1개의 문자를 의미
NOT 과 사용할 경우 NOT이 먼저 나와야함. NOT LIKE임.
-- SELECT column1, column2, ... -- FROM table_name -- WHERE columnN LIKE pattern; -- 예제 -- last_name이 F로 시작하는 것들. SELECT last_name FROM employees.employees WHERE last_name LIKE 'F%'; -- last_name이 F로 시작하고 문자열의 길이가 5인 것들. SELECT last_name FROM employees.employees WHERE last_name LIKE 'F____'; -- F로 끝나는 것들. SELECT last_name FROM employees.employees WHERE last_name LIKE '%F'; -- F로 시작하고 a로 끝나는 것들. SELECT last_name FROM employees.employees WHERE last_name LIKE 'F%a'; -- F로 시작하고 a는 아무데나 있으면 되는 경우.(끝 포함.) SELECT last_name FROM employees.employees WHERE last_name LIKE 'F%a%'; -- F로 시작하고 a는 아무데나 있으면 되는 경우를 제외한 경우.(끝 포함.) SELECT last_name FROM employees.employees WHERE last_name NOT LIKE 'F%a%';
-
IN operator
-- 기본 구문 SELECT column_name(s) FROM table_name WHERE column_name IN (value1, value2, ...); SELECT column_name(s) FROM table_name WHERE column_name IN (SELECT STATEMENT); -- 예제 -- last_name이 'Facello'이거나, 'Koblick'인 사람의 emp_no를 찾기 SELECT emp_no FROM employees.employees WHERE last_name IN ('Facello', 'Koblick'); -- employees 테이블의 last_name을 찾는데, dept_manage에 있는 emp_no에 속해있는 사람들을 뽑음 SELECT last_name FROM employees.employees WHERE emp_no IN (SELECT emp_no FROM employees.dept_manager);
-
BETWEEN + 날짜, 여러구문
-- birthdate가 1953년 09.02 부터 1954.05.01까지인 사람. 또한 emp_no가 10500을 넘지 않는 사람 SELECT * FROM employees.employees WHERE birth_date BETWEEN '1953-09-02' AND '1954-05-01' AND NOT emp_no > 10500;
-
AS + CONCAT(), table AS
-- firstname과 emp_no을 ','로 구문하여 합친 것을 hello라는 column으로 보여줌. SELECT last_name, CONCAT(first_name, ', ', emp_no) AS hello FROM employees.employees;
-- emp_no와 title을 보여준다. employees 테이블은 e로, titles테이블은 t로 축약. SELECT e.emp_no, t.title FROM employees.employees AS e, employees.titles AS t WHERE e.emp_no = t.emp_no;
-
JOIN(INNER, LEFT, RIGHT, FULL OUTER - MYSQL에서 지원하지 않기에 UNION, SELF)
-- INNER JOIN (교집합) SELECT employees.emp_no, titles.title FROM employees.employees INNER JOIN employees.titles ON employees.emp_no = employees.titles.emp_no; -- LEFT JOIN (왼쪽 테이블 기준) /* 조인을 하는데, titles 테이블에 있는 title을 오름차순, 같으면 emp_no기준으로 오름차순 */ SELECT employees.emp_no, titles.title FROM employees.employees LEFT JOIN employees.titles ON employees.emp_no = employees.titles.emp_no ORDER BY titles.title ASC, employees.emp_no ASC; -- RIGHT JOIN(오른쪽 테이블 기준) /* 위와 마찬가지. */ SELECT employees.emp_no, titles.title FROM employees.employees RIGHT JOIN employees.titles ON employees.emp_no = employees.titles.emp_no ORDER BY titles.title ASC, employees.emp_no ASC; -- MYSQL은 FULL OUTER JOIN을 지원하지 않는다. LEFT JOIN + RIGHT JOIN 해야함. SELECT employees.emp_no, titles.title FROM employees.employees LEFT JOIN employees.titles ON employees.emp_no = titles.emp_no UNION SELECT employees.emp_no, titles.title FROM employees.employees RIGHT JOIN employees.titles ON employees.emp_no = titles.emp_no; -- SELF JOIN -- empno가 서로 다른 모든 경우의 수를 출력하는데 밑의 양식에 따라 출력. SELECT e.last_name AS e1last_name, e2.last_name AS e2last_name, e.emp_no, e2.emp_no FROM employees.employees e, employees.employees e2 WHERE e.emp_no <> e2.emp_no
— left join —
— FULL OUTER JOIN (union) —
— SELF JOIN —
-
GROUP BY
-- 기본 SELECT COUNT(emp_no) AS last_name_count, birth_date, last_name FROM employees.employees GROUP BY last_name; -- 약간 응용 밑의 결과 쿼리 SELECT COUNT(emp_no) AS last_name_count, birth_date, last_name FROM employees.employees GROUP BY last_name ORDER BY COUNT(emp_no) DESC;
-
HAVING
SELECT COUNT(last_name), last_name FROM employees.employees GROUP BY last_name HAVING COUNT(last_name) < 200 ORDER BY last_name DESC;
-
IF(), IFNULL(), CASE
SELECT
-
잡다