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

Differences Between Three Levels of ANSI-SPARC Architecture

The document discusses three levels of data independence in the ANSI-SPARC architecture: logical data independence, physical data independence, and how they relate to the three-level architecture. It also provides definitions and examples of key concepts in relational database systems, including relations, attributes, domains, tuples, candidate keys, primary keys, foreign keys, and referential integrity.

Uploaded by

Sudais khan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
53 views

Differences Between Three Levels of ANSI-SPARC Architecture

The document discusses three levels of data independence in the ANSI-SPARC architecture: logical data independence, physical data independence, and how they relate to the three-level architecture. It also provides definitions and examples of key concepts in relational database systems, including relations, attributes, domains, tuples, candidate keys, primary keys, foreign keys, and referential integrity.

Uploaded by

Sudais khan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 31

Differences between Three Levels of

ANSI-SPARC Architecture

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

2
Data Independence
• 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.

3
Data Independence and the ANSI-
SPARC Three-level Architecture

4
Data Model

• Data Model comprises:


– A structural part
– A manipulative part
– Possibly a set of integrity rules

5
Data Model
• Purpose
– To represent data in an understandable way.

6
Relational Systems
• Then, in 1970,E. F. Codd wrote “A Relational Model of
Data for Large Shared Databanks” and introduced the
relational model
• Information is stored as tuples or records in relations or
tables
• Most modern DBMS are based on the relational model
• The relational model covers 3 areas:
– Data structure
– Data manipulation
– Data integrity
Relational Model Terminology
• A relation is a table with columns and rows.

• Attribute is a named column of a relation.

• Domain is the set of allowable values for


one or more attributes.

8
Relational Model Terminology
• Tuple is a row of a relation.

• Degree is the number of attributes in a relation.

• Cardinality is the number of tuples in a relation.

• Relational Database is a collection of relations


with distinct relation names.

9
Instances of Branch and Staff Relations

10
Examples of Attribute Domains

11
Alternative Terminology for Relational
Model

12
Properties of Relations
• Relation name is distinct from all other relation
names in relational schema.

• Each cell of relation contains exactly one


atomic (single) value.

• Each attribute has a distinct name.

• Values of an attribute are all from the same


domain.

13
Properties of Relations
• Each tuple is distinct; there are no duplicate
tuples.

• Order of attributes has no significance.

• Order of tuples has no significance.

14
Candidate Keys
• A set of attributes in a
relation is called a candidate ID First Last
key if, and only if, S139 John Smith
– Every tuple has a unique S140 Mary Jones
value for the set of attributes S141 John Brown
(uniqueness) S142 Jane Smith
– No proper subset of the set
has the uniqueness property Candidate key: {ID}; {First,Last}
looks reasonable but we may get
(minimality)
people with the same name
{ID, First}, {ID, Last} and {ID,
First, Last} satisfy uniqueness,
but are not minimal
{First} and {Last} do not give
a unique identifier for each row
Choosing Candidate Keys

• Important: don’t look just on the data in the table to


determine what is a candidate key

• The table may contain just one tuple, so anything


would do!

• Use knowledge of the real world – what is going to


stay unique!
Primary Keys

• One Candidate Key is usually chosen to be used to


identify tuples in a relation
• This is called the Primary Key
• Often a special ID attribute is used as the Primary Key
NULLs and Primary Keys
• Missing information can • Entity Integrity: Primary
be represented using Keys cannot contain
NULLs NULL values
• A NULL indicates a
missing or unknown
value
• More on this later...
Foreign Keys
• Foreign Keys are used to link data in two
relations. A set of attributes in the first
(referencing) relation is a Foreign Key if its
value always either
– Matches a Candidate Key value in the second
(referenced) relation, or
– Is wholly NULL
• This is called Referential Integrity
Foreign Keys - Example

Department Employee
DID DName EID EName DID
13 Marketing 15 John Smith 13
14 Accounts 16 Mary Brown 14
15 Personnel 17 Mark Jones 13
18 Jane Smith NULL

{DID} is a Candidate Key {DID} is a Foreign Key in Employee -


for Department - Each each Employee’s DID value is either
entry has a unique value NULL, or matches an entry in the
for DID Department relation. This links each
Employee to (at most) one Department

The Relational Model


Foreign Keys - Example

Employee
{ID} is a Candidate Key for
ID Name Manager Employee, and {Manager} is
E1496 John Smith E1499 a Foreign Key, which refers
E1497 Mary Brown E1498 to the same relation - every
E1498 Mark Jones E1499 tuple’s Manager value is either
E1499 Jane Smith NULL NULL or matches an ID value
Referential Integrity
• When relations are • There are a number of
updated, referential options:
integrity can be violated – RESTRICT - stop the user from
• This usually occurs when a doing it
referenced tuple is updated – CASCADE - let the changes
flow on
or deleted
– NULLIFY - make values NULL
Referential Integrity - Example
• What happens if
– Marketing’s DID is changed to Department
16 in Department? DID DName
– The entry for Accounts is 13 Marketing
deleted from Department? 14 Accounts
15 Personnel

Employee
EID EName DID
15 John Smith 13
16 Mary Brown 14
17 Mark Jones 13
18 Jane Smith NULL
RESTRICT
• RESTRICT stops any action
that violates integrity Department
– You cannot update or delete DID DName
Marketing or Accounts 13 Marketing
– You can change Personnel as 14 Accounts
it is not referenced 15 Personnel

Employee
EID EName DID
15 John Smith 13
16 Mary Brown 14
17 Mark Jones 13
18 Jane Smith NULL
CASCADE

• CASCADE allows the changes Department


made to flow through DID DName
– If Marketing’s DID is changed to 13 16 Marketing
16 in Department, then the 14 Accounts
DIDs for John Smith and Mark 15 Personnel
Jones also change
– If Accounts is deleted then so is Employee
Mary Brown EID EName DID
15 John Smith 13 16
16 Mary Brown 14
17 Mark Jones 13 16
18 Jane Smith NULL

The Relational Model


NULLIFY

• NULLIFY sets problem values Department


to NULL DID DName
– If Marketing’s DID changes then 13 16 Marketing
John Smith’s and Mark Jones’ 14 Accounts
DIDs are set to NULL 15 Personnel
– If Accounts is deleted, Mary
Brown’s DID becomes NULL Employee
EID EName DID
15 John Smith 13 NULL
16 Mary Brown 14 NULL
17 Mark Jones 13 NULL
18 Jane Smith NULL

The Relational Model


Relational Integrity
• Enterprise Constraints
– Additional rules specified by database
administrators.

27
Views
• Base Relation
– Named relation corresponding to an entity in
conceptual schema, whose tuples are
physically stored in database.

• View
– Dynamic result of one or more relational
operations operating on base relations to
produce another relation.

28
Views
• A virtual relation that does not necessarily
actually exist in the database but is produced
upon request, at time of request.

• Contents of a view are defined as a query on


one or more base relations.

• Views are dynamic, meaning that changes made


to base relations that affect view attributes are
immediately reflected in the view.

29
Purpose of Views
• Provides powerful and flexible security
mechanism by hiding parts of database from
certain users.

• Permits users to access data in a customized


way, so that same data can be seen by
different users in different ways, at same time.

• Can simplify complex operations on base


relations.

30
Updating Views
• All updates to a base relation should be
immediately reflected in all views that
reference that base relation.

• If view is updated, underlying base relation


should reflect change.

31

You might also like