This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I think this is the best place for this question. I have been reading Craig Larman's book on UML and OO, and was wondering where does data modeling fit into the whole process? What artifacts if any from OOA/D are used when modeling data? Who is responsible for making decisions about the data model? Is it the developers, or the DBA? Thanks, Steve
I guess the answer to this is as much political as practical. Any question "who is responsible for ..." should really incude an " ... in this organization". In my opinion, there is no real distinction between "developer" and "DBA" roles. One specializes in (say) Java, XML and Tomcat config files, one specializes in (say) Oracle schemas, indexes and explain plans. Surely the whole team has to "buy in" to the chosen solution? You'll be telling me that testers have no input next ! In practice, if your organization enforces some sort of arbitrary separation between developer and DBA roles, then you need to find out from the organization what the individual responsibilities of those roles should be. I don't think you can just guess.
Originally posted by Steve Chernyak: Who is responsible for making decisions about the data model? Is it the developers, or the DBA?
My answer would be "wrong question". Data modeling is an area that is as deep as OO modeling. There are multiple kinds of data models, and different people care about different models (and there are assorted debates about the kinds of models you should have). A conceptual data model is essentially a pictorial representation of the scope of a project. It indicates the integration context for an application (system, service, whatever). It shows the fundamental interactions and data expectations of the application and the other systems it touches/is touched by/indirectly influences. In other words, a conceptual data model is a bit like an I/T planning analog of use cases, prior to the use cases being elaborated. It is useful for uncovering fundamental world-view inconsistencies between systems that may not be apparent if you rely too much upon use cases to uncover requirements. The project manager, and the key participants in providing or consuming data with this new application, all need to be in agreement with the conceptual data model. Developers and DBAs aren't relevant at this point. At the next levels of refinement are logical and physical data models. A team should have somebody in the role of a database engineer who will work with developers and DBAs. The developers have needs that will tend to drive the logical model. The DBAs will know things about effective use of the technology that will tend to drive the physical model. The DBE tries to make all that information and need come together effectively.