0% found this document useful (0 votes)
7 views

Database System Concepts and Architecture

The document discusses data models, schemas, and database instances. It describes high-level and low-level data models, as well as schemas, instances, and the three-schema architecture. The three-schema architecture separates user applications from the physical database through conceptual and internal schemas.

Uploaded by

Utkarsh Khaire
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
7 views

Database System Concepts and Architecture

The document discusses data models, schemas, and database instances. It describes high-level and low-level data models, as well as schemas, instances, and the three-schema architecture. The three-schema architecture separates user applications from the physical database through conceptual and internal schemas.

Uploaded by

Utkarsh Khaire
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 8

Data Models, Schemas, and Instances

Thursday, January 11, 2024 8:39 AM

• A Data model
○ A collection of concepts that can be used to describe the structure of a database (data
types, relationships, and constraints that apply to the data).
○ Provides the necessary means to achieve data abstraction.

• Categories of Data Models


○ High-level or conceptual data models
▪ Use concepts such as entities, attributes, and relationships.
▪ An entity represents a real-world object or concept, such as an employee or a project
from the miniworld that is described in the database.
▪ An attribute represents some property of interest that further describes an entity,
such as the employee’s name or salary.
▪ A relationship among two or more entities represents an association among the
entities, for example, a works-on relationship between an employee and a project.
○ Low-level or physical data models
▪ Describe how data is stored as files in the computer by representing information such
as record formats, record orderings, and access paths.
▪ An access path is a structure that makes the search for particular database records
efficient.
▪ An index is an example of an access path that allows direct access to data using an
index term or a keyword.
○ Representational (or implementation) data models
▪ Provide concepts that may be easily understood by end users but that are not too far
removed from the way data is organized in computer storage
▪ Most frequently used in traditional commercial DBMSs
▪ Represent data by using record structures and hence are sometimes called record-
based data models.

• Schemas, Instances, and Database State


○ The description of a database is called the database schema, which is specified during
database design and is not expected to change frequently.
○ A displayed schema is called a schema diagram.

Database System Concepts and Architecture Page 1


○ STUDENT or COURSE—a schema construct.


○ Data type of each data item, relationships among the various files, and many types of
constraints are not represented in schema.
▪ Ex. students majoring in computer science must take CS1310 before the end of their
sophomore year
○ The data in the database at a particular moment in time is called a database state or
snapshot. It is also called the current set of occurrences or instances in the database.
○ When we define a new database, we specify its database schema only to the DBMS.
▪ At this point, the corresponding database state is the empty state with no data.
▪ We get the initial state of the database when the database is first populated or loaded
with the initial data.
▪ From then on, every time an update operation is applied to the database, we get
another database state.
▪ At any point in time, the database has a current state
○ Valid state: a state that satisfies the structure and constraints specified in the schema
○ The DBMS stores the descriptions of the schema constructs and constraints—also called the
meta-data
○ The schema is sometimes called the intension, and a database state is called an extension of
the schema.
○ Schema evolution: another data item needs to be stored for each record in a file, such as
adding the Date_of_birth to the STUDENT schema.

Database System Concepts and Architecture Page 2


Three-Schema Architecture and Data Independence
Thursday, January 11, 2024 10:19 AM

• The Three-Schema Architecture


○ The goal of the three-schema architecture is to separate the user applications from the
physical database.

○ Internal level has an internal schema, which describes the physical storage structure of the
database.
▪ The internal schema uses a physical data model and describes the complete details of
data storage and access paths for the database.
○ Conceptual level has a conceptual schema, which describes the structure of the whole
database for a community of users.
▪ The conceptual schema hides the details of physical storage structures and
concentrates on describing entities, data types, relationships, user operations, and
constraints.
▪ A representational data model is used to describe the conceptual schema when a
database system is implemented.
▪ This implementation conceptual schema is often based on a conceptual schema
design in a high-level data model.
○ The external or view level includes a number of external schemas or user views.
▪ Each external schema describes the part of the database that a particular user group is
interested in and hides the rest of the database from that user group.
▪ Each external schema is typically implemented using a representational data model.
○ The DBMS must transform a request specified on an external schema into a request against
the conceptual schema, and then into a request on the internal schema for processing over
the stored database.
▪ If the request is a database retrieval, the data extracted from the stored database
must be reformatted to match the user’s external view.
▪ The processes of transforming requests and results between levels are called
mappings.

Database System Concepts and Architecture Page 3


