Converting a logical model to a physical model. Trouble understanding ERD

Question

I am working with an ERD. It is supposedly a logical model and I am to make a physical model from it. I should be formatting in UML and our DBMS is PostgreSQL.

Some of my research (http://www.1keydata.com/datawarehousing/data-modeling-levels.html // http://en.wikipedia.org/wiki/Logical_data_model#Conceptual.2C_Logical_.26_Physical_Data_Model) indicates that this ERD may have too much information in it to be a logical model and that it may actually be closer to the physical.

My questions are as follows:

1. What do the bold labels mean?
2. What do the white "N"s and red "U"s at the end of some entries mean?
3. What is the difference between a dashed line (relationship) and a solid one?
4. What is the difference between the "crows foot" and the broken line on either end of the relationship?
5. Is this closer to the physical model or logical model? What would I have to do to convert it from one to the other?

This is the ERD:

Answer 1

1. Could bold text indicate primary key attributes?
2. That's not part of any standard ER modelling notation. By no means certain but my guess would be U means unique, N means nullable.
3. A solid line means an identifying relationship. Dashed line means a non-identifying one. It's usually not an especially important distinction but look those terms up if you want to know more.
4. One to many relationship. The crows foot represents the "many" side of the relationship; the short line across is the "one" side. Where the "one" symbol appears at both ends that's a one-to-one relationship.
5. In the context of information modelling a logical model means a semantic model - a model that's more about the business domain than about an actual database design. Exactly what goes into the logical model and at what level of detail depends a lot on the intended audience for the model and on how you want to use it. Turning it into a "physical" model means making it into a design for a database with the technical features and any changes you would need for your chosen DBMS platform (specific data types for example).

Logical/physical models in the information modelling sense should not be confused with what are termed the logical level and physical level in DBMS architecture and database theory. In principle relational database tables (AKA relation variables) are always "logical" level constructs but in data modelling terms they are part of a so-called "physical" model. That unfortunate choice of modelling terminology is responsible for a lot of confusion and misunderstandings.