357 BROUGHT TO YOU IN PARTNERSHIP WITH

NoSQL Migration
CONTENTS

• About SQL and NoSQL

− SQL Incentives (What Were

Essentials
They Thinking?)
−   NoSQL Incentives (How Did We
Get Here?)

• Key Concepts in NoSQL Migration

Moving Out of a Relational Database −   NoSQL Data Modeling
−   Common Migration Paths
• Conclusion

−   Additional Resources
UPDATED BY MATTHEW D. GROVES, PRODUCT MARKETING MANAGER

ORIGINAL BY FRANK EAVES, SENIOR SOFTWARE ENGINEER

The need to transition from an SQL (relational) to a NoSQL (non-
relational) data solution happens usually under a positive business
environment. Your customers' requirements are causing you to
reevaluate your data solution in order to help them achieve their
business objectives. So congratulations, you have come to the right
place. When you're finished reading this Refcard, you'll have a solid
understanding of the foundations of this transition and serious paths to
consider when going about planning and implementing your migration
from an SQL to a NoSQL database.
ABOUT SQL AND NOSQL
The primary engineering incentive driving the design principles for
SQL is minimizing memory and disk usage, while that of NoSQL is
improving scalability. Understanding the reasons behind each of these
motivations will help set a foundation on which to base a migration
from SQL to NoSQL.
NOSQL INCENTIVES (HOW DID WE GET HERE?)
From 1979–2021 (42 years), the number of people using networked
computers (the Internet) grew exponentially. During this time, the
cost of storage fell to $0.023 per gigabyte. The motivations of 1979's
data engineers have changed drastically. Internet hosts went from
single digits in the late 60s to just over one billion in 2021. The modern
incentive of data engineering is scalability, while cost of storage is now
basically an afterthought. The foremost guiding principle within the
NoSQL database community is using keys and indexes on independent
data to create efficient data access and as a result, achieve speed and
scalability.
KEY CONCEPTS IN NOSQL MIGRATION
Why is database migration such a critical topic of conversation? It is
essential to first understand how the issue ties directly to the success
of today's modern business.

SQL INCENTIVES (WHAT WERE THEY THINKING?)

Relational Software Inc., now Oracle, announced the first
implementation of SQL in 1979. At the time, one megabyte of storage
cost $47,000 (inflation adjusted). Given that storage was so expensive,
engineering design was focused on the efficient use of this scarce
resource. Not repeating data was the main challenge to limiting
the amount of storage used. References to data in other tables and
constraints to assist with data integrity are the guiding principles
within the SQL database community.

This understanding and logic promulgated throughout the engineering

community as well as into academia. Students of computer science are
taught these principles and take that knowledge base with them into
the professional workplace.

REFCARD | NOVEMBER 2022 1

Couchbase Capella: A faster, easier, and more

The ideal database for mobile and edge applications

Learn More

