How should one design a logical data model for a social platform, or skip it?

Question

After studying from 'Usage-Driven Database Design: From Logical Data Modeling Through Physical Schema Definition'a book by George Tillmann.

I want to create a logical model for a my own social platform that resembles a blogging platform with its own flair. However, while mapping out the logical model, it hard deciding what gets its own entity and relations. Most examples in the book shows a 'mapping' to real world entities of everything already exists i.e. department to worker as oppose to my website which has more artificial separations.

For instance, I have to decide how 'user', 'public profile', 'user-defined-category', 'comments', 'likes', 'posts' all relate. The issue is, I can find a relationship between all of them. i.e. a comment is made by a user, a comment can be fitted in a public profile, a comment is in a post, a comment has likes, and so on for other entities. As you can see, the distinction is not as prominent as real world mapping. Is this mapping normal? Unless, I should be more specific..like profile-comment links to profile and user, post-comment links to post and user, postlikes links to post and user, commentlikes likes to comment and user. There is still a star schema off of here. Whats worse if I add a 'notification logger' entity, almost everywhere here is linked to that as well !

I feel for now, creating an actual physical model without a logical model would be easier, but I don't want to make a mistake to assume it's okay to skip - because my lack of ability to build one.

George Tillmann's suggestion on the framework to follow:

Answer 1

I've personally never formally created a logical model / logical schema more than just some pre-planning and information & requirements gathering from the end users. So that loosely accounts for the first two steps of logical modeling in the figure you provided from George Tillmann, short of actually constructing the logical model.

I like to start getting my hands dirty, and building the physical entities and their relationships in the database. It's easy to make changes to them as needed, especially prior to them being released to production, and especially prior to there being any actual data in them. Having the physical schema in place makes it easy to visualize and then make revisions to as needed, in the short-term.

My general advice when people struggle to define models is to essentially work backwards and think about the use cases that the end users need, and then think about the concrete classes in the application that would be needed to support that. Your data model shouldn't usually be far off in design from the concrete classes themselves, especially in most common use cases, such as yours with a blogging platform.

Also, there's nothing inherently wrong when most of your models relate with each other, per se. In one regard, it's a good thing, because it shows you have strong referential integrity in your relational model, making it fitting for a relational database.

And not every entity is directly related in your use case, for example, you can't like a public-profile (usually) in a blog. Rather those two entities have an extended relationship where a public-profile relates to a user who likes a post.