Wikipedia+ER+Info

Mapping natural language
Chen proposed the following rules of thumb for mapping natural language descriptions into ER diagrams:[|[][|5][|]]
 * ~ English grammar structure ||~ ER structure ||
 * [|Common noun] || Entity type ||
 * [|Proper noun] || Entity ||
 * [|Transitive verb] || Relationship type ||
 * [|Intransitive verb] || Attribute type ||
 * [|Adjective] || Attribute for entity ||
 * [|Adverb] || Attribute for relationship ||

Physical view show how data is actually stored.

An ER model is an abstract way to describe a [|database]. Describing a database usually starts with a [|relational database], which stores data in tables. Some of the data in these tables point to data in other tables - for instance, your entry in the database could point to several entries for each of the phone numbers that are yours. The ER model would say that you are an entity, and each phone number is an entity, and the relationship between you and the phone numbers is 'has a phone number'. Diagrams created to design these entities and relationships are called entity–relationship diagrams or ER diagrams. Using the [|three schema approach] to [|software engineering], there are three levels of ER models that may be developed. > A conceptual ER model may be used as the foundation for one or more [|logical data models]. The purpose of the conceptual ER model is then to establish structural [|metadata] commonality for the [|master data] entities between the set of logical ER models. The conceptual data model may be used to form commonality relationships between ER models as a basis for data model integration. > The physical model is normally forward engineered to instantiate the structural metadata into a database management system as relational database objects such as [|database tables], [|database indexes] such as [|unique key] indexes, and database constraints such as a [|foreign key constraint] or a commonality constraint. The ER model is also normally used to design modifications to the relational database objects and to maintain the structural metadata of the database. The first stage of [|information system] design uses these models during the [|requirements analysis] to describe information needs or the type of [|information] that is to be stored in a [|database]. The [|data modeling] technique can be used to describe any [|ontology] (i.e. an overview and classifications of used terms and their relationships) for a certain [|area of interest]. In the case of the design of an information system that is based on a database, the [|conceptual data model] is, at a later stage (usually called logical design), mapped to a [|logical data model], such as the [|relational model]; this in turn is mapped to a physical model during physical design. Note that sometimes, both of these phases are referred to as "physical design".
 * 1) The [|conceptual data model]: This is the highest level ER model in that it contains the least granular detail but establishes the overall scope of what is to be included within the model set. The conceptual ER model normally defines master reference data entities that are commonly used by the organization. Developing an enterprise-wide conceptual ER model is useful to support documenting the [|data architecture] for an organization.
 * 1) The [|logical data model]: A logical ER model does not require a conceptual ER model especially if the scope of the logical ER model is to develop a single disparate information system. The logical ER model contains more detail than the conceptual ER model. In addition to master data entities, operational and transactional data entities are now defined. The details of each data entity are developed and the entity relationships between these data entities are established. The logical ER model is however developed independent of technology into which it will be implemented.
 * 2) The physical model: One or more physical ER models may be developed from each logical ER model. The physical ER model is normally developed to be instantiated as a database. Therefore, each physical ER model must contain enough detail to produce a database and each physical ER model is technology dependent since each [|database management system] is somewhat different.