1.DB
2.DBMS
3.DB system
4.data models
5.schema & state
6.three-schema architecture
7.database language
database (DB)란?
전자적으로(electronically) 저장되고 사용되는 관련있는 데이터들의 조직화된 집합(organized collection)이다.
여기서 관련있는 데이터의 의미는 같은 출처, 같은 목적, 같은 서비스 안에서 생성되는 데이터를 말한다.
이렇게 관련있는 데이터들을 조직화된 집합으로 묶어야 한다.
데이터를 잘 조직화 하면 찾고자 하는 데이터를 빠르게 찾을 수 있도록 해주고, 불필요한 데이터가 중복 생성되는 것을 막을 수 있고, 데이터의 불일치 또한 막을 수 있다.
그러므로 데이터는 조직화된 집합으로 관리되어야 한다.
마지막으로 이러한 데이터들을 전자적으로 저장하고 활용할 때 즉 컴퓨터에 저장되고 사용될 때 이것을 database (DB)라고 한다.
DBMS란?
ex) 여러 명의 예금 계좌 정보를 모아 놓은 데이터베이스에 여러 명이 동시 접속하는 것을 가능하게 해주는 것이 DBMS
database management systems의 약자로
데이터베이스를 사용하려는 사용자에게 DB를 정의하고 만들고 관리하는 기능을 제공하는 소프트웨어 시스템이다.
대표적으로 PostgreSQL, MySQL, Oracle Databese, Microsoft SQL Server가 있다.
DB를 정의하다 보면 부가적인 데이터가 발생하는데 이러한 것을 metadata(data about data-데이터를 설명하기 위한 데이터)라고 한다.
예를 들어 사진을 찍으면 사진의 해상도가 얼마인지 포맷이 무엇인지 언제 찍혔는지 등 사진의 부가적인 정보를 담고 있는 데이터는 사진을 설명하는 데이터이다.
metadata는 database를 정의하거나 기술하는 data로
catalog라고 부르기도 하고 metadata가 저장되는 곳을 catalog라고 부른다.
metadata에는 데이터 유형, 구조, 제약 조건, 보안, 저장, 인덱스, 사용자 그룹 등이 들어간다.
metadata도 DBMS에 저장되고 관리된다.
database system
database+DBMS+연관된 applications
(줄여서 database라고 부르기도 함)
Application Program을 만들었을 때 DB에 접근하기 위한 여러가지 쿼리들이 있는데 쿼리는 데이터베이스에 접근해서 원하는 데이터를 가져오거나 원하는 형태로 데이터를 수정하도록 요청할 수 있다. 매니지먼트 시스템은 이러한 쿼리를 받으면 의미를 해석하고 요청을 처리한다. 요청된 데이터가 어떠한 형태로 되어있는지 부가적인 정보를 확인하고 그것을 바탕으로 실제 요청받은 데이터를 찾아서 Application에 돌려주는 형태로 동작한다. 위와 같은 과정은 database system이 동작하는 방식이다.
data models
DB의 구조(structure)를 기술하는데 사용될 수 있는 개념들이 모인
DB 구조를 추상화해서 표현할 수 있는 수단을 제공(모델링이라고 생각하면 됨, 원하는 형태로 원하는 추상화 수준으로 모델링)
data model은 여러 종류가 있으며 추상화 수준과 DB 구조화 방식이 조금씩 달라짐
DB에서 읽고 쓰는 기본적인 동작(operations)도 포함
data model categories
1.conceptual(or high-level) data models
-일반 사용자들도 쉽게 이해할 수 있는 개념들로 이루어짐
-추상화 수준이 가장 높음
-비즈니스 요구 사항을 추상화하여 기술할 때 사용
ex)entity-relationship model
데이터 베이스의 구조를 entity와 entity들의 관계를 모델링 (Student와 Course가 entity)
2.logical(or representational) data models
-이해하기 어렵지 않으면서 디테일하게 DB를 구조화 할 수 있는 개념 제공
-데이터가 컴퓨터에 저장될 때 구조와 크게 다르지 않게 DB구조화 가능
(실제 물리적 저장 장치에 저장될 때)
-특정 DBMS나 storage에 종속되지 않는 수준에서 DB 구조화 가능
(어느 정도 추상화 가능, 백엔드 개발자는 logical data model을 많이 사용)
ex)relational data model
쉽게 말하면 table에는 low(데이터 각각) column(속성,Attribute)이 있는데 이렇게 table형태로 저장을 하고 relational data model이라고 부른다.
이외에도 object data model(객체 개념을 이용), object-relational data model(relational data model+object data model)이 있다.
Oracle, MySQL, SQL Server 모두 relational data model 사용, Postgre SQL은 object-relational data model 사용
3.physical(or low-level) data models
-컴퓨터에 데이터가 어떻게 파일 형태로 저장되는지 기술할 수 있는 수단 제공
(데이터가 저장 장치에 저장되는 실제 형태에 가장 근접)
-data format, data orderings, access path 등등
-access path는 데이터 검색을 빠르게 하기 위한 구조체 e.g.)index
database schema
-data model을 바탕으로 database의 구조를 기술한 것
-schema는 database를 설계할 때 정해지고 한번 정해지면 자주 바뀌지 않음
ex)STUDENT와 BOOk은 어떠한 속성(Attribute)를 가지는지 기술해놓은 것
database state
-database에 있는 실제 데이터는 꽤 자주 바뀜
-특정 시점에 database에 있는 데이터를 data state or snapshot이라고 함
-혹은 database에 있는 현재 instances의 집합
(시간의 흐름에 따라 데이터가 바뀌거나 수정 or 삭제되기 때문에, 각 시점마다 달라질 수도 있고 같을 수도 있음)
three-schema architecture
-database system을 구축하는 architecture중 하나(대부분 이걸 따라감)
-user application으로 부터 물리적인 database를 분리시키는 목적
(물리적인 구조가 조금씩 바뀔 때가 있는데 이때 user application에는 영향을 끼치지 않기 위해 three-schema architecture를 사용함)
-세 가지 level이 존재, 각각의 level마다 schema가 정의되어 있음
1.external schemas at external level
2.conceptual schemas at conceptual level
3.internal schemas at internal level
internal schema는 물리적인 저장 장치에 가장 가깝게 있음
(물리적으로 데이터가 어떻게 저장되는지 physical data model을 통해 표현/data storage, data structure,access path 등 물리적으로 실체가 있는 내용을 기술)
external schema는 사용자가 바라보는 schema
(external views, user views라고도 불림/특정 유저들이 필요로 하는 데이터만 표현, 알려줄 필요 없는 데이터는 숨김/logical data model을 통해 표현)
->초창기에는 internal과 external만 존재하여 각각의 유저마다 필요로 하는 데이터가 달라졌 을 때 중복되는 데이터가 발생! 중복 internal schema가 생기니까 관리가 힘들어지고 데이터 불일치 발생)
-->이러한 문제를 해결하기 위해 conceptual schema 등장
conceptual schema
(한번 추상화 시켜서 표현)
전체 database에 대한 구조를 기술
물리적인 저장 구조에 대한 내용 숨김
entities, data types, relationships, user operations, constraints에 집중
logical data model을 통해 기술
three-schema architecture는 각 레벨을 독립시켜서 어느 레벨에서의 변화가 상위 레벨에 영향을 주지 않게 함(conceptual, internal 사이의 mapping만 바꿔주면 됨, 안정적)
internal과 conceptual이 영향 받지 않게 만드는 것보다 conceptual과 external이 영향 받지 않게 만드는 것은 상대적으로 어려움
오늘날 대부분 DBMS가 three level을 완벽하게 혹은 명시적으로 나누지X
데이터가 존재하는 곳은 internal level
data definition language(DDL)
-conceptual schema를 정의하기 위해 사용되는 언어
-internal schema까지 정의할 수 있는 경우도 존재(언어를 가지고 정의하는 것 보다 파라미터를 통해 정의)
storage definition language(SDL)
-internal schema를 정의하는 용도로 사용되는 언어
-relation DBMS에서는 SDL이 거의 없고 파라미터 등의 설정으로 대체
view definition language(VDL)
-external schemas를 정의하기 위해 사용되는 언어
-대부분의 DBMS에서는 DDL이 VDL 역할까지 수행
data manipulation language(DML)
-database에 있는 data를 활용하기 위한 언어
-data 추가, 삭제, 수정, 검색 등의 기능을 제공
통합된 언어 SQL
DML, VDL, DDL이 따로 존재하기 보다는 통합된 언어로 존재하는데
대표적인 예가 relational database language로 SQL
References
시니어 백엔드 개발자가 알려주는 데이터베이스 개론 & SQL
https://www.inflearn.com/course/%EB%B0%B1%EC%97%94%EB%93%9C-%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EA%B0%9C%EB%A1%A0/dashboard
oracle DB
https://www.oracle.com/kr/database/what-is-database/
혼공 데이터베이스 이해하기
https://hongong.hanbit.co.kr/%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B2%A0%EC%9D%B4%EC%8A%A4-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-databasedb-dbms-sql%EC%9D%98-%EA%B0%9C%EB%85%90/
https://www.researchgate.net/figure/Simplified-database-system-Risunok-1-Uprosennaa-sistema-baz-dannyh-Slika_fig1_326006960
DBMS Tutorial
https://www.tutorialspoint.com/dbms/relational_data_model.htm