Download Lecture2

Ref. Chapter2
Lecture2
Lecture2: Database Environment
1
• Overviews
• Three-level Architecture.
• Schemas and Instances
• External, conceptual, and external level
• Data Models and conceptual modeling
• Some terms definitions.
• Data Models
• Some Example about data models
• Database Languages
• Classification or models of DBMSs.
Lecture2
Topics Covered
2
Lecture2
Three-level
Architecture
3
Schemas and Instances
• when we define a new database, we specify its schema –
“the structure that describes the database”.
Lecture2
• important to distinguish between description of
database and the database itself
• schema (intention)
• instance (database state / extension)
• The actual data in the database at any point of time
• when we initially load data into the database, it is said to
move into the initial state of the database.
• each write operation (insert, delete, modify) changes
the current state of the database to its new state
4
• The Database is provide users with an abstract
view of data
• Abstract database means to hide certain details
of how data is stored and manipulated.
Lecture2
Three-level Architecture
5
Three-level Architecture
2. Conceptual Level (logical structure of entire database)
• Community view of the database.
• Describes what data is stored in database and
relationships among the data.
3. Internal Level ( the way DBMS and OS perceive the data)
• Physical representation of the database on the computer.
• Describes how the data is stored in the database.
Lecture2
1. External Level ( the ways users perceive the data)
• Users' view of the database.
• Describes that part of database that is relevant to a
particular user.
6
7
Lecture2
Lecture2
Illustrating Example
8
1. Each user should able to access the data, but
have a different customized view of data.
2. The DBA should be able to change the DB
storage structure without affecting the user’s
view.
3. The internal structure of database should
unaffected by changes to the physical aspects
of storage, such as change to new storage
device.
Lecture2
Reasons for Separations?
9
• The three-level architecture provides Data Independence,
which means that upper level are unaffected by changes
to lower level
• There are two kinds of data independence:
• Logical Data Independence
• Physical Data Independence
Lecture2
Data Independence
10
• 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.
Lecture2
Data Independence
11
• Physical Data Independence
• 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.
Lecture2
Data Independence
12
Lecture2
Data Independence and the Three-Level
Architecture
13
14
Lecture2
Lecture2
Data Models
15
Terms
Terms
Definition
Entity
Represents a real world object or concept e.g. employee
and student
Attribute
Represents some property of interest that further
describes an entity e.g. employee name and student
number
Relationship
Represents the relation among two or more entities e.g.
work on relationship between employees and
departments.
Primary key
A primary key value defined on a key specifies that each
row in the table can be uniquely identified by the values in
the key e.g. student_ID
Foreign Keys
A foreign key is a key that points to the primary key of
another table.
16
Terms
Term
Definition
Table Names
Converting of entities into tables
Column Names
Converting of attributes into columns
Normalization
The process of organizing data to minimize
redundancy such as dividing large tables into smaller
(and less redundant) tables and defining relationships
between them
Denormalization
The process of attempting to optimise the read
performance of a database
Such as adding attributes to a relation from another
relation with which it will be joined
17
Integrated collection of concepts for describing
data, relationships between data, and constraints
on the data in an organization.
• Purpose
• To represent data in an understandable way.
• Data Model contains:
• High-level (Conceptual) models:
Lecture2
Data Model
• Logical models:
• Low-level (physical) models
18
Data Model
• High-level (Conceptual ) models:
• Logical models:
• Provide concepts about logical structure of data, closer
to physical models.
Lecture2
• Provide concepts that are close to the way end users
perceive data.
• Low-level (physical) models
• Provide concepts that describe the details of how data
is stored in the computer .
• Concepts provide by low-level data models are
generally meant for computer specialists, not for
typical ends users.
19
Conceptual Data Model
• A conceptual data model identifies the highest-level
relationships between the different entities. Features of
conceptual data model includes the important entities
and the relationships among them.
• No attribute is specified.
• No primary key is specified
From the figure, we can see that the only
information shown via the conceptual data
model is the entities that describe the data
and the relationships between those entities.
No other information is shown through the
conceptual data model.
Lecture2
.
20
Logical Data Model
•
A logical data model describes the data in as much detail as possible,
without regard to how they will be physical implemented in the
database.
Features of a logical data model include:
1.
2.
3.
4.
5.
•
Includes all entities and relationships among them.
All attributes for each entity are specified.
The primary key for each entity is specified.
Foreign keys (keys identifying the relationship between different
entities) are specified.
Normalization occurs at this level.
Lecture2
•
The steps for designing the logical data model are as follows:
1.
2.
3.
4.
5.
Specify primary keys for all entities.
Find the relationships between different entities.
Find all attributes for each entity.
Resolve many-to-many relationships.
Normalization.
21
•
Comparing the logical data model shown above with the conceptual data
model diagram, we see the main differences between the two:
1. in a logical data model, primary keys are present, whereas in a
conceptual data model, no primary key is present.
2. In a logical data model, all attributes are specified within an entity. No
attributes are specified in a conceptual data model.
3. Relationships between entities are specified using primary keys and
foreign keys in a logical data model. In a conceptual data model, the
relationships are simply stated, not specified, so we simply know that
two entities are related, but we do not specify what attributes are
used for this relationship.
Lecture2
The figure is an example of a
logical data model.
22
•
•
•
Physical data model represents how the model will be built in the database. A
physical database model shows all table structures, including column name,
column data type, column constraints, primary key, foreign key, and relationships
between tables.
Features of a physical data model include:
1. Specification all tables and columns.
2. Foreign keys are used to identify relationships between tables.
3. Denormalization may occur based on user requirements.
4. Physical considerations may cause the physical data model to be quite
different from the logical data model.
5. Physical data model will be different for different RDBMS. For example, data
type for a column may be different between MySQL and SQL Server.
The steps for physical data model design are as follows:
1.
2.
3.
4.
Convert entities into tables.
Convert relationships into foreign keys.
Convert attributes into columns.
Modify the physical data model based on physical constraints / requirements.
Lecture2
Physical Data Model
23
Lecture2
The figure below is an
example of a physical
data model.
•
Comparing the logical data model shown above with the logical
data model diagram, we see the main differences between the
two:
1. Entity names are now table names.
2. Attributes are now column names.
3. Data type for each column is specified. Data types can be
different depending on the actual database being used.
24
Conceptual, Logical, And Physical Data
Models
Feature
Conceptual
Logical
Entity Names
✓
✓
Entity
Relationships
✓
✓
Physical
Attributes
✓
Primary Keys
✓
✓
Foreign Keys
✓
✓
Table Names
✓
Column Names
✓
Column Data
Types
✓
Lecture2
• The three level of data modeling, conceptual data model, logical data
model, and physical data model, were discussed in prior sections.
• Here we compare these three types of data models. The table below
compares the different features:
25
Logical Model Design
Physical Model Design
• Summary: We can see that the complexity increases from conceptual
to logical to physical. This is why we always:
1. first start with the conceptual data model (so we understand at high
level what are the different entities in our data and how they relate
to one another),
2. then move on to the logical data model (so we understand the
details of our data without worrying about how they will actually
implemented),
3. and finally the physical data model (so we know exactly how to
implement our data model in the database of choice).
Lecture2
Conceptual Model Design
26
27
Lecture2
Lecture2
Database Languages
28
Database Languages
1.
2.
3.
Data Definition Language (DDL)
Data Manipulation Language (DML)
Data Control Language (DCL)
Lecture2
• It is made up of three components:
• Data Definition Language (DDL)
• Allows the DBAs or users to describe and name entities,
attributes, and relationships required for the application
( define a schema or modify an existing one)
• plus any associated integrity and security constraints.
29
Database Languages
• Data Manipulation Language (DML)
• Insertion of new data into the database
• Modification of data stored in the database
• Retrieval of data contained in the database
• Deletion of data from database
• Two type of DML:
• Procedural DML
• allows user to tell system exactly how to manipulate data.
Lecture2
• provides basic data manipulation operations on data held
in the database – include
• Ex. Oracle’s PL/SQL
• Non-Procedural DML
• allows user to state what data is needed rather than how it
is to be retrieved.
• Example : SQL (Structured Query Languages)
30
• The Data Control Language (DCL)
• This component of the database language is
used to create privileges to allow users access to
the database.
Lecture2
Database Languages
31
• SQL is made up of 4 components:
1.Data Definition Language (DDL)
2.Data Manipulation Language (DML)
3.Data Control Language (DCL)
4.Transaction control statements
Lecture2
SQL in Oracle
32
SQL in Oracle
1. The Data Definition Language (DDL)
This component of the SQL language is used to create and
modify tables and other objects in the database.
1. CREATE TABLE tablename : to create a table in the
database
2. DROP TABLE tablename : to remove a table from the
database
3. ALTER TABLE tablename : to add or remove columns
from a table in the database
Lecture2
 For tables there are three main commands:
