개념 사전 · 개념

관계형 데이터베이스와 DBMS

RDBMS · 관계형 DB · 관계형 데이터베이스

는 행과 열로 표현한 자료를 키·제약·관계 연산으로 조직하는 저장 방식이다. DBMS는 그 구조를 관리하면서 처리·접근 통제·동시성·로그와 복구를 제공하는 프로그램 계층이다.

밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.

01무엇이고, 어떤 일을 하나

  • 테이블·키·으로 자료의 구조와 불변 조건을 표현한다.
  • 질의 계획과 저장 엔진을 통해 필요한 자료를 조회·변경한다.
  • 과 복구 기록으로 동시 작업과 장애 뒤 상태를 관리한다.

02어떤 순서로 동작하나

  1. 연결과 권한

    클라이언트를 인증하고 사용할 데이터베이스·객체의 권한을 적용한다.

  2. 문장 해석

    을 파싱하고 테이블·열·자료형을 해석한다.

  3. 계획과 실행

    통계·를 바탕으로 실행 계획을 선택하고 캐시·페이지·잠금 또는 버전 정보를 이용해 처리한다.

  4. 결과·확정

    조회 결과 또는 변경 행 수를 반환하고 의 커밋·롤백 규칙에 따라 변경을 확정하거나 취소한다.

03먼저 알아둘 용어와 구성요소

테이블의 행은 개별 자료, 열은 이름과 자료형을 가진 속성이다.
기본키는 행을 유일하게 식별한다. 외래키는 같은 테이블 또는 다른 테이블의 참조 가능한 키와 연결되어 참조 무결성을 검사한다. 같은 테이블에서 부모 행을 가리키는 자기 참조도 가능하다.
NOT NULL은 NULL을 금지하고 UNIQUE는 키의 중복을 제한한다. 에서 CHECK는 식이 false인 행을 거부하므로 CHECK(amount >= 0)만으로 NULL을 막지 못한다. 값이 필수이면 NOT NULL도 필요하다.
는 이런 논리 구조이고 파일 시스템의 디렉터리 이름과 같은 개념은 아니다.
는 불필요한 중복과 갱신 이상을 줄이기 위한 설계 방법이다.
는 특정 키로 필요한 행 위치를 빠르게 찾기 위한 추가 구조다.
LEARN THROUGH PRACTICE

PHP 파일 작성에서 웹 실행·DB 연결까지 경계 나누기

소스 파일 존재, 실행, 애플리케이션의 DB 접속을 서로 다른 단계의 결과로 확인한다.