Since the introduction of SQL, the importance of data has grown
exponentially, and in tandem, so has the need to learn and apply the
concepts of SQL databases. Academia and industry both found new and
compelling uses for data. This naturally led colleges to teach relational
principles. As graduates entered the workforce, relational databases
were used in systems development, which resulted in many businesses
running legacy software systems that are now struggling to scale and
meet the needs of the modern Internet customer.
Relying on legacy systems can result in lagging behind the smaller
start-ups using modern solutions and cloud-based services, including
NoSQL. These start-ups can scale their offerings far beyond what the
legacy systems can offer. The loss of market share for these companies
has opened a new market for industry solutions that help businesses
with legacy systems migrate their data infrastructure to NoSQL and
educate engineering teams about efficient implementation of it with
the hopes of maintaining and regaining lost market share.
Making this leap isn’t as hard as it might seem. Next, we'll cover the
basics (and a comparison) of SQL and NoSQL data modeling.
NOSQL DATA MODELING
The fundamental principles around NoSQL data modeling are the same
as those used for SQL. The difference comes down to denormalization
vs. normalization of data and the minor shift in the shared approaches
that this causes. Below is a Venn diagram showing a high-level view of
data modeling for SQL and NoSQL.
Figure 1
The process of creating an entity relationship diagram, understanding
your application’s access patterns, and then optimizing data throughput
by using indexes is the same for both SQL and NoSQL. So let’s focus on
understanding the differences between normalization and
denormalization.
DENORMALIZING DATA
What Is Normalization? …Just Be Like Everyone Else
The objectives of normalization are to reduce data redundancy and the
amount of data storage used, as well as to improve data integrity.
REFCARD | NOVEMBER 2022
REFCARD | NOSQL MIGR ATION ESSENTIALS
In his paper, "Further Normalization of the Data Base Relational Model,"
Edgar Codd defined four forms of data normalization:
Table 1
FORM PURPOSE
1NF (First Normal Remove unnecessary insertions, updates, and
Form) deletion dependencies from the data model — all
values must be atomic
2NF Optimize your data model so when new data types
are required, restructuring the schema is unneeded
— non-key values must have a clear connection to
the primary key
3NF Remove transitive dependencies within the data
model
4NF Identify statistics that could change in the future;
make changes to the data model relationships so
querying for these statistics is neutral
Following this process results in a set of tables with well-defined
constraints that meet the objectives of reduced data redundancy and
keeping data integrity intact.
What Is Denormalization? — Only Exceptional Data Need Apply!
The objective of denormalization is to design all access patterns in the
most efficient way possible. Data access patterns are a main focus,
and careful analysis is needed to attain that efficiency. This is done by
combining or nesting data into one structure, which makes the reads
and writes faster and avoids the overhead of joins.
Some people think that NoSQL is schema-less; however, this isn't true.
All applications have an inherent logical data structure, which still
exists in a NoSQL database — it is just stored implicitly. By utilizing this
capability, joins can be reduced, allowing the application to retrieve all
necessary information using a single lookup.
Before jumping into the example, let's first review the possible
variations of NoSQL data models.
NOSQL MODELS
For SQL data solutions, a table is the core data model. However, there
are multiple models for NoSQL data solutions to choose from. This
mainly depends on the NoSQL database you are using — the four most
popular types:
1. Key-value pair
2. Column-oriented
3. Graph-based
4. Document-oriented
Many NoSQL databases support two or more of these models. These
are known as "multi-model" databases.
3 BROUGHT TO YOU IN PARTNERSHIP WITH
 REFCARD | NOSQL MIGR ATION ESSENTIALS

Quick note: In a later section, a simple music site is used to demonstrate Figure 2
denormalization. The data used in the models below — band and song
names — are taken from that example.

Key-Value Pair
For key-value pair NoSQL databases, the model consists of a key and
value:

Table 2

PRIMARY KEY VALUE

Band Name Coldplay

But for more complex data structures, the value can be a JSON object,
which is greater in depth and complexity. Typically, text is used as the
visualization model for JSON structures. Document-Oriented
Document-oriented NoSQL databases have a primary key and a JSON
Primary Key: Band Name
value.
Value:

{ Primary Key: Arctic Monkeys

"Band Name": "Coldplay", Value:
"Year": 2002,
{
"Origin": "Sheffield, England"
"Band Name": "Arctic Monkeys",
}
"Year": 2002,
"Origin": "Sheffield, England",
Column-Oriented "Band Members": [
For column-oriented NoSQL databases, tables (or "column families", "Alex Turner",
since they are fundamentally different from relational tables) can be "Jamie Cook",
used to show the column data structures. Tables can have multiple "Nick O'Malley",

header rows — one for each data structure: "Matt Helders"

],
Table 3 "Genres": [
"Indie rock",
PRIMARY KEY ATTRIBUTES
"garage rock",
BAND NAME YEAR ORIGIN BAND MEMBERS "post-punk revival",
"psychedelic rock",
Arctic 2002 Sheffield, Alex Turner, Jamie Cook,
"alternative rock"
Monkeys England Nick O'Malley, Matt
Helders ]
}
PEAK
SONG NAME YEAR
CHART POS
Because all SQL models use tables, describing the migration process
When the Sun 2018 1 from SQL to NoSQL with tables may be a more applicable depiction
Goes Down that resonates with those coming from an SQL background. Therefore,
in the following sections, a table model will be used.

This model shows two data structures, Band Name and Song Name.
With the base knowledge about NoSQL databases, let's dive into how

Graph-Based denormalization works.

For graph-based NoSQL databases, the model consists of nodes