• Data Independence
○ The capacity to change the schema at one level of a database system without having to
change the schema at the next higher level.
○ Logical data independence is the capacity to change the conceptual schema without having
to change external schemas or application programs.
▪ We may change the conceptual schema to expand the database, to change
constraints, or to reduce the database. In the last case, external schemas that refer
only to the remaining data should not be affected.
▪ Only the view definition and the mappings need to be changed in a DBMS that
supports logical data independence.
○ Physical data independence is the capacity to change the internal schema without having to
change the conceptual schema.
▪ Hence, the external schemas need not be changed as well.
▪ Changes to the internal schema may be needed because some physical files were
reorganized—for example, by creating additional access structures—to improve the
performance of retrieval or update.
▪ If the same data as before remains in the database, we should not have to change the
conceptual schema.

Database System Concepts and Architecture Page 4


Database Languages and Interfaces
Tuesday, January 16, 2024 12:29 AM

• DBMS Languages
○ Data Definition Language (DDL): define conceptual and internal schema
○ Storage Definition Language (SDL): specify the internal schema
○ View Definition Language (VDL): specify user views and their mappings to the conceptual
schema
○ Data Manipulation Language (DML): DB modification
▪ Which data to retrieve rather than how to retrieve it --> Declarative
▪ Low-level DMLs are also called record-at-a-time
▪ High-level DMLs are called set-at-a-time
▪ DML commands embedded in a general-purpose programming language, that
language is called the host language and the DML is called the data sublanguage.
▪ Casual end users typically use a high-level query language to specify their requests,
whereas programmers use the DML in its embedded form
○ SQL = DDL+VDL+DML
• DBMS Interfaces
○ Menu-Based Interfaces for Web Clients or Browsing.
▪ These interfaces present the user with lists of options (called menus) that lead the
user through the formulation of a request.
○ Forms-Based Interfaces.
▪ Users can fill out all of the form entries to insert new data, or they can fill out only
certain entries, in which case the DBMS will retrieve matching data for the remaining
entries.
▪ Forms are usually designed and programmed for naive users.
○ Graphical User Interfaces.
▪ GUIs utilize both menus and forms.
▪ Most GUIs use a pointing device, such as a mouse, to select certain parts of the
displayed schema diagram.
○ Natural Language Interfaces.
▪ These interfaces accept requests written in English or some other language and
attempt to understand them.
▪ Ex. Search engine, web pages
○ Speech Input and Output.
▪ Limited use of speech as an input query and speech as an answer to a question or
result of a request is becoming commonplace.
▪ Ex. inquiries for telephone directory, flight arrival/departure, and credit card account
information
○ Interfaces for Parametric Users.
▪ Parametric users, such as bank tellers, often have a small set of operations that they
must perform repeatedly.
▪ Ex. a teller is able to use single function keys to invoke routine and repetitive
transactions such as account deposits or withdrawals, or balance inquiries.
○ Interfaces for the DBA.
▪ Privileged commands that can be used only by the DBA staff.
▪ Ex. commands for creating accounts, setting system parameters, granting account
authorization, changing a schema, and reorganizing the storage structures of a
database.

Database System Concepts and Architecture Page 5


Centralized and Client/Server Architectures for DBMSs
Tuesday, January 16, 2024 1:09 AM

• Centralized DBMSs Architecture


○ Centralize (Terminal --> PC's, workstations) --> client-server (high-processing systems)

• Basic Client/Server Architectures


○ The idea is to define specialized servers with specific functionalities.
○ The resources provided by specialized servers can be accessed by many client machines
○ Ex. CAD (computer-aided design) package—being stored on specific server machines and
being made accessible to multiple clients
○ Logical two-tier

○ Physical two-tier

Database System Concepts and Architecture Page 6


• Two-Tier Client/Server Architectures for DBMSs


○ Application program (Client) --> Open Database Connectivity (ODBC) (ex. JDBC connects java
program to DB) provides an application programming interface (API) --> query server or
transaction server (ex. SQL server)
○ User interface programs and application programs can run on the client side.
• Three-Tier and n-Tier Architectures for Web Applications

○ This intermediate layer or middle tier is called the application server or the Web server,
depending on the application.
○ This server runs application programs and store business rules (procedures or constraints)
that are used to access data from the database server.
○ Improve database security by checking a client’s credentials before forwarding a request to
the database server.
○ The presentation layer displays information to the user and allows data entry.
○ The business logic layer handles intermediate rules and constraints before data is passed up
to the user or down to the DBMS.
The bottom layer includes all data management services.

Database System Concepts and Architecture Page 7


○ The bottom layer includes all data management services.

Database System Concepts and Architecture Page 8

You might also like