01

Introduction to Database - Database

Architectures
 FIT

Outline
• Data Models
• Schemas, Instances, and States
• Basic Definitions & Typical DBMS Functionality
• Database and Database Users
• Schemas, Instances, and States
• Three-Schema Architecture
• Data Independence
• Centralized and Client-Server Architectures
• Three-tier client-server architecture

• Ref: Chapter 1-2

2 Design and Manage Database

 FIT

Types of Databases and Database Applications

• Traditional Applications:
• Numeric and Textual Databases
• More Recent Applications:
• Multimedia Databases
• Geographic Information Systems (GIS)
• Biological and Genome Databases
• Data Warehouses
• Mobile databases
• Real-time and Active Databases

3 Design and Manage Database

 FIT

Recent Developments
• Social Networks started capturing a lot of information about people and
about communications among people-posts, tweets, photos, videos in
systems such as:
• Facebook
• Twitter
• Linked-In
• All of the above constitutes data
• Search Engines (Google, Bing, Yahoo, …): collect their own repository of
web pages for searching purposes

4 Design and Manage Database

 FIT

• New Technologies are emerging from the so-called non-database

software vendors to manage vast amounts of data generated on the web:
• Big Data storage systems involving large clusters of distributed
computers
• NOSQL (Non-SQL, Not Only SQL) systems
• A large amount of data now resides on the “cloud” which means it is in
huge data centers using thousands of machines.

5 Design and Manage Database

 FIT

Basic Definitions
• Database:
• A collection of related data.
• Data:
• Known facts that can be recorded and have an implicit meaning.
• 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.

6 Design and Manage Database

 FIT

Impact of Databases and Database Technology

• Businesses: Banking, Insurance, Retail, Transportation, Healthcare,
Manufacturing
• Service industries: Financial, Real-estate, Legal, Electronic Commerce,
Small businesses
• Education : Resources for content and Delivery
• More recently: Social Networks, Environmental and Scientific Applications,
Medicine and Genetics
• Personalized applications: based on smart mobile devices

7 Design and Manage Database

 FIT

• Simplified database
system environment

8 Design and Manage Database

 FIT

What a DBMS Facilitates

• 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:
• Retrieval: Querying, generating reports
• Modification: Insertions, deletions and updates to its content
• Accessing the database through Web applications
• Processing and sharing by a set of concurrent users and application
programs – yet, keeping all data valid and consistent

9 Design and Manage Database

 FIT

Other DBMS Functionalities

• DBMS may additionally provide:
• Protection or Security measures to prevent unauthorized access
• “Active” processing to take internal actions on data
• Presentation and visualization of data
• Maintenance of the database and associated programs over the lifetime of
the database application

10 Design and Manage Database

 FIT

Application Programs and DBMS

• Applications interact with a database by generating
• Queries: that access different parts of data and formulate the result of a
request
• Transactions: that may read some data and “update” certain values or
generate new data and store that in the database

11 Design and Manage Database

 FIT

Example of a Database (with a Conceptual Data Model)

• Mini-world for the example:
• Part of a UNIVERSITY environment
• Some mini-world entities:
• STUDENTs
• COURSEs
• SECTIONs (of COURSEs)
• (Academic) DEPARTMENTs
• INSTRUCTORs

12 Design and Manage Database

 FIT

• Some mini-world relationships:

• SECTIONs are of specific COURSEs
• STUDENTs take SECTIONs
• COURSEs have prerequisite COURSEs
• INSTRUCTORs teach SECTIONs
• COURSEs are offered by DEPARTMENTs
• STUDENTs major in DEPARTMENTs

13 Design and Manage Database

 FIT

Main Characteristics of the Database 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:
• Called program-data independence.
• Allows changing data structures and storage organization without having to
change the DBMS access programs
• E.g., abstract data types

14 Design and Manage Database

 FIT

• Example of a Simplified Database Catalog

15 Design and Manage Database

 FIT

• 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:
• Each user may see a different view of the database, which describes only the
data of interest to that user.

16 Design and Manage Database

 FIT

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

17 Design and Manage Database

 FIT

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

18 Design and Manage Database

 FIT

Database Users – Actors on the Scene