MOVING DATA INTO A NOSQL DATABASE
and edges. Data structures are put into nodes, and relationships are
To demonstrate the core concept of denormalization, we'll walk
represented by the edges that join one node to another. For example,
through the design of a data solution from the beginning. However,
visualizing a band, the songs that the band performs, and the members
most likely you will have gone through the initial phase(s) in building
of the band might be modeled this way:
your current SQL data solution.
SEE FIGURE 2 ON NEXT PAGE

REFCARD | NOVEMBER 2022 4 BROUGHT TO YOU IN PARTNERSHIP WITH

 REFCARD | NOSQL MIGR ATION ESSENTIALS

When creating any data solution, whether SQL or NoSQL, you should The data model for the Home screen:
consider following these steps:
Table 4
1. Understand your application – Use design tools and processes
PRIMARY KEY ATTRIBUTES
that are best suited to illustrate your problem domain and its
design. For this example, I use wire diagrams. SONG BAND PEAK CHART
HOME SCREEN YEAR
NAME NAME POS
2. Build an entity relationship diagram – Capture the data Yes When the Arctic 2018 1
structures and the relationships between them. Sun Goes Monkeys
Down
3. Define your access patterns – The data that should be grouped
together for optimal data delivery based on the application's Yes Yellow Coldplay 2000 2
needs.

4. Design your primary keys and indexes – Analyze the best Note that accessing this data structure will be done using the Home
way to design the primary keys and indexes for optimal data Screen column, and therefore, indexing this column may be necessary
delivery. for improved performance.

For this example, our problem domain is a simple music site where Functionality: Allow users to view song details.
users are presented with a list of songs and associated data, as well as
Figure 4
links to more information about each song and band.

1: Understand Your Application

The functionality this application will provide is allowing users to
choose a song or band they want to read more details about. Below is
the Home screen of our simple music site.

Functionality: Present a list of songs with links to song and band

details.

Figure 3

The model for the Song Details screen:

Table 5

PRIMARY KEY ATTRIBUTES

PEAK
BAND NAME -
ALBUM YEAR CHART LYRICS
SONG NAME
POS

Arctic Whatever 2018 1 So who's that

Monkeys - People Say girl there?
I Am, That's I wonder what
When the Sun
What I'm went wrong
Goes Down Not So that she had
Users can select the song name to navigate to song details or the band
to roam the
name to navigate to band details.
streets

TABLE CONTINUES ON NEXT PAGE

REFCARD | NOVEMBER 2022 5 BROUGHT TO YOU IN PARTNERSHIP WITH

 REFCARD | NOSQL MIGR ATION ESSENTIALS

PRIMARY KEY ATTRIBUTES PRIMARY

ATTRIBUTES
KEY
PEAK
BAND NAME -
ALBUM YEAR CHART LYRICS BAND
SONG NAME BAND
POS NAME - YEAR ORIGIN GENRES
MEMBERS
DETAILS
Coldplay - Parachutes 2000 2 Look at the stars
Yellow Look how they Coldplay - 1996 London, Chris Martin, Alternative
shine for you Details England Jonny rock, pop rock,
And everything Buckland, Guy post-Britpop,
you do Berryman, Will pop
Champion, Phil
Harvey
Note that if your primary key must be a number, then hashing the string
value into a number will work as well.
Note that the Band Members and Genres columns are both arrays,
Functionality: Allow users to view band details. representing a one-to-many embedded relationship.

Figure 5 2: Build an Entity Relationship Diagram

The entity relationship diagram looks like this:

Figure 6

There are four entities: Band Name, Song Name, Genre, and Band
The model for the Band Details screen:
Member. And there are three relationships, Perform, BelongsTo, and

Table 6 PartOf — all of which are one-to-many.

PRIMARY 3: Define the Access Patterns

ATTRIBUTES
KEY
Access patterns are the data patterns/groupings needed for the
BAND
BAND application.
NAME - YEAR ORIGIN GENRES
MEMBERS
DETAILS
In our music site, we have Song Name and Band Name, and the access
Arctic 2002 Sheffield, Alex Turner, Indie rock,
patterns for each of the wire diagrams are:
Monkeys - England Jamie Cook, garage rock,
Nick O'Malley, post-punk • Home screen – Displays the list of songs
Details
Matt Helders revival,
psychedelic • Song Details screen – Displays song details
rock,
alternative rock
• Band Details screen – Displays band details

To better understand these access patterns, let’s look at a composite

