Database Fundamentals- Content Analysis

profilewostinabin2
Week3-Lectureslides-20200617.zip
Home>Information Systems homework help>Database Fundamentals- Content Analysis

DB-Lecture3_ch03.ppt

Database Principles: Fundamentals of Design, Implementations and Management

CHAPTER 3

Relational Model Characteristics

Objectives

  • In this chapter, you will learn:
  • That the relational database model offers a logical view of data
  • About the relational model’s basic component: relations
  • That relations are logical constructs composed of rows (tuples) and columns (attributes)
  • That relations are implemented as tables in a relational DBMS
  • About relational database operators, the data dictionary, and the system catalog
  • How data redundancy is handled in the relational database model
  • Why indexing is important

*

A Logical View of Data

  • Relational model
  • Enables the programmer to view data logically rather than physically
  • Table
  • Has structural and data independence
  • Resembles a file conceptually
  • Relational database model easier to understand than its hierarchical and network database predecessors models
  • Table also called a relation because the relational model’s creator, Codd, used the term relation as a synonym for table

*

Tables and Their Characteristics

  • Logical view of relational database based on relation
  • Relation thought of as a table
  • Think of a table as a persistent relation:
  • A relation whose contents can be permanently saved for future use
  • Table: two-dimensional structure composed of rows and columns
  • Persistent representation of logical relation
  • Contains group of related entities = an entity set

*

Properties of a Relation

*

Example Relation / Table

*

Attributes and Domains

*

  • Each attribute is a named column within the relational table and draws its values from a domain.

  • The domain of values for an attribute should contain only atomic values and any one value should not be divisible into components.

  • No attributes with more than one value are allowed.

Degree and Cardinality

  • Degree and cardinality are two important properties of the relational model.

  • A relation with N columns and N rows is said to be of degree N and cardinality N.

  • The degree of a relation is the number of its attributes and the cardinality of a relation is the number of its tuples.

  • The product of a relation’s degree and cardinality is the number of attribute values it contains.

*

Relational Schema

A relational schema is a textual representation of the database tables, where each table is described by its name followed by the list of its attributes in parentheses.

Keys

  • A key consists of one or more attributes that determine other attributes

  • Primary key (PK) is an attribute (or a combination of attributes) that uniquely identifies any given entity (row)

  • A Key’s role is based on determination
  • If you know the value of attribute A, you can look up (determine) the value of attribute B

*

*

Keys (cont..)

Relational Database Keys (cont….)

  • Composite key
  • Composed of more than one attribute
  • Key attribute
  • Any attribute that is part of a key
  • Superkey
  • Any key that uniquely identifies each row
  • Candidate key
  • A superkey without redundancies and without unnecessary attributes
  • Ex: Stud_ID, Stud_lastname

*

Keys (cont..)

  • Nulls:
  • No data entry
  • Not permitted in primary key
  • Should be avoided in other attributes
  • Can represent
  • An unknown attribute value
  • A known, but missing, attribute value
  • A “not applicable” condition
  • Can create problems when functions such as COUNT, AVERAGE, and SUM are used
  • Can create logical problems when relational tables are linked
  • Controlled redundancy:
  • Makes the relational database work
  • Tables within the database share common attributes that enables the tables to be linked together
  • Multiple occurrences of values in a table are not redundant when they are required to make the relationship work
  • Redundancy exists only when there is unnecessary duplication of attribute values

*

Keys (cont..)

*

Keys (cont..)

*

Keys (cont..)

  • Foreign key (FK)
  • An attribute whose values match primary key values in the related table
  • Referential integrity
  • FK contains a value that refers to an existing valid tuple (row) in another relation
  • Secondary key
  • Key used strictly for data retrieval purposes

*

Integrity Rules

  • Many RDBMs enforce integrity rules automatically
  • It is safer to ensure that your application design conforms to entity and referential integrity rules
  • Rules are summarized in the next slide

  • Designers use flags to avoid nulls
  • Flags indicate absence of some value
  • For Ex, the code -99 could be used as the AGENT_CODE entry for the 4th row of the CUSTOMER Table to indicate that customer Paul Olowsky does not have yet an agent assigned to it

