DATA MODELING FUNDAMENTALS (P15) pptx

There are several reasons why separate notes are useful.First of all, although the requirements definition document may be used for referenceall the time, the set of notes of modeling is

. Making change management as formal as possible depends on your organizationalculture 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 completely worthless.

. Set up an acceptable approval process to filter the changes

. As you do incremental modeling, relate each version of the model to the changesincorporated Document the version status

. Changes cannot go on forever There must be cutoff points This may be done inseveral ways You may set cutoff points for each partial model and then when allthe 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 isimportant, but that is not the whole project

Notes for Modeling

Notes for modeling—what, another piece of documentation? We looked at the 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 referenceall the time, the set of notes of modeling is kept by the data modelers for their specificuse The requirements definition is a common document meant for many groups participat-ing in the development project

require-Notes for modeling are prepared by data modelers, primarily for their private use Hereare 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 ment as it evolves Note down all the changes to the data model as and when theyare requested

docu-. Separate sections for entity types, attributes/identifiers, and relationships may be agood 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 phonenumbers 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 enormousimportance that we should separately consider some suggestions on this aspect of the

software development effort In this section, we will review a few different facets of theparticipation 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 Anyoneoutside of the information technology group who has a direct interest in the outcome ofthe software development effort is necessarily included in this broad category Thesepeople 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 theones 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 dowhen stakeholders are at multiple distant sites

. At the very beginning of the project during project initiation itself, stress the ance of their participation to the stakeholders Emphasize that their involvement isindispensable for the success of the project Do this orally at initial meetings andalso through written memos

import-. Describe the scope of stakeholder participation to them clearly

. From the beginning, foster a sense of joint ownership of the project with thestakeholders

. Go to great lengths to describe the benefits of participation and illustrate withexamples

. Also, present the dangers of project failure if the participation falls below requiredlevels

. 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 theirroutine responsibilities

. Set up and publish timetables for the participation showing who will be involved inwhat 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 areselected 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 onthe project almost full-time are known as user representatives on the project.

As the term liaison implies, user liaison persons act as catalysts for collaborationbetween the information technology team and the stakeholders at various levels Theykeep 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 towork 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 functions of the organization.. Depending on the availability and qualifications of user liaison persons, nominate afew to be continually on the project as user representatives

. 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 upother 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 interviews 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 ticipation in a development project One aspect has to be clear about the participation of thestakeholders The cooperation and collaboration of the stakeholders with the informationtechnology 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 goand do the software development all by themselves

par-. 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 theproject 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 arethere together for the long haul

. In order to sustain the interaction, stipulate how completion of documents becomes ajoint responsibility

Multiple Sites

In a global organization, stakeholder participation has to be extended to multiple sites Youwill 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 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 withmembers of the project team at the headquarters for the project team

con-. Choose and send appropriate project team members to visit sites periodically to keepthe 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 parts of the data models by individual sites if this isfeasible

ITERATIVE MODELING

Iterative modeling and incremental modeling go hand-in-hand You break up the modelingeffort into manageable chunks and work incrementally on one fragment at a time As youproceed from one fragment to the next, you integrate the previous fragment to the currentfragment being worked on

Even when working on a single fragment, you go through an iterative process Youcreate an initial cut of the model for that fragment, present the initial version to theusers, get their feedback, and refine and produce the next version A few iterations ofthe creation – feedback – refinement take place

In this section, we will cover cycles of iteration, logical increments for modeling, action between requirements definition and modeling, and integration of all the completedfragments Each of these aspects is significant for iterative modeling

inter-Establishing Cycles

Iterative modeling consists of cycles of iterations Each cycle contains a creation phase, areview and feedback phase, and a phase in which the model is refined These iterationstake place for each fragment of the data model

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 model builds on the previous increment What is the idealincrement size? What are the best practices for integrating each increment with the datamodel version from the previous? We need to know how to break up the modelingeffort 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 andusers

. Choose the best approach to incremental modeling that suits your circumstances—component by component or fragment by fragment In the first approach, youcreate 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 forthe pilot

