관계 데이터 연산 01 관계 데이터 연산의 개념 02 관계 대수 03 관계 해석 목표 ▪ 관계 데이터 연산의 개념과 종류를 알아본다. ▪ 일반 집합 연산자와 순수 관계 연산자의 차이를 이해한다. ▪ 일반 집합 연산자와 순수 관계 연산자를 이용해 질의를 표현하는 방법을 익힌다. ▪ 관계 해석의 개념을 간단히 정리해본다. 01 관계 데이터 연산의 개념 ◆ 데이터모델 = 데이터구조 + 연산 + 제약조건 ◆ 관계 데이터 연산(relational data operation) 관계 데이터 모델의 연산 원하는 데이터를 얻기 위해 릴레이션에 필요한 처리 요구를 수행하는 것 관계대수와 관계해석 ◆ 관계대수와 관계해석의 역할 데이터 언어의 유용성을 검증하는 기준 관계 대수나 관계 해석으로 기술할 수 있는 모든 질의를 기술..
관계 데이터 모델 01 관계 데이터 모델의 개념 02 관계 데이터 모델의 제약 목표 ▪ 관계 데이터 모델의 기본 용어를 익힌다. ▪ 릴레이션을 구성하는 요소와 특성을 이해한다. ▪ 릴레이션에서 키의 역할과 종류를 알아본다. ▪ 무결성 제약의 의미와 필요성을 이해한다. 01 관계 데이터 모델의 개념 ◆ 관계 데이터 모델의 기본 개념 개념적 구조를 논리적 구조로 표현하는 논리적 데이터 모델 하나의 개체 관한 데이터를 하나의 릴레이션에 저장 ◆ 관계 데이터 모델의 기본 용어 릴레이션(relation) 하나의 개체에 관한 데이터를 2차원 테이블의 구조로 저장한 것 파일 관리 시스템 관점에서 파일(file)에 대응 속성(attribute) 릴레이션의 열 파일 관리 시스템 관점에서 필드(field)에 대응 튜플(t..
데이터 모델링 01 데이터 모델링과 데이터 모델의 개념 02 개체-관계 모델 03 논리적 데이터 모델 목표 ▪ 데이터 모델링과 데이터 모델의 개념을 이해한다. ▪ 개념적 데이터 모델인 개체-관계 모델을 이용해 모델링하는 방법을 익힌다. ▪ 개체-관계 다이어그램을 작성하는 방법을 익힌다. ▪ 논리적 데이터 모델의 종류와 특징을 이해한다 01 데이터 모델링과 데이터 모델의 개념 ◆ 2단계 데이터 모델링 개념적 데이터 모델링(conceptual modeling) 현실 세계의 중요 데이터를 추출하여 개념 세계로 옮기는 작업 논리적 데이터 모델링(logical modeling) 개념 세계의 데이터를 데이터베이스에 저장하는 구조로 표현 하는 작업 ◆ 데이터 모델 데이터 모델링의 결과물을 표현하는 도구 개념적 데이터..
데이터베이스 시스템 데이터베이스 시스템의 정의 데이터베이스의 구조 데이터베이스 사용자 데이터 언어 데이터베이스 관리 시스템의 구성 목표 데이터베이스, 데이터베이스 관리 시스템, 데이터베이스 시스템의 차이를 이해한다. 데이터베이스 시스템의 구성 요소를 살펴본다. 데이터베이스 3단계 구조에서 데이터 독립성의 개념을 실현하는 방법을 이해한다. 데이터 언어별 특징을 알아본다. 데이터베이스 사용자별 특징을 알아본다. 데이터베이스 관리 시스템의 구성을 알아본다. 01 데이터베이스 시스템의 정의 데이터베이스 시스템(DBS; DataBase System): 데이터베이스에 데이터를 저장하고, 이를 관리하여 조직에 필요한 정보를 생성해주는 시스템 02 데이터베이스의 구조 ◆ 스키마와 인스턴스 스키마: 데이터베이스에 저장되..
데이터 베이스 기본 개념 01 데이터베이스의 필요성 02 데이터베이스의 정의와 특징 03 데이터 과학 시대의 데이터 목표 ▪ 데이터와 정보의 차이를 이해한다. ▪ 데이터베이스의 필요성을 알아본다. ▪ 데이터베이스의 정의에 숨겨진 의미와 주요 특징을 이해한다. ▪ 형태와 특성에 따른 데이터 분류 방법을 알아본다. 01. 데이터베이스의 필요성 ◆ 데이터와 정보 데이터(data) • 현실 세계에서 단순히 관찰하거나 측정하여 수집한 사실이나 값 정보(information) • 의사 결정에 유용하게 활용할 수 있도록 데이터를 처리한 결과물 ◆정보 시스템과 데이터베이스 정보 시스템(information system) • 조직 운영에 필요한 데이터를 수집하여 저장해두었다가 필요할 때 유용한 정보를 만들어 주는 수단 ..
Semaphore를 사용할 때 어떤 상황에서 프로세스가 기다려야 하는가? 프로세스가 몇 개의 Queue로 나뉘어져 관리가 되어야 하는가? → Queue의 개수를 결정해야 한다. Queue의 수만큼 Semaphore를 생성한다. → Semaphore 1개당 Queue 1개 Semaphore에는 딱 두가지 함수만이 존재한다. → 이 두가지 함수만으로 다양한 동기화 문제를 해결할 수 있다. semWait semSignal Bounded Buffer using Semaphores 위의 코드에서 세마포는 3가지가 존재한다. s → Queue에 Produce와 Consumer가 섞여서 들어간다. n → Queue에 Consumer만이 들어간다. e → Queue에 Producer만이 들어간다. Producer Pr..
2023년 04월 16일 기준 (문제 업데이트 중) 3월에 태어난 여성 회원 목록 출력하기 (LEVEL 2) https://school.programmers.co.kr/learn/courses/30/lessons/131120 프로그래머스 코드 중심의 개발자 채용. 스택 기반의 포지션 매칭. 프로그래머스의 개발자 맞춤형 프로필을 등록하고, 나와 기술 궁합이 잘 맞는 기업들을 매칭 받으세요. programmers.co.kr SELECT MEMBER_ID, MEMBER_NAME, GENDER, DATE_FORMAT(DATE_OF_BIRTH, '%Y-%m-%d') AS DATE_OF_BIRTH FROM MEMBER_PROFILE WHERE MONTH(DATE_OF_BIRTH)=3 AND GENDER='W' AN..
2023년 04월 16일 기준 (문제 업데이트 중) 조건에 맞는 회원수 구하기 (LEVEL 1) https://school.programmers.co.kr/learn/courses/30/lessons/131535 프로그래머스 코드 중심의 개발자 채용. 스택 기반의 포지션 매칭. 프로그래머스의 개발자 맞춤형 프로필을 등록하고, 나와 기술 궁합이 잘 맞는 기업들을 매칭 받으세요. programmers.co.kr SELECT COUNT(user_id) as users FROM user_info WHERE YEAR(joined) = '2021' AND age >= 20 AND age
프로세스가 몇 개의 Queue로 나뉘어져 관리가 되어야 하는가? → Queue의 개수를 결정해야 한다.
Queue의 수만큼 Semaphore를 생성한다. → Semaphore 1개당 Queue 1개
Semaphore에는 딱 두가지 함수만이 존재한다. → 이 두가지 함수만으로 다양한 동기화 문제를 해결할 수 있다.
semWait
semSignal
Bounded Buffer using Semaphores
위의 코드에서 세마포는 3가지가 존재한다.
s → Queue에 Produce와 Consumer가 섞여서 들어간다.
n → Queue에 Consumer만이 들어간다.
e → Queue에 Producer만이 들어간다.
Producer Process:
Buffer가 가득 찼는지 확인
Critical Section 진입 가능 여부 확인
Buffer에 데이터 쓰기
Critical Section 깨워주기
Consumer 깨워주기
Consumer Process:
Buffer가 비었는지 확인
Critical Section 진입 가능 여부 확인
Buffer에서 데이터 읽기
Criitcal Section 깨워주기
Producer 깨워주기
Monitors
OS는 Semaphore를 제공해서 우리가 Semaphore를 이용하여 여러 문제를 해결할 수 있게 해준다. ↔ 하지만, 잘못 사용하게 되면 Deadlock이 발생할 수 있다.
Monitor는 Programming-language construct 이다.
semaphore와 동등한 기능을 제공하고, 제어하기 쉬운 프로그래밍 언어 구조이다.
Programming-language construct
Programming-language construct 는 라이브러리 함수이다.
File에서 Data를 다룰 때 System Call에는 오로지 READ, WRITE만 존재한다. 하지만, READ, WRITE는 데이터 타입 구분을 하지 않는다. ⇒ 쉽게 시스템을 사용할 수 있게 하기 위해(입출력하기 위해) Buffering와 Printf, Scanf 와 같은 라이브러리를 이용한다.
이와 같이 우리가 바로 Semaphore 를 사용하게 되면, 어렵기도 하고 잘못 사용하면 Deadlock 이 발생할 수 있기 때문에 Monitor 라는 모듈 라이브러리를 사용하는 것이다.
간단히 말해서 Monitor 는 Semaphore 를 구현해 놓은 module이다.
Monitor 는 software module 이다.
Monitor의 구성요소
한 가지 이상의 Procedures
initialization sequence
local data
Structure of a Monitor
Monitor
Monitor 자체가 Critical Section이다. → 한 번에 하나의 Process만 Monitor에 진입할 수 있다.
ex) Process1이 Procedure1을 실행하고 싶어하고,
Process2가 Proedure2를 실행하고 싶어서 동시 호출해도,
Monitor 안에는 하나의 Process만 진입할 수 있고
다른 프로세스들은 모니터 밖의 Queue에서 대기하게 된다.
local data
monitor에 대한 local 이다. → Procedure 입장에서는 전역 변수이다. 즉, 여러 Procedure에서 access할 수 있는 변수이다. ⇒ Monitor 안에서만 access가 가능하다. ⇒ 두 프로세스 동시 접근 불가
Procedure
여러개의 Procedure가 존재한다. (1~k) Monitor "안" 에서만 실행된다.
어떤 프로세스가 Procedure를 실행시키기 위해서는 monitor 안에 들어와서 실행해야 한다.
cwait(cn)
호출한 프로세스가 바로 Block된다. → 바로 Condition Queue로 들어가게 된다. → 이후 바깥의 Queue에서 대기 중이던 프로세스가 Monitor로 들어온다.
urgent queue
monitor 안에 Process1가 Procedure1을 실행 중 → semSignal(c) 호출 → 새로운 Process가 monitor 안으로 들어오게 됨
이 경우, monitor 바깥의 Queue에서 대기하다가 막 깨어난 프로세스가 우선순위를 갖게 되어 막 들어온 프로세스가 monitor 작업을 진행하게 된다. 원래 monitor안에서 실행 중이던 Process1은 Urgent Queue로 들어가서 block 하게 된다.
→ 이후 바깥에서 막 들어온 프로세스가 작업 진행을 마치면 다시 Process1이 Urgent Queue에서 나와 원래 하던 작업을 실행하고 monitor에서 나가게 된다. → 이후 바깥의 Queue에서 대기하던 프로세스 중 하나가 monitor에 들어오게 된다.
Characteristics
Local data variables are accessible only by the monitor ↳ Monitor들은 local data variable에 한 번에 하나만 접근할 수 있다.
Process enters monitor by invoking one of its procedures ↳ Process가 Procedure를 호출하면 monitor안으로 들어 오게 되고, procedure에서 연산을 진행하게 된다. 밖에서는 연산이 불가능하다. ⇒ Mutual Exclusion 이 지켜진다.
Only one process may be executing in the monitor at a time (mutual exclusion facility) ↳ 오직 하나의 프로세스만이 monitor를 실행할 수 있다. ⇒ Mutual Exclusion facility
Synchronization
condition variables
Synchronization achieved by condition variables within a monitor ↳ only accessible by the monitor.
condition variables 는 버퍼가 차있는지 동기화를 해결하기 위해 사용된다.
monitor 안에서만 사용 가능
Queue 존재
Semaphore와 다르다. ↔ condition variable에는 정수값이 존재하지 않는다. Queue만 존재한다.
Monitor Functions
cwait(c)
Suspend execution of the calling process on condition c → 무조건 이 함수를 호출한 Process를 Block 시킨다.
csignal(c)
Resume execution of some process blocked after a cwait on the same condition → Queue에 있는 Process 하나를 꺼내서 Monitor 안으로 들여온다. 세마포와 달리, 정수 값이 없기 때문에 Queue가 비었는지 안비었는지 확인할 수 없다.
Bounded Buffer Solution Using Monitor(2)
여러개의 Producer와 Consumer들이 존재하는 상황이다.
char x와 같이 데이터를 만드는 작업이나 consume()은 monitor 바깥에서 작업해도 된다. ↔ 하지만, append()와 take() 작업은 반드시 monitor 안에서 작업해야한다.
Bounded Buffer Solution Using Monitor
boundedbuffer
monitor boundedbuffer;
데이터를 읽고 쓰기 전 후 monitor 안에서 둘 이상의 Producer가 append를 동시에 하는 것을 막고, 둘 이상의 Consumer가 take를 동시에 하는 것을 막는다.
buffer[N]
char buffer [N]
N 크기의 버퍼
nextin, nextout
int nextin, nextout;
nextin: 다음에 데이터를 쓸 위치
nextout: 다음에 데이터를 읽을 위치
count
int count;
local data → 버퍼의 데이터가 가득찼는지 안 찼는지를 판단한다.
notfull, notempty
cond notfull, notempty;
notfull: producer들이 버퍼가 full 했을 때 block 되는 Queue
notempty: consumer들이 버퍼가 empty 했을 때 block 되는 Queue
초기값
buffer initially empty
nextin = 0
nextout = 0
count = 0
Q. Count 변수를 사용할 수 있는 이유?
↳ monitor안의 local 변수 count를 사용했기 때문이다.
이 monitor 자체가 Critical Section이기 때문이다. Count는 monitor 안에 있기 때문에 연산이 가능한 것이고, Count를 사용해서 코드가 간단해졌다.
Semaphore에서는 count와 같은 변수를 사용할 수 없다.
Q. Monitor에서 Deadlock이 발생하지 않을까?
Semaphore로 Buffer 문제 해결했을 때는 코드 위치를 변경했을 때 Deadlock이 발생했다.
semWait(e) ↔ semWait(s) : Critical Section에 먼저 들어간 뒤, 버퍼가 찼는지 확인
semWait(n) ↔ semWait(s) : Critical Section에 먼저 들어간 뒤, 버퍼가 비었는지 확인
↔ monitor의 경우, Critical Section에 원래 먼저 들어간 뒤, 버퍼가 비었는지 꽉 찼는지를 확인한다. ⇒ Deadlock이 발생하지 않는다.
⇒ 왜 순서를 바꿨을 때, Semaphore는 Deadlock이 발생하고 왜 Monitor에서는 Deadlock이 발생하지 않을까?
Readers/Writers Problem
버퍼 안에 공유데이터 가 존재한다. → Producer와 Consumer처럼 서로 대칭 작업을 하는 두 종류의 프로세스가 있는 게 아니라, readers와 writers라고 하는 서로 비대칭 적인 작업을 하는 두 종류의 프로세스가 있다.
Readers와 Writers는 비대칭 작업 을 한다.
Readers : 동시 작업이 가능하다. → 공유 영역 데이터를 "읽기" 만 한다. ↳ 데이터 값 변경 X
Writers : 동시 작업이 불가능하다. (Race condition이 발생할 수 있다.) → 데이터를 쓰는 애 X, 데이터를 읽고 계산하고 쓰는 역할을 한다. ↳ 데이터 값 변경 O
r-r O
w-w X
r-w X
w-r X
A data area is shared among many processes
Some processes only read the data area, some only write to the area
Conditions to satisfy:
Multiple readers may read the file at once.
Only one writer at a time may write
If a writer is writing to the file, no reader may read it. → 만약 writer가 file에 쓰고 있다면, reader는 동시에 file을 읽을 수 없다.
Readers have Priority
Reader 하나 들어가면 나머지 reader가 따라 들어온다.
main()
readcount 공유변수 1개가 있고, 값을 0으로 초기화한다. reader, writer가 여러명 존재하며 동시에 작업을 시작할 수 있다.
비대칭적인 작업 ⇒ 이전과 달리 reader() 와 writer() 의 코드가 다른 것을 확인할 수 있다.
writer()
reader가 1명도 없다고 가정했을 때, writer는 그냥 critical section이다.
semWait(wsem) 을 통과해서 write 작업을 한다. 그 뒤 semSignal(wsem) 을 진행한다.
writer는 한 번에 하나씩만 critical section에 접근할 수 있는 완벽한 critical section 문제이다.
이 Ciritical Section 안에는 Data라고 하는 Buffer 가 있다. wsem seamaphore가 지키고 있는 Critical Section이다.
Critical Section 이기 때문에 wsem semaphore의 초기값이 1이다.
w1이 Critical Section으로 들어와서 읽고 쓰고 업데이트를 할 때, wsem의 값은 0이 된다. ⇒ Criitcal Section의 문은 닫히게 된다.
이 때 다른 writer 들이 Critical Section에 들어가고 싶어서 대기를 하면, wsem의 값을 하나씩 빼 가며 writer들이 줄을 서게 된다.
이 때, 밖의 wsem Queue에 reader 하나가 Critical Section에 들어가고자 등장한다. reader 도 당연히 줄을 서야 한다. ↳ writer 가 작업하고 있는 동안에 reader 는 들어갈 수 없다.
이후 두번째 reader 도 Critical Section에 들어가고자 나타났다고 하자. 그런데 이 reader 도 wsem Queue에 줄을 서야할까? ↳ 첫번째 reader 는 당연히 줄을 서야 한다. ⬇ r1이 들어가면 r2는 같이 들어간다. ⇒ 첫번째 reader 만 줄을 서고 나머지 reader 는 줄을 서지 않는다. 최대 1명의 reader 만 줄을 선다. (1개 또는 0개만 줄을 선다.)
어느 순간 wsem Queue를 보면, writer는 여러 명이 줄을 서있고, reader는 한 명만 줄을 서 있는다. 또는 reader가 아무도 없을 수도 있다.
만약 reader 가 자신의 차례를 기다리다가 차례가 되어 Critical Section 안으로 들어왔다고 가정하자. 밖에는 여전히 Writer 들이 wsem Queue에서 대기를 하고 있는데, 만약 이 때 새로운 reader 가 등장하게 되면 이 reader는 대기할 필요가 없다.
그냥 같이 들어가서 READ 작업을 하면 된다.
위와 같이 여러명의 reader들이 동시에 읽을 수 있다.
⇒ Critical Section 안에 reader 가 들어있다 == wsem Queue 안에는 대기하는 reader 가 존재하지 않는다.
r1이 작업을 완료해서 Critical Section을 나오게 된다. 원래는 Critical Section에서 작업하던 애가 작업을 마치고 나올때는 바깥 Queue에 대기하고 있던 애를 깨워주고 Critical Section에 넣어주고 나가게 된다.
그런데 여기서는 r1이 작업이 끝났다고 해서 대기하고 있던 프로세스를 Critical Section 안에 넣어줄 수 없다. → 아직 reader들이 남아있기 때문이다.
Critical Section 안에 들어있는 모든 reader 가 작업을 마칠 때까지 writer 는 Critical Section 에 들어올 수 없다.
reader 의 경우, 첫번째 reader 만 줄을 서기 때문에, 내가 첫번째 reader 인지 알아야 한다. 또, 마지막에 나오는 reader 의 경우에만 semSignal()을 해서 writer 를 깨워서 Critical Section 안에 넣어줄 것이다. ⇒ 내가 몇 번째 reader 인지 알아야 한다. ↳ 이 일을 하는 것이 readCount 이다.
readCount
초기값 = 0
reader가 한 명씩 올때마다 readCount를 하나씩 증가시킨다.
reader가 작업을 마칠때마다 readCount를 하나씩 감소시킨다.
⇒ 내가 몇 번째 reader 인지 알 수 있다.
readCount 자체는 Critical Section 안에서 연산(+, -)를 진행해야 한다.
⇒ Critical Section 이 하나 더 필요하다!
X라고 하는 Critical Section을 하나 더 사용할 것이다.
readCount를 이 Critical Section 안에 집어 넣는다.
새로운 reader가 도착하면 readCount++ 를 Critical Section 안에 들어가서 진행한다.
작업을 다 마치고 나면, readCount-- 를 Critical Section 안에서 진행한다.
내가 read 작업을 하기 전에, readCount++ 를 하는데, Critical Section 에서 작업하기 위해 → semWait(x) 를 통해 Critical Section 진입한 후 readCount 연산을 진행한다.
내가 read 작업을 다 마친 후, readCount-- 를 하는데, Critical Section 에서 작업하기 위해 → semWait(x) 를 통해 Critical Section 진입한 후 readCount 연산을 진행한다.
readCount == 1 일 때, 해당 reader 가 첫번째 reader 라는 뜻이므로 wsemWait에 가서 줄을 설 것이다.
if(readCount == 1) semWait(wsem);
readCount == 0 일 때, 해당 reader 가 마지막 reader 라는 뜻이므로 semSignal(wsem)을 통해 wsemQueue에서 대기 중이던 writer 를 Critical Section 안으로 들여보내 줄 것이다.
if(readCount == 0) semSignal(wsem);
reader들이 줄 서 있는 곳?
첫 번째 reader 만 wsemQueue에 줄을 서는데, 그렇다면 나머지 reader 들은 어디에서 줄을 설까? → x 라고 하는 semaphore Queue에서 줄을 선다.
x semaphore 의 기능
Critical Section 기능 구현: readCount++, readCount-- 를 둘 이상의 reader 가 동시에 실행하면 안되기 때문에 한 번에 하나씩만 readCount 연산을 진행하기 위해 사용하는 semaphore
대기하고 있던 reader 들을 줄 세우는 작업을 한다.
r1
semWait(x) → x = 0
readCount++ → readCount = 1
semWait(wsem) → wsem Queue에 대기 → 이미 wsem에는 대기 프로세스가 앞에 있어 문이 닫혀 있는 상태라 통과 X ⇒ 다음 코드로 넘어갈 수 없다. ⇒ swmSignal(x)를 해서 reader 들을 blocked 상태에서 풀어줄 수 없다.
r2
semWait(x) → x = -1
Critical Section에 들어가지 못한다.
r1이 Critical Section에 들어가지 못했기 때문에 다른 reader 들이 x Queue에서 대기하고 있어도 readCount는 여전히 1이다. Critical Section에 들어가지 못했기 때문에 readCount 값을 바꿀 수 없다.
reader 가 4명이나 있어도 reader 들 중에 어느 누구도 Critical Section 에 들어가서 data를 읽지 못하는 상황에서는 readCount가 계속 1을 유지한다.
여러명의 reader 가 도착했더라도 하나의 reader 만 wsem Queue에 대기하고 나머지 reader 들은 x Blocked Queue에서 대기하게 된다.
Writer 가 작업을 마침 r1이 드디어 Critical Section 에 들어가게 된다.
semSignal(x) 를 실행한다.
x Queue에 대기하고 있던 reader 를 Critical Section으로 넣어준다.
readCount가 1 증가한다.
semSignal(x) → 다른 reader 를 깨워준다.
늦게온 r5가 먼저 기다리고 있던 w들보다 먼저 실행된다.
정리
writer
writer 는 기본적으로 Critical Section 이다.
wsem 을 이용해서 기본 Critical Section 을 구현한다.
reader
reader 의 경우, 첫 번째 reader 만 wsem 에 대한 semWait(wsem)을 실행한다.
마지막 reader 만 wsem 에 대한 semSignal(wsem)을 실행한다. → 다음 writer 를 Critical Section 으로 넣어준다.
SELECT MEMBER_ID, MEMBER_NAME, GENDER, DATE_FORMAT(DATE_OF_BIRTH, '%Y-%m-%d') AS DATE_OF_BIRTH
FROM MEMBER_PROFILE
WHERE MONTH(DATE_OF_BIRTH)=3 AND GENDER='W' AND NOT TLNO IS NULL
ORDER BY MEMBER_ID ASC
SELECT A.REST_ID, B.REST_NAME, B.FOOD_TYPE, B.FAVORITES, B.ADDRESS, ROUND(AVG(A.REVIEW_SCORE),2) AS SCORE
FROM REST_REVIEW AS A
JOIN REST_INFO AS B ON A.REST_ID=B.REST_ID
GROUP BY A.REST_ID
HAVING B.ADDRESS LIKE '서울%'
ORDER BY SCORE DESC, B.FAVORITES DESC
SELECT DATE_FORMAT(SALES_DATE, '%Y-%m-%d') AS SALES_DATE, PRODUCT_ID, USER_ID,SALES_AMOUNT
FROM ONLINE_SALE
WHERE MONTH(SALES_DATE)=3
UNION ALL
SELECT DATE_FORMAT(SALES_DATE, '%Y-%m-%d') AS SALES_DATE, PRODUCT_ID, NULL AS USER_ID,SALES_AMOUNT
FROM OFFLINE_SALE
WHERE MONTH(SALES_DATE)=3
ORDER BY SALES_DATE ASC, PRODUCT_ID ASC, USER_ID ASC
SELECT BOOK_ID, DATE_FORMAT(PUBLISHED_DATE, '%Y-%m-%d') AS PUSBLISHED_DATE
FROM BOOK
WHERE CATEGORY='인문' AND YEAR(PUBLISHED_DATE)='2021'
ORDER BY PUBLISHED_DATE;
SELECT A.TITLE, A.BOARD_ID, B.REPLY_ID, B.WRITER_ID, B.CONTENTS, DATE_FORMAT(B.CREATED_DATE, '%Y-%m-%d')
FROM USED_GOODS_BOARD AS A
JOIN USED_GOODS_REPLY AS B
ON A.BOARD_ID=B.BOARD_ID
WHERE MONTH(A.CREATED_DATE)=10
ORDER BY B.CREATED_DATE, A.TITLE
SELECT DR_NAME, DR_ID,MCDP_CD, DATE_FORMAT(HIRE_YMD, '%Y-%m-%d') AS HIRE_YMD
FROM DOCTOR
WHERE MCDP_CD = 'CS' OR MCDP_CD= 'GS'
ORDER BY HIRE_YMD DESC, DR_NAME ASC
SELECT A.FLAVOR
FROM FIRST_HALF AS A
JOIN ICECREAM_INFO AS B ON A.FLAVOR=B.FLAVOR
WHERE A.TOTAL_ORDER>3000 AND B.INGREDIENT_TYPE='fruit_based'
ORDER BY A.TOTAL_ORDER DESC
