JPA를 사용할때 Date타입의 컬럼 사용시 어떤 Java Object를 사용해야하는지에 대한 글이 있어 옮겨 적어봅니다. 원본보기

java.sql.Date, java.sql.Time, java.sql.Timestamp

@Column(name = "DATE_FIELD")
private java.sql.Date dateField;

@Column(name = "TIME_FIELD")
private java.sql.Time timeField;

@Column(name = "DATETIME_FIELD")
private java.sql.Timestamp dateTimeField;

@Column(name = "TIMESTAMP_FIELD")
private java.sql.Timestamp timestampField;

응용 프로그램이 날짜 및 시간 값을 저장하기만 해도 될 경우 사용합니다. 서버 GMT 오프셋과 같이 날짜 및 시간의 확장 된 세부 정보를 저장하거나 다른 지역 또는 시간대에 다른 날짜와 시간을 저장하지 않아도 될 경우에 좋습니다.

java.util.Date

@Temporal(TemporalType.DATE)
@Column(name = "DATE_FIELD")
private java.util.Date dateField;

@Temporal(TemporalType.TIME)
@Column(name = "TIME_FIELD")
private java.util.Date timeField;

@Temporal(TemporalType.TIMESTAMP)
@Column(name = "DATETIME_FIELD")
private java.util.Date dateTimeField;

@Temporal(TemporalType.TIMESTAMP)
@Column(name = "TIMESTAMP_FIELD")
private java.util.Date timestampField;

프로그램의 날짜와 GMT값을 날짜,시간,타임스템프 필드와 함꼐 저장해야하는 경우에 사용합니다. java.util.Date 클래스는 날짜와 시간 정보를 모두 저장할 수 있기 때문에 올바른 TemporalType 속성 (TemporalType.DATE, TemporalType.TIME 또는 TemporalType.TIMESTAMP)이있는 @Temporal 주석이 추가로 필요합니다.

java.util.Calendar

@Column(name = "DATE_FIELD")
@Temporal(TemporalType.DATE)
private java.util.Calendar dateField;

@Column(name = "TIME_FIELD")
@Temporal(TemporalType.TIME)
private java.util.Calendar timeField;

@Column(name = "DATETIME_FIELD")
@Temporal(TemporalType.TIMESTAMP)
private java.util.Calendar datetimeField;

@Column(name = "TIMESTAMP_FIELD")
@Temporal(TemporalType.TIMESTAMP)
private java.util.Calendar timestampField;

국제 날짜및 시간정보 캡처가 필요한 경우 사용하면 좋습니다. java.util.Date 클래스와 마찬가지로 @Temporal주석이 필요합니다.

일반적으로 개발할때는 java.sql.Timestamp만 사용해도 충분하겠네요 :)

정규화란?

데이터베이스의 설계에서 중복을 최소화 하게 데이터를 구조화

정규화의 목표

• 데이터의 삽입,삭제,갱신 이상 제거
• 자료저장 공간 최소화

정규화 단계

제1정규화(1NF)

• 모든 속성은 반드시 하나의 값을 가짐(not null, 반복형태 X).
• 레코드들은 서로 간에 식별 가능해야 합니다..

제2정규화(2NF)

• 식별자가 아닌 모든 속성들은 식별자 전체 속성에 완전 종속되어야 합니다(완전함수종속).

제3정규화(3NF)

• 2차 정규형을 만족하고 식별자를 제외한 나머지 속성들 간의 종속이 존재하면 안됩니다.

예제

학습 암기용 목적의 포스팅입니다.
자세한 내용은 엔터티(Entity), 속성(Attribute), 관계(Relationship)를 참고하세요.

1. Entity

Entity 개념

저장되기 위한 어떤 집합적인 것(Thing:사람,장소,물건,사건,개념).

출처 : http://tech.devgear.co.kr/db_kb/324

Entity 특징

1. 업무에 필요한 정보
2. 의미있는 식별자에 의해 인스턴스는 1개씩만 존재(중복배제)
3. 2개이상의 인스턴스 집합으로 구성
4. 업무프로세스에 의해 이용되어야 함
5. 속성을 포함해야 함(식별자만 있으면 의미없음)
6. 관계가 존재해야함

Entity 분류

• 유무(有無)형에 따른 분류

• 발생시점에 따른 분류

2. Attribute

엔터티, 인스턴스, 속성, 속성값의 관계

