Well, a proper ORM is a level up from that. Your mapping is more abstract, and you may have an object that is mapped to two or more tables, or several types all sharing one table. In effect you design your object layer focused on OO concepts, then you design your SQL tables focused on relational concepts. You then use the ORM to map between the two, because OO and relational do NOT map 1:1.
There are often impedance mismatches between SQL and OO, and the ORM hides the consequences of that. Since Linq to SQL works directly off the DB tables, it is NOT an ORM, it is a data access system. It provides no OO abstractions off your data.
nHibernate does, and Entity Frameworks does (just badly).
"He has all of the virtues I dislike and none of the vices I admire." - Winston Churchill