I never really bought into the distinction of "logical" data modeling from so-called "physical" modeling. Or at least, not the way it's discussed. I guess it's because it strikes me as sloppy phrasing, and sloppy phrasing may not facilitate clear thinking.
For many years, the practice in relational data modeling is to create a "logical design" and then a "physical design." Logical designs are typically called "entity-relationship models." The modeler assembles a list of entities and then sets up the relationships among them. The following example uses the original Chen notation:
Note there are several other widely-used notations as well.
I find this representation quite readable. "A patient is treated in a ward" - jumps right off the page. This is why logical data modeling has become so prevalent. However, at some point you need to turn this into something your database can store: the "physical model." This means the definitions of tables with columns, typically including foreign-key constraints and indexes.
But in this usage, "physical" data models are hardly physical at all. Tables and rows in a database are hardly stored even as rows. The "physical" implementation of a completely vanilla Oracle table is essentially segmenting table rows against onto storage blocks. Then when you add more constructs like partitioning, index-organized tables, and clustering you have "physical storage" looking even less like a table. Then how "physical" is a table when its bits are RAID-striped across network-attached storage under some logical volume manager?
Denoting — or demoting — relational table design as "physical" has the effect of compromising or nullifying the centrality of data normalization in relational modeling. You can't normalize an E/R diagram. Doesn't work - doesn't happen. Why not? Because by marking certain data as relationships you have already determined the functional dependencies and relative cardinalities. You've short-circuited the relational modeling process.
If you've ever plowed through a copy of Codd/Date's classic Introduction to Database Systems, you'll see that what many now call "physical database design" is in fact highly logical, formalized, and abstract. So don't rush to make your E/R the source and infallible reference for your data model. You might find it, well, illogical.