‭Copyright © 2007 Ramez Elmasri and Shamkant B.

Navathe‬‭Slide 1- 1‬

‭Module 1.1‬
I‭ntroduction: Databases and‬
‭Database Users‬

‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬

‭Outline‬
‭■‬ ‭ ypes of Databases and Database Applications‬
T
‭■‬‭File system drawbacks , comparison with‬

‭DataBase‬
‭■‬‭Basic Definitions‬

‭■‬‭Typical DBMS Functionality‬

‭■‬‭Example of a Database (UNIVERSITY)‬‭■‬‭Main‬

‭Characteristics of the Database Approach‬‭■‬

‭Database Users‬
‭■‬‭Advantages of Using the Database Approach‬

‭■‬‭When to use and Not to Use Databases‬

‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 3‬

‭Types of Databases and Database‬

‭Applications‬
‭■‬ ‭Traditional Applications:‬
‭■‬ ‭Numeric and Textual Databases‬
‭More Recent Applications:‬
‭■‬

‭■‬ ‭ ultimedia Databases‬

M
‭■‬‭ Geographic Information Systems (GIS)‬
‭■‬‭ Data Warehouses‬
‭■‬‭Real-time and Active Databases‬
‭■‬‭
Many other applications‬

‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 4‬

‭Drawbacks of using file systems to store data‬

 ‭/‬‭Purpose of Database Systems‬
‭■‬
‭In the early days, database applications were built‬‭directly on top of‬
‭file systems‬
‭■‬
‭Drawbacks of using file systems to store data:‬
‭●‬
‭Data redundancy and inconsistency‬
‭Multiple file formats, duplication of information‬‭in different files‬
‭●‬
‭Difficulty in accessing data‬
‭Need to write a new program to carry out each new‬
‭●‬
‭task‬ ‭Data isolation — multiple files and formats‬
‭●‬
‭Integrity problems‬
I‭ntegrity constraints (e.g. account balance > 0)‬
‭become “buried” in program code rather than being stated‬
‭explicitly‬
‭Hard to add new constraints or change existing ones‬
 ‭DBMS‬

‭Purpose of Database Systems (Cont.)‬

‭■‬
‭Drawbacks of using file systems (cont.)‬
‭●‬
‭ tomicity of updates‬
A
‭Failures may leave database in an inconsistent state with partial‬
‭updates carried out‬
‭ xample: Transfer of funds from one account to another‬‭should‬
E
‭either complete or not happen at all‬
‭●‬
‭ oncurrent access by multiple users‬
C
‭Concurrent accessed needed for performance‬
‭Uncontrolled concurrent accesses can lead to inconsistencies‬

‭ ‭E
– ‬ xample: Two people reading a balance and updating‬‭it at the same‬
‭time‬
‭●‬
‭ ecurity problems‬
S
‭Hard to provide user access to some, but not all, data‬
 ‭■‬
‭Database systems offer solutions to all the above problems‬‭DB‬

‭Basic Definitions‬
‭■‬ ‭Data:‬
‭■‬‭ Known facts that can be recorded and have an implicit‬‭meaning.‬
‭■‬‭Database:‬

‭■‬‭ A collection of related data.‬

‭■‬‭Mini-world:‬

‭■‬‭Some part of the real world about which data is‬‭stored in a‬

‭database. For example, student grades and transcripts at a‬
‭university.‬
‭■‬‭Database Management System (DBMS):‬

‭■‬‭
A software package/ system to facilitate the creation‬‭and‬
‭maintenance of a computerized database.‬
‭■‬‭Database System:‬
 ‭The DBMS software together with the data itself. Sometimes, the‬
‭■‬

‭applications are also included.‬

‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 7‬

‭Simplified database system‬

‭environment‬
 ‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 8‬

‭Typical DBMS Functionality‬

‭■‬ ‭Define‬‭a particular database in terms of its data types,‬
‭structures, and constraints‬
‭■‬‭Construct‬‭or Load the initial database contents‬‭on a‬

‭secondary storage medium‬

‭■‬‭Manipulating‬‭the database:‬

‭ etrieval: Querying, generating reports‬

R
‭■‬

‭■‬‭
Modification: Insertions, deletions and updates‬‭to its content‬
Accessing the database through Web applications‬‭■‬‭Processing‬
‭■‬‭

‭ nd‬‭Sharing‬‭by a set of concurrent users and application‬

