1.

Requirement Analysis
It’s very crucial to understand the requirements of our application so that you can think in
productive terms. And imply appropriate integrity constraints to maintain the data integrity &
consistency.
2. Logical & Physical Design
This is the actual design phase that involves various steps that are to be taken while
designing a database. This phase is further divided into two stages:
 Logical Data Model Design: This phase consists of coming up with a high-level design
of our database based on initially gathered requirements to structure & organize our data
accordingly. A high-level overview on paper is made of the database without considering
the physical level design, this phase proceeds by identifying the kind of data to be
stored and what relationship will exist among those data.
Entity, Key attributes identification & what constraints are to be implemented is the core
functionality of this phase. It involves techniques such as Data Modeling to visualize
data, normalization to prevent redundancy, etc.
 Physical Design of Data Model: This phase involves the implementation of the logical
design made in the previous stage. All the relationships among data and integrity
constraints are implemented to maintain consistency & generate the actual database.
3. Data Insertion and testing for various integrity Constraints
Finally, after implementing the physical design of the database, we’re ready to input the data
& test our integrity. This phase involves testing our database for its integrity to see if
something got left out or, if anything new to add & then integrating it with the desired
application.
Logical Data Model Design
The logical data model design defines the structure of data and what relationship exists
among those data. The following are the major components of the logical design:
1. Data Models: Data modeling is a visual modeling technique used to get a high-level
overview of our database. Data models help us understand the needs and requirements of
our database by defining the design of our database through diagrammatic representation.
Ex: model, Network model, Relational Model, object-oriented data model.

Data Models

2. Entity: Entities are objects in the real world, which can have certain properties & these
properties are referred to as attributes of that particular entity. There are 2 types of entities:
Strong and weak entity, weak entity do not have a key attribute to identify them, their
existence solely depends on one 1-specific strong entity & also have full participation in a
relationship whereas strong entity does have a key attribute to uniquely identify them.
Weak entity example: Loan -> Loan will be given to a customer (which is optional) & the
load will be identified by the customer_id to whom the lone is granted.
3. Relationships: How data is logically related to each other defines the relationship of that
data with other entities. In simple words, the association of one entity with another is defined
here.
A relationship can be further categorized into – unary, binary, and ternary relationships.
 Unary: In this, the associating entity & the associated entity both are the same. Ex:
Employee Manages themselves, and students are also given the post of monitor hence
here the student themselves is a monitor.
 Binary: This is a very common relationship that you will come across while designing a
database.
Ex: Student is enrolled in courses, Employee is managed by different managers, One
student can be taught by many professors.
 Ternary: In this, we have 3 entities involved in a single relationship. Ex: an employee
works on a project for a client. Note that, here we have 3 entities: Employee, Project &
Client.
4. Attributes: Attributes are nothing but properties of a specific entity that define its
behavior. For example, an employee can have unique_id, name, age, date of birth (DOB),
salary, department, Manager, project id, etc.
5. Normalization: After all the entities are put in place and the relationship among data is
defined, we need to look for loopholes or possible ambiguities that may arise as a result of
CRUD operations. To prevent various Anomalies such as INSERTION, UPDATION, and
DELETION Anomalies.
Data Normalization is a basic procedure defined for databases to eliminate such anomalies
& prevent redundancy.
An Example of Logical Design
 Logical Design Example

Physical Design
The main purpose of the physical design is to actually implement the logical design that is,
show the structure of the database along with all the columns & their data types, rows,
relations, relationships among data & clearly define how relations are related to each other.
Following are the steps taken in physical design
Step 1: Entities are converted into tables or relations that consist of their properties
(attributes)
Step 2: Apply integrity constraints: establish foreign key, unique key, and composite key
relationships among the data. And apply various constraints.
Step 3: Entity names are converted into table names, property names are translated into
attribute names, and so on.
Step 4: Apply normalization & modify as per the requirements.
Step 5: Final Schemes are defined based on the entities & attributes derived in logical
design.
 Physical Design

Conclusion
In conclusion, a good database design is an essential part of a strong database
management system (DBMS). It provides the basis for data governance, data storage, and
data retrieval. The quality of a database has a direct impact on a system’s overall
performance and dependability. It is important to consider data organization,
standardization, performance, integrity, and more when designing a database to meet the
needs of your organization and your users.