TABLE CONTINUES IN NEXT COLUMN
data model for all wire diagrams (data sourced from Tables 4-6).

REFCARD | NOVEMBER 2022 6 BROUGHT TO YOU IN PARTNERSHIP WITH

 REFCARD | NOSQL MIGR ATION ESSENTIALS

Table 7 While not possible in every NoSQL database, many document databases
have recently introduced JOIN capability. With JOIN functionality, you
PRIMARY
ATTRIBUTES
KEY can design your model to take advantage of whichever approach is best.
HOME SONG BAND PEAK CHART You can denormalize to maximize performance, and you can normalize
YEAR
SCREEN NAME NAME POS to maximize data integrity.
Yes When the Sun Arctic 2018 1
Goes Down Monkeys 4: Design Your Primary Keys and Indexes
In the composite table above, there are separate primary keys for each
Yes Yellow Coldplay 2000 2
data structure used. By querying this single table, you can extract
BAND NAME ALBUM PEAK YEAR LYRICS different schemas or groups of data. The Home screen’s primary key is
- SONG CHART the Home Screen column. When the Home Screen column is queried, it
NAME POS
will look for data that has a Home Screen attribute set to yes. Therefore,
Arctic Whatever 1 2018 So who's that an index should be created on the Home Screen attribute, so that look up
Monkeys - People Say girl there?
will be as fast as possible. The Song Details primary key uses a string
I Am, That's I wonder what
When the
What I'm Not went wrong that consists of the Band Name and Song Name concatenated together.
Sun Goes So that she had The Band Details primary key uses a string consisting of the Band Name
Down to roam the
followed by - Details. These primary keys are designed this way to
streets
give the application the data it needs in the quickest manner possible.
Coldplay - Parachutes 2 2000 Look at the
Yellow stars COMMON MIGRATION PATHS
Look how they In most cases, legacy solutions are unable to meet organizations’
shine for you
scalability objectives. And the engineering teams supporting those
And everything
you do legacy applications may not be aware of NoSQL database principles;
however, they have a tremendous amount of application and domain
BAND NAME BAND ORIGIN YEAR GENRES
- DETAILS MEMBERS knowledge. In short, companies in these situations have two primary

Arctic routes for migrating to a NoSQL database.

Alex Turner, Sheffield, 2002 Indie rock,
Monkeys - Jamie England garage rock,
Cook, Nick post-punk DIRECT PORT
Details
O'Malley, revival, Every business' situation is unique, and the migration approach will
Matt Helders psychedelic
inevitably be unique as well. A direct port will be easiest if your current
rock,
alternative rock data solution has a clear decoupling between the application logic and
data. If the application data layer is designed in a manner that allows
Coldplay - Chris Martin, London, 1996 Alternative
pulling out one database architecture and replacing it with another, then
Details Jonny England rock, pop rock,
Buckland, post-Britpop, it's just a matter of implementing the data layer interface using NoSQL.
Guy pop However, if your engineering team needs to create a clear decoupling of
Berryman,
the application logic and data, that work will need to be completed first.
Will
Champion, Then they can implement the data layer interface using NoSQL.These
Phil Harvey tasks may be done in parallel with one team coming up to speed on NoSQL—
and following the four steps for creating a new data solution discussed
The beneficial part about denormalizing data this way is that when above — while the other team does the architectural work of decoupling the
queried using a primary key, the application retrieves the data needed application logic and data. Then when both teams are ready, the application
to satisfy the functionality without resorting to joins. The downside of can be switched from an SQL database to a NoSQL database.
denormalizing your data is that some data may be duplicated (i.e., Band
Name, Year, Peak Chart Pos). In a fully normalized SQL database, PIECEMEAL
data isn't duplicated, and data integrity is maintained by the database In cases when a legacy application must remain running to keep the

through table constraints.
To meet scalability needs, a NoSQL database has duplicated data and
moves the responsibility of data integrity to the application code. When
data needs to be updated in multiple places, it is the application’s
responsibility to keep all data structures up to date.
business operational, switching the entire data layer over at once isn't
reasonable. Depending on the size of the data layer and the number of
engineering teams involved, migrating piecemeal may be an option.
Oftentimes, the areas where the application struggles under the
current SQL data layer is known. Focus your engineering efforts there
first, porting the critical code over in a piecemeal fashion.

