모델링을 하지 않고 구축된 데이터베이스만 다루는 사람은 자신이 지도 위의 어느 지점에 위치해 있는지 모르는길 잃은 자와 같고, 데이터베이스의 원리를 모르고 모델링만 하는 사람은 목적지가 없이 지도만 가지고 길을가는 사람과 같습니다. 모델링을 전개할 때는 먼저는 업무로부터 논리적인 모델을 만들어 내야 하고 두 번째는논리적인 모델로부터 데이터베이스를 생성하기 위한 물리적인 모델을 만들어 내야 합니다. 그래야 데이터의무결성도 지키면서 성능을 향상 시킬 수 있는 모델링을 전개하게 됩니다.

반대로 데이터베이스 담당자는 모델이 어떤 비즈니스로 비즈니스 모델이 어떻게 데이터베이스 모델이되었는지를 알고 있으면서 데이터베이스를 운영 및 관리해야 합니다. 그래야 정확한 데이터 스키마 관리,성능관리 그리고 데이터의 무결성 관리가 가능해지죠.

모델러는 데이터베이스를 모르고 모델링을 하고 DBA는 업무를 모르고 데이터베이스만 관리하는 경우 좋지않습니다. 이는 가장 중요한 프로세스가 끊겨 버리는 현상으로 잘못된 물리 모델이 생성되거나 구축 이후데이터베이스가 변경이 될 때 이상한 모습으로 변경이 될 수 있는 위험이 많은 구조입니다. 모델러도 물리적인데이터베이스의 모습을 이해한 상태에서 모델링을 진행해야하고 DBA도 업무의 구조와 흐름을 이해한 상태에서물리 모델로 전환하는 작업을 직접 수행하거나 이해해야 프로젝트가 효과적으로 진행됩니다.

반대로 DBA가 모델에 대한 지식이 없으면 데이터베이스 테이블이나 PK 등에 대한 변경 요청에 대해데이터베이스만 고려하여 무조건 반영을 하게 되어 업무적인 특징이나 모델 내부의 흐름을 단절시키는 경우가많이 발생합니다.

정리하면 데이터모델러는 커맨드 처리에 미숙하고 DBA는 업무를 이해하여 모델을 분석하는 데 미흡하면 아주취약한 데이터모델링과 데이터베이스가 되는 것이지요. 이러한 사실은 시스템 구축 프로젝트를 진행할 때 모든데이터모델링을 수행하는 사람은 데이터베이스에 대한 지식을 갖추는 것이 필요하므로 별도로 시간을 내어 교육하고, 데이터베이스 관리자(DBA)에게는 업무 흐름에따라 데이터 모델에 대해 이해하는 방법을 교육해야 합니다.

데이터모델링과 데이터베이스 관리자(DBA)의 두 역할은 분리된 역할로 존재하는 것이 아닌 상호 밀접하게 연결되어 있는 것을 받아들일 뿐만 아니라,  두 영역의 중복은 필수적으로 존재하는 영역이고 중복적인 역할이 안정적인 프로젝트를 이행하는데 핵심요소가 됨을 인정할 필요가 있습니다.

결국 업무를 주로 설계하는 데이터모델러는 데이터베이스 물리적인 영역을 이해하도록 노력하고

반대로, 오라클, SQL서버, DB2, MySQL 등을 다루는 DBA는 논리적인 데이터베이스 설계가 어떻게 만들어졌는지 학습하는 노력이 필수적으로 요구됨을 받아 들일 필요가 있습니다.