[컴퓨터과학 개론] 13강 - 데이터베이스(1)

✅ 1. 데이터베이스 개념

(1) 데이터 처리 개념

[ 데이터 ]

• 관찰이나 측정을 통해 현실 세계에서 단순히 수집된 사실이나 값을 의미함.
• 데이터는 적절한 처리를  거쳐야만 정보로써 가치를 지니게 된다.

[ 정보처리 시스템 ]

• 한 기관에서 데이터를 수집, 조직, 저장하고 정보를 생성, 분배하는 시스템
• 쉽게말해, 데이터를 입력받아 처리(가공) 하고, 그 결과를 정보로 산출하는 시스템을 의미한다.
• 이러한 정보처리 시스템을 구현하기 위해서는 여러 기술이 필요함. ( 운영체제, 네트워크 기술, 앱로직, 보안 ... 등 )
• 이러한 기술 중에서 방대한 데이터를 효과적으로 저장하고 운영하기 위한 기술인 데이터베이스를 배우는것임.
• 즉, 정보처리 시스템에서 한 축을 담당하고 있는 것이 이 데이터베이스임. -> 1960 년대에 등장함.

(2) 파일 처리 시스템

• 데이터베이스 등장 이전에 데이터 저장 및 처리를 하기 위해서 파일 처리 시스템을 이용함.
• 파일 처리 시스템은 파일 단위(파일 중심)의 데이터 저장 및 처리를 해주는 시스템임.

[ 파일 처리 시스템 - 특징 ]

• 각 응용 프로그램이 특정 응용을 위해 필요한 파일을 독립적으로 소유/관리를 하는 형태임.
• 즉, 각 응용 프로그램은 파일의 논리적 구조와 물리적 구조가 대응되도록 구현이 되어있는 형태임.

[ 파일 처리 시스템 - 문제점 ]

• 해당 파일 처리 시스템의 문제는 위와 같이 급여, 세금정산, 퇴직금과 같은 프로그램이 있을때 급여를 통해서 세금정을 할 수 있고 이후 퇴직금을 처리 할 수 있지만, 각각 데이터파일이 나눠져 있기 때문에 데이터 종속성과 중복성에 대한 문제가 발생함.
• 데이터 종속성: 응용 프로그램과 데이터 사이에 1:1 상호 의존 관계가 존재함.
• ( 파일 구성 요소, 접근 방식 등이 변경되면 해당 응용 프로그램도 함께 변경을 해줘야하는 종속적인 문제점이 있음. )
• 데이터 중복성: 한 시스템에 동일한 데이터가 여러 개 존재 할 수 있음.
• ( 일관성, 보안성, 경제성, 무결성의 문제가 발생 할 수 있음. )
• 결론: 이러한 파일 처리 시스템의 문제점 때문에 데이터베이스가 만들어짐.

(3) 데이터베이스 개념

• 기존 파일 처리 시스템은 응용 프로그램과 데이터파일 간의 1:1 관계를 가지고 있음.
• 하지만, 데이터베이스는 데이터를 한 곳에 보관함으로써 응용 프로그램과 데이터간의 1:N 의 관계를 가짐. ( 데이터의 공용 )

(4) 데이터베이스 정의

• 한 조직의 여러 응용 시스템이 공유해서 사용하기 위한 통합, 저장, 운영 데이터의 집합을 데이터베이스로 정의함.

[ 공유 ]

• 여러 응용 프로그램이 공동으로 소유하고 사용하는 데이터를 의미하는 개념임.

[ 통합 ]

• 중복된 데이터를 배제하여 각 데이터의 일관성을 유지하는 개념임.
• 단, 중복의 완전한 배제가 아닌 시스템의 성능 향상을 위한 제한적인 중복이 있을 수 있음.

[ 저장 ]

• 컴퓨터가 접근 가능한 저장매체에 저장된 데이터를 의미하는 개념임.

[ 운영 ]

• 어떤 조직의 목적과 유용성 측면에서 반드시 유지해야 할 데이터를 의미함.
• 즉, 일시적으로 필요한 데이터를 제외한 클라이언트측에서 저장 할 데이터로 유지해야 할 데이터로 볼 수 있음.

