devNote

포린키 생성 실패

메시지 내용

2017-10-20 14:53:53 c8ca8b70 Error in foreign key constraint of table CYBER_EDU_MUSEUM_UPDATE/#sql-532_1dca:

 FOREIGN KEY (`DSPY_SIL_CODE`, `PART_NO`) REFERENCES `JNT_DSPY_PART` (`DSPY_SIL_CODE`, `PART_NO`):

Cannot find an index in the referenced table where the

referenced columns appear as the first columns, or column types

in the table and the referenced table do not match for constraint.

Note that the internal storage type of ENUM and SET changed in

tables created with >= InnoDB-4.1.12, and such columns in old tables

cannot be referenced by such columns in new tables.

See http://dev.mysql.com/doc/refman/5.6/en/innodb-foreign-key-constraints.html

for correct foreign key definition.

내가 찾아봐서 해결한 방법은

컬럼에 utf8_unicode_ci , utf8_general_ci 두개를 참조 컬럼과 외래키 컬럼의 콜렉션타입을 다르게 해서 였다.

각각의 테이블 키 컬럼의 타입과 참조 컬럼의 타입을 같게 아무거나 맞춰주니 포린키 생성 성공했다.

utf8_general_ci 에는 악센트 문자가 없어서 엑센트 없는문자로만 나온다네요.

utf8_general_ci로 해야 속도가 빠르다고는 한다. 

제일 중요한건 한가지 타입으로 맞춰주는거.

• Key Entity
• Main Entity
• Action Entity
• Production Entity

Key Entity

• 부모 Entity가 존재하지 않음
• 성능 형성에 중요한 역할을 수행
• Join시 자주 사용됨
• 고객, 제휴사, 가맹점 등.
• 실체 엔터티라고 함.
• 실제 물체에 대한 본질적인 데이터를 관리하는 엔터티

Main Entity

• 부모엔터티와 자식 엔터티를 모두 가지고 있다.
  
• 카드거래내역, 카드 마스터
• 대용량 테이블일 확률이 높다.(최적화 고려대상)
• 행위엔터티 라고함
• 실체의 업무행위나 활동에 의해서 발생된 원천 데이터를 관리하는 엔터티
• 행위엔터티의 생성 기준은 '누가, 무엇을 언제 어떻게' 이다. 누가, 무엇을 해당하는 것이 실체 엔터티이다.
• 엔터티의 교차 엔터티가 행위엔터티다.
• 실체와 행위가 일대일관계일지라도 성격이 다르면 별개의 엔터티로 설계하는것이 바람직하다.

이력은 선분이고 현재의 순간은 점이므로 선분이다.

과거에 비해 현저하게 오랜 기간을 관리해야 한다는 것은 결코 함부로 결정 해서는 안된다.

모든 업무는 언제 시작해서 언제 끝났는지에 과한 정보가 기록되어 있다.

예)주민등록증의 뒷면 주소변경란은 이사를 가서 주소 이력 정보가 기입된다.

예)환율

이력 관리 대상 선정

이력을 관리한다는것은 관리하지 안을때와 비교해서 많은 비용이 들어간다.

이력의 관리 필요성 검증을 거쳐야한다.

이력 데이터의 종류

발생 이력데이터

어떤 데이터가 발생할 때마다 이력 정보를 남겨야만 한다면 이력은 발생 이력이라고 본다.

(이벤트가 발생할때에만 이력데이터를 발생하는 방법이 있고, 이력이 발생하지 않더라도 날마다 데이터를 생성하는 경우도 있다.)

변경 이력데이터

데이터가 변경될 때마다 변경 전과 후의 차이를 확인해야 한다면 변경 이력을 남길 수 있다.

진행 이력데이터

업무의 진행에 따라 이데이터를 이력 정보로 남겨야만 하는 경우.

가장 대표적인 것이 바로 주문과 같은 업무처리.(구매신청->입금완료->배송준비중->배송중->배송완료,주문취소)각 업무처리 단계가 언제 누구에 의해서 처리되고, 현단계는 무엇인지에 관한 정보가 필요한 경우.

이력관리 형태

시점이력 : 데이터의 변경이 발생한 시각만을 관리 (특점 시점의 데이터를 추출하고자 할 경우에 불필요한 작업(모두읽어 MAX를 구함)을 수행하게  된다.)

선분이력 : 데이터 변경의 시작 시점부터 그 상태의 종료 시점까지 관리

선분이력 관리 유형

인스턴스 레벨이력관리(ROW LEVEL) : 하나의 인스턴스의 어떤 변경이라도 발생하면 전체 인스턴스를 새롭게 생성하는 방식의 이력관리 유형