a
‭programs – yet, keeping all data valid and‬ ‭consistent‬

‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 9‬

‭Typical DBMS Functionality‬

‭■‬ ‭Other features:‬
 ‭■‬ ‭Protection or Security measures to prevent‬
‭unauthorized access‬
‭■‬‭ “Active” processing to take internal actions on‬‭data‬
‭■‬‭ Presentation and Visualization of data‬
‭■‬‭Maintaining the database and associated‬
‭programs over the lifetime of the database‬
‭application‬
‭■‬ ‭Called database, software, and system‬
‭maintenance‬

‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 10‬

‭ xample of a Database‬
E
‭(with a Conceptual Data Model)‬
‭■‬‭Mini-world for the example:‬‭■‬‭Part of‬
‭a UNIVERSITY environment.‬‭■‬‭Some‬
‭mini-world‬‭entities‬‭:‬
‭■‬ ‭ TUDENTs‬
S
‭■‬‭ COURSEs‬
‭■‬‭ SECTIONs (of COURSEs)‬
‭■‬‭(academic) DEPARTMENTs‬
‭■‬‭
INSTRUCTORs‬

‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 11‬

‭Example of a Database‬
‭(with a Conceptual Data Model)‬
‭Some mini-world‬‭relationships‬‭:‬
‭■‬

‭■‬ ‭ ECTIONs‬‭are of specific‬‭COURSEs‬

S
‭■‬‭ STUDENTs‬‭take‬‭SECTIONs‬
‭■‬‭ COURSEs‬‭have prerequisite‬‭COURSEs‬
‭■‬‭ INSTRUCTORs‬‭teach‬‭SECTIONs‬
‭■‬‭COURSEs‬‭are offered by‬‭DEPARTMENTs‬
‭■‬‭
STUDENTs‬‭major in‬‭DEPARTMENTs‬

‭Note: The above entities and relationships are typically‬

‭■‬

‭expressed in a conceptual data model, such as the‬

‭ NTITY-RELATIONSHIP data model (see Chapters 3, 4)‬
E

‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 12‬

‭Example of a simple database‬

 ‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 13‬

‭ ain Characteristics of the Database‬

M
‭Approach‬
‭■‬ ‭Self-describing nature of a database‬
‭system:‬
‭■‬ ‭A DBMS‬‭catalog‬‭stores the description‬
‭of a particular database (e.g. data‬
‭structures, types, and constraints)‬
‭■‬‭ The description is called‬‭meta-data‬‭.‬
‭■‬‭This allows the DBMS software to work‬
‭with different database applications.‬
‭Insulation between programs and‬
‭■‬

‭data:‬
‭■‬‭ alled‬‭program-data independence‬‭.‬
C
‭■‬‭
Allows changing data structures and‬
‭storage organization without having to‬
‭change the DBMS access programs.‬
‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 14‬

‭Example of a simplified database‬

‭catalog‬

‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 15‬

 ‭ ain Characteristics of the Database‬
M
‭Approach (continued)‬
‭■‬ ‭Data Abstraction:‬
‭■‬‭A‬‭data model‬‭is used to hide storage details and‬
‭present the users with a conceptual view of the‬
‭database.‬
‭■‬‭Programs refer to the data model constructs rather‬
‭than data storage details‬
‭■‬ ‭Support of multiple views of the data:‬‭■‬
‭ ach user may see a different view of the‬
E
‭database, which describes‬‭only‬‭the data of‬
‭interest to that user.‬

‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 16‬

 ‭ ain Characteristics of the Database‬
M
‭Approach (continued)‬
‭Sharing of data and multi-user transaction‬
‭■‬

‭processing:‬
‭■‬ ‭Allowing a set of‬‭concurrent users‬‭to retrieve from‬‭and to‬
‭update the database.‬
‭■‬‭ Concurrency control‬‭within the DBMS guarantees that‬‭each‬
‭transaction‬‭is correctly executed or aborted‬
‭■‬‭ Recovery‬‭subsystem ensures each completed transaction‬
‭has its effect permanently recorded in the database‬‭■‬‭OLTP‬
‭(Online Transaction Processing) is a major part of database‬
‭applications. This allows hundreds of concurrent‬
‭transactions to execute per second.‬

‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 17‬

