UNIT 2

L.H: 6
Database System Concepts
and Architecture
 Database Models
  Types of DBMS

  Hierarchical Model/Database

  Network Model/Database

  Relational Model/Database

  Object-Oriented/Database

Set of rules and standard that define how the database

organizes/ store data
Hierarchical Model/Database
  Arranges records in hierarchy like an organizational
chart

  Each record type in this model is called a node or

segment

  A node represents a particular entity

  The top most node is called root. Each node is called

root. Each node is a subordinate of the node that is the
next higher level.
  This database model organizes data into a tree-like-
structure, with a single root, to which all the other data is
linked. The hierarchy starts from the Root data, and
expands like a tree, adding child nodes to the parent
nodes.
  In this model, a child node will only have a single parent
node.
  This model efficiently describes many real-world
relationships like index of a book, recipes etc.
  In hierarchical model, data is organized into tree-like
structure with one one-to-many relationship between two
different types of data, for example, one department can
have many courses, many professors and of-course many
students.
 Network Model/Database
  This is an extension of the Hierarchical model. In this model data
is organized more like a graph, and are allowed to have more than
one parent node.
  In this database model data is more related as more relationships
are established in this database model. Also, as the data is more
related, hence accessing the data is also easier and fast. This
database model was used to map many-to-many data relationships.
  This was the most widely used database model, before Relational
Model was introduced.
 Relational Model
  In this model, data is organized in two-dimensional tables and the
relationship is maintained by storing a common field.

  This model was introduced by E.F Codd in 1970, and since then
it has been the most widely used database model, infect, we can
say the only database model used around the world.

  The basic structure of data in the relational model is tables. All

the information related to a particular type is stored in rows of
that table.

  Hence, tables are also known as relations in relational model.

 Object Oriented Model
  This hybrid database model combines the simplicity of the relational
model with some of the advanced functionality of the object-
oriented database model. In essence, it allows designers to
incorporate objects into the familiar table structure.

  Object oriented databases are different from relational databases

which are table-oriented.

  Inheritance, polymorphism, overloading. object-identity,

encapsulation and information hiding with methods to provide an
interface to objects, are among the key concepts of object-oriented
programming that have found applications in data modeling.

  Languages and call interfaces include SQL3, vendor languages,

ODBC, JDBC, and proprietary call interfaces that are extensions of
the languages and interfaces used by the relational model.
Object Oriented Model
 Entity Relationship Model
  In this database model, relationships are created by dividing object of interest
into entity and its characteristics into attributes.

  Different entities are related using relationships.

  E-R Models are defined to represent the relationships into pictorial form to
make it easier for different stakeholders to understand.

  This model is good to design a database, which can then be turned into tables
in relational model(explained below).

  Let's take an example, If we have to design a School Database,

then Student will be an entity with attributes name, age, address etc.
As Address is generally complex, it can be another entity with attributes street
name, pincode, city etc, and there will be a relationship between them.

  Relationships can also be of different types. To learn about E-R Diagrams in

details, click on the link.
 Data Modeling
  Process of creating a data model for the data to be
stored in a database, conceptual representation of Data
objects, associations between different data objects, and
the rules, helps in the visual representation of data and
enforces business rules, regulatory compliances, and
government policies on the data
 Data Model
  An abstract model that organizes data description, data
semantics, and consistency constraints of data, emphasizes
on what data is needed and how it should be organized
instead of what operations will be performed on data, an
architect's building plan, which helps to build conceptual
models and set a relationship between data items

  Techniques are

Entity Relationship (E-R) Model

UML (Unified Modeling Language)

 Types of Data models
  Conceptual Data Model:

defines WHAT the system contains, typically created by Business

stakeholders and Data Architects, The purpose is to organize, scope
and define business concepts and rules.
  Logical Data Model:

Defines HOW the system should be implemented regardless of the

DBMS, typically created by Data Architects and Business Analysts,
The purpose is to developed technical map of rules and data
structures.
  Physical Data Model:

This Data Model describes HOW the system will be implemented

using a specific DBMS system, typically created by DBA and
developers, purpose is actual implementation of the database.
 Conceptual Data Model
  A Conceptual Data Model is an organized view of database
concepts and their relationships. The purpose of creating a
conceptual data model is to establish entities, their attributes,
and relationships.

  3 basic Conceptual Data Model are

Entity: A real-world thing

Attribute: Characteristics or properties of an entity

Relationship: Dependency or association between two entities