• Database administrators
• Database designers
• End-users:
• Casual
• Naïve or Parametric
• Sophisticated
• Stand-alone
• System Analysts and Application Developers
• System Analysts
• Application Programmers
• Business Analysts
• System Designers and Implementors
• Tool Developers
• Operators and Maintenance Personnel

19 Design and Manage Database

 FIT

Additional Implications of Using the 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:
• Incremental time to add each new application is reduced.

20 Design and Manage Database

 FIT

• Flexibility to change data structures:

• Database structure may evolve as new requirements are defined.
• Availability of current information:
• Extremely important for on-line transaction systems such as shopping,
airline, hotel, car reservations.
• Economies of scale:
• Wasteful overlap of resources and personnel can be avoided by consolidating
data and applications across departments.

21 Design and Manage Database

 FIT

Historical Development of Database 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 using IBM’s IMS system.
• 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.

22 Design and Manage Database

 FIT

• 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-relational DBMSs (ORDBMSs)
• Extended relational systems add further capabilities (e.g. for multimedia data,
text, XML, and other data types)

23 Design and Manage Database

 FIT

• Data on the Web and E-commerce Applications:

• Web contains data in HTML (Hypertext markup 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).
• Script programming languages such as PHP and JavaScript allow generation
of dynamic Web pages that are partially generated from a database
• Also allow database updates through Web pages

24 Design and Manage Database

 FIT

Extending Database Capabilities

• New functionality is being added to DBMSs in the following areas:
• Scientific Applications – Physics, Chemistry, Biology - Genetics
• Spatial: weather, earth and atmospheric sciences and astronomy
• XML (eXtensible Markup Language)
• Image storage and management
• Audio and video 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.

25 Design and Manage Database

 FIT

• Background since the advent of the 21st Century:

• First decade of the 21st century has seen tremendous growth in user
generated data and automatically collected data from applications and
search engines.
• Social Media platforms such as Facebook and Twitter are generating millions
of transactions a day and businesses are interested to tap into this data to
“understand” the users
• Cloud Storage and Backup is making unlimited amount of storage available
to users and applications

26 Design and Manage Database

 FIT

• Emergence of Big Data Technologies and NOSQL databases

• New data storage, management and analysis technology was necessary to deal with
the onslaught of data in petabytes a day (10**15 bytes or 1000 terabytes) in some
applications – this started being commonly called as “Big Data”.
• Hadoop (which originated from Yahoo) and Mapreduce Programming approach to
distributed data processing (which originated from Google) as well as the Google file
system have given rise to Big Data technologies. Further enhancements are taking
place in the form of Spark based technology.
• NOSQL (Not Only SQL- where SQL is the de facto standard language for relational
DBMSs) systems have been designed for rapid search and retrieval from documents,
processing of huge graphs occurring on social networks, and other forms of
unstructured data with flexible models of transaction processing

27 Design and Manage Database

 FIT

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 access to data by multiple users is not required
• When a DBMS may be infeasible
• In embedded systems where a general purpose DBMS may not fit in available
storage

28 Design and Manage Database

 FIT

• When no DBMS may suffice:

• If there are stringent real-time requirements that may not be met because of
DBMS overhead (e.g., telephone switching systems)
• If the database system is not able to handle the complexity of data because
of modeling limitations (e.g., in complex genome and protein databases)
• If the database users need special operations not supported by the DBMS
(e.g., GIS and location based services).

29 Design and Manage Database

 FIT

Data Models
• Data Model:
• A set of concepts to describe the structure of a database, the operations for
manipulating these structures, and certain constraints that the database
should obey.
• Data Model Structure and Constraints:
• Constructs are used to define the database structure
• Constructs typically include elements (and their data types) as well as groups
of elements (e.g. entity, record, table), and relationships among such groups
• Constraints specify some restrictions on valid data; these constraints must be
enforced at all times

30 Design and Manage Database

 FIT

• Data Model Operations:

• These operations are used for specifying database retrievals and updates by
referring to the constructs of the data model.
• Operations on the data model may include basic model operations (e.g.
generic insert, delete, update) and user-defined operations (e.g.
compute_student_gpa, update_inventory)

31 Design and Manage Database

 FIT

Categories of Data Models

