Introduction to Database Review 2. Crows-Feet Notation for ER Diagrams This is an alternative to the diamond representation of relationships. Diamond.

Introduction to Database

Review 2

Crows-Feet Notation for ER Diagrams

This is an alternative to the diamond representation of relationships.

Diamond icons are replaced with lines, simplifying the ER schema.

Intuition means “Zero” means “One” means “or more”

Entity 1 Entity 3Entity 2

Zero or one One or more Zero or more Exactly one (mandatory)

Subclasses And Superclasses

Grouping of the entities of an entity type into subgroups (forming an "IS-A" relationship).

Entities in a superclass are grouped into one or more subclasses.

An arbitrary number of levels is permitted in a class hierarchy.

An entity in a subclass exists in the superclass also (recursively).

Subclasses/Superclasses Example

The Customer entity type has the subclasses PreferredCustomer and Employee.

All employees are customers.

Customer

O

EmployeePreferred Customer

Inheritance Among Classes

Entities in a subclass inherit the attributes of the superclass.

A subclass may have its own attributes (termed the specific attributes).

Entities in a subclass may participate in relationships directly (termed specific relationships), and they may participate in relationships via their superclass(es).

6

Inheritance Example

A PreferredCustomer entity inherits the attributes Name, Address, CutomerID and Balance from Customer.

The PreferredCustomer subclass also has the attribute DiscountLevel.

Customer

O

EmployeePreferred Customer

CustomerID

Address

Name

Balance

EmployeeID Discount Level

Schema Design Strategies

Top-down strategy Start out with high-level, abstract concepts and apply step-

wise refinements (e.g., specialization) to add "detail."

Bottom-up strategy Start out with basic concepts and apply refinements (e.g.,

generalization).

Inside-out strategy Start with a few central concepts and successively include

additional concepts.

Mixed strategy Combine the above strategies.

Top-down Strategy

CustomerChecked

Out VideoTape Title

RentalPrice

(0,m)

LengthCustomerID

Name(0,n)

CustomerChecked

Out VideoTape

Film

Copies

TapeNum

Title

RentalPrice

(0,m) (0,n) (1,1)

(0,n)

FilmID

Status

Length

CustomerID

Name

Bottom-up Strategy

Example: discovering a new generalized entity type and relating it.

CustomerCust

Checked Out

VideoTape Title

RentalPrice

(0,m)

LengthCustomerID

Name

Emp Checked

OutEmployeeName

EmployeeID

Length

(0,m)

(0,n)

(0,n)

Bottom-up Strategy, cont.

This is converted to:

CustomerChecked

OutVideoTape Title

RentalPrice

(0,m)

LengthCustomerID

Name(0,n)

EmployeeID

O

Employee Preferred Customer

Conceptual Database Design Approaches

Centralized design approach Integrate first the requirements for all applications and then

design a single schema. Assumes a centralized organization. The DBA merges the multiple sets of requirements. The DBA designs the schema.

View integration approach Design first a schema for each application in isolation, then

integrate the schemas into a single global schema. Each user group can design its own schema. The DBA designs the global schema.

Entity Integrity

Primary Key: A candidate key of a relation is a set of attributes that satisfy two time independent properties: Uniqueness - No two tuples of the relation have the same

values for the set of attributes forming the candidate key. Minimality - No attributes can be discarded from the

candidate key without destroying the uniqueness property.

No component of the Primary Key of a base relation is allowed to accept nulls.

Foreign key

A foreign key is an attribute or attribute combination of one relation R2 whose values are required to match those of the primary key of relation R1 where R1 and R2 are not necessarily distinct. Note that a foreign key and the corresponding primary key should be defined on the same domain(s).

Emp#e1e2e3

enameredbluebrown

Deptd1d2d3

Worksfordeptd1

d2

DnamePayTaxArt

Employee Dept

Foreign key

Mapping an EER Schema to Relations

In a sequence of steps, a set of relations is created. Sometimes automated in CASE tools

