1. I agree that the data model is part of the Design, unless an existing data model is an integral part of the requirements.
2. Even if the SRS is divided into parts, I don't think it's necessary to divide the data model, especially if there would be duplication across those areas.
3. I think the data model at a minimum includes ERDs and a data dictionary. People need to know what a field is, when it should be used, what valid values are, etc. This information could be stored in the ERD tool and just extracted. Data flows are important when data moves from one table or file to another. I rarely distinguished between the conceptual data model and the physical data model. The only real use I see for them is where the conceptual data model is the ideal (in at least 3rd normal form) and the physical data model shows how things have evolved & denormalized for performance or other issues.
4. I think it's important that the physical data design show the relationship among the tables and all keys and indices.
5. I think the Detailed Design should document the design of the database down to the field level and explain why certain choices were made. It should point to any standards used for database table & field names, abbreviations, data types, etc. For maintainability, all the "grunt" work of the detailed database design (the tables, fields, keys, etc.) should be able to be reverse engineered from the database to ensure that they are current. A good solution is one that lets you model the database, generate the scripts, reverse engineer the database back to a model, make changes, generate scripts, etc.