• 한번의 액세스로 스냅샷을 참조하는 것이 가능하다. 즉, 한번의 액세스로 해당 시점의 모든 데이터를 참조하는 것이 가능하다.
• 로그성 데이터를 저장할 목적인 경우 적당한 방법이다.
• 다른 이력 관리 유형에 비해서 저장하기가 쉽다.
• 하나 이상의 컬럼에 변경이 발생했을때 이벤트가 모호해진다는점(어떤 컬럼이 변경됬는지 구분이 어렵다.)
• 만약 이벤트가 자식정보를 가지게 된다면 매우 치명적이다. 즉 각각의 이벤트가 하위의 데이터(엔터티)를 가지게 된다면 해당 이벤트를 찾기가 매우 어려워진다.
• 이력관리의 다른 유형들에 비해 저장공간의 낭비를 초래할 수 있다.
• 실제 어떤데이터가 변경된 것인지를 찾기 위해서는 과거의 데이터를 머지해서 비교해야만 한다.
• 특정 순간의 스냅샷만 보는게 아니라면 처리가 복잡해지는 경향이 있다.
• 변화가 빈번히 발생하는 상황이라면 고려해 볼 수 있는 유형이다.

속성 레벨이력관리(COLUMN LEVEL) : 이력을 관리할 대상 속성에 변화가 생길 때만 이력을 생성하는 방식.

• 변경이벤트가 매우 분명하게 관리된다. 실제 어떤 데이터가 변경되었는지 분명하다.
• 하나의 이력 관리 엔터티에서 다른 엔터티와 통합 이력 관리가 가능하다.
• 변경된 것만 처리하기 때문에 독립적 처리가 가능하다.
• 변화가 발생할 가능성은 매우 낮으면서 이력 관리 대상 속성은 매우 많은 경우에 사용하는 것이 유리하다.
• 특정 속성들에 변화가 집중되는 경우에 해당 속성에 대해서만 이력을 관리할 수 있기 때문에 유리하다.
• 여러 속성에 대한 이력이 필요할 때 많은 머지가 발생하게 된다.
• 이력관리의 다른 유형들에 비해서 향후 사용될 데이터 액세스 쿼리에서 조건 검색이 조금 어렵다.
• 변화가 너무 많은 경우에는 적용이 곤란하다.

주제 레벨이력관리(SUBJECT LEVEL) : 내용이 유사하거나 연동될 확률이 높은 것별로 인스턴스 레벨 이력을 관리하는 방법

• 인스턴스 레벨과 속성레벨의 장점을 모두 수용하는 형태의 이력관리 형태이다.
• 목적이 분명한 엔터티를 생성함으로써 확장성을 확보할 수 있는 용도로 사용할 수 있다.
• 변경 부분만 처리가 가능하다.(독립적 처리 가능)
• 다른 엔터티와 통합 이력 관리가 가능하다.
• 속성 레벨의 단점을 해소할 수 있다.
• 전체를 참조할 때 인스턴스 레벨에 비해 머지가 발생하는 문제점이 존재한다.
• 부분에 따라 변경 정도의 차이가 심한 경우 유리하다.

선분이력에서 식별자 결정

선분이력을 관리하는 엔터티의 UID를 확정하는 것은 향후에 테이블로 만들어지고 사용될 때의 성능 측면도 고려되야한다.

실제 데이터는 유니크하지만 의미적으로 유니크하지 않은 일이 발생한다. 이러한 부분의 의미적인 유니크를 검증할 수 있는 조치를 병행해야한다.

선분 이력에서 종료점 처리시 주의사항

종료점이 미정이므로 NULL : 논리적으로 타당하지만 비교가 불가능, 인덱스를 하용하지 못하므로 수행속도 저하

수렴하므로 최대치 부여 : 아직 종료되지 않았으므로 무한히 계속되는 것으로 간주, 최대치 부여(9999/12/31), 테이블생성시 기본값 부여, 수행속도에 유리.

• 이력 데이터 관리 방법 (세가지 분류)
  1. 엔터티의 속성 중에서 하나라도 변경되면 변경 전의 전체 인스턴스를 그대로 관리
     • 저장 공간의 낭비
     • 저장이 쉽고 해당 시점의 전체 데이터 조회도 쉽다 (스냅샷)
     • 변경된 속성의 데이터만을 조회하기 어렵고 조회 처리가 복잡해짐
  2. 변경된 속성만을 개별적으로 관리
     • 저장 공간의 절약
     • 변경된 속성이 무엇인지 명확함
     • 속성 별로 하나의 엔터티에서 별도 관리시 이력 관리가 필요한 속성 도출이 어려움
     • 속성 전체를 하나의 엔터티에서 관리시 변경 데이터 저장은 쉬우나, 조회가 어렵고 필요한 속성만이 포함되도록 관리 하기가 어려움
     • 이력 데이터를 관리해야 하는 속성이 광범위 하고 가변적 이라면 하나의 엔터티에서 전체 속성의 이력 데이터를 관리하는 방법이 유용할 수 있음 (이 때도 자주 변경되고 조회도 빈번한 속성은 별도의 엔터티에서 개별적으로 관리하는 것이 좋음)
  3. 유사한 속성을 묶어서 관리
     • 속성 중 내용(도메인)이 유사하거나 같이 사용될 수 있는 속성만으로 별도의 엔터티를 만들고, 해당 속성중 하나라도 변경되면 그 시점의 데이터 인스턴스를 스냅샷으로 관리
     • 인스턴스로 관리하는 방법과 개별 속성으로 관리하는 방법의 장점을 수용한 방식 (잘못 사용되면 단점만을 수용할 수도 있음)
     • 유사한 성격의 이력 데이터가 하나의 엔터티에서 관리되므로 엔터티의 성격이 분명해지는 장점 (효율적)
     • 해당 시점의 전체 인스턴스 조회시 머지(Merge) 발생으로 처리가 어려움

