What is a Record in DBMS?

A "record" in Database Management Systems (DBMS) is an assemblage of data objects arranged in a

table, each pertaining to a certain topic or theme. For example, student records in educational
institutions are kept according to enrollment information in different departments and academic
achievement. Exam dates, course materials, and any penalties or disciplinary measures taken are
usually included in these records.

These entries are generally spread across several tables for effective administration and retrieval and
are kept in large databases. Well-known spreadsheet programs like Google Sheets and Microsoft
Excel may also be used as platforms for managing these kinds of documents. This is an illustration of
their structure:

Student ID Name Department Grade Exam Date

1 John Physics A 10-03-2024

2 Pranav Chemistry A+ 11-03-2024

3 Brown Biology B- 12-03-2024

4 Tim David Maths B+ 20-03-2024

Each row in this depiction represents a student record, while the columns include information about
the student, including name, department, grade, exam date, and student ID.

What are the Examples of Records in DBMS?

Records in Database Management Systems (DBMS) are groups of linked data objects arranged in
tables. These documents function as a container for data on particular things or entities. The
following are some typical DBMS records from various domains:

1. Employee Records: Each employee's record in a human resources database may contain
information about them, including their name, department, job, employment date, pay
scale, and contact details.

2. Reservation Records: Databases used in the hospitality or transportation industries manage

booking IDs, client information, dates, hours, preferences, and payment status.

3. Medical Records: Healthcare databases

4. contain patient records containing data such as patient IDs, medical histories, diagnoses,
treatments, prescriptions, test results, and appointment schedules.

5. Inventory Records: Store information on products, including SKU (Stock Keeping Unit)
numbers, descriptions, and quantities in stock, as well as information about suppliers, prices,
and locations, in databases used in manufacturing or retail settings.
 6. Library Records: Library databases store titles, authors, ISBNs (International Standard Book
Numbers), genres, publishing dates, availability statuses, and borrower information.

7. Event Records: Dates, locations, organizers, participants, agendas, feedback, and event IDs
are all tracked by event management systems.

8. Financial Records: Information on transactions, invoices, receipts, account balances, income

statements, and balance sheets are all kept in accounting databases.

What are the Benefits of Using a Database?

There are several advantages to using a database for data management, storage, and retrieval. Here
are a few main benefits:

1. Data Integrity: Databases impose data integrity requirements, such as unique keys, foreign
key connections, and data validation criteria, to preserve the correctness and dependability
of stored data.

2. Data Standardisation and uniformity: Databases enforce uniform data structures and
formats, helping to minimize mistakes caused by inconsistent data and encourage uniformity
between applications.

3. Effective Data Retrieval: Instead of sifting through massive amounts of unstructured data,
users may rapidly obtain specified data from databases by utilizing queries and filters.
Techniques for indexing and optimization speed up retrieval.

4. Scalability: To handle increasing data volumes and user demands, databases can expand
vertically (by adding additional resources to a single server) or horizontally (by spreading
data across numerous servers).

5. Concurrency Control: Databases use locks and transactions to allow several users to access
data concurrently while maintaining data consistency. This facilitates teamwork and guards
against data tampering.

6. Data centralization: Databases centralize data storage by allowing several users and
applications to access and edit data from a single, unified source. This ensures data integrity
and removes redundancy.

7. Data Security: Databases provide security features, including auditing, encryption,

authentication, and authorization, to prevent unauthorized access, manipulation, or theft of
sensitive data.

8. Data Recovery and Backup: Databases come with tools to help you routinely back up your
data and recover it in case of data corruption, hardware malfunctions, or natural
catastrophes. This guarantees business continuity and data availability.

9. Data Analysis and Reporting: Databases provide sophisticated queries, analytics, and
reporting features that help users understand data, draw conclusions, and produce insightful
reports.

To sum up, records are fundamental building blocks of data storage and organization and are an
integral part of database management systems. Designing successful databases and using them to
store, retrieve, and manage data efficiently requires an understanding of the structure and function
of records. Anyone working with data in a digital environment has to have a firm knowledge of
records, whether they are creating a new database schema or querying an already-existing database.

Difference between Super key and Candidate key?

Introduction:

In this article, we will explain the differences between the super key and candidate key in detail. Both
keys are related to ensuring data uniqueness in a table and retrieving records from a table. They both
contain NULL values. But there are many differences between them. Let's understand each key one
by one and then we will understand their differences.

What do you mean by Super Key?