1. Regular entity types 2. Weak entity types 3. Binary 1:1 relationship types 4. Binary 1:N relationship types 5. Binary M:N relationship types 6. n-ary relationship types 7. Multi-valued attributes 8. Superclass/subclass relationship types

1. Entity Type Maps to a Table

Create a table for each regular entity type. One column in table for each simple attribute Derived attributes may or may not appear (your choice) Table’s primary key is the primary key of the entity type

Optimization: If there are no attributes other than the primary key, and if the entity participates totally in a relationship, then the table can be eliminated.

2. Weak Entity Type Maps to a Table

Create a table for each weak entity type One column for each simple attribute Include column(s) for the primary key of each owner entity

type. These columns are foreign keys The primary key is the combination of each owner primary

key and the partial key.

3. Mapping 1-1 Relationship Types

For each 1:1 binary relationship type, extend one of the tables for a participating entity type. Primary key of the other entity type becomes a foreign key in

this table

It is best to extend a table of an entity type with total participation

Add columns for each of the simple attributes of the relationship type

Optimization: Perhaps remove the table corresponding to the other entity type

4. 1-to-Many Relationship Types

For each regular 1:N binary relationship type, there are several approaches Option 1: Create a separate table for the relationship type

Three tables resultKey of relationship table is key of “many” side

Option 2: If the relationship is total, then extend a table corresponding to the ‘many’ entity typeTwo tables result (optimization)

Option 3: If the relationship is not total, extend a table with nullable attributes (sometimes not allowed for foreign keys)Two tables result (optimization)

5. Many-to-Many Relationship Types

Create a table for each binary M:N relationship type The table has columns for

A column for each primary key attribute in a participating entity type. These are foreign keys

A column for each of the simple attribute of the relationship type

The primary key of the table is the union of the primary keys of the participating entity types

6. N-ary Relationship Types

Create a table for each n-ary (n > 2) relationship type Columns in the table are the primary keys of the participating

entity types. (These are foreign keys) Also include columns for each simple attribute of the

relationship type

The primary key of the created table is the union of the primary keys of the participating entity types

Optimization: If the relationship type is (1,1) on a side, it may be possible to remove an entity table, placing its attributes in the table associated with the relationship

7. Multivalued Attributes

Create a table for each multivalued attribute The table has a column for each simple attribute of the

multivalued attribute Add columns for the primary key of the entity or relationship

type to which the attribute belongs. (This is a foreign key) The primary key is the combination of all the attributes Example:

Director (FilmID, Name)

Film FilmID

Director

Outline

DDL Creating/altering schema Data types Constraints DataArchitect mapping from a CDM to a PDM Referential integrity and other assertions

Data Definition in SQL

Three statements are used to define the schema in SQL. CREATE DROP ALTER

These statements apply to Tables Views Domains

Create Table

Specifies a new base tableCREATE TABLE <table name> (<column name> <data type>

[<size>] <column constraint>, ... <table constraints> );

Columns with Name Data type Column constraints Default value

Table constraints

Referential Integrity

Referential integrity says “pointed to” information must exist. A foreign key points to data in some relation

Example Customer information must exist for a customer to reserve a film No CustomerID can be in Reserves and not in Customer

Can be specified as a column constraint CREATE TABLE Reserves (...

CustomerID INTEGER CONSTRAINT ReservesToCustomerFK REFERENCES Customer(ID), ...)

Can be specified as a table constraintCREATE TABLE Reserves (..., CONSTRAINT ReservesToCustomerFK FOREIGN KEY (CustomerID) REFERENCES Customer(ID) ... )

Referential Integrity Violation Remedies

Can specify ON UPDATE and ON DELETE options Example

CREATE TABLE Reserves (..., CONSTRAINT ResToCusFK FOREIGN KEY (CustomerID) REFERENCES Customer(ID) ON DELETE CASCADE ON UPDATE SET NULL ... )

Options (next slide) Note: Child table - has the foreign key, references key in parent

table Example: Customer is parent, Reserves is child

Remedy Options

None Update or delete parent value No change to matching child value

Restrict Cannot update or delete parent value if one or more matching

values exist in the child table No change to matching child value

Cascade Update or delete parent value Update or delete matching values in child table

