A bit of terminology that gets beaten to death is that of the “physical” database.  I would think most every DBA uses this term (I do), but…to mean what?  I think there are two common utilizations:

1. The layer of tables, constraints, indexes, etc used to store data
2. The actual on-disk structures.

Frankly, until 3 years ago, I used the first interpretation.  However, I was beaten up pretty badly by a few people whom I don’t really remember (I think Anith Sen was one of them.)  The problem is, I was scolded, “physical” already had a meaning, given it by the “founder” himself, EF Codd.

So, checking his 12 Rules, Codd stated the following two things:

Rule 8: Physical data independence:

Changes to the physical level (how the data is stored, whether in arrays or linked lists etc.) must not require a change to an application based on the structure.

Rule 9: Logical data independence:

Changes to the logical level (tables, columns, rows, and so on) must not require a change to an application based on the structure. Logical data independence is more difficult to achieve than physical data independence.

And actually, the implementation layer really is the logical model if you follow his terminology since his rules were pertaining to the relational model and not the entire design process.  This article says it better than I can in a long blog, but I am not sure about that URL (mac.com?):

http://homepage.mac.com/s_lott/iblog/architecture/C465799452/E20080301143528/

The physical layer of a relational database occurs down at the file system level.  Codd’s “Rule 8” (Physical Data Independence) says that the things we’re designing in ERwin (and similar tools) are the things our application depends on.  These are not physical in nature, but are the relational implementation. 

So the thing I am trying to say is that physical means that a little 5 volt charge is sitting there representing a bit of data in the physical world.  I like the term logical to mean implementation platform non-specific.. The thing in the middle is the SQL Server/Relational  implementation specific model.  It may take liberties to optimize for SQL Server, but it is not physical. That is were partitioning. indexing, filegroups, etc come in. Changes to this layer ought never be noticable by the application. 

I guess in the comments, I ought to expect a good number of replies that might start to answer the question.  Does it matter? Is it only semantics? Hey if you don’t think semantics matter, I hope that when you find yourself drowning that the person who has the choice of tossing you a life preserver or a sack of door knobs interprets the meaning of your cry for help in the way you intended. You would hate to find yourself at the bottom of a lake thinking “hmm, I wonder why they did that? Did they hate me, of just mis-interpret the meaning of my sentence?”