관계형 데이터베이스와 테이블, DML
관계형 DB가 왜 표준이 됐는지, 그리고 테이블을 만들고 데이터를 채우는 기본기를 정리한다.
관계형 데이터베이스, 파일 관리의 한계를 넘어서다
데이터 양이 많아지고 여러 사람이 같은 데이터를 동시에 다루기 시작하면, 엑셀 같은 개인용 소프트웨어로는 한계에 부딪힌다. 파일 하나를 여러 사용자가 동시에 조회할 수는 있지만, 동시에 입력·수정·삭제하는 것은 불가능하기 때문이다. 이를 해결하려고 파일을 여러 개 복사해서 쓰면, 이번엔 원본과 사본 사이에 데이터 불일치가 생긴다. 이런 문제를 해결하기 위해 등장한 것이 DBMS(Database Management System)다.
1970년 E.F. Codd 박사의 논문에서 관계형 데이터베이스가 처음 소개된 이후, IBM의 SQL 개발과 Oracle의 상용화를 거치며 관계형 DB는 기존 파일시스템과 계층형·망형 DB를 대체하는 주력 구조가 되었다. 관계형 DB는 정규화를 통해 이상 현상(Anomaly)을 제거하고 중복을 피하며, 동시성 제어로 여러 사용자가 동시에 데이터를 공유하게 해준다. 여기에 메타데이터 관리, 보안, 제약조건을 통한 무결성 보장, 장애 복구 기능까지 포함하고 있다.
SQL(Structured Query Language)은 이 관계형 데이터베이스를 유일하게 다룰 수 있는 언어다. 관계형 DB가 수학의 집합 논리에 기반하기 때문에, SQL도 데이터를 집합으로 다룬다. "포지션이 미드필더인 선수를 검색한다"는 요청은 선수라는 큰 집합에서 조건을 만족하는 부분집합을 추출하는 작업으로 이해할 수 있다.
DDL과 DML은 처리 방식이 다르다. DDL 명령어는 테이블에 직접 영향을 미쳐 입력하는 순간 자동으로 완료(AUTO COMMIT)된다. 반면 DML 명령어는 조작할 테이블을 메모리 버퍼에 올려놓고 작업하기 때문에, 실제 테이블에 반영되려면 COMMIT을 실행해야 실시간으로 반영된 것이 된다. 이 차이는 다음 편에서 다룰 트랜잭션의 핵심이다.
제약조건, 데이터의 문지기
제약조건(CONSTRAINT)은 원하는 조건의 데이터만 유지하기 위한, 즉 데이터 무결성을 지키기 위한 장치다. 테이블을 생성할 때 제약조건을 꼭 넣지 않아도 되지만, 나중에 데이터가 이미 쌓인 상태에서 ALTER TABLE로 추가·수정하려면 처리 과정이 훨씬 까다로워진다. 그래서 테이블 생성 시점부터 충분히 검토하는 편이 낫다.
CREATE TABLE PLAYER (
PLAYER_ID CHAR(7) NOT NULL,
PLAYER_NAME VARCHAR(20) NOT NULL,
TEAM_ID CHAR(3) NOT NULL,
HEIGHT SMALLINT,
WEIGHT SMALLINT,
CONSTRAINT PLAYER_PK PRIMARY KEY (PLAYER_ID),
CONSTRAINT PLAYER_FK FOREIGN KEY (TEAM_ID) REFERENCES TEAM(TEAM_ID)
);
NULL은 아직 정의되지 않은 값이다. 0이나 공백과는 전혀 다르다. 0은 숫자이고 공백은 문자 하나지만, NULL은 값 자체가 없는 상태를 뜻한다. NOT NULL이나 PRIMARY KEY로 정의되지 않은 칼럼은 모두 NULL을 허용한다.
DML, 데이터와 대화하는 문장
SELECT는 테이블 내용은 건드리지 않고 조회만 하는 문장이다. INSERT, UPDATE, DELETE는 테이블 안의 데이터를 실제로 조작한다.
INSERT
INSERT INTO PLAYER (PLAYER_ID, TEAM_ID, PLAYER_NAME, POSITION, HEIGHT, WEIGHT, BACK_NO)
VALUES ('1997035', 'K02', '이운재', 'GK', 182, 82, 1);
UPDATE
UPDATE는 WHERE절 없이 실행하면 테이블 전체 데이터가 한 번에 바뀐다는 점을 늘 염두에 둬야 한다.
UPDATE PLAYER SET POSITION = 'MF' WHERE PLAYER_ID = '1997035';
DELETE, TRUNCATE 중 무엇을 쓸까
테이블의 전체 데이터를 지울 때는 DELETE보다 TRUNCATE 쪽이 시스템 부하가 적다. DELETE는 삭제 내역을 로그로 남기지만, TRUNCATE는 로그를 남기지 않기 때문에 ROLLBACK이 불가능하다는 점을 주의해야 한다. 단, SQL Server에서는 사용자가 트랜잭션을 직접 시작한 뒤 TRUNCATE로 지웠더라도, 이후 ROLLBACK 문으로 되돌릴 수 있다.
| 구분 | 로그 | ROLLBACK | 용도 |
|---|---|---|---|
| DELETE FROM TABLE | 남긴다 | 가능 | 일부 또는 전체 삭제, 되돌릴 여지가 필요할 때 |
| TRUNCATE TABLE | 남기지 않는다 | 원칙적으로 불가 | 전체 삭제이면서 성능이 중요할 때 |
SELECT의 기본 골격
SELECT [ALL/DISTINCT] 칼럼명, 칼럼명 ... FROM 테이블명 WHERE 조건식;
ALL은 중복 데이터를 포함해 전부 출력하는 기본값이고, DISTINCT는 중복된 데이터를 한 건으로 묶어 출력한다. 조회하려는 칼럼을 전부 보고 싶다면 와일드카드 *를 쓴다.
'기초 CS > 데이터베이스' 카테고리의 다른 글
| 03. 정규화 / 반정규화 (0) | 2026.08.03 |
|---|---|
| 02. 속성, 관계, 식별자 (1) | 2026.08.02 |
| 01. 데이터 모델링과 엔티티 (0) | 2026.08.01 |