Data model example:

  Customer and Product are two entities. Customer number

and name are attributes of the Customer entity

  Product name and price are attributes of product entity

  Sale is the relationship between the customer and product

Conceptual Data Model

Characteristics of a conceptual data model

  Offers Organization-wide coverage of the business

concepts.

  This type of Data Models are designed and developed

for a business audience.

  The conceptual model is developed independently of

hardware specifications like data storage capacity,
location or software specifications like DBMS vendor
and technology. The focus is to represent data as a user
will see it in the "real world."
 Logical Data Model
  The Logical Data Model is used to define the structure of data
elements and to set relationships between them. The logical
data model adds further information to the conceptual data
model elements.

  The advantage of using a Logical data model is to provide a

foundation to form the base for the Physical model. However,
the modeling structure remains generic.
  At this Data Modeling level, no primary or secondary key is
defined. At this Data modeling level, you need to verify and
adjust the connector details that were set earlier for
relationships.

  Characteristics of a Logical data model

  Describes data needs for a single project but could integrate

with other logical data models based on the scope of the project.
  Designed and developed independently from the DBMS.

  Data attributes will have data types with exact precisions and
length.

  Normalization processes to the model is applied typically till

3NF.
 Physical Data Model
  A Physical Data Model describes a database-specific
implementation of the data model. It offers database
abstraction and helps generate the schema. This is because of
the richness of meta-data offered by a Physical Data Model.

  The physical data model also helps in visualizing database

structure by replicating database column keys, constraints,
indexes, triggers, and other RDBMS features.
 Characteristics of a physical data
model:
  The physical data model describes data need for a single project or
application though it maybe integrated with other physical data
models based on project scope.

  Data Model contains relationships between tables that which

addresses cardinality and null ability of the relationships.
  Developed for a specific version of a DBMS, location, data storage or
technology to be used in the project.

  Columns should have exact data types, lengths assigned and default
values.
  Primary and Foreign keys, views, indexes, access profiles, and
authorizations, etc. are defined.
 Advantages of Data model:
  The main goal of a designing data model is to make certain
that data objects offered by the functional team are represented
accurately.

  The data model should be detailed enough to be used for

building the physical database.
  The information in the data model can be used for defining the
relationship between tables, primary and foreign keys, and
stored procedures.

  Data Model helps business to communicate the within and

across organizations.

  Data model helps to documents data mappings in ETL process

  Help to recognize correct sources of data to populate the model

 Disadvantages of Data model:
  To develop Data model one should know physical data
stored characteristics.

  This is a navigational system produces complex

application development, management. Thus, it
requires a knowledge of the biographical truth.

  Even smaller change made in structure require

modification in the entire application.

  There is no set data manipulation language in DBMS.

 Database Language
  A DBMS has appropriate languages and interfaces to
express database queries and updates.

  Database languages can be used to read, store and

update the data in the database.
Types of Database Language
 Data Definition Language
  DDL stands for Data Definition Language. It is used to
define database structure or pattern.
  It is used to create schema, tables, indexes, constraints,
etc. in the database.
  Using the DDL statements, you can create the skeleton
of the database.
  Data definition language is used to store the
information of metadata like the number of tables and
schemas, their names, indexes, columns in each table,
constraints, etc.
Here are some tasks that come under DDL:

  Create: It is used to create objects in the database.

  Alter: It is used to alter the structure of the database.

  Drop: It is used to delete objects from the database.

  Truncate: It is used to remove all records from a table.

  Rename: It is used to rename an object.

  Comment: It is used to comment on the data dictionary.

 Data Manipulation Language
  DML stands for Data Manipulation Language. It is used
for accessing and manipulating data in a database. It
handles user requests.
Here are some tasks that come under DML:
  Select: It is used to retrieve data from a database.
  Insert: It is used to insert data into a table.
  Update: It is used to update existing data within a table.
  Delete: It is used to delete all records from a table.
  Merge: It performs UPSERT operation, i.e., insert or
update operations.
  Call: It is used to call a structured query language or a
Java subprogram.
  Explain Plan: It has the parameter of explaining data.
  Lock Table: It controls concurrency.
 Data Control Language
  DCL stands for Data Control Language. It is used to retrieve the stored
or saved data.

  The DCL execution is transactional. It also has rollback parameters.

  (But in Oracle database, the execution of data control language does not
have the feature of rolling back.)

