CMU Andy Pavlo 교수님의 강의를 정리한 내용입니다.
#01 - Relational Model & Algebra (CMU Intro to Database Systems) - Andy Pavlo
파일 저장 방식의 문제점
데이터를 컴마로 구분된, 파일에 저장하면 어떤 문제점이 발생하는가?
그리고 이를 프로그래밍 언어를 통해 직접 파싱해서 다뤄야 한다면?
Data Integrity
-
만약 누군가가 year를 저장해야하는 곳에 Invalid String을 삽입하면?
-> 도메인 무결성 X -
하나의 앨범에 여러 아티스트가 존재하면?
-> 파일의 구조를 변경해야하고, 작성한 코드는 더 이상 사용할 수 없다. -
아티스트를 삭제한다면?
-> 앨범 파일에서의 삭제 처리를 보장할 수 있는가? -
동일한 아티스트가 여러 앨범을 만들었을 경우, 같은 아티스트임을 어떻게 보장할 수 있는가?
-> 참조 무결성 X
Implementation
-
특정 레코드를 어떻게 찾을 것인가?
-> 파일의 내용을 full-scan 해야만 한다. -
같은 데이터베이스를 사용하는 애플리케이션을 하나 더 만든다면? 그리고 그것이 서로 다른 Machine 에서 작동한다면?
-> 전체를 Copy, Paste? -
서로 다른 스레드에서 동시에 파일에 접근한다면?
Durability
-
레코드를 업데이트하는 도중 프로그램이 멈추면?
-> 트랜잭션 지원 X -
Replication 등을 활용해 고가용성을 지원할 수 있는가?
DBMS는 위와 같은 문제들을 해결하는 소프트웨어이다.
Data Models
Data Model은 데이터베이스에 데이터가 어떤 형식으로 저장되는지 묘사한 것.
Schema는 특정 Data Model을 기반으로 데이터의 형식을 표현한 것.
대부분의 DBMS는 관계형 모델이다.
Data Independence (데이터 독립성)
3단계 데이터 구조
-
Physical Schema
: 데이터의 물리적 저장구조를 정의한다 -
Logical Schema
: 데이터의 논리적 구조를 정의한다. -
External Schema
: 뷰등 사용자 관점에서 데이터베이스를 바라보는 관점을 정의한다.
관계형 모델의 구조적 핵심은 데이터 독립성이다.
데이터베이스의 테이블과 내용을, 물리적인 저장 방식과 독립적으로 다루는 것이다.
DBMS를 사용하는 애플리케이션 개발자는 데이터가 물리적으로 어떻게 저장되는지 알 필요가 없다. 개발자는 오직 high-level의 애플리케이션 로직에만 집중하면 된다. (추상화)
그에 따라 물리적인 저장장치가 변경되어도, 애플리케이션의 코드가 변경될 필요가 없다.
-
Physical Data Independence(물리적 데이터 독립성)
: Physical Schema(데이터의 물리적 저장방식)가 변경되어도 Logical Schema에 영향을 주지않는다. 데이터베이스의 논리적 구조를 변경하지 않고도 저장 장치를 변경할 수 있다. -
Logical Data Independence(논리적 데이터 독립성)
: Logical Schema(논리적 구조)가 변경되어도, External Schema(애플리케이션에서의 사용)에 영향을 주지 않는다. 애플리케이션의 코드를 변경하지 않고도 데이터베이스의 논리 구조를 변경할 수 있다.
Document Data Model
Document Data Model은 Object와 Relation의 불일치를 피하기 위해 등장했다.
객체와 데이터베이스를 강하게 결합하는 방식이다.
Relational 모델은 위와 같이 Artist와 Album 간의 관계를 맺고, ArtistAlbum 테이블을 생성하는 방식으로 데이터를 저장한다. 하지만 이러한 방식은 객체지향의 세계와 일치하지 않는다.
객체지향에서는 참조자를 통해 다른 객체를 포함하지만, 관계형 모델은 외래키를 통해 테이블을 조인해야만 한다.
조인에는 많은 비용이 소모되고, Document Model을 고안한 사람들은 이러한 조인 비용이 좋지않다고 생각했다(교수님 왈)
Document 모델은 객체지향에서 한 객체가 다른 객체를 포함하듯이, 데이터를 저장한다.
마치 Artist 객체가 Album 객체의 리스트를 포함하듯, Artist 내부에 Json Document 형식으로 데이터를 저장한다.
조인 비용이 소모되지 않으므로, 빠른 데이터 접근이 가능하다.
Document 모델의 문제점
하지만 이러한 방식은 어떤 문제점이 있을까?
-
데이터 중복
: 하나의 앨범이 여러 아티스트가 작업했다면? 각 아티스트마다 동일한 앨범정보가 포함될 것이다. -
추상화 X
: 내 애플리케이션이 데이터를 다루기 위해 데이터 구조를 잘 알아야한다. 즉, 추상화가 되지 않는다. 데이터 구조가 변경되면 애플리케이션 코드도 변경되어야 한다.