※ 이력 데이터 관리 방법을 하나로 획일화 하는것은 옳지 않음
※ 엔터티의 성격과 요건, 중요도에 맞춰 다양한 방법이 사용되어야 함
※ 요건에 가장 합당한 방법을 채택할 수 있는 힘 필요

① 엔터티 하나로 현재와 과거 데이터 관리

• 하나의 엔티티에서 과거, 현재, 미래 데이터를 함께 관리
• 속성 중 하나라도 변경되면 변경된 데이터로 업데이트 하고, 변경 전 과거 데이터는 새로운 인스턴스로 생성
• 과거 데이터 사용 빈도가 높을때 효과적 이며 현재 데이터만 사용 한다면 엔터티를 분리 하는것이 효율적
• 데이터 모델 관리, 개발(하나의 프로그램), 데이터 생성이 편리함

  하나의 엔터티	두 개의 엔터티
  하위 엔터티를 가질 수 없음 (확장성X)	속성 추가시 두 엔터티 및 두개 프로그램 수정 필요

• 장/단점이 명확하지 않다면 모델의 변경 관리를 위해 하나의 엔터티 고려 가능

  하위 엔터티가 존재할 수 없는 모델 (나쁜사례)
  가정 : 주문 내용의 변경된 데이터를 주문 엔터티에서 관리 하고, 변경은 하루에 한번만 가능

• 변경전 릴레이션
  • 주문

    #주문번호	#변경일자	#배송처
    100	2019-05-05	서울시

  • 주문상품

    #주문번호	#변경일자	#상품코드	주문수량
    100	2019-05-05	1010	1
    100	2019-05-05	1020	3
    100	2019-05-05	1050	2

• 변경후 릴레이션1 (하위 엔터티와 관계가 끊어진 릴레이션)
  • 주문 다음날 100번 주문의 배송처가 집에서 사무실로 변경
  • 주문상품 릴레이션에 변경일자가 2019-05-06 인 데이터가 없기 때문에 주문 상품이 무엇인지 쉽게 알기 어려움 (주문 엔터티에서 변경 직전 인스턴스 추적 필요)
  • 주문

    #주문번호	#변경일자	#배송처
    100	2019-05-05	서울시
    100	2019-05-06	경기도

  • 주문상품

    #주문번호	#변경일자	#상품코드	주문수량
    100	2019-05-05	1010	1
    100	2019-05-05	1020	3
    100	2019-05-05	1050	2

• 변경후 릴레이션2 (하위 엔터티의 이력을 관리하는 릴레이션)
  • 주문상품 (변경일자 업데이트 / 실전선택)

    #주문번호	#변경일자	#상품코드	주문수량
    100	2019-05-06	1010	1
    100	2019-05-06	1020	3
    100	2019-05-06	1050	2

  • 주문상품 (새로운 변경일자로 인스턴스 생성 / 필자선택)

    #주문번호	#변경일자	#상품코드	주문수량
    100	2019-05-05	1010	1
    100	2019-05-05	1020	3
    100	2019-05-05	1050	2
    100	2019-05-06	1010	1
    100	2019-05-06	1020	3
    100	2019-05-06	1050	2

※ 두개 모두 바람직 하지 않음, 하위 엔터티(주문상품)를 돌아다니면서 해당 인스턴스를 변경/추가 하는것은 한계가 있음
※ 하위 엔터티가 존재할 때는 하나의 엔터티에서 변경 데이터를 같이 관리하면 안됨

보통 데이터 조작은 한번 이지만, 조회는 수없이 일어나므로 조회에 최적화 하는것은 의미가 있음

• 좋은사례

  주문 이력 엔터티 (좋은사례)

• 릴레이션
  • 100번 주문의 배송처가 2019-05-06 에 '경기도' 로 변경 된 후 2019-05-07 에 '대전시' 로 변경됨
  • 변경 발생시 하위 엔터티의 데이터는 아무 변함이 없어야 함 (그렇지 않은 경우는 극단 적인 경우를 제외하고 발생 해서는 안되며 모델이 잘못된것)
• 주문

  #주문번호	#변경일자	#배송처
  100	2019-05-07	대전시
  101	2019-05-08	서울시

• 주문이력

  #주문번호	#변경일자	#배송처
  100	2019-05-05	서울시
  100	2019-05-06	경기도

• 주문상품

  #주문번호	#상품코드	주문수량
  100	1010	1
  100	1020	3
  100	1050	2
  101	1010	2

  엔터티 하나로 현재와 과거 데이터 관리 인스턴스 단위로 변경 관리하므로 변경된 속성만을 찾을 수가 없음 해당 인스턴스의 전체 속성을 조회할 때는 적합 시점 데이터를 스냅샷 형태로 보관 하므로 공간을 많이 차지함 데이터 조회가 하나의 엔터티에 집중됨 핵심 실체/행위 엔터티는 하나의 엔터티에서 현재와 과거의 데이터를 관리하면 대개 바람직 하지 않음

