2025.05.07
RestFul API 개발
- 데이터 위주의 프로세스 설계
Data-Modeling
데이터 모델링의 필요성
파일 저장형태
- App 에서 사용하는 데이터를 메모리에서만 관리하면 App 종료 or 컴퓨터 종료 시 데이터가 사라지게 된다
- 따라서 데이터가 소멸되지 않게 디스크(disk) 저장장치에 파일 형식으로 저장하고 읽고 쓰게 된다
- 하지만 시스템 장애나 파일 IO 도중 문제가 발생했을 때 원상태로 복구 하기가 힘들다
- 이진 파일은 사람이 바로 읽고 해석하기 힘들다
엑셀 파일 저장
- 한 눈에 알아보기 쉽게 엑셀 파일로 2차원 테이블 형태로 저장하게 된다면 각 컬럼과 데이터를 한 눈에 살펴볼 수 있다
- 컬럼이 늘어나고, 같은 컬럼에 들어가야 할 데이터가 많아질 수록 중복되는 데이터가 많아진다 -> 저장할 데이터가 기하급수적으로 많아진다
- 하나의 테이블로 관리 시 데이터가 늘어 날수록 처리되는 시간과 관리가 힘들다
- 중복된 데이터가 많아 행을 추가, 삭제, 수정 할 때마다 이상현상 (Anomaly) 발생
관계형 데이터베이스 저장(RDBMS)
- 각 데이터들의 종류를 한 눈에 파악하기 쉽다
- 데이터 테이블 간의 관계를 통해 연관있는 데이터들이 어떻게 누적되어 가는 지 한 눈에 파악하기 쉽다
- 중복값이 제거되어 중복 된 데이터로 인한 문제들을 해결할 수 있다
데이터베이스 설계
설계
데이터베이스 안에 저장될 테이블, 뷰 등의 구조를 디자인
- 기본키, 외래키, 인덱스 등의 요소들을 계획하는 작업
- 업무의 분석, 논리적 설계(데이터 모델링), 물리적 설계, 데이터베이스 구축에 이르는 전 과정을 포함
데이터베이스 설계 과정
- 요구 조건 분석 :
데이터베이스 사용자에 따른 수행업무와 필요한 데이터의 종류, 용도, 처리형태, 흐름, 제약조건 등을 수집하여 수집된 정보를 바탕으로 요구조건 명세를 작성 - 개념적 설계(정보 모델링, 개념화) :
현실 세계의 정보를 추상화하여 개념 모델(ERD) 로 표현
DBMS와 무관하게 설계하며, 주요 개체(Entity), 속성(Attribute), 관계(Relationship)를 정의 - 논리적 설계(데이터 모델링) :
개념 모델을 관계형 모델로 변환
엔티티 → 테이블, 속성 → 컬럼
Primary Key(기본키), Foreign Key(외래키) 설계
DBMS에 종속되지 않음 - 물리적 설계(데이터 구조화) :
논리적 설계를 바탕으로 실제 데이터베이스를 구축하기 위한 테이블, 뷰, 인덱스 등을 설계하고 반정규화를 시행하는 과정
특정 DBMS 제품을 염두에 두고 진행
데이터 타입, 제약조건, 인덱싱, db에 ddl 부분에 들어갈 부분
실제 물리적으로 적용할 요소들
관계형 데이터베이스 모델링
2차원 테이블 구조에 우리가 관리할 데이터를 어떻게 담는 것이 최적인지를 고민하는 과정
- 릴레이션(Relation): 관계형 데이터베이스에서의 테이블을 의미
- 이질적인 정보가 혼재되어 있는 릴레이션의 데이터간 종속성을 기준으로 분리(정규화)
- 표 사이의 연결고리는 데이터모델의 관계에 해당
- 각 엔터티(테이블)의 고유 식별값은 엔터티의 주 식별자에 해당
- 과목명 표기 방법을 통일화 한 것은 데이터 표준화의 개념 중 코드의 개념
데이터 모델링 주요 개념
Entity (개체)
업무 활동상 지속적인 관심을 가지고 있는 대상, 그 대상들 간에 동질성을 지닌 개체 집합이나 행위의 집합
- 반드시 시스템을 구축하고자 하는 업무에서 필요하고 관리하고자 하는 정보여야 한다
- 유일한 식별자(Unique Identifier)에 의해 식별이 가능
- 영속적으로 존재하는 개체의 집합
- 해당 개체는 업무 프로세스 내에서 반드시 사용
- 개체 타입에는 반드시 속성(Attribute)들이 포함 -> 속성을 찾을 수 없다면 엔터티이기 보다는 다른 엔터티의 속성일 가능성이 높다
- 개체 타입은 다른 개체 타입과 최소 한 개 이상의 관계가 있어야 한다
- 일반적으로 엔티티는 2개 이상의 인스턴스가 존재해야 의미가 있다
Attribute (속성)
업무에 필요한 개체에서 관리하고자 하는 더 이상 분리되지 않는 최소의 데이터 단위
- 개체 타입에 속한 개체의 성격을 구체적으로 나타낼 수 있는 항목들
- 각각의 개체 타입은 속성의 집합으로 설명
Identifier (식별자)
여러 개의 집합체를 담고 있는 하나의 개체 타입에서 각각의 개체를 구분할 수 있는 속성/속성들의 집합
- 모든 개체 타입에는 반드시 하나 이상의 식별자가 있어야 한다
- 식별자에 의해 개체 타입 내 모든 개체들이 유일하게 구분(Unique)
- 특정 개체 타입에 식별자가 지정되면 그 식벽자는 변하지 않아야 한다
- 주 식별자의 경우 식별자가 지정되면 주 식별자 속성에 반드시 데이터 값이 있어야 한다(not null)
주 식별자
- 개체 타입의 대표성을 나타내는 유일한 식별자
- 개체 타입 하나에 한 개
- 개체 타입에서 개체를 유일하게 식별할 수 있는 속성이 두 개 이상일 때 해당 업무에 적합한 속성을 주 식별자로 정한다
보조 식별자
- 주 식별자를 대신하여 보조적으로 개체를 식별할 수 있는 속성
- 개체 타입 하나에 하나 이상일 수 있다
- 기본키로 지정되지는 않고 유니크 인덱스(unique index)로 지정되어 사용
- 개체 타입에서 개체를 유일하게 식별할 수 있는 속성이 두 개 이상일 때 주 식별자로 선정 되지 않은 다른 속성을 보조 식별자로 활용
내부 식별자
- 타 개체 타입으로부터 식별자를 가져오지 않고 자신의 개체 타입 내에서 스스로 생성되어 존재하는 식별자
외부 식별자
- 다른 개체 타입과의 관계에 의해 주 식별자 속성을 상속받아 자신의 속성에 포함되는 식별자
- 식별관계 : 자신의 외부 식별자가 주 식별자 영역에 포함
- 비식별 관계 : 자신의 외부 식별자가 일반 속성에 포함
- 자신의 개체 타입으로부터 다른 개체 타입을 찾아가는 연결자 역할
단일 식별자
- 주 식별자의 구성이 한 가지 속성으로만 이루어진 경우
복합 식별자
- 주 식별자의 구성이 두 개 이상의 속성으로 구성된 경우
원조 식별자
- 실제 업무에서 사용하는 의미 있는 속성을 그대로 주 식별자로 사용하는 경우
- 주 식별자의 속성이 복합 식별자일 경우에도 여러 개의 속성을 그대로 사용하는 경우
대리 식별자(인조 식별자)
- 주 식별자의 속성이 복합 식별자일 경우 여러 개의 속성을 묶어 하나의 속성으로 만들어 주 식별자로 활용하는 경우
Relationship (관계)
2개 이상의 엔티티 간에 존재하는 연관성
- 한 엔터티의 속성이 다른 엔터티를 참조하거나 종속될 때 표현
- 단순히 연관만 있다고 관계를 맺지 않으며, 속성으로 관리되는 경우에만 관계로 정의
- 종속관계 : 부모 엔티티와 자식 엔티티 간의 관계, 부모 엔티티가 존재해야 자식 엔티티가 존재, 부모 엔티티 없이 관계를 삭제하고 자식 엔티티만 존재할 수 없다
- 참조관계 : 엔티티 간에 연관성이 존재하긴 하지만, 다른 엔티티가 없다고 존재할 수 없는 관계는 아닌 경우, 관계를 삭제해도 한 속성에 대한 연관성만 문제가 되고 하위 엔티티 존재에는 지장이 없다
관계의 구성 요소
카디널리티(Cardinality)
- 릴레이션에서 튜플의 개수
- 상위(부모) 엔티티의 인스턴스 하나가 하위(자식) 엔티티의 인스턴스 수이 비율
- 관계가 있는 두 엔티티는 1 : 1 , 1: N , N : M 관계를 나타내게 된다
- ️다 대 다(M : M) 관계이면 교차 엔티티를 통해 일 대 다(1 : M) 관계로 해소해주어야 한다
옵셔널리티(Optionality)
- 상위(부모) 엔티티와 하위(자식) 엔티티가 서로 연관되는 값이 반드시 존재해야 하는 지 존재하지 않아도 되는 지를 의미
- 서로 연관되는 값이 반드시 존재하면 Mandatory(필수), Not null
- 서로 연관되는 값이 반드시 존재하지 않아도 된다면 Optional(선택), Null able
1 : 1
- 한 쌍의 엔티티가 서로 고유한 인스턴스 관계
배타 관계 - 하나의 엔티티가 둘 중 하나의 엔티티와만 관계를 가질 수 있는 구조
재귀 관계 - 하나의 엔티티가 자기 자신과 관계를 맺는 구조
엔티티 도출 과정 예시
요구사항 명세서 등을 검토, 현업 담당자와 인터뷰, 현업에서 사용하는 장표를 검토, 기존 시스템의 산출물이 있는 경우 검토
1. 엔티티 후보 풀과 엔티티 리스트를 준비
2. 분석 대상 문서를 보고 명사를 찾는다
3. 표시한 명사들을 엔티티 / 속성 구별
- 엔티티 명사 -> 엔티티 리스트에 기록
- 속성 명사 -> 엔티티 리스트의 포함 속성에 기록
- 불분명 -> 엔티티 후보 풀에 기록
- 중복된 명사 / 유사한 의미의 명사 정리
- 엔티티 후보 풀에 있는 명사를 검토, 엔티티 리스트 / 속성에 기록
- 도출된 엔티티에 대해 구축될 시스템에서 관리할 필요가 있는지 검토
추상화와 범주화
추상화 : 어떤 관점을 기준으로 관심 없고 복잡한 특성은 걷어낸 핵심
범주화 : 추상화를 통해 간추려진 핵심들을 유사한 것들끼리 하나의 집합으로 파악
- 사물의 행위가 아닌 본질(대상의 가장 핵심적이고 필수적인 속성)을 중시하여 엔티티 선정
- 개체의 본질에 집중하여 개체의 집합으로 바라보아야 범주화가 가능
- 엔티티가 업무 수행에 필요한 데이터를 성격이 유사한 것끼리 모아 놓은 집합이므로 추상화 범주화를 통해 엔티티를 도출할 수 있다.
- 정보를 담는 최소 단위인 속성의 종속성을 분석하여 유사한 것끼리 모으고 독립적인 것은 분리하는 과정
- 관계형 데이터 모델은 자신이 필요한 정보는 엔티티로 집약해서 모으고, 다른 정보가 필요할 때는 관계를 통해 원하는 정보를 조회할 수 있는 구조
논리모델(Logical Model)
개념 모델을 상세화하는 작업
- 전체 속성을 도출하고 도출되지 않은 대부분의 엔티티들과 관계들을 도출하는 단계
- 정규화(Normalization)를 진행하는 단계
이상
중복된 데이터 때문에 데이터에 의도하지 않은 현상이 발생되는 형상
- 삽입 이상, 갱신 이상, 삭제 이상이 존재
삽입 이상(Addition Anomaly)
릴레이션에서 새로운 인스턴스를 삽입할 때 발생하는 데이터 이상 현상
- 불필요한 정보를 함께 저장하지 않고는 어떤 정보를 저장하는 것이 불가능
- 일부 속성만으로는 삽입 불가능
갱신 이상(Update Anomaly)
릴레이션에서 속성의 값을 업데이트할 때 발생하는 데이터 이상 현상
- 반복된 데이터 중에 일부만 수정하면 데이터의 불일치가 발생
삭제 이상(Deletion Anomaly)
릴레이션에서 인스턴스를 삭제할 때 발생하는 데이터 이상 현상
- 유용한 정보를 함께 삭제하지 않고는 어떤 정보를 삭제하는 것이 불가능
정규화(Normalization)
중복 데이터를 제거하여 안정성과 확장성을 도모
- 안정성: 함수 종속을 기반으로 데이터의 성격에 맞는 엔터티가 도출되어 모델 구조를 정의
- 확장성: 데이터의 정체성이 그대로 반영되어 업무가 수정되거나 추가 되더라도 엔터티에 반영하기가 수월
함수 종속
릴레이션 내에 존재하는 속성 간의 종속성을 의미
- 대표 속성(식별자)이 나머지 속성을 유일하게 식별할 수 있다면 대표 속성과 나머지 속성 사이에는 연관관계가 성립
- 결정자(Determinant) : 어떤 속성의 값을 결정하는 속성
- 종속자(Dependent) : 결정자의 값에 의해 결정되는 속성
1 정규형(1NF)
원자성
- 모든 속성은 반드시 하나의 값을 가져야 한다
- 중복 인스턴스가 있으면 안된다
2 정규형(2NF)
부분 함수 종속성 제거
- 엔티티의 일반속성은 주식별자 전체에 종속이어야 한다.
- 부분 함수 종속 : 복합 기본키 중 일부 속성에만 종속되는 일반 속성
3 정규형(3NF)
이행 함수 종속성 제거
- 엔티티의 일반속성 간에는 서로 종속적이지 않다.
- 이행 종속성 : 기본키가 아닌 속성이 또 다른 일반 속성을 결정하는 경우 (A->B , B->C 의 관계)
후보키가 아닌 결정자 제거, 모든 결정자가 후보키
BCNF
모든 결정자가 후보 키 집합에 속해야 한다
4 정규형(4NF)
다치종속 제거
- 다치 종속 : A->B 일 때, 하나의 A값에 여러 개의 B 값이 존재, 최소 3개의 컬럼이 존재
5 정규형(5NF)
조인 종속성(Join Dependency) 제거
- 릴레이션을 무손실 분해한 후에도 재조인이 항상 원래 릴레이션과 일치해야 함
물리모델
개념적/논리적 모델을 실제 DBMS에 맞춰 구현 가능한 구조로 구체화하는 작업
- 테이블 구조, 데이터 타입, 인덱스, 파티셔닝, 뷰 등 물리적 요소에 초점
- 사용자 DBMS 결정 -> 데이터 타입 크기 결정 및 업무분석 -> 반정규화 -> 무결성 제약조건 정의 -> 뷰, 인덱스 정의 -> 데이터베이스 생성
슈퍼타입
엔티티들의 공통적인 속성
서브타입
슈퍼타입의 특성을 상속받으며, 고유 속성을 추가로 가지는 하위 엔티티
- 슈퍼타입과 구별되는 조건(속성 값)에 따라 구분되며, 배타적일 수도, 중첩될 수도 있다
뷰(가상 테이블)
하나의 테이블 / 여러 테이블에 대해 특정 사용자/조직의 관점에서 데이터를 바라볼 수 있도록 해주는 수단
- 복잡한 쿼리를 단순화하여 재사용하거나, 민감한 데이터를 보호하기 위해 생성
- 물리적으로 저장되지 않으며 가상 테이블 형태로 존재
인덱스
검색의 기준이 되는 컬럼만을 뽑아 정렬한 상태를 유지
- 특정 컬럼에 대해 검색 속도를 빠르게 하기 위해 별도의 자료구조(B-tree 등)로 관리
- 인덱스의 각 튜플은 원래 데이터가 저장되어 있는 테이블에 대응하는 튜플의 주소 값을 가지고 있다
- 기본키(PK), 유니크 키(UK)에는 자동으로 인덱스가 생성된다
비정규화(Denormalization)
정규화 작업이 완료된 후 데이터 물리 모델링 과정 중 시스템의 성능 향상, 개발 과정의 편의성, 운영의 단순화를 추구
- 중복은 감수하고 데이터베이스의 성능을 향상시키는 것
수직 분할
속성이 많은 테이블을 사용 빈도/업무 성격에 따라 속성 단위로 나누는 방식
수평 분할
레코드(row) 단위로 조건에 따라 테이블을 나누는 방식
- 엔티티 크기가 감소하여 성능 향상의 효과
엔티티 통합
자주 함께 조회되는 테이블을 하나로 합쳐 조인 비용을 줄이려는 방법
- 조인 연산에 걸리는 시간을 단축
- 중복이 존재할 수 있어 이상(Anomaly) 현상이 발생할 수 있다는 것을 고려
참고
JPA의 이상적인 설계는 DB 종속성을 낮추고 객체 지향적으로 구조화하는 것
- 객체와 객체 사이의 의미 있는 관계 중심으로 설계하는 것이 중요
잔디 속 새싹 하나