Exit Exam Tutorial

Part 2: Fundamental Database Management Systems

Episode 2: Database System Concepts and
Architectures
2.2 Database System Concepts
and Architectures
- The purpose and origin of the three-level database
architecture
- All users should be able to access same data
- A user's view is unaffected or immune to changes made in
other views
- Users should not need to know physical database storage
details
- DBA should be able to change database storage structures
without affecting the users' views.
- Internal structure of database should be unaffected by
changes to physical aspects of storage.
- DBA should be able to change conceptual structure of
database without affecting all users.
2.2 Database System Concepts
and Architectures
- The purpose of the external/conceptual and the
conceptual/internal mappings:
- External Level: Users' view of the database. Describes that
part of database that is relevant to a particular user.
- Different users have their own customized view of the
database independent of other users.
- Conceptual Level: Community view of the database.
- Describes what data is stored in database and relationships
among the data.
- Internal Level: Physical representation of the database on
the computer.
- Describes how the data is stored in the database.
2.2 Database System Concepts
and Architectures
- Internal schema at the internal level to describe physical
storage structures and access paths.
- 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 level.
2.2 Database System Concepts
and Architectures
DATA INDEPENDENCE:
- Logical Data Independence: Refers to immunity of external
schemas to changes in conceptual schema.
- Conceptual schema changes e.g. addition/removal of
entities should not require changes to external schema or
rewrites of application programs.
- The capacity to change the conceptual schema without
having to change the external schemas and their
application programs.
2.2 Database System Concepts
and Architectures
– Physical Data Independence: The ability to modify the
physical schema without changing the logical schema.
– Applications depend on the logical schema.
– In general, the interfaces between the various levels and
components should be well defined so that changes in some
parts do not seriously influence others.
– The capacity to change the internal schema without having
to change the conceptual schema.
– Refers to immunity of conceptual schema to changes in the
internal schema.
– Internal schema changes e.g. using different file
organizations, storage structures/devices should not
require change to conceptual or external schemas.
2.2 Database System Concepts
and Architectures
2.2.1 Data Definition and Data Manipulation Language
- DATA DEFINITION LANGUAGE (DDL): Allows DBA or user
to describe and name entitles, attributes and relationships
required for the application.
- Specification notation for defining the database schema.
- Data Manipulation Language (DML): Provides basic data
manipulation operations on data held in the database.
- Language for accessing and manipulating the data
organized by the appropriate data model.
- DML also known as query language.
- Procedural DML: user specifies what data is required and
how to get the data.
- Non-Procedural DML: user specifies what data is required
but not how it is to be retrieved.
2.2 Database System Concepts
and Architectures
- SQL is the most widely used non-procedural language query
language
- Fourth Generation Language (4GL): Query Languages,
Forms Generators, Report Generators, Graphics Generators
and Application Generators.
2.2 Database System Concepts
and Architectures
2.2.2 A Classification of data models
- A specific DBMS has its own specific Data Definition
Language, but this type of language is too low level to
describe the data requirements of an organization in a way
that is readily understandable by a variety of users.
- We need a higher-level language.
- Such a higher-level is called data-model.
- Data Model: a set of concepts to describe the structure of a
database, and certain constraints that the database should
obey.
- A data model is a description of the way that data is stored
in a database.
2.2 Database System Concepts
and Architectures
- Data model helps to understand the relationship between
entities and to create the most effective structure to hold
data.
- Data Model is a collection of tools or concepts for
describing data, data relationships, data semantics and data
constraints.
- The main purpose of data Model is to represent the data in
an understandable way.
- The main purpose of Data Model is to represent the data in
an understandable way.
- Categories of data models include: Object-based, Record-
based and Physical.
- Object-based Data Models: Entity-Relationship, Semantic,
Functional and Object-Oriented.
2.2 Database System Concepts
and Architectures
RECORD BASED DATA MODELS:
- Consist of a number of fixed format records.
- Each record type defines a fixed number of fields, Each field
is typically of a fixed length. There are: Relational Data
Model, Network Data Model and Hierarchical Data Model.
2.2 Database System Concepts
and Architectures
THREE MAJOR TYPES OF DATA MODEL:
1. Hierarchical Model: The simplest data model.
 Record type is referred to as node or segment.
 The top node is the root node.
 Nodes are arranged in a hierarchical structure as sort of
upside-down tree.
 A parent node can have more than one child node.
 A child node can only have one parent node.
 The relationship between parent and child is one-to-many.
 Relation is established by creating physical link between
stored records (each is stored with a predefined access path
to other records).
2.2 Database System Concepts
and Architectures
- ADVANTAGES of Hierarchical Data Model:
 Hierarchical Model is simple to construct and operate on.
 Corresponds to a number of natural hierarchically
organized domains - e.g., assemblies in manufacturing,
personnel organization in companies.
 Language is simple; uses constructs like GET, GET UNIQUE,
