Chapter 2: Review Q;A – Flashcards

A data model is a relatively simple representation, usually graphical, of a more complex real world object event. The data model's main function is to help us understand the complexities of the real-world environment. The database designer uses data models to facilitate the interaction among designers, application programmers, and end users. In short, a good data model is a communications device that helps eliminate (or at least substantially reduce) discrepancies between the database design's components and the real world data environment. The development of data models, bolstered by powerful database design tools, has made it possible to substantially diminish the database design error potential. (Review Section 2.1 in detail.)

A business rule is a brief, precise, and unambigous description of a policy, procedure, or principle within a specific organization's environment. In a sense, business rules are misnamed: they apply to any organization -- a business, a government unit, a religious group, or a research laboratory; large or small -- that stores and uses data to generate information. Business rules are derived from a description of operations. As its name implies, a description of operations is a detailed narrative that describes the operational environment of an organization. Such a description requires great precision and detail. If the description of operations is incorrect or inomplete, the business rules derived from it will not reflect the real world data environment accurately, thus leading to poorly defined data models, which lead to poor database designs. In turn, poor database designs lead to poor applications, thus setting the stage for poor decision making - which may ultimately lead to the demise of the organization. Note especially that business rules help to create and enforce actions within that organization's environment. Business rules must be rendered in writing and updated to reflect any change in the organization's operational environment. Properly written business rules are used to define entities, attributes, relationships, and constraints. Because these components form the basis for a database design, the careful derivation and definition of business rules is crucial to good database design.

As a general rule, a noun in a business rule will translate into an entity in the model, and a verb (active or passive) associating nouns will translate into a relationship among the entities. For example, the business rule "a customer may generate many invoices" contains two nouns (customer and invoice) and a verb ("generate") that associates them.

The three languages were: 1. The DDL (schema) constitutes the Data Definition Language for the database schema. The DDL's use enabled the database administrator to define the database schema, i.e., its over all blueprint. 2. The DDL (subschema) allows the definition of the specific database components that will be used by each application. 3. The DML is the Data Manipulation Language that allows us to manipulate the database contents. Standardization is important to users and designers because it allows them to shift from one commercial application to another with little trouble when they operate at the logical level.

A relational database is a single data repository that provides both structural and data independence while maintaining conceptual simplicity. The relational database model is perceived by the user to be a collection of tables in which data are stored. Each table resembles a matrix composed of row and columns. Tables are related to each other by sharing a common value in one of their columns. The relational model represents a breakthrough for users and designers because it lets them operate in a simpler conceptual environment. End users find it easier to visualize their data as a collection of data organized as a matrix. Designers find it easier to deal with conceptual data representation, freeing them from the complexities associated with physical data representation.

An entity relationship model, also known as an ERM, helps identify the database's main entities and their relationships. Because the ERM components are graphically represented, their role is more easily understood. Using the ER diagram, it's easy to map the ERM to the relational database model's tables and attributes. This mapping process uses a series of well-defined steps to generate all the required database structures. (This structures mapping approach is augmented by a process known as normalization, which is covered in detail in Chapter 6 "Normalization of Database Tables.")

An object has greater semantic content because it embodies both data and behavior. That is, the object contains, in addition to data, also the description of the operations that may be performed by the object.

An object is an instance of a specific class. It is useful to point out that the object is a run-time concept, while the class is a more static description. Objects that share similar characteristics are grouped in classes. A class is a collection of similar objects with shared structure (attributes) and behavior (methods.) Therefore, a class resembles an entity set. However, a class also includes a set of procedures known as methods.