Unlock the Power of Placement Preparation!

Feeling lost in OS, DBMS, CN, SQL, and DSA chaos? Our Complete Interview
Preparation Course is the ultimate guide to conquer placements. Trusted by over 100,000+
geeks, this course is your roadmap to interview triumph.
Ready to dive in? Explore our Free Demo Content and join our Complete Interview
 Types of Databases


A quick review of the present need to store massive chunks of data relevant to
multiple related or unrelated categories, reveals that databases must be highly
effective at what they are designed to do.
This is not only because of the amount of data being continuously revised or
modified that we are dealing with the dynamics of it aren’t of sole interest
anymore. It’s because of the social value that every individual has assigned to
them: databases are the literal backbone of a client’s lifestyle or a business’s
worth.
Designing different types of databases lies at the core of the functionality that
they provide to the users. Since data is a dynamic entity, the way it is stored
varies a lot. It is also the reason behind companies designing their own types of
databases that comply with their needs. In this article, we will be discussing the
types of Databases in detail.
Types of Databases
There are several types of databases, that are briefly explained below.
 Hierarchical databases
 Network databases
 Object-oriented databases
 Relational databases
 Cloud Database
 Centralized Database
 Operational Database
 NoSQL databases
Hierarchical Databases
Just as in any hierarchy, this database follows the progression of data being
categorized in ranks or levels, wherein data is categorized based on a common
point of linkage. As a result, two entities of data will be lower in rank and the
commonality would assume a higher rank. Refer to the diagram below:
 Hierarchical Database Example

Do note how Departments and Administration are entirely unlike each other and
yet fall under the domain of a University. They are elements that form this
hierarchy.
Another perspective advises visualizing the data being organized in a parent-child
relationship, which upon addition of multiple data elements would resemble a
tree. The child records are linked to the parent record using a field, and so the
parent record is allowed multiple child records. However, vice versa is not
possible.
Notice that due to such a structure, hierarchical databases are not easily salable;
the addition of data elements requires a lengthy traversal through the database.

Network Databases
In Layman’s terms, a network database is a hierarchical database, but with a
major tweak. The child records are given the freedom to associate with multiple
parent records. As a result, a network or net of database files linked with multiple
threads is observed. Notice how the Student, Faculty, and Resources elements
each have two-parent records, which are Departments and Clubs.

Network Database Example

Certainly, a complex framework, network databases are more capable of

representing two-directional relationships. Also, conceptual simplicity favors the
utilization of a simpler database management language.

The disadvantage lies in the inability to alter the structure due to its complexity
and also in it being highly structurally dependent.

Object-Oriented Databases
Those familiar with the Object-Oriented Programming Paradigm would be able to
relate to this model of databases easily. Information stored in a database is
capable of being represented as an object which response as an instance of the
database model. Therefore, the object can be referenced and called without any
difficulty. As a result, the workload on the database is substantially reduced.

Object-Oriented Example

In the chart above, we have different objects linked to one another using
methods; one can get the address of the Person (represented by the Person
Object) using the livesAt() method. Furthermore, these objects have attributes
which are in fact the data elements that need to be defined in the database.

An example of such a model is the Berkeley DB software library which uses the
same conceptual background to deliver quick and highly efficient responses to
database queries from the embedded database.

Relational Databases
Considered the most mature of all databases, these databases lead in the
production line along with their management systems. In this database, every
piece of information has a relationship with every other piece of information. This
is on account of every data value in the database having a unique identity in the
form of a record.

Note that all data is tabulated in this model. Therefore, every row of data in the
database is linked with another row using a primary key. Similarly, every table is
linked with another table using a foreign key.

Refer to the diagram below and notice how the concept of ‘Keys’ is used to link
two tables.
 Relational Database Example

Due to this introduction of tables to organize data, it has become exceedingly

popular. In consequence, they are widely integrated into Web-Ap interfaces to
serve as ideal repositories for user data. What makes it further interesting is the
ease in mastering it, since the language used to interact with the database is
simple (SQL in this case) and easy to comprehend.
It is also worth being aware of the fact that in Relational databases, scaling and
traversing through data is quite a light-weighted task in comparison to
Hierarchical Databases.