실습 구성과 전제

  • phpinfo. 내용 조회와 WordPress 설치 화면은 서로 다른 구성 사례다. 첫 파일이 두 번째 설치 프로그램으로 바뀐 연속 실행이 아니다.
  • 실행기가 준비된 실습 환경을 사용한다. 설정 정보가 많이 노출되는 phpinfo 페이지를 외부에 상시 공개하지 않는다.
  1. 파일 내용과 실행 결과를 구별한다

    • 첫 사진의 cat은 파일의 텍스트를 읽는다. 여는 태그와 phpinfo()가 보인다는 것은 소스가 저장되었다는 증거이며 웹 서버가 를 실행했다는 증거는 아니다.
    • 브라우저가 코드를 그대로 내보낸다면 실행기 연결 문제를 의심해야 한다. 정상 실행에서는 소스 문장 대신 프로그램이 만든 출력이 HTTP 응답 본문이 된다.
    <?php
    header("Content-Type: text/plain; charset=UTF-8");
    echo "PHP executed\n";

    정보 노출을 줄인 재구성 실행 확인 파일이다. 처리 경로가 준비된 로컬 실습에서만 사용한다.

    5/26 - php, mariaDB · 명령·상태 출력 5원본 크기로 보기 ↗
    • cat phpinfo.php 아래에 PHP 태그와 phpinfo() 호출이 그대로 표시된다.
    • 이 화면은 터미널의 파일 조회이며 PHP 정보 페이지가 렌더링된 브라우저 화면이 아니다.
    확인 기준

    파일 존재, 문법 검사, CLI 실행, 웹 요청 실행을 각각 확인한다. CLI와 FPM이 서로 다른 버전·설정을 사용할 수 있다.

  2. 웹 서버와 PHP 실행기의 연결을 검증한다

    • 정적 파일 응답이 성공한 뒤 . 요청을 실행기로 전달하는 설정을 확인한다. FPM을 쓴다면 FastCGI 소켓·스크립트 경로·풀의 실행 계정이 연결되어야 한다.
    • -l은 소스의 문법을 검사하지만 DB 접속이나 FPM 요청 경로까지 실행해 보지는 않는다. curl 응답 본문에서 재구성한 고정 문자열을 확인하면 웹 실행을 별도 검증할 수 있다.
    bash
    php -l /srv/lab-web/check.php
    curl -i http://127.0.0.1/check.php

    설정된 실습 문서 루트의 파일 문법과 웹 응답을 조회하는 예시다.

    확인 기준

    소스 노출, 404, 502, 오류는 실패 경계가 다르다. 웹 서버 로그와 FPM 상태를 해당 요청 시각에 맞춰 읽는다.

  3. 애플리케이션의 DB 설정은 다음 단계다

    • WordPress 화면은 DB 이름·사용자·암호·호스트·테이블 접두사를 요구한다. 프로그램이 실행되더라도 올바른 DB 계정과 접속 경로가 없으면 설치가 이어지지 않는다.
    • 테이블 접두사는 생성할 테이블 이름의 접두어이며 DB 서버 주소가 아니다. 실제 암호나 운영 계정은 예시 본문에 복사하지 않는다.
    PHP·MariaDB·CMS · CMS : Contents Management System (8)원본 크기로 보기 ↗
    • 설치 화면에 Database name, Username, Password, Database host, Table prefix 입력 항목이 보인다.
    • wp-config.php 안내가 있어 애플리케이션이 사용할 DB 연결 설정 단계임을 알 수 있다.
    확인 기준

    이 양식이 보인다는 사실은 DB 인증 성공의 증거가 아니다. 입력 후 연결·권한·테이블 생성 결과를 추가 확인해야 한다.

실습에서 확인한 동작 원리

  • 소스 파일을 읽은 결과와 프로그램을 실행한 HTTP 응답은 구별해야 한다.
  • 웹 서버→ 실행기→DB의 각 경계마다 경로·신원·오류 로그가 다르다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서
LEARN THROUGH PRACTICE

MariaDB 연결 성공 뒤 SQL 문법·선택 DB 상태 읽기

접속 성공, 구문 오류, 현재 DB, 전송 방식의 정보를 실제 클라이언트 출력에서 분리한다.

