UNIT 1 INTRODUCTION TO DBMS - Nirmala Memorial · PDF fileUNIT 1 INTRODUCTION TO DBMS 8 Levels Of Abstraction:- Process of hiding irrelevant details from user is called data abstraction

Database

Systems

-F.Y.CS

-Prof Valerie

UNIT 1 INTRODUCTION TO DBMS 2


Example of simple college database which stores student and course information.

Student:

Stud-id Name Subjects Grade

1 Bob CS A

2 Tom MATH B


Example of database catalog.

STUDENT Table

Student_id Name Subjects Class

1 Bob CS 1

20 Tom MATH 2

Column_name Data_type Belongs_to_relation

Stud_id Character (4) STUDENT

Name Character (10) STUDENT

Subjects Character (20) STUDENT

Class Integer (1) STUDENT





Levels Of Abstraction:-

Process of hiding irrelevant details from user is called data abstraction.

We have three levels of abstraction:

Physical level: This is the lowest level of data abstraction. It describes how data is

actually stored in database. You can get the complex data structure details at this

level.

Logical level: This is the middle level of 3-level data abstraction architecture. It

describes what data is stored in database.

View level: Highest level of data abstraction. This level describes the user


interaction with database system.

Example: Let’s say we are storing customer information in a customer table. At

physical level these records can be described as blocks of storage (bytes,

gigabytes, terabytes etc.) in memory. These details are often hidden from the

programmers.

At the logical level these records can be described as fields and attributes along

with their data types, their relationship among each other can be logically

implemented. The programmers generally work at this level because they are

aware of such things about database systems.

At view level, user just interact with system with the help of GUI and enter the

details at the screen, they are not aware of how the data is stored and what data

is stored; such details are hidden from them.

Data Independence


Logical Data Idependence

Logical data independence indicates that the conceptual schema can be changed without affecting the existing external schemas. The change would be absorbed by the mapping between the external and conceptual levels.

Physical Data Independence

Physical data independence indicates that the physical storage structures or devices could be changed without affecting conceptual schema. The change would be absorbed by the mapping between the conceptual and internal levels.

DBMS Architecture

There are following 3 levels or layers of DBMS Architecture:

1. External level

2. Conceptual level

3. Internal level


EXTERNAL LEVEL

The user’s view of the database.

Consists of a number of different external views of the DB.

Describes part of the DB for particular group of users.

Provides a powerful and flexible security mechanism by hiding parts of the DB from certain

users.

It permits users to access data in a way that is customized to their needs, so that the same

data can be seen by different users in different ways, at the same time.

CONCEPTUAL LEVEL

The logical structure of the entire database as seen by DBA.

What data is stored in the database.

The relationships among the data.

Complete view of the data requirements of the organization, independent of any storage

consideration.


INTERNAL LEVEL

Physical representation of the DB on the computer.

How the data is stored in the database.

- Storage space allocation for data and indexes

- Record description for storage

- Record placement

- Data compression, encryption

DATA MODELS

Client-Server Architecture:- Client-User machine that provides user interface capabilities and local processing. Client handles user interface programs and application programs. Server-System containing both hardware and software. Provides services to the client machines.Such as file access, printing, archiving, or database access. Server handles query and transaction functionality related to SQL processing. Servers with specific functionalities:-

File server-Maintains the files of the client machines.

Printer server Connected to various printers; all print requests by the

clients are forwarded to this machine


Two-Tier Client/Server Architecture Provides application programming

interface (API). Allows client-side programs to call the DBMS.Both client

and server machines must have the necessary software installed.

Three-Tier and n-Tier Architectures for Web Applications provides

Application server or Web server which adds intermediate layer

between client and the database server. Runs application programs and

stores business rules

N-tier-Divide the layers between the user and the stored data further

into finer components.


Object-based logical models:

-Describe data at the conceptual and view levels.

-Provide fairly flexible structuring capabilities.

-Object-based logical model includes the following.

