참조 무결성 제약과 영역 구분을 내제하지 않는다면,

데이터를 넣고 뺄 때마다 전 테이블을 돌면서 참조 무결성 제약과 데이터의 영역을 체크해야 할 것입니다.

당연히 스키마 안에 집어넣어야 합니다.

데이터 입출력시,

규칙을 검사하는 것과 데이터를 검사하는 것의 차이라고 생각합니다..

잘못 된 이야기이면 리플 달아주세요~

영역제약이 혹시 Domain제약을 말씀하시는 건가요?

경영학과 DB수업이시라면.....

데이터베이스 스키마에 제약 포함하는 이유는 여러가지가 있겠지만.. 그중 가장 큰(?) 이유가 비즈니스 로직을 위해서라고 들었습니다.

(비즈니스 로직을 위해 꼭 DB 스키마에 제약을 걸지않고도... 사용자 교육이나 어플리케이션 로직으로 처리 할 수도 있겠지만....^^)

Domain이라고 가정하고 말씀드리면

Domain은 attribute들이 가질수 있는 값들의 집합으로 format(data type, length)과 semantic(의미)에 대한 부분이겠네요. 그중 semantic부분은 쫌 애매하네요..

참조무결성은 아시는 것처럼 entity와 entity의 관계에서  integrity와 cardinality를 준수하고 fragment와 orphans를 방지하기 위해.. FK로 반영하구요..

경영학에서 말하는 DB는 실세계를 반영하고 비즈니스를 지원하기 위한 수단이지요.

제대로된(?) 데이터를 축적하기 위해 제약을 걸고 이를 가지고 의사결정을 하기위함이지요. (CRM이나 기타 등등..)

또 다른 이유는.. 시스템 통합이나 DW를 구현할때 동일 제품이나 고객에 대한 다른체계의 코드는.. 뜻하지 않는 비용이 발생등의 이유가 있겠네요..

답변 감사합니다 근데 잘 이해 못하겠어여 죄송해여 ;;