1. Introduction to Database Review 1

2. What is a database  Basic Definitions  Database Management System (DBMS): A software package to facilitate the process of  Defining - specifying types, organization (schema)  Constructing - loading the data  Manipulating - querying the data  One DBMS, many DBs, many applications  Database system: A database and a DBMS

3. What is a database  Pictorial Representation Users/Programs Application Programs/Queries Software to Process Queries/Programs Software to Access Stored Data DATABASE SYSTEM DBMS SOFTWARE Stored Database Definition (Meta-Data) Stored Database

4. What is a database  Functions of a DBMS  Provides persistent, shared storage  Objects live beyond program execution  Shared by multiple applications  DBMS reduces redundancy in Development and maintenance  Provides multiple interfaces  Query language, embedded query language, APIs, GUIs  Protects against  Software/hardware failure  Security breaches

5. Classes of DB Users – Workers On the Scene  Persons whose job involves daily use of a large database  Database administrators (DBAs)  Database designers  End users  Application programmers

6. Data Models  A data model is a data definition language along with a data manipulation language  Conceptual  Representational  Physical

7. Data Models  A data definition language (DDL) describes database schemas  Data relationships  Data semantics  Integrity constraints  Database schemas vs. instances  Similar to types and variables in programming languages  A data manipulation language (DML) is used for querying and updating database instances

8. Schema vs. Instance  Schema - Description of how data is organized and constrained  Instance - The data in a database (conforms to a schema)  Snapshot - Database state at a particular point in time  Initially empty  Database is populated or loaded DBMS ensures every state is a valid state  Schema evolution vs. data update

9. ANSI Three-Schema Architecture  Defines DBMS schemas at three levels:  Physical How data is stored on disk Data storage structures Access paths to the data  Logical How we think the data is organised Conceptual structure Integrity constraints  External What a user sees of the data View is often limited by security

10. Data Independence  Each level is “independent” in the sense that a completely different organization can be used  Physical data independence - Physical level can change without having to change the logical level  Logical data independence - Logical level can change without having to change the external level

11. Lifecycle of an Information System 1.Feasibility analysis 2.Requirements formulation 3.System design 4.Database design 5.Implementation 6.Validation and acceptance testing 7.Loading/data conversion 8.Operation.Conversion Training.Monitoring and tuning.New requirements

12. Lifecycle of an Information System Development Methodology using a DBMS cost/benefit analysis  feasibility analysis  load data  test and evaluate  formulate reqs. ER model requirements analysis phasedatabase design phaseimplementation phase  system design  database design  physical database design  implement tables, indexes, and storage types plan for information system requirements  specify reqs.  conceptual database design  transaction design  chose DBMS  logical database design  operation

13. Lifecycle of an Information System  Successful design depends on an iterative approach, starting at an abstract level and adding detail  Appropriate data models at each level focus on the important aspects  The end result is a fully elaborated design, with each major design decision well documented  Modification should proceed from the appropriate level downward

14. Entity-Relationship Model  This model is used in conceptual design  Popular in CASE tools, e.g., ERWin, DataArchitect  A database can be modelled as  a collection of entity types, and  relationships among entity types  Result is an ER Schema or an ER Diagram

15. Entity Definition: An entity is an object that exists and is distinguishable from other objects.  Object, exists, distinguishable  Video store mini-world example  Physically exist The CUSTOMER Jane Doe. The Xtra-vision STORE. The EMPLOYEE Juan Gonzales.

16. Entity, cont.  Abstract or organisational entities that do not exist physically  The Introduction to Databases COURSE.  The SCHOOL of Electrical Engineering and Computer Science.  Events  The TUTORIAL on Friday, October 31, 2003.  The EXAMINATION on Tuesday December 15, 2003.

17. Attribute Definition: An attribute is a property of an entity.  Feature example: CUSTOMER Name Date of Birth (DOB) example: VIDEO TAPE Copy number Title  CUSTOMER entity examples Name=Jane, DOB=1/1/70 Name=Joe, DOB=5/6/75

18. 18 Distinguishing Entities  How can entities be distinguished from each other?  Assumption: Each entity will have a unique combination of attribute values.  Example, assume the Customer entity type has Name and DOB attributes. There may be several Customers with a Name of ‘Joe’. Also, there may be several Customers with a DOB of 5/6/75. But there can be at most one Customer with the Name ‘Joe’ and a DOB of 5/6/75.  Is there a smaller such set of attributes? Name=Joe, DOB=10/7/49 CUSTOMER entities Name=Fred, DOB=5/6/75 Name=Joe, DOB=5/6/75