1.Entity-relationship model.

2.Object-oriented model.

1. The E-R Model

The entity-relationship model is based on a perception of the world as consisting of a collection of basic objects (entities) and relationships among these objects as it's name itself suggests .

An entity is a distinguishable object that exists.

Each entity has associated with it a set of attributes describing it.

E.g. number and balance for an account entity.

A relationship is an association among several entities.

e.g. A cust_acct relationship associates a customer with each account he or she has.

The set of all entities or relationships of the same type is called the entity set or relationship set.

Another essential element of the E-R diagram is the mapping cardinalities, which express the number of entities to which another entity can be associated via a relationship set.

The overall logical structure of a database can be expressed graphically by an E-R

diagram:

rectangles: represent entity sets.

ellipses: represent attributes.

diamonds: represent relationships among entity sets.

lines: link attributes to entity sets and entity sets to relationships.


Entity-relationship model

2. Object-oriented data model:

Object-oriented programming (especially in Java, C++, or C#) has become the

popular software development methodology. This led to the development of an

object-oriented data model.

Record-based logical models:

Also describe data at the conceptual and view levels.Named so because the database is structured in fixed-format records of several types.Each record type defines a fixed number of fields, or attributes.The three most widely-accepted models are the relational, network, and hierarchical.

1.The Relational Model.

Data and relationships are represented by a collection of tables. Each table has a number of columns with unique names.

Student_id Name Subjects Class

1 Bob CS 1

20 Tom MATH 2


2. The Network Model.

Data are represented by collections of records. Relationships among data are represented by links. Organization is that of an arbitrary graph.

3. The Hierarchical Model.

Similar to the network model. Organization of the records is as a collection of trees, rather than arbitrary

graphs.

http://1.bp.blogspot.com/-fPCV6CO3GtU/VADVqFT8EwI/AAAAAAAAAUc/afev7UICsIk/s1600/hierarchy.png


Entity Relational Model

Entity:- The basic object that the ER model represents is an entity, which is a thing in

the real world with an independent existence.An entity may be an object with a physical existence (for example, a particular person, car,house, or employee) Each entity has attributes—the particular properties that describe it. For example, an EMPLOYEE entity may be described by the employee’s name, age, address, salary, and job.

rectangles: represent entity sets. Example:-

Where customer,account are entities. Attributes:- Each entity has attributes—the particular properties that describe it. For example, an EMPLOYEE entity may be described by the employee’s name, age, address,

ellipses: represent attributes. In the diagram above name, mob_no,city are the attributes of customer entity and Acc_no,balance are the attributes of account entity. Several types of attributes occur in the ER model: 1.simple versus composite 2.single valued versus multivalued 3. stored versus derived. 1.simple versus composite:- Attributes that are not divisible are called simple or atomic attributes. Composite attributes can form a hierarchy; for example, Street_address can be further subdivided into three simple component attributes: Number, Street, and Apartment_number 2. Single-Valued versus Multivalued Attributes. Most attributes have a single value for a particular entity; such attributes are called single-valued. For example,

Age is a single-valued attribute of a person.


Attribute can have a set of values for the same entity—for instance, a Colors attribute for a car can have many values such as blue, green. 3. In some cases, two (or more) attribute values are related—for example, the Age and Birth_date attributes of a person. For a particular person entity, the value of Age can be determined from the current (today’s) date and the value of that person’s Birth_date. The Age attribute is hence called a derived attribute and is said to be derivable from the Birth_date attribute, which is called a stored attribute.

Entity-relationship diagram

Rectangles represent entity sets. Diamonds represent relationship sets. Lines link attributes to entity sets and entity sets to relationship sets. Ellipses represent attributes Double ellipses represent multivalued attributes. Dashed ellipses denote derived attributes. Underline indicates primary key attributes Entity Set: The collection of all entities of a particular entity type in the database at any point in time is called an entity set. Example: set of specific person, company, event, plant Entity Sets customer and loan


Relationship set:-

A relationship is an association among several entities A relationship type R among n entity types E1, E2, ..., En defines a set of associations— or a relationship set—among entities from these entity types. fig 7.9


A relationship type of degree two is called binary, and one of degree three is called ternary. Cardinality Ratios(Mapping) for Binary Relationships. The cardinality ratio for a binary relationship specifies the maximum number of relationship instances that an entity can participate in. For a binary relationship set the mapping cardinality must be one of the following types: 1.One to one 2.One to many 3.Many to one 4.Many to many Diagram given below:-

(a) One to One (b) One to Many


(a)MANY to One (b)Many to Many

PARTICIPATION CONSTRAINTS:

The participation constraint specifies whether the existence of an entity depends on its being related to another entity via the relationship type. There are two types of participation constraints—total and partial.

Diag 7.12


Key Constraint:- An important constraint on the entities of an entity type is the key or

uniqueness constraint on attributes. A super key of an entity set is a set of one or more attributes whose values uniquely determine each entity. A candidate key of an entity set is a minimal super key Customer-id is candidate key of customer account-number is candidate key of account Although several candidate keys may exist, one of the candidate keys is selected to be the primary key. The combination of primary keys of the participating entity sets forms a super key of a relationship set. (customer-id, account-number) is the super key of depositor NOTE: this means a pair of entity sets can have at most one relationship in a particular relationship set. E.g. if we wish to track all access-dates to each account by each customer, we cannot assume a relationship for each access. For example, the Name attribute is a key of the COMPANY entity type. Sometimes several attributes are called as composite attribute which together form a key. In ER diagrammatic notation, each key attribute has its name underlined inside the oval, as illustrated in Figure 7.7(a). Fig7.7


weak entity type:- An entity type may also have no key, in which case it is called a weak entity type. Entities belonging to a weak entity type are identified by being related to specific entities from another entity type in combination with one of their attribute values. We call this other entity type the identifying or owner entity type,10 and we call the relationship type that relates a weak entity type to its owner the identifying relationship of the weak entity type. A weak entity type always has a total participation constraint (existence dependency) with respect to its identifying relationship because a weak entity cannot be identified without an owner entity. A weak entity type normally has a partial key, which is the attribute that can uniquely identify weak entities that are related to the same owner entity. The weak entity type and its identifying relationship are distinguished by surrounding their boxes and diamonds with double lines. The partial key attribute is underlined with a dashed or dotted line. An entity set that does not have a primary key is referred to as a weak entity set. Diag:-

Generalization and Aggregation: Generalization is a bottom-up approach in which two lower level entities combine to form a

higher level entity. In generalization, the higher level entity can also combine with other lower

level entity to make further higher level entity.


diag: generalization

diag:- Aggregation

Binary versus ternary:-

The degree of a relationship type is defined as the number of participating entity type. A relationship type of degree two is called binary and a relationship type of degree three is called ternary.

A ternary relationship is when three entities participate in the relationship.

For Example:

The University might need to record which teachers taught which subjects in which

Aggregration is a process when relation between two entity is treated as a single

entity. Here the relation between Center and Course, is acting as an Entity in relation

with Visitor.


Relational Data Model:- A domain D is a set of atomic values. By atomic we mean that each value in the domain is indivisible as far as the formal relational model is concerned. A common method of specifying a domain is to specify a data type. examples of domains follow: Social_security_numbers. The set of valid nine-digit Social Security numbers. (This is a unique identifier assigned to each person in the United States for employment, tax, and benefits purposes.) Names: The set of character strings that represent names of persons. Employee_ages. Possible ages of employees in a company; each must be an integer value between 15 and 80.

courses.

A binary relationship is when two entities participate and is the most common relationship degree


A data type or format is also specified for each domain.The data type for Employee_ages is an integer number between 15 and 80. A relation schema R, denoted by R(A1, A2, ...,An), is made up of a relation name R and a list of attributes, A1, A2, ..., An. Each attribute Ai is the name of a role played by some domain D in the relation schema R. D is called the domain of Ai and is denoted by dom(Ai). A relation student, which stores information about university students, would contain four attributes describing each student. as follows: STUDENT(Name, Ssn, Home_phone, Address) Using the data type of each attribute, the definition is sometimes written as: STUDENT(Name: string, Ssn: string, Home_phone: string, Address: string) A relation r of the relation schema R(A1, A2, ..., An), also denoted by r(R), is a set of n-tuples r = {t1, t2, ..., tm}. Each n-tuple t is an ordered list of n values t =<v1, v2, ..., vn>, where each value vi, 1 <i ≤n, is an element of dom (Ai) or is a special NULL value. Example:- Student relation with attributes and tuples Student

Name Ssn age

Tom 305-61-2435

19

Bob 381-62-1245 20

Where Name,Ssn,Age are attributes, Tom,Bob,305-61-2435,381-62-1245 ,19,20 are tuples Student is the relation name.

Relational Model Notation We will use the following notation in our presentation:

1. A relation schema R of degree n is denoted by R(A1, A2, ..., An). 2. The uppercase letters Q, R, S denote relation names. 3. The lowercase letters q, r, s denote relation states.


4. The letters t, u, v denote tuples. 5. The name of a relation schema such as STUDENT indicates the current set of tuples in

that relation whereas STUDENT(Name, Ssn, ...) refers only to the relation schema.

6.An attribute A can be qualified with the relation name R to which it belongs by using the dot notation R.A—for example, STUDENT.Name or STUDENT.Age. This is because the same name may be used for two attributes in different relations. However, all attribute names in a particular relation must be distinct. 7. An n-tuple t in a relation r(R) is denoted by t = <v1, v2, ..., vn>, where vi is the value corresponding to attribute Ai. The following notation refers to component values of tuples: 8.Both t [Ai] and t.Ai (and sometimes t[i]) refer to the value vi in t for attribute Ai. 9. Both t[Au, Aw, ..., Az] and t.(Au, Aw, ..., Az), where Au, Aw, ..., Az is a list of attributes from R, refer to the subtuple of values <vu, vw, ..., vz> from t corresponding to the attributes specified in the list. As an example, consider the tuple t = <‘Barbara Benson’, ‘533-69-1238’, 19> from the STUDENT relation. we have t [Name] = <‘Barbara Benson’>, and t [Ssn, Age] = <‘533-69-1238, 19>.

Characteristics of Relations:-

1.Ordering of Tuples in a Relation. A relation is defined as a set of tuples. when we display a relation as a table, the rows are displayed in a certain order. Many tuple orders can be specified on the same relation. For example, tuples in the STUDENT relation in could be ordered by values of Name, Ssn, Age, or some other attribute. The definition of a relation does not specify any order: There is no preference for one ordering over another. When a relation is implemented as a file or displayed as a table, a particular ordering may be specified on the records of the file or the rows of the table. 2.Ordering of Values within a Tuple and an Alternative Definition of a Relation The ordering of values in a tuple—and hence of attributes in a relation schema—is important. However, at a more abstract level, the order of attributes and their values is not that important as long as the correspondence between attributes and values is maintained. An alternative definition of a relation can be given, making the ordering of values in a tuple unnecessary.


When a relation is implemented as a file, the attributes are physically ordered as fields within a record. We will generally use the first definition of relation, where the attributes and the values within tuples are ordered, because it simplifies much of the notation. 3.Values and NULLs in the Tuples. Each value in a tuple is an atomic value; that is, it is not divisible into components within the framework of the basic relational model. Hence, composite and multivalued attributes are not allowed. This model is sometimes called the flat relational model. An important concept is that of NULL values, which are used to represent the values of attributes that may be unknown or may not apply to a tuple. A special value, called NULL, is used in these cases. For example, Another student has a NULL for home phone, presumably because either he does not have a home phone or he has one but we do not know it (value is unknown). In general, we can have several meanings for NULL values, such as value unknown, value exists but is not available, or attribute does not apply to this tuple (also known as value undefined). 4.Interpretation (Meaning) of a Relation. The relation schema can be interpreted as a declaration or a type of assertion. For example, STUDENT relation of that, in general, a student entity has a Name, Ssn, Home_phone, Address, Office_phone, Age, and Gpa. Each tuple in the relation can then be interpreted as a fact or a particular instance of the assertion. For example, the first tuple asserts the fact that there is a STUDENT whose Name is Benjamin Bayer, Ssn is 305-61-2435, Age is 19. An alternative interpretation of a relation schema is as a predicate; in this case, the values in each tuple are interpreted as values that satisfy the predicate. For example,the predicate STUDENT (Name, Ssn, ...) is true for the five tuples in relation STUDENT.

Relational Constraints:-

UNIQUE Constraint

The UNIQUE constraint is used to uniquely identify each record in a database. It requires that each value in a column should be unique,i.e. no 2 rows of same column should have duplicate values.

It provides you the guarantee for uniqueness in a column or set of columns and allows us to input the NULL values, unless there is not defined NOT NULL constraint for the same column.

As in UNIQUE constraint, there is a fact that there could be and number of rows which can include NULL for columns without NOT NULL constraints, reason because nulls are not considered equal to anything.

It can be defined at table level or at column level.

Example :


CREATE TABLE employee

(

EID int NOT NULL,

Name varchar(20) NOT NULL,

Address varchar(50),

Salary int,

);

The column “EmpID” cannot have null values and the values in it are distinct.

CHECK constraint :

The check constraint is used to check the value which is entered into a record. It is used to define condition which each row must satisfy.

If the condition value evaluates to fall, then the record violates the constraint and you cannot enter it into the table.

We cannot define check constraint in SQL view.

Syntax :

CREATE TABLE table_name

(

column1 datatype,

column2 datatype,

....

CONSTRAINT constraint_name CHECK

(column-name_contition));


The check constraint can be defined by a create table statement or alter table statement.

Primary key constraint

A primary key constraint is a field in a table which uniquely identifies each rows/records in a database table.

Characteristics of Primary Key :

Primary key constraint must contain unique values.

Primary key constraint column cannot have null values.

Table can have only one primary key.

If multiple fields are used as a primary key, then they are called as composite key.

Example :

CREATE TABLE employee

(

EmpID int NOT NULL,

Name varchar(30) NOT NULL,

Address varchar(50),

Salary int,

PRIMARY KEY (EmpID)

);

Primary key applied on EmpID column, therefore now the column cannot be left blank nor duplicate values can exist.

A primary key constraint keeps the attributes of UNIQUE Constraint in itself. A table can contain only one primary key constraint, but can have several many constraints.


Referential Integrity:- An integrity constraint (Ie) is a condition specified on a database schema and restricts the data that can be stored in an instance of the database. If a database instance satisfies all the integrity constraints specified on the database schema, it is a legal instance. A DBMS enforces integrity constraints, in that it permits only legal instances to be stored in the database. For referential integrity to hold in a relational database, any field in a table that is declared a foreign key can contain either a null value, or only values from a parent table's primary key or a candidate key.[2] In other words, when a foreign key value is used it must reference a valid, existing primary key in the parent table. Integrity constraints are specified and enforced at different times: When a database application is run, the DBMS checks for violations and disallows changes to the data that violate the specified ICs. Sometimes the information stored in a relation is linked to the information stored in another relation. If one of the relations is modified, the other must be checked, and perhaps modified, to keep the data consistent. An IC involving both relations must be specified if a DBMS is to make such checks. The most common IC involving two relations is a foreign key constraint. Fig3.4 referential integrity

NOT NULL Constraint

NOT NULL constraint restricts a column from having a NULL value. Once NOT NULL constraint is

applied to a column, you cannot pass a null value to that column. It enforces a column to

contain a proper value. One important point to note about NOT NULL constraint is that it

cannot be defined at table level.

Example using NOT NULL constraint

https://en.wikipedia.org/wiki/Relational_database

https://en.wikipedia.org/wiki/Table_(database)

https://en.wikipedia.org/wiki/Foreign_key

https://en.wikipedia.org/wiki/Primary_key

https://en.wikipedia.org/wiki/Candidate_key

https://en.wikipedia.org/wiki/Referential_integrity#cite_note-2


CREATE table Student(s_id int NOT NULL, Name varchar(60), Age int);

ER to TABLE

An entity set is mapped to a relation in a straightforward way: Each attribute of the entity set becomes an attribute of the table. Note that we know both the domain of each attribute and the (primary) key of an entity set. Consider the Employees entity set with attributes ssn, name, and lot shown in Figure 3.8.

Figure 3.8 The Employees Entity Set

ssn name lot I

231-31-5368 Smiley 22

131-24-3650 Smethurst 35

Figure 3.9 An Instance of the Employees Entity Set

The following SQL statement captures the preceding information, including the domain constraints and key information: CREATE TABLE Employees ( ssn CHAR(11), name CHAR(30) , lot INTEGER, PRIMARY KEY (ssn) )


Relationship to tables with constraint key If a relationship set involves n entity sets and some of them are linked via arrows in the ER diagram, the key for anyone of these m entity sets constitutes a key for the relation to which the relationship set is mapped. Hence we have m candidate keys, and one of these should be designated as the primary key.

The table corresponding to Manages has the attributes ssn, did, since. However, because each department has at most one manager, no two tuples can have the same did value but differ on the ssn value. A consequence of this observation is that did is itself a key for Manages. The Manages relation can be defined using the following SQL statement: CREATE TABLE Manages (ssn CHAR (11) , did INTEGER, since DATE, PRIMARY KEY (did), FOREIGN KEY (ssn) REFERENCES Employees, FOREIGN KEY (did~REFERENCES Departments) A second approach is to include the information about the relationship set in the table corresponding to the entity set with the key, taking advantage of the key constraint. This approach eliminates the need for a separate Manages relation, and queries asking for a department's manager can be answered without combining information from two relations. The only drawback to this approach is that space could be wasted if several departments have no managers. In this case the added fields would have to be filled with null values. The following SQL statement, defining a DepLMgr relation that captures the information in both Departments and Manages, illustrates the second approach


to translating relationship sets with key constraints: CREATE TABLE DepLMgr ( did INTEGER, dname CHAR(20), budget REAL, ssn CHAR (11) , since DATE, PRIMARY KEY (did), FOREIGN KEY (ssn) REFERENCES Employees) Note that ssn can take on null values.

Relationships to tables without key constraints To represent a relationship, we must be able to identify each participating entity and give values to the descriptive attributes of the relationship. Thus, the attributes of the relation include: • The primary key attributes of each participating entity set, as foreign key fields. • The descriptive attributes of the relationship set. The set of nondescriptive attributes is a superkey for the relation. If there are no key constraints ,this set of attributes is a candidate key.

Figure 3.11 The Reports_To Relationship Set role indicators supervisor and subordinate are used to create meaningful field names in the CREATE statement for the Reports..To table: CREATE TABLE Reports_To ( supervisor...ssn CHAR (11), subordinate...ssn CHAR (11) , PRIMARY KEY (supervisor_ssn,subordinate_ssn), FOREIGN KEY (supervisor...ssn) REFERENCES Employees(ssn),


FOREIGN KEY (subordinate...ssn) REFERENCES Employees(ssn) ) Observe that we need to explicitly name the referenced field of Employees because the field name differs from the name(s) of the referring field(s).


Documents

UNIT 1 INTRODUCTION TO DBMS - Nirmala Memorial · PDF fileUNIT 1 INTRODUCTION TO DBMS 8 Levels Of Abstraction:- Process of hiding irrelevant details from user is called data abstraction