Database Systems: Design, Implementation and Management 13th Edition solution manual
8. List and describe the different types of databases.
The focus is on Section 1-3b, TYPES OF DATABASES. Organize the discussion around the number of users, database site location, and data use:
- Number of users
- Single-user
- Multiuser
- Workgroup
- Enterprise
- Database site location
- Centralized
- Distributed
- Cloud-based
- Type of data
- General-purpose
- Discipline-specific
- Database use
- Transactional (production) database (OLTP)
- Data warehouse database (OLAP)
- Degree of data structure
- Unstructured data
- Structured data
9. What are the main components of a database system?
The basis of this discussion is Section 1-7a, THE DATABASE SYSTEM ENVIRONMENT. Figure 1.10 provides a good bird’s eye view of the components. Note that the system’s components are hardware, software, people, procedures, and data.
10. What is metadata?
Metadata is data about data. That is, metadata define the data characteristics such as the data type (such as character or numeric) and the relationships that link the data. Relationships are an important component of database design. What makes relationships especially interesting is that they are often defined by their environment. For instance, the relationship between EMPLOYEE and JOB is likely to depend on the organization’s definition of the work environment. For example, in some organizations an employee can have multiple job assignments, while in other organizations – or even in other divisions within the same organization – an employee can have only one job assignment.
The details of relationship types and the roles played by those relationships in data models are defined and described in Chapter 2, Data Models.”. Relationships will play a key role in subsequent chapters. You cannot effectively deal with database design issues unless you address relationships.
11. Explain why database design is important.
The focus is on Section 1-4, WHY DATABASE DESIGN IS IMPORTANT. Explain that modern database and applications development software is so easy to use that many people can quickly learn to implement a simple database and develop simple applications within a week or so, without giving design much thought. As data and reporting requirements become more complex, those same people will simply (and quickly!) produce the required add-ons. That's how data redundancies and all their attendant anomalies develop, thus reducing the "database" and its applications to a status worse than useless. Stress these points:
- Good applications can't overcome bad database designs.
- The existence of a DBMS does not guarantee good data management, nor does it ensure that the database will be able to generate correct and timely information.
- Ultimately, the end user and the designer decide what data will be stored in the database.
A database created without the benefit of a detailed blueprint is unlikely to be satisfactory. Pose this question: would you think it smart to build a house without the benefit of a blueprint? So why would you want to create a database without a blueprint? (Perhaps it would be OK to build a chicken coop without a blueprint, but would you want your house to be built the same way?)