• 모델

  현재+과거 엔터티

  • 수수료율 엔터티는 하위 엔터티가 발생하지 않는다. (기준 정보 엔터티)
  • 이런 종류의 기준 엔터티는 대부분 하위 엔터티와 참조 무결성 관계가 성립하지 않는다.
    1. 실제로 참조 무결성 관계가 있는지, 참조 무결성 관계로 관리 하는것이 실익이 있는지 고려 필요
    2. 과거 특정 시점 값을 조회하는 요건이 있을 때 하나의 엔터티에서 관리 하는것이 단순해짐 (하나의 프로그램, 하나의 SQL)
    3. 하나의 엔터티에서 과거와 현재 데이터를 관리할 때는 엔터티명에 "~이력"을 사용하지 않는 것이 일반적
• 모델

  현재와 과거 데이터를 별도로 관리하는 모델

  • 유효시작일자, 유효종료일자는 선분 이력으로 관리 하기 위해 사용하는 속성
  • 과거 특정 시점의 조회가 빈번하고 최적 성능을 요할때 채택
  • 하위 엔터티가 존재하지 않고, 과거 특정 시점의 수수료율이 빈번하게 조회되므로 굳이 두개 엔터티로 나눌 필요는 없음
• 모델

  선분 이력이 아닌 엔터티

  • 성능상의 이슈가 없다면 변경일자를 관리 하는것 으로 충분 (점 이력)
  • 최근의 데이터를 효율적으로 관리하기 위해 사용여부 추출 속성 고려 가능

하루에 두번 이상 변경될 때 변경일자, 시작일자, 종료일자는 연/월/일 만 관리 하므로 데이터가 하루에 한번만 변경 가능, 하루에 두번 이상 변경 될 수 있다면 변경일시, 시작일시, 종료일시 사용

• 모델

  변경순번 속성을 사용한 이력 엔터티

  • 데이터가 하루에 여러번 변경될 수 있을 때 실무에서 변경순번 속성을 사용하나 주 식별자에 순번 속성을 사용해 업무 식별자를 숨기는 것은 가능한 피해야 함
    1. 변경순번은 계좌상품코드, 거래채널코드에 따른 순차적인 번호, 실무에서 무작위로 순번을 사용하는 경우가 빈번(X)
    2. 변경순번을 사용하면 주 식별자에 업무 식별자 성격과 인조 식별자 성격이 섞이게 되어 업무 식별자가 모호해짐
    3. 변경순번 위에 존재하는 주 식별자 속성을 임의대로 정해도 식별이 되므로 기준이 없게 됨 (계좌상품코드 + 변경순번 ==> 식별가능)
    4. 가능한 계좌상품코드 + 거래채널코드 + 변경일자 속성을 주 식별자로 사용 하는 것이 바람직

② 두 개의 엔터티에서 현재와 과거 데이터 별도로 관리

• 변경 되는 속성이 하나라도 발생하면 그 시점의 스냅샷 데이터를 과거 데이터를 관리하는 엔터티로 복사 후 현재 데이터를 관리하는 엔터티 변경
• 핵심 엔터티에는 하나의 엔터티에서 과거와 현재의 데이터를 모두 관리하지 않는다.
  • 하위 엔터터 존재 문제, 데이터 건수가 많아지는 문제

• 모델

  스냅샷 방식의 이력 관리 모델
  두 개의 엔터티에서 현재와 과거 데이터를 분리해 관리하는 기본 모델, 현재[보험계약] / 과거[보험계약이력]

  • 보험계약이력 엔터티는 과거의 데이터를 관리 하기 때문에 엔터티 이름에 "~이력" 을 사용 함
  • 보험계약이력 엔터티는 보험계약 엔터티의 주 식별자를 식별 관계로 상속 받고, 시작일자,종료일자/변경일자 속성을 추가 한다.
  • 보험계약 엔터티 속성 중 하나라도 변경되면 변경 전 데이터를 스냅샷 형태로 보험계약이력 엔터티에 입력하고 (종료일자는 로직에 의해 계산), 보험계약 엔터티에 변경 후 데이터를 반영 한다.
  • 변경된 속성이 무엇인지 알기 어려움
  • 보험계약 엔터티에 하위 엔터티가 존재할 수 있음 (하위 엔터티가 많은 핵심 실체/행위 엔터티에 적용 가능)

• 릴레이션 (현재 데이터와 과거 데이터 각각 관리)
  • 2020-10-10 '12345' 증권의 상품이 'A00' 에서 'A10' 으로 변경되고, 보험가입금액이 '1000'원 에서 '1200'원으로 변경됨
• 보험계약

  #증권번호	상품코드	보험가입일자	보험가입금액
  12345	A10	2020-01-01	1200
  23456	B20	2020-05-04	500

• 보험계약이력

  #증권번호	#유효시작일자	유효종료일자	상품코드	보험가입일자	보험가입금액
  12345	2020-01-01	2020-10-09	A00	2020-01-01	1000

• 릴레이션 (보험계약이력 엔터티에서 현재 데이터도 관리)
  • 현재/과거 데이터를 동시에 조회하는 요건의 중요도(성능과 사용빈도)에 따라 적용할 수 있지만 데이터 중복이 심하게 발생하므로 지양