Cloud Databases
A cloud database is used where data requires a virtual environment for storing
and executing over the cloud platforms and there are so many cloud computing
services for accessing the data from the databases (like SaaS, Paas, etc).
There are some names of cloud platforms are-
 Amazon Web Services (AWS)
 Google Cloud Platform (GCP)
 Microsoft Azure
 ScienceSoft, etc.
Centralized Databases
A centralized database is basically a type of database that is stored, located as
well as maintained at a single location and it is more secure when the user wants
to fetch the data from the Centralized Database.
Advantages
 Data Security
 Reduced Redundancy
 Consistency
Disadvantages
 The size of the centralized database is large which increases the response and
retrieval time.
 It is not easy to modify, delete and update.

Personal Databases
Collecting and Storing the data on its own System and this type of databases is
basically designed for the single user.
Advantages
 It is easy to handle
 It occupies less space
Operational Databases
It is used for creating, updating, and deleting the database in real-time and it is
basically designed for executing and handling the daily data operation in
organizations and businesses purposes.
Advantages
 easy to fetch.
 Structured data
 Real-time processing

NoSQL Databases
A NoSQL originally referring to non SQL or non-relational is a database that
provides a mechanism for storage and retrieval of data. This data is modeled in
means other than the tabular relations used in relational databases.

A NoSQL database includes simplicity of design, simpler horizontal scaling to

clusters of machines, and finer control over availability. The data structures used
by NoSQL databases are different from those used by default in relational
databases which makes some operations faster in NoSQL. The suitability of a
given NoSQL database depends on the problem it should solve. Data structures
used by NoSQL databases are sometimes also viewed as more flexible than
relational database tables.

MongoDB falls in the category of NoSQL document-based database.

Advantages of NoSQL
There are many advantages of working with NoSQL databases such as MongoDB
and Cassandra. The main advantages are high scalability and high availability.
Disadvantages of NoSQL
NoSQL has the following disadvantages.
 NoSQL is an open-source database.
 GUI is not available
 Backup is a weak point for some NoSQL databases like MongoDB.
 Large document size.
These are but a few types of database structures which represent the
fundamental concepts extensively used in the industry. However, as mentioned
earlier, clients tend to focus on creating databases which would suit their own
needs; to store data in a schema which showcases a variable functionality based
on its blueprint. Hence, the scope for development in reference to databases and
database management systems is bright.
Frequently Asked Questions
Q.1: What are the most common SQL database types?
Answer:
Relational databases and non-relational databases are the two basic categories of
databases in SQL.
Q.2: Which NewSQL databases are the mostly used?
Answer:
The most popular NewSQL databases are CockroachDB and NuoDB, Spanner etc.
Q.3: In SQL,What is a database?
Answer:
A database in SQL is an organized collection of Structured data. Databases help
us with efficiently storing, accessing, and manipulating data held on a computer
system or Server.

5 Steps in creating a Database

Design Process
In today's digital age, data has become an essential part of every
business. With the increasing amount of data being generated, it has
become more important than ever to store and organize it efficiently. A
well-designed database can help businesses to manage their data
effectively, make informed decisions, and drive business growth.
However, designing a database is not a simple task and requires
careful planning and execution. To create an effective database design
process, businesses need to follow a structured approach that takes
into account their specific requirements and constraints. In this blog
post, we will discuss five key steps that businesses can follow to create
a database design process. By following these steps, businesses can
ensure that their database meets their requirements, is optimized for
performance, and is easy to use and maintain. We will provide practical
examples and tips to help businesses get started on their database
design journey, whether they are creating a new database or
improving an existing one.

Define the Purpose of the Database

The purpose of a database is to efficiently store, organize, and retrieve
large amounts of data that can be used to support business operations
and decision-making. Databases can be used for a wide range of
applications, such as tracking inventory in a warehouse, storing
customer information for an online store, or tracking financial
transactions for a business. In order for a database to be effective, it
must be designed in a way that aligns with the specific needs of the
organization using it. This is where the database design process comes
in.
The database design process is a structured approach to designing a
database that meets the needs of the organization. The process
involves several steps, including identifying the purpose of the
database, identifying the entities and relationships that exist in the
data, creating a data model, and creating the physical database
structure. The purpose of the database is a critical first step in the
design process as it sets the foundation for the rest of the design
process. Without a clear understanding of the purpose of the database,
it can be difficult to design a database that meets the needs of the
organization.
When defining the purpose of the database, it is important to consider
the specific business requirements that the database will support. This
may include determining the types of data that will be stored in the
database, the expected data volume, the expected data growth rate,
and the expected data access patterns. It is also important to consider
the security and performance requirements of the database, as well as
any regulatory or compliance requirements that may apply. By
considering these factors, organizations can develop a clear
understanding of the purpose of the database and ensure that the
database design process is aligned with the specific needs of the
organization.

