Computer Science/Database Design & Query Languages

[CS][데이터베이스설계와질의] Chapter01. Introduction to Database Systems

y-seo 2023. 10. 9. 20:46
 
 

What is a DBMS?

  • 데이터 vs 정보 vs 지식
    • 세가지 모두 데이터에서 파생된 개념 
    • 데이터 : 서술/관찰/측정된 날 것 그대로의 사실, 모든 것이 될 수 있음
    • 정보 : 준비되고 조직된 데이터, 사람이 사용하기 위해 다듬고 만든 것
    • 지식 : 실제 의사결정을 위해 사용되는 데이터/정보/규칙, 인간의 법칙까지 포함
  • 데이터베이스 : 관련된 데이터의 크고 통합된 모음
    • 통합(Integrated) : 개념적으로 보았을 때 데이터가 퍼져있지 않고 모아져 있음 
  • DBMS(Database Management System)
    • 데이터베이스를 저장하고 관리하도록 설계된 소프트웨어 패키지
    • DB에서 일어나는 일을 DBMS에게 맡김
    • DB를 관리하기 위한 체계
    • 우리가 만드는 프로그램은 DBMS를 통해 Disk 저장소에 접근 = DBMS approach

 

 
 

Why use a DBMS?

  • 데이터 독립성 : 응용 프로그램들은 데이터의 표현과 저장에 대한 세부사항에 영향을 받지 않는 것이 이상적, DBMS는 이러한 세부사항을 은닉하는 데이터의 추상적인 관점 제공
  • 효율적인 액세스
  • 애플리케이션 개발 시간 단축
  • 데이터 무결성 및 보안
  • 균일한 데이터 관리 : 데이터에 대한 관리를 중앙 집중화
  • 동시 액세스, 충돌로부터의 복구

 

 
 

Data Models

  • Data Model
    • 데이터를 설명하기 위한 개념의 모음
    • 고수준의 데이털르 기술하는 구성자들의 집합
    • DBMS가 사용자로 하여금 저장될 데이터를 데이터 모델에 의해 정의할 수 있게 함
  • Schema
    • 주어진 데이터 모델을 사용하여 특정 데이터 모음을 설명하는 것
    • 틀, 데이터 개개인의 표현 X
    • 각 field(attribute, raw)의 이름과 타입, 명
    • "데이터 모음이 이런 식입니다"라고 표현해둔 것
    • DB에서 데이터가 구조화 되는 방식을 정의
  • Instance
    • 정의된 schema에 따라 DB에 실제로 저장된 값

  • Relational model of Data (관계형 데이터 모델)
    • 오늘날 가장 널리 사용
    • 레코드들의 집합
    • 주요 개념 : 관계, 기본적으로 행/열이 있는 테이블
    • Relation한 컨셉으로 데이터 표
    • 모든 관계에는 열 또는 필드를 설명하는 스키마 존재

 

 
 

History of Data Models

  1. 1960년대 초반
    1. Network Model
    2. Node&Edge로 세상 표현 ( ≒ graph )
    3. By Charles Bachman at GE
    4. CODASYL (Conference On Data Systems Language)
  2. 1960년대 후반
    1. Hierarchical Model
    2. Root 존재 ( ≒ tree )
    3. IMS by IBM
    4. SABRE airline reservation system
  3. 1970년대
    1. Relational Model
    2. By Edgar Codd at IBM
    3. SQL from IBM System R
  4. 1980년대 후반 & 1990년대 초반
    1. Extended(Object) Relational Model : 데이터를 테이블로 보는, Relational인데 Object가 수식어
    2. Object Oriented Model : 객체 지향
  5. 1990년대 후반
    1. Data Warehousing, Data Mining, Distributed DB, Web Database, ERP(Enterprise Resource Planning) 등
  6. ER(Entity-Relationship Model)
    1. Semantic Data Model vs Record based Model
    2. 어떤 데이터 모음이 필요한지 탐색하는 것

 

 
 

