데이터베이스 시스템: 두 판 사이의 차이

youngwiki
편집 요약 없음
편집 요약 없음
45번째 줄: 45번째 줄:
#* 해당 모델은 relatinal model을 캡슐화, 메서드, 객체 식별 개념과 결합하여 확장한 방식이다.
#* 해당 모델은 relatinal model을 캡슐화, 메서드, 객체 식별 개념과 결합하여 확장한 방식이다.


<nowiki>===Data Abstraction===</nowiki>
===Data Abstraction===
[[파일:ArchitecureOfDBSystem.png|섬네일|An architecture for a database system]]
[[파일:ArchitecureOfDBSystem.png|섬네일|An architecture for a database system]]
DB는 복잡한 데이터 구조를 가지고 해당 DB 내의 데이터를 표현한다. 하지만 대부분의 DB 사용자들은 해당 방법에 대한 전문적인 지식이 없기 때문에 개발자들은 여러 단계의 Data Abstraction을 통해 이런 복잡성을 숨긴다. 이를 통해 사용자가 시스템과 상호작용하는 것을 더욱 쉽게 할 수 있다. 이러한 Data Abstraction은 오른쪽 그림과 같이 세가지 수준에서 구현된다.
# Physical Level: 가장 낮은 추상화 수준으로 데이터가 실제로 어떤 방식으로 저장되는지에 대해 기술한다.
# Logical Level
#* 그 다음으로 높은 수준이지만 Physical Level에 비해 상대적으로 단순한 구조로 데이터베이스에 저장된 데이터가 무엇인지와 해당 데이터들 사이의 관계에 대해서 서술한다.
#데이터 베이스 관리자는 DB에 어떤 정보를 저장할지를 결정할 때 논리적 수준의 추상화를 이용한다.
#* physical data independence: 해단 수준에서 사용되는 단순한 구조를 실행시킬 때 복잡한 physical level에서의 구조를 통해서 구현될 수 있음에도, Logical Level과는 독립적이므로 사용자는 이에 대해서 몰라도 된다는 것이다.
#View Level
#* 가장 높은 수준으로 사용자에게 전체 데이터 베이스의 일부만을 표시한다. 이는 대부분의 DB 사용자들은 전체의 DB 정보를 필요로 하지 않고 특정 부분만 접근하면 되기 때문이다. 이는 하나의 DB에 대해 여러 개의 뷰를 제공하여 구현된다. 그리고 이를 통해서 이런 사용자들의 상호작용을 단순화할 수 있다.
#* 논리적 수준은 단순하지만 전체 DB는 매우 거대하고 다양한 데이터로 이루어져 있으므로 여전히 복잡성이 남아있다.





2025년 3월 10일 (월) 10:29 판

개요

Database-management system(DBMS)란 연관된 data들과 그러한 데이터들에 접근하는 프로그램의 집합이다.이를 통해서 사용하기 편리하고 효율적인 환경을 이용자에게 제공한다. Database System(DB system)은 매우 많고 가치있기 때문에 다수의 유저와 application들에 의해 동시에 접근되는 정보를 관리하도록 설계되었다. 이를 위해 정보 저장을 위한 구조를 정의하거나 정보를 수정하는 메커니즘을 제공한다. 또한 DB system은 system crash나 허가되지 않은 접근들에 맞서서 저장된 정보들의 안전성을 담보해야 한다.

이런 DB system의 예시는 다음과 같다.

  • 기업 정보
    • 판매: 소비자, 상품, 구매
    • 회계: 가격, 영수증, 자산
    • 인적 자원: 직원 정보, 급여

목적