REFCARD | NOVEMBER 2022 7 BROUGHT TO YOU IN PARTNERSHIP WITH


SQL and NoSQL Working Together
If your application’s data layer involves using multiple databases, you
can choose to port over one database to a NoSQL solution while leaving
the other alone. This approach works well in a cloud-native environment
where multiple microservices are running. Teams should start with the
service that is under the most stress and then move to the next service.
When a monolith is involved, a careful process needs to be followed
where you would wall off the part that has the most pressing issues with
scaling. After decoupling this part, it starts to look like a microservice,
and you can then focus on the data layer porting process. Once complete,
the next piece of the monolith can be addressed, repeating the process.
Convert to NoSQL While Still Using SQL Queries
The market has recognized the need for businesses to migrate to a
NoSQL solution. And those currently using an SQL solution also need
a bridge that enables them to move incrementally into a full NoSQL
database. This method offers three things:
1. Businesses can address their scalability objectives.
2. Engineering teams have time to come up to speed on NoSQL
principles.
3. Businesses have more options for addressing and evolving their
data solution going forward.
There are solutions available that allow you to convert your SQL schema
over to a NoSQL database while continuing to use SQL queries. There
are also NoSQL databases that are implementing the "SQL++" standard:
adding denormalized capabilities to the familiar query language. This
approach may help teams ramp up to NoSQL faster, building on their
existing experience and code base. (With the advent of SQL++, the term
"NoSQL" can be defined as "Not Only SQL": SQL is still an option for
interacting with data, but it's not the only one).
After, the business can operate as normal and only address the areas where
scalability has become a critical issue, leaving the rest of their data solution
as is. As the business and engineering teams grow more familiar with
NoSQL databases and key principles, leaders can make more informed
decisions about how to design the business' overall data architecture.
CONCLUSION
There are areas where a NoSQL database shouldn’t be used, and another
type of database should be considered. For example, an engineering team
uses custom queries to discover and explore relationships within their
data, which provides the metrics needed for business intelligence efforts.
Put simply, probing such data and performing statistical analyses that
do complex database queries will execute poorly in a NoSQL database.
NoSQL has been designed specifically to address database scalability
at the expense of the memory used, the database’s ability to support
custom queries, and data integrity — just as the SQL database was
designed to minimize memory use through the process of normalization.
As SQL database technology evolved, so did its capabilities to handle
efficient custom queries and support data integrity.
REFCARD | NOVEMBER 2022
REFCARD | NOSQL MIGR ATION ESSENTIALS
The basic principles surrounding NoSQL databases aren’t that different
from SQL. The key difference is in normalizing your data versus
denormalizing your data. By walking through an application design step
by step, you saw how data structures can be organized and then put into
a denormalized structure. Finally, I highly encourage you to visit https://
couchbase.live/ and interact with the JSON data to truly experience a
NoSQL database (see Additional Resources). The lessons learned from
the evolution of SQL are being applied to NoSQL in an effort to improve
and strengthen its weaker areas, as well as to continue innovating
simpler ways for organizations to migrate from SQL to NoSQL.
ADDITIONAL RESOURCES
•   "Number of Internet hosts worldwide: 1969–present" – https://
en.wikipedia.org/wiki/History_of_the_Internet#/media/
File:Internet_Hosts_Count_log.svg
•   "Further Normalization of the Data Base Relational Model" –
https://forum.thethirdmanifesto.com/wp-content/uploads/
asgarosforum/987737/00-efc-further-normalization.pdf
•   Couchbase Playground – https://couchbase.live/ (start a
sandbox session and paste this code in the "Query Workbench"
to create the structures and data)
CREATE COLLECTION tutorial._default.bands;
CREATE COLLECTION tutorial._default.songs;
CREATE COLLECTION tutorial._default.band_details;
INSERT INTO tutorial._default.bands (KEY, VALUE)
VALUES
("Arctic Monkeys", {
"Home Screen": "Yes",
"Song Name": "When the Sun Goes Down",
"Year": 2018,
"Peak Chart Pos": 1
}),
("Coldplay", {
"Home Screen": "Yes",
"Song Name": "Yellow",
"Year": 2000,
"Peak Chart Pos": 2
});
INSERT INTO tutorial._default.songs (KEY, VALUE)
VALUES
("Arctic Monkeys - When the Sun Goes Down", {
"Album": "Whatever People Say I Am, That's
What I'm Not",
"Peak Chart Pos": 1,
"Year": 2018,
"Lyrics": "So who's that girl there? I wonder
what went wrong So that she had to roam the streets"
}),
CODE CONTINUES ON NEXT PAGE
8 BROUGHT TO YOU IN PARTNERSHIP WITH
 REFCARD | NOSQL MIGR ATION ESSENTIALS