. If you have planned a staged delivery of the overall system, the stages determine thenature and size of the model fragments

. As you complete iterations for one fragment, finish integrating the fragment into theearlier version of the data model Then proceed to the next model fragment.. As you progress through the model fragments, one by one, maintain continuity ofintegration

. Consider iterating the whole model if the model is sufficiently small—containing lessthan 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 evolvingdata model

Here are some suggestions on how this interaction needs to happen:

. At each iteration of the model fragment, check back with the corresponding part ofthe requirements definition

. Allow for reworking of the requirements definition Until the modeling phase is plete, the requirements definition could accommodate revisions

com-. Constantly ensure that each iteration of the data model is kept synchronized with therequirements definition

. In small projects, requirements definition and modeling can be taken together foriterative development

. In global projects, interaction between requirements and data model may be kept atthe individual site level

. When the overall model is nearly complete, review the model in the light of the plete requirements definition

com-Integration of Partial Models

As newer fragments of the data model are created and refined, they must be integrated withthe 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, integratethe entire model only when all component types are completed

. If you are fragmenting the data model function by function, integrate when you plete the iteration cycles for each function

com-. 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 arecompleted separately

. For global projects, integration, site by site, proves to be successful

. Sometimes, integration may be performed at different levels—integrate many partialmodels 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 porate final revisions

incor-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 wewant 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 areuseful 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 acompany 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 preservingthe similarities and still maintaining their uniqueness Let us specifically take the entitytype CLIENT Clients consign property items to an auction company to be sold atauction Therefore, CLIENT must be shown as an entity type in the data model for theauction company You can have individuals as clients or art dealer companies asclients The data modeler faces the problem of representing CLIENT data type Ofcourse, the business rules would guide the representation

We can show the representation in three different ways Let us look at the three waysand note the comments of the three representations

Figure 12-1 shows the method of representing CLIENT as a supertype of UAL and DEALER

INDIVID-This representation, although it may be in line with the business rules, could be some if we have to represent complex relationships between INDIVIDUAL and DEALER

cumber-An individual may be the contact person for a dealer company

Another method for representation is to make CLIENT as a subtype of both UAL and DEALER See Figure 12-2

INDIVID-This is perhaps a common method of representation Although this representation serves the independence of INDIVIDUAL and DEALER, it introduces much redundancy.Further, this representation does not clearly connote the meaning of the entity typeCLIENT

pre-Now look at the representation indicated by Figure 12-3 where clients are represented

by relationships

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 entitytypes and attributes.

Locations and Places

Many kinds of business objects would fall under the category of location or place Alocation may be identified by three coordinates x, y, and z In a medical center, a room

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 ofthese relate to locations

How to represent locations in a data model? There seems to be a very large number ofbusiness objects that could be included in the category of locations or places Also, you cancombine a few of these together to signify a location

We will examine a few standard methods for representing locations You may adaptthese 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 anartificial identifier and other attributes Apart from the selected attributes, all other possibleattributes for the location are ignored This simplistic method assumes that every locationentity 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 asubtype This method is more flexible and wider in scope than the previous simplisticmethod

Figure 12-6 shows locations as subtypes Also note how this structure may be used tofind specific locations for individual persons

Abstraction of Location This method presents a method for abstracting location as acoordination object In this case, the location entity type has no other attributes except anidentifier Use this method only if you have several types of locations in your organizations

that need to be modeled This high level of abstraction is also less amenable for the datamodel to be used as a communication tool with the users.

Figure 12-7 presents the abstraction method for representing locations Review thefigure 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 thedata model for proper representation of the business

SPECIAL CASES 405

Before attempting to define time periods in your data model, find out the specifics.What are the requirements? Does a specific time period have start and end dates?Should start/end times be included in addition to start/end dates? Are there any require-ments to aggregate units such as sale units or revenue units over periods of time? Depend-ing upon the answers to such questions, determine whether you need a separate time periodobject in your data model.