‭Database Users‬
‭■‬ ‭Users may be divided into‬
‭■‬‭Those who actually use and control the database‬
‭content, and those who design, develop and‬
‭maintain database applications (called “‬‭Actors on‬
‭the Scene‬‭”), and‬
‭■‬‭Those who design and develop the DBMS‬
‭software and related tools, and the computer‬
‭systems operators (called “‬‭Workers Behind the‬
‭Scene”).‬

‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 18‬

‭Database Users‬
‭■‬ ‭Actors on the scene‬
‭Database administrators:‬
‭■‬

‭■‬ ‭Responsible for authorizing access to the database,‬

‭for coordinating and monitoring its use, acquiring‬
‭software and hardware resources, controlling its use‬
‭and monitoring efficiency of operations.‬
‭Database Designers:‬
‭■‬

‭■‬ ‭Responsible to define the content, the structure,‬‭the‬

‭constraints, and functions or transactions against‬
‭the database. They must communicate with the‬
‭end-users and understand their needs.‬

‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 19‬

‭Categories of End-users‬
‭■‬ ‭Actors on the scene (continued)‬
‭End-users:‬‭They use the data for queries, reports‬
‭■‬

‭and some of them update the database content.‬

‭End-users can be categorized into:‬
‭■‬‭Casual‬‭: access database occasionally when‬
‭needed‬
‭■‬‭Naïve‬‭or Parametric: they make up a large section‬
‭of the end-user population.‬
‭■‬‭They use previously well-defined functions in the‬‭form of‬
‭“canned transactions” against the database.‬
‭■‬‭Examples are bank-tellers or reservation clerks‬‭who do‬
‭this activity for an entire shift of operations.‬

‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 20‬

‭Categories of End-users (continued)‬

 ‭■‬ ‭Sophisticated:‬
‭■‬ ‭ hese include business analysts, scientists, engineers,‬
T
‭others thoroughly familiar with the system capabilities.‬
‭■‬‭
Many use tools in the form of software packages‬‭that work‬
‭closely with the stored database.‬
‭■‬ ‭Stand-alone:‬
‭■‬‭Mostly maintain personal databases using ready-to-use‬
‭packaged applications.‬
‭■‬‭An example is a tax program user that creates its‬‭own‬
‭internal database.‬
‭■‬‭
Another example is a user that maintains an address‬‭book‬

‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 21‬

‭ dvantages of Using the Database‬

A
‭Approach‬
‭■‬ ‭Controlling redundancy in data storage and in‬
‭development and maintenance efforts.‬‭■‬
‭Sharing of data among multiple users.‬
‭ estricting unauthorized access to data.‬‭■‬
R
‭■‬

‭Providing persistent storage for program Objects‬‭■‬

‭In Object-oriented DBMSs – see Chapters 20-22‬‭■‬
‭ roviding Storage Structures (e.g. indexes) for‬
P
‭efficient Query Processing‬

‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 22‬

‭ dvantages of Using the Database‬

A
‭Approach (continued)‬
‭■‬ ‭ roviding backup and recovery services.‬‭■‬
P
‭Providing multiple interfaces to different classes‬
‭of users.‬
‭■‬‭Representing complex relationships among data.‬

‭■‬‭Enforcing integrity constraints on the database.‬‭■‬

‭Drawing inferences and actions from the stored‬

‭data using deductive and active rules‬

‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 23‬

‭ dditional Implications of Using the‬

A
‭Database Approach‬
‭■‬ ‭Potential for enforcing standards:‬
‭This is very crucial for the success of database‬
‭■‬

‭applications in large organizations.‬‭Standards‬

‭refer to data item names, display formats, screens,‬
‭report structures, meta-data (description of data),‬
‭Web page layouts, etc.‬
‭■‬ ‭Reduced application development time:‬‭■‬
I‭ncremental time to add each new application is‬
‭reduced.‬

‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 24‬

‭ dditional Implications of Using the‬

A
‭Database Approach (continued)‬
‭■‬ ‭Flexibility to change data structures:‬
‭Database structure may evolve as new‬
‭■‬

‭requirements are defined.‬

‭■‬ ‭Availability of current information:‬
‭ xtremely important for on-line transaction‬
E ‭■‬

‭systems such as airline, hotel, car reservations.‬‭■‬

‭Economies of scale:‬
‭Wasteful overlap of resources and personnel can‬
‭■‬

‭be avoided by consolidating data and applications‬

‭across departments.‬

‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 25‬

‭ istorical Development of Database‬