A super key is a combination of either one or more columns that can uniquely identify each row in a
table. No two rows in a super key can have identical values for the attributes that make up a super
key. For example: In a student table ,Student_rollno, Student_Email makes super keys.

Following are the various key features or properties of a Super Key

ADVERTISEMENT

ADVERTISEMENT

o Each super key is not a candidate key.

o A super key can contain any combination of columns that guarantees row uniqueness.

o Every relation should have atleast one super key.

o All attributes of a relation taken together are a super key because each row in a relation is
unique.

What do you mean by Candidate Key?

It represents a set of attributes in a table which uniquely identifies every row of the table. The value
of the candidate key must be unique for all rows in the table. A relation can have more than one
candidate key. For example: In a student table Student_rollno makes a candidate key.

Following are the various key features or properties of a Candidate Key

o Candidate key attributes must ensure that no two rows have the same value in a table.

o Uniqueness of each attribute key in the candidate key is required to maintain the attribute.

o A relation must have atleast one candidate key.

Following are the tabular differences between super key and candidate key on the basis of
comparison.

Basis Super Key Candidate Key

 1. Unique A super key contains multiple columns where all It uniquely identifies each row in a
columns must be selected to join the two tables. table so we can demonstrate it as a
single identifier.

2. Count Super keys are more than in number as compared Candidate keys are less in numbers.
to candidate keys.

3. Combination The combinations of super keys become The combinations of candidate keys
of keys candidate keys. become the primary key.

4. Redundant A super key can contain redundant attributes. A candidate key cannot contain
redundant attributes.

5. SQL It is a Data Manipulation Language It is Data Definition Language

Language

6. Minimal It may or may not contain a minimal super key. It must contain a minimal key.

7. Irreducible It is a combination of a set of columns that The attributes which are used to form
uniquely identifies a row within a table but may the keys should not be broken down
or may contain irreducible property. into sub parts.

What Is a Field in a Database?

Fields in databases refer to a single piece of information or data value that is stored within a record
or row. Fields act as containers that hold data of a particular type, allowing for efficient organization
and retrieval of information.

Fields represent a specific attribute of an entity or object, such as a customer's name, age, email
address, or product price.

Ultimately, fields help you maintain all the information you need about customers, clients, and their
data.

Check out our article "What Is a Database?" to learn more about databases.

How Are Fields in Databases Used?

Fields in databases are essential for organizing and managing data effectively. They provide structure
by defining specific attributes of entities, such as a customer's name or product price.

Fields ensure data integrity by validating information and enforcing rules. They also enable users to
extract specific data through queries and filters, allowing for targeted searches and analysis.
Ultimately, fields help you sort, filter, and organize your data so that you can access your data by
categories or topics.

In summary, fields play a vital role in organizing, validating, and retrieving data within a database.

What Types of Fields Are in Databases?

Databases support various types of fields, each tailored to accommodate different types of data.
Some common field types include:

 Text Fields: These fields store textual data such as names, addresses, descriptions, or any
form of alphanumeric information.

 Numeric Fields: Numeric fields are used for storing numerical values, including integers and
even currency values. Numeric fields also allow for formulas to help you perform calculations
within your database.

 Date and Time Fields: Date and time fields are designed to record the dates of transactions,
project deadlines, scheduled events, and more.

 Boolean Fields: Boolean fields are essentially check boxes, which you can turn On/Off for
different values. They are useful for storing conditions or flags that determine the state of a
particular attribute.

Difference between E-R Model and Relational Model in DBMS

Last Updated : 11 Dec, 2023

In database management systems (DBMS), two key methods are the Relational model and the Entity-
Relationship (E-R) model. Each has a specific function in the development and operation of
databases. While the Relational model provides the practical structure for organizing and managing
data in relational databases, the E-R model concentrates on offering a conceptual framework for
comprehending the relationships between entities.

The E-R model and the Relational model are two types of data models present in DBMS. Let’s have a
brief look at them:

E-R Model

The E-R model stands for the Entity-Relationship model. ER Model is used to model the logical view
of the system from a data perspective which consists of these components: Entity, Entity Type, Entity
Set. An Entity may be an object with a physical existence – a particular person, car, house, or
employee – or it may be an object with a conceptual existence – a company, a job, or a university
course. An Entity is an object of Entity Type and a set of all entities is called an entity set. e.g.; E1 is
an entity having Entity Type Student and a set of all students is called Entity Set. An Entity Type
defines a collection of similar entities and a set of all entities is called an entity set.
Relational model