Here are some tasks that come under DCL:

  Grant: It is used to give user access privileges to a database.

  Revoke: It is used to take back permissions from the user.

There are the following operations which have the authorization of Revoke:

  CONNECT, INSERT, USAGE, EXECUTE, DELETE, UPDATE and

SELECT.
 Transaction Control Language

  TCL is used to run the changes made by the DML

statement. TCL can be grouped into a logical
transaction.

  Here are some tasks that come under TCL:

  Commit: It is used to save the transaction on the

database.

  Rollback: It is used to restore the database to original

since the last Commit.
 Database Users and Administrators
Database Users
  Database users are the one who really use and take the
benefits of database. There will be different types of users
depending on their need and way of accessing the database.

  End Users

End users are the people whose jobs require access to a

database for querying, updating and generating reports.

  Application Programmers

The application user is someone who accesses an existing

application program to perform daily tasks.
   Sophisticated user

Sophisticated users are those who have their own way of accessing the
database. This means they do not use the application program provided in
the system. Instead, they might define their own application or describe
their need directly by using query languages. These specialized users
maintain their personal databases by using ready-made program packages
that provide easy-to-use menu driven commands, such as MS Access

  Application Programmers

These users implement specific application programs to access the stored

data. They must be familiar with the DBMSs to accomplish their task.

  Database Administrators (DBA)

This may be one person or a group of people in an organization responsible

for authorizing access to the database, monitoring its use and managing all
of the resources to support the use of the entire database system.
 Database Administrator
  Specialized computer systems administrators

  Maintains a successful database environment by

directing or performing all related activities to keep the
data secure.

  Responsibility of DBA professional is to maintain data

integrity.

  Make secure data from unauthorized access but provide

and access is available to users.
A DBA has many responsibilities. A good performing database is
in the hands of DBA.

  Installing and upgrading the DBMS Servers

  Design and implementation

  Performance tuning

  Migrate database servers

  Backup and Recovery

  Security

  Documentation
 ER-Model
The main data objects are termed as Entities, with their details
defined as attributes, some of these attributes are important and
are used to identity the entity, and different entities are related
using relationships.
ER Model: Entity and Entity Set
  Considering the above example, Student is an
entity, Teacher is an entity, similarly, Class, Subject etc are
also entities.
  An Entity is generally a real-world object which has
characteristics and holds relationships in a DBMS.
  If a Student is an Entity, then the complete dataset of all the
students will be the Entity Set
 ER Model: Attributes

  If a Student is an Entity, then student's roll no., student's name,

student's age, student's gender etc will be its attributes.

  An attribute can be of many types, here are different types of attributes

defined in ER database model:

  Simple attribute: The attributes with values that are atomic and cannot be
broken down further are simple attributes. For example, student's age.

  Composite attribute: A composite attribute is made up of more than one

simple attribute. For example, student's address will contain, house
no., street name, pincode etc.

  Derived attribute: These are the attributes which are not present in the
whole database management system, but are derived using other attributes.
For example, average age of students in a class.

  Single-valued attribute: As the name suggests, they have a single value.

  Multi-valued attribute: And, they can have multiple values.

 ER Model: Keys

  If the attribute roll no. can uniquely identify a student

entity, amongst all the students, then the attribute roll
no. will be said to be a key.

  Following are the types of Keys:

  Super Key

  Candidate Key

  Primary Key
 ER Model: Relationships

  When an Entity is related to another Entity, they are

said to have a relationship. For example, A Class Entity
is related to Student entity, because students study in
classes, hence this is a relationship.

  Depending upon the number of entities involved,

a degree is assigned to relationships.

  For example, if 2 entities are involved, it is said to

be Binary relationship, if 3 entities are involved, it is
said to be Ternary relationship, and so on.
  Cardinality in DBMS

  In terms of data models, cardinality refers to the relationship

between two tables. Relationship can be of four types as we
have already seen in Entity relationship guide.
  One to One – A single row of first table associates with single
row of second table. For example, a relationship between
person and passport table is one to one because a person can
have only one passport and a passport can be assigned to only
one person.
  One to Many – A single row of first table associates with
more than one rows of second table. For example,
relationship between customer and order table is one to many
because a customer can place many orders but a order can be
placed by a single customer alone.
  Many to One – Many rows of first table associate with a
single row of second table. For example, relationship
between student and university is many to one because
a university can have many students but a student can
only study only in single university at a time.

  Many to Many – Many rows of first table associate with

