Today’s lecture will discuss Database Plannings, some guidelines on how to select a DBMS, selec CASE (Computer Assisted Software Engineering) and Fact Finding in order to do a good Conceptual Design
Database planning should include Conceptual, Logical and Physical Design. Conceptual design is the data as seen by end-user. Logical design is the data associated with the Model (Relational Model in most cases), but still independent of hardware and software. Physical design is how data will be stored on a specific hardware/software plantorm.
In the conceptual design, you should try to identify the user view for each individual or group of users.
To obtain the user requirements and consequently the conceptual design, one can do each individual user or role needs and then integrate that to get the full conceptual view of the system.
Ideally, the DBMS should be chosen at the Conceptual Design stage. The figure above is a good checklist of possible requirements that a Database needs. Note that not all databases will need all the requirements. However, it is nice to have a checklist like the one above available.
These are some very important questions that one should answer or estimate when purchasing a DBMS. Volume estimates : a prediction of the resources that will be required. Data Usage . Aproximately how many orders will be done during one month ? Will data only be retrieved (really on) or will it be updated ? Will data be updated. If it is only retrieved and only one or a few users, one may consider a personal DBMS.
Below is a weighted factor scoring model. One practical way to select between products (Databases, IP providers, Networks, etc). Each feature is given a Rating (how good it ranks compared to similar items) and a Weight (how important is this feature). The score of each feature is represented by the product of RATING and WEIGHT. The best product will be the one who has the createst final score (sum of all scores). What happens if the product you think is best doesn’t win ? You should not forge the data or simply go with the results that you are not comfortable. You should also not just declare the other project has the winner. You should probably try to analyze each individual item and evaluate to see that they were given the proper rating and weight.
Above are two links above are articles on how to select a specific DBMS. One should consider if they need an Enterprise DBMS where data is stored for the whole organization, a Departmental DBMS, where it is shared by a specific department or group, a personal DBMS that is used by one person, or a Mobile/embedded DBMS that can be used on a PDA or embedded device.
CASE tools are something that we may use in any of the phases (conceptual, logical, physical) of developing your database. An simple example of CASE tools is when you use Microsoft access and create a query with the wizard or the designer and view the query in SQL. If you don’t know how to do this, please contact me. Other things that case tools can do is to help you create an ER diagram and then automatically convert your ER diagram to tables for a specific DBMS.
This diagram shows that there are Upper Case tools (tools that help with Conceptual Design, Logical Design) or LowerCase tools (tools that help with Physical Design or Implementation) as well as Integrated-Case (tools that help with the whole life-cycle of developing a Database. A main problem commonly found in CASE tools is that they are not integrated. They are just for a specific part of the design phase.
As shown below, the CASE tools speed up the process and guarantee a certain consistency. However, besides the Lack of integration between high end (upper case) and low end (lower case) that we discussed in the last slide, CASE tools are often good for creating, but not always as good for modifying. For example, MS-Word can create a web-page very fast with a simple Save AS, but it gives you less flexibility to edit and Notepad (manually) may work better for modifying web-pages. I once used a Case tool called Jennifer that automatically generated Database Applications for DBASE II and FOXBASE. We were developing software in the headquarters of a company that had branches throughout Brazil. The CASE tool really speeded up our process. However, when we tested in the branches, we found out that the CASE tool had generated very inefficient code (the computers at the branches were very slow. Another problem of CASE tools is that they tend to generates Silver bullet syndrome. Silver bullet syndrome is when the developers find a new tool or solution and thinks that it will solve all their problems. They believe that the tool will do magic. The problem with this is that they then provide management with an unrealistic schedule. Studies have shown that CASE tools frequently give you an illusion that they will accelerate the software development process significantly (such as four or five times faster) and they usually only accelerate about 20% even if we use the correct case tools. I am going to try to illustrate with the next slide.
The Categories form below Creates, Reads, Updates and Deletes rows in the Categories table. Likewise, the Customers, Employees, Suppliers and Products table do the same. Using MS-Access’s Form Wizard to create forms, you can create these forms very fast. Perhaps 5 or 10 times faster than you can do it with Java or C++, for example. However, a CASE will not help much with the ORDERS form. It cannot automatically generate a form that performs ad-hoc operations/more complicated operations. And in a software/database development project, it is the hard tasks that take up the most time and really delay a project.
A CASE tool is great for creating a Prototype or a working module. Not that great to create the final version.
Next we will analyze Fact Finding. When creating a Database or Developing a New software the first phase (even before Conceptual or Logical Design) is to do fact finding (or also called requirements analysis). There are many different techniques to find out what the user needs: interviews, questionnaires, document gathering, etc. We will discuss them in the next slides.
Although companies usually use a combination of two or more methods from the list above, interviewing is the most popular.
Documents refer to gathering existing forms, reports and other documents that the company currently uses to operate the business that we are trying to automate. These documents may be manually generated or from an existing Information Systems that we are trying to improve. The idea behind Documents is that by knowing the Input and the Output, one can figure out the process.
Interviews, like I said in a previous slide, is the most popular. It is very flexible and enables the interviewer to adapt as needed. The face-to-face provides insights that otherwise it wouldn’t be possible. The interviewer can alter the nature of the interview as they feel necessary.
Here is a summary of the adv/disadv. of interview. Of course, the success of the interview also depends on how prepared the interviewer is.
It is important that we know who to interview. Frequently, to satisfy both technical and political problems, we need to interview the person who is formally in charge as well as the person who really knows/does the work. In designing interview questions it is important that we find the right balance between open ended such as “What do you think needs improvement in the current system” and closed ended questions such as “Is the maximum discount that a customer can have 5 or 10% ? In the next slides we will also look at Preparing, Conducting and Post-Interview
Before going to interview a client, the interviewer should develop a list of questions as well as follow-up questions for antecipated answers. Such as, if the user responds with X to question Y, I will follow up with question Z . It is important that the inteviewee is informed why they are being interviewed as well as the areas of discussion. This will allow the inverviewee to feel more comfortable and not only be more collaborative with the interview, but have a better feeling of the project.
The interviewer should ask unbiased questions such as “Do you think that the current system serves its purpose well” instead of “Why do you think the system is no good”. Tape recording may be an interesting option. However, one must check if it doesn’t go against the company’s policy as well as ask if the interviewee doesn’t mind. One should also be political about taping. Should say that there time is very important and taping would reduce the number of questions that you may ask later INSTEAD of saying that you are taping to make sure they don’t change there mind. Separate facts from opinions. A frequent opinion of the intervewee is that he/she is overloaded with work. It is important that the interviewer shows the interviewee self-confidence. If the interviewer shows signs of fear or lack of enthusiasm, the interviewee will feel the same
It is important to write down a summary of the interview ASAP. If one takes too long to do so, one might forget important parts of the interview.
For complex tasks, an interesting technique may be observing the professional perform their regular activities and observe some intrinsic characteristics that can’t be observed otherwise. In certain scenarios, one may want to apply VERBAL PROTOCOLS. In Verbal Protocols, one tries to go inside the mind of somebody that is performing a certain task. To do this, we must encourage them to think aloud. There is literature on how to best do this.
A main problem with Verbal Protocols is that people react different when they are being observed. Therefore it is crucial that you explain to the person being observed that they are not the subject of the evaluation. They are just being observed in order to improve the process. Nevertheless, my experience is that some people will still not believe you, while some people will. It is preferred that more spontaneous individuals are chosen for observation. Also, you must check on the laws, IRB, and normally it is required that the person who is being observed signs a waiver agreeing to it.
Research is an interesting option also. Suppose you are going to develop a stock market analysis program or a point of sale program. A quick way to find out about the subject (even before you interview the client) is to download and run software similar to the one you want to design and implement.
Questionnaires allow us to reach a huge number of individuals. When we are referring to questionnaires, we are not referring to questions that can be elaborated for the interview, but questions that are sent alone.
Questionnaires lack flexibility and they typically have a very low response rate.
JAD or Group interview may be an interesting option. JAD (Joint Application Development) is a term proposed by IBM and it is basically a structured form of group interview where all stakeholders participate (developers, end-users, managers, etc.). My experience with this is that JAD will apply better depending on what type of organization. We did JAD when I worked for the Brazilian Navy and the higher ranked officers dominated the conversation while the lower ranked officers that were really more familiar with the work to be developed shied away from giving their opinion due to the high level of hierarchical power.
CS8630 Dr. Mario Guimaraes Database Planning, Selecting DBMS, Case Tools and Fact Finding