The Relational Model was proposed by E.F. Codd to model data in the form of relations or tables.
After designing the conceptual model of the Database using an ER diagram, we need to convert the
conceptual model into a relational model that can be implemented using any RDBMS language like
Oracle SQL, MySQL, etc. Consider a relation STUDENT with attributes ROLL_NO, NAME, ADDRESS,
PHONE, and AGE shown in Table 1. STUDENT

ROLL_NO NAME ADDRESS PHONE AGE

1 RAM DELHI 9455123451 18

2 RAMESH GURGAON 9652431543 18

3 SUJIT ROHTAK 9156253131 20

4 SURESH DELHI 18

Differences between ER model and Reational model

Let’s see the difference between ER model and relational model:

ER model Relational model

Developed by Peter Chen in 1976. Developed by E.F. Codd in 1970.

ER model is the high level or conceptual It is the representational or implementation

model. model.

It is used by people who don’t know how

It is used by programmers.
database is implemented.

It represents collection of entities and It represent data in the form of tables and
describes relationship between them. describes relationship between them.

It consists of components like Entity, Entity It consists of components like domain,

Type, Entity Set. attributes, tuples.
ER model Relational model

It is easy to understand the relationship It is less easy to derive the relationship

between entities. between different tables.

It describes cardinality. It does not describe cardinality.

Relational model defines dependencies in

E-R model does not define data dependencies.
tables.

E-R model represents relationships as Relational model represents relationships as

associations. join tables.

E-R model is more granular in terms of data

Relational model is less granular.
representation.

E-R model is more flexible than the relational Relational model is less flexible than E-R
model. model.

E-R model does not involve normalization. Relational model involves normalization.

E-R model use case is useful for initial planning Relational model use case is useful for
and design. implementation and maintenance

Some of the popular Language and Notations

used-
Some of the popular Language and Notations
 Chen used-

 UML  SQL

 Crow’s foot  MySQL

 Bachman and others.

Conclusion

The Relational model is a practical implementation that uses tables for data storage, whereas the E-R
model is a high-level conceptual tool for visualizing entities and relationships. Relational offers the
framework for database systems, combining conceptual clarity with effective implementation,
whereas E-R helps with design.

Introduction of ER Model

Peter Chen developed the ER diagram in 1976 .The ER model was created to provide a simple and
understandable model for representing the structure and logic of databases. It has since evolved into
variations such as the Enhanced ER Model and the Object Relationship Model

The Entity Relational Model is a model for identifying entities to be represented in the database and
representation of how those entities are related. The ER data model specifies enterprise schema that
represents the overall logical structure of a database graphically.

The Entity Relationship Diagram explains the relationship among the entities present in the database.
ER models are used to model real-world objects like a person, a car, or a company and the relation
between these real-world objects. In short, the ER Diagram is the structural format of the database.

Why Use ER Diagrams In DBMS?

 ER diagrams are used to represent the E-R model in a database, which makes them easy to
convert into relations (tables).

 ER diagrams provide the purpose of real-world modeling of objects which makes them
intently useful.

 ER diagrams require no technical knowledge and no hardware support.

 These diagrams are very easy to understand and easy to create even for a naive user.

 It gives a standard solution for visualizing the data logically.

Symbols Used in ER Model

ER Model is used to model the logical view of the system from a data perspective which consists of
these symbols:

 Rectangles: Rectangles represent Entities in the ER Model.

 Ellipses: Ellipses represent Attributes in the ER Model.

 Diamond: Diamonds represent Relationships among Entities.

 Lines: Lines represent attributes to entities and entity sets with other relationship types.

 Double Ellipse: Double Ellipses represent Multi-Valued Attributes.

 Double Rectangle: Double Rectangle represents a Weak Entity.

Symbols used in ER Diagram

Components of ER Diagram

ER Model consists Entities, Attributes, and Relationships among Entities in a Database System.

Entity

An Entity may be an object with a physical existence – a particular person, car, house, or employee –
or it may be an object with a conceptual existence – a company, a job, or a university course.

Entity are of two types

1.Tangible Entity – Which can be touched like car , person etc.

2.Non – tangible Entity – Which can’t be touched like air , bank account etc.

Entity Set: An Entity is an object of Entity Type and a set of all entities is called an entity set. For
Example, E1 is an entity having Entity Type Student and the set of all students is called Entity Set. In
ER diagram, Entity Type is represented as:
Entity Set

We can represent the entity set in ER Diagram but can’t represent entity in ER Diagram because
entity is row and column in the relation and ER Diagram is graphical representation of data.

