Requirement Analysis Software Development Activities and Database Normalization

Requirement Analysis, Software Development Activities and Database Normalization Analisa dan Perancangan Sistem Informasi By Zulkarnain, Skom Batam, Tuesday, 27 April 2010

Requirements analysis l l l Requirements analysis in systems engineering and software engineering, encompasses those tasks that go into determining the needs or conditions to meet for a new or altered product, taking account of the possibly conflicting requirements of the various stakeholders, such as beneficiaries or users. Requirements analysis is critical to the success of a development project. [ Requirements must be actionable, measurable, testable, related to identified business needs or opportunities, and defined to a level of detail sufficient for system design.

Waterfall Model For Software Development In Royce's original Waterfall model, the following phases are followed in order: l Requirements specification l Design l Construction (implementation or coding) l Integration l Testing and debugging (Validation) l Installation l Maintenance

Data Redundancy l l Data redundancy, sometimes refers to in computer data storage, is a property of some disk arrays (most commonly in RAID systems) which provides fault tolerance, so that all or part of the data stored in the array can be recovered in the case of disk failure. Redundancy is attained when the same data values are stored more than once in a table, or when the same values are stored in more than one table. To prevent redundancy in Database Tables, database normalization should be done to prevent redundancy and any other problems that might affect the performance of the database. One of the biggest disadvantages of data redundancy is that it increases the size of the database unnecessarily. Also data redundancy might cause the same result to be returned as multiple search results when searching the database causing confusion and clutter in results.

Database Normalization l In the field of relational database design, normalization is a systematic way of ensuring that a database structure is suitable for general-purpose querying and free of certain undesirable characteristics that could lead to a loss of data integrity

Database Normalization Objectives of normalization l l l Free the database of modification anomalies Minimize redesign when extending the database structure Make the data model more informative to users

Database Normalization 1 st Normal Form (1 NF) l A table (relation) is in 1 NF if: 1. There are no duplicated rows in the table. 2. Each cell is single-valued (no repeating groups or arrays). 3. Entries in a column (field) are of the same kind. 2 nd Normal Form (2 NF) l A table is in 2 NF if it is in 1 NF and if all non-key attributes are dependent on all of the key. 3 rd Normal Form (3 NF) l A table is in 3 NF if it is in 2 NF and if it has no transitive dependencies.

l Rule 1: Eliminate Repeating Groups. Make a separate table for each set of related attributes, and give each table a primary key. Unnormalized Data Items for Puppies l puppy number l puppy name l kennel code l kennel name l kennel location l trick ID l trick name l trick where learned l skill level l In the original list of data, each puppy description is followed by a list of tricks the puppy has learned. Some might know 10 tricks, some might not know any. Moving the tricks into a seperate tablehelps considerably. Seperating the repeating groupsof tricks from the puppy information results in first normal form. Now we can answer our question with a direct retrieval look to see if Fifi’s puppy number and the trick ID for “roll over” appear together in the trick table. l l First Normal Form: l Puppy Table puppy number puppy name kennel location l Trick Table puppy number trick ID trick name trick where learned skill level — primary key

l Rule 2: Eliminate Redundant Data, if an attribute depends on only part of a multi-valued key, remove it to a separate table. The trick name (e. g. “roll over”) appears redundantly for every puppy that knows it. Just trick ID whould do. l TRICK TABLE Puppy Number Trick ID Trick Name Where Learned Skill Level 52 27 ”roll over” 16 9 53 16 ”Nose Stand” 9 9 54 27 ”roll over” 9 5 *Note that trick name depends on only a part (the trick ID) of the multi-valued, i. e. composite key. l l l Second Normal Form l puppy table puppy number puppy name kennel code kennel name kennel location l tricks table tricks ID tricks name l Puppy-Tricks puppy number trick ID trick where learned skill level Suppose you want to reclassify a trick, i. e. to give it a different trick ID. The change has to be made for every puppy that knows the trick. If you miss some of the changes, you will have several puppies with the same trick under different IDs, this is an update anomaly.

l l l Rule 3: Eliminate columns not dependent on key. If attributes do not contribute to a description of the key, remove them to a separate table. l Puppy Table puppy number puppy name kennel code kennel name The puppy table satisfies the first normal form, since in contains no repeating groups. It satisfies the second normal form, since it does not have a multivalued key. But the key is puppy number , and the kennel name and the kennel location describe only a kennel, not a puppy. To achieve third normal form, they must be moved into a separate table. Since they describe a kennel, kennel code becomes the key of the new “kennels” table. Third Normal Form l Puppies puppy number puppy name kennel code l Kennel kennel code kennel name kennel location l Tricks trick ID trick name l Puppy Tricks puppy number trick ID trick where learned skill level The motivation for this is the same as for the second normal form. We want to avoid update and delete anomalies. For example suppose no puppies from the Puppy Farm were currently stored in the database. With the previous design, there would be no record of its existence.