Identify Entities and Relationships

The database design process is a critical aspect of software

development, and it is important to follow a structured approach to
ensure that the database meets the requirements of the organization.
The first step in the database design process is to gather
requirements, which involves identifying the data that needs to be
stored and the relationships between the data. Once the requirements
have been identified, the next step is to identify the entities and
relationships that exist in the data, as this will affect the structure of
the database. The data model that is created based on this information
will guide the creation of the physical database structure, and the
database designer must ensure that the database is optimized for
performance and accuracy. The database design process can be
complex, but it is essential to ensure that the database is designed in a
way that supports the organization's needs and objectives. Whether it
is for website design or managing large volumes of data in a database
management system (DBMS), a well-designed database can
improve operational efficiency and support informed decision-making.
It is important for organizations to work with experienced database
designers who can guide them through the process and ensure that
the end result meets their requirements.

Normalise the Data

Normalization is an important step in the database design process as it

helps to reduce data redundancy and ensure data consistency. By
organizing data in a database to minimize redundancy and
dependency, normalization can lead to improved data quality and
faster data retrieval times. The normalization process involves several
levels, with each level having its own set of rules and guidelines. The
first level, 1NF, requires that each column in a table contains only
atomic values, while 2NF requires that each non-key column is
dependent on the entire primary key. 3NF requires that each non-key
column is dependent only on the primary key and not on any other
non-key column. Although additional normalization levels exist, they
are less commonly used in practice. By adhering to normalization rules
and guidelines, database designers can create a more efficient and
effective database that is optimized for performance and data
integrity. Normalization is also important for website design and
software development, as it ensures that data is properly organized
and structured for use in applications and user interfaces.

Choose a Database Management System

Choosing the right database management system (DBMS) is an

important decision that can have a significant impact on the success of
a database design project. There are several factors to consider when
selecting a DBMS, including the scalability of the system, its
compatibility with the organization's existing infrastructure, its security
features, and its performance capabilities. Some popular DBMS options
include MySQL, Oracle, Microsoft SQL Server, and MongoDB.
MySQL is a popular open-source option that is known for its scalability
and ease of use, making it a popular choice for web-based
applications. Oracle is a powerful enterprise-level DBMS that is known
for its reliability and security features. Microsoft SQL Server is a
popular option for organizations that are already using Microsoft
technology, as it integrates well with other Microsoft products.
MongoDB is a NoSQL database that is designed for scalability and
flexibility, making it a good choice for organizations that are dealing
with large volumes of unstructured data. Ultimately, the choice of
DBMS will depend on the specific needs of the organization and the
requirements of the database design project. It is important to
carefully evaluate the options and choose a DBMS that aligns with the
organization's needs and goals.

Test the Database Design

Testing is a critical step in the database design process as it ensures

that the database meets the organization's requirements and performs
optimally. There are several types of tests that can be conducted,
including unit tests, integration tests, and performance tests. Unit
tests are designed to test individual components of the database,
such as tables and queries, to ensure that they are working as
intended. Integration tests are used to test the interaction between
different components of the database to ensure that they are working
together seamlessly. Performance tests are used to evaluate the speed
and responsiveness of the database under various conditions, such as
high user traffic or large data volumes. It is important to test the
database design thoroughly before it is deployed to ensure that it is
working correctly and that it can handle the expected workload.
Testing should be conducted at each stage of the database design
process, from the conceptual data model to the final physical data
model. Once testing is complete, any issues or bugs should be
addressed and the database design should be refined as needed. By
testing the database design thoroughly, organizations can ensure that
their database is reliable, efficient, and meets their needs for storing
and managing data.

Conclusion

In conclusion, creating a well-designed database is crucial for the