1. Strong Entity

A Strong Entity is a type of entity that has a key Attribute. Strong Entity does not depend on other
Entity in the Schema. It has a primary key, that helps in identifying it uniquely, and it is represented
by a rectangle. These are called Strong Entity Types.

2. Weak Entity

An Entity type has a key attribute that uniquely identifies each entity in the entity set. But some
entity type exists for which key attributes can’t be defined. These are called Weak Entity types.

For Example, A company may store the information of dependents (Parents, Children, Spouse) of an
Employee. But the dependents can’t exist without the employee. So Dependent will be a Weak
Entity Type and Employee will be Identifying Entity type for Dependent, which means it is Strong
Entity Type.

A weak entity type is represented by a Double Rectangle. The participation of weak entity types is
always total. The relationship between the weak entity type and its identifying strong entity type is
called identifying relationship and it is represented by a double diamond.

Strong Entity and Weak Entity

Attributes

Attributes are the properties that define the entity type. For example, Roll_No, Name, DOB, Age,
Address, and Mobile_No are the attributes that define entity type Student. In ER diagram, the
attribute is represented by an oval.
Attribute

1. Key Attribute

The attribute which uniquely identifies each entity in the entity set is called the key attribute. For
example, Roll_No will be unique for each student. In ER diagram, the key attribute is represented by
an oval with underlying lines.

Key Attribute

2. Composite Attribute

An attribute composed of many other attributes is called a composite attribute. For example, the
Address attribute of the student Entity type consists of Street, City, State, and Country. In ER diagram,
the composite attribute is represented by an oval comprising of ovals.

Composite Attribute

3. Multivalued Attribute

An attribute consisting of more than one value for a given entity. For example, Phone_No (can be
more than one for a given student). In ER diagram, a multivalued attribute is represented by a double
oval.
Multivalued Attribute

4. Derived Attribute

An attribute that can be derived from other attributes of the entity type is known as a derived
attribute. e.g.; Age (can be derived from DOB). In ER diagram, the derived attribute is represented by
a dashed oval.

Derived Attribute

The Complete Entity Type Student with its Attributes can be represented as:

Entity and Attributes

Relationship Type and Relationship Set

A Relationship Type represents the association between entity types. For example, ‘Enrolled in’ is a
relationship type that exists between entity type Student and Course. In ER diagram, the relationship
type is represented by a diamond and connecting the entities with lines.

Entity-Relationship Set

A set of relationships of the same type is known as a relationship set. The following relationship set
depicts S1 as enrolled in C2, S2 as enrolled in C1, and S3 as registered in C3.

Relationship Set

Degree of a Relationship Set

The number of different entity sets participating in a relationship set is called the degree of a
relationship set.

1. Unary Relationship: When there is only ONE entity set participating in a relation, the relationship
is called a unary relationship. For example, one person is married to only one person.
Unary Relationship

2. Binary Relationship: When there are TWO entities set participating in a relationship, the
relationship is called a binary relationship. For example, a Student is enrolled in a Course.

Binary Relationship

3. Ternary Relationship: When there are n entities set participating in a relation, the relationship is
called an n-ary relationship.

Cardinality

The number of times an entity of an entity set participates in a relationship set is known
as cardinality. Cardinality can be of different types:

1. One-to-One: When each entity in each entity set can take part only once in the relationship, the
cardinality is one-to-one. Let us assume that a male can marry one female and a female can marry
one male. So the relationship will be one-to-one.

the total number of tables that can be used in this is 2.

one to one cardinality

Using Sets, it can be represented as:

Set Representation of One-to-One

2. One-to-Many: In one-to-many mapping as well where each entity can be related to more than one
entity and the total number of tables that can be used in this is 2. Let us assume that one surgeon
department can accommodate many doctors. So the Cardinality will be 1 to M. It means one
department has many Doctors.

total number of tables that can used is 3.

Set Representation of One-to-Many

3. Many-to-One: When entities in one entity set can take part only once in the relationship set and
entities in other entity sets can take part more than once in the relationship set, cardinality is many
to one. Let us assume that a student can take only one course but one course can be taken by many
students. So the cardinality will be n to 1. It means that for one course there can be n students but
for one student, there will be only one course.

The total number of tables that can be used in this is 3.

many to one cardinality

Using Sets, it can be represented as:

Set Representation of Many-to-One

In this case, each student is taking only 1 course but 1 course has been taken by many students.

4. Many-to-Many: When entities in all entity sets can take part more than once in the relationship
cardinality is many to many. Let us assume that a student can take more than one course and one
course can be taken by many students. So the relationship will be many to many.

