Having designed the class model should be enough if we plan our application to run against the class instances that are created in computer memory based on the model. However, in the real world all entity objects have to be stored (persisted) somewhere. Common data store used today is relational database.
CommunityBlog will also store its data in a relational database. The existing class model will be mapped to a relational database model. Martin Fowler in PoEAA provides some basic theory on how we can perform such mapping. However, the way I will do that is utilizing my modeling tool.
Enterprise Architect has a great feature for transforming one kind of diagram into another. Transformation from class model to data model is provided as a feature. We can directly use generated data model as is, however usually I do not stop here. I use the transformation result as a starting point of my data model. Then I can perform some editing like renaming some generated table names, and adding some tables that were not modeled in class model.
Here is the resulting data model (ERD):
The resulting data model is not one to one mapping with the class model. In the class model, I model Post and Page as different entities. But in data model, those two different entities are combined into one table. To differentiate between post and page, I associate the table with PostType table. This decision is made because Post and Page do not have significant difference in field structure for the time being.
The resulting data model can be used to generate the DDL statement that later can be executed to create tables in the target database. This is one of advantages that we can benefit from using a tool to capture our data model. If later there are changes in the model, these changes can be directly applied to target database.
As conclusion, the data model for CommunityBlog is directly mapped from class model using Enterprise Architect tool. However, some changes are performed to suit with best method of relational database modeling.
