Introduction to Database Review 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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,  The EXAMINATION on Tuesday December 15, 2003.

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

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.

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

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

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

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

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

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!

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

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)

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)

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

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)

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

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)

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

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

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.