many rows of second table. For example, relationship
between student and course table is many to many
because a student can take many courses at a time and
a course can be assigned to many students.
 Participation Constraints E-R
  The participation constraint specifies the number of
instances of an entity can participate in a
relationship set.
  The participation constraint specifies whether the
existence of an entity depends on its being related to
another entity via the relationship type. This
constraint specifies the minimum number of
relationship instances that each entity can participate
in.
  This constraint specifies the number of instances of
an entity that are participating in the relationship
type.
   There are two types of Participation constraint:
  Total participation
  Partial participation

Total participation constraint

  It specifies that each entity present in the entity set must
mandatorily participate in at least one relationship instance
of that relationship set,for this reason, it is also called as
mandatory participation
  It is represented using a double line between the entity set
and relationship set

Example of total participation constraint

  It specifies that each student must be enrolled in at least one
course where the “student” is the entity set and relationship
“enrolled in” signifies total participation
  It means that every student must have enrolled at least in
one course
  Total Participation is when each entity in the entity set
occurs in at least one relationship in that relationship
set.

  For instance, consider the relationship borrower

between customers and loans. A double line from loan
to borrower, as shown in figure below indicates that
each loan must have at least one associated customer.
Partial participation
  It specifies that each entity in the entity set may or may
not participate in the relationship instance of the
relationship set, is also called as optional participation
  It is represented using a single line between the entity
set and relationship set in the ER diagram

Example of partial participation

  A single line between the entities i.e courses and
enrolled in a relationship signifies the partial
participation, which means there might be some
courses where enrollments are not made i.e enrollments
are optional in that case
  Partial Participation is when each entity in the entity
set may not occur in at least one relationship in that
relationship set. For instance, If a company policy
states that employee (manager) must manage a
department, However every employee may not
manage a department, so the participation of
EMPLOYEE in the MANAGES relationship type is
partial, meaning that some or part of the set of
employee entities are related to some department
entity via MANAGES, but not necessarily all.

  Partial Participation is represented by single line

connecting entities in relationship Co
 Entity Relationship Diagram (ER
Diagram)
  ER Diagram stands for Entity Relationship Diagram,
also known, as ERD is a diagram that displays the
relationship of entity sets stored in a database.
  ER diagrams help to explain the logical structure of
databases. ER diagrams are created based on three
basic concepts: entities, attributes and relationships.
  ER Diagrams contain different symbols that use
rectangles to represent entities, ovals to define
attributes and diamond shapes to represent
relationships.
  An Entity–relationship model (ER
model) describes the structure of a database
with the help of a diagram, which is known
as Entity Relationship Diagram (ER
Diagram).
  An ER model is a design or blueprint of a
database that can later be implemented as a
database. The main components of E-R model
are: entity set and relationship set.
 Sample of E-R Diagram
Rectangle: Represents Entity sets.
Ellipses: Attributes
Diamonds: Relationship Set
Lines: They link attributes to Entity Sets and Entity sets to
Relationship Set
Double Ellipses: Multivalued Attributes
Dashed Ellipses: Derived Attributes
Double Rectangles: Weak Entity Sets
Double Lines: Total participation of an entity in a relationship set
 ER Diagram Symbols and Notations
  Rectangle: Represents Entity sets.
Ellipses: Attributes
Diamonds: Relationship Set
Lines: They link attributes to Entity Sets and Entity sets to Relationship
Set
Double Ellipses: Multivalued Attributes
Dashed Ellipses: Derived Attributes
Double Rectangles: Weak Entity Sets
Double Lines: Total participation of an entity in a relationship set
ER diagram has three main components:
1. Entity
2. Attribute
3. Relationship
 1. Entity
  An entity is an object or component of data. An entity is
represented as rectangle in an ER diagram.
  Entities, which are represented by rectangles. An entity is
an object or concept about which you want to store
information.

  In the following ER diagram we have two entities Student

and College and these two entities have many to one
relationship as many students study in a single college. We
will read more about relationships later, for now focus on
entities.
 Week Entity
  An entity that cannot be uniquely identified by its own
attributes and relies on the relationship with other entity is
called weak entity.

  The weak entity is represented by a double rectangle. For

example – a bank account cannot be uniquely identified
without knowing the bank to which the account belongs, so
bank account is a weak entity.

  A weak entity is an entity that must defined by a foreign key

relationship with another entity as it cannot be uniquely
identified by its own attributes alone.
 2. Attribute
  An attribute describes the property of an entity. An attribute