Figure 12-8 shows a partial data model with time period as a separate entity type Note theother entity types in the figure and see how they are related to the time period entity type.However, in most data models, time periods are not shown as separate entity types Youwill adopt the method of showing time period as a separate entity type only if you need toshow the capture of 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

SPECIAL CASES 407

current state of the person’s attributes or whether you need the model to keep track of thechanges.

Figure 12-10 represents the simpler approach to allow representation of only the currentvalues of the attributes of persons

Notice how Figure 12-11 is an improvement over the first approach This methodallows the representation of all revisions in the attributes of persons

As you know, in manufacturing, a product is made up of components, a component made

up of subcomponents, a subcomponent composed of parts This hierarchy from product tocomponent to part may extend to several levels depending on the manufacturing environ-ment The hierarchical structure is known as a bill-of materials structure

Frequently, you will be faced with the task of modeling bill-of-materials structures.Your model must preserve the hierarchical nature of the relationships We now showtwo methods of modeling bill-of-materials structures The first is a straightforwardtop-down representation The second method uses recursive relationships

Figure 12-12 shows the top-down representation Note the hierarchical arrangement ofthe data model components

Figure 12-13 illustrates the use of recursive relationships Note the cardinality cators of the relationships

indi-CONCEPTUAL MODEL LAYOUT

We now want to consider the actual layout of the data model itself in the form of adiagram Data models primarily consist of data model diagrams and accompanying sup-plementary documentation Data models integrate graphics and textual matter Thesecan be fairly complex and not understood readily We need to take special effort tomake data models readable and comprehensible

In this subsection, let us examine the laying out of the model components in a datamodel 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 haveestablished all other components of the data model, your data modeling task does notreally end Recall one of the primary purposes of a data model You need to make it as

CONCEPTUAL MODEL LAYOUT 409

best a communication tool as possible You must ensure that the data model is readable byuser groups for whom the cryptic notations and semantics of model elements are not part

of their daily routine They must be able to use the model continuously for review and firmation of information requirements

con-There are several ways by which you can enhance the data model diagram and itslayout You can make the data model not only appealing but also as a readily usabledeliverable of the project Suggestions to enhance a data model fall into the followingcategories of tasks

Component Arrangement A data model consists of several model components, andthese are shown in a model diagram to represent the information requirements If the com-ponents are arranged in an orderly and logical manner, then the model becomes easy toreview and follow along from component to component

Enhancement with Texts Titles, captions, legends, version numbers, and so ongreatly add to the ease of understanding of a data model

Visual Improvements A data model can be perked up with the use of special graphics,color, and font variations Such improvements tend to lead the reviewer to the importantparts of the data model quickly and easily

We will discuss each of these techniques for adding to the value of a data model Wewill take up each technique, one by one

Component Arrangement

Component arrangement in a data model includes placing the various components or parts

of the data model in a logical manner so that the model is intelligible to the user groups andstakeholders When they review the model, they must be able to anticipate which com-ponent would follow which other

From the point of view of programmers and database implementers, the arrangement ofentity types that makes the most sense would be the order in which data ought to be createdand loaded in the database However, this may not be the ideal arrangement for user groupsand stakeholders You may find that there would be a marked difference in the twoarrangements—those for database practitioners and user groups If so, consider arrangingthe entity types in one way for the user groups in the conceptual data model Use anotherarrangement for the logical data model The logical model is closer to the database prac-titioners than it is for the user groups

In this section, we will concentrate on the practical tips for the layout of the conceptualmodel We will extend these principles to the logical data model in the next section.Layout of Entity Types Layout of the entity types in a data model influences theappearance of the model diagram to a great extent Proper placement of entity typesimproves readability of the data model Also, when you arrange the entity types in anorderly manner, you are more likely to detect any errors in the data model Principles

of proper layout enforce a standard that can be applied to partial data models created byseveral data modelers in a large project

The model diagram usually runs into multiple pages whether you use a specializedCASE tool or use standard diagramming and presentation software First of all, organize