the total number of tables that can be used in this is 3.

many to many cardinality

Using Sets, it can be represented as:

Many-to-Many Set Representation

In this example, student S1 is enrolled in C1 and C3 and Course C3 is enrolled by S1, S3, and S4. So it
is many-to-many relationships.

Participation Constraint

Participation Constraint is applied to the entity participating in the relationship set.

1. Total Participation – Each entity in the entity set must participate in the relationship. If each
student must enroll in a course, the participation of students will be total. Total participation is
shown by a double line in the ER diagram.

2. Partial Participation – The entity in the entity set may or may NOT participate in the relationship.
If some courses are not enrolled by any of the students, the participation in the course will be
partial.

The diagram depicts the ‘Enrolled in’ relationship set with Student Entity set having total
participation and Course Entity set having partial participation.

Total Participation and Partial Participation

Using Set, it can be represented as,

Set representation of Total Participation and Partial Participation

Every student in the Student Entity set participates in a relationship but there exists a course C4 that
is not taking part in the relationship.

How to Draw ER Diagram?

 The very first step is Identifying all the Entities, and place them in a Rectangle, and labeling
them accordingly.

 The next step is to identify the relationship between them and place them accordingly using
the Diamond, and make sure that, Relationships are not connected to each other.

 Attach attributes to the entities properly.

 Remove redundant entities and relationships.

 Add proper colors to highlight the data present in the database.

Relational Model in DBMS

E.F. Codd proposed the relational Model to model data in the form of relations or tables. After
designing the conceptual model of the Database using ER diagram, we need to convert the
conceptual model into a relational model which can be implemented using any RDBMS language like
Oracle SQL, MySQL, etc. So we will see what the Relational Model is.

The relational model uses a collection of tables to represent both data and the relationships among
those data. Each table has multiple columns, and each column has a unique name. Tables are also
known as relations. The relational model is an example of a record-based model. Record-based
models are so named because the database is structured in fixed-format records of several types.
Each table contains records of a particular type. Each record type defines a fixed number of fields, or
attributes. The columns of the table correspond to the attributes of the record type. The relational
data model is the most widely used data model, and a vast majority of current database systems are
based on the relational model.

What is the Relational Model?

The relational model represents how data is stored in Relational Databases. A relational database
consists of a collection of tables, each of which is assigned a unique name. Consider a relation
STUDENT with attributes ROLL_NO, NAME, ADDRESS, PHONE, and AGE shown in the table.

Table Student

ROLL_NO NAME ADDRESS PHONE AGE

1 RAM DELHI 9455123451 18

2 RAMESH GURGAON 9652431543 18

3 SUJIT ROHTAK 9156253131 20

4 SURESH DELHI 18

Important Terminologies

 Attribute: Attributes are the properties that define an entity. e.g.; ROLL_NO, NAME,
ADDRESS

 Relation Schema: A relation schema defines the structure of the relation and represents the
name of the relation with its attributes. e.g.; STUDENT (ROLL_NO, NAME, ADDRESS, PHONE,
and AGE) is the relation schema for STUDENT. If a schema has more than 1 relation, it is
called Relational Schema.

 Tuple: Each row in the relation is known as a tuple. The above relation contains 4 tuples, one
of which is shown as:

1 RAM DELHI 9455123451 18

 Relation Instance: The set of tuples of a relation at a particular instance of time is called a
relation instance. Table 1 shows the relation instance of STUDENT at a particular time. It can
change whenever there is an insertion, deletion, or update in the database.

 Degree: The number of attributes in the relation is known as the degree of the relation.
The STUDENT relation defined above has degree 5.

 Cardinality: The number of tuples in a relation is known as cardinality. The STUDENT relation
defined above has cardinality 4.

 Column: The column represents the set of values for a particular attribute. The
column ROLL_NO is extracted from the relation STUDENT.
ROLL_NO

 NULL Values: The value which is not known or unavailable is called a NULL value. It is
represented by blank space. e.g.; PHONE of STUDENT having ROLL_NO 4 is NULL.

 Relation Key: These are basically the keys that are used to identify the rows uniquely or also
help in identifying tables. These are of the following types.

o Primary Key

o Candidate Key

o Super Key

o Foreign Key

o Alternate Key

o Composite Key

Constraints in Relational Model

While designing the Relational Model, we define some conditions which must hold for data present
in the database are called Constraints. These constraints are checked before performing any
operation (insertion, deletion, and updation ) in the database. If there is a violation of any of the
constraints, the operation will fail.