DB system은 file system을 통한 data관리의 어려움을 타파하기 위해 만들어졌다. 아래와 같은 어려움들이 존재한다.

  1. Data redundancy and inconsistency
    • 서로 다른 프로그래머들이 파일과 응용 프로그램을 장기간에 걸쳐 만드므로 다양한 파일들이 서로 다른 구조로 이루어질 가능성이 높다. 또한 응용 프로그램들이 서로 다른 프로그래밍 언어로 짜여질 가능성 또한 존재한다. (inconsistency)
    • 추가로 동일한 정보가 여러 파일에 동시에 존재할 가능성이 있다.
  2. Difficulty in accessing data
    • 유저가 data에 접근하여 이를 활용하고자 할때 그에 대한 응용 프로그램을 각각 만들어야 한다. 아니면 사용자가 수작업으로 데이터를 가공하여야 한다.
    • 예시로 유저가 60점 이상인 학생들의 목록을 추출할 때, 특정 주소지에 있는 학생들의 목록을 추출할 때, 모두 별개의 프로그램이 필요하다.
  3. Data isolation
    • 데이터가 여러곳에 분산되어 있고, 파일 형식 등이 다를 수 있으므로 적절한 응용 프로그램의 개발이 어렵다.
  4. Integrity
    • 어떤 데이터에 대한 응용 프로그램의 경우는 특정한 제약 조건이 필요하다. (예를 들면 몸무게 > 0 등...) 하지만 새로운 제약이 추가되거나 기존의 제약이 수정될 경우에는 이를 응용 프로그램에 적용하는 것이 어렵다.
  5. Atomicity of Updates
    • 컴퓨터가 응용 프로그램의 실행 중 문제가 발생하였을 때 이를 이전의 상태로 복원을 하여야 한다. 이는 DB의 일관성에 필수적인 요소이다. 예를 들어 은행에 500만원을 입금하였을 때 장애가 생기면 500만원이 입금되었으나 실제로는 계좌에 돈이 입금되지 않는 경우가 생길 수 있으므로 이를 취소해야 한다. 즉 반만 실행되서는 안되며, 완전히 성공하는 경우가 아니라면 아예 DB의 상태가 바뀌어서는 안된다. 하지만 파일 기반 시스템의 경우 이런 속성을 구현하는 것이 어렵다.
  6. Concurrent access by multiple users
    • DB 관리의 효율성과 속도를 위해서는 다수의 사용자가 동시에 접속할 수 있어야 한다. 하지만 이러한 경우 다음과 같은 문제가 생길 수 있다. 계좌 A의 잔액이 10,000달러인 상황에서 두 명의 은행 직원이 동시에 500달러와 100달러를 인출한다고 가정하자. 두 프로그램이 동시에 실행되면, 두 프로그램이 각각 이전 잔액인 10,000달러를 읽고, 차감한 후 새로운 값을 기록할 수 있다. 이 경우, 최종 잔액은 9,500달러 또는 9,900달러로 잘못 저장될 수 있다.
    • 이러한 문제를 해결하기 위해서는 시스템이 감독 기능을 제공해야 한다. 하지만 기존의 파일 처리 시스템에서는 여러 응용 프로그램들이 사전에 조율되지 않았기 때문에 이를 제공하기가 어렵다.
  7. Security problem
    • 사용자는 그 신분에 따라 접근할 수 있는 data의 범위가 달라져야 한다. 예를 들어 학생을 교수의 이름과 이메일 주소는 볼 수 있어도 교수의 연봉 등의 정보에는 접근할 수 없어야 한다. 하지만 파일 관리를 기반으로 DB를 관리하면 이러한 경우를 통제하기 어렵다.

View of Data

DB system의 기본적인 목적은 data에 관한 abstract view를 제공하는 것이다. abstract view란 사용자가 data가 어떻게 관리되고 저장되는 지에 대한 지식이 없어도 해당 data에 접근하고 조작할 수 있다는 개념을 의미한다.

Data Models

DB의 구조를 뒷받침하기 위해서는 Data Model이 필요하다. 이는 데이터를 설명하고, 데이터 간의 관계와 의미, 그리고 consistency 제약 조건을 정의하는 개념적인 도구들의 집합이다. Data Model에는 대표적으로 다음 예시들이 있다.

  1. Relational Model
  2. Entity-Relationship Model(E-R Model): 해당 모델은 entity라고 불리는 기본 객체들과 해당 객체들 간의 관계들의 집합을 통해 data를 나타낸다.
  3. Semi-structured Data Model
    • 동일한 유형의 개별 data 항목들이 서로 다른 속성 집합을 가질 수 있도록 허용한다.
    • 대표적인 예시로는 XML이 있다.
  4. Object-Based Data Model
    • 객체지향 프로그래밍의 대두와 함께 개발된 data model이다.
    • 해당 모델은 relatinal model을 캡슐화, 메서드, 객체 식별 개념과 결합하여 확장한 방식이다.

Data Abstraction

An architecture for a database system

DB는 복잡한 데이터 구조를 가지고 해당 DB 내의 데이터를 표현한다. 하지만 대부분의 DB 사용자들은 해당 방법에 대한 전문적인 지식이 없기 때문에 개발자들은 여러 단계의 Data Abstraction을 통해 이런 복잡성을 숨긴다. 이를 통해 사용자가 시스템과 상호작용하는 것을 더욱 쉽게 할 수 있다. 이러한 Data Abstraction은 오른쪽 그림과 같이 세가지 수준에서 구현된다.

  1. Physical Level: 가장 낮은 추상화 수준으로 데이터가 실제로 어떤 방식으로 저장되는지에 대해 기술한다.
  2. Logical Level
    • 그 다음으로 높은 수준이지만 Physical Level에 비해 상대적으로 단순한 구조로 데이터베이스에 저장된 데이터가 무엇인지와 해당 데이터들 사이의 관계에 대해서 서술한다.
  3. 데이터 베이스 관리자는 DB에 어떤 정보를 저장할지를 결정할 때 논리적 수준의 추상화를 이용한다.
    • physical data independence: 해단 수준에서 사용되는 단순한 구조를 실행시킬 때 복잡한 physical level에서의 구조를 통해서 구현될 수 있음에도, Logical Level과는 독립적이므로 사용자는 이에 대해서 몰라도 된다는 것이다.
  4. View Level
    • 가장 높은 수준으로 사용자에게 전체 데이터 베이스의 일부만을 표시한다. 이는 대부분의 DB 사용자들은 전체의 DB 정보를 필요로 하지 않고 특정 부분만 접근하면 되기 때문이다. 이는 하나의 DB에 대해 여러 개의 뷰를 제공하여 구현된다. 그리고 이를 통해서 이런 사용자들의 상호작용을 단순화할 수 있다.
    • 논리적 수준은 단순하지만 전체 DB는 매우 거대하고 다양한 데이터로 이루어져 있으므로 여전히 복잡성이 남아있다.




Category:데이터베이스 시스템