*

Integrity Rules

*

Integrity Rules

*

The Data Dictionary and System Catalog

  • Data dictionary

  • Provides detailed accounting of all tables found within the user/designer-created database

  • Contains (at least) all the attribute names and characteristics for each table in the system

  • Contains metadata: data about data

  • Sometimes described as “the database designer’s database” because it records the design decisions about tables and their structures

*

*

A Sample Data Dictionary

The Data Dictionary and System Catalog (cont..)

  • System catalog
  • Contains metadata

  • Detailed system data dictionary that describes all objects within the database

  • Terms “system catalog” and “data dictionary” are often used interchangeably

  • Can be queried just like any user/designer-created table

*

Relationships within the Relational Database

  • 1:M relationship
  • Relational modeling ideal
  • Should be the norm in any relational database design
  • 1:1 relationship
  • Should be rare in any relational database design
  • M:N relationships
  • Cannot be implemented as such in the relational model
  • M:N relationships can be changed into two 1:M relationships

*

The 1:M Relationship

  • Relational database norm
  • Found in any database environment

*

*

The 1:M Relationship (cont…)

The 1:1 Relationship

  • One entity related to only one other entity, and vice versa
  • Sometimes means that entity components were not defined properly
  • Could indicate that two entities actually belong in the same table
  • Certain conditions absolutely require their use
  • As rare as 1:1 relationships should be, certain conditions absolutely require their use

*

*

The 1:1 Relationship (cont…)

*

The 1:1 Relationship (cont…)

The M:N Relationship

  • Can be implemented by breaking it up to produce a set of 1:M relationships
  • Avoid problems inherent to M:N relationship by creating a composite entity or a bridge entity
  • The composite entity Includes -as foreign keys- at least the primary keys of the tables that are to to be linked

*

  • Implementation of a composite entity
  • Yields required M:M to 1:M conversion
  • Composite entity table must contain at least the primary keys of original tables
  • Linking table contains multiple occurrences of the foreign key values
  • Additional attributes may be assigned as needed

*

The M:M Relationship (cont..)

*

The M:M Relationship (cont…)

*

Figure 3.16 in the book

*

Figure 3.17 in your book

*

Data Redundancy Revisited

  • Data redundancy leads to data anomalies
  • Such anomalies can destroy the effectiveness of the database

  • Foreign keys
  • Control data redundancies by using common attributes shared by tables
  • Crucial to exercising data redundancy control

  • Sometimes, data redundancy is necessary

*

Data Redundancy Revisited (cont…)

*

Data Redundancy Revisited (cont..)

*

*

Data Redundancy Revisited (cont…)

Indexes

  • Orderly arrangement to logically access rows in a table
  • Index key
  • Index’s reference point
  • Points to data location identified by the key
  • Unique index
  • Index in which the index key can have only one pointer value (row) associated with it
  • Each index is associated with only one table

*

*

Indexes (cont..)

Similar to Figure 3.20 of your book and better explained

Codd’s Relational Database Rules

  • In 1985, Codd published a list of 12 rules to define a relational database system

  • The reason was the concern that many vendors were marketing products as “relational” even though those products did not meet minimum relational standards

*

Summary

  • Tables (relations) are basic building blocks of a relational database
  • Keys are central to the use of relational tables
  • Keys define functional dependencies
  • Superkey
  • Candidate key
  • Primary key
  • Secondary key
  • Foreign key
  • Each table row must have a primary key which uniquely identifies all attributes
  • Tables can be linked by common attributes. Thus, the primary key of one table can appear as the foreign key in another table to which it is linked

Good design begins by identifying appropriate entities and attributes and the relationships among the entities. Those relationships (1:1, 1:M, M:N) can be represented using ERDs.

*