DATA MODELING FUNDAMENTALS (P15) pptx

. Making change management as formal as possible depends on your organizational culture. Do not make it too rigid and turn your users off. On the other hand, making it too informal encourages users to pay little attention at the beginning. This will render your initial cut of the data model compl etely worthless. . Set up an acceptable approval process to filter the changes. . As you do incremental modeling, relate each version of the model to the changes incorporated. Document the version status. . Changes cannot go on forever. There must be cutoff points. This may be done in several ways. You may set cutoff points for each partial model and then when all the partial models are integrated. You may set cutoff points by iterations. . The desire to accommodate changes can lead to making change management a project by itself. Avoid undue effort just on change management. Change management is important, but that is not the whole project. Notes for Modeling Notes for modeling—what, another piece of documentation? We looked at the require- ments definition document, how it evolves and gets finalized. Can we not use that docu- ment as notes for modeling? There are several reasons why separate notes are useful. First of all, although the requirements definition document may be used for reference all the time, the set of notes of modeling is kept by the data modelers for their specific use. The requirements definition is a common document mea nt for many groups participat- ing in the development project. Notes for modeling are prepared by data modelers, primarily for their private use. Here are a few tips: . Tailor-make the notes to suit your particular preferences. There are no standards. . The medium on which you keep your notes is also up to you. . Make sure your notes are kept synchronized with the requirements definition docu- ment as it evolves. Note down all the changes to the data model as and when they are requested. . Separate sections for entity types, attributes/identifiers, and relationships may be a good method for dividing up the notes. . Note down special cases in a separate section. . Have a separate section for issues you need to get clarified by the users. Make a note of the resolutions. . If you are modeling for a global organization, contact information with phone numbers proves to be very useful. . Index your notes. . As in every type of document, strive for an optimal level of documentation. STAKEHOLDER PARTICIPATION Participation and involvement of stakeholders and user groups are of such enormous importance that we should separately consider some suggestions on this aspect of the 396 CHAPTER 12 DATA MODELING: PRACTICAL TIPS software development effort. In this section, we will review a few different facets of the participation and go over a few tips on how to make the participation effective. When we mention stakeholders, we include a variety of people and groups. Anyone outside of the information technology group who has a direct interest in the outcome of the software development effort is necessarily included in this broad category. These people are experts in the subject areas in which context the development takes place. These are the ones who will be using the resulting database regularly. These are the ones who can continually provide input on what the information requirements are. Let us consider four distinct factors of participation: how to organize participation, how to establish user liaison persons, how to promote continuous interaction, and what to do when stakeholders are at multiple distant sites. Organizing Participation Organizing stakeholder participation includes promotion of the concept, methods for promo- ting participation, setting up participation parameters, making participation really happen on a day-to-day basis, and so on. Participation may be left to happen on an ad hoc basis; the stakeholders probably would like this informal, laid-back approach. However, unless stake- holder participation is put down as a definitive objective and emphasized enough, you will not see enough participation. Not that the stakeholders are irresponsible, but software devel- opment is not their main job as it is for you in the information technology department. Here are a few tips on how to organize stakeholder participation: . At the very beginning of the project during project initiation itself, stress the import- ance of their participation to the stakeholders. Emphasize that their involvement is indispensable for the success of the project. Do this orally at initial meetings and also through written memos. . Describe the scope of stakeholder participation to them clearly. . From the beginning, foster a sense of joint ownership of the project with the stakeholders. . Go to great lengths to describe the benefits of participation and illustrate with examples. . Also, present the dangers of project failure if the participation falls below required levels. . Make each stakeholder understand his or her role in the cooperative effort. . Endeavor to make it easy for each stakeholder to participate so that he or she will still be able to perform his or her normal duties. As far as possible, try to work around their routine responsibilities. . Set up and publish timetables for the participation showing who will be involved in what roles. . Think of ways to encourage stakeholders with rewards for participation. User Liaison User liaison persons play a special role in software development. These persons are selected from the pool of stakeholders. In most organizations, for the duration of the devel- opment project, user liaison persons are relieved of most of their daily routine work. They STAKEHOLDER PARTICIPATION 397 need to spend most of their time on the project itself. Those stakeholders who could be on the project almost full-time are known as user representatives on the project. As the term liaison implies, user liaison persons act as catalysts for collaboration between the information technology team and the stakeholders at various levels. They keep the interactions alive and smooth. The following suggestions apply to user liaison persons: . User liaison persons must have excellent interpersonal skills. They must be able to work well with people at various levels. Recommend only such persons for this role. . User liaison persons need not be subject area experts, but they must know the work- ings of the departments and the overall structure and fu nctions of the organization. . Depending on the availability and qualifications of user liaison persons, nominate a few to be continually on the project as user represen tatives. . Attempt to have at least one user liaison person for each department. . Spell out the responsibilities of each user liaison person clearly. . The user liaison person will act as the conduit to the respective department or set up other means of communication with the department. . All important issues concerning a department will go through the user liaison person. . Use the liaison person to coordinate interview s and group discussions. . Let the user liaison person get the requirements definition confirmed. . Channel all changes and feedback through the user liaison persons. Continuous Interaction We discussed stakeholder participation and also user liaison persons who facilitate such par- ticipation in a development project. One aspect has to be clear about the participation of the stakeholders. The cooperation and collaboration of the stakeholders with the information technology team cannot be sporadic. The interaction must be continuous and ongoing. Let us list a few suggestions on continuous interaction between the two groups. . Dispel wrong ideas about continuous interaction from the minds of the stakeholders. Even today, many user departments assume that initially they spell out a few require- ments of theirs to the information technology department, whose members then go and do the software development all by themselves. . Explain the necessity to consult with them throughout the project. . Describe the iterative nature of software development, especially data modeling. . Specify each iteration and indicate what is expected of the stakeholders at each iteration. . Explain to the stakeholders the interaction at each phase from beginning to end of the project. Set a continuous timetable for interaction. . Share responsibilities with users from the beginning. . Choose suitable users for interaction at different stages. . User groups may share the collaborative efforts so that no one group is overburdened. . Develop long-term personal relationships with the stakeholders. Both groups are there together for the long haul. . In order to sustain the interaction, stipulate how completion of documents becomes a joint responsibility. 398 CHAPTER 12 DATA MODELING: PRACTICAL TIPS Multiple Sites In a global organization, stakeholder participation has to be extended to multiple sites. You will have user groups residing in various countries. Whenever a project spans stakeholders in multiple sites, the joint effort needs special consideration. Here are a few tips on stakeholder participation from multiple sites: . Keep top management at each site involved in the project. . Find a primary promoter of the project at each site. . Appoint at least one liaison person from each site. . Each contiguous or logical group of sites may have one user representative to be part of the project effort on a continual basis. . Encourage participation through group meetings. As necessary, invite users from con- tiguous sites for group meetings at a site more or less central for that set of sites. . From time to time, invite key personnel from the dispersed sites to meet with members of the project team at the headquarters for the project team. . Choose and send appropriate project team members to visit sites periodically to keep the two-way communication going. . Keep progress at all sites coordinated and balanced. . Keep all sites continually informed of the overall progress. . Encourage ownership of specific par ts of the data models by individual sites if this is feasible. ITERATIVE MODELING Iterative modeling and incremental modeling go hand-in-hand. You break up the modeling effort into manageable chunks and work incrementally on one fragment at a time. As you proceed from one fragment to the next, you integrate the previous fragment to the current fragment being worked on. Even when working on a single fragment, you go through an iterative process. You create an initial cut of the model for that fragment, present the initial version to the users, get their feedback, and refine and produce the next version. A few iterations of the creation–feedback –refinement take place. In this section, we will cover cycles of iteration , logical increments for modeling, inter- action between requirements definition and modeling, and integration of all the completed fragments. Each of these aspects is significant for iterative modeling. Establishing Cycles Iterative modeling consists of cycles of iterations. Each cycle contains a creation phase, a review and feedback phase, and a phase in which the model is refined. These iterations take place for each fragment of the data mo del. The following are a few suggestions for establishing and managing iteration cycles: . Do not overdo the iterations. Just two or three iterations are practical. . Define the purpose of each cycle precisely. ITERATIVE MODELING 399 . Define each phase of the iteration cycle clearly: creation/refinement–review– feedback. . Prepare and use a checklist of tasks for each phase. . Establish responsibilities in each phase. . Determine phase duration for each model fragment. . Avoid long phases. Redo fragment sizes if necessary. . Establish a schedule for each iteration and stick to the schedule. . The same number of iterations may not be necessary for every model fragment. . Define user participation clearly in each phase. Determining Increments Each increment of the data mo del builds on the previous increment. What is the ideal increment size? What are the best practices for integrating each increment with the data model version from the previous? We need to know how to break up the modeling effort into manageable increments. The following tips apply to the determination of the increments for iterative modeling: . Smaller model fragments for iterative development are more manageable. . Choose the size of model fragments according to experience of modelers and users. . Choose the best approach to incremental modeling that suits your circumstances— component by component or fragment by fragment. In the first approach, you create all components of one type, then move on to the next type of component, and so on. In the second approach, you create all components for each fragment, then move on to the next fragment, and so on. . Fragmentation of the model by functions or user groups works well. . Every model fragment need not be of the same size. . If you are implementing a pilot system, choose fragments for the model necessary for the pilot. . If you have planned a staged delivery of the overall system, the stages determine the nature and size of the model fragments. . As you complete iterations for one fragment, finish integrating the fragment into the earlier version of the data model. Then proceed to the next model fragment. . As you progress through the model fragments, one by one, maintain continuity of integration. . Consider iterating the whole model if the model is sufficiently small—containing less than 20 entity types. Requirements: Model Interface The data model is expected to be the true representation of the information requirements of an organization. Therefore, while iterations takes place for refining the data model, there must be constant interaction between requirements definition and the evolving data model. 400 CHAPTER 12 DATA MODELING: PRACTICAL TIPS Here are some suggestions on how this interaction needs to happen: . At each iteration of the model fragment, check back with the corresponding part of the requirements definition. . Allow for reworking of the requirements definition. Until the modeling phase is com- plete, the requirements definition could accommodate revisions. . Constantly ensure that each iteration of the data model is kept synchronized with the requirements definition. . In small projects, requirements definition and modeling can be taken together for iterative development. . In global projects, interaction between requirements and data model may be kept at the individual site level. . When the overall model is nearly complete, review the model in the light of the com- plete requirements definition. Integration of Partial Models As newer fragmen ts of the data model are created and refined, they must be integrated with the previous versions of the data model. This is a continual task—by no means simple. The following are a few suggestions on the integration. . If you are fragmenting the data model component type by component type, integrate the entire model only when all component types are completed. . If you are fragmenting the data model function by function, integrate when you com- plete the iteration cycles for each function. . Each integration must be complete before you proceed to the next model fragment. . Only when the overall model is small, postpone integration until all fragments are completed separately. . For global projects, integration, site by site, proves to be successful. . Sometimes, integration may be performed at different levels—integrate many partial models into a smaller set of partial models, then into still smaller set of partial models, and so on, until you arrive at the final model. . If you have a pilot system, integrate the partial models for the pilot first. . If your system has staged deliverables, integrate partials for each stage. . Use a checklist for integration tasks. . When the final integration is done, perform one final review, get feedback, and incor- porate final revisions. SPECIAL CASES Now we turn our attention to some special cases of data modeling. During our discussions in the previous chapters, we had considered a few special cases from time to time. Here we want to add a few more special cases and provide suggestions to deal with these. Each special case is described with an example. You will note why suggestions are useful in these special cases. SPECIAL CASES 401 Legal Entities Consider examples of legal entities such as CLIENT, CUSTOMER, or SHAREHOLDER. In each of these, the entity may represent a single person or an institution. A client may be a single person or an organization. Similarly, a customer may be an individual or a company. In the same way, a shareholder may be a single person or an institution. In each case, information must be represented for two types of entities while preserving the similarities and still maintaining their uniqueness. Let us specifically take the entity type CLIENT. Clients consign property items to an auction company to be sold at auction. Therefore, CLIENT must be shown as an entity type in the data model for the auction company. You can have individuals as clients or art dealer companies as clients. The data modeler faces the problem of representing CLIENT data type. Of course, the business rules would guide the representation. We can show the representation in three different ways. Let us look at the three ways and note the comments of the three representations. Figure 12-1 shows the method of representing CLIENT as a supertype of INDIVID- UAL and DEALER. This representation, although it may be in line with the business rules, could be cumber- some if we have to represent complex relationships between INDIVIDUAL and DEALER. An individual may be the contact person for a dealer company. Another method for representation is to make CLIENT as a subtype of both INDIVID- UAL and DEALER. See Figure 12-2. This is perhaps a common method of representation. Although this representation pre- serves the independence of INDIVIDUAL and DEALER, it introduces much redundancy. Further, this representation does not clearly connote the meaning of the entity type CLIENT. Now look at the representation indicated by Figure 12-3 where clients are represented by relationships. FIGURE 12-1 CLIENT as supertype. 402 CHAPTER 12 DATA MODELING: PRACTICAL TIPS However, this representation makes it difficult for addition of client-specific attributes. Figure 12-4 illustrates the ideal representation. This representation preserves the inde- pendence of INDIVIDUAL and DEALER. Also notice the lack of duplication of entity types and attributes. Locations and Places Many kinds of business objects would fall under the category of location or place. A location may be identified by three coordinates x, y, and z. In a medical center, a room FIGURE 12-2 CLIENT as subtype. FIGURE 12-3 CLIENT as relationships. SPECIAL CASES 403 and bed number would constitute a location. For a customer, a street address would refer to a location. Apartment number, PO box number, state, city, zip code, postal code—all of these relate to locations. How to represent locations in a data model? There seems to be a very large number of business objects that could be included in the category of locations or places. Also, you can combine a few of these together to signify a location. We will examine a few standard methods for representing locations. You may adapt these to suit your information requirements and the practices in your organization. Simplistic Method. In this method, a location is simply described as an object with an artificial identifier and other attributes. Apart from the selected attributes, all other possible attributes for the location are ignored. This simplistic method assumes that every location entity possesses only the selected attributes and no other. Figure 12-5 illustrates this simple and straightforward method. Locations as Subtypes. This method uses a generalization –specialization structure. As you come across newer kinds of locations, you add each new kind to the model as a subtype. This method is more flexible and wider in scope than the previous simplistic method. Figure 12-6 shows locations as subtypes. Also note how this structure may be used to find specific locations for individual persons. Abstraction of Location. This method presents a method for abstracting location as a coordination object. In this case, the location entity type has no other attributes except an identifier. Use this method only if you have several types of locations in your organizations FIGURE 12-4 CLIENT: ideal representation. 404 CHAPTER 12 DATA MODELING: PRACTICAL TIPS that need to be modeled. This high level of abstraction is also less amenable for the data model to be used as a communication tool with the users. Figure 12-7 presents the abstraction method for representing locations. Review the figure carefully. Time Periods In the business world, time periods such as a calendar year, fiscal year, fiscal quarter, evening shift, second semester, and so on are important. These must be included in the data model for proper representation of the business. FIGURE 12-5 LOCATION: simplistic representation. FIGURE 12-6 Locations as subtypes. SPECIAL CASES 405 [...]... Reingruber, Michael C., and William W Gregory, The Data Modeling Handbook: A Best-Practice Approach to Building Quality Data Models, Hoboken, NJ: Wiley, 1994 Schmidt, Bob, Data Modeling for Information Professionals, Upper Saddle River, NJ: PrenticeHall, 1999 Silberschatz, Abraham, et al., Database System Concepts, New York: McGraw-Hill, 1999 Data Modeling Fundamentals By Paulraj Ponniah Copyright # 2007... considerations of database implementation Easier Database Implementation Any enhancement you make to the logical data model that eases the implementation is welcome After completing the logical data model, the remaining steps include transition to a physical model, space allocation for the various data structures, defining of the structures to the data dictionary, populating the database with initial data, deployment... to requirements in a data modeling project Explain why they are likely to work 6 Describe iterative modeling What are the major activities to make modeling iterative? 7 In iterative modeling, what do we mean by an iteration cycle? Make some suggestions for establishing cycles 8 Discuss how you can divide up a modeling effort into fragments How does model fragmentation make the modeling effort more... components in a data model diagram Let us look at a few tips on improving the model layout Readability and Usability After you have designed the entity types and the relationships and even after you have established all other components of the data model, your data modeling task does not really end Recall one of the primary purposes of a data model You need to make it as 410 CHAPTER 12 DATA MODELING: PRACTICAL... time-dependent information See Figure 12-9 where data about time are included as attributes of other entity types Persons Essentially, data modelers adopt two approaches for modeling persons and their attributes The adopted approach depends on whether you want the data model to represent just the FIGURE 12-10 Person entity type: current status only 408 CHAPTER 12 DATA MODELING: PRACTICAL TIPS FIGURE 12-11 Person... Texts If a data model is not enhanced with appropriate texts, the model would look bald and incomplete Textual data that is not generally part of standard model conventions can improve readability of the data model a great deal This textual information, if applied in proper measure, will enable the user groups to understand the data model even more easily For you, the data modeler, textual data will... suggestions how to keep the data model true to the information requirements during the entire data modeling phases? List the suggestions and briefly describe each 10 What is integration of partial models? Give some practical suggestions for performing the integration tasks BIBLIOGRAPHY Allen, Sharon, Data Modeling for Everyone, Birmingham, UK: Curlingston, 2002 Ambler, Scott W., Agile Modeling, Hoboken, NJ:... Mastering Data Modeling, Boston, MA: Addison-Wesley, 2000 Connolly, Thomas M., et al., Database Systems: A Practical Approach to Design, Implementation, and Management, Boston, MA: Addison-Wesley, 1998 Elmasri, Ramez, and Shamkant B Navathe, Fundamentals of Database Systems, Boston, MA: Addison-Wesley, 2000 Fowler, Martin, and Scott Kendall, UML Distilled: A Brief Guide to Standard Object Modeling Language,... serve as handles to pick up different parts of the data model and present them to the user groups and communicate with them The following types of textual data applied to a data model are found to be useful Headings Provide headings for each page containing the data model Subheadings may be used whenever you want to identify parts of a data model LOGICAL DATA MODEL 417 Titles Titles serve as overall cryptic... is crucial for the success of a modeling project Practical tips cover organizing participation, user liaison, continuous interaction, and multiple sites Useful suggestions on iterative modeling relate to establishing iteration cycles, determining increments for modeling, and integration of partial models Review and adapt practical suggestions on special cases of data modeling: legal entities, locations, . specific par ts of the data models by individual sites if this is feasible. ITERATIVE MODELING Iterative modeling and incremental modeling go hand-in-hand. You break up the modeling effort into. period object in your data model. FIGURE 12-7 Abstraction of location. FIGURE 12-8 Time period: separate entity type. 406 CHAPTER 12 DATA MODELING: PRACTICAL TIPS Figure 12-8 shows a partial data model. the actual layout of the data model itself in the form of a diagram. Data models primarily consist of data model diagrams and accompanying sup- plementary documentation. Data models integrate graphics