(5) 데이터베이스 특징

[ 실시간 접근성 ]

• DB에 수시로 접근하는 사용자의 요구를 즉시 처리하여 응답을 제공하는 실시간 접근성의 특징을 가짐.

[ 계속적인 변화 ]

• 삽입/삭제/갱신 등의 연산을 통해 새로운 데이터로 내용을 지속적으로 변화를 시키는 특징을 가짐.
• 즉, 계속적인 변화에 대응 할 수 있는 유지력의 능력을 가지고 있다는 의미임.

[ 동시 공유 ]

• 서로 다른 목적을 가진 여러 사용자가 동시에 원하는 데이터에 접근 할 수 있는 특징임.

[ 내용에 의한 참조 ]

• 데이터가 저장된 위치나 주소가 아닌 내용/값에 따라 데이터를 참조할 수 있게 도와주는 특징임.

(6) 데이터베이스 - 기존 파일 처리 방식에서 향상된 특징

[ 데이터베이스의 자기 기술성 ]

• DB 시스템은 DB 자체뿐만 아니라 DB에 대한 정의/설명까지 포함하고 있음.
• DB에 속하는 각 파일의 구조, 각 항목의 타입과 저장 형식, 데이터의 제약 조건 등이 시스템 카탈로그에 저장이 됨.
• 쉽게말해, 데이터베이스는 단순히 데이터를 저장하는 것뿐 아니라, 그 데이터가 어떤 구조로 되어있는지도 함께 저장함
• 데이터 구조나 제약조건 정보까지 DB 안에 포함이 된다는 의미임.
• ( 학생 테이블 - 컬럼: 이름(VARCHAR), 나이(INT), 학번(UNIQUE) )

[ 프로그램-데이터 독립성 ]

• 데이터 파일 구조에 대한 정보가 응용 프로그램으로부터 분리되어 관리가 됨.
• 즉, 종속성과 중복성의 문제를 해결하게 됨.

[ 데이터 추상화 ]

• 사용자에게 데이터 저장 방식에 대한 상세 정보보다 데이터에 대한 개념적 표현을 제공 보다 용이한 데이터 접근 가능.
• 즉, 사용자가 데이터의 물리적 저장 구조를 몰라도, 개념적 구조만으로 데이터를 다룰 수 있게 하는 데이터베이스의 특징임.

[ 다중 뷰 제공 ]

• DB에 대한 여러 사용자의 서로 다른 관점의 데이터 요구에 따라 각자의 필요한 부분만을 선별적으로 추출해서 보는 기능
• 쉽게말해, 여러 사용자가 같은 DB를 쓰더라도, 각 사용자가 필요한 데이터만 따로 볼 수 있도록 해주는 기능임.

[ 데이터 공유 ]

• 여러 사용자가 동시에 DB에 접근할 수 있는 기능을 제공함. ( 동시 접근은 데이터 공유로 볼 수 있음. )

[ 다수 사용자의 트랜잭션 처리 ]

• 동시성 제어(병행 제어) 기능을 통해 다수 사용자가 동일 데이터를 동시에 변경하는 경우에도 데이터의 일관성을 보장해줌.
• 쉽게말해, 다수가 DB 동일 데이터 접근 후 수정을 해도 트랜잭션 기능을 제공해서 일관성을 보장해줌.

(7) 데이터베이스 장단점

• 위의 기존 파일 처리 방식에서 향상된 특징 외에도 DB에는 다양한 장점이 존재하는 반면 단점도 존재함.

---

✅ 2. 데이터베이스 시스템

• 데이터를 데이터베이스에 저장하고 관리해서 필요한 정보를 생성하는 컴퓨터 중심의 시스템을 의미함.

[ 데이터 베이스 시스템 구성요소 ]

• 데이터베이스
• 데이터베이스 관리 시스템
• 데이터 언어
• 데이터베이스 사용자
• 데이터베이스 관리자
• 데이터베이스 기계

(1) 데이터베이스 구조

