6th normal form, recomposition query, efficient implementation
Might be preferable to store PERS_INFO as a single table under the
  covers, so that the tables resulting from decomposition can be
  implemented as mappings to that. But current technology doesn’t give
  clean separation of physical storage from logical design.


He's talking about the dbms storing it as a single table, not you storing it as a single table.

The relational model itself says nothing about physical storage. It only requires that "the database be perceived by the user as tables. . . . At the physical level, in fact, the system is free to store the data any way it likes . . ." (An Introduction to Database Systems, 7th ed., CJ Date, p 61)

So Darwen is saying that if the database designer declares a set of 6NF tables, along with their 


candidate keys, 
distributed keys, 
foreign keys, 
foreign distributed keys, 
and so on, 


then the dbms is free to 


implement that set of 6NF tables as a single table in a SQL tablespace, 
hide that single-table implementation from the user, and
expose to the users a set of updatable views that are indistinguishable from the 6NF tables the database designer declared.


Having said all that, you might be able to work around the lack of dbms support by creating a single table on top of the covers (so to speak), and create a set of updatable views that are indistinguishable from your 6NF design. Revoke permissions on the single table, and require all users to use only the updatable views. What you can't do is have the dbms take care of all those details  based solely on a series of logically correct, 6NF CREATE TABLE statements.