1. Introduction to Database Review 2

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 3 Entity 2 Zero or one One or moreZero or more Exactly one (mandatory)

3. 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).

4. Subclasses/Superclasses Example  The Customer entity type has the subclasses PreferredCustomer and Employee.  All employees are customers. Customer O Employee Preferred Customer

5. 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. 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 Employee Preferred Customer CustomerID Address Name Balance EmployeeIDDiscount Level

7. 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.

8. Top-down Strategy Customer Checked Out VideoTape Title RentalPrice (0,m) Length CustomerID Name (0,n) Customer Checked Out VideoTape Film Copies TapeNum Title RentalPrice (0,m) (0,n) (1,1) (0,n) FilmID Status Length CustomerID Name

9. Bottom-up Strategy  Example: discovering a new generalized entity type and relating it. Customer Cust Checked Out VideoTape Title RentalPrice (0,m) Length CustomerID Name Emp Checked Out Employee Name EmployeeID Length (0,m) (0,n)

10. Bottom-up Strategy, cont.  This is converted to: Customer Checked Out VideoTape Title RentalPrice (0,m) Length CustomerID Name (0,n) EmployeeID O Employee Preferred Customer

11. 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.

12. 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.

13. 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# e1 e2 e3 ename red blue brown Dept d1 d2 d3 Worksfordept d1 d2 Dname Pay Tax Art Employee Dept Foreign key

14. 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

15. 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.

16. 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.

17. 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

18. 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 result Key of relationship table is key of “many” side  Option 2: If the relationship is total, then extend a table corresponding to the ‘many’ entity type Two 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)

19. 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

20. 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

21. 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

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

23. Data Definition in SQL  Three statements are used to define the schema in SQL.  CREATE  DROP  ALTER  These statements apply to  Tables  Views  Domains

24. Create Table  Specifies a new base table CREATE TABLE ( [ ],... );  Columns with  Name  Data type  Column constraints  Default value  Table constraints

25. 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 constraint CREATE TABLE Reserves (..., CONSTRAINT ReservesToCustomerFK FOREIGN KEY (CustomerID) REFERENCES Customer(ID)... )

26. 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

27. 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

28. 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

29. 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 list FROMtable list WHEREcondition

30. 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

31. 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)

32. View  Views provide a mechanism to create a virtual table CREATE 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 AS SELECT * FROM Customer WHERE City = ’Dublin’

33. View, cont.  Define a view of all customers holding reservations, and the films they have reserved CREATE VIEW Reservations AS SELECT Name, Title FROM Customer, Reserved, Film WHERE Customer.CustomerID = Reserved.CustomerID AND Reserved.FilmID = Film.FilmID

34. 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

35. 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 X before after insertion deletion update

36. 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

37. 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

38. 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.

39. 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. 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

41. 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 Java Several commercial products  Object-relational (ORDBMS)  Hellerstein - “extends a relational database with O-O features”  Rich data types Inheritance Several commercial vendors, SQL3

42. 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