Developer Log
  • Wiki
  • Books
    • 리눅스 시스템 프로그래밍
      • 핵심 개념 소개
        • 시스템 프로그래밍
        • API와 ABI
        • 리눅스 프로그래밍의 개념
          • 파일과 파일시스템
          • 프로세스
          • 사용자와 그룹
          • 권한
          • 시그널
          • 프로세스간 통신
          • 에러 처리
    • 데이터 베이스 첫걸음
      • 데이터베이스란
        • 데이터베이스의 역할을 생각해 보자
          • 우리와 데이터베이스의 관계
          • 데이터베이스의 기본 기능
          • 데이터베이스 종류
      • 관계형 데이터베이스란
        • 대표적인 DBMS를 알아보자
          • 관계형 데이터베이스란
          • SQL 기초 지식
          • 관계형 데이터베이스를 다루기 위한 사전 지식
      • 데이터베이스에 얽힌 돈 이야기
        • 초기비용과 운영비용을 생각하자
      • 데이터베이스와 아키텍처 구성
        • 다중화에 대해 생각해보자
          • 아키텍처란
          • 데이터베이스의 아키텍처
            • 역사와 개요
              • Stand-alone
              • 클라이언트/서버
              • Web 3계층
            • 가용성과 확장성의 확보
          • DB 서버의 다중화
            • 클러스터링
            • 리플리케이션
          • 성능을 추구하기 위한 다중화 - Shared Nothing
          • 적합한 아키텍처를 설계하기 위해
      • DBMS를 조작할 때 필요한 기본 지식
        • MySQL 설치해보자
        • MySQL과 커넥션 만들기, 데이터베이스에 전화걸기
        • SQL과 관리 명령의 차이
        • 관계형 데이터베이스의 계층
      • SQL 문의 기본
        • SELECT 문으로 테이블 내용을 살펴보자
        • SELECT 문을 응용해보자
        • 데이터를 갱신, 삽입, 제거해보자
        • 뷰를 작성하고 복수 테이블에서 선택해보자
      • 트랜잭션과 동시성 제어
      • 테이블 설계의 기초
      • 백업과 복구
      • 성능을 생각하자
    • 개발자가 반드시 정복해야 할 객체 지향과 디자인 패턴
      • 객체 지향
        • 들어가기
        • 객체 지향
        • 다형성과 추상 타입
        • 재사용: 상속보단 조립
      • 설계 원칙 / DI와 서비스 로케이터
        • 설계 원칙: SOLID
          • 단일 책임 원칙(Single Responsibility Principle)
          • 개방 폐쇄 원칙(Open - Closed Principle)
          • 리스코프 치환 원칙(Liskov Substitution Principle)
          • 인터페이스 분리 원칙(Interface Segregation Principle)
          • 의존 역전 원칙(Dependency Inversion Principle)
          • SOLID 정리
        • DI(Dependency Injection)와 서비스 로케이터
      • 주요 디자인 패턴
        • 디지인 패턴이란?
        • 전략(Strategy) 패턴
        • 템플릿 메서드(Template Method) 패턴
        • 상태(State) 패턴
        • 데코레이터(Decorator) 패턴
        • 프록시(Proxy) 패턴
        • 어댑터(Adapter) 패턴
        • 옵저버(Observer) 패턴
        • 미디에이터(Mediator) 패턴
        • 파사드(Facade) 패턴
        • 컴포지트(Composite) 패턴
        • 널(Null) 객체 패턴
        • 팩토리 메서드 패턴
        • 커맨드 패턴
        • 추상 팩토리 패턴
    • 테스트 주도 개발
      • 1부
        • 다중 통화를 지원하는 Money 객체
        • 타락한 객체
        • 모두를 위한 평등
        • 프라이버시
        • 솔직히 말하자면
        • 돌아온 '모두를 위한 평등'
        • 사과와 오렌지
Powered by GitBook
On this page
  • 데이터의 검색과 갱신
  • 동시성 제어
  • 장애 대응
  • 보안

Was this helpful?

  1. Books
  2. 데이터 베이스 첫걸음
  3. 데이터베이스란
  4. 데이터베이스의 역할을 생각해 보자

데이터베이스의 기본 기능

Previous우리와 데이터베이스의 관계Next데이터베이스 종류

Last updated 6 years ago

Was this helpful?