1. 한 개의 엔터티는 두 개 이상의 인스턴스의 집합.
2. 한 개의 엔터티는 두 개 이상의 속성을 가짐.(식별자 외에 1개이상 필요)
3. 한 개의 속성은 한 개의 속성값을 가짐.

속성의 특징

• 업무에 필요한 정보
• 주식별자에 함수적 종속성
• 한 개의 속성값만 가짐, 다중값일 경우 별도의 엔터티를 이용하여 분리 필요

속성의 분류

• 특성에 따른 분류

• 엔터티 구성방식에 따른 분류

도메인(Domain)

속성이 가질 수 있는 값의 범위

3. Relationship

관계의 정의

인스턴스 사이의 논리적인 연관성

관계의 패어링

엔터티 안에 인스턴스가 개별적으로 관계를 가지는것
패어링의 집합 -> 관계

관계의 표기법

• 관계명(Membership) : 관계의 이름
• 관계차수(Cardinality) : 1:1, 1:M, M:N
• 관계선택사양(Optionality) : 필수관계(not null), 선택관계(nullable, O를 표시)

데이터 모델링이란?

시스템 구축을 위해 업무의 데이터를 분석하는 방법, 명확하게 표현하는 추상화 기법

중요성

• 파급효과(Leverage) : 데이터 구조가 프로젝트 막바지에 바뀌게 되면 영향도가 큽니다.
• 요구사항의 간결한 표현(Conciseness) : 요구사항 파악하기 좋고, 많은 관련자들이 소통하기 좋습니다.
• 데이터 품질(Data Quality) : 데이터는 시스템의 자산. 정확성이 떨어지는 데이터는 가치가 없습니다.

유의점

중복을 피하고, 유연해야하며, 일관성있어야 합니다.

데이터 모델링 단계

• 개념적 데이터 모델링 : 핵심 엔터티와 그들 간의 관계를 찾고 엔터티-관계 다이어 그램을 생성합니다.

※ 출처 : http://dbteam6.pbworks.com/f/1179078501/%EC%A7%84%EC%A7%9C%EC%A7%84%EC%A7%9C%EC%B5%9C%EC%A2%85.jpg

• 논리적 데이터 모델링 : 실질적으로 프로젝트에서 사용할 비지니스 정보의 논리적인 구조와 규칙을 명시하는 단계로 실질적으로 모델링을 완료하는 단계입니다.(정규화 활동이 포함)

※ 출처 : http://cfs9.tistory.com/upload_control/download.blog?fhandle=YmxvZzE5NDM0MkBmczkudGlzdG9yeS5jb206L2F0dGFjaC8wLzc5LmdpZg%3D%3D

• 물리적 데이터 모델링 : 논리모델에서 설계된 내용을 실제 물리적으로 어떻게 표현될지를 정합니다.

※ 출처 : https://upload.wikimedia.org/wikipedia/commons/thumb/b/b4/Data_model_in_ER.png/700px-Data_model_in_ER.png

데이터 모델링 구조 및 독립성

데이터 모델링의 구조와 독립성에 대한 여러가지 설명이 있지만 아래 두 그림으로 딱 설명이 되는것 같습니다.

※ 출처 : http://cfile28.uf.tistory.com/image/2119243556BD75431EB784

※ 출처 : http://cfile233.uf.daum.net/image/2056933C4F60B0312DC599

• 외부스키마(외부단계)는 S/w, 개발자가 직접 접근하는 DB View입니다.
• 개념스키마(개념적단계)는 전체 DB를 기술합니다.
• 내부스키마(내부적단계)는 물리적 장치에 데이터가 실제적으로 저장되는 방법을 표현합니다.

각 독립성은 각 스키마가 변경되더라도 서로 영향을 끼치지 않아야 한다는 의미입니다.

• 논리적 독립성 : 개념스키마가 변해도 외부스키마는 변하지 않도록 지원해야함.
• 물리적 독립성 : 내부스키마가 변해도 개념스키마가 변하지 않도록 지원해야함.

사상은 Mapping이라고 부르는것이 더 이해하기 쉽습니다. 각 저장구조가 바뀐다면 Mapping정보가 바뀌어야 독립성이 유지됩니다.

• 논리적사상 : 외부뷰는 개념뷰에서 Mapping된 정보
• 물리적사상 : 개념뷰는 내부뷰에서 Mapping된 정보

git log의 유용하게 쓰이는 몇몇 옵션들을 정리해 봅니다.
자세한 사용법은 Git의 기초 - 커밋 히스토리 조회하기를 참고하세요.