33
SQL in Oracle
2. The Data Manipulation Language (DML)
 There are four main commands:
1. SELECT : to select rows of data from a table.
2. INSERT : to insert rows of data into a table.
3. UPDATE : to change rows of data in a table.
4. DELETE : to remove rows of data from a table.
Lecture2
component of the SQL language is used to manipulate data
within a table.
34
SQL in Oracle
This component of the SQL language is used to create
privileges to allow users access to, and manipulation of,
the database.
 There are two main commands:
1.GRANT : to grant a privilege to a user
2.REVOKE : to revoke (remove) a privilege from a user
Lecture2
3. The Data Control Language (DCL)
4. Transaction control statements
• COMMIT, ROLLBACK
35
36
Lecture2
Lecture2
Classification of
DBMSs
37
Classification or models of DBMSs
1. first generation
• Network, Hierarchical
2. second generation
• Relational
3. third generation
• Object-oriented, Object-relational
38
First Generation
 Network Data Model
 Hierarchical Data Model
Disadvantages:
• Required complex programs for even simple queries.
• Minimal data independence.
• No widely accepted theoretical foundation
39
Second Generation
• Relational Data Model
40
Third Generation
• Object-oriented Data Model
• Response to increasing complexity of DB applications
41
Relational Data Model (second generation)
• Computer database in which all data is stored in
Relations which are tables with rows and columns.
• Each table is composed of records (called Tuples) and
each record is identified by a field (attribute containing a
unique value).
42
Advantages of Relational model
The benefits of a database that has been designed
according to the relational model are numerous. Some of
them are:
• Data entry, updates and deletions will be efficient.
• Data retrieval, summarization and reporting will also be
efficient.
• Since the database follows a well-formulated model, it
behaves predictably.
• Since much of the information is stored in the database
rather than in the application, the database is somewhat
self-documenting.
• Changes to the database schema are easy to make.
43
44
Lecture2
• “Database Systems: A Practical Approach to
Design, Implementation and Management.”
Thomas
Connolly,
Carolyn
Begg.
5th Edition, Addison-Wesley, 2009.
Lecture2
References
45