Seems OK to me. I'm not crazy about the pattern where you name each PK with the same name and then you have to figure out where it's used elsewhere. I'd rather see UserID for User & BlogCategoryID for BlogCategory, etc. It just makes things more clear and clarity is something to strive for. I don't see indications of unique constraints. You're using the "Identity Everywhere" approach to primary keys (and arguments can be made for both sides as to the utility of it), but you're still going to have to enforce unique constraints to prevent duplication of data.

For me, a table like BlogRelationPosts wouldn't have an identity. It serves no purpose. The other two columns would probably be the primary key. Same thing on any other many-to-many situation.

Basically, it looks relatively functional for how I would imagine a blog database to be put together if you were storing it relationally.