- Database: 정보를 필요에 따라 모아놓은 것. 조직이나 개인이 사용하는 조작 가능한, 저장된 데이터의 모임
- Data: 실세계의 실체를 묘사하는 값. 사실들 그 자체에 대한 일차적인 표현
Information: 데이터로부터 유도될 수 있는 유추된 사실들
- Types of Data
- Transient data: 해당 프로세스가 실행되는 동안만 일시적으로 존재. 휘발성 매체에 저장 (컴퓨터 메모리, RAM)
예: 프로그램의 변수
- Persistent data: 어떤 프로세스의 생명주기에 종속적이지 않고 스스로 존재. 비휘발성 매체에 저장 (SSD, HDD)
예: 입출금 내역 데이터
- 일반적인 DB는 지속적인 data의 집합을 뜻함.
- Database with data
- Database: 관련된 데이터의 모임 또는 집합
- Data in database: 일관되고 공통된 특성 (속성)을 가짐. 컴퓨터에 저장되어 조작 (처리) 가능해야 함.
- 데이터 처리 작업: Computation, insertion & deletion, search, sort, analysis
예: grading students, analyzing a product’s sales
- DBMS: 컴퓨터에 저장되는 DB를 관리해주는 software system
예: mysql, oracle
- DBMS에 관여하는 사람들
- User: accesses database by using application programs
- Application Programmer: develops application that users access.
예: 주문 배송 관리, 급여 관리, 경영자 정보 관리
- DBA (database administrator): manages, supervises, and manipulates DB and DBMS
예: DBMS를 통해 창고 관리
- DBMS Developer: designs and develops DBMS. 데이터 저장창고를 관리
- File System vs. DBMS
- File system: 운영체제의 일부로서 운영체제가 파일을 관리하는 시스템
예: 윈도우 환경에서 데이터를 담고 있는 대상은 파일, 파일 단위로 데이터가 관리됨.
프로그램은 저장장치에 저장된 파일에 접근하여 데이터를 읽고 씀.
데이터를 읽고 쓰는 기본적인 기능만 제공
- DBMS: 데이터를 읽고 쓰고 관리하는 다양한 기능을 제공
- File System의 문제점
- 동시 접근의 문제: 여러 프로그램이 동일한 파일에 접근하여 변경 -> 일관성이 사라짐.
예: 지마켓과 옥션을 동시에 열고 업데이트를 한다면 한 쪽에만 업데이트가 될 수 있음 -> inconsistency 발생
- Data redundancy & inconsistency: 중복되어 있어 일관성이 깨질 수 있음. 데이터가 여기저기 산재해 있다. 다른 파일에 정보가 중복되어 저장되어 있다.
- 데이터 접근의 어려움: 오직 파일을 통해서만 데이터에 접근할 수 있다.
- Integrity constraint 문제: 제약 조건을 지정하기 어렵다.
- Atomicity 문제: 결함 (fault)가 발생하면 데이터의 일관성이 깨질 수 있다. Transaction이 지녀야 할 성질의 하나. 시스템의 어떤 상황 하에서도 한 트랜잭션에 대한 모든 연산들의 결과가 DB에 모두 반영되든가 아니면 전혀 반영되지 않아야 함을 의미.
예: A계좌에서 B계좌로 이체하는 도중 오류가 발생하였는데, 오류를 수정하고 보니 두 계좌의 합이 바뀌는 상황
- Security 문제: 사용자마다 데이터 접근 권한을 제어하기 어렵다.
- DBMS offers solutions to all the above problems
- 데이터의 추상화: DB는 사용자에게 데이터가 저장된 방식 및 유지 방법 등의 자세한 내용을 숨김.
- Physical level: 데이터 저장 구조에 대한 정보. 데이터의 저장 방식. 어디에 저장? 어떻게 저장?
Abstracted (hidden) to programmers and users. Mainly, DBMS developer, or sometimes DBA
- Logical level: 데이터의 종류. DB에 어떤 데이터가 저장되어 있고 데이터 간에 어떤 관계가 있는가? DB에 저장되는 physical level과 view level을 제외한 모든 데이터
Abstracted (hidden) to users. Mainly, DBA. Sometimes for application developer & DBMS developer.
- View level: 사용자 프로그램 정보. 사용자에 따라 공개되어야 하는 DB의 정보는 무엇인가? 사용자에게 보여지는 응용 프로그램에 데이터의 형식과 같은 구체적인 정보는 드러나지 않음. 특정 정보는 공개되지 않음. user마다 define 가능. 하나의 DB는 여러 개의 view를 가질 수 있음
Mainly, application programmer, sometimes user requests
- View of Data
View level: logical level (모든 레벨의 데이터)의 부분집합. Logical data가 필요함. 사용자마다 관심 있는 view를 하나하나 정의
↑
Logical level (Hidden to users): 모든 종류의 data. DB에서 제일 중요함. DB 설계의 결과물. Logical data를 정의해야 함.
↑
physical level (Hidden to programmers)
- Schemas and Instances
- Schema: 전체적인 DB의 설계. Logical level의 데이터. DB의 핵심
- Instance: 특정 순간에 DB에 저장되어 있는 정보의 모임
- Instance는 시간에 따라 변하지만 Schema는 그렇지 않음. 나중에 logical level의 data를 바꾸는 데에 신중해야 함.
- 프로그래밍에서 선언된 변수의 경우
변수의 이름 및 타입 -> 스키마
프로그램 수행 중 특정 순간에서 변수의 값 -> 인스턴스
- Physical schema (내부 스키마, internal schema): physical level의 데이터를 설계한 결과물. DB의 물리적 구조를 정의, 데이터의 실제 저장 방법. 시스템 프로그래머, 시스템 설계자, DBMS 개발자에 의해 정의
- Logical schema (개념 스키마, conceptual schema): logical level의 데이터를 정리한 것. DB의 전체적인 논리적 구조, 개체간의 관계와 제약 조건, DB의 접근 권한, 보안, 무결성 규칙. DBA에 의해 구성.
- Sub schema (외부 스키마, external schema): 사용자 사용자나 응용 프로그래머가 각 입장에서 필요로 하는 view를 정의. User, Application developer에 의해 구성.
- 일반적으로 DB schema는 logical schema를 의미.
- Physical Data Independence: 물리적 스키마가 변해도 논리적 스키마를 변경할 필요가 없음.
예: 어떤 데이터의 저장 위치가 A disc에서 B disc로 변경되어도 논리적 스키마가 바뀔 필요가 없음.
예: Examples of schemas
외부 스키마 1 (Register’s office) -
ST – Name, Grade, Dept
외부 스키마 2 (student affair office)
STUDENT – Sno, Sname, Year, Addr
↓
개념 스키마 (logical schema) -> 내부 스키마 (internal schema)
Snumber, Name, Year, Grade… BYTE(4) OFFSET = 0
- Data Models: DB의 구조.
Data, Data relationships, Data semantics, Data constraints를 기술하기 위한 개념적 도구의 집합.
Relational model
Entity-Relationship data model (mainly for DB design) 개체 관계 모델
Object-based data models (객체 기반, 객체 관계 모델)
XML, Network model, Hierarchical model…
- Relational Model (관계형 모델): 테이블을 사용하여 데이터와 데이터의 관계를 모두 나타냄.
레코드 기반 모델. 고정된 형식의 레코드로 DB를 구성. 각 레코드는 여러 개의 필드 (또는 속성 attribute)로 구성.
스키마, logical level의 데이터. Logical schema가 define되어야 실제 data가 저장 가능함.
- ‘참고한다’ -> 종속되게. Account table이 depositor table에 의해 참고된다면, account table에 없는 값은 depositor table에도 없어야 함. 종속이 되는 table의 키가 참조됨. (account table의 account_num이 참조됨. Depositor table의 key는 customer_id)
- Entity-Relationship Model (개체-관계 모델): 개체와 개체 간의 관계를 이용하여 실세계를 모델링하는 방법.
- Entity: object의 의미를 지님, 다른 object와 구별되는 대상. 몇 가지 속성 (attribute)들의 집합으로 기술됨.
예: 고객 – 이름, ID, 주소 등의 attribute를 갖는 entity
- Relationship: 개체 간의 연관성을 나타냄.
예: 은행 계좌와 고객 간의 관계. 예금 또는 예금자 관계
- Entity-relationship diagram이라 불리는 그림으로 표현. attribute 중에 가장 중요한 attribute는 key
- DB design
- Logical Design (논리 설계) – DB schema (relation schema): 일반적이면서 필수적인 DB 설계. Relation을 정의하는 것. 즉 relation을 구성하는 attribute의 이름과 type을 정의. Table의 attribute를 정의. 가급적 한 relation에는 attribute를 적게 정의하는 것이 좋음. 테이블에 저장되는 데이터는 record
예: ID, name, salary, dept_name
- Physical Design (물리 설계) – DB의 physical layout을 정의: 저장 장치의 물리적인 구조. 특정 데이터의 저장 위치.
- DB languages
- DB의 데이터: physical, logical, view level의 data
- DDL (Data definition lg): to define schema. Relational model의 경우 table (relation)을 생성하는 것. Attribute를 정의하고 table을 생성.
- DML (Data manipulation lg): to search or define data in DB. (insertion / deletion / update)
- DDL
예: create table account (account-number char(10), balance integer)
- To create table, update data dictionary (i.e. metadata, the set of DB schema)
- To define storage structure and ways to access data
- To define integrity constraints
Domain constraints (도메인 제약 조건): Domain은 각 attribute에 저장될 수 있는 atomic value(single<->multi value)의 집합. (예: building attribute의 domain은 building 이름의 집합)
Table을 만들 때 설정됨. 새로 들어온 record가 조건을 만족시키지 않을 때 차단도 가능.
Referential integrity (참조 무결성): 두 relation을 연결하는 공통된 attribute 간의 참조 제약 조건
예: depositor relation의 account_number는 account relation의 account_number에 포함된 값이어야 함.
- To set authorization
- DML
- To deal with (manipulate – insertion, deletion, update – or search) data
- DML also known as query lg (질의어)
- DML의 종류
Procedural DML (절차적 DML): 사용자가 데이터 처리 (검색 등) 과정을 직접 지정.
예: A 데이터를 찾고, 다음 두 결과를 병합해라
Declarative DML (선언적 DML): 사용자는 데이터 처리 방법에 관여하지 않고 명령을 통해 결과를 얻음. 편리하지만, Procedural에 비해 비효율적일 수 있음
예: K, M, L relation에서 A 데이터를 찾아라
- SQL은 선언적 DML에 해당
예: select account.balance from depositor, account where depositor.customer_id =…
- DBA: DB를 설계하고 관리. 기관의 정보를 정확히 이해하고 있어야 함.
- They define and update DB schema
- They define access authorization
- They maintain DB
- DB system in functional view
- DBMS의 필수 기능 요소: storage management, query processing, consistent transaction processing (atomicity)
- Storage Management: Storage manager (저장 관리 프로그램)
DB에 저장되는 하위 레벨 데이터와 응용 프로그램 또는 질의 간에 인터페이스 제공. 신속 정확한 데이터 검색과 갱신을 위한 데이터 저장 관리
- Query Processing: Query processor (질의 처리기)
Parsing and translation (문법 분석과 변환 = compile) -> relational algebra expression (declarative DML: 사용자는 query만 입력. 찾는 과정의 절차는 기계가 알아서) -> optimizer (최적화된 질의로 변환. 가공하기) with statistics (최근에 가장 많이 access한 데이터를 보여주기 위해) -> execution plan -> evaluation engine with data -> query output
- Transaction Management
Transaction: DB 응용 프로그램에서 수행되는 연산들의 모임. DB에서 수행하는 과정 하나 하나. (예: 계좌 이체 트랜잭션, 입금 트랜잭션)
Transaction manager (트랜잭션 관리기): 트랜잭션 시작 전후 DB의 일관성 유지. (예: 계좌 잔액 유지) 트랜잭션 수행 도중 시스템 오류 (예: 전원 차단 상황) 발생시 transaction recovery를 통해 일관성 유지 (atomicity 유지)
병행제어 관리: 여러 트랜잭션이 병행으로 실행될 때 DB의 일관성 유지. Sequence (시차)를 두고 처리를 해야 함. (예: A계좌에서도 B계좌로 송금하고, C계좌에서도 B계좌로 송금할 때)
- History of DB System
1950s and early 1960s: magnetic tapes provide only sequential access
Late 1960s and 1970s: Edgar F. Codd defines the relational data model
1980s: SQL becomes industrial standard. Parallel and distributed DB systems
1990s: data-mining applications & large multi-terabyte
2000s: Big data storage systems Map reduce.
