[DB] Database Management System(DBMS)

• DBMS에는 특정 기관에 대한 정보를 가지고 있다.
  • 연관된 data의 집합
  • data와 data 접근에 필요한 프로그램의 집합
  • 쉽고 편한 data CRUD 환경 제공
• 초창기 database app은 파일 시스템을 이용하여 구축되었다. 이는 여러가지 단점이 존재했다.
  • data 증폭 및 불일치: 여러 종류의 파일과 다양한 포맷
  • data 접근의 어려움: 새로운 작업을 수행하기 위해서는(예를 들어 특정 조건을 만족하는 data list 검색) 새로운 프로그램을 작성해야 된다.
  • data 고립: 서로 관련된 data들이 다른 파일 / 포맷으로 흩어짐
  • 무결성 문제: 무결성 제약조건이 DB와 다르게 명시적으로 나타나지 않으며 해당 조건이 지켜지기 어렵다. 따라서 프로그램에 제약조건이 내포될 수 밖에 없는데 이로 인해 새로운 제약조건을 추가하거나 기조의 조건을 변경하는 것이 어렵다.
  • 원자 단위의 업데이트: 업데이트중 일부분만이 수행될 경우 data 일관성이 깨지게 된다.
  • 동시접근: 성능을 위해서는 data에 대한 동시 접근이 필요한데 이에 대한 통제가 제대로 이루어지지 않는다면 data 일관성이 깨지고 만다. 따라서 많은 user들이 서로 다른 data에 접근하게 되는 일이 발생할 수도 있다.
  • 보안문제: 파일 시스템의 경우 특정 유저에게 특정 data에만 접근 가능한 권한 설정이 어렵다.
• Levels of Abstraction
  • Physical level: record가 어떻게 저장되는지(하드웨어 측면)
  • Logical level: DB에 저장되는 data와 data사이 관계 설명

    type instructor = record
        ID: string;
        name: string;
        dept_name: string;
        salary: integer;
    end;
    

  • View level: app은 data의 타입을 숨기고, 보안상 여러 data를 유저로부터 숨긴다.
• 인스턴스와 스키마
  • 스키마: DB의 논리적 구조를 의미한다. 예를 들어 특정 DB는 소비자, 계좌, 그들의 관계에 대한 정보로 이루어져 있다.
    • Physical schema: Physical level에서의 DB 설계
    • Logical schema: Logical level에서의 DB 설계
  • 인스턴스: 특정 시점에 DB에 있는 실제 data
  • Physical Data independence: Physical schema가 변해도 Logical schema는 변하지 않는다. 즉 영향이 없다. 하지만 App은 Logical schema을 기반으로 설계되기 떄문에 Logical schema가 변동되면 App도 변경이 필요하다.