• 보험계약

  #증권번호	상품코드	보험가입일자	보험가입금액
  12345	A10	2020-01-01	1200
  23456	B20	2020-05-04	500

• 보험계약이력

  #증권번호	#유효시작일자	유효종료일자	상품코드	보험가입일자	보험가입금액
  12345	2020-10-10	9999-12-31	A10	2020-01-01	1200
  12345	2020-01-01	2020-10-09	A00	2020-01-01	1000
  23456	2020-05-04	9999-12-31	B20	2020-05-04	500

  • 하위 엔터티가 존재하지 않는다면 하나의 엔터티에서 관리하는 방법이 나을 수 있음 (필자)
    • 두 개의 엔터티는 모델 형상 관리가 복잡함 (이중 관리)
    • 두 개의 엔터티는 유연성이 좋음 (현재는 하위 엔터티가 없지만 미래에 생길 경우를 대비)
  • 미래까지 고려한 하위 엔터티 존재 여부와, 과거 데이터의 조회 빈도에 따라 하나의 엔터티로 관리할지 두 개로 관리할지 판단

• 서브타입 모델의 이력 관리 방법

  예제1		슈퍼타입과 서브타입을 합친 인스턴스별로 이력데이터 관리(서브타입 개념 반영, 연결된 인스턴스 조회 편리)
  예제2		슈퍼타입과 서브타입별 각각의 이력 데이터 관리(이력 데이터 발생 쉽고, 공간 절약)

③ 변경 속성을 별도의 엔터티로 관리

• 변경되는 속성만을 관리

  계좌비밀번호 속성의 이력 엔터티

  • 계좌비밀번호이력 엔터티에서는 과거의 비밀번호만을 관리하고(~이력), 현재의 비밀번호는 계좌 엔터티에 존재
  • 데이터 값 중복 없음, 데이터 모델의 속성 중복 있으므로 상대적으로 좋지 않지만 업무적으로 현재 비밀번호가 주로 조회 되므로 적정
• 변경되는 속성만을 관리

  계좌비밀번호 변경 내역 엔터티

  • 계좌 엔터티에는 계좌비밀번호 속성이 없음
    • 효율을 위해 계좌비밀번호 속성을 추가해 현재 비밀번호를 중복 관리 고려 가능
  • 현재/과거 비밀번호를 하나의 엔터티에서 관리
    • 계좌비밀번호 엔터티는 계속 발생 하는 내역 엔터티, ~이력 X
    • 과거 특정 시점의 비밀번호를 조회하는 요건이 중요 하다면 변경일자 대신 시작일자+종료일자 속성 적용 가능
• 모델

  여러 유형의 계좌비밀번호 발생 내역

  • 계좌별로 여러개의 비밀번호가 존재하는 경우 (계좌비밀번호.비밀번호구분코드)
  • 현재/과거 비밀번호 : 계좌비밀번호 엔터티
• 모델

  여러 유형의 계좌비밀번호의 발생 내역과 변경 이력

  • 현재 비밀번호 : 계좌비밀번호 엔터티
  • 과거 비밀번호 : 계좌비밀번호이력 엔터티
• 모델

  관계(역할) 이력 관리 모델

  • 계좌관리사원 엔터티에서 계좌를 현재 관리하고 있는 사원과, 과거에 관리했던 사원 데이터를 함께 관리
    • (~이력 X)
    • 과거 관리 사원 조회 빈도를 고려해 선분 이력 구현 (시작일자+종료일자)
    • 현재 계좌 관리 사원을 알려면 항상 계좌관리사원 엔터티와 JOIN 필요
      • 계좌를 가장 많이 관리하고 있는 '홍길동' 사원의 전체 계좌 정보 조회, 지점별 관리자가 관리하는 계좌 숫자와 예수금 총액 화면등에서 성능 문제 발생 가능
• 모델

  추출 속성을 사용한 관계(역할) 이력 관리 모델

  • 현재 계좌관리사원 관련 성능문제를 고려해 계좌 엔터티에 추출 속성 (현재계좌관리사원번호) 적용
  • 대부분 요건은 계좌 엔터티 로 처리 하고, 과거 특정 시점 관리 사원 정보 필요시 계좌 + 계좌관리사원 엔터티로 처리
    • 계좌, 계좌관리사원 엔터티에 중복된 현재 관리 사원 데이터중 계좌관리사원 엔터티 쪽이 원천 데이터이며, 계좌 쪽은 추출된 중복 데이터임

데이터 무결성이 최우선 요소지만 무조건 항상 그런 것은 아니며, 성능을 우선으로 고려해야 하는 경우가 존재

• 모델

  현재와 과거 관리사원을 별도로 관리하는 모델

  • 계좌 엔터티에서는 현재 관리 사원만 관리하고, 과거 관리 사원은 계좌관리사원이력 엔터티에서 관리
    • 계좌관리사원이력 : ~이력 O
    • 계좌.계좌관리사원번호 : 현재~ X
      • 현재,최근,최초 등의 단어가 사용되면 일반적으로 추출 속성