efficient storage and management of large amounts of data in any
organization. A structured database design process ensures that the
database meets the specific needs of the organization and is optimized
for performance. The five steps involved in creating a database design
process include analyzing requirements, identifying entities and
relationships, normalizing data, creating a data model, and
implementing the database.
The first step of analyzing requirements involves understanding the
data requirements of the organization, including what data needs to be
stored, how it will be used, and who will use it. Identifying entities and
relationships is crucial in defining the structure of the database, and
normalization helps to ensure data consistency and reduce
redundancy. Creating a data model helps to visualize the database
structure and the relationships between data entities. Finally,
implementing the database involves the actual creation of the
database structure and populating it with data.
By following these steps, organizations can create a database design
process that meets their specific needs and ensures optimal
performance. A well-designed database can lead to improved
operational efficiency, better decision-making, and ultimately, business
growth. Therefore, investing in a proper database design process is
essential for any organization that wants to effectively manage their
data and stay ahead in today's data-driven business landscape.
 Steps of DB Designing
Database design is one of the most important factors contributing to the performance of
an application. Consequently, how well the database is designed is of utmost importance.
Database design is all about efficiently organizing data based on product workflows,
future roadmap, and expected usage patterns.

The output of a database design exercise is a data model. A data model represents all the
objects, entities, attributes, relationships, and constraints in the system. Broadly speaking,
data models can be of two types: logical or physical. The representation of the data model
is done by creating an ER diagram, also known as an entity relationship diagram, an ERD
diagram, or a database diagram.

The physical data model relates to the actual implementation details in the database. The
logical data model, on the other hand, abstracts away the implementation technicalities.
This makes the logical data model consumable for the business. One key difference
between the two models is that the logical model is database-agnostic while the physical
model has to be specific to the database in use.

Proper database design is often understated and neglected during application

development. The cost of this neglect is realized usually much later when new application
features come in or when old features require change. This is when the database design
ceases to make sense. While it is not possible to future-proof the design of a database, it
is very much possible to make the effort to best understand the business use cases and
design the database accordingly. Read more about tips on better database design HERE .

With that in mind, let’s go through the steps in database design.

Step 1: Gather Business Requirements

The first step is to talk to the business about their requirements. If the conversation is
effective, it should result in enough information to start working on a conceptual data
model, which is an abstraction of the logical model. Talking to the business, first of all,
provides a complete picture of the business processes, which, in turn, provides
information about the various data points that are important for the business to capture
and track. For instance, in a taxicab booking model, it is worth asking the following
questions:
  Does the business want the vehicle tracking data in the database irrespective of
whether there's an active trip or not? If yes, then the field vehicle_trip_id in the
table vehicle_trips would be nullable. Otherwise, it won't be nullable.
 Does the business want the history of changes to trip_status stored in the
database? If yes, then every time the trip_status changes, there'll be another
record in the trips table. Otherwise, every time
the trip_status changes, trip_status will be updated in place.

As shown in this example, based on inputs from the business, you would end up choosing
one option over the other. It would result in changing the concerned entities and their
relationships.

Requirement gathering also generally involves initiating a conversation about data

security, such as which data to be masked and encrypted. The requirement gathering
exercise results in a requirement document often supported by a working draft of the
conceptual data model.

Step 2: Understand Business Roadmap

Businesses change their processes all the time; their ability to adapt makes them less
likely to fail. Changing business processes means changing workflows and data models.
Although it is not possible to know these changes way ahead of time, it is certainly
possible to be up to date with the business roadmap.

For instance, if a company has plans to target a new geographical region, the model
would have to cater to language support, currencies, time zones, and so on. The benefits
of understanding the long-term business roadmap often show up in a smoother transition
to new business processes.

Let me share one more example, which is more about continuously evolving business
priorities. The taxi business was impacted badly at the beginning of COVID-19. As a cab
company, you want to act preemptively to assure people that you're doing everything to
make sure that your travel in the cab is as safe as possible, that the vehicle is disinfected
every day, that the driver wears a mask at all times, and that there's hand sanitizer
available in the cab. Now, to capture all this information, changes to two
entities, drivers and vehicles , would be required. Several Boolean flag fields need to be
added to these entities to cater to this business use case.
Step 3: Identify Entities and Attributes
Once the business requirements are gathered, the information can be used to identify
entities along with the essential set of attributes. One or more entities generally map
directly to business processes, and the relationship between those entities also mimics
the business process workflow.

