필요한 기능들은 README.md에 작성해보았고 이제 이 기능들을 구현하기 위해서 필요한 테이블 설계를 진행해보려고 한다.
soeun135/GiftFunding: 선물하기 펀딩 프로젝트 (11.13 ~ 12.15) (github.com)
GitHub - soeun135/GiftFunding: 선물하기 펀딩 프로젝트 (11.13 ~ 12.15)
선물하기 펀딩 프로젝트 (11.13 ~ 12.15). Contribute to soeun135/GiftFunding development by creating an account on GitHub.
github.com
테이블마다의 관계를 설정할 때 식별/비식별 관계가 존재
- 식별관계 (A개체의 기본키가 B개체의 외래키면서 동시에 기본키도 됨.)
부모 테이블의 기본키 또는 유니크 키를 자식 테이블이 자신의 기본키로 사용하는 관계
부모테이블의 키가 자신의 기본키에 포함되기 때문에 반드시 부모 테이블에 데이터가 존재해야 자식 테이블에 데이터를 입력할 수 있다.
ERD 상에서 실선으로 표시되며 부모테이블에 자식 테이블이 종속된다.
장점 : 자식테이블에 데이터가 존재한다면 부모 데이터도 반드시 존재함을 보장.
단점 : 요구사항이 변경되었을 경우 구조 변경이 어렵다.
- 비식별관계(A개체의 기본키가 B개체의 비기본키 영역에서 외래키가 됨)
부모 테이블의 기본키 또는 유니크 키를 자신의 기본키로 사용하지 않고, 외래 키로 사용하는 관계
자식 데이터는 부모 데이터가 없어도 독립적으로 생성될 수 있다. 부모와의 의존성을 줄일 수 있어서 좀 더 자유로운 데이터 생성과 수정이 가능하다.
ERD상에서 점선으로 표시.
장점 : 변경되는 요구 사항을 유동적으로 수용할 수 있고 부모데이터와 독립적인 자식 데이터를 생성할 수 있다.
단점 : 자식 데이터가 존재해도 부모데이터가 존재하지 않을 수 있다. 데이터의 무결성을 보장하지 않는다,
* 무결성 : 데이터의 정확성, 일관성, 유효성이 유지되는 것을 의미. (현실세계와 DB 사이에)
정확성 - 중복이나 누락이 없는 상태.
일관성 - 원인과 결과의 의미가 연속적으로 보장되어 변하지 않는 상태.
DB에서 데이터 무결성 설계를 하지 않으면 테이블에 중복된 데이터가 존재, 부모와 자식 데이터 간의 논리적 관계 깨짐, 잦은 에러와 재개발 비용 발생 등과 같은 문제가 발생.
* 데이터 무결성 제약조건의 종류와 개념
1. 개체 무결성(Entity integrity)
기본 키 제약이라고도 하며, 테이블은 기본키를 지정하고 그에 따른 무결성 원칙을 지켜야 하는 조건
- 기본키에는 NULL값이 올 수 없음.
- 기본키는 테이블 내에 오직 하나의 값만 존재해야함.
(하나의 테이블 내에 동일한 기본 키를 가진 레코드는 존재할 수 없음.)
2. 참조 무결성(Referential integrity)
외래 키 제약이라고도 하며, 테이블 간의 참조 관계를 선언하는 제약조건
- 외래키의 값은 null 이거나 참조 릴레이션의 기본키 값과 동일해야함.
- 외래 키 속성은 참조할 수 없는 값을 지닐 수 없음.
(외래 키 속성 값이 상위 테이블의 인스턴스에 반드시 존재하거나 null 이어야함)
3. 도메인 무결성 (Domain integrity)
테이블에 존재하는 필드의 무결성을 보장하기 위한 것으로 속성 값이 정의된 도메인에 속한 값이어야 한다는 규정.
필드의 타입, null값 허용등에 대한 사항을 정이하고 올바른 데이터가 입력되었는지 확인.
ex) 주민번호 필드에 문자가 입력되어도 도메인 무결성이 깨진 것.
4. Null 무결성
테이블의 특정 속성 값이 Null이 될 수 없게 하는 조건
5. 고유 무결성
테이블의 특정 속성에 대해 각 레코드들이 갖는 값들이 서로 달라야 하는 조건
6. 키 무결성
하나의 테이블에는 적어도 하나의 키가 존재해야한다는 조건
7. 관계 무결성
테이블의 어느 한 레코드 삽입 가능 여부 또는 한 테이블과 다른 테이블의 레코드들 사이의 관계에 대한 적절성 여부를 지정한 조건.
마스터 데이터 & 트랜잭션 데이터
- 트랜잭션 데이터
- 시간과 함께 생성되는 데이터를 기록한 것
- 한 번 기록하면 시간과 함께 생성되기에 변화하지 않는다.
- 트랜잭션 데이터는 트랜잭션에서 수집한 정보이다.
거래 진행 시간, 발생 장소, 구매한 항목의 기준 소매 가격, 사용된 지불 방법, 할인(있는 경우), 거래와 관련된 기타 항목이 기록
ex) 판매 테이블
- 마스터 테이블
- 트랜재션에서 참고되는 각종 정보 테이블
- 상황에 따라 다시 쓰임
- 마스터 데이터는 데이터 분석이 수행되는 매개변수를 고려하여 해당 트랜잭션이 수행되는 실제적이고 중요한 비즈니스 개체
ex) 고객 테이블, 상품 테이블, 점포 테이블
대충 설계를 마쳤고 데이터 타입을 넣어줘야하는데 나는 MYSQL을 사용할 것이기 때문에 여기에 맞는 데이터 타입으로 넣어줘야한다 !
문자형 데이터타입
| 데이터 유형 | 정의 |
| CHAR(n) | 고정 길이 데이터 타입(최대 255byte)- 지정된 길이보다 짦은 데이터 입력될 시 나머지 공간 공백으로 채워진다. |
| VARCHAR(n) | 가변 길이 데이터 타입(최대 65535byte)- 지정된 길이보다 짦은 데이터 입력될 시 나머지 공간은 채우지 않는다. |
| TINYTEXT(n) | 문자열 데이터 타입(최대 255byte) |
| TEXT(n) | 문자열 데이터 타입(최대 65535byte) |
| MEDIUMTEXT(n) | 문자열 데이터 타입(최대 16777215byte) |
| LONGTEXT(n) | 문자열 데이터 타입(최대 4294967295byte) |
| JSON | JSON 문자열 데이터 타입 - JSON 형태의 포맷을 꼭 준수해야 한다. |
숫자형 데이터 타입
| 데이터 유형 | 정의 |
| TINYINT(n) | 정수형 데이터 타입(1byte) -128 ~ +127 또는 0 ~ 255수 표현할 수 있다. |
| SMALLINT(n) | 정수형 데이터 타입(2byte) -32768 ~ 32767 또는 0 ~ 65536수 표현할 수 있다. |
| MEDIUMINT(n) | 정수형 데이터 타입(3byte) -8388608 ~ +8388607 또는 0 ~ 16777215수 표현할 수 있다. |
| INT(n) | 정수형 데이터 타입(4byte) -2147483648 ~ +2147483647 또는 0 ~ 4294967295수 표현할 수 있다. |
| BIGINT(n) | 정수형 데이터 타입(8byte) - 무제한 수 표현할 수 있다. |
| FLOAT(길이, 소수) | 부동 소수형 데이터 타입(4byte) -고정 소수점을 사용 형태이다. |
| DECIMAL(길이, 소수) | 고정 소수형 데이터 타입고정(길이+1byte) -소수점을 사용 형태이다. |
| DOUBLE(길이, 소수) | 부동 소수형 데이터 타입(8byte) -DOUBLE을 문자열로 저장한다. |
날짜형 데이터 타입
| 데이터 유형 | 정의 |
| DATE | 날짜(년도, 월, 일) 형태의 기간 표현 데이터 타입(3byte) |
| TIME | 시간(시, 분, 초) 형태의 기간 표현 데이터 타입(3byte) |
| DATETIME | 날짜와 시간 형태의 기간 표현 데이터 타입(8byte) |
| TIMESTAMP | 날짜와 시간 형태의 기간 표현 데이터 타입(4byte) -시스템 변경 시 자동으로 그 날짜와 시간이 저장된다. |
| YEAR | 년도 표현 데이터 타입(1byte) |
* DATETIME과 TIMESTAMP에는 차이가 있다.
timestamp는 time_zome에 의존하여 시간이 바뀐다.
Datetime을 사용하는 경우 time_zone이 반영되지 않기 때문에 서울 오전 9시에 작성한 글이 미국으로 Replication 하는 경우 똑같이 오전 9시로 반영. 이런 경우 UTC 지원가능한 timestamp를 사용하는 것이 더 좋음.
또 다른 차이
Datetime 은
- 1000-01-01 00:00:00부터 9999-12-31 23:59:59까지 지원
Timestamp는
- 1970-01-01 00:00:01부터 2038-01-19 03:14:07까지 지원
- Index가 더 빠르게 생성된다.
* 타입 고를 때 유의할 점
1. 타입은 작을 수록 좋다
데이터를 저장하고 표현하는데 문제가 없는 데이터 타입 중 가장 작은 것을 골라야한다.
하지만 저장할 값의 크기를 너무 작게 추정하지 않도록 주의.
2. 타입은 단순한게 좋다.
간단한 데이터 타입을 처리할수록 CPU 사이클을 덜 소비한다. 문자비교 보다는 정수 비교가 비용이 더 저렴하다. 날짜와 시간은 문자열로 저장하지말고 MySQL의 내장.
3. 가능하면 NULL을 쓰지말자
컬럼은 되도록 NOT NULL로 정의. NULL허용 컬럼은 저장 공간도 더 많이 사용하며 NULL 허용 컬럼을 인덱싱할 때 항목마다 한 바이트 씩 더 들어간다.
* BOOLEAN 형태는 5버전대부터 사용이 가능하고 자료형을 BOOLEAN(BOOL)타입으로 정의하면 1바이트의 TINYINT(1) 타입으로 정의된다.
1차로 만들어본 ERD 설계 리뷰 요청까지 완료.
참고
https://medium.com/daangn/mysql-boolean-%EC%BB%AC%EB%9F%BC-7abd9b35c664
'프로젝트' 카테고리의 다른 글
| GiftFunding) Spring Security를 이용한 로그인 구현 (1) | 2023.11.23 |
|---|---|
| GiftFunding) 예외 처리하기 (@ExceptionHandler, @RestControllerAdvice) (0) | 2023.11.21 |
| GiftFunding) @EntityListeners, @EnableJpaAuditing 으로 생성 날짜, 수정 날짜 자동 입력하기 (0) | 2023.11.21 |
| GiftFunding) 인텔리제이 DB 연결 (Mysql) (0) | 2023.11.21 |
| GiftFunding) 프로젝트 셋업 (1) | 2023.11.16 |
