Scribd
Upload
116 views

Dbms Terminologies To Remember

The document defines key terms and concepts related to database management systems (DBMS), including relations, tuples, attributes, domains, cardinality, and relational databases. It discusses properties of relations like having a distinct name and atomic values. The document also covers functional dependencies, normal forms, normalization, anomalies caused by redundancy, and using decomposition to eliminate redundancies.

Uploaded by

WearIt Co.
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
116 views

Dbms Terminologies To Remember

The document defines key terms and concepts related to database management systems (DBMS), including relations, tuples, attributes, domains, cardinality, and relational databases. It discusses properties of relations like having a distinct name and atomic values. The document also covers functional dependencies, normal forms, normalization, anomalies caused by redundancy, and using decomposition to eliminate redundancies.

Uploaded by

WearIt Co.
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 16

DBMS

TERMINOLOGIES
TO REMEMBER
RELATION- AN ENTITY THAT IS COMPOSED OF ROWS AND
COLUMNS
TUPLES – REFERS TO THE ROWS OF A RELATION
ATTRIBUTE- REFERS TO THE NAMED COLUMN OF A
RELATION
DOMAIN- SET OF ALLOWABLE VALUES FOR ONE OR
MORE
ATTRIBUTES
DEGREE- THE NUMBER OF ATTRIBUTES THAT A RELATION

CONTAINS
CARDINALITY- REFERS TO THE NUMBER OF TUPLES A
RELATION CONTAINS
RELATIONAL DATABASE- A COLLECTION OF NORMALIZED
RELATION WITH DISTICT RELATION NAMES.
Attribute Attribute Attribute Attribute

StudentNo FirstName LastName Year

Relation or Table
Tuples/row
Formal Alternative Alternative
Terms 1 2
Relational Table File
Tuples Rows Record
Attributes Columns Field
Properties of Relations
1. The relation should have a name that is
distinct from all other relation names in the
relational schema
2. Each cell of the relation contains exactly
one atomic/single value
3. The values of an attribute should all be
coming from same domain
4. Each tuple is distinct. There should be no
duplicated tuple
5. The order of attributes has no significance
6. The order of the tuples has no significance

Relational Keys
Super Key- an attribute or combination of
attributes that uniquely identifies a tuple in
a relation
 Candidate Key- a superkey that no proper

subset is a superkey
 Primary Key- the attribute that was

identified from the selected candidate key


which help in the identification of one tuple
to other
 Foreign Key- the attribute that exist in

another table which can be used to match


record to the parent table.
Structural and Data Dependence
Structural Dependence- access to file is
dependent on its own structure
• All file system program must be modified to conform
to a new file system

Structural Independence- File structure can be


changed without affecting data access

Data Dependence- Data access changes when data


storage characteristics change

Data Independence- changes in data storage


characteristics do not affect data access
Structural and Data Dependence
Logical Data Format
-how humans views the data

Physical Data Format


- It talks about how the computer works with data
Functional Dependencies
Objectives of Normalization
 Develop a good description of the data, its
relationships and constraints
 Produce a stable set of relations that

◦ Is a faithful model of the enterprise


◦ Is highly flexible
◦ Reduces redundancy-saves space and reduces
inconsistency in data
◦ Is free of update, insertion and deletion anomalies
Normal Forms
 First normal form -1NF
 Second normal form-2NF
 Third normal form-3NF
 Boyce-Codd normal form-BCNF
 Fourth normal form-4NF
 Fifth normal form-5NF
 Domain/Key normal form-DKNF

Each is contained within the previous form –


each has stricter rules than the previous form
 Normalization theory provides
a mechanism for analyzing
and refining the schema
produced by an E-R design, or
any other design.

 E-Rdesigning will be tackled


soon
Redundancy
Dependencies between attributes within a relation cause
redundancy
SSN Name Town Zip
1234 Joe Huntingdon 16652
2345 Mary Huntingdon 16652
3456 Tom Huntingdon 16652
5948 Harry Alexandria 16603
Ex. All addresses in the same town have the same zip code There's clearly
redundant information stored here. 
Consistency and integrity are harder to maintain even in this simple example, e.g.,
ensuring the fact that the zip code always refers the same city and the city is spelled
consistently.
Note we don't have a zip code to city fact stored unless there is a person from that
zip code
Redundancy and Other Problem
 Set-valued or multi-valued attributes in the E-R diagram result in
multiple rows in corresponding table
 Example: Person (SSN, Name, Address, Hobbies)
 A person entity with multiple hobbies yields multiple rows in table
Person
 Hence, the association between Name and Address for the same
person is stored redundantly
 SSN is key of entity set, but (SSN, Hobbies) is key of corresponding
relation below. The relation Person can’t describe people without
hobbies but more important is the replication of what would be the
key value
SSN Name Address Hobbies
1111 Joe 123 Main hiking
1111 Joe 123 Main biking
2222 Mary 321 Elm lacross
Anomalies
 An anomaly is an inconsistent, incomplete, or
contradictory state of the database
 Insertion anomaly – user is unable to insert a new
record of data when it should be possible to do so
because not all other information is available.
 Deletion anomaly – when a record is deleted, other
information that is tied to it is also deleted
 Update anomaly –a record is updated, but other
appearances of the same items are not updated
 Redundancy leads to the following anomalies:
 Update anomaly: A change in Address must be made in
several places. Updating one fact may require updating
multiple tuples.
Deletion anomaly: Deleting one fact may
delete other information.
◦ Suppose a person gives up all hobbies. Do we:
◦ Set Hobby attribute to null? No, since Hobby is
part of key
◦ Delete the entire row? No, since we lose other
information in the row
Insertion anomaly: To record one fact may
require more information than is available.
Hobby value must be supplied for any
inserted row since Hobby is part of key
Decomposition
Solution: use two relations to store Person information
Person1 (SSN, Name, Address)
Hobbies (SSN, Hobby)
The decomposition is more general: people with
hobbies can now be described
No update anomalies:
Name and address stored once
A hobby can be separately supplied or deleted

Decomposition is the process of breaking a relation into


two or more relations to eliminate the redundancies and
corresponding anomalies.

You might also like