• 모델

  여러 역할을 관리하는 모델

  • 계좌를 관리하는 사원, 계좌를 유치한 사원과 같이 다양한 역할을 계좌관계사원 엔터티와 같이 통합해 관리
    • 계좌관계사원.계좌관계사원구분코드 : 관리사원, 유치사원, 운용사원, 실적사원...
    • 여러 역할을 통합 관리하므로 엔터티명, 속성명에 좀더 일반적인 용어 적용 (관리 -> 관계)
• 모델

  여러 역할을 관리하는 모델에 추출 속성을 적용한 모델

속성 단위로 변경 데이터를 관리하는 이력 방법은 속성의 명확한 정의가 선행 되어야 함 장점 : 엔터티의 성격이 분명해지고 모델을 보고 업무파악이 더욱 쉬워지고, 커뮤니케이션에 많은 도움이 됨 단점 : 속성별 이력 요건 분석이 필요하므로 모델링 기간이 늘어나고, 모델링이 힘들어짐, 인스턴스별로 조회하기 어려움 별도의 엔터티에서 하나의 속성 값이 변하는 데이터를 관리한다는 것은 해당 데이터가 그만큼 중요하다는 의미 엔터티가 증가하게 되므로 꼭 필요하다고 판단될 때만 적용

정규화는 엔터티 개수가 아무리 늘어나더라도 데이터 성격을 명확하게 정의하고 무결성 확보를 위해 반드시 필요

④ 모든 변경 속성을 하나의 통합 엔터티로 관리

• 변경된 모든 속성의 데이터를 하나의 엔터티에서 관리
  • 이력 관리 대상 속성을 코드화해서 관리
  • 코드화 엔터티에 대한 관리 부담 발생 (이력 발생전 기초 데이터 등록, 속성이름 정합성 유지)
  • 이력 엔터티에서 관리할 속성이 보통 명확하지 않은 문제점이 있음
    • 속성별로 상세한 업무 파악이 필요하지 않아 엔터티의 성격이 모호해짐
    • 모델만 봐서는 이력에 대한 업무를 상세하게 파악하기 어려우며 모델의 가독성이 낮음
  • 인스턴스의 스냅샷 저장이 아니므로, 특정 시점의 모든 속성 데이터를 조회하기가 어려움 (개별 속성 조회는 쉬움)
• 유일한장점 : 모델 형상 관리 불필요 (유연성)
  • 다른 엔터티의 변경 이력도 통합해 관리 가능 (유연성↑ / 가독성↓)

• 릴레이션
  • 계좌 번호가 '12345678'인 계좌의 관리 사원이 2021-07-07에 '홍길동' 에서 '김길동' 으로 변경된 후, 2021-12-31 다시 '박길동'으로 변경됨
• 계좌이력속성

  #속성코드	속성명
  100	계좌명
  110	계좌관리사원번호
  120	계좌비밀번호

• 계좌이력

  #계좌번호	#속성코드	#시작일자	종료일자	속성값
  12345678	110	2021-05-05	2021-07-06	홍길동
  12345678	110	2021-07-07	2021-12-30	김길동

• 모델

  변경 속성을 코드로 관리하는 모델

  • 계좌이력속성 엔터티 : 계좌의 속성을 코드로 관리하는 엔터티
    • 계좌 속성 중에 변경되는 속성이 생기면 계좌이력속성 엔터티에 속성코드와 속성명으로 데이터 생성 필요
    • 계좌이력속성.속성명 의 값은 계좌 엔터티의 속성 이름과 일치시켜야 함
• 모델

  이전 속성 값을 관리하는 모델

  • 변경 이전에 어떤 값이었는지를 알아야 할 때 '이전속성값' 추출 속성 적용

여러 단점에도 불구하고 사용하기 편하다는 장점으로 실무에서 자주 사용됨 이 유형의 모델 채택은 업무를 분석하기 어렵거나, 분석할 의사가 별로 없다는 의미로 인식 (필자는 마음이 편치 않음)

• 모델

  동시에 변경된 속성을 관리하는 모델

  • 동일한 업데이트 트랜잭션에 의해 변경된 속성이 무엇인지 알 수 있음
    • 변경순번 속성 값이 같으면 동시에 변경된 속성
    • 일반적으로 ~순번 속성은 인스턴스 유일성을 보장하기 위한 인조 식별자로 사용되는데, 이 모델에서는 같이 변경된 속성을 구분하기 위한 업무 식별자 성격임

• 릴레이션
  • 가장 최근에 함께 변경된 속성은 계좌관리사원('123') 과 계좌비밀번호('2222') 임
  • 계좌 데이터는 세번에 걸쳐 변경됐고, 변경된 속성은 네개 이며, 계좌 비밀번호는 두 번 변경 됨
• 계좌이력속성

  #속성코드	속성명
  100	계좌명
  110	계좌관리사원번호
  120	계좌비밀번호

• 계좌이력

  #계좌번호	#변경순번	#속성코드	변경일자	속성값
  12345678	3	110	2021-07-07	123
  12345678	3	120	2021-07-07	2222
  12345678	2	100	2021-05-05	홍길동
  12345678	1	120	2021-02-10	1111

  • 어떤 속성의 변경 데이터를 이력 관리해야 하는지에 대한 기본적인 요건이 확정되지 않았다면 이력 관리 모델을 유보 하는것이 옳음
    • 요건이 확정되지 않았다고 일반적이고 유연한 모델을 선택하는 것은 안됨