The Extended Relational Data Model (ERDM) is the relational data model's response to the Object Oriented Data Model (OODM.) Most current RDBMSes support at least a few of the ERDM's extensions. For example, support for large binary objects (BLOBs) is now common. Although the "ERDM" label has frequently been used in the database literature to describe the relational database model's response to the OODM's challenges, C. J. Date objects to the ERDM label for the following reasons: • The useful contribution of "the object model" is its ability to let users define their own -- and often very complex -- data types. However, mathematical structures known as "domains" in the relational model also provide this ability. Therefore, a relational DBMS that properly supports such domains greatly diminishes the reason for using the object model. Given proper support for domains, relational database models are quite capable of handling the complex data encountered in time series, engineering design, office automation, financial modeling, and so on. Because the relational model can support complex data types, the notion of an "extended relational database model" or ERDM is "extremely inappropriate and inaccurate" and "it should be firmly resisted." (The capability that is supposedly being extended is already there!) • Even the label object/relational model (O/RDM) is not quite accurate, because the relational database model's domain is not an object model structure. However, there are already quite a few O/R products -- also known as Universal Database Servers -- on the market. Therefore, Date concedes that we are probably stuck with the O/R label. In fact, Date believes that "an O/R system is in everyone's future." More precisely, Date argues that a true O/R system would be "nothing more nor less than a true relational system -- which is to say, a system that supports the relational model, with all that such support entails."

Remind students to review the definitions of data- and structural independence found in Chapter 1, "Database Systems." Data independence exists when it is possible to make changes in the data storage characteristics without affecting the application program's ability to access the data. Conversely, data dependence exists when an application program is unable to access the data after a change in the data storage characteristics has been made. The practical significance of data dependence is the difference between the logical data format (how the human being views the data) and the physical data format (how the computer "sees" the data). Because a file system exhibits data dependence, any program that accesses a file system's file must not only tell the computer what to do, but also how to do it. In contrast to the file system, a relational database exhibits data independence. Therefore, anyprogram can access the data regardless of a change in the data storage characteristics. For example, if you want to get a listing of all the customers whose last name is "Smith" in a relational database, the command set SELECT * FROM CUSTOMER WHERE CUS_LNAME = "Smith"; reads the same regardless of the last name field's size (for example, up to 20 bytes or up to 35 bytes) or characterics (fixed field length or variable field length). NOTE Although students have not yet been introduced to Structured Query Language (SQL), the relational database query language standard, this command set is simple enough to serve as a discussion vehicle. If you explain that the "*" symbol in the SELECT statement means "all" to indicate that all the records are to be selected, the remaining components FROM and WHERE are self-explanatory. You can dermonstrate this command with any of the MS Access databases that unclude a CUSTOMER table. For example, use the Ch02_InsureCo database - see Figure 2.1 for the data - to make the point Structural independence exists when it is possible to make changes in the database structure without affecting the application program's ability to access the data. For example, the preceding SQL command set works fine regardless of whether the CUS_LNAME is listed first, third, or last in the CUSTOMER table structure.

A relationship is an association among (two or more) entities. Three types of relationships exist: one-to-one (1:1), one-to-many (1:M), and many-to-many (M:N or M:M.)

1:1 An academic department is chaired by one professor; a professor may chair only one academic department. 1:M A customer may generate many invoices; each invoice is generated by one customer. M:N An employee may have earned many degrees; a degree may have been earned by many employees.

Strictly speaking, the relational data model bases data storage on relations. These relations are based on algebraic set theory. However, the user perceives the relations to be tables. In the relational database environment, designers and users perceive a table to be a matrix consisting of a series of row/column intersections.Tables, also called relations, are related to each other by sharing a common entity characteristic. For example, an INVOICE table would contain a customer number that points to that same number in the CUSTOMER table. This feature enables the RDBMS to link invoices to the customers who generated them. Tables are especially useful from the modeling and implementation perspecectives. Because tables are used to describe the entities they represent, they provide ane asy way to summarize entity characteristics and relationships among entities. And, because they are purely conceptual constructs, the designer does not need to be concerned about the physical implementation aspects of the database design.

A relational diagram is a visual representation of the relational database's entities, the attributes within those entities, and the relationships between those entities. Therefore, it is easy to see what the entities represent and to see what types of relationships (1:1, 1:M, M:N) exist among the entities and how those relationships are implemented. An example of a relational diagram is found in the text's Figure 2.2.