H
‭Technology‬
 ‭Early Database Applications:‬
‭■‬

‭The Hierarchical and Network Models were introduced‬‭in‬

‭■‬

‭mid 1960s and dominated during the seventies.‬

‭■‬‭A bulk of the worldwide database processing still‬‭occurs‬
‭using these models, particularly, the hierarchical model.‬‭■‬
‭Relational Model based Systems:‬
‭■‬‭Relational model was originally introduced in 1970,‬‭was‬
‭heavily researched and experimented within IBM Research‬
‭and several universities.‬
‭■‬‭Relational DBMS Products emerged in the early 1980s.‬

‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 26‬

‭ istorical Development of Database‬

H
‭Technology (continued)‬
 ‭Object-oriented and emerging applications:‬
‭■‬

‭■‬ ‭Object-Oriented Database Management Systems‬

‭(OODBMSs) were introduced in late 1980s and early 1990s‬
‭to cater to the need of complex data processing in CAD and‬
‭other applications.‬
‭Their use has not taken off much.‬
‭■‬

‭■‬‭Many‬ ‭relational‬ ‭DBMSs‬ ‭have‬ ‭incorporated‬ ‭object‬ ‭database‬

‭concepts,‬‭leading‬‭to‬‭a‬‭new‬‭category‬‭called‬‭object-relationa‬‭l‬
‭DBMSs (ORDBMSs)‬
‭■‬‭
Extended relational‬‭systems add further capabilities‬‭(e.g. for‬
‭multimedia data, XML, and other data types)‬

‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 27‬

‭ istorical Development of Database‬

H
‭Technology (continued)‬
‭■‬ ‭Data on the Web and E-commerce Applications:‬
‭■‬ ‭ eb contains data in HTML (Hypertext markup‬
W
‭language) with links among pages.‬
‭■‬‭This has given rise to a new set of applications‬
‭and E-commerce is using new standards like XML‬
‭(eXtended Markup Language). (see Ch. 27).‬
‭■‬‭
Script programming languages such as PHP and‬
‭JavaScript allow generation of dynamic Web‬
‭pages that are partially generated from a database‬
‭(see Ch. 26).‬
‭Also allow database updates through Web pages‬
‭■‬

‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 28‬

‭Extending Database Capabilities‬

‭■‬ ‭New functionality is being added to DBMSs in the following areas:‬‭■‬
‭Scientific Applications‬
‭■‬‭ XML (eXtensible Markup Language)‬
‭■‬‭ Image Storage and Management‬
‭■‬‭ Audio and Video Data Management‬
‭■‬‭ Data Warehousing and Data Mining‬
‭■‬‭Spatial Data Management‬
‭■‬‭
Time Series and Historical Data Management‬

‭■‬ ‭The above gives rise to‬‭new research and development‬‭in‬

‭incorporating new data types, complex data structures, new‬
‭operations and storage and indexing schemes in database systems.‬

‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 29‬

‭When not to use a DBMS‬

‭■‬ ‭Main inhibitors (costs) of using a DBMS:‬
‭■‬‭High initial investment and possible need for additional‬
‭hardware.‬
‭■‬‭Overhead for providing generality, security, concurrency‬
‭control, recovery, and integrity functions.‬
‭When a DBMS may be unnecessary:‬
‭■‬

‭■‬ ‭If the database and applications are simple, well‬‭defined,‬

‭and not expected to change.‬
‭■‬‭ If there are stringent real-time requirements that‬‭may not be‬
‭met because of DBMS overhead.‬
‭■‬‭If access to data by multiple users is not required.‬

‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 30‬

‭When not to use a DBMS‬

‭■‬ ‭When no DBMS may suffice:‬
‭■‬ I‭f the database system is not able to handle the‬
‭complexity of data because of modeling limitations‬‭■‬
‭If the database users need special operations not‬
‭supported by the DBMS.‬

‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 31‬

‭Summary‬
‭■‬ ‭ ypes of Databases and Database Applications‬
T
‭■‬‭Basic Definitions‬

‭■‬‭Typical DBMS Functionality‬

‭■‬‭Example of a Database (UNIVERSITY)‬‭■‬‭Main‬

‭Characteristics of the Database Approach‬‭■‬

‭Database Users‬
‭■‬‭Advantages of Using the Database Approach‬

‭■‬‭When Not to Use Databases‬

‭Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe‬‭Slide 1- 32‬