Domain Constraints

These are attribute-level constraints. An attribute can only take values that lie inside the domain
range. e.g.; If a constraint AGE>0 is applied to STUDENT relation, inserting a negative value of AGE
will result in failure.

Key Integrity

Every relation in the database should have at least one set of attributes that defines a tuple uniquely.
Those set of attributes is called keys. e.g.; ROLL_NO in STUDENT is key. No two students can have the
same roll number. So a key has two properties:

 It should be unique for all tuples.

 It can’t have NULL values.

Referential Integrity

When one attribute of a relation can only take values from another attribute of the same relation or
any other relation, it is called referential integrity. Let us suppose we have 2 relations

Table Student

ROLL_NO NAME ADDRESS PHONE AGE BRANCH_CODE

1 RAM DELHI 9455123451 18 CS

2 RAMESH GURGAON 9652431543 18 CS

3 SUJIT ROHTAK 9156253131 20 ECE

4 SURESH DELHI 18 IT

Table Branch

BRANCH_CODE BRANCH_NAME

CS COMPUTER SCIENCE

IT INFORMATION TECHNOLOGY

ELECTRONICS AND COMMUNICATION

ECE
ENGINEERING

CV CIVIL ENGINEERING

BRANCH_CODE of STUDENT can only take the values which are present in BRANCH_CODE of BRANCH
which is called referential integrity constraint. The relation which is referencing another relation is
called REFERENCING RELATION (STUDENT in this case) and the relation to which other relations refer
is called REFERENCED RELATION (BRANCH in this case).

Anomalies in the Relational Model

An anomaly is an irregularity or something which deviates from the expected or normal state. When
designing databases, we identify three types of anomalies: Insert, Update, and Delete.

Insertion Anomaly in Referencing Relation

We can’t insert a row in REFERENCING RELATION if referencing attribute’s value is not present in the
referenced attribute value. e.g.; Insertion of a student with BRANCH_CODE ‘ME’ in STUDENT relation
will result in an error because ‘ME’ is not present in BRANCH_CODE of BRANCH.

Deletion/ Updation Anomaly in Referenced Relation:

We can’t delete or update a row from REFERENCED RELATION if the value of REFERENCED ATTRIBUTE
is used in the value of REFERENCING ATTRIBUTE. e.g; if we try to delete a tuple from BRANCH having
BRANCH_CODE ‘CS’, it will result in an error because ‘CS’ is referenced by BRANCH_CODE of
STUDENT, but if we try to delete the row from BRANCH with BRANCH_CODE CV, it will be deleted as
the value is not been used by referencing relation. It can be handled by the following method:

On Delete Cascade

It will delete the tuples from REFERENCING RELATION if the value used by REFERENCING ATTRIBUTE
is deleted from REFERENCED RELATION. e.g.; For, if we delete a row from BRANCH with
BRANCH_CODE ‘CS’, the rows in STUDENT relation with BRANCH_CODE CS (ROLL_NO 1 and 2 in this
case) will be deleted.

On Update Cascade

It will update the REFERENCING ATTRIBUTE in REFERENCING RELATION if the attribute value used by
REFERENCING ATTRIBUTE is updated in REFERENCED RELATION. e.g;, if we update a row from
BRANCH with BRANCH_CODE ‘CS’ to ‘CSE’, the rows in STUDENT relation with BRANCH_CODE CS
(ROLL_NO 1 and 2 in this case) will be updated with BRANCH_CODE ‘CSE’.

Super Keys

Any set of attributes that allows us to identify unique rows (tuples) in a given relationship is known as
super keys. Out of these super keys, we can always choose a proper subset among these that can be
used as a primary key. Such keys are known as Candidate keys. If there is a combination of two or
more attributes that are being used as the primary key then we call it a Composite key.

Codd Rules in Relational Model

Edgar F Codd proposed the relational database model where he stated rules. Now these are known
as Codd’s Rules. For any database to be the perfect one, it has to follow the rules.

For more, refer to Codd Rules in Relational Model.

Advantages of the Relational Model

 Simple model: Relational Model is simple and easy to use in comparison to other languages.

 Flexible: Relational Model is more flexible than any other relational model present.

 Secure: Relational Model is more secure than any other relational model.

 Data Accuracy: Data is more accurate in the relational data model.

 Data Integrity: The integrity of the data is maintained in the relational model.

 Operations can be Applied Easily: It is better to perform operations in the relational model.

