database 기본 개념(Feat. data models, conceptual level, logical level, physical level, three schema architecture etc)

database system (줄여서 database라고도 부름)

= database(순수 데이터가 저장된 곳) + DBMS + 연관된 applications

 

data model : DB 구조(structure)를 추상화하여 표현하는 것
*DB 구조 : 데이터 유형, 테이터 관계(relationship), 제약 사항(constraints) 등등

data model의 분류(catagolizing) : 크게 3가지로 분류 가능

1] conceptual data models : 일반 사용자에게 DB 구조 이해시키기위한 수단

-> 비즈니스 요구 사항을 추상화하여 기술할 때 사용

ER diagram

*ER 다이어그램 : conceptual data models의 종류 중 하나. 

 

2] logical data models : 개발자들이 가장 많이 보는 data model이며 아래와 같은 특징 때문이다. 

->데이터가 컴퓨터에 저장될 떄의 DB 구조와 크게 다르지 않게 DB 구조화 가능(Physical data models) &&

특정 DBMS나 storage에 종속되지 않은 수준에서 DB 구조화 가능

 

relational data model

*  relational data model : logical data model의 한 종류로서 relation은 테이블을 의미.

-> 즉 relational data model은 테이블이라는 수단으로 DB 구조를 

 

대부분의 RDBMS는 relational data model을 이용하고 있으며 단, PostgreSQL DBMS는 object-relational data model을

사용(relational data model과 object data model을 혼합한 것이므로, 이 또한 relational data model을 사용한다고 말할 수 있다).

3] Physical data models : 저장 장치에 데이터가 실제로 저장되는 파일 형태(DB 구조)를 기술하는 수단

-> EX) data format, data orderings, access path 등등으로 파일 형태(DB 구조) 기술

 * Access Path: 데이터 검색을 빠르게 하기 위한 구조체(ex. index 등)

 

database schema 

data model이 DB 구조를 표현하기 위한 [수단]이였다면, database schema는 아래의 그림과 같이 data model을 바탕으

로 DB 구조를 [기술]한 것.

database schema

Logical data model의 한 종류인 relational data model, 즉 테이블이란느 수단으로 DB 구조(STUDENT 테이블 + BOOK 테이블)를 기술한 예시이다. 

 

three-schema architecture

DB(여기서는 physical database)로부터 user Application을 분리시키기 위해 만들어진 database system을 구축하는

architecture 중의 하나(대부분의 RDBMS는 three-schema architecture를 따른다고 한다).

* 여기서의 분리는 역할의 분리라고 생각하면 된다. user Application에서 physical database를 다루는 역할(ex. data foramt, data orderings, access path 등을 이용한 작업) 부분을 추상화하여, user application에서는 physical database에 대한 정보 없이 user application이 역할에만 충실하게 하였다. 

 

three-schema architecture

 

초창기의 database system architecure는 external schema와 Internal Schema, 이 2 레벨 체제였다. 

그러나 user application마다 요구되는 데이터가 다르다 보니 Internal Level에서 중복되는 데이터가 발생하는 문제가 있었

다. 

이러한 니즈를 만족시키고자 그 중복되는 부분(역할)을 추상화하여 conceptual schema가 탄생하였다. 

ex. A 클래스와 B 클래스 모두 C라는 repository 인터페이스를 의존하고 있다고 하자! 

그러나 A 클래스와 B 클래스는 서로 다른 repository 구현체를 주입 받아야하는 상황일 때, AppConfig 클래스에서는

동시에 C 인터페이스에 서로 다른 구현체를 주입시킬 수 없으므로, 어쩔 수 없이 2개의 AppConfig 클래스를 만들어 주는 

중복 문제가 발생. 이러한 중복 문제를 해결하고자 Front-AppConfig와 같은 추상화 클래스를 만들어 주어 AppConfig 클래

스가 중복되는 문제를 해결.