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:

enter image description here

1 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.

  • Thank you J.D. , I put some thought into this, but would you say that designing a thorough logical model is more so used for mapping out existing real-world structures such as helping a company transitioning from paper and pen actions to database-oriented actions, and for that purpose it needs a strong source of logical truth, since that will propagate the efficiency of other teams that builds the software. Given my scenario, a single developer, making an abstract model should concern no more than a conceptual level. Logical details can be deferred until more people gets on the project.
    – Qi luo
    Commented Mar 2, 2022 at 18:10
  • @Qiluo I would say that's one way to design software, yes. Is it the norm or my personal choice, I don't think so. But I'm a developer / DBA myself, and my subjective choice is to jump right in and start building things and let that physical implementation show the picture. For me, altering a database schema before it has any real dependencies (e.g. published application in production) is as easy as it gets. I almost feel like the logical schema is something a proficient business analyst should compile from the business requirements they gather in an ideal world, but that's my opinion.
    – J.D.
    Commented Mar 2, 2022 at 19:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.