NEVERMIND...

I'd say that it is necessary to keep in mind what you're relating - it would probably be unwise to try to join a DATE column with a CLOB column, for example. During design process, you - in most cases - can not know which values will be stored into relating columns.

As a physical model is created upon underlying logical model, usually they are equal. However, during implementation process you'll sometimes find out that certain things should be done differently than you designed in the logical model.

Completing an ER design (entity relationship design) IMO requires that you or someone else that is working on the design with you, understands the data that you are going to be storing.

You need to understand the entities and the business model to be able to determine your relationships, the data doesn't matter a lot, it is really just an implementation of the relationship.

The logical model will not necessarily equate to the physical model. The physical model can change for implementation/practicality reasons. The physical model may store calculated values to save time retrieving data.

Data could be split off into different entities to reduce table size and improve query performance.

This sounds like home work....