데이터를 어딘가에 보관해서 처리해야 됨
파일에 보관
파일에서 조회
파일은 HDD
App은 RAM에서 실행
RAM ← 각각의 비트에 전기가 있냐 없냐로 데이터를 표시
HDD ← 자석가루. 반도체 (전기적 신호)
USB 전기가 바깥으로 누수가 안 되게 전기를 가둬놓는다
가둬놓는 데 한계가 있다
전기가 조금씩 누수되면서 최종적으로 데이터가 날아간다
HDD보다 flash에 저장하면 더 빨리 날라감
HDD에 옮겨놔야 됨
ram vs flash memory
ArrayList에 add, get
ArrayList (RAM)
파일 (HDD)
ArrayList를 파일에 저장 (무식한 방법)
다른 pc의 파일을 조회할 수 없다
데이터 공유가 안 됨
다른 컴퓨터에 HDD를 공유해서 거기서 읽고 쓴다.
같이 접근해서 저장하고 쓸 수 있다
데이터 공유가 가능하다
누구는 데이터를 읽기만 가능해야 됨
인사팀에서는 직원 정보를 등록, 변경, 삭제할 수 있고
다른 부서에서는 직원 정보를 조회해야지 변경하면 안 됨
파일에 접근할 때 접근을 제어할 필요가 있음
사용자에 따라서 접근을 제어할 필요가 있음
이 사람이 유효한 사용자인지 검사 → 인증 (authentication)
권한(authorization)
인증과 권한을 퉁쳐서 Auth 라고 부른다.
사용자에 따라서 / App에 따라서 (어느 프로그램이냐에 따라서) 접근을 제어해야 한다
두 사람이 동시에 하나의 파일을 쓰려고 할 때 충돌 문제 발생
동시 접근 문제
한 사람이 파일 쓰는 중이면 다른 사람은 기다려야 됨
동시 접근 문제 처리
같은 HDD 사용
전문적인 프로그램이 다루게 하자
DBMS 등장
DBMS <---I/O---> 파일
App ---요청--> DBMS
DBMS가 하는 일 : 인증/권한 검사, 동시 접근 제어, 무결성 제공
우리가 직접 컨트롤 하는 것보다 DBMS를 사용하는 게 나음
DBMS를 사용하려면 명령을 보내야 됨
우리를 대신해서 파일에 데이터를 읽고 쓰는 일을 함
SQL 등장
구조화된 쿼리 언어(Structured Query Language)
SQL : DBMS에 공통으로 사용할 수 있는 명령문 작성 문법
SQL + DBMS 전용 기능을 활용할 수 있는 문법
SQL(90%) + α(10%)
데이터 타입, function
Oracle ----migration----> MS-SQL
DBMS Client와 API
DBMS Client가 App을 쓰고 싶음
DBMS Server에 연결하고 싶음
프로그램이 SQL 명령을 서버에 보내고 싶음
그리고 그 App을 사람이 쓴다
문제
DBMS Client 프로그램은 사람이 쓰라고 만든 거지 App이 쓰라고 만든 게 아님
우리가 원하는 거
사용자가 프로그램을 쓰고
프로그램이 DBMS Client를 이용해서
그게 바로 API(Application Programming Interface)
사용자 ---> App ---> DBMS API(클래스, 메서드) ---> DBMS Sever ---> 파일
EC2에 있는 거 사용하려면 Client만 설피하면 됨
App이 API를 call하면 리턴 받는다 (DB 프로그래밍)
오늘부터 call 하는 거 배울 거
Mybatis가 SQL Mapper
Native API = Vendor API
DBMS 제조사에서 제공하는 API
vendor (제조사)
DBMS API
DBMS 전용 프로토콜을 사용해서 통신을 해야 된다
App ------요청------> DBMS
통신개발자가 DBMS 전용 프로토콜에 맞춰서
통신 프로그램을 짜야 한다.
-> 매우 번거롭고 복잡해진다.
네트워크 통신을 하려면 전용 프로토콜을 알아야 됨
문제점
매우 번거롭고 복잡해진다
DBMS 제조사에서 기술 유출 방지를 위해 프로토콜 공개 안 함
프로토콜을 공개하게 되면 해킹의 가능성이 높아진다.
DBMS가 파일의 입출력을 대신 해준다면서
App에서 DBMS 서버에 직접 접근하는 방법 -> 현재 불가능
DBMS 서버에 간접적으로 접근하는 방법
DBMS가 우리를 대신해서 파일에 데이터를 넣고 꺼낸다(I/O)
API를 제공
API가 우리랑 대신해서 요청함
우리의 APP은 API 메서드를 call
그 결과를 return 받는다
API
• DBMS에서 제공
• DBMS와의 통신을 대행
App
• DBMS 통신 프로토콜을 알 필요가 없다
• 통신 프로래밍이 필요 없다.
App(프로그램)에서는 DBMS Client를 사용할 수 없다
대신 프로그램이 사용할 수 있는 DBMS API를 제공
=> DB 프로그래밍
Native API = Vendor API
Native API <- C/C++로 되어있다
Windows : *.dll, *.lib
Unix : *.so, *.lib
Oracle API
MS-SQL API
MySQL API
제공하는 함수를 call 호출하고 결과를 return 받는다
문제점이 있음
① native API는 DBMS마다 API 규격이 다르다
API 규격이 다르다 -> 클래스나 메서드가 다르다 (메서드명, 파라미터, 리턴값이 다르다)
-> DBMS마다 따로 프로그래밍을 해야 한다
Oracle에서는 m1이라는 메서드를 호출해야 되고
MS-SQL m2 메서드 호출
MySQL m3 메서드 호출
ODBC API와 Driver
ODBC(Open Database Connectivity)
DBMS마다 API가 달라서 프로그래밍의 일관성이 없는 문제를 해결하기 위해서
=> API의 규격을 통일
API의 규격 : 메서드 사용법(메서드명, 파라미터, 리턴값)
=> ODBC API 정의
=> DBMS 제조사는 ODBC API 규격에 맞춰 클래스와 메서드를 제작
⭐️ ODBC Driver : ODBC 규격에 맞춰 작성한 구현체(클래스 및 메서드)
ODBC API 규격에 맞춰 메서드를 구현 -> Oracle ODBC Driver
Oracle ODBC Driver -> Oracle API -> Oracle DBMS
App -> Oracle ODBC Driver -> Oracle API -> Oracle DBMS
App -----> Other ODBC Driver -----> Other DBMS
App <- API가 같기 때문에 DBMS마다 따로 프로그래밍 할 필요 없다
프로그램을 한 번만 짜면 된다
ODBC Driver
ODBC Driver 두 종류임
제조사 마음임
MySQL은 둘 다
문서를 봐야 됨
어떤 방식으로 동작하는 ODBC Driver를 만들지는 제조사 마음!
① Vendor API 호출 -> 프로그래밍의 일관성을 위해 껍데기로서 역할
ODBC Driver는 Vendor API를 호출하고
Vendor API가 DBMS에 요청하고 응답한다
② 직접 DBMS와 통신
ODBC Driver ----요청---> DBMS
ODBC Driver를 사용하면 개발자 입장에서는
메서드 사용법이 같기 때문에 DBMS마다 프로그램을 짤 필요가 없다
ODBC는 마이크로소프트가 만듦
https://ko.wikipedia.org/wiki/ODBC
Connectivity : 연결자
ODBC(Open DataBase Connectivity)는 마이크로소프트가 만든,
데이터베이스에 접근하기 위한 소프트웨어의 표준 규격 (메서드 규격)
Oracle ODBC Driver (ODBC API) ---> Oracle API (Vendor API) ---> Oracle DBMS
단점
Vendor API는 다이렉트로 요청하고 응답하는데
ODBC Driver는 한다리 거쳐서 실행속도가 느리다
둘 다 C, C++ (운영체제의 기계어)
자바에서 쓸 수 없다는 게 문제
JDBC API와 Driver - Type1
JDBC Driver : JDBC API 규격에 따라 구현한 클래스와 메서드
Type1 드라이버 (JRE에 기본 포함됨)
JRE : JVM, 라이브러리
‐ ODBC Driver를 사용 (PC에 설치되어 있어야 함)
ODBC Driver 사용: OS의 기계어 => OS Native 메서드 => OS에 의존
100% java가 아니다
C/C++
PC에 ODBC Driver, Vendor API 설치해야 됨
JDBC API와 Driver - Type2
Java App ---> JDBC Driver ---> Vendor API
ODBC Driver를 경유하지 않고 native API를 다이렉트로 call한다.
Type2 Driver
‐ 별도 다운로드 필요
‐ Vendor API(Native API) 호출
Native API가 없는 경우 Type2 Driver를 사용할 수 없다.
(PC에 Vendor API 설치되어 있어야 함)
🔹 Native API
① DBMS 제조사에서 제공하는 C/C++ API <- JDBC API에서 말하는 의미
② OS에 맞춰 기계어로 컴파일된 API <- 프로그래밍 세계에서 일반적으로 말하는 의미
문맥에 따라서 해석하기
JDBC API와 Driver - Type3
중계서버 돈 주고 사야 됨
DBMS 중계서버 (middleware)
middle software => middleware
Java App. -> 중계서버용 JDBC Driver -> DBMS 중계서버 (middleware) -> Oracle DBMS
Type3 드라이버
‐ 별도 다운로드 필요
‐ 중계서버용 Driver만 있으면 된다 -> DBMS에 비종속
-> DBMS별로 드라이버를 다운로드할 필요가 없다
왜? 중계서버에서 처리한다
-> 중계서버 구입 비용이 추가된다
프로그래밍은 편해졌지만 중계서버 구입 비용이 추가됨
‐ 속도가 느리다
보통 중계 서버는 컴퓨터가 다름
PC <------> 서버1(중계서버) <------> 서버2(DBMS)
JDBC API와 Driver - Type4
DBMS 서버와 다이렉트로 통신
Type4 드라이버
‐ 별도 다운로드 필요
‐ DBMS 서버와 직접 통신
‐ 실무에서 주로 사용
‐ 속도가 빠르다
DBMS에 따라서 바뀔 필요는 없음
메서드 사용법이 같다
ODBC Driver가 무조건 Vendor API를 쓰는 건 아니다
구동 방식이 이렇게 네 종류
JDBC Driver의 구동 방식
메서드 호출 규칙은 같음
주요 JDBC API
JDBC API
⭐️ java.sql.* 패키지
Driver 라는 인터페이스가 있음
Connection 이라는 인터페이스가 있음
Statement 라는 인터페이스가 있음
ResultSet 이라는 인터페이스가 있음
🔹 <<interface>> Driver
JDBC 드라이버 정보를 다루는 메서드가 정의되어 있음
Connction 객체를 준비하는 메서드가 들어 있음
org.mariadb.jdbc.Driver.class
드라이버 이름이 뭔지, 버전은 뭔자
🔹 <<interface>> Connection
DBMS 연결과 관련된 일을 수행하는 메서드가 정의되어 있다
Statement 객체를 준비하는 메서드가 들어 있다
org.mariadb.jdbc.Connection.class
🔹 <<interface>> Statement
DBMS에 SQL을 전달하는 일을 수행하는 메서드가 들어 있다
ResultSet 객체를 준비하는 메서드가 들어 있다
org.mariadb.jdbc.Statement.class
🔹 <<interface>> ResultSet
DBMS에서 select 실행결과를 가져오는 일을 수행
org.mariadb.jdbc.result.CompleteResult.class
이걸 구현한 클래스가 있겠지
얘가 얘를 리턴한다
얘가 얘를 생성하고
DBMS에서 java.sql.* 패키지의 인터페이스를 구현한 클래스를 제공
보통 *.jar 파일에 패킹해서 제공
이게 바로 JDBC Driver
실제 동작하는 건 JDBC Driver (구현체)
JDBC 드라이버 다운로드
https://search.maven.org/artifact/org.mariadb.jdbc/mariadb-java-client/3.0.3/jar
implementation 'org.mariadb.jdbc:mariadb-java-client:3.0.3'
② Driver 구현체 생성 및 등록
java.sql.Driver 인터페이스로 구현한 클래스의 인스턴스를 생성
mariadb jdbc documentation
https://mariadb.com/kb/en/about-mariadb-connector-j/
Type마다 추가적으로 다운로드 받아야 되는 게 다름
mariadb odbc driver 검색
https://mariadb.com/kb/en/mariadb-connector-odbc/
https://mariadb.com/kb/en/about-mariadb-connector-j/#using-the-driver
ODBC API 규격을 정의한 거
ODBC Driver 규격에 맞춰서 실제 구현한 거
인터페이스로 호출 규칙을 정의하고 그 규칙대로 구현
엑셀 파일 : ODBC Type1 Driver
자바 패키지명이 javax로 시작하면 확장 기능
기업용 프로그램을 위한 기능들이 들어 있다
https://docs.oracle.com/en/java/javase/11/docs/api/java.sql/java/sql/Driver.html
https://docs.oracle.com/en/java/javase/11/docs/api/java.sql/java/sql/Connection.html
https://docs.oracle.com/en/java/javase/11/docs/api/java.sql/java/sql/Statement.html
DBMS 서버에 전달
executeQuery : select문을 서버에 전달
② Driver 구현체 생성 및 등록
JDBC 드라이버 관리자에 등록
com.eomcs.jdbc.ex1.Exam0110.java
DriverManager 클래스
③ DBMS에 연결
DriverManager에게 연결 요청을 해야 한다
Driver 구현체의 인스턴스를 생성한다.
DriverManager.registerDriver(mariadbDriver);
추가한 경우에는 gradle eclipse
java.sql.Driver oracleDriver = new oracle.jdbc.OracleDriver();
항상 문서 보기
jdbc URL
com.eomcs.jdbc.ex1.Exam0111.java
com.eomcs.jdbc.ex1.Exam0120.java
static 블록에서 자동으로 처리
com.eomcs.jdbc.ex1.Exam0130.java
fully-qualified class name : 패키지명을 포함한 클래스명
쓸데없이 인스턴스 안 만들어도 클래스가 로딩될 때 static 블록이 실행
forName() : 클래스를 로딩하는 메서드
클래스는 딱 한 번 로딩되니까
소스코드에 데이터베이스 클래스 이름을 적지 말고
소스코드를 수정해야 됨 -> 다시 컴파일 해야 됨 -> 다시 빌드 (jar 파일 다시 만들어야 됨)
jdbc-driver.properties - java-lang
.properties 파일과 java.util.Properties 클래스
외부 파일에 저장해두면 소스파일을 변경할 필요가 없다
.properties 파일
key/value 형식의 환경변수를 간단하게 저장하는 파일 포맷
예) key=value (중간에 공백 불가)
예) name=aaa
age=20 (한 줄에 한 개의 key/value여야 한다)
예) jdbc.url = jdbc:mariadb://
key 이름을 작성할 때 OGNL 방식을 사용하면 값을 쉽게 구분할 수 있다.
OGNL(Object Graph Navigation Language)
=> 객체명.프로퍼티명.프로퍼티명.프로퍼티명
java.util.Properties는 .properties 파일을 로딩할 수 있다.
getProperties()
메모리에 로딩됨
이름 키를 가진 값을 리턴해다오
위의 방식을 사용하면 Driver 구현체를 소스 파일에 직접 명시할 필요가 없다
경로가 기본적으로 등록되어 있다
jdbc.driver는 등록되어 있지 않다
드라이버가 자동 로딩되는 걸 확인해보자
로딩되는지 알 길이 없음
// DriverManager에 자동 등록된 것을 확인해보자!
// =>DriverManager의 getDriver()를 호출하여 java.sql.Driver 구현체를 달라고 요구할 때
// 1) 등록된 드라이버 중에서 jdbcUrl에 지정된 드라이버가 있는지 찾아본다.
// 2) 없으면 이 클래스를 로딩한다. 약속이 되어 있다.
자동 로딩
등록된 java.sql.Driver 구현체 중에서
