Summary

Looking at the business use case and business object models, the database designer can begin to understand the data that is needed to build the database. Of course, this data will need elaboration and more will need to be captured, but this gives a good starting point. Using the UML, the teams can share the information gathered and use it in their jobs. The data analyst can share this information and diagrams with the business analysts and developers. (For example, the data analyst can tell them that the attributes of an auditor will probably include a name , address, phone, specialty, and so on and that an auditor may even become a business entity.) The data will be captured in much more detail later, but it is good to get an understanding in the requirements stages rather than just starting with the entity relationship diagrams much later. Use cases also begin the process of uncovering information that will be added to the database. For example, understanding how accounts receivable are handled supplies the data analyst with information about what data need to be captured internally and what data may come from external factors. The more elaborate business models for this case study can be found in Appendix A. We suggest you review them to see just how much information can be obtained from this early work. From a relatively small investment of time, in conjunction with discussions with the business people and a few easy-to-understand diagrams, a database designer can get quite a head start in the development of the system database.