GET NEXT, GET NEXT WITHIN PARENT etc.
- DISADVANTAGES of Hierarchical Data Model:
 Navigational and procedural nature of processing.
 Database is visualized as a linear arrangement of records.
 Little scope for "query optimization“.
2.2 Database System Concepts
and Architectures
2. Network Model: Allows record types to have more that
one parent unlike hierarchical model.
 A network data models sees records as set members.
 Each set has an owner and one or more members.
 Allow no many to many relationship between entities.
2.2 Database System Concepts
and Architectures
- ADVANTAGES of Network Data Model:
 Network Model is able to model complex relationships and
represents semantics of add/delete on the relationships.
 Can handle most situations for modeling using record types
and relationship types.
 Language is navigational; uses constructs like FIND, FIND
member, FIND owner, FIND NEXT within set, GET etc.
Programmers can do optimal navigation through the
database.
- DISADVANTAGES of Network Data Model:
 Navigational and procedural nature of processing.
 Database contains a complex array of pointers that thread
through a set of records.
 Little scope for automated "query optimization”.
2.2 Database System Concepts
and Architectures
3. Relational Data Model: Terminologies originates from the
branch of mathematics called set theory and relation.
 Can define more flexible and complex relationship.
 Viewed as a collection of tables called “Relations”
equivalent to collection of record types.
 Relation: Two dimensional table.
 Stores information or data in the form of tables with rows
and columns.
 A row of the table is called tuple and it is equivalent to
record.
 A column of a table is called attribute and it is equivalent to
fields.
2.2 Database System Concepts
and Architectures
 Data value is the value of the attribute
 Records are related by the data stored jointly in the fields of
records in two tables or files.
 The related tables contain information that creates the
relation
 The tables seem to be independent but are related some
how.
 No physical consideration of the storage is required by the
user.
 Many tables are merged together to come up with a new
virtual view of the relationship.
2.2 Database System Concepts
and Architectures
2.2.3 Relational Data Model Explanations
Properties of Relational Databases:
 Each row of a table is uniquely identified by a PRIMARY
KEY composed of one or more columns.
 Each tuple in a relation must be unique.
 Group of columns, that uniquely identifies a row in a table is
called a CANDIDATE KEY.
 ENTITY INTEGRITY RULE of the model states that no
component of the primary key may contain a NULL value.
 A column or combination of columns that matches the
primary key of another table is called a FOREIGN KEY.
 Used to cross-reference tables.
2.2 Database System Concepts
and Architectures
 The REFERENTIAL INTEGRITY RULE of the model states
that, for every foreign key value in a table there must be a
corresponding primary key value in another table in the
database or it should be NULL.
 All tables are LOGICAL ENTITIES.
 A table is either a BASE TABLES (Named Relations) or
VIEWS (Unnamed Relations).
 Only Base Tables are physically stores.
 VIEWS are derived from BASE TABLES with SQL
instructions like: [SELECT .. FROM .. WHERE .. ORDER BY].
 It is the collection of tables has each entity in one table and
attributes are fields (columns) in table.
2.2 Database System Concepts
and Architectures
2.2.4 Building Blocks of the Relational Model
- The building blocks of the relational data model are:
 Entities: real world physical or logical object
 Attributes: properties used to describe each Entity or real
world object.
 Relationship: the association between Entities
 Constraints: rules that should be obeyed while
manipulating the data.
2.2 Database System Concepts
and Architectures
- The relation itself corresponds to our familiar notion of a
table: A relation is a collection of tuples, each of which
contains values for a fixed number of attributes.
- The domain from which attribute values are taken (A
DOMAIN is a set of values from which attribute values may
be taken.)
- Each attribute has values taken from a domain.
- Whether the attribute is part of the entity identifier
(attributes which just describe an entity and those which
help to identify it uniquely).
- Whether it is permanent or time-varying (which attributes
may change their values over time).
- Whether it is required or optional for the entity (whose
values will sometimes be unknown or irrelevant).
2.2 Database System Concepts
and Architectures
2.2.5 Types of Attributes
1) Simple (atomic) Vs Composite attributes
- Simple: contains a single value (not divided into sub parts).
- Composite: Divided into sub parts (composed of other
attributes).
2) Single-valued Vs multi-valued attributes
- Single-valued: have only single value (the value may change
but has only one value at one time).
- Multi-Valued: have more than one value.
3) Stored vs. Derived Attributes
- Stored: not possible to derive or compute.
- Derived: The value may be derived (computed) from the
values of other attributes.
2.2 Database System Concepts
and Architectures
4) Null Values
- NULL applies to attributes which are not applicable or
which do not have values.
- You may enter the value NA (meaning not applicable).
- Value of a key attribute cannot be null.
- Default value: assumed value if no explicit value.
2.2 Database System Concepts
and Architectures
- The RELATIONSHIPS between entities which exist and
must be taken into account when processing information.
- One external event or process may affect several related
entities.
- Related entities require setting of LINKS from one part of
the database to another.
- A relationship should be named by a word or phrase which
explains its function.
- An important point about a relationship is how many
entities participate in it.
2.2 Database System Concepts
and Architectures
- The number of entities participating in a relationship is
called the DEGREE of the relationship.
- UNARY/RECURSIVE RELATIONSHIP: Single entity.
- BINARY RELATIONSHIPS: Two entities associated.
- TERNARY RELATIONSHIP: Three entities associated.
- N-NARY RELATIONSHIP: arbitrary number of entity sets.
 Another important point about relationship is the range of
