요구사항 설계 - 테이블 설계

구체적으로 요구사항 설계

면담 - 요구사항 분석

추상화된 답변을 심층적으로 재질문해서

요구사항 구체화

주제를 도출해서 테이블 설계

모든 클라이언트는 한번에 디테일하게 답변을 할 수 없다.

심층 질문을 통해 주제 도출 -> 테이블 설계

계산된 필드들은 데이터베이스에 설계하지 않는다. ex) 할인 제품

클라이언트의 응답에서 나타난 특성중에 필요없는 주제는 빼고

선정된 주제는 궁극적으로 데이터베이스에서 필드들이 된다.

4가지 주제에 초점을 맞춘다.

1. 사용자들이 현재 사용하고 있는 종류의 데이터

2. 사용자들이 . 현재 그들의 데이터를 사용하는 방법

3. 분석의 처음 두 단계에서 모은 샘플들

4. 사용자들이 일상적인 작업을 위해 필요로 하는 정보의 종류

관리자의 정보도 필요하다.

1. 관리자들이 현재 받고 있는 정보의 종류

2. 그들이 받을 필요가 있는 추가적인 정보의 종류

3. 그들이 필요할 것으로 예상하는 정보의 종류

4. 조직의 전반적인 정보요구사항에 대한그들의 인식

‘금액 (amount)’ , ‘총계 (total)’ , 합계 (sum)', ‘평균(average)’ , ‘최소 값(minimum)’ ,

‘최 대 값(maximum)’ , ‘개수(count)' 와 같은 단어들을 포함하는 이름을 가진 필드는

계산된 필드 목록을 위한 후보가 될 가능성이 크다. 계산된 필드의 일반적인 이름에는

‘소계 (Subtotal)’ , ‘평균 연령 (Average Age)’ , ‘할인 금액 (Discount Amount)’ , 

‘고객 수(Customer Count)' 등 계산되는 필드는 다 제거시켜야한다.

같은 이름, 같은 항목, 같은 특성을 가진 필드는 정제해야 한다.

더작은 조각들로 쪼개기 -> 정규화

정규화를 할수록 성능이 저하된다.

실무에서는 성능때문에 역정규화를 쓰게 된다.

관계를 표현할때, 조인을 사용한다.

1:1 관계는 합친다 - 역정규화

관계를 구성할 때, 반대로도 생각해본다.

1:1관계인지, 1:N관계인지 애매할 때는 정보를 제공하는 관리자나 클라이언트에게

심층질문을 통해 구체화 한다.

a. 소유 지향 질문은 ‘소유하다 (own)’ , ‘가지다(has)’ , ‘∼의 부분이다(is part of)’ ,

그리고 ‘포함하다(contain)’ 와 같은 단어나 구를 포함한다. 

이 종류의 질문의 예가 여기 있다.

하나의 주문은 하나 이상의 제품들을 포함할 수 있는가?

연결적 질문에서 했던 것과 같은 수정을 함으로써, 이 질문을 자기 참조 관계를 테 스트하는데 사용할 수 있다. 

예를 들어 부품(PARTS) 테이블을 위해 제기할 수 있는 질문이 여기 있다.

하나의 부품은 하나 이상의 다른 부품들을 포함할 수 있는가?

b. 행위 지향 질문은 ‘만들다(make)’ , ‘방문하다(visit)’ , ‘놓다(place)’ , ‘가르치다(teach)’ , 

그리고 ‘출석하다(attend)’ 와 같은 행위 동사를 수반한다.

이 종류의 질문의 예가 여기 있다.

한 명의 비행 강사는 한 종류 이상의 클래스를 가르치는가?

추측히고 있겠지만, 같은 수정을 함으로써 역시 이 질문을 자기 참조 관계를 테스트하는데 사용할 수 있다.

한 명의 직원이 한 명 이상의 다른 직원들을 관리하는가?

1:1관계는 의미가 없기때문에 역정규화 시킨다 - 테이블을 합친다.

ERD를 그리면서 테이블을 모델링한다.

N:M 관계로 만들면 물리적으로든 논리적으로든 힘든 설계가 된다.
N:M 관계는 중간에 정리해줄 테이블이 필요하다

기초적인 설계가 끝나면 성능을 끌어올리기 위해 튜닝을 한다.