Levels of Abstraction

  • Schema를 Level로 만들자
  • 적어도 3개 Level이 표준

  • 사용자가 데이터를 보는 방식을 설명한 그림
  • External schema
    • 사용자의 View
    • 개별 사용자 입장에서 DB의 논리적 구조를 정의한 것
    • 사람마다 보는 View는 다르지만 사실 보는 대상(Conceptual Schema)은 동일
    • 필요한 것만 보기, User가 굳이 다 볼 필요는 없으니까
    • 동일한 데이터에 대해 서로 다른 관점 정의 허용
    • 최종 사용자의 요구들에 의해 방향이 정해짐
    • 하나의 DB System에는 여러 개의 External schema 존재 가능
    • 하나의 External schema를 여러 개의 응용 프로그램이나 사용자가 공용 가능
  • Conceptual schema
    • 전체적인 View
    • 데이터의 전체 논리적 구조를 정의
    • 얘로 DB를 바라 봄
    • 개념적 파악 가능
    • 모든 Relation 기술
    • 하나의 DB에는 하나의 Conceptual shema만 존재
  • Physical schema
    • = Internal schema
    • 추가적인 저장의 세부사항들 명시
    • 사용되는 파일과 인덱스를 설명 (내부 레코드 형식, 물리적 순서 등)
    • 물리적 저장 장치의 입장에서 본 DB 구조 (물리적으로 어떻게 저장/관리 되어야 하는지)
    • Conceptual schema를 보조기억장치에 물리적으로 구현하기 위한 방법 기술
    • 하나의 DB에는 하나의 Physical shema만 존재
  • Schema는 DDL로 정의된다 (DDL :  Data를 Definition 하는 Language)
  • Data는 DML로 수정/쿼리된다 (DML : Data를 manipulatie 하는 Language)

 

 
 

Example : University Database

  • External Schema (View)
    • Course_info(cid:string, enrollment:integer)
  • Conceptual schema
    • Students(sid: string, name: string, login: string, age: integer, gpa:real)
    • Courses(cid: string, cname:string, credits:integer)
    • Enrolled(sid:string, cid:string, grade:string)
  • Physical schema (Internal Schema)
    • Relations stored as unordered files
    • Students, Courses 릴레이션들의 첫번째 필드에 대한 인덱스를 생성

 

 
 

Data Independence

  • 만약 DBMS가 없다면, 응용프로그램은 DB에 종속
    • 이렇게 안하려고 DBMS 생성 = Data Independence
  • 응용 프로그램이 데이터의 구성과 저장 방식의 변화로부터 격리되어 있다는 뜻
  • 데이터 추상화를 통해 달성 → 특히 Conceptual & External schema가 독립성을 유지하기 위해 큰 역할
  • Layer을 만들면 얻는 효과, 수정 시 다 갈아엎지 않게
  • DBMS 사용의 가장 중요한 효과 중 하나
  • 데이터가 구조화되고 저장되는 방식으로부터 떨어진 애플리케이션
  • Logical data independence : 데이터의 논리적 구조 변경 또는 저장될 relation들의 선택의 변경로부터 보호
  • Physical data independence : 데이터의 물리적 저장의 세부적인 변화로부터 보호, By Conceptual schema
    • 위 두 가지는 Layer가 3개이기 때문에 가능한 것

 

 
 

Transaction : An Execution of a DB program

  • 일처리의 단위
  • DB 작업(읽기/쓰기) atomic한 순서
    • atomic ≒ unit = 쪼갤 수 없는 단위 
  • transaction이 시작될 때 DB가 consistent한 경우, 완전히 실행된 각 transaction은 DB를 consistent state로 유지해야 합니다 ★★★
    • consistent state가 1순위, 무결성(일관성)을 위해
    • 각 operation까지 consistency와 integrate는 보장되지 않음 → transaction에서 보장 (DBMS가 처리)
    • transaction 중간에는 consistency를 논하지 않음

 

 
 

Concurrency Control

  • 동시성 제어
  • DBMS의 우수한 성능을 위해서는 사용자 프로그램의 동시 실행이 필수적
    • Disk Access가 빈번하고 상대적으로 느리기 때문에
    • 여러 사용자 프로그램에서 동시에 작업하여 CPU hummning을 유지하는 것이 중요
  • 다른 사용자 프로그램의 Inerleaving 작업은 불일치를 초래할 수 있음
  • DBMS는 이러한 문제가 발생하지 않도록 보장
    • 사용자가 단일 사용자 시스템을 사용하는 것처럼
    • scheduling, locking 등

 

 
 

Structure of a DBMS

  • 일반적인 DBMS는 Layered architecture
  • 각 시스템에는 고유한 변화 존재

  • 위 그림에는 동시성 제어 및 복구 구성 요소 표현 X
  • 위 그림은 여러 가지의 가능한 architecture 중 하나
  • Query = Bring a Question
  • Buffer : 중간 임시 저장소
  • 위에서 아래로 component 기반 passing

 

 
 

Summary

  • DBMS : 대규모 datasets을 유지, 쿼리하는데에 사용
  • 장점 : 시스템 충돌로부터의 복구, 동시 액세스, 빠른 애플리케이션 개발, 데이터 무결성 및 보안 등
  • 추상화의 Level은 데이터의 독립성을 제공
  • DBMS는 일반적으로 Layered architecture을 가짐
  • DBA는 책임감 있는 업무를 수행하고 보수가 높음
  • DBMS R&D는 가장 광범위한 것 중 하나이며, CS에서 가장 흥미로운 분야

 

 

저작자표시