Disadvantages of the Relational Model

 Relational Database Model is not very good for large databases.

  Sometimes, it becomes difficult to find the relation between tables.

 Because of the complex structure, the response time for queries is high.

Characteristics of the Relational Model

 Data is represented in rows and columns called relations.

 Data is stored in tables having relationships between them called the Relational model.

 The relational model supports the operations like Data definition, Data manipulation, and
Transaction management.

 Each column has a distinct name and they are representing attributes.

 Each row represents a single entity.

Flat File Database

A database kept in a file known as a flat file is referred to as a flat-file database. Every entry has the
same format, and there are no systems in place for indexing or determining the links between items.
The file is simple to read.

A flat file can be a binary file or a plain text file such as CSV, txt, or TSV file. Although connections
cannot be explicitly declared in the database format, they can be deduced from the data in the
database. While very big databases can also be flat, the phrase has always denoted a tiny database.

What is a Flat File Database?

Flat File Database is a text database. When storing data in an MS Excel plain text file, this is the most
significant kind of database. During the early 1970s, IBM created flat file databases.

The plain text file in the Flat File Database has one entry per line. Using delimiters like tabs and
commas, these records are kept apart. A flat-file database has the benefit of being simple to
assimilate and efficient in sorting the results.

How Flat File Database Works?

 Data is stored in plain text format in flat file databases, usually arranged into tables.

 Every table has its own file, and every line in the file corresponds to a record or row in the
database.

 A delimiter—a comma or a tab—separates the fields or columns that make up a record.

Using common file handling methods, creating, accessing, and manipulating data is made
simple by the flat file structure’s simplicity.

 Accessible to users without specialized database administration abilities, flat file databases
may be built and changed with a spreadsheet program or text editor.

Types of Flat File Database

Below are some types of Flat File Database

 JavaScript Object Notation (JSON): It is a simple data transfer format that is easy to read and
write for people. JSON files are perfect for hierarchically storing more difficult data structures
 since they express data as nested lists and dictionaries, which are identical to arrays and
objects in JavaScript.

 Initialization File(INI): INI files are arranged into header-defined parts, with key-value pairs
shown underneath each section.

 Comma Separated Values(CSV): These are a type of file that creates tabular data in plain
text. They are conceivably the most well-known format. Commas are utilised to separate the
various fields inside each record, and each line in the file represents a single record.

 Xtensible Markup Language(XML): It is an adaptable text format that may be utilised to

display structured data. Similar to HTML, XML files determine objects and properties using
tags, which enables the creation of sophisticated data structures with hierarchical
relationships.

Usages of Flat File Database

 Despite offering somewhat basic methods for storing, modifying, and retrieving data, flat
files are nonetheless extensively employed in many modern applications.

 Flat-file databases may be created and edited using spreadsheet programmes like Google
Sheets and Excel.

 As simple-to-create and simple-to-maintain date files for frequently requested information,

including name and address files, membership lists, or class rosters, flat-file databases
remain very valuable.

 These are also extensively utilised in data warehouse/data lake and internet of things (IoT)
contexts.

 For such uses, the ease of use and minimal overhead of a flat-file database make it a good
option for storing large amounts of data that must be kept in their original format.

Features of Flat File Database

 Portability: Flat file databases are ideal for situations where data needs to be shared or
migrated since they are simple to move or transfer across systems.

 Simple Data Accessibility: Users without specialised database administration abilities can
access and alter data in a flat file database using conventional file handling methods.

 Cost-Effective: Because flat file databases don’t need expensive database management
systems or specialised hardware, they are frequently less expensive than typical relational
databases.

 Flexible Data Structure: Because flat file databases lack a strict schema, their data
structures may be more flexible and it is simple to add or remove fields as needed.

Advantages of Flat File Database

Below are some advantages of Flat File Database

 Flexibility: Text, numeric, and graphical data may be stored in flat file databases, which can
be utilised for a variety of purposes.
  Human-readable: Data may be more easily inspected, debugged, and edited directly without
the need for specialised tools thanks to formats like CSV, JSON, and YAML.

 Simplicity: Because flat file databases just have one table containing a list of information,
they are straightforward and simple to set up. They don’t need any specialised software or
intricate programming.

 Rapid Development and Testing: Flat files’ ease of use may greatly accelerate software
projects’ development and testing stages, enabling more rapid iterations and prototype
stage simplifications.

Disadvantages of Flat File Database

Below are some disadvantages of Flat File Database

 Data redundancy: Since flat file databases only have one table, several entries containing the