is represented as Oval in an ER diagram. A key attribute is
the unique, distinguishing characteristic of the entity.
  An attribute is a property, trait, or characteristic of an entity,
relationship, or another attribute. For example, the attribute
Inventory Item Name is an attribute of the entity Inventory
Item.
  There are four types of attributes:
1. Key attribute
2. Composite attribute
3. Multivalued attribute
4. Derived attribute
Attributes in ER diagrams, Note that an attribute can
have its own attributes ( composite attribute )
 Key attribute:
  A key attribute can uniquely identify an entity from an entity
set. For example, student roll number can uniquely identify
a student from a set of students. Key attribute is represented
by oval same as other attributes however the text of key
attribute is underlined
 Composite attribute:
  An attribute that is a combination of other attributes is
known as composite attribute. For example, In student
entity, the student address is a composite attribute as an
address is composed of other attributes such as pin code,
state, country.
 Multivalued attribute:
  An attribute that can hold multiple values is known as
multivalued attribute. It is represented with double ovals in
an ER Diagram. For example – A person can have more
than one phone numbers so the phone number attribute is
multivalued.

  If an attribute can have more than one value it is called

a multi-valued attribute. It is important to note that this is
different from an attribute having its own attributes.

Example of a multivalued attribute

 Derived attribute:
  A derived attribute is one whose value is dynamic and derived
from another attribute. It is represented by dashed oval in an
ER Diagram. For example – Person age is a derived attribute as
it changes over time and can be derived from another attribute
(Date of birth).
  An attribute based on another attribute. This is found rarely in
ER diagrams. For example, for a circle, the area can be derived
from the radius.

Derived Attribute in ER diagrams

  E-R diagram with multivalued and derived attributes:
 Relationship
  A Relationship describes how entities interact. It
defines the numerical attributes of the relationship
between two entities or entity sets.
  For example, the entity “Carpenter” may be related to
the entity “table” by the relationship “builds” or
“makes”. Relationships are represented by diamond
shapes and are labeled using verbs.
  A relationship is represented by diamond shape in ER
diagram, it shows the relationship among entities.
There are four types of relationships:
1. One to One
2. One to Many
3. Many to One
4. Many to Many
 1. One to One Relationship
  When a single instance of an entity is associated with a single
instance of another entity then it is called one to one
relationship. For example, a person has only one passport
and a passport is given to one person.

  One entity from entity set X can be associated with at most

one entity of entity set Y and vice versa. Example: One
student can register for numerous courses. However, all those
courses have a single line back to that one student.

 
 One to Many Relationship
  When a single instance of an entity is associated with more
than one instances of another entity then it is called one to
many relationship. For example – a customer can place many
orders but a order cannot be placed by many customers.

  One entity from entity set X can be associated with multiple

entities of entity set Y, but an entity from entity set Y can be
associated with at least one entity. For example, one class is
consisting of multiple students.
 Many to One Relationship
  When more than one instances of an entity is associated with a
single instance of another entity then it is called many to one
relationship. For example – many students can study in a single
college but a student cannot study in many colleges at the same
time.

  More than one entity from entity set X can be associated with at
most one entity of entity set Y. However, an entity from entity
set Y may or may not be associated with more than one entity
from entity set X. For example, many students belong to the
same class.

 
 Many to Many Relationship
  When more than one instances of an entity is associated with
more than one instances of another entity then it is called many
to many relationship. For example, a can be assigned to many
projects and a project can be assigned to many students.

  One entity from X can be associated with more than one entity
from Y and vice versa.For example, Students as a group are
associated with multiple faculty members, and faculty members
can be associated with multiple students.
 How to Draw ER Diagrams
  Identify all the entities in the system. An entity should
appear only once in a particular diagram. Create
rectangles for all entities and name them properly.

  Identify relationships between entities. Connect them

using a line and add a diamond in the middle
describing the relationship.

  Add attributes for entities. Give meaningful attribute

names so they can be understood easily.
 What is an Entity Relationship Diagram (ERD)?

  An entity relationship diagram (ERD) shows the

relationships of entity sets stored in a database. An
entity in this context is an object, a component of data.
An entity set is a collection of similar entities. These
entities can have attributes that define its properties.

  By defining the entities, their attributes, and showing

the relationships between them, an ER diagram
illustrates the logical structure of databases. ER
diagrams are used to sketch out the design of a
database.
 DBMS architecture and Data
