2022-02-23(수)

09-JDBC프로그래밍 / 16 페이지

ER-Diagram

테이블과 테이블 사이의 관계를 표현한 것

ERD (Entity Relationship Diagram)

Entity = Table

Entity의 Relationship 관계

테이블과 테이블 사이의 관계를 그림으로 표현한 것

'객체'가 클래스를 가리키는 건지 인스턴스를 가리키는 건지는
이야기의 흐름에 맞춰서 이해해야 됨

테이블과 테이블의 관계를 그림으로 Diagram

작성자 테이블 (PK: 이메일)
게시글 테이블 (FK: 작성자)
일대다 관계

하나의 작성자는 여러 게시글을 작성한다.
작성자가 게시글을 작성 안 할 수도 있음. 0개 이상 작성. 세 다리로 그린다.
게시글에는 작성자가 반드시 있어야 함.

게시글이 작성자를 참조
참조 당하는 쪽이 부모 테이블 (작성자 테이블)

artificial key (인공키) = surrogate key (대리키)

게시글 테이블 (PK: 게시글 번호) ← artificial key (인공키)
첨부파일 테이블 (PK: 파일 번호) ← artificial key (인공키)
FK: 게시글

한 개의 게시글이 0개 이상의 첨부파일을 가진다. 다리가 3개.
한 개의 첨부파일을 여러 게시글이 소유할 수 없다.
첨부파일 입장에서는 오로지 한 개의 게시글과 관계를 가진다.

PK를 갖고 있는 게 부모 테이블
그 PK를 참조하는 게 자식 테이블

테이블과 테이블 사이에 어떤 관계가 있는지 그림만 보면 이해할 수 있다

테이블 사이의 관계를 그림으로 알 수 있다
이게 ERD가 존재하는 이유

여러 테이블로 분할되다 보니까 관계를 표현해야 되는데

git\eomcs-docs\sql\Exam04.sql

rdt : registered date

filepath1 varchar(255) : 첨부파일을 하드디스크에 따로 저장해놓고, 하드디스크에 저장된 경로만 데이터베이스에 넣겠다는 거

옛날에는 파일도 데이터베이스에 저장했었음
게시글 테이블을 만들 때 번호, 제목, 내용, 등록일, 첨부파일
첨부파일 타입을 BLOB(Binary Large Object) ← 최대 2GB까지 저장할 수 있음
예전에는 첨부파일 저장하는 컬럼의 타입을 BLOB(2GB)으로 함

App → DBMS → OS → HDD
하드디스크를 제어하는 게 운영체제(OS)
운영체제 앞단에 DBMS가 있음
DBMS를 이용하는 게 Application

App ---> DBMS ---> OS ---> HDD

Application이 첨부파일을 DBMS에 주면
DBMS는 운영체제를 통해서 HDD에 파일을 저장한다
DBMS가 다이렉트로 저장할 방법은 없다
HDD에 액세스 하려면 운영체제에서 제공해주는 function을 호출해야만 하드웨어
H/W(마이크, 사운드 카드, RAM, HDD, CD-ROM, USB, VGA 카드, 랜카드)에 접근할 수 있다.
운영체제 없이 다이렉트로 접근할 방법은 없다.

유일하게 운영체제를 경유하지 않고 VGA 카드에 바로 접근해서 좀 더 빠르게 VGA 카드에 접근해서 그래픽을 처리하는 거
그래서 Microsoft가 만든 게 DirectX 라이브러리
결국 DirectX도 운영체제의 일부
운영체제를 경유하지 않고 실행한다는 건 좀 이상함
물론 이걸 더 세밀하게 따지면
확대
하드웨어가 다르면 하드웨어를 다루는 방법이 다름
바이트 데이터를 출력하는 건데
결국 데이터를 출력하는 건데
프로그램 입장에서는 데이터를 출력하는 거
장비마다 출력하는 방법이 다르면 프로그래밍에 일관성이 없어서 피곤함
그래서 계층을 하나 더 둔다

마우스를 제어하는 프로그램은 마우스 제조 업체에서 짠다
API 제공
키보드 제어 API ← 키보드 제어 회사에서 만듦
같은 회사라도 모델마다 다름
CPU가 달라지면 기계어가 달라지기 때문에
하드웨어를 만드는 회사는 그 하드웨어를 제어할 수 있도록 응용 프로그램 개발
우리가 제공해주는 function을 호출해
보통 아직까지 C function으로 제공한다
소프트웨어라고 안 부르고 API 라고 한다. Application을 프로그래밍 할 때 사용하는 도구.
프로그램에서 프린터를 제어. API 라고 한다.
사운드 카드 제어 API
VGA 제어 API
LAN 카드 제어 API
⇒ H/W 제어 API
H/W 제어 API = Driver

미리 규칙을 정해놓음
Device Driver (*.dll)
윈도우에서 정한 Device Driver 도구를 이용해서 만든다

사용자가 프린터를 교체하면 프로그램도 다 고쳐야 됨
그래서 운영체제는 중간층을 하나 더 만든다
H/W를 직접적으로 dll에 접근하지 말고 간접적으로 접근하도록
추상층을 앞에 둔다 (HAL층)
운영체제가 HAL을 경유하고 HAL이 실제 드라이버를 호출하는 방식