⑤ 유사한 변경 속성들을 묶어서 별도의 엔터티로 관리

• 여러 개의 속성이 하나의 엔터티에서 관리된다는 점을 제외하고 변경된 속성만을 별도의 엔터티에서 관리하는 방법과 유사
• 엔터티의 정체성과 모델의 확장성, 유사 속성의 조회 편이성이 좋아지고, 엔터티도 많이 늘지 않음

  유사한 속성을 묶어서 이력 관리하는 모델

  • 보험계약일자이력 엔터티에서는 보험과 관련된 날짜의 변경 이력을 관리 하고, 보험계약금액이력 엔터티에서는 금액 관련 속성을 이력 관리 한다.
    1. 보험종료일자 속성 값이 변경되면 보험계약일자이력 엔터티에만 한 인스턴스가 생성됨 (특정 시점의 하나의 인스턴스 전체를 조회하기 쉽지 않음)
    2. 유사한 관리 속성으로 말미암아 비교적 데이터 성격이 분명한 엔터티가 생김 (업무 파악 용이성)
    3. 엔터티를 인스턴스 단위로 이력 관리하는 방법과 속성 단위로 이력 관리하는 방법의 장점을 취할 수 있음 (양쪽의 단점만을 취하지 않도록 주의)
  • 요건에 따라 가장 효율적일 수 있지만, 자주 발생할 수 있는 모델은 아님

다섯가지 이력 관리 유형의 장/단점

문서정보

• 이 문서는 구루비에서 작성하였습니다.
• 이 문서를 다른 블로그나 홈페이지에 게재하실 경우에는 출처를 꼭 밝혀 주시면 고맙겠습니다.~^^
• 출처 : http://wiki.gurubee.net/pages/viewpage.action?pageId=28116644&
• 구루비 지식창고의 모든 문서는 크리에이티브 커먼즈의 저작자표시-비영리-동일조건변경허락(BY-NC-SA) 라이선스에 따라 자유롭게 사용할 수 있습니다.

엔티티 식별 : 엔티티자격조건, 엔티티주식별자 임시부여

엔티티 배열 : 

 키엔티티는 외곽, 

 메인엔티티는 업무수행순서에 따라 상에서 하로, 좌에서 우로

 액션엔티티는 키엔티티 최 좌우 측에 또는 메인 엔티티 최 좌우 측에 배치

관계정의 : 관계명, 슈퍼-서브타입관계 식별

기수성 식별

