반응형
* 테이블 디자인을 하면서 주의해야 할 사항을 정리 해 보았다*
 
1. PK 영역에는 변경될 수 있는 값을 넣지 말자.
   → 해당 테이블을 참조하는 테이블이 있으면 변경 할 수 없으므로.
즉 트랜잭션 데이터의 경우 일반적으로 '(영업, 생산, 반품 등 행위가 실제로 발생한) 업무일자 +  일련번호'로 PK를 부여 하는 경우가 많다. 그런데 해당 테이블을 참조하는(즉, FK로 참조) 테이블이 있다면 날짜의 변경이 필요한 경우에 곤란해 진다.
따라서 이를 해소 할 수 있는 대안으로 PK에는 "자료등록일자(log일자) + 일련번호"를 부여 하고 실제 업무일자는 별도 컬럼으로 관리를 하므로서 업무일자가 변경되어야 할 경우에도 유연하게 처리할 수 있다.

※ SQL서버의 경우 SQL서버2000 이상에서는 UPDATE, DELETE에 대해서 CASCADE를 지원한다. 따라서 DB의 기능을 이용할 수 있다. 그러나 지원하지 않는 DB의 경우는 Trigger등을 사용해야 하지만, 참조 하는 테이블이 많을 경우 이것도 불편하다.

따라서 설계 자체를 잘 하는 것이 좋을 것이다.

[SQL서버의 CASCADE 예제] 

-- 부모 테이블
create table parents
( keycolumn int primary key,
  datacolumn char(10)
)

insert into parents values (1, 'AAAA')
insert into parents values (2, 'BBBB')

-- 부모 테이블을 FK로 참조하는 자식 테이블
create table child
( childkey int primary key,
  childdata char(10),
  parentskey int not null,
  FOREIGN KEY (parentskey) REFERENCES parents(keycolumn) ON UPDATE CASCADE
) 
insert into child values(10, '가가가가', 1)
insert into child values(20, '나나나나', 2)

select * from child

  childkey    childdata  parentskey
  ----------- ---------- -----------
  10          가가가가       1
  20          나나나나       2

-- 부모 테이블의 PK 변경
update parents
set keycolumn = 100
where keycolumn = 1

-- 자식 테이블의 FK도 같이 변경되었는지 확인
select * from child

  childkey    childdata  parentskey
  ----------- ---------- -----------
  10          가가가가       100
  20          나나나나       2
   

2. FK가 NULL값을 가질 수 있도록 하면 NULL인 값을 SELECT해야 할 경우 INDEX를 사용할 수 없으므로 주의해야 한다.
   
3. 동시성문제를 항상 고려하자. 즉 동시에 다중 사용자가 INSERT, UPDATE, DELETE가 발생 할 경우에 대한 처리.
  -> 자동증가(IDENTITY) 필드를 지원하는 DB와 그렇지 않은 경우도 고려
 
4. ENTITY의 PK에 해당하는 실체가 한개가 존재 하는지 아니면 여러개가 존재 하는지에 따라서 릴레이션이 달라질 수 있다.
즉, 거래처, 사원과 같이 PK에 해당하는 실체가 1개만 있는 경우와 제품과 같이 여러개의 수량으로 존재할 수 있는 경우에 따라서 1:M 될수도 있고 M:M이 될수도 있다.
또한 제품이라고 해도 온라인에서 판매되는 상품과 같이 하나의 코드에 여러개의 재고가 있는 경우도 있고 선박이나 건물과 같이 오직 하나만 있는 경우도 있으므로, 반드시 실제(현실세계)를 고려해야 한다.
즉, PK가 바로 실체 그 자신과 동격인지, 아니면 여러개의 실체를 대표하는 대표코드 성격인지를 파악해야 한다.
다시 말해서 하나의 row가 instance 성격인지 아니면 object(class) 성격인지를 확인해야 한다.
object 성격이라면 필수적으로 수량 관리가 들어 간다.
 
5. ENTITY와 ENTITY간의 릴레이션이 오직 한번만 이루어 지는지 아니면 여러번 이루어 질 수 있는지 고려해야 한다.
예를들어, M:M 관계를 풀기 위해서는 양쪽 ENTITY의 PK로 교차 ENTITY의 PK를 만들게 되는데 그 PK만으로 유니크 할 수도 있고, 만약 그런 관계가 여러번 발생한다면 일련번호등의 PK가 추가되어야 한다.
 
6. 어떤 자료가 변경 될 경우 단순히 UPDATE만 할 것 인지, 아니면 이력으로 관리 해야 할 것인지를 판단 해야 한다.
    (마스터는 물론 Transaction 데이터도)

 

반응형

+ Recent posts