층이 많다는 것은 호출, 호출, ... 속도가 느림
그래서 DirectX
게임할 때는 그래픽 카드를 직접 액세스해야 하기 때문에
VGA 카드에 직접 액세스할 수 있도록 DirectX 라는 규칙을 만들어놓고
제조사에서 DirectX 드라이버 제공
DirectX 드라이버에 있는 function을 호출해서 제어
그래서 속도를 높인다

이 개념이 나중에 JDBC 드라이버에도 그대로 적용된다

HDD에서 파일을 읽어올 때도 App → DBMS → OS → HDD
처음에는 첨부파일을 DB에 저장하는 방식으로 했는데 이렇게 하면 속도가 엄청 떨어짐
그래서 그렇게 안 하고

App ---> OS ---> HDD
일반 data는 DBMS를 경유하지만
파일은 직접 OS에서 파일을 읽고 쓰는 방식으로

✓ 일반 데이터는 DBMS를 통해 저장, 변경, 삭제
✓ 파일은 OS File API를 통해 직접 읽고 쓴다.
⇒ 이런 이유로 DB에는 첨부파일의 경로만 저장한다.

첨부파일을 저장할 때 왜 파일을 저장하지 않고 파일 경로를 저장하느냐
⇒ DBMS를 통해서 파일을 읽고 쓰게 되면 속도가 느리다

파일을 읽고 쓸 때는 파일 입출력 API 통해서 운영체제를 통해서 읽고 쓰고
단, 파일의 경로만 DB에 보관한다.

왜 첨부파일을 데이터베이스에 저장하지 않습니까?
⇒ 효율성 때문에. 속도가 느림.
왜 속도가 느립니까?
결국 파일로 저장하려면 운영체제를 통해서 저장해야 됨.
DBMS도 다이렉트로 HDD에 저장할 수 없다.
운영체제에서 제공해주는 File API를 사용해서 저장한다
그럴 바에는 App이 파일을 다룰 때는 운영체제의 파일입출력을 통해서 직접 읽고 쓰고
다만 첨부파일을 관리하는 측면에서 파일 이름만 DBMS에 저장하는 방법을 쓰자는 거

DBMS는 OS 위에 있다
OS 위에 설치
OS 아래에 H/W가 있는 거
HDD, Keyboard, LAN 카드, ...

스프링 부트인 경우에는 둘 다 remote

Local(PC) : Web Browser
Remote(서버) : SpringBoot
Remote(서버) : DBMS

S/W, H/W 퉁쳐서
시스템 아키텍처
System Architecture

filepath1 varchar(255) ← 파일 경로만 저장하기 때문에 최대 255자

2교시

컬럼 자체가 존재하기 때문에 메모리는 무조건 차지함

fno ← artificial key (인공키)

테이블에는 무조건 Primary Key가 있어야 한다.

100번 게시글은 없음
결함이 발생
데이터가 온전하지 않다
데이터 신뢰성이 무너짐

결함이 발생하지 않게 만드는 문법이 필요
'무결성 제약 조건'이라는 문법이 등장

이것들도 다 제약 조건
int
not null
varchar(255)

유효하지 않은 게시글 번호...

FK 제약 조건이 없으면 첨부파일 데이터를 입력할 때 존재하지 않는 게시물 번호가 들어 갈 수 있다. 그러면 첨부파일 데이터는 무효한 데이터가 된다.

해결책?
‐ 다른 데이터를 참조하는 경우 해당 데이터의 존재 유무를 검사하도록 강제한다.
‐ 다른 테이터에 의해 참조되는지 여부를 검사하도록 강제한다.
어 이거 삭제 못 해. 1번 게시글 참조하고 있어.

게시글에 존재하지 않는 데이터를 참조할 수 없다.

앞이나 뒤에 fk 적어서 라벨을 붙인다
라벨명을 생략하면 임의의 라벨명이 붙는다

alter table test2
add constraint test2_fk foreign key (bno) references test1(no);

MariaDB [studydb]> alter table test2
    -> add constraint test2_fk foreign key (bno) references test1(no);
ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails (`studydb`.`#sql-alter-6d4-5`, CONSTRAINT `test2_fk` FOREIGN KEY (`bno`) REFERENCES `test1` (`no`))

MariaDB [studydb]> delete from test2 where bno=1;

현재 들어 있는 데이터가 FK를 거는 데 문제가 없으면 잘 된다.

MariaDB [studydb]> delete from test1 where no=5;
ERROR 1451 (23000): Cannot delete or update a parent row: a foreign key constraint fails (`studydb`.`test2`, CONSTRAINT `test2_fk` FOREIGN KEY (`bno`) REFERENCES `test1` (`no`))

parent row

참조하는 데이터가 없을 때는 삭제 잘 됨

존재하는 데이터가 아니면 에러남

이게 바로 제약 조건이 존재하는 이유
결함이 발생하지 않도록
여러 테이블에 분산해서 저장하다 보면 관계가 생길 수 밖에 없음
분산 저장해야 데이터가 중복되지 않는다
데이터가 분산되는 순간 관계가 생길 수 밖에 없다