This step is also used to identify which attributes will act as identifiers in the entities.
Identifiers translate to primary keys in the physical model. In addition, it is also common to
specify data types for all the attributes in this step.

For instance, in the taxicab booking model, you would have to identify the attributes which
will act as the mandatory fields for the registration of users and drivers from the booking
app. User registration would be done using user_phone and driver registration would be
done using driver_phone .

Similarly, other entities and attributes are identified during this step, after having been
mapped to the business process workflows.

Step 4: Identify Relationships

After identifying the entities and their attributes, the next step is to define the relationships
between entities based on the business workflows that were documented in the
requirement gathering phase. In addition to establishing that there's a relationship
between two entities, it is also important to identify which of the following four types of
relationship exists between them. Consider two arbitrary entities, A and B:

1. One-to-one → One record in A corresponds to at most one record in B.

2. One-to-many → One record in A corresponds to many records in B.
3. Many-to-one → Many records in A correspond to at most one record in B.
4. Many-to-many → Many records in A correspond to many records in B.

In the taxicab booking model, only one type of relationship has been used, i.e., one-to-
many. Take the relationship between users and trips as an example. In the model,
there's an assumption that only one user can be related to a trip, which implies that there
are no shared or pooled cabs. But if there were shared or pooled cabs, there would
possibly have been a many-to-many relationship between users and trips , if many
users shared the same trip_id .
Step 5: Create a Logical ER Diagram
With entities, attributes, and entity relationships defined, the immediate next step is to
draw the ER diagram. All of the steps listed above can be done within VERTABELO . There
are no hard and fast rules for the way logical modeling is supposed to be done, with the
possible exception of the reference notation.

For instance, take a look at the FOLLOWING EXAMPLE of a logical ER diagram. It captures a
simple business workflow of a cab company, where a user can book a ride with the ability
to track the vehicle.

EDIT MODEL IN YOUR BROWSER

Cab Bookingsvehiclesvehicle_idvehicle_registration_numberIntegerVarchar(255)M
PIMdriversdriver_iddriver_namedriver_phoneIntegerVarchar(255)IntegerM
PIMMvehicle_trip_trackingvehicle_trip_tracking_idvehicle_trip_idgps_timegps_latitudegps
_longitudeIntegerIntegerTimestampLongFlatLongFlatM
PIMMMMvehicle_tripvehicle_trip_idvehicle_idtrip_idIntegerIntegerIntegerM
PIMMusersuser_iduser_nameuser_phoneIntegerVarchar(255)IntegerM
PIMMtripstrip_iddriver_idvehicle_iduser_idtrip_statusIntegerIntegerIntegerIntegerVarchar(
255)M PIMMMM

Step 6: Validate the Logical ER Diagram

Logical modeling is a process in which a lot of business information needs to be translated
into a database design. Without thorough checks, this phase of database development is
prone to errors that can prove to be quite costly at a later stage.

To take care of this, VERTABELO has a thorough list of checks that can be performed on a
logical model. Checks can be performed at all granularities, from the model as a whole to
individual attributes, and everything in between. Some of the simple checks are:

 Names of entities, attributes, relationships, etc., cannot be null and have to be

unique.
 An entity must have at least 1 attribute.
 Identifiers (PKs) must be defined for every entity.
 The model must use one of the listed data types for attributes.

All of these checks are optional and can be configured to be skipped, if there's another
validation framework in place. Proper validation from VERTABELO helps you move to the
next step with the minimum amount of friction possible.
Step 7: Create a Physical ER diagram
Once the logical ER diagram is created, the next step is to create a physical data model.
The physical data model will be specific to the database where you want to deploy the
data model. All databases have their unique implementation of nomenclature rules, data
types, and constraints. Due to this, the Data Definition Language (DDL) often differs from
one database to another.

To create a physical data model, follow these steps:

1. Find the closest data type in the target database to replace the generic data type
selected in the logical data model.
2. Follow the nomenclature rules for tables, columns, and constraints as prescribed by
the target database.
3. Modify the model to align with predefined query workflows. This generally results in
increasing redundancy to save joins.
4. Finally, you can create indexes, partitions, distribution keys, and sort keys. This is
when you can create any performance-enhancing modifications to the model.

