Migration lab update. Wording changes, typos, and an image update (#92)

Author: amazon-wolfe

content/hands-on-labs/rdbms-migration/migration-chapter02.en.md

@@ -23,5 +23,5 @@ The CloudFormation template used below will create Source VPC, EC2 hosting MySQL
 
 
 {{% notice note %}}
-_Do not continue unles the MySQL instance is passing both health checks, 2/2._
+_Do not continue unless the MySQL instance is passing both health checks, 2/2._
 {{% /notice %}}

content/hands-on-labs/rdbms-migration/migration-chapter03.en.md

@@ -37,7 +37,7 @@ It has also configured a remote MySQL user based on the CloudFormation input par
   mysql -u DbMasterUsername -pDbMasterPassword
   ```
    ![Final Deployment Architecture](/images/migration14.jpg)
-10. Congratulations! you are now connected to a self-managed MySQL source database on EC2. In next steps we will explore database and tables hosting IMDb datasets
+10. Congratulations! You are now connected to a self-managed MySQL source database on EC2. In next steps, we will explore database and tables hosting IMDb datasets
   ```bash
   use imdb;
   ```
@@ -58,7 +58,7 @@ For illustration purpose, below is a logical diagram represents relationship bet
   - name_basics has cast and crew details. Every member has unique nconst value assigned.
   ![Final Deployment Architecture](/images/migration31.jpg)
 
-12. We will create denormalized view with 1:1 static information and get it ready for migration to Amazon DynamoDB table. For now, go ahead and copy below code and paste into mysql command line.
+12. We will create denormalized view with 1:1 static information and get it ready for migration to Amazon DynamoDB table. For now, go ahead and copy below code and paste into the MySQL command line.
 The details around target data model will be discussed in the next chapter.
 ```bash
 CREATE VIEW imdb.movies AS\
@@ -87,7 +87,7 @@ CREATE VIEW imdb.movies AS\
     LEFT JOIN imdb.name_basics nm ON tp.nconst = nm.nconst\
     LEFT JOIN imdb.title_crew tc ON tc.tconst = tp.tconst;
   ```
-  Use below command to review count of records from the denormalized view. At this point you source database is ready for migration to Amazon DynamoDB.
+  Use below command to review count of records from the denormalized view. At this point, your source database is ready to migrate to Amazon DynamoDB.
   ```bash
   select count(*) from imdb.movies;
   ```

content/hands-on-labs/rdbms-migration/migration-chapter04.en.md

@@ -17,11 +17,11 @@ A common approach to DynamoDB schema design is to identify application layer ent
 In DynamoDB, this means using [composite sort keys](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-sort-keys.html), [overloaded global secondary indexes](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-gsi-overloading.html), and other design patterns.
 
 
-In this scenario, we will follow the [Adjacency List Design Pattern](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-adjacency-graphs.html#bp-adjacency-lists) with primary key overloading to store relational data in the DynamoDB table. The advantages of this pattern includes optimal data duplication and simplified query patterns to find all metadata related to each movie. Normally the adjacency list pattern stores duplicate data under two items, each representing one half of the relationship. To associate a title with a region, for example, you would write one item for the region under the title and one item under the title under the region, like this:
+In this scenario, we will follow the [Adjacency List Design Pattern](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-adjacency-graphs.html#bp-adjacency-lists) with primary key overloading to store relational data in the DynamoDB table. The advantages of this pattern include optimal data duplication and simplified query patterns to find all metadata related to each movie. Normally the adjacency list pattern stores duplicate data under two items, each representing one half of the relationship. To associate a title with a region, for example, you would write one item for the region under the title and one item under the title under the region, like this:
 
 | Partition Key        |  Sort Key           | Attribute List         |
 | ------------- |:-------------:|:-------------:|
-| tt0309377     | REGN\|NZ | ordering, language, regiion, title, types |
+| tt0309377     | REGN\|NZ | ordering, language, region, title, types |
 | REGN\|NZ      | tt0309377 | language, region, title  |
 
 However in this lab we'll only work with one side of the relationship: the data residing under the title. Our partition key will be `mpkey` and our sort key `mskey` for the movies table. Each partition and sort key is prefixed with letters to identify the entity type, and the sort key uses `|` as a separator between the entity type and value.

content/hands-on-labs/rdbms-migration/migration-chapter05.en.md

@@ -242,7 +242,7 @@ Replace the string “REPLACE THIS STRING BY MOVIES LIST” with list of movies
 ![Final Deployment Architecture](/images/migration36.png)
 Go to the bottom and click on Create task. At this point the task will be created and will automatically start loading selected movies from source to target DynamoDB table. 
 You can move forward and create two more tasks with similar steps (historical-migration02 and historical-migration03).
-Keep rest of the parameter as is except the JSON document. For historical-migration02 and historical-migration03 tasks use the JSON document mentioned below.
+Use the same settings as above except the Table Mappings JSON document. For historical-migration02 and historical-migration03 tasks use the JSON document mentioned below.
 
 Below JSON document will migrate title_akas table from imdb MySQL database (Task identified: historical-migration02)
 Replace the string "REPLACE THIS STRING BY MOVIES LIST" with list of movies copied earlier.