1.

The difference between relational database and flat file:

Relational Database Flat File
Relational Database proceeds to store data of opposing definitions or say formats distinctly in a most
referred technique as tables. Flat File Database is naturally self-determining or independent of each other
and needs no external architecture to store or state the data for later analysis.
Here, every table comprises of two sets of columns recognized as key values as well as stored values,
where key values help to related records among tables in a database. They can be simply modified and
printed directly, deprived of clarification beyond the file layout.
Relational Database includes multiple entities or, say, objects. A flat file Database includes of only one
file with no structured relationship.
It is characterized by means of schema. It is characterized by means of a data dictionary.
For example, SQL, which is a standard interface, is a popular type of Relational Database. For example, a
CSV file is the most mutual type of Flat File Database.
It helps in data redundancy and develops consistency. It is simple, easy to apply and economical, but a
problem exists with data redundancy.
It is safer than a flat-file database. It is less safe.
It includes the entity’s attributes with relationships. It includes files, fields, records and characters.
Few other relational databases comprise of MySQL, Microsoft SQL Server and Oracle Database servers.
Some other flat file formats comprise of EDI (Electronic Data Interchange) platform standard formats like
XML (Extensible Markup Language), X12 and EDIFACT or comma-delimited files named as
spreadsheets.
Relational Database offers reporting feature with report generators which filters and shows particular
fields. The Data Warehousing projects apply flat files for importing data but without having any
manipulation of data stored, which can simply carry data from the server.
It is normally initiated in data warehousing operations where the uninterrupted record access is necessary.
It is most regularly implemented in any transactional nature where a complete file needs processing.
This database is basically more difficult with different costs but delivers advanced proficiencies and more
resourceful access options. This database is simple and also free basically, but it confines the data access
to manual procedures or maybe structured programs.

2.
Relational model
The most common model, the relational model sorts data into tables, also known as relations, each of
which consists of columns and rows. Each column lists an attribute of the entity in question, such as price,
zip code, or birth date. Together, the attributes in a relation are called a domain. A particular attribute or
combination of attributes is chosen as a primary key that can be referred to in other tables, when it’s
called a foreign key.
3.
Types of Databases
Enterprise analytics works to extract value from many types of data from many sources. Optimizing an
analytics strategy requires starting at the database level and choosing a DBMS that will work effectively
for your specific business needs. Significant trade-offs exist between consistency, availability, and
partition tolerance, and no database technology can deliver on all three. This concept, known as the CAP
theorem, means that it is necessary for organizations to choose which database strengths are most
important for their particular business needs.
Databases may be hosted on-premises or in the cloud. Cloud databases are known for scalability, but
some businesses prefer to keep data on-premises in order to have more control over security, especially in
regulated industries.
Your programming language defines data structures and is critical to manipulating and analyzing data.
Different database products and types use programming languages optimized for specific data types,
functions, and use cases. Many large companies will need several types of databases to organize and
employ their data effectively.
Relational Databases
Relational databases, based on standardized data tables that express relationships between data,
commonly use structured query language (SQL). Relational databases are highly effective for managing
structured data with consistent rules and relationships—like financial transactions or inventory tracking.
Relational database software includes Oracle, Microsoft* SQL Server, IBM DB2, and Azure SQL.
 OLTP
OLTP (Online Transactional Processing) is a category of data processing that is focused on
transaction-oriented tasks. OLTP typically involves inserting, updating, and/or deleting small
amounts of data in a database.
One of the most common applications for databases is transaction processing. OLTP is a mode of
accessing databases that is geared specifically for transaction processing with many simultaneous
users. OLTP is a common way to use Oracle, IBM, and Microsoft databases.
 OLAP
To review a large amount of historical information for analytics purposes, businesses may use
online analytical processing (OLAP). OLAP queries typically use a multidimensional data model,
though some also use relational data models. Data warehouses are a specialized type of OLAP
designed specifically for analytics.
Object-Oriented Databases
In an object-oriented database, information is represented as objects and classes of objects. A hybrid form
of object-oriented and relational databases is called an object-relational database.
Non-Relational Databases
Sometimes called NoSQL databases, non-relational databases break free from the table structure.
Typically using metadata for organization, these databases are effective for managing non-structured data
and complex data types like images and video. MongoDB and Apache Cassandra are examples of popular
non-relational database software.
  Key-Value Database
Sometimes called a key-value store, this is the simplest form of a NoSQL database. Redis and
Oracle NoSQL Database are both key-value databases, which use a hash table to store and
retrieve data using a unique identifying “key".
 Wide-Column Stores
In wide-column stores, data is stored in columns of related information. Cassandra is the most
common of these databases, which offer scalability and fast queries for large data sets.
 Document Databases
Sometimes called document stores, these store data as complex records called “documents,”
which include metadata or information about the data itself. Documents can include any type of
data, including images and video.
 Graph Databases
