SQL Query
여기서 DML, DDL,DCL이 뭔지 알고, 각 명령어를 알아야 한다.
테이블(Table)이란?
테이블은 Schema Objects의 하나로 관계형 데이터베이스를 구성하는 기본 데이터 구조로서 행과 열의 구조를 가지며 이 테이블을 이용하여 데이터를 입력, 수정, 삭제, 추출등을 하게된다.
Schema Object란? Schema는 Schema Objects의 모임이며 오라클에서 사용자를 스키마라고 부른다. 스키마 오브젝트에는 TABLES, INDEXES, VIEWS, SEQUENCES, SYNONYM, CLUSTERS, DATABASE LINK, PROCEDURES, FUNCTIONS, PACKAGE등이 해당 된다.
1. 스키마란 무엇이며, 그 유형에는 어떤 것이 있는지 설명해 보라.
- 스키마란 데이터베이스의 구조와 제약 조건에 대한 명세를 기술한 것이다. 그리고 그 유형은 외부 스키마와 개념 스키마와 내무 스키마로 나눌 수 있다.
2. 3단계 디비 구조란 무엇이며 이것은 데이터 독립성과 어떻게 연관되는지 설명해 보라.
- 3단계 디비 구조란 디비를 3단계로 나누어 기술하는 것으로 외부 스키마, 개념 스키마, 내부스키마로 나뉜다. 이 스키마들의 대응 관계를 사상이라 하는데, 이 사상은 응용 프로그램을 변경시키지 않고도 개념 스키마를 변경시킬 수 있으므로 논리적 데이터의 독립성을 제공해 준다.
3. 데이터 정의어를 설명하라
-데이터 정의어는 디비 관리자나 설계자가 주로 사용하는 것으로 디비를 정의하거나 그 정의를 수정할 목적으로 사용하는 언어이다.
4. 디비 관리자의 기능을 설명하라.
- 디비 관리자란 데이터 정의어와 데이터 제어어를 사용하여 디비를 DBMS에 기술해주고 저장된 데이터를 제어할 목적으로 디비에 접근하는 사람이다.
5. 디비, 디비 관리 시스템 ,디비 시스템을 구별해 보라.
디비는 한 조직의 여러 응용 시스템들이 공용할 수 있도록 통합, 저장된 운영 데이터의 집합이고,
디비 관리 시스템은 응용 프로그램과 데이터 중재자 역할을 하는 것으로 모든 응용 프로그램들이 디비를 공용할 수 있게끔 관리해주는 소프트웨어 시스템이다. 따라서 응용 프로그램들이 디비를 이용하기 위해서는 디비 관리 시스템이 필요하다.
그리고 디비 시스템이란 데이터를 디비로 저장하고 관리해서 필요한 정보를 생성하는 컴퓨터 중심의 시스템을 말한다. 디비와 디비관리 시스템은 이 디비 시스템을 구성하는 주요 요소들의 일부가 된다.
즉 디비는 운영 데이터 집합이고, 디비 관리 시스템은 응용 프로그램과 데이터의 중재자 역할이고, 디비 시스템이란 데이터와 디비를 관리하는 시스템이다.
6. 디비 시스템에서 사상과 데이터 독립성의 관계를 설명하라.
-스키마들의 대응 관계를 사상이라 하는데, 이 사상은 응용 프로그램을 변경 시키지 않고도 개념 스키마를 변경시킬 수 있으므로 논리적 데이터의 독립성을 제공해준다.
7. 데이터 조작어를 수행하는 디비 연산을 설명하라.
- 디비 조작어란 사용자가 DBMS로 하여금 원하는 데이터를 처리하게끔 명하는 도구로, 사용자와 DBMS간의 인터페이스를 제공한다, 이 데이터 조작어는 방법에 따라 절차적 데이터 조작어와 비절차적 데이터 조작어로 나뉜다.
8. 데이터 제어에 포함되는 연산들을 설명하라.
- 데이터 제어어는 데이터를 보호하기 위한 데이터 보안, 데이터 무결성, 데이터 회복과 병행수행을 제어를 명세할 수 있는 연산들을 포함한다.
??위에는 그랜트랑 리보크 밖에 안보이는데, security, integrity, recovery, concurrency는 뭐지??
9. 응용 프로그램을 데이터베이스를 접근하는 것과 질의어로 데이터베이스를 접근하는 것을 비교 설명해보라.
-응용 프로그램으로는 범용 호스트 프로그래밍 언어로 프로그램을 작성한다. 그리고 질의어로 접근은 보통 터미널 사용자라 한다.
10. 외부 스키마와 저장 데이터베이스 구조와의 관계를 설명하라.
- 외부 스키마와 저장 디비 구조 사이에는 응용 인터페이스와 저장 인터페이스 즉, 외부/개념 사상과 개념/내부 사상의 두 단계 인터페이스가 포함된다. 따라서 DBMS는 이 인터페이스들을 이용하여 논리적 데이터 독립성과 물리적 데이터 독립성을 보장해 주게 되며, 결과적으로 외부 스키마에 영향을 주지 않고도 저장 디비 구조를 변경할 수 있게 된다.
11. 절차적 조작어와 비절차적 조작어의 장단점을 설명하라.
- 데이터 조작어란 사용자가 DBMS로 하여금 원하는 데이터를 처리하게끔 명세하는 도구로서 사용자와 DBMS간의 인터페이스를 제공한다. 절차적 데이터 조작어는 사용자가 무슨 데이터를 원하며 어떻게 그것을 접근하는지를 명세해야 되는 초급 데이터 언어이다. 이 언어는 프로그램도 알고 디비도 아는 사람만이 사용할 수 있다. 비절차적 데이터 조작어는 사용자가 무슨 데이타를 원하는지만 명세하고 그것을 어떻게 접근할 것인가에 대해서는 명세할 필요가 없는 고급 데이타 언어이다. 이 언어는 디비로 부터 보통 한번에 여러 개의 레코드를 검색해 처리하는 특성을 갖는다, 어떻게 그 데이터를 검색하는지 DBMS가 알아서 처리하므로 독자적으로 사용될 수 있다.
12. DBMS를 구성하는 소프트웨어 모듈, 즉 구성요소의 기능과 이들간의 상호관계를 설명해 보라.
- DBMS의 구성요소는 질의어 처리기 , DML 예비 컴파일러, DDL 컴파일러, DML 컴파일러, 런타임 데이터베이스 처리기, 트랜잭션 관리자, 그리고 저장 데이터 관리자가 있다.
DDL 컴파일러는 DDL로 명세된 스키마 정의를 내부 형태로 변환하여 시스템 카타로그에 저장한는 일을 한다.
질의어 처리기는 터미널을 통해 일반 사용자가 제출한 고급 질의문을 처리한다.
그리고 DML 예비 컴파일러는 호스트 플그래밍 언어로 작성된 응용 프로그램 속에 삽입된 DML 명령문을 파싱하고 컴파일하여 효율적인 목적 코드를 생성한다.
런타임 디비 처리기는 실행 시간에 디비 접근을 관리하며
트랜잭션 관리자는 디비를 접근하는 과정에서 무결성 제약 조건이 만족하는지, 사용자 데이터를 접근할 수 있는 권한을 갖는지 권한 검사를 한다.
저장 데이터 관리자는 디스크에 저장되어 있는 사용자 디비나 시스템 카탈로그 접근을 책임진다.
스프링 기초
검색해서 봐도 모르겠다. 유트브로 좀 하는걸 봐야 감이 올듯.
접질문선착순으로 쿠폰을 발행하는 로직을 설명하고 딱 100장을 발급 하는 방법에 대해서 말해보아라.면접답변 혹은 면접느낌제대로 답변을 하지 못한 것 같습니다. 단순히 redis 클러스터 기반으로 동시접근을 막고 100개의 차감한다고 하였습니다.
디자인 패턴
싱글톤 패턴 Singleton Pattern
[https://jeong-pro.tistory.com/86]
싱글톤 패턴
애플리케이션이 시작될 때 어떤 클래스가 최초 한번만 메모리를 할당하고(Static) 그 메모리에 인스턴스를 만들어 사용하는 디자인패턴.
생성자가 여러 차례 호출되더라도 실제로 생성되는 객체는 하나고 최초 생성 이후에 호출된 생성자는 최초에 생성한 객체를 반환한다. (자바에선 생성자를 private로 선언해서 생성 불가하게 하고 getInstance()로 받아쓰기도 함)
=> 싱글톤 패턴은 단 하나의 인스턴스를 생성해 사용하는 디자인 패턴이다.
(인스턴스가 필요 할 때 똑같은 인스턴스를 만들어 내는 것이 아니라, 동일(기존) 인스턴스를 사용하게함)
싱글톤 패턴을 쓰는 이유
고정된 메모리 영역을 얻으면서 한번의 new로 인스턴스를 사용하기 때문에 메모리 낭비를 방지할 수 있음
또한 싱글톤으로 만들어진 클래스의 인스턴스는 전역 인스턴스이기 때문에 다른 클래스의 인스턴스들이 데이터를 공유하기 쉽다.
DBCP(DataBase Connection Pool)처럼 공통된 객체를 여러개 생성해서 사용해야하는 상황에서 많이 사용.
(쓰레드풀, 캐시, 대화상자, 사용자 설정, 레지스트리 설정, 로그 기록 객체등)
안드로이드 앱 같은 경우 각 액티비티나 클래스별로 주요 클래스들을 일일이 전달하기가 번거롭기 때문에 싱글톤 클래스를 만들어 어디서나 접근하도록 설계하는 것이 편하기 때문...
+ 인스턴스가 절대적으로 한개만 존재하는 것을 보증하고 싶을 경우 사용.
+ 두 번째 이용시부터는 객체 로딩 시간이 현저하게 줄어 성능이 좋아지는 장점!
싱글톤 패턴의 문제점
싱글톤 인스턴스가 너무 많은 일을 하거나 많은 데이터를 공유시킬 경우 다른 클래스의 인스턴스들 간에 결합도가 높아져 "개방-폐쇄 원칙" 을 위배하게 된다. (=객체 지향 설계 원칙에 어긋남)
따라서 수정이 어려워지고 테스트하기 어려워진다.
또한 멀티쓰레드환경에서 동기화처리를 안하면 인스턴스가 두개가 생성된다든지 하는 경우가 발생할 수 있음
개발을 할때 항상 들어온 goto는 쓰면 안돼! 전역 객체는 안 좋은거야! 라는 말 처럼 꼭 필요한 경우아니면 지양해야함. // 적절히 잘 쓰면 아주 좋음, (그게 어렵지)
멀티쓰레드에서 안전한(Thread-safe) 싱글톤 클래스, 인스턴스 만드는 방법은 아직 잘 모르겠다. 왜 다중 스레드에서 해당 클래스를 이용할때 인스턴스가 1개 이상 생성될 수 있다는 거지?? 음 알았다. 아래 프린터 예제를 보면 알 수 있다.
문제점 [https://gmlwjd9405.github.io/2018/07/06/singleton-pattern.html]
다중 스레드에서 Printer 클래스를 이용할 때 인스턴스가 1개 이상 생성되는 경우가 발생할 수 있다.
경합 조건(Race Condition) 을 발생시키는 경우
Printer 인스턴스가 아직 생성되지 않았을 때 스게드 1이 getPrinter 메서드의 if문을 실행해 이미 인스턴스가 생성되었는지 확인한다. 현재 printer 변수는 null인 상태다.
만약 스레드 1이 생성자를 호출해 인스턴스를 만들기 전 스레드 2가 if문을 실행해 printer 변수가 null인지 확인한다. 현재 printer 변수는 null이므로 인스턴스를 생성하는 생성자를 호출하는 코드를 실행하게 된다.
스레드 1도 스레드 2와 마찬가지로 인스턴스를 생성하는 코드를 실행하게 되면 결과적으로 Printer 클래스의 인스턴스가 2개 생성된다.
경합 조건이란?
메모리와 같은 동일한 자원을 2개 이상의 스레드가 이용하려고 경합하는 현상
public class Printer {
// 외부에 제공할 자기 자신의 인스턴스
private static Printer printer = null;
private Printer() { }
// 자기 자신의 인스턴스를 외부에 제공
public static Printer getPrinter(){
if (printer == null) {
// Printer 인스턴스 생성
printer = new Printer();
}
return printer;
}
public void print(String str) {
System.out.println(str);
}
}
https://gmlwjd9405.github.io/2018/07/06/singleton-pattern.html음 그럼 내 이전 과제또한 이런 문제가 있을 수 도 있겠다, 다중 스레드에서 싱글톤 패턴의 문제점 같다.
해결책이 있네
프린터 관리자(Lazy Initialization)는 사실 다중 스레드 애플리케이션이 아닌 경우에는 아무런 문제가 되지 않는다.
다중 스레드 애플리케이션에서 발생하는 문제를 해결하는 방법
정적 변수에 인스턴스를 만들어 바로 초기화하는 방법 (Eager Initialization)
인스턴스를 만드는 메서드에 동기화하는 방법 (Thread-Safe Initialization)
1. 정적 변수에 인스턴스를 만들어 바로 초기화하는 방법. (Eager Initialization)
public class Printer {
// static 변수에 외부에 제공할 자기 자신의 인스턴스를 만들어 초기화
private static Printer printer = new Printer();
private Printer() { }
// 자기 자신의 인스턴스를 외부에 제공
public static Printer getPrinter(){
return printer;
}
public void print(String str) {
System.out.println(str);
}
}
https://gmlwjd9405.github.io/2018/07/06/singleton-pattern.htmlstatic 변수
객체가 생성되기 전 클래스가 메모리에 로딩될 때 만들어져 초기화가 한 번만 실행된다.
프로그램 시작~종료까지 없어지지 않고 메모리에 계속 상주하며 클래스에서 생성된 모든 객체에서 참조할 수 있다.
2. 인스턴스를 만드는 메서드에 동기화하는 방법. (Thread-Safe Initialization)
public class Printer {
// 외부에 제공할 자기 자신의 인스턴스
private static Printer printer = null;
private int counter = 0;
private Printer() { }
// 인스턴스를 만드는 메서드 동기화 (임계 구역)
public synchronized static Printer getPrinter(){
if (printer == null) {
printer = new Printer(); // Printer 인스턴스 생성
}
return printer;
}
public void print(String str) {
// 오직 하나의 스레드만 접근을 허용함 (임계 구역)
// 성능을 위해 필요한 부분만을 임계 구역으로 설정한다.
synchronized(this) {
counter++;
System.out.println(str + counter);
}
}
}
https://gmlwjd9405.github.io/2018/07/06/singleton-pattern.html
인스턴스를 만드는 메서드를 임계 구역으로 변경
다중 스레드 환경에서 동시에 여러 스레드가 getPrinter 메서드를 소유하는 객체에 접근하는 것을 방지한다.
공유 변수에 접근하는 부분을 임계 구역으로 변경
여러 개의 스레드가 하나뿐인 counter 변수 값에 동시에 접근해 갱신하는 것을 방지한다.
getInstance()에 Lock을 하는 방식이라 속도가 느리다.
전자의 방법을 나도 사용한거 같은데, 초기화 시점이 언제인지가 중요할거 같다.
다른 두 방법은
정적 클래스와 , enum 클래스 사용 방법이 있다.
정적 클래스는 정적 메서드로만 이루어진 정적 클래스를 사용하면 싱글턴과 동일한 효과를 얻을 수 있다.
Enum 클래스는
public enum SingletonTest {
INSTANCE;
public static SingletonTest getInstance() {
return INSTANCE;
}
}
https://gmlwjd9405.github.io/2018/07/06/singleton-pattern.htmlThread-safety와 Serialization이 보장된다.
Reflection을 통한 공격에도 안전하다.
따라서 Enum을 이용해서 Singleton을 구현하는 것이 가장 좋은 방법이다.
????이렇다니 이건 진짜 처음 들어봐서 왜그런지 모르겠다. enum 클래스에 대해 더 알아봐야 겠다.
rest api란?
[https://n1tjrgns.tistory.com/185?category=809842]
[https://meetup.toast.com/posts/92]
특정 URI을 통해 사용자가 원하는 정보를 제공하는 방식.
REST 방식으로 제공되는 외부 연결 URI를 REST API.
REST 방식의 서비스 제공이 가능한 것을 Restful 하다고 표현.
2. REST 구성
쉽게 말해 REST API는 다음의 구성으로 이루어져있습니다. 자세한 내용은 밑에서 설명하도록 하겠습니다.
- 자원(RESOURCE) - URI
- 행위(Verb) - HTTP METHOD
- 표현(Representations)
3. REST 의 특징
1) Uniform (유니폼 인터페이스)
Uniform Interface는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일을 말합니다.
2) Stateless (무상태성)
REST는 무상태성 성격을 갖습니다. 다시 말해 작업을 위한 상태정보를 따로 저장하고 관리하지 않습니다. 세션 정보나 쿠키정보를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만을 단순히 처리하면 됩니다. 때문에 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않음으로써 구현이 단순해집니다.
3) Cacheable (캐시 가능)
REST의 가장 큰 특징 중 하나는 HTTP라는 기존 웹표준을 그대로 사용하기 때문에, 웹에서 사용하는 기존 인프라를 그대로 활용이 가능합니다. 따라서 HTTP가 가진 캐싱 기능이 적용 가능합니다. HTTP 프로토콜 표준에서 사용하는 Last-Modified태그나 E-Tag를 이용하면 캐싱 구현이 가능합니다.
4) Self-descriptiveness (자체 표현 구조)
REST의 또 다른 큰 특징 중 하나는 REST API 메시지만 보고도 이를 쉽게 이해 할 수 있는 자체 표현 구조로 되어 있다는 것입니다.
5) Client - Server 구조
REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어들게 됩니다.
6) 계층형 구조
REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 합니다.
4. REST API 디자인 가이드
REST API 설계 시 가장 중요한 항목은 다음의 2가지로 요약할 수 있습니다.
첫 번째, URI는 정보의 자원을 표현해야 한다.
두 번째, 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE)로 표현한다.
다른 것은 다 잊어도 위 내용은 꼭 기억하시길 바랍니다.
HTTP 메소드?
자원 정보는 URI로 표현하고, 자원에 대한 행위는 http 메소드를 통해 표현한다.
[참고]HTTP METHOD의 알맞은 역할
POST, GET, PUT, DELETE 이 4가지의 Method를 가지고 CRUD를 할 수 있습니다.
METHOD역할
| POST | POST를 통해 해당 URI를 요청하면 리소스를 생성합니다. |
| GET | GET를 통해 해당 리소스를 조회합니다. 리소스를 조회하고 해당 도큐먼트에 대한 자세한 정보를 가져온다. |
| PUT | PUT를 통해 해당 리소스를 수정합니다. |
| DELETE | DELETE를 통해 리소스를 삭제합니다. |
리스폰스 코드란?
5. HTTP 응답 상태 코드
마지막으로 응답 상태코드를 간단히 살펴보도록 하겠습니다. 잘 설계된 REST API는 URI만 잘 설계된 것이 아닌 그 리소스에 대한 응답을 잘 내어주는 것까지 포함되어야 합니다. 정확한 응답의 상태코드만으로도 많은 정보를 전달할 수가 있기 때문에 응답의 상태코드 값을 명확히 돌려주는 것은 생각보다 중요한 일이 될 수도 있습니다. 혹시 200이나 4XX관련 특정 코드 정도만 사용하고 있다면 처리 상태에 대한 좀 더 명확한 상태코드 값을 사용할 수 있기를 권장하는 바입니다.
상태코드에 대해서는 몇 가지만 정리하도록 하겠습니다.
상태코드
| 200 | 클라이언트의 요청을 정상적으로 수행함 |
| 201 | 클라이언트가 어떠한 리소스 생성을 요청, 해당 리소스가 성공적으로 생성됨(POST를 통한 리소스 생성 작업 시) |
상태코드
| 400 | 클라이언트의 요청이 부적절 할 경우 사용하는 응답 코드 |
| 401 | 클라이언트가 인증되지 않은 상태에서 보호된 리소스를 요청했을 때 사용하는 응답 코드 |
| (로그인 하지 않은 유저가 로그인 했을 때, 요청 가능한 리소스를 요청했을 때) | |
| 403 | 유저 인증상태와 관계 없이 응답하고 싶지 않은 리소스를 클라이언트가 요청했을 때 사용하는 응답 코드 |
| (403 보다는 400이나 404를 사용할 것을 권고. 403 자체가 리소스가 존재한다는 뜻이기 때문에) | |
| 405 | 클라이언트가 요청한 리소스에서는 사용 불가능한 Method를 이용했을 경우 사용하는 응답 코드 |
상태코드
| 301 | 클라이언트가 요청한 리소스에 대한 URI가 변경 되었을 때 사용하는 응답 코드 |
| (응답 시 Location header에 변경된 URI를 적어 줘야 합니다.) | |
| 500 | 서버에 문제가 있을 경우 사용하는 응답 코드 |
URL VS URL
[https://blog.lael.be/post/61]
URL은 Uniform Resource Locator
URI는 Uniform Resource Identifier
이다.
그냥 단어의 뜻대로 해석하자면 예전에는 URL이 가리키는게 자원(파일) 위치 였는데
요즘은 Rewrite 등의 Apache , IIS, Tomcat 핸들러 때문에 자원 식별자 이라고 부른다.
즉 요즘에는 웹사이트 주소가 (http://test.com/company/location) 라고 했을 때
요청하는 주소가 파일이라기 보다는 구분자로 보는 것이다.
실제로 해당 웹사이트의 company/location 라는 파일은 없다. (아마도 company 클래스의 location 메소드를 호출할 것이다. 이렇게 구분자(Identifier)로 보는 것이 URI 이다.)
요약하자면 URL 은 다음과 같다.
http://test.com/work/sample.pdf
test.com 서버에서 work 폴더안의 sample.pdf 를 요청하는 URL.
URI(통합 자원 식별자) 의 예는 다음과 같다.
1) rewrite 기술을 사용하여 만든 의미있는 식별자
http://test.com/company/location
2) REST 서비스 (url로 실행되는 서비스)
3) Web-oriented architecture (웹 기반의 구조문법)
kakaotalk://sendmsg?text=hello! (이 uri는 kakaotalk 프로토콜을 해석할 수 있는 프로그램이 핸들링한다. 해당프로그램은 sendmsg 라는 식별자를 해석하고 동작한다.)
facebookmsg://like?url=mysite.com (이 uri는 facebookmsg 프로토콜을 해석할 수 있는 프로그램이 핸들링한다. 해당프로그램은 like 라는 식별자를 해석하고 동작한다.)
이해하기 쉽게 동물로 표현하자면.
URI(동물) 가 좀더 상위 개념이라서 URL(강아지), URN(다람쥐) 등의 하위 개념을 포함한다.
URI 와 URL 이 아예 다른게 아니라 포함관계라서
모든 URL 는 URI 이다. 가 성립힌다. (TRUE)
URI = URL + URN
#내용추가 . 13.07.15
위키백과 보고 조금 더 추가합니다.
요즘 URI를 쓰는이유가 URN 때문은 아닐 것이라 생각하지만 그래도 알아두면 좋을것 같아서 관련내용을 작성해봅니다.
URI 가 URL과 URN을 포함하는데 URN은 Uniform Resource Name 의 약자입니다.
URN 문법은
urn:isbn:0451450523
urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66
이런건데 isbn이나 uuid를 해석가능한 프로그램이 있어야 동작합니다.
예를 들어서 저만의 urn을 만들어보자면
urn:laelbe:blog-61
을 쓰고 laelbe 해석 프로그램을 만든다음에 https://blog.lael.be/post/61 으로 매칭하도록 짤수 있겠군요.
urn 개념은 이해 못했습니다.