Instructor

Chapter 9 of the textbook delved into database design, which has two steps — (1) creating a logical database model and (2) creating a physical database model — which are often done parallel with other system design steps.

Logical database modeling has four key steps:

1. Develop a logical data model for each known user interface (form and report) for the application using normalization principles.
2. Combine normalized data requirements from all user interfaces into one consolidated logical database model; this step is called view integration.
3. Translate the conceptual E-R data model for the application or enterprise, developed without explicit consideration of specific user interfaces, into normalized data requirements.
4. Compare the consolidated logical database design with the translated E-R model and produce, through view integration, one final logical database model for the application.

In the physical design, you choose things like datatype, file organization, storage media, and much more. It’s where you really start to worry about storage space and speed.

One of the most important aspects of database design is picking primary keys. Primary keys are a unique field (or fields) that allow an individual record to be identified. Records from one table can then be associated with those from another, by way of foreign key, which is the primary key from another table. Normalization and the different normal forms are also based around the primary keys. In first normal form, there are unique rows and no attributes with multiple values in them. In second normal form, each nonprimary key attribute is identified by the whole primary key. In third normal form, nonprimary key attributes do not depend on each other.

Practical Assignment Three

5203_09_Software_Design

An important concept from this unit’s reading that stood out to me was the concept of normalization. Normalization is one of the main concepts applied when designing the logical database. Normalization is the process used by database designers to create intuitive, well-structured databases. Normalization takes complex inputs, such as data structures, and converts them into simple, non-redundant, low-maintenance structures. Normalization employs non redundancy by following the concept of functional dependence, which creates relationships between attributes that are dependent on each other. Normalization is such an important concept in logical database design because it promotes this non-redundancy. Redundancy in database design is not only bad practice – it is also costly and ineffective. If a database stores the same data in multiple places, these values may contradict each other, which causes the integrity of the database to fail as no one knows which value is correct. This is also costly because you are paying to store the same data more than once. Database storage is already costly as it is, so it is important to prevent redundancy as much as possible.

-Taylor Trench

8_MACKEY_Database

The previous chapter focused on the flow of information and processes, while Chapter 8 of MSAD focused on data requirements. Data models are important because they can serve as the foundation for database design. And since data are often the most complex aspects of information systems, data modeling needs to be comprehensive and accurate. One interesting point I found was that “an information system design based on a data orientation, rather than a process or logic orientation, should have a longer useful life and should have common features for the same applications or domains in different organizations.”

ERDs, or entity relationship diagrams, are the most common form used for data modeling. Class diagrams are used for object-oriented analysis. You can go about it with either a top-down or bottom-up approach. Top-down comes from an intimate understanding of the nature of the business. Bottom-up comes from reviewing business documents and knowing what data are needed. An entity is a person, place, object, event, or concept about which the organization wishes to maintain data. An entity type (sometimes called an entity class) is a collection of entities that share common properties or characteristics. An entity instance is a single occurrence of an entity type. It’s important to have clear, descriptive names so everyone knows what is being referenced. Thus there are specific entity and attribute naming guidelines. 

The display of the relationships are important in these data models. The three most common types are unary, binary and ternary. Unary is a recursive relationship. Binary is between instances of two entity types (most common). Ternary a relationship among three entity types. Diagrams can show mandatory or optional relationships and even subtypes and supertypes (hierarchy). 

5203_06_Structural_Models

Chapter 7 of Modern Systems Analysis and Design was all about process modeling and data flow diagrams. My biggest takeaway is that DFDs are an important way to map requirements and processes to allow for further analysis. The context diagram gives an overview of the system, while level-n DFD diagrams progressively break down the processes.  

There are two standard sets of symbols used in data flow diagrams. However, overall best practices can be universal. DFDs contain data stores, processes, and sources/sinks. A data store is data at rest. It can be a physical location. A process is the actions performed on data. It can be done manually or by a computer. A source/sink is the origin and/or destination of data. They are outside of the system.

The following are important concepts to remember when creating data flow diagrams:

• Completeness – need to have all the necessary components for the system, everything should be labeled and described
• Consistency – the depictions of the system at the different levels must be compatible 
• Timing – DFDs can’t display time so draw them as if the system has never started and will never stop
• Iterative Development – the first DFD will rarely capture everything so it’s important to keep improving
• Primitive DFDs – deciding when to stop decomposing processes, one rule is to stop drawing when you have reached the lowest logical level

It’s also important to remember the DFD rules (e.g. no process can have only outputs.)

The book draws a clear line between traditional and contemporary methods for gathering requirements.

Traditional methods include interviewing and listening, directly observing users, and analyzing procedures and documents. Interviews can be done with individuals or groups. Either way, it’s one of the primary ways analysts gather information. There are many different interviewing methods. They also start with plenty of prep work, which can include an interview guide to set out a path for the sequence of questions. Open-ended questions are used to probe for new information, while close-ended questions allow for respondents to pick from a set of options. It’s important for the interviewer to not make it seem like there is a right or wrong answer. Notes should be taken and typed up as soon as possible afterward. Interviewers should seek diverse views and not make any promises in terms of final product. Observation is time consuming and can cause users to change their usual behavior, but is a way to see how things work first hand. Analyzing documents lets you know how things should be done (by the book). Reviewing documents can reveal key individuals, why the current system in the way it is, problems, and much more.

Contemporary methods include Joint Application Design (JAD) and prototyping. JAD is “a structured process in which users, managers, and analysts work together for several days in a series of intensive meetings to specify or review system requirements.” JAD sessions are usually conducted at a place other than where the individuals normally work to remove distractions. They usually involve whiteboards, flipcharts, and other audio-visual elements. The end result should reveal the details of the existing system and features of the new proposed system. Prototyping involves building and rebuilding a rudimentary version of an information system according to user feedback. In evolutionary prototyping, the prototype is the actual foundation for the new system. In throwaway prototyping, it’s a model or mockup that is discarded.

There are also radical methods like business process reengineering and introducing disruptive technologies. 

Agile methods involve continual user involvement and focus on the user.

The success of a project starts before the project is ever even close to beginning. As explained in Chapters 4 and 5, a lot of the fate of the project is really determined in the identification, selection, initiation, and planning phases (which all fall within the larger planning phase). Identification can come from many sources, whether it be the steering committee or from bottom-up like user departments. Before projects are selected they should be evaluated for benefits, risks, size/duration and other factors. They should also line up with the overall strategic plan of the organization. Before a project is started, a business case needs to be put together. That is a justification of the project in terms of tangible and intangible benefits, costs, and feasibility. There are many feasibility factors, but I think two of the most important are economic feasibility and technical feasibility. Economic feasibility can be analyzed by calculating project costs and benefits over time. The end results can be a break-even analysis, return on investment, or something else that shows whether the project will be profitable over time. Technical feasibility has to do with whether the system can actually be built or integrated into the current environment. All these things are important so that a project has less risk of being abandoned, wasting money. It’s better to determine before the project begins that it is not one your organization wants to pursue than realizing that six months into it.