Chapter 2 Relational Models Chapter Review Questions Concepts of Database Management 8th Edition

Main Trunk

Chapter vii The Relational Data Model

Adrienne Watt

The relational data model was introduced past Due east. F. Codd in 1970. Currently, information technology is the near widely used information model.

The relational model has provided the basis for:

• Inquiry on the theory of data/relationship/constraint
• Numerous database design methodologies
• The standard database access language chosen structured query language (SQL)
• Nigh all modern commercial database management systems

The relational data model describes the globe as "a drove of inter-related relations (or tables)."

Fundamental Concepts in the Relational Data Model

Relation

Arelation,likewise known as a tabular array or file, is a subset of the Cartesian production of a list of domains characterized past a name. And within a table, each row represents a group of related information values. A row, or record, is likewise known as a tuple. The columns in a tabular array is a field and is likewise referred to as an aspect. You can also recollect of it this way: an attribute is used to define the record and a tape contains a set of attributes.

The steps below outline the logic between a relation and its domains.

1. Given north domains are denoted by D1, D2, … Dn
2. And r is a relation defined on these domains
3. Then  r ⊆ D1×D2×…×Dn

Table

A database is equanimous of multiple tables and eachtabular array holds the data. Figure seven.1 shows a database that contains three tables.

Figure 7.1. Database with three tables.

Column

A database stores pieces of data or facts in an organized way. Understanding how to use and get the nigh out of databases requires united states of america to empathize that method of system.

The principal storage units are called columns or fields or attributes. These business firm the bones components of information into which your content can be broken downward. When deciding which fields to create, you need to think generically most your data, for instance, drawing out the common components of the information that yous will store in the database and avoiding the specifics that distinguish 1 item from another.

Look at the example of an ID bill of fare in Effigy 7.2 to see the human relationship between fields and their data.

Effigy seven.2. Example of an ID card by A. Watt.

Domain

A domain is the original sets of atomic values used to model information. By diminutive value, we hateful that each value in the domain is indivisible as far as the relational model is concerned. For instance:

• The domain of Marital Status has a prepare of possibilities: Married, Single, Divorced.
• The domain of Shift has the set of all possible days: {Mon, Tue, Wed…}.
• The domain of Salary is the set of all floating-signal numbers greater than 0 and less than 200,000.
• The domain of Offset Proper name is the set of character strings that represents names of people.

In summary, a domain is a gear up of acceptable values that a column is allowed to contain. This is based on various properties and the data blazon for the cavalcade. Nosotros will talk over data types in another chapter.

Records

Just every bit the content of any ane certificate or item needs to be broken downward into its elective bits of data for storage in the fields, the link between them also needs to be available and so that they can be reconstituted into their whole form. Records allow us to do this. Records contain fields that are related, such as a customer or an employee. Equally noted earlier, a tuple is another term used for record.

Records and fields grade the footing of all databases. A unproblematic tabular array  gives usa the clearest picture of how records and fields piece of work together in a database storage project.

Figure 7.3. Instance of a elementary table by A. Watt.

The uncomplicated tabular array example in Effigy 7.3 shows us how fields can hold a range of different sorts of data. This one has:

• A Tape ID field: this is an ordinal number; its data type is an integer.
• A PubDate field: this is displayed as day/month/year; its information type is date.
• An Author field: this is displayed as Initial. Surname; its data type is text.
• A Title field text: free text can be entered here.

You tin can control the database to sift through its information and organize information technology in a particular way. For example, you can request that a selection of records exist limited by date: i. all before a given engagement, two. all afterward a given date or 3. all between two given dates. Similarly, you can cull to accept records sorted past date. Because the field, or record, containing the information is set up as a Date field, the database reads the data in the Date field not just as numbers separated by slashes, but rather, as dates that must be ordered according to a calendar system.

Degree

The degree is the number of attributes in a table. In our example in Effigy 7.3, the degree is four.

Properties of a Table

• A table has a name that is singled-out from all other tables in the database.
• There are no duplicate rows; each row is singled-out.
• Entries in columns are atomic. The table doesnot contain repeating groups or multivalued attributes.
• Entries from columns are from the same domain based on their data type including:
  • number (numeric, integer, bladder, smallint,…)
  • grapheme (string)
  • date
  • logical (true or false)
• Operations combining different data types are disallowed.
• Each attribute has a distinct name.
• The sequence of columns is insignificant.
• The sequence of rows is insignificant.

atomic value: each value in the domain is indivisible as far every bit the relational model is concernedattribute: principle storage unit of measurement in a database

column: come across attribute

degree: number of attributes in a table

domain: the original sets of diminutive values used to model data; a set of adequate values that a cavalcade is allowed to comprise

field: seeattribute

file:see relation

record: contains fields that are related; see tuple

relation: a subset of the Cartesian product of a listing of domains characterized by a proper name; the technical term for table or file

row: meet tuple

structured query language (SQL): the standard database admission language

tabular array:come across relation

tuple: a technical term for row or record

Terminology Key

Several of the terms used in this chapter are synonymous. In add-on to the Key Terms above, please refer to Table 7.1 below. The terms in the Alternative i column are nigh ordinarily used.

Tabular array vii.1. Terms and their synonyms by A. Watt.

Use Table seven.2 to answer questions ane-4.

1. Using right terminology, place and describe all the components  in Table 7.2.
2. What is the possible domain for field EmpJobCode?
3. How many records are shown?
4. How many attributes are shown?
5. List the properties of a table.

Tabular array seven.two. Table for exercise questions, by A. Watt.

 Attribution

This chapter of Database Design (including images, except as otherwise noted) is a derivative copy of Relational Design Theory  by Nguyen Kim Anh licensed underCreative Commons Attribution License three.0 license

The following material was written by Adrienne Watt:

1. All or part of the sections on relations, tables, columns and degree
2. Key Terms
3. Exercises

carlefalwye.blogspot.com

Source: https://opentextbc.ca/dbdesign01/chapter/chapter-7-the-relational-data-model/

Share this post