앞서 관계를 어떻게 정의하느냐에 따라서 모델에 변화되는 것을 보았다. 관계뿐만 아니라 개체집합을 어떻게 정의하느냐에 따라서도 모델이 변화한다. 아래의 ERD를 보자.

위 ERD에서는 “교실” 개체집합이 현실상 존재하는 건물(예: 이공관 501호)로 정의했다. 그러나 강의방식이 바뀌어 개설된 강좌가 가상공간에서 일어나는 “사이버강좌” 라고 한다면 우리가 앞서 정의했던 “교실” 개체집합의 범위에서 벗어나 버린다. 이는 “교실” 개체집합의 범위가 확장된 것이다. 그러면 Mandatory였던 관계는 Optional로 바뀌어 버린다.

Optional이라는 것은 관계가 명확하지 않음을 의미한다. 그러므로 개체집합의 범위를 확장하여 “교실” 개체집합의 정의에 “사이버강좌의 URL” 을 포함한다면 자연스레 다시 Mandatory관계가 형성된다.

ERD 아래쪽을 보자. 아래의 그림과 같이 “강사도 개설된 강좌를 수강할 수 있다”고 개체집합의 정의를 내렸다면 ERD는 어떻게 될까?

역시 개체집합의 범위를 확장하면 간단히 해결된다. “학생”, “강사”를 추상화 레벨을 높여 일반화 시키면 된다. 즉, “학생”, “강사”를 일반화 시켜 “구성원”의 부분집합으로 놓는다. 그러면 “구성원”은 모두 개설된 강좌를 수강할 수 있고, “강사” 만이 강의를 할 수 있도록 된다.

다른 예를 보자. “주소”는 키개체집합인지 아니면 다중값 속성인지에 따라서 모델이 변화한다.

만약 키개체집합으로 “주소”가 표현되었다면 고객:주소 = 다:1 의 관계가 될 것이다. 이런 경우라면 고객의 주소는 “현주소”가 될 가망성이 높다. 해당 업무가 “고객의 주소는 있으면 좋고, 없어도 괜찮다”고 한다면 “현주소”의 의미도 희석된다. 또한 “고객”의 다중값 속성으로 “주소”를 보았다면 “고객은 여러 개의 주소를 가진다” 라는 정의가 내려져야 한다. 만약 그림처럼 “고객”과 “주소” 사이에 “주소변경내역”이라는 개체집합이 도출되었다면 “주소”는 키개체집합이 된다.
앞서 관계의 정의 변화와 개체집합의 정의 변화에 따라 모델이 변화되는 모습을 살펴보았다. 이는 의미하는 바가 매우 크다. 개념을 애매모호하게 정의한다면 모델을 계속적으로 수정해야만 한다. 그러므로 각 단계에서 매우 많은 고려를 해야 한다. 사소한 것이라도 집고 넘어가는 버릇을 기르자.