[Database] 1. The Database Environment and Development Process

최근 들어 프로젝트에 JPA를 사용하면서 DB에서 데이터들을 편리하게 꺼내 쓸 수 있음을 느낄 수 있었다.

 

그런데, DB의 근본적인 개념들에 대해 부족함을 느껴 이를 정리해보고자 한다.

 

정리에 사용되는 자료는 다음과 같다. 명지대학교 융합소프트웨어학부 김일주 교수님의 DB설계 및 구현2 수업자료들과, 수업교재로 사용된 Modern Database Management, 12th Edition(J.A Hoffer)이다.

 

첫 포스팅은 데이터베이스 환경과 개발 프로세스이다.  목차는 다음과 같다.

 

목차

<데이터베이스 환경과 개발 프로세스>

1. 현대 조직에서의 데이터

2. 데이터, 정보, 지식

3. 데이터베이스란

4. 왜 데이터베이스를 사용하는가

5. DB 기술의 진화

6. DB 개발 프로세스

데이터베이스 환경과 개발 프로세스

1. 현대 조직에서의 데이터

현대 조직에서의 데이터들은 정형화 된 작업에 사용된다. 이마트를 예로 들자면, 상품의 가격, 세율, 신용카드 번호 등이다. 온라인 뱅킹을 예로 들자면, 소비자 id, 거래, 계좌 번호 등이 있다.

 

정형화된 작업 뿐만 아니라 데이터들은 현대 조직에서 의사결정에 사용된다. 고객프로필과 이전 구매 이력을 바탕으로한 소비자 타게팅이나 고객 수요에 대한 데이터를 기반으로한 자동차 제조 회사, 주가나 금리 데이터를 바탕으로 한 투자 포트폴리오에 사용된다.

 

위를 통해 알 수 있듯, 데이터는 현대 조직에 매우 소중한 자산이다. 데이터베이스 기술이란, 현대 조직에서 어떻게 데이터를 모집하고 저장하고 처리하고 운영할 것인지에 대한 것이다. 

 

현대의 데이터베이스는 이론적 토대를 기반으로 하는데, 이 이론적 토대는 Dr. E. F. Codd의 관계형 데이터베이스 이론을 기반으로 한다. 

2. 데이터, 정보, 지식

데이터, 정보, 지식에 대해 알아본다.

 

데이터란 가공되지 않은 사실들을 의미한다. 정형화된 데이터에는 숫자, 텍스트, 날짜, 휴대폰번호 등이 있고 비정형화된 데이터에는 이미지, 비디오, 문서들이 있다. 

 

데이터의 예시로는 김정우의 학점은 2.9

2022년 판매실적은 300밀리언 달러이다.

 

즉, 데이터는 많은 의미를 갖지 않는다. 

 

정보란 의미를 가지도록 처리된 데이터이다. 

 

정보의 예시로는, 전공별 등록 비율이 있다. 경제학과는 10%의 등록비율, 컴퓨터공학은 20%의 등록비율을 갖는 것이 될 수 있다.

 

지식이란, 행동을 안내할 수 있는 통찰력의 집합이다. 즉, 지식은 참고만하는 것이 아니라 우리를 행동을 하도록 이끌어 주는 것이다.

 

지식의 예시로는, 학업성취도 향상을 위한 통찰력, 2020년 매출 증대를 위한 통찰력 등이 있다. 

데이터, 정보, 지식을 그림으로 표현하자면 다음과 같다. 

 

3. 데이터베이스란

데이터베이스란 논리적으로 관련된 데이터의 정리된 수집이다. 

 

메타데이터란, 데이터 유형, 데이터 허용 값 등을 포함한 데이터 속성에 대한 설명을 의미한다.

 

그렇다면 데이터베이스에서 데이터 모델링 및 구성 방법은 어떻게 진행될까?

 

User Requirements -> Entity-relationship Model -> Relational Model -> Create a database in Oracle과 같이 진행된다.

 

데이터베이스를 이해하기 위한 용어들에 대한 개념은 다음과 같다.

 

Database -> storehouse of the data

Repository -> centralized storehouse of metadata
User Interface -> text and graphical displays to users
Database Management System (DBMS) -> software for managing the database (ex. Oracle, IBM DB2, MS SQL Server, MySQL, MS Access)

Application Programs -> software using the data
CASE Tools -> computer-aided software engineering tools
Data/Database Administrators -> personnel responsible for maintaining the database
System Developers -> personnel responsible for designing databases and software
End Users -> people who use the applications and databases

 

4. 왜 데이터베이스를 사용하는가

 

데이터들은 데이터베이스 뿐만 아니라 텍스트파일이나 엑셀 파일처럼 "파일"에 저장될 수 있다.

 

그렇다면, 왜 파일 시스템이 아닌 데이터베이스를 사용하는 것일까?

 

파일 처리 시스템의 단점으로는 다음과 같다.

 

1. 프로그램 - 데이터간의 의존성

 -> 파일 처리 시스템을 사용한다면 모든 프로그램에서 사용하는 각 파일에 대해 메타데이터를 유지 관리해야 하기 때문이다.

 

