[데이터베이스] 1. Database and DBMS

Database

• 데이터의 효율적 관리와 사용을 위해 데이터 베이스

• 정렬, 분류
• 빠른 검색을 위해 사용한다.

Data and Information

• 데이터는 실세계의 값
• 정보는 유도된 유추된 사실들

• 그래프를 통해 더 나은 인사이트 도출이 가능함.

Types of Data

• 일시적인 데이터 : 프로그램 실행될 때만 휘발성 매체에 저장. (RAM)
• 지속적인 데이터 : 비휘발성 매체에 저장 (SSD, 하드디스크) (일반적인 데이터베이스)

Database with Data

• 관련된 데이터의 모임을 데이터베이스라 한다.
• 공통된 특성, 속성을 가짐
• 컴퓨터에 저장되어 조작 가능해야 함
• 데이터 처리 : Computation, insertion, deletion, Search, Sort, Analysis

Database Management System (DBMS)

• 데이터베이스를 관리하는 시스템(소프트웨어)

• 상용 DBMS
  

• 관여하는 사람들

1. 사용자: 데이터베이스 유저. End User 이라 함.
2. 응용 프로그램 개발자: 데이터베이스를 연결하는 앱을 개발하는 개발자.
3. 데이터베이스 관리자: DBA, 데이터베이스 관리감독, 감시. 데이터베이스 안의 데이터들을 정의.
4. DBMS 개발자: DBMS 시스템 자체를 개발하는 사람.

• 데이터베이스의 데이터들은 DBMS 를 통해 관리
• 프로그램을 통해 유저는 접근.
• DBMS 는 프로그램과 데이터베이스 연결 (DMBS개발자가 만드는 것)
• 데이터베이스는 DBA가, DBMS 는 DBMS 가 만듦.

File System vs DBMS

File System

• 운영체제라 생각하면 됨.

• 파일을 관리하는 시스템

• 프로그램은 저장장치에 저장된 파일에 접근하여 데이터를 읽음.

• 어떠한 문제가 있을까? 굳이 DBMS?

• 옥션, G마켓.. 등이 File1을 공유.

• File1의 수정. (동시에 오픈하여 각각 전화번호, 주소 수정)

• File system 의 문제: 동시에 똑같은 파일을 열었을 때 일관성이 사라지는 문제가 생김 (둘 중에 하나만 반영, 하나는 안됨)
  

• 동시접근의 문제라고도 함.

• File: 읽고 쓰기만

• DBMS: 읽고 쓰고 관리

File System 의 문제점

• Data redundancy and inconsistency(여기저기 산재, 중복)
• 데이터 접근의 어려움 (오직 파일을 통해서만)
• Integrity (제약 조건integrity constraint을 지정하기 어렵다)
• Atomicity (결함이 발생하면 일관성 깨질 수 있다, 오류 발생 시 데이터 합이 달라지는 경우)
• Security(데이터 접근 권한을 제어하기 어렵다)

DBMS가 이에 대한 해답을 제공한다.

Atomicity란?
트랜잭션(데이터베이스가 처리하는 하나의 일의 단위)이 지녀야 할 성질의 하나. 트랜잭션의 결함(수강신청 중 결함)의 상황에서도 연산의 결과가 모두 반영되든가(트랜잭션 완료) 아니면 전혀 반영되지 않아야(아예 반영이 되지 않아야) 한다.
파일 시스템은 이러한 기능을 제공하지는 않고, DBMS 만 제공한다.

View of Data: Levels of Abstraction

데이터의 추상화. : 사용자에게 저장된 방식, 유지 방법을 숨김.

데이터베이스에 저장되는 데이터의 종류 3가지.
1. physical level: 어떤 주소에 어떤 위치에 어떻게 저장되는지 나타내는 정보. - DBMS 개발자가 다루는 범위
2. Logical level: 어떤 데이터를 저장하며 어떤 관계가 있는지. 데이터의 타입도 정의. - DBA 관리자가 다루는 범위

