데이터베이스를 설계할 때는, 가장 먼저 요구 분석(requirement analysis) 단계를 거친다. 여기서 개념 설계(conceptual design)가 이루어지게 된다. ER Model은 이 단계에서 사용된다. ER Model의 가장 커다른 특징은, 설계 결과를 그림으로 표현할 수 있다는 것이다. 즉, 데이터들의 연관성을 쉽게 파악할 수 있다. ER은 엔티티(entity) - 관계(relationship)을 의미하는데, 엔티티는 개별적인 개체를 의미한다. 그리고, 관계란 엔티티 사이의 관계를 말한다. ER Model은 엔티티 사이의 관계를 쉽게 파악할 수 있으며, 데이터들의 제약 조건까지도 결정할 수 있다. ER Model은, 정적인 관계만을 포함할 수 있는 것은 아니다. 관계들은 결국 레코드 - 필드 형태로 나타나지만, 이것이 의미하는 추상적인 의미가 항상 속한다 - 속하지 않는다의 정적인 의미만은 아니라는 것이다. 예를 들어, 어떤 기업의 직원을 나타내는 레코드를 생각해보자. 이 레코드는 이름, 나이, 부서명, 직급 따위를 가질 수도 있다. 이런 경우는 정적인 형태라고 할 수 있다. 하지만, 이 직원이 보고서를 상사에게 제출한다고 해보자. 그렇다면, 이 보고서를 받을 상사를 명시해야 할 것이다. 하지만, 이 직원과 상사와의 관계는 정적이라기보다는 동적이다. 이것을 직원이라는 레코드가 가지는 필드값으로만 표현하려고 한다면, 이 엔티티가 가지는 속성(attribute)이 너무 복잡해거지거나 전체 모델에서 중복되는 부분이 생길 수도 있다.
엔티티 속성의 타입(type)과 도메인(domain)은 서로 다른 개념이다. 타입은 어떤 데이터 형태를 가질 것인가를 결정하는 것이지만, 도메인은 이 속성이 가지는 값의 범위를 의미한다. 또, 개체 집합(entity set)에서, 각 개체를 유일하게 구별할 수 있는 키(key)가 필요하다. 이 키는 특정 엔티티와 다른 엔티티를 구별하는 개체 집합에서 유일한 값이어야 한다.
그러나, 이렇게 얻어진 결과를 가지고 바로 데이터를 저장할 수는 없다. 즉, 개념 설계 단계는 문서 형태로 이루어지며, 이것으로 데이터의 대략적인 파악이 끝나면 실제 특정 데이터베이스를 사용하여 논리적인 설계를 하게 된다. 여기서 특정 데이터베이스는 RDBMS가 될 수도 있고, 그렇지 않을 수도 있다.
엔티티 속성의 타입(type)과 도메인(domain)은 서로 다른 개념이다. 타입은 어떤 데이터 형태를 가질 것인가를 결정하는 것이지만, 도메인은 이 속성이 가지는 값의 범위를 의미한다. 또, 개체 집합(entity set)에서, 각 개체를 유일하게 구별할 수 있는 키(key)가 필요하다. 이 키는 특정 엔티티와 다른 엔티티를 구별하는 개체 집합에서 유일한 값이어야 한다.
그러나, 이렇게 얻어진 결과를 가지고 바로 데이터를 저장할 수는 없다. 즉, 개념 설계 단계는 문서 형태로 이루어지며, 이것으로 데이터의 대략적인 파악이 끝나면 실제 특정 데이터베이스를 사용하여 논리적인 설계를 하게 된다. 여기서 특정 데이터베이스는 RDBMS가 될 수도 있고, 그렇지 않을 수도 있다.