• 1975년 미국 표준 협회 ANSI와 SPARC 위원회의 제안으로 데이터베이스 아키텍처(3단계 스키마 구조)로 데이터베이스 시스템을 세 가지 관점(외부, 개념, 내부)로 나누어 정의한 모델임.
• DBMS 사용자와 관리자가 "데이터를 논리적, 물리적으로 어떻게 구분해서 다룰까"를 설명하는 개념 모델임.
• 단계(level): 데이터를 바라보는 관점(계층)이다. 즉, 데이터베이스를 바라보는 관점을 의미함.
• 스키마(schema): 단계의 구체적인 구조 정의서(설계도) 이다. 즉, 단계의 관점에서 정의된 데이터 구조(설계 내용) 를 의미함.
• ( 스키마는 실제 물리적 구현물이 아닌 "데이터베이스 구조를 정의한 설계(관점) 임. )
• ( 스키마는 형태, 구조, 틀을 의미함. )
• 이러한 구조 아키텍처의 목적은 데이터의 독립성을 높이는데 있음.
• 정리하면, 단계는 관점이고 스키마는 관점에 대한 실제 데이터 구조를 의미함.

[ 외부 단계, 개념 단계, 내부 단계 ]

[ 스키마 개념 예시 ]

• 스키마는 설계 단계이지, 구현 단계가 아님 즉, 설계 단계의 관점으로 보는 것임.
• 이렇게 3단계 구조로 나누는 이유는, 논리적 구조와 물리적 구조를 분리해서 서로 영향을 주지 않고 독립적으로 변경할 수 있게 하여 데이터 독립성을 보장하기 위해서임. ( 설계 방식임 )

[ 외부 스키마 - 사용자 관점의 DB 구조 ]

• 사용자나 응용 프로그램이 보는 부분적 논리 구조로 이며 개별 사용자/응용 프로그래머가 관심을 두는 DB 일부분만 기술함.
• 각 사용자(응용 프로그램)가 필요로 하는 데이터만 볼 수 있게 정의한 DB 논리적 구조로도 볼 수 있음.
• 쉽게말해, 사용자가 필요한 데이터만 SQL 질의로 보는 관점으로 볼 수 있음.
• 예시로는, 학생 이름을 조회하면 학생 테이블 중 일부 컬럼인 학생 이름만 보여줌.
• 즉, 외부스키마는 여러 사용자가 사용을 하기 때문에 필요한 정보가 다름. 즉, 여러개가 존재할 수 있다는 의미임.

[ 개념 스키마 - 전체 DB의 논리적 구조 ]

• 조직 전체의 데이터 구조(테이블, 속성, 관계, 제약조건 등)를 논리적으로 설계한 것임. ( 외부랑 다르게 하나만 존재함 )
• 모든 사용자 관점으로 통합된 구조이며, DB 설계의 핵심 그리고 ER 다이어그램 설계 단계가 여기에 해당됨.

[ 내부 스키마 - 저장 관점의 DB 구조 ]

• 데이터가 실제로 저장되는 물리적 구조(파일 구조, 인덱스, 저장방식 등)를 정의한 설계 단계임.
• 예를들면, B-tree 인덱스 사용 여부, 저장 공간 최적화, 접근 속도 등에 대한 설계 단계임.
• 물리적 저장 장치(하드웨어) 관점으로 볼 수 있지만, 관리 주체는 디스크/OS 가 아닌, DBMS 엔진 관점이다.
• 즉, 하드웨어 물리 계층인 물리적 레코드(페이지, 블록)와 저장장치의 특성(실린더, 트랙)은 고려하지 않음.
• DBMS 엔진 관점으로 파일 구조, 페이지 단위 저장, 인덱스, 버퍼링, 블록 접근 방식 등을 고려함.

[ 외부 스키마, 개념 스키마, 내부 스키마 정리 ]

• 외부 스키마는 여러개 존재 할 수 있으며, 각기 다르게 필요한 정보를 정의해서 개념 스키마를 통해 데이터를 가져갈 수 있음.
• 즉, 여러 응용프로그램(사용자 관점)에서 필요한 데이터를 개념 스키마의 관점에서 가지고 온다고 보면 됨.
• 개념 스키마는 위와 같이 하나가 존재하며, 기관 전체에서 사용하는 데이터베이스로 볼 수 있음.
• 내부 스키마는 실제로 저장 될 때 위와 같은 형태로 저장이 되는 것을 나타낸 것이라고 보면 됨.
• 즉, 외부 스키마로 개념 스키마에 접근해서 데이터를 조회 및 삽입하는데 결과는 내부 스키마 형식으로 저장이 된다고 봄.
• OSI 7계층처럼 하위 단계의 복잡함을 상위 단계에서 숨겨주는 구조적 추상화 모델로 볼 수 있음.

(2) 데이터베이스 구조 - 각 단계의 사상

[ 외부/개념 사상 - 논리적 데이터 독립성 ]

• 특정 외부 스키마와 개념 스키마 사이의 대응 관계를 정의함.
• 응용 프로그램에 영향을 주지 않고 DB의 논리적 구조의 변경이 가능
• 하나의 논리적 구조로 많은 응용 프로그램이 요구하는 다양한 형태의 논리적 구조를 제공 할 수 있음.
• 외부/개념 사상을 통해 논리적 데이터 독립성을 보장 할 수 있음.

[ 개념/내부 사상 - 물리적 데이터 독립성 ]

• 개념 스키마와 내부 스키마 사이의 대응 관계를 정의함
• 논리적 구조에 영향을 주지 않고, 실제 데이터에 대한 저장 양식의 변경이 가능함.
• 하나의 논리적 구조로 여러 가지 상이한 물리적 구조의 지원이 가능함.
• 개념/내부 사상을 통해 물리적 데이터 독립성을 확보 할 수 있음.

[ 데이터 독립성 보장 ]

• 이런 사상을 통해서 데이터의 독립성을 보장하기 때문에, 데이터를 쉽게 공유해 사용 할 수 있음.

---

✅ 3. 데이터베이스 관리 시스템

(1) 데이터 관리 시스템 - DBMS (DataBase Management System)

• DBMS 는 응용 프로그램이 데이터베이스를 공용할 수 있도록 관리해주는 소프트웨어 시스템이다.
• 사용자와 데이터베이스 사이에 위치하여, DB의 구성, 접근 방법, 관리 유지 등에 관한 모든 책임과 권한을 갖고 모든 기능을 통합적으로 수행하여 사용자의 요구에 맞는 정보를 생성해 주는 소프트웨어이다.
• 쉽게말해, 데이터베이스와 DBMS 는 다른 프로그램으로 볼 수 있으며, 데이터베이스 회사에서 DB 설치시 DBMS 도 같이 설치시 같이 설치 되도록 제공을 하고 있음.
• 목적: 응용 프로그램이 데이터에 종속되지 않는 데이터의 독립성 제공해 데이터 공유를 하기 위함임.

(2) 데이터 관리 시스템 - 작업 과정 예시

[ 개념적인 수준의 작업 과정 - 관계형 DBMS ]

• (1) 사용자는 SQL 과 같은 언어를 이용하여 데이터에 대한 접근을 요구를 함.
• (2) DBMS가 요구를 받아서 분석을 하게 됨.
• (3) 외부스키마, 대응하는 외부와 개념 스키마 접속
• (4) 개념 스키마, 개념과 내부 스키마 접속
• (5) 기억장소 구조 정의 순으로 차례대로 검토
• (6) 저장된 데이터베이스에 필수적인 연산 수행

(3) 데이터 관리 시스템 - DBMS 필수 기능

• 데이터베이스 관리 시스템(DBMS)이 DB에 대한 모든 접근에 관리를 하고 통제를 하기 위해서 필요한 기능들이 있음.
• ***DBMS에는 아래와 같은 필수적인 기능인 정의, 조작, 제어 크게 3가지 필요함.***

[ 정의 definition ]

• 물리적으로 구현된 하나의 DB 구조로부터 여러 사용자들의 다양한 요구에 부응할 수 있도록 가장 적합한 DB 구조를 정의하는 기능을 필요로 함. ( SQL 문 - DCL, DDL , DML, TCL )

[ 조작 manipulation ]

• 사용자와 DB 사이의 상호작용을 위한 수단으로 사용자가 연산 지원 도구를 통해 DB에 체계적으로 접근하고 조작할 수 있는 기능(삽입, 삭제, 조회 등)을 필요로 함. ( SQL 문 - DCL, DDL , DML, TCL )

[ 제어 control ]

• 공용 목적으로 관리되는 DB의 내용을 정확하고 안전하게 유지시키는 기능
• 데이터 무결성 유지(트랜잭션), 보안 유지 및 권한 검사, 동시성 처리 등 ( SQL 문 - DCL, DDL , DML, TCL )

[ 정리 ]

• 위와 같은 정의, 조작, 제어의 기능은 DBMS 에서는 필수적인 개념으로 볼 수 있음.
• 이러한 개념을 기능으로써 구현하고 데이터 언어(SQL)을 통해 그러한 기능을 개발자가 사용 할 수 있게 해줌.

(4) 데이터 관리 시스템 구성요소 - 데이터 언어

[ 데이터 언어란? ]

• DBMS와의 통신을 하기위한 수단을 데이터 언어로 볼 수 있음 ( SQL 로 불림 )
• 데이터언어는 기능과 목적에 따라 데이터 정의어, 데이터 제어어, 데이터 조작어로 나눌 수 있음.
• 별도 언어로 존재하기 보다는 하나의 통합된 언어 속에서 기능적으로만 구분이 됨.
• 쉽게말해, DDL, DML, DCL이 각각 다른 언어가 아닌, SQL 이라는 한 언어 안에 기능별로 나눠져 있다는 뜻을 내포함.

[ 데이터 정의어 - DDL, Data Definition Language ]

• DB의 구조, 데이터 형식, 처리 방식 등을 정의하는 언어이다.
• 개념 스키마를 정의하기 위해서 주로 사용이 됨. ( 즉, 테이블, 컬럼 등을 정의하기 위해서 사용 )
• 데이터베이스 설계자 또는 관리자가 주로 사용을 함.
• 예시: CREATE(테이블, DB, 인덱스 생성), ALTER(테이블 구조 변경), DROP, TRUNCATE 등
• 또한, 외부 스키마를 정의하기 위한 언어로 "뷰 정의어", 내부 스키마를 정의하기 위한 언어로 "기억장소 정의어" 도 있음.

[ 데이터 제어어 - DCL, Data Control Language ]

• 여러 사용자가 데이터를 공유해서 정확하고 안전하게 사용하도록 데이터 제어를 정의하고 기술하는 언어이다.
• 데이터베이스 관리자가 사용해서 데이터 보안, 무결성, 데이터 회복, 동시성 제어 등 관련 명령어를 통해 데이터를 관리함.
• 대개 사용자 권한과 접근 제어를 다루는 명령어로 볼 수 있음.
• 예시: GRANT(사용자에게 권한 부여), REVOKE(권한 회수) 등이 있음.

[ 데이터 조작어 - DML, Data Manipulation Language ]

• DB에 대한 검색, 수정, 삽입, 삭제 등의 조작을 위한 언어이다.
• 절차적 데이터 조작어: 필요한 데이터를 어떻게 구하는 지를 구체적으로 명시해야 하는 조작어이며, 응용 프로그램 속에 삽입되어 사용이 된다. ( 한 번에 하나의 레코드를 검색하거나 처리함 ) -> 저수준의 데이터 조작어로 볼 수 있음.
• 비절차적 데이터 조작어: 어떻게 구하는 지는 명시하지 않고, 어떤 데이터가 필요하지만을 명시해서 조작 할 수 있으며, 선언적 언어 또는 고수준 데이터 조작어로 볼 수 있음. ( 질의어, SQL이 이에 해당 할 수 있음. )
• 정리하면, RDB는 비절차적인 선언적 모델을 기반으로 만들어졌지만, 내부적으로는 어떻게 할지 절차적으로 DBMS가 스스로 결정을 하게 됨. 하지만, 확장 기능을 통해 절차적 방식으로도 데이터 조작이 가능함. 그리고, 비절차적 방식은 결국 DBMS가 내부적으로는 절차적으로 실행을 하기 때문에 내가 원하는 성능을 내기 위해 세밀한 성능 제어나 복잡한 로직이 필요한 경우에는 절차적 DML을 사용할 수 있음.

(5) 데이터 관리 시스템 구성요소 - 데이터베이스 사용자

• DB에 접근하는 사람의 총칭이며, 업무에 따라서 일반 사용자, 응용 프로그래머, 데이터베이스 관리자 3개로 나뉨.
• 일반 사용자: SQL과 같은 질의어를 통해 데이터 조작(검색, 삽입, 수정 등)을 목적으로 단순히 DB에 접근하는 사람
• 응용 프로그래머: 일반 호스트 언어(Java, C)와 데이터 부속어(Java JPA Code)를 통해 DB에 접근하는 사람
• 데이터베이스 관리자: 데이터베이스 시스템의 별도의 한 구성요소로써 취급이 됨.

(6) 데이터 관리 시스템 구성요소 - 데이터베이스 관리자

[ 데이터 베이스 관리자 DBA, DataBase Administrator ]

• DDL과 DCL을 통해 DB를 정의하고 제어할 목적으로 접근하여 관리하는 사람이다.
• 데이터를 여러 사람이 공용할 수 있도록 관리하고 제어하는 사람이다.
• 조직의 모든 전산 업무, DBMS, 관련 HW/SW 등에 대한 상당한 지식이 요구가 된다.
• DB에 대한 접근 권한 설정, 제작과 갱신, 보전과 관리, 운영 및 통제, 성능 측정 및 변경 요구에 대한 응답 등의 의무를 가짐.

(7) 데이터 관리 시스템 구성요소 - 데이터베이스 컴퓨터

• DB 관리 기능을 효율적으로 수행할 수 있도록 특화되어 설계된 하드웨어 및 소프트웨어이다.
• 후위 처리기, 지능형 저장처리, 내용에 의한 참조 메모리, 병렬 처리, 데이터베이스 연산기 등을 포함하고 있다.

---

✅ 4. 데이터 모델링

• 현실 세계의 데이터를 데이터 모델 상의 데이터베이스 구조로 변환하는 과정을 "데이터 모델링"이라고 한다.
• 실세계의 일부분을 DB 시스템이 지원하는 데이터 모델의 형태로 데이터베이스를 표현화는 과정으로 볼 수 있음.
• 데이터 모델: 데이터타입, 데이터의 연산, 데이터의 의미 및 일관성 제약 조건 등의 DB 구조를 추상화하여 체계적으로 명시하기 위한 개념의 집합으로 볼 수 있다. ( 데이터 모델링의 결과를 표현하는 도구 느낌 )
• 지원하는 개념의 타입에 따라 개념적 모델, 논리적 모델, 물리적 모델로 나뉜다.

(1) 개념적 모델

• 현실 세게에서 주요 데이터를 추출하여 개념 세계의 데이터로 변환하는 과정에서 사용되는 모델이다.
• 현실 세계를 개념 세계로 추상화했을 때 어떤 요소로 이루어져 있는지를 표현함
• 즉, 업무 개념(엔티티) 들 사이의 관계를 그림으로 표현하는 단계임. ( 사용자가 데이터를 인식하는 방법과 밀접한 개념 제공 )
• 기술보다는 업무의 흐름과 정보 구조에 집중을 함. ( 대표적 모델: 개체-관계 모델(E-R 모델) )

(2) 논리적 모델

• 개념 세계의 데이터를 데이터베이스에 저장할 구조로 표현하는 과정에서 사용되는 모델을 의미한다.
• 데이터 구성에 대한 세부적인 사항을 숨기고, 사용자가 이해할 수 있는 정도의 데이터 저장에 대한 개념 제공을 함.
• 즉, 개념적 모델을 데이터베이스의 논리 구조로 바꾸는 단계이며, 이때 관계형 모델, 계층형 모델, 네트워크 모델 등의 형태로 변환을 하게 된다. 또한, 속성, 기본키, 외래키, 정규화 등을 정의하게 된다. ( 아직은 실제로 물리적으로 구현된 단계는 아님. )
• 해당 계층형 모델, 관계형 모델, 네트워크 모델 등은 데이터를 논리적으로 어떻게 표현하고 연결할지 결정하는 데이터베이스 구조(논리적 모델)의 세 가지 큰 패러다임으로 볼 수 있음.

[ 계층형 데이터 모델 ]

회사
 ├── 부서1
 │    ├── 직원A
 │    └── 직원B
 ├── 부서2
 │    ├── 직원C
 │    └── 직원D

• 데이터베이스 구조를 트리 형태로 표현하는 모델이다.
• 데이터 간의 관계가 부모-자식(1:N) 형태로 구성이 된다.
• 회사 - 부서 (1:N) 관계 , 부서 - 직원 (1:N) 관계를 가지는 이러한 트리 형태임.
• 특징: 구조가 명확해서 검색 속도는 빠르지만, 유연성이 떨어짐 ( 부서 간 이동, 다중 관계 표현 어려움 )

[ 네트워크형 데이터 모델 ]

• 그래프 구조로 데이터를 표현하는 모델이다.
• 계층형 모델의 한계를 보완하기 위해 만들어짐.
• 즉, 한 데이터(노드)가 여러 부모를 가질 수도 있고, 여러 자식과도 연결될 수 있음.
• 관계를 링크로 직접 연결해서 서로 연관관계를 가질 수 있게 해줌.
• 특징: 관계 표현이 유연하지만 구조가 복잡해서 데이터 탐색이 어려움

[ 관계형 데이터 모델 ]

• 데이터를 2차원 테이블 형태로 표현하는 모델이다.
• 현재 대부분의 DBMS 가 해당 관계형 데이터 모델을 사용해서 테이블을 구현하고 있음.
• 특징: 데이터 간 관계를 테이블 간 연결로 표현하기 때문에 구조가 단순함.

[ 객체지향 데이터 모델 ]

• 데이터와 절차를 일체화된 단위로 다루는 객체지향의 개념을 잘 모아서 정의해 놓은 집합임.
• 실세계에 존재하는 개념적 객체를 중심으로 모델링하는 방식임.
• 즉, 객체 단위로 데이터를 저장하고 관리하는 모델로 클래스, 상속, 캡슐화, 다형성 같은 객체지향 개념을 그대로 데이터 모델에 반영을 한다. **DB 자체를 객체처럼 만드는 모델**

[ 객체관계형 데이터 모델 ]

• 관계형 모델과 객체지향형 모델의 장점을 결합한 진보된 형태의 모델이다.
• 관계형 시스템에 새로운 객체 저장 능력을 추가한 형태로 볼 수 있다.
• 즉, 기존 관계형 DB의 안정성과 SQL 구조를 유지하면서, 객체지향의 확장성(클래스, 사용자 정의 타입, 상속)을 추가한 모델로 볼 수 있다. **기존 RDB에 객체 개념을 섞는 모델**

(3) 물리적 모델

• 사용자 수준보다 더 하위 수준의 저장장치 입장에서 데이터가 어떻게 저장되어 있는지에 대한 세부적인 사항을 기술하는 개념을 제공한다. ( 레코드 형식, 레코드 순서, 접근 경로 등의 정보 표현하고 제공함. )
• **즉, 논리적 모델을 DBMS의 물리적 저장 구조로 구현하는 단계로 볼 수 있지만, 실제로는 모델이라 DB를 실제로 만들기 직전의 마지막 단계이다. 하지만, 실제 DB 생성 SQL로 변환이 가능한 수준으로 볼 수 있음**.
• 해당 모델 단게에선 인덱스, 파티션, 파일 구조, 접근 경로, 저장 경로, 데이터 타입 등 성능 최적화 요소를 고려하게 됨.

---

✅ 5. 개체-관계 모델

(1) 개체-관계 (E-R Entity-Relationship) 모델이란?

• 개체 타입과 이들 간의 관계 타입을 이용해서 실세계를 사람이 이해할 수 있도록 개념적으로 표현하는 방법이다.
• 쉽게말해, 데이터베이스를 설계할 때 현실 세계의 데이터를 개념적으로 표현하기 위한 모델이다.
• 즉, 현실 세계를 데이터베이스로 옮기기 전에 그림처럼 표현하는 개념적 모델로 볼 수 있다.
• 이러한 그림(청사진)을 개체-관계 다이어그램(ERD) 라고 부르며, 이건 E-R 모델을 그래프 방식으로 표현한 것임.
• **또한, 개체-관계 모델은 개념적 관계로 볼 수 있음.**

(2) 개체 (Entity) 란?

• 데이터로 표현하려는 물리적/개념적으로 존재하는 실세계의 유무형의 모든 것을 개체라고 부름.
• 개체는 컴퓨터 파일구조에서는 하나의 레코드에 대응하게 됨.
• 해당 개체는 하나 이상의 속성으로 구성이 된다.
• 속성: 데이터의 가장 작은 논리적 단위로, 각 개체의 특성이나 상태를 표현함. (하나의 컬럼안에 하나의 속성 느낌, 필드값정도)
• 속성 종류: 단일값/다중값 속성, 단순/복합 속성, 유도 속성 등이 있음.

(2) 관계 란?

• 개체 집합 사이의 대응성(사상)을 의미함. 즉, 두 개 이상의 개체 사이의 연관성을 의미함.
• 쉽게말해, 두 개 이상의 개체들이 서로 어떤 일을 하고 있는가, 어떤 관련이 있는가를 표현하는 것임.
• 집합 간에 어떤 관계를 미리 정의해 놓고 주어진 값을 정의된 관계에 따라 해석하면 유용한 의미 표현이 가능함.

[ 개체 간의 관계 - 관계의 종류 (카디널리티, Cardinality)  ]

• 개체와 개체가 몇 명씩 연결되는지에 따라 다음과 같이 1:1, 1:N, N:1, M:N 으로 나누게 된다.
• 카디널리티: 얼마나 많은 수의 데이터가 서로 연관되는가를 의미하는 용어임.

[ 개체 간의 관계 - 관계의 종류 (종속, 필수) ]

의존적 관계 예시

• 위와 같이 학생이 과목을 수강한다는 단순 연결뿐 아니라, 해당 관계가 의존적 관계인지, 필수 참여인지에 따라 나눌 수 있음.
• 예시처럼, 부서가 없으면 직원이 소속될 수 없으므로, 직원은 부서에 종속적인 관계로 볼 수 있음.

필수 참여(전체참여) 예시

• 예시처럼, 모든 학생이 모든 과목을 수강하는 경우를 의미한다. 즉, 외래키가 모두 NULL 이 아닌 경우임.
• 어떤 학생이 아직 과목을 수강하지 않는 경우는 부분 참여로 볼 수 있음.
• 이러한 참여 기준으로도 관계가 어떤 관계인지 분류를 할 수 있음.

(3) E-R 다이어그램 (ERD)

• 앞서 살펴본, 관계의 종류를 ERD 를 통해서 추상적으로 표현이 가능함. ( 관계를 눈으로 보기 편하게 쉽게 정의 가능 )

• ERD 예시로는, 위와 같이 고객 개체와 계좌 개체를 통해 계좌 거래라는 관계가 나타날 수 있음.
• 고객의 속성명인 컬럼으로는 고객 이름, 집 주소, 주민등록번호... 등이 있음.
• 계좌의 속성명인 컬럼으로는 계좌번호, 잔고가 있음.
• 고객과 계좌의 관계는 계좌 거래라는 이름으로 1:N 의 관계가 될 수 있음. ( 즉, 한 명의 고객은 여러개의 계좌를 가질 수 있음 )
• 계좌거래 라는 중간 테이블을 활용해, 거래일자를 정의하고 있음. 둘의 PK 를 외래키로 쓰는 경우임.