DATABASE MANAGEMENT SYSTEM (DBMS)
A DBMS is specialized computer software, available from computer vendors that is used to create, access, control and manage the database. The core of the DBMS is often called its database engine. The engine responds to specific commands to create database structure and then to create, read, update and delete records in the’database. The database management system is purchased from a database technology vendor such as Oracle, IBM, Microsoft or Sybase.
- Data Definition Language (DDL) : is used by the DBMS to physically
establish the record types, fields, and structural relationships. Additionally, DDL defines views of the database. Views restrict the portion of the database that may be used or accessed by different users and programs.
- Data Manipulation Language (DML) : A DML is used to create, read, update and delete records in the database and to navigate between records and types of records — for e.g., from a CUSTOMER record to the ORDER record for that customer. The DBMS and DML hides and details concerning how records are organized and allocated to the disk.
In general, DML is very flexible in that it may be used by itself to create, read, update and delete records.
Goals and Prerequisites of Database Design
The goals of database are as follows :
- The database should provide for the efficient storage, update and retrieval of data.
- A database should be reliable — the stored data should have high integrity to promote user trust in the data.
- A database should be adaptable and scalable to new and unforeseen requirements and applications.
- A database should support the business requirements of the information system.
The purpose of design reviews is to ensure that the design satisfies the requirements and is of “good quality”. If errors are made during the design process, they will ultimately reflect themselves in the code and the final system. As the cost of removing faults caused by errors that occur during design increases with the delay in detecting the errors, it is best if design errors are detected early, before they manifest themselves in the system. Detecting errors in the design is the aim of design reviews.
The system design review process is similar to the other reviews, in that groups of people get together to discuss the design with the aim of revealing design errors or undesirable properties. The review group must include a member of both the system design team, the author of the requirement’s document, the author responsible for maintaining the design document, and an independent software quality engineer.
Each member studies the design before the meeting, and with the aid of a checklist, marked items that the reviewer feels are incorrect or need clarification. The member asks questions and the chief designer tries to explain the situation.
As with any review, the aim of the meeting is to uncover design errors not to try to fix them; fixing is done later. The meeting ends with a list of action items, which are later acted on by the design team. Further, reviews may be organized, if needed.
During reviews, element of design that are not conducive to modification and expansion or elements that fail to conform to design standards should also be considered “errors”.
CODE REVIEWS .
The review process was started with the purpose of detecting defects in the code. Though design reviews substantially reduce defects in code, reviews are still very usefult and can enhance reliability and reduce efforts during testing. Code reviews are designed to detect defects that originate during the coding process, although they can also detect defects in detailed design.
Code inspections are usually held after code has been successfully completed and other forms of static tools have been applied but before any testing has been performed. Therefore, activities like code reading, symbolic execution and static analysis should be performed, and defects found by these techniques corrected before code reviews are held. The main motivation for this is to save human time and effort, which would otherwise be spent detecting errors that a compiler or static analyzer can detect.
The documentation to be distributed to the review team members includes the code to be reviewed and the design document. The review team for code reviews should include the programmer, the designer, and the tester. The review starts with the preparation for the review and ends with a list of action items.
The aim of reviews is to detect defects in code. One obvious coding defect is that the code fails to implement the design. This can occur in many ways. The function implemented by a module may be different from the function actually defined in the design or the interface of the modules may not be the same as the interface specified in the design.