출력 log 제한

git log -(n)

최근 N개의 log만 출력합니다.

$ git log -2 --pretty=oneline
7343a5f82686c8c94800ddf8d2cffb30f6160243 modify m3
5a65f7acf00b6c18285bc0396d463f6a7c506c91 modify m2

git log --since[after,until,before]

특정 날짜 이전/이후 commit만 조회합니다.

$ git log --since="2017-01-29"
commit 7343a5f82686c8c94800ddf8d2cffb30f6160243
Author: unknown <pptwenty@gmail.com>
Date:   Mon Jan 30 22:54:30 2017 +0900

    modify m3

git log --author[committer]

특정 저자/커미터의 commit만 조회합니다.

$ git log --author=unknown
commit 7343a5f82686c8c94800ddf8d2cffb30f6160243
Author: unknown <pptwenty@gmail.com>
Date:   Mon Jan 30 22:54:30 2017 +0900

    modify m3

git log -- [path1] [path2] ...

특정 경로(폴더or파일)의 변경사항에 대해서만 조회합니다.

$ git log -p -- ./w.txt ./v.txt ./work
commit 169f19e36a4360c6a587e146a104e092a62ffc04
Author: unknown <pptwenty@gmail.com>
Date:   Mon Jan 30 23:32:48 2017 +0900

    work add

diff --git a/work/w1.txt b/work/w1.txt
new file mode 100644
index 0000000..e69de29

commit 6b1dbc9c20ad9be3cea60e4cf467328141b17180
Author: unknown <pptwenty@gmail.com>
Date:   Sun Jan 29 23:49:28 2017 +0900

    v2

diff --git a/v.txt b/v.txt
index 626799f..8c1384d 100644
--- a/v.txt
+++ b/v.txt
@@ -1 +1 @@
-v1
+v2

diff 내용 같이 보기

git log -p --word-diff --stat

$ git log -p --word-diff --stat -1
commit 7343a5f82686c8c94800ddf8d2cffb30f6160243
Author: unknown <pptwenty@gmail.com>
Date:   Mon Jan 30 22:54:30 2017 +0900

    modify m3
---
 m.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/m.txt b/m.txt
index 5895249..86afc2c 100644
--- a/m.txt
+++ b/m.txt
@@ -1,4 +1,4 @@
m3
m4-1
[-m5-2-]{+m5-3+} mmmmmm [-aaaaaa-]{+aaxxaa+}
m6

출력 log내용 형식 변경

git log --pretty=[OPTION] --abbrev-commit

--pretty옵션 값은 oneline, short, full, fuller가 있습니다.
oneline은 commit 내용을 한 줄로 표시(Hash값 , log 메시지)하며 나머지 옵션은 기본 log정보에서 추가정보를 가감합니다. --abbrev-commit는 log HASH키 값을 처음 몇 자만 보여주도록 합니다.
※ --pretty=oneline --abbrev-commit의 경우 --oneline으로 대신 쓸 수 있습니다.

$ git log --pretty=oneline -1
7343a5f82686c8c94800ddf8d2cffb30f6160243 modify m3
$ git log --pretty=oneline --abbrev-commit -1
7343a5f modify m3
$ git log --pretty=fuller -1
commit 7343a5f82686c8c94800ddf8d2cffb30f6160243
Author:     unknown <pptwenty@gmail.com>
AuthorDate: Mon Jan 30 22:54:30 2017 +0900
Commit:     unknown <pptwenty@gmail.com>
CommitDate: Mon Jan 30 22:54:30 2017 +0900

    modify m3

git log --pretty=format:"%h %s" --graph

--pretty=format옵션은 필요한 정보에 대해 특정 format으로 표시하는데 %h는 log의 HASH키 값을 줄여서 보여주며 %s는 log 메시지를 보여줍니다.
※HASH키 전체값을 보고 싶을 경우 %H옵션을 사용합니다.
--graph 옵션은 branch와 merge한 내역을 시각화 하여 보여줍니다.

$ git log --pretty=format:"%h %s" --graph
* 7343a5f modify m3
* 5a65f7a modify m2
* 01c75b6 modify m
*   ae65735 Merge branch 'work2'
|\
| * 6b1dbc9 v2
| * aa8dc59 v1
|/
*   0604c1e Merge branch 'work1'
|\
| * 277030f w2
| * 4d72d03 w1
|/
* 4283fad m3
* 08e8d8d m2
* 4820c18 m1