쇼핑몰 스키마를 설계해서 DB를 공부하는 것은 매우 좋은, 그리고 바람직한 학습의 방법이 될 수 있겠지요. 그 동기가 무척이나 중요하니까요. 글구 그 동기를 꼭 성취하실 때 쯤이면 분명 많은 것을 익히셨겠지요.

DB설계에서 가장 중요한 것은 뭐니뭐니해도, ER 다이어그램인데, ERD 이전에 이것이 없으면 ERD가 안나옵니다. 바루 업무규칙, 비즈니스 룰인데, BR에서 모든 ERD가 결정된다고 해도 과언이 아닙니다.

BR을 정제했을때 초기 ERD가 나오고, 또 새로운 BR이 발견되었을때 초기 ERD에서 쪼금 개선되어 나오고, 그러한 반복을 계속 하다가, 즉, BR이 모두 빠짐없이 구현되었을때 스키마를 만들어 주는 스크립트를 만들게 되죠.

물론 스크립트를 만들어 DB를 정의했다 해도 개발 과정중에 DB의 스키마가 바뀌는 것은 부지기수 입니다. 그러니 한술에 배부르려 하지 마시고, BR부터 정의해나가 봅시다.

위의 글로 미루어 짐작했을때,

1. 분류(음악, 영화, 게임)는 여러개의 상품을 가진다. 즉, 한 상품은 1개의 카테고리에 속한다. (여기서 1개 이상의 카테고리에 소속된다하면 테이블이 더 필요해 지겠지요)

2. 하나의 패키지에는 여러개의 상품이 존재한다. 한 상품은 여러개의 패키지에 구성된다. (다대 다의 관계가 생기지요.)

3. 세번째에 쓰신것은 DB를 짜는데 유용한 정의가 아닙니다. 짜려고 하는 DB 시스템을 정확히 말해주는 BR이 필요한 것이죠. 사이버 머니로 구매가 가능하다는 것은 사이버 머니를 저장하는 필드가 있겠다.. 하고 짐작을 하구요.

4. 네번째 기술한 것은 두번째 기술한것과 중복됩니다.

만일 카테고리별로 속한 상품마다 서로 다른 성질의 속성을 갖는다면 쪼금 더 어려운 설계가 되겠지만, 간단히 하는 것은 매우 중요한 작업이므로~ 음악, 영화, 게임등을 분류로만 보고, 상품은 같은 거라 한다면, 가격이야 상품이 결정짓는 것이므로 당근 상품 테이블에 한번만 정의되어야 겠지요.

DB 설계에 대한 일반적인 이야기만 한것 같네요. 다 책을 보면 나와 있는 이야기니 보다 기초적인 학습을 든든히 하면 ^^ 성과를 얻을 수 있을껍니다 ^^