(사진 수정: 아이디가 integer, city 가 string 이어야 함)
3. View level: 사용자에 따라 공개되어야 하는 데이터베이스의 정보. (학생과 교강사의 보여져야 하는 종정시 데이터 차이) - 사용자가 다루는 범위

• 하나의 데이터베이스는 여러개의 view 를 가질 수 있음.

DBMS - DBMS 개발자 - physical level - 어떤 위치에 어떻게 (저장 구조)
데이터베이스 - DBA - logical level - 데이터와 데이터 타입(종류)
사용자 - View level

한 번 더 정리

• physical level : 저장 구조
  애플리케이션, 사용자에게 숨김

• logical level : 데이터와 데이터 타입
  사용자에게 숨김, 애플리케이션 개발자는 알아야 함.

• View level : 사용자 프로그램 정보

View of Data : Schemas and Instances

• Schema 설계의 결과물.

• Instance 특정 순간에 저장되어 있는 정보의 모임.(매학기마다 수강인원, 수강자...)

• 스키마는 시간에 따라 변하지 않고(변수의 이름, 타입), 인스턴스(값)는 변함.

• Physical schema (내부 스키마)
  피지컬 레벨 데이터(위치)를 저장한 결과.
  물리적 구조와 실제 저장 방법을 정의. DBMS 개발자에 의해 정의.

• Logical schema (개념 스키마)
  로지컬 레벨 데이터의 설계 결과물.
  물리적 구조가 아닌 논리적 구조, 개체간 관계, 제약 조건, 접근 권한, 보안, 무결성 규칙. DBA 가 함.

• Sub schema (외부 스키마)
  view 를 정의

일반적인 스키마는 Logical Schema 를 의미.
physical data independence: 물리적 스키마 변해도 (스토리지, 위치가 변함) 논리적 스키마(논리구조, 관계...)를 변경할 필요가 없음.

전과를 해서 학생 정보를 옮겨도 학생 정보의 logical level 은 변화시킬 필요가 없음.

오른쪽 하단에 스토리지

• 서버와 가장 가까운 위치에 (physical schema)
• 사용자와 가장 가까운 위치에 (sub schema)
• 이들은 logical schema 에서 파생 (conceptual schema)

• 내부 스키마는 정보, 데이터 사이즈(바이트), 주소(offset) 가 있다.
• 개념 스키마에는 데이터 종류와 데이터 타입이 있다.
• 외부 스키마는 1, 2 가 있고 개념 스키마의 부분 집합으로 구성된다.

Data Models

데이터 모델이 정의하는 것들. (데이터, 관계, 의미...)
데이터 특징을 고려해 모델을 구성한다.

• 관계형 모델
• 디자인을 위해
• 객체지향 컨셉을 가져옴

Relational Model

• 테이블로 데이터, 관계 표시
• 레코드 기반 모델
• 테이블은 relation 이라 바꿔 부르기로 하자.

• logical level data 가 위에 있다. (종류)
• 이를 Attributes 라 한다.
• 행 하나하나는 레코드라 한다.

• 고객 정보 / 잔액 / 계좌
• attribute 가 많아지면 문제가 생기므로 위와 같이 쪼개자.

Entity-Relationshilp Model (개체-관계 모델)

• 개체와 개체 간의 관계를 이용하여 모델링
• 하나의 개체는 몇 가지 속성의 집합으로 정의.
  
• Relationship 은 개체와 개체간 관계. (학생과 교수)
• 관계를 여기선 그림으로 (Relational 에서는 테이블로)
  
• customer 과 account 개체 2개를 depositor 가 잇고 있고, 각 개체에는 여러 attribute 가 있다.

Database Design

• 설계의 결과물은 스키마
• Logical Design 논리설계
  attribure, type 을 정의.
• Physical Design 물리설계
  구조, 위치 정의

• logical 디자인이다.
• 일관성이 깨지는 문제가 발생했다. (dept_name, building 간)
• Mozart 정보를 삭제하면 음악 학과의 빌딩과 예산 정보가 없어진다.