2. 데이터의 중복

-> 서로다른 시스템/프로그램에 동일한 데이터의 개별 복사본이 있어야 하기 때문이다. ex) 은행 창구에서 고객이 계좌개설을 했다면 그 고객에 대한 데이터가 창구지점뿐만 아니라 은행의 본점에도 있어야 하는데, 이러면 데이터의 중복이 발생한다.

 

3.  데이터 공유의 한계

-> 중앙 집중식 데이터 제어 기능이 없다.

 

4. 긴 개발시간

-> 프로그래머는 자신의 파일 형식을 설계해야 한다.

 

5. 과도한 프로그램 유지 관리

-> 정보시스템 예산의 80%를 차지한다. 

 

데이터의존성의 문제는 다음과 같다.

각 어플리케이션 프로그래머는 자신의 데이터를 유지해야 하고, 각 응용 프로그램에는 각 파일의 메타데이터가 포함되어야 하며 자체 프로세싱이 있어야 한다. 예를 들어 CRUD에 대한 루틴 자료이다. 또한, 조정 및 중앙 통제가 부족하고 비표준파일형식이다. 

 

데이터 중복 문제는 다음과 같다.

중복 데이터가 있는 공간이 낭비되고 유지관리자의 복잡도가 증가, 마지막으로 제일 중요한 것은 한 파일에서 데이터를 변경하면 불일치가 발생할 수 있다는 점이다. 즉, 데이터의 무결성을 훼손한다. 

 

-> 이러한 해결책으로 데이터베이스가 있다.

 

데이터베이스는 공유데이터의 중앙 저장소, 제어 에이전트에 의해 데이터 관리, 표준화되고, 편리한 형태로 보관한다는 접근이다. 즉, 데이터베이스는 주문시스템, 결제시스템, 청구시스템을 하나의 데이터베이스에서 관리한다. 

 

추가적으로, 데이터베이스의 장점은 무엇일까?

 

1. 계획되지 않은 데이터 복제 / 재분할을 제거한다.

 

2. 데이터일관성을 향상시킨다.

 

3. 프로그램-데이터 독립성을 지킬 수 있다. (ex. 데이터의 설명이 변경된다면? 데이터의 물리적 저장 형식이 변경된다면? -> DB의 변경이 있을뿐, 프로그램의 변경은 없다.)

 

4. 유지보수 비용이 절감된다.

 

5. 데이터 보안이 향상된다.

 

데이터베이스는 어떤 형식으로 저장될까?

 

The Three-Schema Architecture를 통해 알아본다.

 

데이터베이스의 물리적 구조를 나타내는 Internal schema(Logical Schema, Physical Schema로 구성됨), 전체 데이터베이스의 개념 구조를 나타내는 Conceptual Schema, 데이터베이스 부분의 개념 구조를 나타내는 External Schema가 있다.

 

데이터베이스는 장점이 많지만 단점도 많다.

 

1. 전문화된 신규인력이 필요하다는 점(DBA, 개발자 등)

 

2. 설치 및 관리비와 복잡성

 

3. 레거시 시스템에서 전환비용이 든다는 점

 

4. 정기적인 백업 및 오류 복구가 필요하다는 점

 

5. 잠재적인 조직이 충돌할 가능성이다.

5. DB 기술의 진화

[참조]: https://blogs.gartner. com/adamronthal/iles/2019/06/dbms-marketshare. png

2011 - 2018 까지의 회사별 데이터베이스 기술 진화 그래프이다.

 

데이터베이스 응용프로그램 범위는 다음과 같이 나눌 수 있다.

 

1. 개인데이터베이스(클라이언트, 서버 및 데이터베이스가 모두 동일한 시스템에 상주하는 경우)

2. Two-tier Client/Server databases(프리젠테이션 클라이언트, 데이터베이스는 서버로 나뉜 경우)

3. Three-tier (프리젠테이션 레이어, 어플리케이션 계층, 데이터베이스 서버로 나뉜 경우)

4. Enterprise Applications이다.

Enterprise Applications는 ERP(Enterprise Resource Planning)나 Data warehouse가 있다. 

ERP란? -> 제조, 금융 등 모든 엔터프라이즈 기능을 통합한 것이다.

Data Warehouse란? -> 다양한 운영 데이터베이스에서 파생된 통합 의사결정 지원 시스템이다. 즉, 여러 데이터베이스에 분산되어 있는 자료를 표준화하고 통합하여 놓은 데이터베이스이다. 

 

Data - Information - Knowledge Pyramid

 

피라미드에서 위로 갈수록 스스로 발견하게 하는 heuristic성질을 갖고, 아래로 갈수록, 정해진 순서로 문제를 해결하는 성질을 갖는다. 

6. DB 개발 프로세스

 

DB 설계 프로세스를 통해 사용자의 정보 요구 및 조직의 운영을 지원하기 위한 데이터베이스 시스템의 내용 및 구조를 결정한다. 

 

데이터베이스 설계 목표는 다음과 같다.

 