선택성 식별 (

다대다일때 교차실체 사용하여 일대다로 분리

속성의 정의 

 함수정 종속성에 의해 해당하는 엔티티에 배치, 추출속성은 배제

정규화 검토

 1차정규화 : 중복/반복

 2차정규화 : 2개 이상 구성된 복합식별자의 ...

 3차정규화

속성의 특징 -

속성도 일종의 집합

릴레이션도 일종의 속성 

속성들 간은 서로 독립적

 속성들은 반드시 식별자에 종속 : 제2정규형

 속성들간에 종속은 없어야함 : 제3 정규형

속성은 발견과 창조로 도출 

  주변 속성들로부터 연관되는 속성들을 유추하여 도출

속성의 정의

속성의 검증기준

 최소 단위로 분할

 유일 값 존재 검증

 가공값 유무판정 : 추출속성 (단가 * 수량 = 금액) , 단가와 수량은 기초속성 , 금액은 추출속성

 설계속성( 코드등 전산을 위해서 만든 속성)

- 논리 데이터 모델에서는 추출속성은 작성하지 않는게 원칙임.

정규화

 이상 현상을 야기하는 속성간의 종속관계를 제거하기 위해 엔티티를 작은 여러 엔티티로 무손실 분해하는 과정 , DB 설계 최적화 과정.

 정규화 단계별 규칙을 사용하여 속성의 위치를 적절히 하는것

 정규화의 목적 : 반복 배제, 질의에 대한 응답시간을 향상

비정규릴레이션 -> 1차정규형  -> 2차정규형 -> 3차정규형 -> Boyce-Codd 정규형( BCNF) -> 4차정규형 -> 5차정규형

이력관리

점이력, 선분이력

점이력 

 - 로그성 데이터로 이력을 쌓아두고자 할 경우[ 임의 시점에 대한 조회 요구사항이 있음]

 - 이력데이터를 저장하고 이해하기에는 용이하지만 활용상에서 비효율이 많이 나타남

 - 과거 임의의 시점에서의 이력을 재현하기에 비효율이 많이 발생

선분이력

 - 이력관리 대상 속성들이 의미하는 정보가 일정 시점의 정보만을 나타내는 것이 아니라 일정 기간 동안 해당 정보가 유효하다는 의미

 - 임의의 시점의 데이터를 찾고자 하는 요구가 있는 경우에 유용

 - 과거 임의의 시점에서의 이력을 재현하고 활용하는데 매우 효율적임

이력관리유형

 ROW_LEVEL 이력관리 ( 변경일자별 수수료율 등)

 COLUMN_LEVEL 이력관리 (계좌비밀번호 이력 등)

 SUBJECT_LEVEL 이력관리 ( 엔티티구분, 속성 구분 을 나누어 별도로 관리, 이력엔티티, 이력속성)

엔티티관계 정의

• 관계의 의미

• 관계는 정의된 기호를 사용하여 두엔티티 간에 존재하는 업무적 연관성을 표현하는 것으로, 방법론에 따라 표현 방법은 다소 다르지만 표현하고자 하는 내용은 대동소이함.

• 관계 표현을 통해 두 엔티티 간에 존재하는 업무 규칙을 정의

• 관리하고자 하는 업무 영역내의 임의의 두 엔티티 간에 존재할 수 있는 수 많은 관계 중에서 특별히 관리하고자하는 직접적인 관계가 관계로서 의미를 가짐

• 관계의 의미를 정확하게 이해하고 표현할 수 있어야만 데이터 모델링을 통한 정확한 업무 정의가 가능

• 부정확한 관계 표현이나 관계가 아예존재하지 않는 데이터 모델은 데이터에 대한 업무 규칙이 제대로 파악되지 않았음을 의미하며, 이러한 모델에 기반하여 구축된 시스템은 본인의 목적달성이 불가능하고 막대한 유지보수 비용을 발생시키며, 쓸모없는 데이터만 양산하게 됨.

• 관계 정의의 의의

• 집합 간의 업무적 연관성을 관계명과 기호로서 규명

• 검토 및 정의 결과를 기획

• 추후 상세화 및 변경에 대한 베이스라인

• 이해관계자 간 정확한 의사소통

• 적절한 관계 정의는 관련 현업 업무를 효율화할 수 있음.

• 이해 관계자 간의 업무 중복이나 혼선을 조정하기에 용이하고 그 결과를 명확하게 기호로 표현함으로써 관련자 모두가 쉽게 공유하고 업무에 활용이 가능함

• 관계는 데이터를 매개로 한 업무의 흐름과 데이터의 흐름을 규명함

• 관계 정의를 통해 이 집합들에 대해 어떤 업무가 이루어지고 있고, 집합 간의 관계들을 추적하여 데이터 발생 경로와 어떤 경로를 거쳐 데이터가 어떻게 변화하고 진화하는지를 알 수 있어 업무와 데이터의 흐름을 명확하게 이해할 수 있음.

• 관계가 정의되지 않은 엔티티들 간에는 직접적인 연관성이 없음   -> 데이터 발생의 원천을 알 수 없음(어디서온 데이터인지 확인이 불가능함)

• 잘 못 그리면 엔티티의 의미나 업무의 내용이 달라질 수 있음

• 관계 명을 누락하면 애매모호한 관계가 되어버림

• 서브 타입

• SUPER-TYPE이란 SUB-TYPE을 가지는 ENTITY

• SUPER-TYPE은 두 개 이상의 독립적인 SUB-TYPE으로 구성

• SUPER-TYPE은 각 SUB-TYPE들의 공통적인 attribute와 relationship 보유

• SUB-TYPE은 자신이 attribute나 독립적인 relationship을 가진다.

• 자신의 attribute나 relationship을 가지지 않은 SUB-TYPE도 존재 할 수 있으나 이런 경우는 일반적인 attribute로 처리하는 것이 좋다 (차별성)

• SUPER-TYPE의 모든 instance는 SUB-TYPE중 단 하나와 반드시 연결

• SUB-TYPE은 서로 중첩되지 않아야 하며 그 전체집합은 SUPER-TYPE과 1:1

• 전체집합에 확신이 없다면 ‘기타’ 구분을 생성

• SUPER-TYPE과 SUB-TYPE은 결코 부모 : 자식 관계가 아니다(동일 Level)

서브타입 배타적 관계

• 어떤 ENTITY가 두개 이상의 다른 Entity의 합집합과 relationship을 가지는 것을 배타적(Exclusive)관계 혹은 아크(Arc)관계라고 함.

• 아크(Arc)내에 있는 Relationship은 보통 함.(기수성)

• 배타적 관계는 항상 Mandatory 이거나 Optional이어야 함.

• 배타적 관계는 반드시 하나의 Entity에만 속해야 함. (하나의 아크가 여러 Entity를 가질 수 없음)

• 어떤 Enitty는 다수의 아크를 가질 수 있음.그러나 지정된 Relationship은 단 하나의 아크에만 사용되어야 함.

엔티티 정의

http://cyber.dbguide.net/ 

 2012 대한민국 DA설계 공모대전 문제풀이 동영상 내용을 정리한 내용이다.

window mysql 5.6  

my.ini 파일에 하단 내용 추가 

lower_case_table_names = 0  //  테이블 생성 및 조회 시 대·소문자 구분한다.

lower_case_table_names = 1  //  입력 값이 대·소문자든 소문자로 인식 소문자 인식 파일 생성

lower_case_table_names = 2  //  윈도우에서 대·소문자를 구분해서 테이블생성

리눅스와 유닉스의 경우 0, 윈도우의 경우 1, 맥키토시의 경우 2 가 기본 값