19. Keys Definition: A super key of an entity type is a set of one or more attributes whose values uniquely determine each entity.  Assume each Customer has a unique ID. The following are super keys. {Name, DOB, ID}, {Name, ID}, {Name, DOB}, {DOB, ID}, {ID} Definition: A candidate key is a minimal super key.  {Name, DOB} is a candidate key of Customer.  {ID} is a candidate key of Customer. Definition: Generally, there are may be several candidate keys. One of the keys is selected to be the primary key.  {ID} is the primary key of Customer.

20. ER Diagram - Diamond Notation  An entity type is represented with a labelled rectangle.  An attribute is represented with a labelled oval, connected to an entity type with a line. Customer Name DOB

21. Attributes - Diamond Notation  Single valued versus multi-valued  E.g., multiple telephone extensions  Simple attributes versus structured attributes  E.g., an address is composed of a number, a street, a city and a state CustomerExtension Address Street City State Customer

22. Attributes, cont.  Stored versus derived  E.g., an age can be derived from a stored birthdate  Additional constraints - not represented in a diagram  Null versus non-null  Domain constrained E.g., a student number must be exactly 9 decimal digits Customer DOB Age

23. Keys in ER Diagrams  An attribute that is part of the (primary) key is underlined.  E.g., ID uniquely identifies customers  Assume no two customers with the same name live at the same address. Customer Name Address ID Customer Name Address ID

24. Relationship Definition: A relationship is an object that associates entities. Joe Jenkins Jane Doe Finding Nemo copy 1 Babe copy 3 Customer entities Video Tape entities relationship objects

25. 25 Relationship Types - Diamond Notation  A relationship type is represented with a labelled diamond, and has lines to each of the entity types it relates.  The relationship type could have attributes.  A relationship type does not have key attribute(s) – the key comes from entity types that it relates. Customer Rents Video Tape Name Customer ID Return Date Location Address

26. Kinds of Relationship Types  How many of each entity type participate in a relationship type?  1-1  1-many  many-1  many-many  Total vs. Partial participation  Total participation means that every entity participates in the relationship.  Partial means that some entities might not participate.  Bounds (min-max) on participation  (At least) three different “diamond” notations  Arrow vs. straight line with or without participation bounds  DO NOT MIX NOTATIONS!

27. An Example One-to-One Relationship Type  A Customer might be an Employee.  An Employee IsA Customer.  Participation is total on the Employee side in this example. CustomerIsAEmployee

28. Diagramming One-To-One Rel. Types  An element in A is associated with at most one element in C via the relationship B. An element in C is associated with at most one element in A via B. A B C A B C A B C 11 (0,1)

29. Total vs. Partial Participation  Use a double line to indicate total participation.  Example: Every A is in a B relationship with exactly one C, but some C’s may be unrelated to an A.  Using participation constraints, total participation is a 1 on the minimum bound. A B C 11 A B C (1,1)(0,1)

30. An Example One-to-Many Relationship Type  A Customer Rents zero to several Video Tapes.  A Video Tape can be Rented by at most one Customer.  Participation is partial on both sides in this example. CustomerRentsVideo Tape

31. One-To-Many Relationship  An element in A is associated with several (including 0) elements in C via B. An element in C is associated with at most one element in A via B. A B C A B C A B C 1m (0,m)(0,1)

32. An Example Many-to-Many Rel. Type  A Performer Stars In one or many Films.  A Film can Star zero to many Performers.  Participation is total on the Performer in this example. PerformerStars InFilm

33. Many-To-Many Relationship  An element in A is associated with several elements in C via B.  An element in C is associated with several elements in A via B. A B C A B C A B C nm (0,m)(0,n)

34. Weak Entity Types  Definition: A weak entity type borrows key attributes from another entity type (called the owning or strong entity type) to uniquely identify entities.  Example: A Video Tape has a Copy #, relative to a Film title (e.g., `Babe copy 1’, `Babe copy 2’, `Finding Nemo copy 1’. Copy # is not a key, but combined with Title it is (for Video Tape).  ER diagram - double box represents weak entity type.  The existence of a Video Tape entity depends on the existence of a Film entity. FilmVideoTape (0,n)(1,1) Copies Status Copy # Title

35. Weak Entity Type – Partial Keys  A weak entity type has a partial key (key is completed by borrowing key attributes from owning entity type(s)).  Example: Key for Video Tape is (Title, Copy#).  ER diagram - partial key represented with dashed line. FilmVideoTape (0,n)(1,1) Copies Status Copy # Title

36. Weak Entity Type, cont.  Semantics:  Deletion of a Film entity requires deletion of that film's video tape entities.  A weak entity is related to precisely one entity in the owning entity type, via a 1-1 or 1-many relationship.  It is possible to introduce more attributes to the video tape entity type, so that a primary key will exist, but they may not be needed for database processing.