• Conceptual (high-level, semantic) data models:
• Provide concepts that are close to the way many users perceive data.
• (Also called entity-based or object-based data models.)
• Physical (low-level, internal) data models:
• Provide concepts that describe details of how data is stored in the computer. These
are usually specified in an ad-hoc manner through DBMS design and administration
manuals
• Implementation (representational) data models:
• Provide concepts that fall between the above two, used by many commercial DBMS
implementations (e.g. relational data models used in many commercial systems).
• Self-Describing Data Models:
• Combine the description of data with the data values. Examples include XML, key-
value stores and some NOSQL systems.

32 Design and Manage Database

 FIT

Schemas versus Instances

• Database Schema:
• The description of a database.
• Includes descriptions of the database structure, data types, and the
constraints on the database.
• Schema Diagram:
• An illustrative display of (most aspects of) a database schema.
• Schema Construct:
• A component of the schema or an object within the schema, e.g., STUDENT,
COURSE.

33 Design and Manage Database

 FIT

• Database State:
• The actual data stored in a database at a particular moment in time. This
includes the collection of all the data in the database.
• Also called database instance (or occurrence or snapshot).
• The term instance is also applied to individual database components, e.g. record
instance, table instance, entity instance

34 Design and Manage Database

 FIT

Database Schema vs. Database State

• Database State:
• Refers to the content of a database at a moment in time.
• Initial Database State:
• Refers to the database state when it is initially loaded into the system.
• Valid State:
• A state that satisfies the structure and constraints of the database.
• Distinction
• The database schema changes very infrequently.
• The database state changes every time the database is updated.

• Schema is also called intension.

• State is also called extension.

35 Design and Manage Database

 FIT

• Example of a Database Schema

36 Design and Manage Database

 FIT

• Example of a database state

37 Design and Manage Database

 FIT

Three-Schema Architecture
• Proposed to support DBMS characteristics of:
• Program-data independence.
• Support of multiple views of the data.
• Defines DBMS schemas at three levels:
• Internal schema at the internal level to describe physical storage structures and
access paths (e.g indexes).
• Typically uses a physical data model.
• Conceptual schema at the conceptual level to describe the structure and constraints
for the whole database for a community of users.
• Uses a conceptual or an implementation data model.
• External schemas at the external level to describe the various user views.
• Usually uses the same data model as the conceptual schema.

38 Design and Manage Database

 FIT

39 Design and Manage Database

 FIT

Data Independence
• Logical Data Independence:
• The capacity to change the conceptual schema without having to change the external
schemas and their associated application programs.
• Physical Data Independence:
• The capacity to change the internal schema without having to change the conceptual
schema.
• For example, the internal schema may be changed when certain file structures are
reorganized or new indexes are created to improve database performance
• When a schema at a lower level is changed, only the mappings between this schema and
higher-level schemas need to be changed in a DBMS that fully supports data
independence.
• The higher-level schemas themselves are unchanged.
• Hence, the application programs need not be changed since they refer to the external
schemas.

40 Design and Manage Database

 FIT

DBMS Languages
• Data Definition Language (DDL):
• Used by the DBA and database designers to specify the conceptual schema
of a database.
• In many DBMSs, the DDL is also used to define internal and external schemas
(views).
• In some DBMSs, separate storage definition language (SDL) and view
definition language (VDL) are used to define internal and external schemas.
• SDL is typically realized via DBMS commands provided to the DBA and database
designers

41 Design and Manage Database

 FIT

• Data Manipulation Language (DML):

• Used to specify database retrievals and updates
• DML commands (data sublanguage) can be embedded in a general-purpose
programming language (host language), such as COBOL, C,
C++, or Java.
• A library of functions can also be provided to access the DBMS from a
programming language
• Alternatively, stand-alone DML commands can be applied directly (called a
query language).

42 Design and Manage Database

 FIT

Types of DML
• High Level or Non-procedural Language:
• For example, the SQL relational language
• Are “set”-oriented and specify what data to retrieve rather than how to
retrieve it.
• Also called declarative languages.
• Low Level or Procedural Language:
• Retrieve data one record-at-a-time;
• Constructs such as looping are needed to retrieve multiple records, along
with positioning pointers.