실습 구성과 전제

  • 두 사진은 다른 세션·계정의 조회 결과다. 권한이 같은 한 세션의 연속 출력처럼 읽지 않는다.
  • 실습 계정은 준비된 DB 서버의 최소 조회 권한을 사용한다. -p 뒤에 실제 암호를 붙여 명령 기록에 남기지 않는다.
  1. 로그인과 SQL 파싱을 구별한다

    • 프롬프트까지 들어왔다는 것은 해당 연결의 인증이 완료되었다는 뜻이다. 그 뒤 show database의 ERROR 1064는 구문 단계에서 난 오류다.
    • 복수형 SHOW DATABASES로 고치면 목록이 반환된다. 목록은 현재 계정이 볼 수 있는 DB 범위를 반영하므로 서버의 모든 DB가 반드시 보인다고 단정하지 않는다.
    SHOW DATABASES;
    SELECT VERSION(), CURRENT_USER(), DATABASE();

    접속한 세션에서 서버 버전·권한 계정·선택 DB를 읽는 조회 예시다.

    PHP·MariaDB·CMS · phpMyAdmin 데이터베이스 관리 (5)원본 크기로 보기 ↗
    • 로그인 후 MariaDB 프롬프트와 10.5.29 서버 버전이 표시된다.
    • show database는 1064 오류를 내고 show databases는 네 행의 목록을 반환한다.
    확인 기준

    구문 오류를 인증 실패로 처리하지 않는다. 서버 응답을 받은 시점과 실패한 문장을 함께 기록한다.

  2. 현재 데이터베이스와 접속 경로를 읽는다

    • status 화면에는 접속 사용자, 연결 방식, 문자 집합 등이 따로 나온다. Current database가 비어 있으면 기본 DB를 선택하지 않은 상태이며, 인증 실패가 아니다.
    • 별도 사진은 UNIX 소켓 연결이므로 SSL Not in use를 곧바로 원격 구간의 평문 전송 증거로 해석하지 않는다. 전송 경로를 먼저 구분해야 한다.
    5/26 - php, mariaDB · 명령·상태 출력 14원본 크기로 보기 ↗
    • Connection 항목은 Localhost via UNIX socket이고 Current database는 비어 있다.
    • SSL Not in use와 여러 utf8mb4 문자 집합 항목이 각각 별도 행으로 보인다.
    확인 기준

    현재 세션의 권한과 전송 방식을 확인한 뒤 결과를 해석한다. socket 접속과 접속은 계정 매칭·보안 조건이 달라질 수 있다.

  3. 스키마 선택 후 이름 해석을 확인한다

    • 테이블 이름만 쓸 때는 현재 DB를 기준으로 찾는다. USE로 DB를 선택하거나 DB명.테이블명으로 명시하면 어떤 객체를 조회했는지 분명해진다.
    • 목록 표시 권한, 테이블 읽기 권한, 테이블 존재 여부는 다르다. SELECT DATABASE()가 NULL인 경우에도 SELECT 1 같은 특정 DB에 의존하지 않는 질의는 실행될 수 있다.
    SELECT DATABASE();
    USE labdb;
    SELECT DATABASE();
    SHOW TABLES;

    labdb는 준비한 실습 DB 이름이다. 출력은 실제 실행 세션에서 확인한다.

    확인 기준

    재구성한 labdb가 실제 준비된 경우에만 USE를 적용한다. Unknown database·table does not exist·access denied를 서로 다른 원인으로 분류한다.

실습에서 확인한 동작 원리

  • 접속 성공 뒤에도 문법, 객체 선택, 개별 권한 단계에서 각각 오류가 발생한다.
  • 현재 DB와 연결 방식은 status·DATABASE() 같은 명시적 조회로 확인하며 화면 하나의 성공을 확대하지 않는다.
관련 개념·전체 실습 화면 이어서 읽기 →
동작·명령 참고 문서

04예제로 따라가기

  • 고객 이름을 주문마다 복사해 관계를 표현하면 동명이인과 이름 변경을 처리하기 어렵다. 고객 키로 연결하면 관계의 식별 기준을 유지한다.
  • UNIQUE와 NOT NULL을 DB 제약으로 두면 서로 다른 입력 경로에서도 핵심 구조 조건을 검사할 수 있다.
  • SELECT 1 성공은 연결과 기본 질의 처리의 증거이며 실제 주문 테이블 권한이나 업무 성공까지 증명하지 않는다.

05혼동하기 쉬운 점과 확인 기준

  • 성능이 느리다는 이유로 만 추가해도 잘못된 관계 연산은 고쳐지지 않는다.
  • 응답 지연은 질의 자체의 연산량뿐 아니라 잠금 대기, 연결 풀 고갈, 네트워크와 디스크 지연에서도 생긴다.
  • ACID라는 약어를 붙였다는 이유로 잘못된 업무 코드를 DB가 자동 교정하지는 않는다.

06상세 노트 · 실습 자료

헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.

공식 문서 · 표준

기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.