Another type of NoSQL database, graph databases are based on graph structures to define
relationships and store data. Graph databases are designed to allow fast queries and high-volume
data processing for highly connected information. SAP HANA and OrientDB both use graph
database models.
4.
5.
Entity
Entities represent data components within a database that could be living or non-living, real or abstract, so
long as their data is stored in the database. Examples of entities include people, places, objects, events, or
concepts. In ER diagrams, entities are usually depicted by rectangles, with the entity name at the top.

Entity
Client, City and Country Entities of a Data Model

Attribute
An attribute is a description of the properties of an entity or relationship. For instance, the entity shipment
could have attributes such as shipment ID (id), client_id, shipment time_created, billing_address, etc. In
the crow’s foot notation, an attribute is represented as a line of text in the lower compartment of the
corresponding entity’s rectangle.

Attribute
A Snapshot Showing Various Attributes of the shipment Entity

Relationship
A relationship denotes how various entities interact with each other. For instance, in a database for a
vehicle hiring service, a customer will form a relationship with the entity vehicle through the act of
selecting. “Select” is, therefore, a relationship between the two entities.

The relationship between data in one table and data in another table is called cardinality. Specifically, the
cardinality indicates the number of times one entity in a table can relate with the instances of another
entity.

When drawing relationships in crow’s foot notation, there are two indicators: one for multiplicity
(cardinality) while the other indicates whether a relationship is optional or mandatory. A mandatory
relationship is shown by a line perpendicular to the relationship line, while an optional relationship is
shown by an empty circle.

When drawing relationships in crow’s foot notation, there are two indicators: one for multiplicity
(cardinality) while the other indicates whether a relationship is optional or mandatory. A mandatory
relationship is shown by a line perpendicular to the relationship line, while an optional relationship is
shown by an empty circle.

In data modeling, there are three types of cardinalities.

One-to-One
In a one-to-one association, one entity in a table can relate only once to an entity in another table. For
instance, a customer can hire only one vehicle at a time, and a vehicle can be assigned to only one
customer at a time.

In an entity-relationship diagram, one row in one table would correlate to only one row in another table.
In the IE notation, a mandatory one-to-one relationship is represented by two lines perpendicular to the
relationship line near both entity rectangles.

One-to-One
One-to-One Association With Mandatory Relationship

One-to-One
One-to-One Association With Optional Relationship

One-to-Many
A one-to-many relationship occurs when one instance of an entity can interact with multiple instances of
another entity. For instance, one customer can hire several vehicles, while each vehicle can only be
assigned to one customer at a time.

In the IE notation, a one-to-many relationship is represented by a single line at the end of the single
instance, and a three-pronged crow’s-foot symbol facing the multiple instance rectangle.

One-to-Many
One-to-Many Association With Mandatory Relationship

Many-to-Many
This type of cardinality occurs when multiple instances of one entity can relate with more than one
instance of another set of entities. Imagine a scenario in which a customer could select multiple vehicles,
and a vehicle could be leased by multiple customers within a certain time period. In the IE notation, a
many-to-many relationship is depicted by crow’s feet at both ends of the relationship line.

Many-to-Many
Many-to-Many Association With Mandatory Relationship

Many-to-Many
Many-to-Many Association With Optional Relationship

While the above notations are in crow’s foot notation, there are a number of other ERD notation formats,
the details of which can be found HERE.
6.
Data Abstraction Layer
In a pictorial view, you can see how the different models work together. Let’s look at this from the
highest level, the external model.
The external model is the end user’s view of the data. Typically, a database is an enterprise system that
serves the needs of multiple departments. However, one department is not interested in seeing other
departments’ data (e.g., the human resources (HR) department does not care to view the sales
department’s data). Therefore, one user view will differ from another.
The external model requires that the designer subdivide a set of requirements and constraints into
functional modules that can be examined within the framework of their external models (e.g., human
resources versus sales).
As a data designer, you need to understand all the data so that you can build an enterprise-wide database.
Based on the needs of various departments, the conceptual model is the first model created.
At this stage, the conceptual model is independent of both software and hardware. It does not depend on
the DBMS software used to implement the model. It does not depend on the hardware used in the
implementation of the model. Changes in either hardware or DBMS software have no effect on the
database design at the conceptual level.
Once a DBMS is selected, you can then implement it. This is the internal model. Here you create all the
tables, constraints, keys, rules, etc.  This is often referred to as the logical design.
The physical model is simply the way the data is stored on disk. Each database vendor has its own way of
storing the data.
Figure 5.1. Data abstraction layers.
9.
A Database Administrator is only as good as their last backup, (or database image, clone, flashback and
other redundancy.) It's the only protection from ID10T errors- our own and others. The best performing
database is one that has no users. The best performing query is one that doesn't have to be executed.