43 Design and Manage Database

 FIT

DBMS Interfaces
• Stand-alone query language interfaces
• Example: Entering SQL queries at the DBMS interactive SQL interface (e.g.
SQL*Plus in ORACLE)
• Programmer interfaces for embedding DML in programming languages
• User-friendly interfaces
• Menu-based, forms-based, graphics-based, etc.
• Mobile Interfaces: interfaces allowing users to perform transactions using
mobile apps

44 Design and Manage Database

 FIT

DBMS Programming Language Interfaces

• Programmer interfaces for embedding DML in a programming languages:
• Embedded Approach: e.g embedded SQL (for C, C++, etc.), SQLJ (for Java)
• Procedure Call Approach: e.g. JDBC for Java, ODBC (Open Database Connectivity) for
other programming languages as API’s (application programming interfaces)
• Database Programming Language Approach: e.g. ORACLE has PL/SQL, a
programming language based on SQL; language incorporates SQL and its data types
as integral components
• Scripting Languages: PHP (client-side scripting) and Python (server-side scripting)
are used to write database programs.

45 Design and Manage Database

 FIT

User-Friendly DBMS Interfaces

• Menu-based (Web-based), popular for browsing on the web
• Forms-based, designed for naïve users used to filling in entries on a form
• Graphics-based
• Point and Click, Drag and Drop, etc.
• Specifying a query on a schema diagram
• Natural language: requests in written English
• Combinations of the above:
• For example, both menus and forms used extensively in Web database
interfaces

46 Design and Manage Database

 FIT

Other DBMS Interfaces

• Natural language: free text as a query
• Speech : Input query and Output response
• Web Browser with keyword search
• Parametric interfaces, e.g., bank tellers using function keys.
• Interfaces for the DBA:
• Creating user accounts, granting authorizations
• Setting system parameters
• Changing schemas or access paths

47 Design and Manage Database

 FIT

Database System Utilities

• To perform certain functions such as:
• Loading data stored in files into a database. Includes data conversion tools.
• Backing up the database periodically on tape.
• Reorganizing database file structures.
• Performance monitoring utilities.
• Report generation utilities.
• Other functions, such as sorting, user monitoring, data compression, etc.

48 Design and Manage Database

 FIT

• Typical DBMS Component Modules

49 Design and Manage Database

 FIT

• Centralized and
Client-Server DBMS Architectures

50 Design and Manage Database

 FIT

• Three Tier Client-Server Architecture

51 Design and Manage Database

 FIT

Classification of DBMSs
• Based on the data model used
• Legacy: Network, Hierarchical.
• Currently Used: Relational, Object-oriented, Object-relational
• Recent Technologies: Key-value storage systems, NOSQL systems: document
based, column-based, graph-based and key-value based. Native XML DBMSs.
• Other classifications
• Single-user (typically used with personal computers)
vs. multi-user (most DBMSs).
• Centralized (uses a single computer with one database) vs. distributed
(multiple computers, multiple DBs)

52 Design and Manage Database

 FIT

Variations of Distributed DBMSs (DDBMSs)

• Homogeneous DDBMS
• Heterogeneous DDBMS
• Federated or Multidatabase Systems
• Participating Databases are loosely coupled with high degree of autonomy.
• Distributed Database Systems have now come to be known as client-
server based database systems because:
• They do not support a totally distributed environment, but rather a set of
database servers supporting a set of clients.

53 Design and Manage Database

 FIT

Cost considerations for DBMSs

• Cost Range: from free open-source systems to configurations costing
millions of dollars
• Examples of free relational DBMSs: MySQL, PostgreSQL, others
• Commercial DBMS offer additional specialized modules, e.g. time-series
module, spatial data module, document module, XML module
• These offer additional specialized functionality when purchased separately
• Sometimes called cartridges (e.g., in Oracle) or blades
• Different licensing options: site license, maximum number of concurrent
users (seat license), single user, etc.

54 Design and Manage Database

 FIT

History of Data Models (Additional Material)

• Network Model
• Hierarchical Model
• Relational Model
• Object-oriented Data Models
• Object-Relational Models

55 Design and Manage Database

 FIT

56 Design and Manage Database