모델링 ( modeling ) 이란?
현실 세계의 시스템이나 프로세스를 컴퓨터 시스템 내에서 표현하기 위해 추상화하는 과정을 의미한다. 이 과정에서 중요한 정보를 식별하고, 해당 정보 간의 관계를 정의하여, 데이터 구조나 알고리즘 등을 설계한다. 모델링은 소프트웨어 개발 과정에서 요구 사항 분석, 설계, 구현 전 단계에서 중요한 역할을 한다. 특히, 데이터베이스 모델링은 정보 시스템의 데이터 구조를 설계하는 데 중점을 둔다.
DB 존재하는 데이터 타입과 자바에서 사용하는 데이터 타입은 일치 하지 않는다. DB 세상에 있는 존재들을 자바 세상에 존재할 수 있도록 모델링 해보자.
ORM (Object-Relational Mapping)
ORM은 객체-관계 매핑을 의미하며, 객체 지향 프로그래밍 언어를 사용하여 생성된 객체와 관계형 데이터베이스의 테이블 간의 매핑을 가능하게 하는 프로그래밍 기법이다. ORM을 사용하면, 개발자는 SQL 쿼리를 직접 작성하는 대신, 객체의 속성과 메서드를 통해 데이터를 조작할 수 있다. 이로 인해 개발자는 데이터베이스 구조보다는 비즈니스 로직에 더 집중할 수 있으며, 코드의 가독성과 유지보수성이 향상된다.
ORM의 대표적인 예로는 Java의 Hibernate, Python의 SQLAlchemy, Ruby의 ActiveRecord 등이 있다.
TRM (Table-Relational Mapping)
TRM(Table-Relational Mapping)은 테이블 간의 관계를 매핑하는 기법으로 언급되기도 하지만, 일반적으로 널리 사용되는 용어나 개념은 아니다. 대신, 데이터 모델링 과정에서 테이블 간의 관계(예: 일대일, 일대다, 다대다)를 정의하고 구현하는 것이 주요 초점이다. TRM이라는 용어 대신, 데이터베이스 설계와 관계형 데이터 모델링에서 이러한 관계를 설계하는 과정이 중요하다.
테이블 설계
-- 데이터 베이스 생성
-- mybank
create database mybank;
use mybank;
-- 외래키 지정 안함...
-- 유저 테이블 설계
create table user_tb(
id int auto_increment primary key,
username varchar(50) not null unique,
password varchar(100) not null,
fullname varchar(50) not null,
created_at timestamp not null default now()
);
desc user_tb;
-- 계좌 정보 테이블
create table account_tb(
id int auto_increment primary key,
number varchar(30) not null unique,
password varchar(30) not null,
balance bigint not null comment '계좌잔액',
created_at timestamp not null default now(),
user_id int
);
desc account_tb;
-- 거래내역에 ID 값이 필요 (id)
-- 거래 금액 (amount)
-- 출금계좌 ID
-- 입금계좌 ID
-- 출금 요청 후 계좌 잔액
-- 입금 요청 후 계좌 잔액
-- 거래 시간
create table history_tb(
id int auto_increment primary key comment '거래내역 ID',
amount bigint not null comment '거래금액',
w_account_id int comment '출금 계좌 ID',
d_account_id int comment '입금 계좌 ID',
w_balance bigint comment '출금 요청 후 계좌 잔액',
d_balance bigint comment '입금 요청 후 계좌 잔액',
created_at timestamp not null default now()
);
desc history_tb;
샘플 데이터 입력 및 데이터의 이해
insert into user_tb(username, password, fullname, created_at)
values('길동', '1234', '고', now());
insert into user_tb(username, password, fullname, created_at)
values('둘리', '1234', '애기공룡', now());
insert into user_tb(username, password, fullname, created_at)
values('마이', '1234', '콜', now());
select * from user_tb;
-- 기본 계좌 등록
insert into account_tb
(number, password, balance, user_id, created_at)
values('1111', '1234', 1300, 1, now());
insert into account_tb
(number, password, balance, user_id, created_at)
values('2222', '1234', 1100, 2, now());
insert into account_tb
(number, password, balance, user_id, created_at)
values('3333', '1234', 0, 3, now());
select * from account_tb;
-- 거래 내역 등록 연습
-- 가상 현재 잔액
-- 1111계좌는 1000원
-- 2222계좌는 1000원
-- 3333계좌는 0원
-- 1, 이체 내역을 기록
-- 1111번 계좌에서 2222번계좌로 100원 이체한다.
insert into history_tb(amount, w_balance, d_balance, w_account_id, d_account_id, created_at)
values(100, 900, 1100, 1, 2, now());
-- 2. ATM 기기에서 출금
-- 1111 계좌에서 100원만 출금하는 히스토리를 만들어 보세요
insert into history_tb(amount, w_balance, d_balance, w_account_id, d_account_id, created_at)
values(100, 800, null, 1, null, now());
-- 3. ATM 기기에서 입금
-- 1111 계좌로 500원만 입금하는 히스토리를 만들어 보세요
insert into history_tb(amount, w_balance, d_balance, w_account_id, d_account_id, created_at)
values(500, null, 1300, null, 1, now());
select * from history_tb;
select * from account_tb;
select * from user_tb;
테이블 기반으로 모델링 해보기
package com.tenco.bank.repository.model;
import java.sql.Timestamp;
import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Data;
import lombok.NoArgsConstructor;
import lombok.ToString;
@Data
@NoArgsConstructor
@AllArgsConstructor
@Builder
@ToString
public class User {
private Integer id;
private String username;
private String password;
private String fullname;
private Timestamp createdAt;
}
package com.tenco.bank.repository.model;
import java.sql.Timestamp;
import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Data;
import lombok.NoArgsConstructor;
import lombok.ToString;
@Data
@NoArgsConstructor
@AllArgsConstructor
@Builder
@ToString
public class Account {
private Integer id;
private String number;
private String password;
private Long balance;
private Integer userId;
private Timestamp createdAt;
// 출금 기능
public void withdraw(Long amount) {
// 방어적 코드
this.balance -= amount;
}
// 입금 기능
public void deposit(Long amount) {
this.balance += amount;
}
// 패스워드 체크
// 잔액 여부 확인
// 계좌 소유자 확인 기능
}
package com.tenco.bank.repository.model;
import java.sql.Timestamp;
import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Data;
import lombok.NoArgsConstructor;
import lombok.ToString;
@Data
@NoArgsConstructor
@AllArgsConstructor
@Builder
@ToString
public class History {
private Integer id;
private Long amount;
private Long wBalance;
private Long dBalance;
private Integer wAccountId;
private Integer dAccountId;
private Timestamp createdAt;
}
!! 아래 부분 반드시 확인
DTO (Data Transfer Object)
DTO(Data Transfer Object)는 계층 간 데이터 교환을 위해 사용하는 객체입니다. 주로 데이터베이스와 비즈니스 로직 사이, 또는 네트워크 연결을 통해 데이터를 전송할 때 사용됩니다. DTO는 여러 데이터 항목을 하나의 객체로 묶어 전달함으로써 메소드 호출 시 인자의 수를 줄이고, 데이터 관리를 효율적으로 할 수 있게 도와줍니다. 주로 getter와 setter 메소드를 포함하며, 로직을 포함하지 않는 순수한 데이터 객체입니다. DTO는 애플리케이션의 다른 계층 사이에서 데이터를 운반하는 데 초점을 맞춥니다.
VO (Value Object)
VO(Value Object)는 값의 불변성을 가지는 객체를 의미합니다. VO는 DTO와 유사하게 데이터를 담는 역할을 하지만, VO는 주로 값 객체의 개념에 초점을 맞춥니다. 이는 도메인 모델에서 값의 특성을 나타내는 데 사용되며, 생성 후 그 상태가 변경되지 않도록 설계됩니다. VO는 동등성(equality)을 기준으로 비교될 때, 객체의 속성 값이 모두 같다면 같은 객체로 간주됩니다. VO는 비즈니스 로직 내에서 값의 불변성을 보장하며, 복잡한 값을 표현하는 데 유용합니다.
DTO (Data Transfer Object) 와 Entity 에 차이점을 반드시 이해하자
DTO (Data Transfer Object)
목적: DTO는 계층 간 데이터 전송을 목적으로 사용된다. 예를 들어, 클라이언트-서버 간 또는 서비스 계층과 프레젠테이션 계층 사이에서 데이터를 주고받을 때 사용한다.
특성: DTO는 로직을 포함하지 않는 순수한 데이터 컨테이너이다. 오직 데이터 전송에 필요한 필드와 그 필드에 대한 게터와 세터 메소드만을 포함합한다.
가변성: DTO는 특정 상황에 맞게 데이터를 담기 위한 구조이므로 필요에 따라 가변적일 수 있다.
Entity
목적: Entity는 데이터베이스의 테이블에 대응되는 객체로, 주로 ORM(Object-Relational Mapping) 프레임워크에서 사용된다. Entity는 데이터의 지속적인 저장과 검색을 위한 모델을 나타낸다.
특성: Entity 객체는 데이터베이스의 테이블 구조를 반영하며, 해당 테이블의 행(row)을 객체화한 것이다. Entity는 비즈니스 로직을 포함할 수 있으며, 데이터의 상태와 행위를 캡슐화한다.
가변성: Entity는 데이터베이스 내의 데이터를 나타내기 때문에, 생명 주기를 가지며 상태가 변할 수 있다. ORM 프레임워크를 사용하면, Entity의 상태 변경을 통해 데이터베이스의 데이터를 관리할 수 있다.
동등성: Entity는 주로 식별자(ID)에 의해 구별된다. 즉, 동일한 ID를 가진 두 Entity 객체는 동일하다고 간주된다.
DTO와 Entity의 차이점
용도와 책임: DTO는 계층 간 데이터 전송을 위한 간단한 데이터 컨테이너이며, Entity는 데이터베이스의 데이터를 모델링하고 관리하는 데 사용된다.
로직 포함 여부: DTO는 보통 로직을 포함하지 않는 반면, Entity는 비즈니스 로직 또는 데이터 관련 로직을 포함할 수 있다.
수명 주기: DTO는 전송하는 동안만 존재하는 일시적인 객체이며, Entity는 데이터베이스에 저장되어 애플리케이션의 생명 주기 동안 지속된다.
동등성 기준: DTO의 동등성은 그 내용에 의해 결정될 수 있지만, Entity의 동등성은 주로 고유 식별자(ID)에 의해 결정된다.
'Spring boot > Bank App 만들기(deployment)' 카테고리의 다른 글
Bank App 만들기 ( deployment ) - 화면 구현2 ( 레이아웃 분리 ) (0) | 2024.08.07 |
---|---|
Bank App 만들기 ( deployment ) - 화면 구현1 ( 템플릿 가져오기 ) (0) | 2024.08.07 |
Bank App 만들기 ( deployment ) - 코딩 컨벤션 ( Coding Convention ) (0) | 2024.08.05 |
Bank App 만들기 ( deployment ) - 패키지 설정 (0) | 2024.08.05 |
Bank App 만들기 ( deployment ) - 디자인 시안 확인 (0) | 2024.08.05 |