("Coldplay - Yellow", { And to query, you can try the following:

"Album": "Parachutes",
"Peak Chart Pos": 2,
•   For Home Screen data: SELECT META(b).id AS BandName,

"Year": 2000, b.* FROM tutorial._default.bands b WHERE b.`Home

"Lyrics": "Look at the stars Look how they Screen` = 'Yes';

shine for you And everything you do" •   For Song Details data: SELECT META(b).id AS SongName,
});
b.* FROM tutorial._default.songs b WHERE META(b).id
= 'Coldplay - Yellow'
INSERT INTO tutorial._default.band_details (KEY, VALUE)
VALUES •   For Band Details data: SELECT META(b).id AS BandName,
("Arctic Monkeys", { b.* FROM tutorial._default.band_details b WHERE

"Band Members": [ META(b).id = 'Coldplay';

"Alex Turner",
"Jamie Cook", As an alternative to embedded and/or duplicating data, consider a
"Nick O'Malley", SQL++ query using a join in NoSQL:
"Matt Helders"
•   SELECT META(b).id AS BandName, d.Origin FROM
],
tutorial._default.bands b INNER JOIN tutorial._
"Origin": "Sheffield, England",
default.band_details d ON META(b).id = META(d).id
"Year": 2002,
"Genres": [
"indie rock",
"garage rock",
"post-punk revival", UPDATED BY MATTHEW GROVES,
"psychedelic rock", PRODUCT MARKETING MANAGER
"alternative rock"
Matthew D. Groves is a guy who loves to code.
] It doesn't matter if it's C#, jQuery, or PHP: he'll
}), submit pull requests for anything. He has been
("Coldplay", { coding professionally ever since he wrote a QuickBASIC
point-of-sale app for his parent's pizza shop back in the 90s. He
"Band Members": [ currently works as a Product Marketing Manager for Couchbase. He
"Chris Martin", is the published author of AOP in .NET and Pro Microservices in .NET
"Jonny Buckland", 6, and is also a Microsoft MVP.
"Guy Berryman",
"Will Champion",
"Phil Harvey"
WRITTEN BY FRANK EAVES,
],
SENIOR SOFTWARE ENGINEER
"Origin": "Sheffield, England",
"Year": 2002, Computer programmer with 20+ years' experience
in application development, project and team
"Genres": [
management, and enterprise integration. Currently
"Alternative rock", focusing on full-stack enterprise architecture/applications utilizing
"pop rock", object-oriented programming languages and frameworks (Spring,
"post-Britpop", Angular, Serverless, React, etc.). Additional experience includes
building embedded systems with C and C++, building trading systems
"pop"
with C# (.NET Framework), and machine learning with Python.
]
});

600 Park Offices Drive, Suite 300

Note: This is the same data in the composite table (Table 7) expressed
as a JSON structure. To query this data, you will need minimum indexes:
•   CREATE PRIMARY INDEX ON tutorial._default.bands;
•   CREATE PRIMARY INDEX ON tutorial._default.songs;
•   CREATE PRIMARY INDEX ON tutorial._default.band_
details;
(More detailed indexes will be necessary later to improve performance).
Research Triangle Park, NC 27709
888.678.0399 | 919.678.0300
At DZone, we foster a collaborative environment that empowers developers and
tech professionals to share knowledge, build skills, and solve problems through
content, code, and community. We thoughtfully — and with intention — challenge
the status quo and value diverse perspectives so that, as one, we can inspire
positive change through technology.
Copyright © 2022 DZone, Inc. All rights reserved. No part of this publication
may be reproduced, stored in a retrieval system, or transmitted, in any form or
by means of electronic, mechanical, photocopying, or otherwise, without prior
written permission of the publisher.

REFCARD | NOVEMBER 2022 9 BROUGHT TO YOU IN PARTNERSHIP WITH