These steps can be performed using any data modeling tool you can use to create a data
model from scratch. However, VERTABELO has an option to convert a logical data model to
a full-fledged physical data model for all the major database systems like MySQL,
PostgreSQL, Oracle, Microsoft SQL Server, Amazon Redshift, Google BigQuery, and
more. Once the logical data model is converted to a physical data model, you can carry on
with the four steps we discussed.

VERTABELO also has an option to add pre- and post-deployment scripts at the table level
along with any comments at the very granular level of the model. The comments turn out
handy when the documentation generation feature offered by VERTABELO is used. The
database document can be exported in any of the following three formats: HTML, PDF, or
DOCX.

Continuing with the cab booking example, let's take a look at the physical data model
generated by VERTABELO .

Step 8: Validate the Physical ER Diagram

Just like the logical ER diagram was validated, VERTABELO has a tool to validate physical
ER diagrams with several additional checks, like whether or not FKs exist and whether the
length of a table name or a column name exceeds the limit based on the database
selected.
The validation doesn't need to be run explicitly. It happens as the diagram is modified. The
issues with the model fall in one of three categories: errors, warnings, and hints, in order
of decreasing severity. There's a useful, well-written ARTICLE which talks about the
common mistakes made during the database design process.

Step 9: Fix Issues With the Physical ER Diagram

The results of the validation may identify issues which need to be fixed. Some of the most
common issues are:

 Missing foreign keys where entity relationships have been defined.

 Missing primary keys from tables.
 Unsupported data types for the selected database.

Once these and other similar issues are resolved, the model is ready to be exported to a
deployable SQL script for the selected database management system.

Step 10: Generate the DDL Scripts for Deploying the Model
DATABASE DESIGN IS NOT JUST ABOUT CREATING ER DIAGRAMS. A data modeling exercise
using ER diagrams is successful only if it results in something deployable. VERTABELO has
a convenient option to export the physical model to a ready-to-deploy SQL script. Once it
is generated, any pending issues can be resolved directly in the SQL script.

However, changing the generated SQL script is not recommended. It causes

a drift between the physical data model and the SQL script deployed on the database,
which can also mean a drift between the actual tables and the database documentation.

Now that we've reached the end of the database design process, let's have a look at
the SQL CODE generated by VERTABELO .

Share Your Thoughts

Database design is a high-impact activity in software development. The field of database
design has evolved over the years with new ways to represent the design for the
business, for the engineers, and for the data analysts. This has often resulted in new
types of diagrams, modeling standards and notations. Much of the evolution has been
covered in the DESIGN FUNDAMENTALS section.

We'll be happy to see what your experiences have been in designing databases. Write to
us at [email protected].
Primary Terminologies Used in Database Design
Following are the terminologies that a person should be familiar with before designing a
database:
 Redundancy: Redundancy refers to the duplicity of the data. There can be specific use
cases when we need or don’t need redundancy in our Database. For ex: If we have a
banking system application then we may need to strictly prevent redundancy in our
Database.
 Schema: Schema is a logical container that defines the structure & manages the
organization of the data stored in it. It consists of rows and columns having data types for
each column.
 Records/Tuples: A Record or a tuple is the same thing, basically its where our data is
stored inside a table
 Indexing: Indexing is a data structure technique to promote efficient retrieval of the data
stored in our database.
 Data Integrity & Consistency: Data integrity refers to the quality of the information
stored in our database and consistency refers to the correctness of the data stored.
 Data Models: Data models provide us with visual modeling techniques to visualize the
data & the relationship that exists among those data. Ex: model, Network Model, Object
Oriented Model, Hierarchical model, etc.
 Functional Dependency: Functional Dependency is a relationship between two
attributes of the table that represents that the value of one attribute can be determined by
another. Ex: {A -> B}, A & B are two attributes and attribute A can uniquely determine the
value of B.
 Transaction: Transaction is a single logical unit of work. It signifies that some changes
are made in the database. A transaction must satisfy the ACID or BASE properties
(depending on the type of Database).
 Schedule: Schedule defines the sequence of transactions in which they’re executed by
one or multiple users.
 Concurrency: Concurrency refers to allowing multiple transactions to operate
simultaneously without interfering with one another.

DB Life cycle