Introduction to Database Review 2. Crows-Feet Notation for ER Diagrams This is an alternative to...
-
date post
21-Dec-2015 -
Category
Documents
-
view
220 -
download
2
Transcript of Introduction to Database Review 2. Crows-Feet Notation for ER Diagrams This is an alternative to...
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