Independence
  The Three-Schema Architecture

  The goal of the three-schema architecture, is to separate

the user applications from the physical database. In this
architecture, schemas can be defined at the following
three levels:
1.  The internal level has an internal schema, which
describes the physical storage structure of the database.
The internal schema uses a physical data model and
describes the complete details of data storage and
access paths for the database.
2.  The conceptual level has a conceptual schema, which
describes the structure of the whole database for a
community of users. The conceptual schema hides the
details of physical storage structures and concentrates
on describing entities, data types, relationships, user
operations, and constraints. Usually, a representational
data model is used to describe the conceptual schema
w h e n a d a t a b a s e s y s t e m i s i mp l e m e n t e d .
This implementation conceptual schema is often based
on a conceptual schema design in a high-level data
model.
3.  The external or view level includes a number
of external schemas or user views. Each external
schema describes the part of the database that a
particular user group is interested in and hides the rest
of the database from that user group. As in the
previous level, each external schema is typically
implemented using a representational data model,
possibly based on an external schema design in a high-
level data model.
 Data Dictionary
  A data dictionary is a collection of the names, definitions, and
attributes for data elements and models. The data in a data
dictionary is the metadata about the database. These elements
are then used as part of a database, research project, or
information system.
  It describes the meanings and purposes of data elements within
the context of a project, and provides guidance on
interpretation, accepted meanings and representation. A Data
Dictionary also provides metadata about data elements. The
metadata included in a Data Dictionary can assist in defining
the scope and characteristics of data elements, as well the rules
for their usage and application.
  These are some of the most common elements used
in a data dictionary, though there’s variation:
  Attribute name
  Attribute type
  Entity-relationship
  Reference data
  Rules for validation, schema, or data quality
  Detailed properties of data elements
  Physical information about where data is stored
 Why Use a Data Dictionary?
  Data Dictionaries are useful for a number of reasons.
In short, they:
  Assist in avoiding data inconsistencies across a project

  Help define conventions that are to be used across a

project
  Provide consistency in the collection and use of data
across multiple members of a research team
  Make data easier to analyze

  Enforce the use of Data Standards

 Types of data dictionary
1. Active Data Dictionary

  An active data dictionary is tied to a specific database,

which makes data transference a challenge, but it updates
automatically with the data management system.

  If the structure of the database or its specifications changes

at any point of time, it should be reflected in the data
dictionary. This is the responsibility of the database
management system in which the data dictionary resides.

  So, the data dictionary is automatically updated by the

database management system when any changes are made in
the database. This is known as an active data dictionary as it
is self updating.
 Passive Data Dictionary
  A passive data dictionary isn’t tied to a particular
database or server, but it also must be manually
maintained to prevent metadata from being out of
sync.
  This is not as useful or easy to handle as an active data
dictionary. A passive data dictionary is maintained
separately to the database whose contents are stored in
the dictionary. That means that if the database is
modified the database dictionary is not automatically
updated as in the case of Active Data Dictionary.
  So, the passive data dictionary has to be manually
updated to match the database. This needs careful
handling or else the database and data dictionary are
out of sync.
 Primary Key
  The primary key is a unique or non-null key that uniquely
identifies every record in a table or relation. Each database
needs a unique identifier for every row of a table, and the
primary key plays a vital role in identifying rows in the table
uniquely. The primary key column can't store duplicate
values. It is also called a minimal super key; therefore, we
cannot specify more than one primary key in any
relationship.
  For example, we have a table named customer with
attributes such as ID, Name, and City. Only the ID
column can never contain duplicate and NULL values
because each customer has a unique identification number.
This feature helps to identify each record in the database
uniquely. Hence, we can make the ID attribute a primary
key.
 Foreign Key
  The foreign key is a group of one or more columns in a
database to uniquely identify another database record in some
other table to maintain the referential integrity.

  It is also known as the referencing key that establishes a

relationship between two different tables in a database. A
foreign key always matches the primary key column in another
table. It means a foreign key column in one table refers to the
primary key column of another table.

  A foreign key is beneficial in relational database

normalization, especially when we need to access records from
other tables.
  A foreign key creates a parent-child relationship with the
tables where the parent table holds the initial column
values, and the child table references the parent column
values. We can achieve this relationship only when the
foreign key constraint is found on the child table.

  For example, we have a table named contact with

attributes such as ID, Customer_Id, Customer_Info, and
Type. Here we can make the Customer_Id column a
foreign key.