instances that can be associated with a single instance from
one entity in a single relationship.
 The number of instances participating or associated with a
single instance from another entity in a relationship is
called the CARDINALITY of the relationship.
2.2 Database System Concepts
and Architectures
RELATIONAL INTEGRITY
- Domain Integrity: No value of the attribute should be
beyond the allowable limits.
- Entity Integrity: In a base relation, no attribute of a primary
key can be null.
- Referential Integrity: If a foreign key exists in a relation,
either the foreign key value must match a candidate key in
its home relation or the foreign key value must be null
foreign key to primary key match-ups.
- Enterprise Integrity: Additional rules specified by the users
or database administrators of a database are incorporated.
2.2 Database System Concepts
and Architectures
KEY CONSTRAINTS
- If tuples are need to be unique in the database, and then we
need to make each tuple distinct.
- To do this we need to have relational keys that uniquely
identify each relation.
- Super Key: an attribute or set of attributes that uniquely
identifies a tuple within a relation.
- Candidate Key: a super key such that no proper subset of
that collection is a super key within the relation.
- A candidate key has two properties: Uniqueness and
Irreducibility.
- If a candidate key consists of more than one attribute it is
called composite key.
2.2 Database System Concepts
and Architectures
- Primary Key: the candidate key that is selected to identify
tuples uniquely within the relation.
- The entire set of attributes in a relation can be considered
as a primary case in a worst case.
- Foreign Key: an attribute, or set of attributes, within one
relation that matches the candidate key of some relation.
- A foreign key is a link between different relations to create
the view or the unnamed relation.
2.2 Database System Concepts
and Architectures
2.2.6 Relational Languages and Views
- The languages in relational database management systems
are the DDL and the DML that are used to define or create
the database and perform manipulation on the database.
- We have the two kinds of relation in relational database.
- The difference is on how the relation is created, used and
updated:
1. Base Relation: A Named Relation corresponding to an
entity in the conceptual schema, whose tuples are physically
stored in the database.
2. View: Is the dynamic result of one or more relational
operations operating on the base relations to produce
another virtual relation.
2.2 Database System Concepts
and Architectures
PURPOSES OF VIEW:
- Hides unnecessary information from users.
- Provide powerful flexibility and security.
- Provide customized view of the database for users.
- A view of one base relation can be updated.
- Update on views derived from various relations is not
allowed.
- Update on view with aggregation and summary is not
allowed.
2.2 Database System Concepts
and Architectures
2.2.7 Schemas and Instances or Database States
- Schema describes how data is to be structured, defined at
set-up time, rarely changes (also called "metadata").
- Database Schema (intension): specifies name of relation,
plus name and type of each column.
- It refers to a description of database (or intention)
- It specified during database design
- It should not be changed unless during maintenance
 Schema Diagrams: convention to display some aspect of a
schema visually.
 Schema Construct: refers to each object in the schema.
2.2 Database System Concepts
and Architectures
- Database state (snapshot or extension): is the collection of
data in the database at a particular point of time (snap-
shot).
- Refers to the actual data in the database at a specific time
- State of database is changed any time we add or delete a
record.
 Valid state: the state that satisfies the structure and
constraints specified in the schema and is enforced by
DBMS.
 Instance is actual data of database at some point in time,
changes rapidly.
 To define a new database, we specify its database schema
to the DBMS (database is empty).
 Database is initialized when we first load it with data.
2.2 Database System Concepts
and Architectures
Special Thanks to the publisher and author with:
2.2 Database System Concepts
and Architectures
 TOPICS AND THE CONCEPTS:
Database System Concepts
Database Schema
Database Instance
Relational Data Model
Relational Integrity
Key Constraints
Types of Attributes
A Classification of Data Model
Data Independence

REFERENCES:
Fundamental Database Management Systems (6th Edition) by Ramez Elmasri, Shamkant B. Navaathe
Database Systems: A Practical Approach to Design, Implementation, and Management (6th Edition) by
Thomas Connolly, Carolyn Begg

PRESENTED BY:
Mohammed Nebil

HISTORY OF THE PROGRAMMING:

Boyce Codd

SPECIAL THANKS:
Digital Library of Educations
Federal Democratic Republic of Ethiopia, Ministry of Educations
Ethiopian Education Short Note