DB/DB 설계 과제

[DB] DB스튜디오 과제 리뷰 2 | 데이터 모델링과 개념적 설계

sebinChu 2024. 4. 17. 13:27

개요

지난 1편에 이어서, 이번 과제도 배울 점이 많아 리뷰를 작성한다.

 

요구사항 1

 

 

지금까지 과제에서는 DATABASE 설계 명목 하에 개체와 속성이 뚜렷하게 보이는 식으로 요구사항이 정의되었다.

그런데 원래 요구사항은 대화하는 방식으로 주어진다. 이번 과제부터 자연어 요구사항이 주어졌고.. 이러한 경우는 "모호성 제거" 단계를 거쳐야 한다.

 

 

 

 

 

내 설계는 위와 같은데, 피드백을 받으면서 느낀 점은 다음과 같다.

 

  • 요구사항이 빠졌는지에 대해 면밀히 검토하는 것은 좋다. 
  • 그런데 개체 간의 단순한 관계의 의미를 넘어서 응용 관점을 검토해보는 태도가 필요하다. 그러니까 위 설계같은 경우는 Customer와 Book 사이에 order라는 관계는 의미상으로는 완벽하다. 하지만 다음 질문에 답하기 어려운 설계다.
    • Customer가 같은 책을 다른 날에 걸쳐 여러 번 주문하게 될 경우 어떻게 처리할 것인가?
    • 참고) 관계가 식별키를 가질 수는 없다.

 

연하게 되어있는 관게는 첫 번째 단계까지만 수행하고 추후 보정을 못한 케이스다.(나의 케이스....)

 

 

요구사항 2

 

 

 

 

  • 역시나 부족한 모호성 제거.... 교수 속성에서도 주제, 상태같은 모호한 것은 정의를 하고 반영하는게 맞다.

 

  • 모호성 제거 단계를 통해 주소지에 관한 다양한 요구사항에 대해서 도시 개체를 만들어 한번에 해결한다.
  • 날짜가 주는 추상화에서 오는 모호성을 제거하여 요일로 표현한다.

 

 

 

위처럼 크게 골격 스키마를 정리하고 나서 겹치는 부분은 다시 세분화하고, 여러 케이스를 따져서 구체화해준다.

 

 

사실 2번은 내가 설계한 것처럼 subentity를 표현하는 것이 문제 의도라고 생각하였는데, 풀이를 듣고보니 스키마 설게 단계 각각을 잘 이해하고 수행하고 있는지 확인하는 것이 의도였다. 어떤 식으로 표현을 하든 정통하는 설계 범주가 있으니, 단계 별로 해야할 일을 주의해서 설계하도록 하자.

 

 

스키마 설계 단계

  1. 모호성 제거
  2. 제거 후, 관련 있는 문장끼리 나누어 집합으로 정리한다. (집합으로 정리하는게 union이나 super-sub 관계를 나타내기도 좋은 것같다..! 앞으로 설계를 할 때 적극적으로 집합 정의를 해볼 생각이다.)
  3. 골격만 잡는 정도의(C-O-B 딱 이 수준의) 초기 설계 후, 여러 상황을 가정하며 세분화 진행; C-O-B에서 여러 주문은 어떻게하지? 이런식으로 의문을 잡아 나가는 것

 

모호성 제거

1. 용어에 대한 추상화의 적절한 단계를 선택한다.

여기서 용어라는 것은 추상적 용어와 구체적 용어 두 가지를 말한다.

예를 들어, 살았던 도시와 년수를 더 추상적인 용어로 변경하면 장소와 기간이 된다. 요구사항을 읽고 두 용어 간의 접점을 잘 잡아서 명명 및 설계해야한다.

 

 

2. 일반적인 개념대신 인스턴스의 사용 회피

필요 이상의 특정 용어들을 막 남발하면 이 용어 때문에 괜한 복잡한 설계를 하게 된다.

예를 들어서 컴퓨터에는 cpu, ram, 메인보드 등이 있는데 이 하나하나를 DB에 사용하면.... 의도치 않게 난잡해질 수 있다. 따라서, 이들을 포괄하는 부품(components)과 같이 포괄적인/일반적인 개념으로 표현하는 것이 좋다.

 

 

3. 완곡한 표현 회피

너무 완곡한 표현을 사용하는 것 또한 의도치않은 오류나 불편함을 초래한다. "매표창구에 앉아있는 사람"은 "매표원"으로 교체하는 등 명확한 개념과 용어를 사용하자.

 

 

4. 표준 문장 형식의 선택

다양한 문장 스타일 대신 단순한 문법 범주의 문장을 사용하자. 

  • <주어><동사><서술부> 형식
  • <if><condition><then><action> 등 프로그래밍 언어 형태의 문장을 활용하는 것이 좋다. (애플리케이션 개발자와 계속 소통할테니 이 편이 확실히 좋다는 느낌을 받았다.)

 

5. 용어들 사이의 명백한 참조

참조할 개념들이 요구사항에 명백히 표현되게 해야 한다.

1번의 추상화 개념과 같이 고려하면 좋다. 예를 들어 이런 것이다. "날짜(day)"는 요일(day of the week)을 말하는 것인지, 날짜(day of month)를 말하는 것인지 명백하게 하는 것이 좋다.

 

 

6. 용어 해설집

사실 과제에서 하는 설계는 개체가 10개도 되지 않는 간단한 것들이기에 바로바로 설명이되지만 실무에서는 포괄적인 용어 해설집을 작성하여 스키마를 접하는 사람의 이해를 돕는다.

 

요구사항 2의 모호성을 제거한 예시다. 대체[모호한 개념]로 표기되어있다.

 

 

생각보다 사소하지만 배우지 않으면 할 수 없는 것들을 배워서 가끔 충격을 받곤한다

졸업하기 전에 제대로된 DB 설계 수업을 듣고싶어서 수강했는데, 잘 했다는 생각이 든다.. 

과제가 많고 개념을 하나하나 공부하기 시간이 필요하지만 성장했으면 좋겟다.

저작자표시