We've covered a lot of material in this chapter about a topic that will be fairly new for many people. I think we can derive from its support in Visio that Microsoft believes ORM to be a way of conceptually modeling systems that can help communication between the system designers and the solution stakeholders. Keep in mind that ORM can even be used in many ways that aren't just related to database design such as Requirements Specifications for Requests for Proposals and can certainly help with UML for modeling the relationships between classes and objects without the complexity of attributes and methods. We have also discussed a framework, the Conceptual Schema Design Procedure for modeling using the ORM. ORM notation has been discussed as well as the different object types, fact types, constraints and subtypes. We looked at how all of these are mapped (or not) to the underlying ER diagram when we are ready to move beyond conceptual design, to the logical design. ER diagrams have been revisited and we have shown how to tweak the properties of our logical model, which allows a fine level of control over how the database is finally generated/updated in the underlying DBMS. Once this is accomplished, we've shown how we can use round-trip engineering so that our model and our DBMS will stay synchronized. With this synchronization comes the benefit that we get to use our design tool to design the database instead of having to rely on the tools included with our specific DBMS. For more information on ORM I recommend the following web sites/articles:
Hopefully you now have an idea of why Microsoft and others have placed a lot of emphasis on the ORM. It really is an excellent way to model a solution conceptually and with the automated features that Visio provides, can help improve the quality and reliability of your next system.
| |||||||||||||||||||||||||||||||||||