데이터의 검색과 갱신

  • 데이터베이스의 용도로써 가장 중요한 기능은 '검색' 이다.

  • 데이터베이스는 새로운 데이터를 등록(등록)하고 기존 데이터를 수정(수정)하며 불필요해진 데이터를 제거(제거)하는 것도 가능해야 한다.

  • 아래에 나타낸 조작은 데이터베이스의 종류나 제품과 관계없이 수행할 수 있다.

  • 데이터베이스를 조작할 때 중요한 것은 "데이터를 어떤 포맷(형식)으로 관리하는가" 이다.

  • 데이터가 방대해 질수록 처리 성능에 유의해야 한다.

동시성 제어

데이터베이스는 동시에 복수의 사용자로부터 검색이나 갱신 처리를 받는다. 이때 중요한 점은 "갱신의 무결성을 어느 정도로 보장할 것인가?" 하는 점이다.

예를 들어, 데이터베이스의 사용자가 2명인 경우를 생각해 보자. PC 의 주소록 파일을 아버지와 아들이 공유하고 있다고 가정하자.

아버지가 파일을 열어 '박XX' 씨의 주소를 변경할 때, 아들도 동시에 파일을 열어서 '박XX' 씨의 주소를 '잘못된' 주소로 갱신하려고 한다면 어떻게 될까?

동작은 대략 다음 중 하나가 될 수 있을 것이다.

  1. 최초로 파일을 연 사람이 파일을 열고 있을 때, 그 다음으로 파일을 열려고 한 사람은 파일을 열 수 없다.

  2. 최초로 파일을 연 사람이 파일을 열고 있을 때, 그 다음으로 파일을 열려고 한 사람에게는 파일이 '읽기 전용(Read Only)' 으로 밖에 열리지 않는다.

  3. 어떤 사람도 문제없이 파일을 여는 것이 가능하고 나중에 수행된 쪽의 갱신이 반영된다.

첫 번째 조건은 아버지가 최초로 주소록 파일을 연 경우로, 아버지가 갱신을 끝내고 파일을 닫을 때까지 아들은 파일을 열 수가 없다. 주소록이 물리적인 책이라면 아버지가 주소록을 가지고서 어딘가로 가서 아들은 주소록을 만지는 것조차 가능하지 않은 상황에 해당한다.

두 번째 조건은 아버지가 최초로 주소록 파일을 연 경우로, 아버지가 갱신을 끝내고 주소록 파일을 닫기 전까지 아들은 파일을 갱신할 수 없지만 파일을 열어 보는 것은 가능하다. 주소록이 물리적인 책이라고 한다면, 아버지가 주소록을 열고 있을 때 아들은 옆에서 '보는' 것은 가능해도 펜으로 '쓰는' 것은 허용되지 않는다. 아들에게는 주소록이 잠시 읽기 전용이 되는 것이다.

세 번째 조건은 아버지와 아들 양측에서 동시에 갱신려는 경우이다. 주소록이 물리적인 책이라고 한다면, 2명이 펜을 쥐고 동시에 쓰려고 하는 상황이다.

데이터베이스를 복수의 사용자가 동시에 공유하고 이용하려고 한다면, 데이터를 갱신하는 상황에 대한 제어가 필요다.

이러한, 복수 사용자의 갱신을 조절하기 위한 데이터베이스의 기본 기능을 "동시성 제어" 또는 "배타 제어" 라고 한다.

더티 쓰기 (Dirty Write) 란

위에서 소개한 3가지 처리 방법 중 "어떤 사람도 문제없이 파일을 여는 것이 가능하고 나중에 수행된 쪽의 갱신이 반영되는 경우" 를 "더티 쓰기 (Dirty Write)" 라고 한다. 데이터베이스에서 이런 식의 제어는 일반적으로 데이터 무결성 관점에서 기피하는 경향이 있다.

장애 대응

데이터베이스의 중요한 기능 중 하나는 "장애에 강할 것" 이다. 쉽게 말해, "좀처럼 부서지기 어렵고 부서졌다 하라도 복원할 수 있어야 한다" 라 것이다.

데이터 소실 문제에 대한 대책으로는 다음과 같은 두 가지 방침을 생각할 수 있다.

  1. 데이터 다중화

    데이터를 한 곳이 아니라 복수의 장소에 분산해서 유지하는 것으로, 데이터가 완전하게 소실되는 것을 막는 예방 방법이다.

  2. 백업

    데이터 소실이 발생했을 때 데이터를 복원하는 방법으로 '사후대책' 이라고 할 수 있다.

보안

데이터베이스에 요구되는 마지막 기본 기능은 "보안" 이다. 즉, 데이터베이스에 보존된 데이터를 어떻게 숨길 것인가 대한 이다.

예를 들어, 데이터베이스 계좌번호와 주소 및 신용카드 번호와 비밀번호 등이 저되어 타인에게 알려지면 틀림없이 악용될 수 있다.