same information may result in data redundancy.

 Restricted functionality: The complicated queries that flat file databases can execute,
including merging many tables or filtering data according to particular standards, are
constrained.

 Cost: Maintaining and licencing a flat file database can be costly, especially for large scale
applications.

 Security: Compared to relational databases (RDBMS), flat file databases are more receptive
to security threats including unauthorized access or data loss.

Difference Between Flat File Database and Relational Database

Flat File Database Relational Database

Data redundancy is an issue in

Data redundancy is not an issue with a relational database.
flat file databases.

Numerous software
Data access in relational databases is accomplished by a
programmes can access a flat
Relational Database Management System.
file database.

A relational database is made up of several tables with rows

Typically, a flat file consists of a
and columns that identify connections between various types
table with rows of data.
of data.

In flat files,there is no built-in In order to guarantee that data is saved consistently and
system for maintaining data accurately, relational databases employ primary and foreign
integrity. keys to maintain data integrity.

Conclusion
In this article we have leaned about Flat File Database. With just one table holding a list of entries,
flat file databases are straightforward and quick to set up. Complex programming or specialized
software is not needed for them.

Frequently Asked Questions on Flat File Database – FAQs

What are flat file databases most useful for?

Importing data for data warehousing initiatives often involves utilizing flat file databases.

Why is it called a flat file?

A flat file database is a collection of records where each record has a consistent format and, if
necessary, adheres to value type restrictions.

What file formats exist with flat-file database?

Many alternative formats, including the previously mentioned XML and CSV formats, can include
data in flat files. Additional forms include of tab-separated, fixed-width, and name and value pairs.

Are flat files secure?

Compared to relational data stores, flat-file data storage are typically less secure.

ER (Entity Relationship) Diagram in DBMS

o ER model stands for an Entity-Relationship model. It is a high-level data model. This model is
used to define the data elements and relationship for a specified system.

o It develops a conceptual design for the database. It also develops a very simple and easy to
design view of data.

o In ER modeling, the database structure is portrayed as a diagram called an entity-

relationship diagram.

For example, Suppose we design a school database. In this database, the student will be an entity
with attributes like address, name, id, age, etc. The address can be another entity with attributes like
city, street name, pin code, etc and there will be a relationship between them.
Component of ER Diagram

1. Entity:

An entity may be any object, class, person or place. In the ER diagram, an entity can be represented
as rectangles.

Consider an organization as an example- manager, product, employee, department etc. can be taken
as an entity.

a. Weak Entity

An entity that depends on another entity called a weak entity. The weak entity doesn't contain any
key attribute of its own. The weak entity is represented by a double rectangle.
2. Attribute

The attribute is used to describe the property of an entity. Eclipse is used to represent an attribute.

For example, id, age, contact number, name, etc. can be attributes of a student.

a. Key Attribute

The key attribute is used to represent the main characteristics of an entity. It represents a primary
key. The key attribute is represented by an ellipse with the text underlined.

b. Composite Attribute

An attribute that composed of many other attributes is known as a composite attribute. The
composite attribute is represented by an ellipse, and those ellipses are connected with an ellipse.
c. Multivalued Attribute

An attribute can have more than one value. These attributes are known as a multivalued attribute.
The double oval is used to represent multivalued attribute.

For example, a student can have more than one phone number.

d. Derived Attribute

An attribute that can be derived from other attribute is known as a derived attribute. It can be
represented by a dashed ellipse.

For example, A person's age changes over time and can be derived from another attribute like Date
of birth.
3. Relationship

A relationship is used to describe the relation between entities. Diamond or rhombus is used to
represent the relationship.

Types of relationship are as follows:

a. One-to-One Relationship

When only one instance of an entity is associated with the relationship, then it is known as one to
one relationship.

For example, A female can marry to one male, and a male can marry to one female.

ADVERTISEMENT

b. One-to-many relationship

When only one instance of the entity on the left, and more than one instance of an entity on the right
associates with the relationship then this is known as a one-to-many relationship.

For example, Scientist can invent many inventions, but the invention is done by the only specific
scientist.
c. Many-to-one relationship

When more than one instance of the entity on the left, and only one instance of an entity on the right
associates with the relationship then it is known as a many-to-one relationship.

For example, Student enrolls for only one course, but a course can have many students.

d. Many-to-many relationship

When more than one instance of the entity on the left, and more than one instance of an entity on
the right associates with the relationship then it is known as a many-to-many relationship.

For example, Employee can assign by many projects and project can have many employees.