1. 사용자 및 사용자의 작업 운영에 대한 핵심 데이터 요구사항을 정확하고 완전하게 캡쳐하고 표현한다.

 

2. 필요한 정보에 자연스럽고 이해하기 쉬운 구조를 제공한다.

 

3. 선택한 DBMS를 사용하여 직접 구현할 수 있는 방식으로 데이터를 표현한다.

 

4. 사용자와 조직 모두의 기능 및 성능 요구사항을 충족시킨다. 

 

데이터베이스 개발은 정보 시스템 개발 프로세스의 일부분이다.

 

시스템이란, 일부 목표를 달성하기 위해 함께 작동하는 관련 구성요소들에 대한 모음을 나타낸다. 

 

정보시스템이란, 핵심 비즈니스 기능을 지원할 수 있는 정보와 지식을 생산하기 위해 데이터를 캡처, 저장, 처리할 수 있는 시스템이다.

 

DB개발 프로세스는 다음 그림과 같다. 

 

첫번째로, Preliminary Investigation, 사전 조사이다. 

비즈니스 요구사항을 파악하고, 확인된 비즈니스 요구사항을 충족하는 잠재적 정보 시스템을 제안한다. 또한, 타당성을 조사한다. 이때 데이터베이스 개발에 대한 활동은 없다.

 

두번째로, System Analysis, 시스템 분석이다.

사용자 요구사항을 수집하고 프로세스를 모델링한다. 또한, Conceptual Data Modeling을 진행한다. 이는 ER(Entity Relationship)모델을 사용해서 진행한다. 

 

여기서 프로세스 모델링이란, 시스템과 그 환경 그리고 시스템 컴포넌트들 사이에서 데이터가 모집, 변환, 저장, 분배되는 프로세스를 그래픽 및 구조적으로 나타내는 것을 의미한다.

 

여기서 Conceptual Data Modeling이란, 데이터베이스 내용을 모델링하는 것으로, Entity Type과 Relationships을 보여주는 ERD를 그리는 것이다. 이는 DBMS와 독립적이다.

Conceptual Data Modeling의 Input은 데이터 요구사항이고, Output은 Conceptual Schema이다. 

 

세번째로, System Design이다. Logical Database Design, Physical Database Design을 포함한다. 

 

Logical Database Design은 Conceptual Data Models 을 Relational Models로 변환하는 과정이다. 중복을 제거하는 등의 관계 모델을 세분화하는 Normalization의 과정을 가진다. 또한, 비즈니스 규칙을 적용하기 위한 제약 조건을 추가하고, DBMS에 의존적이다.

Logical Database Design의 Input은 Conceptual Schema이고, Output은 Logical Schema이다. 

 

Physical Database Design은 내용보다 성능에 주로 주목한다. 

과도한 리소스 사용 없이 응답 시간을 최소화, 인덱스, 데이터를 어떻게 배치할 것인지에 대한 과정을 진행한다. 

Physical Database Design의 Input은 Logical Schema이고, Output은 Physical Schema이다. 

 

네번째로, System Implementatin, 시스템 구현이다. 이 때 테스트, 설치, 시스템 전환의 과정을 가진다.

 

다섯번째로, Maintenance, 유지보수이다. 데이터베이스를 유지보수하는 과정을 가진다. 

 

 

위에서 살펴봤던, Three Schema Architecture를 다시한번 그림을 통해 살펴본다. 

External Schema는 사용자가 데이터를 인식하는 방식이다. 사용자마다 동일한 데이터의 다른 보기를 가질 수 있다.

 

Conceptual Schema는 여러 개의 External View들을 하나의, 서로 논리적으로 이어져있는 종합적인 기업데이터로 정의할 수 있도록 통합한 것이다. 물리 스토리지에 대한 고려 사항과는 무관하다.

 

Internal Schema는 Logical Schema(데이터 관리 기술 유형에 대한 데이터 표현)와 Physical Schema(특정 DBMS를 사용하여 데이터를 SDD에 저장하고 표시하는 방법을 설명)를 포함한다. 

 

즉, 이를 정리하자면 다음 그림과 같다. 

이런 3가지 레벨로 나누면서 얻을 수 있는 이점에는 다음과 같은 것들이 있다.

 

1. 하나의 유저뷰는 다른 유저뷰의 영향을 받지 않는다.

2. DBA는 모든 사용에 영향을 주지 않고 개념구조를 변경할 수 있어야 한다. 

3. 사용자는 물리적 데이터베이스 저장 세부정보를 알 필요가 없다.

4. DBA는 유저뷰에 영향을 주는 것 없이 데이터베이스 저장구조를 변경해야만 한다. 

 

Three level Architecture의 주요 목적은 다음과 같다.

외부스키마는 개념스키마의 변경에 영향을 받지 않고, 개념 스키마는 내부 스키마의 변경에 영향을 받지 않는, 데이터의 독립성 때문이다.

 

지금까지, 데이터베이스의 환경과 개발 프로세스에 대해 알아보았다. 다음 포스팅부터는 지금까지 알아본 틀을 가지고 세부적인 내용에 대해서 자세하게 알아본다.