Remedy Options, cont.

Set null Update or delete parent value Set matching values in child table to NULL

Set default Update or delete parent value Set matching values in child table to default value

Retrieval Queries in SQL: SELECT

SQL has one basic statement for retrieving information from a database; the SELECT statement.

The basic form of the SQL SELECT statement is called a mapping or a select-from-where block.

SELECT column listFROM table list

WHERE condition

Outline - The SELECT statement

Single table Projection Selection

Multiple tables Cartesian product and join Set operations Subqueries

Optional clauses Ordering results Computing aggregates on groups

Additional joins

Modifications

There are three modification statements INSERT UPDATE DELETE

For insertions, either values can be specified, or a select statement provides the values

Enter a reservation for Eric for the film 332244

INSERT INTO Reserved

VALUES (123456, 332244, CURRENT_DATE)

View

Views provide a mechanism to create a virtual tableCREATE VIEW name AS query expression

To create a view we use the command Define a view of all customers in Dublin

CREATE VIEW Dublin_Customers ASSELECT *

FROM CustomerWHERE City = ’Dublin’

View, cont.

Define a view of all customers holding reservations, and the films they have reserved

CREATE VIEW Reservations ASSELECT Name, TitleFROM Customer, Reserved, FilmWHERE Customer.CustomerID = Reserved.CustomerID

AND Reserved.FilmID = Film.FilmID

Transactions

A transaction can be defined syntactically: each transaction, irrespective of the language in which it is written, is enclosed whthin two commands

begin transaction

end transaction Within the transaction code, two particular

instructions can appear

commit work

rollback work

Triggers

The creation of triggers is part of the DDL Maintain data integrity Associated with a table (view) Event-condition-action

Wait for a table event

On event, evaluate condition If condition is true, execute action

Xbefore after

insertion deletion update

Potential Applications

Notification an active database may be used to monitor

Enforce integrity constraints Business roles

Maintenance of derived data Maintain the derived attribute whenever individual tuples are

changed

Trigger Gotchas

Potentially infinite loop Trigger A: On insertion into Person, insert into Population Trigger B: On insertion into Population, insert into Person

Mutating tables Trigger A: On insertion into Person, insert into Person! Disallowed! Trigger cannot make changes to table that trigger is defined

on

The Object Database

Object databases integrate database technology with the object-oriented paradigm

In object databases, each entity of the real world is represented by an object. Classical examples of objects are: Electronic components, designed using a Computer Aided

Design (CAD) system; Mechanical components, designed using a Computer Aided

Manufacturing (CAM) system; Specifications and programs, managed in a Computer Aided

Software Engineering (CASE) environment; Multimedia documents, which includes text, images and

sound, managed by multimedia document managers.

Why OODB?

From programming language point of view: permanent storage of objects (languages just support objects

in memory) sharing of objects among programs fast, expressive queries for accessing data version control for evolving classes and multi-person projects

40

Why OODB?

From database point of view: More expressive data types (traditional DBs provide limited predefined types)

e.g., a desktop publishing program might model a page as a series of frames containing text, bitmaps, and charts

need composite and aggregate data types (e.g., structures and arrays) More expressive data relationships

many-to-one relationship (e.g., many students in one class) navigating across relationship links

More expressive data manipulation SQL is relationally complete but not computationally complete i.e., great

for searching for lousy for anything else

– leads to use of conventional programming language plus SQL-interface

– overhead of mapping from SQL to conventional languages Better integration with programming languages (esp. OO languages) Encapsulation of code with data

Two Object-oriented Approaches

Object-oriented (OODBMS) Hellerstein - “to add DBMS capabilities to an O-O language” Persistence, object lives beyond program execution

PJava - persistent JavaSeveral commercial products

Object-relational (ORDBMS) Hellerstein - “extends a relational database with O-O features” Rich data types

InheritanceSeveral commercial vendors, SQL3

OODBMS

Advantages Removes impedance mismatch Long-lived transactions Enriched modeling

Disadvanatages Lack of universal query language Lack of agreed upon standard Performance depends on class definition