Grammar fixes + clarification @ "Data Modeling Considerations"

source/core/data-modeling.txt

@@ -24,7 +24,7 @@ you can model your documents in MongoDB so that they can closely
 resemble and reflect application-level objects.
 
 As in all data modeling, when developing data models (i.e. *schema
-designs,*) for MongoDB you must consider the inherent properties and
+designs*) for MongoDB, you must consider the inherent properties and
 requirements of the application objects and the relationships between
 application objects. MongoDB data models must also reflect:
 
@@ -37,21 +37,23 @@ number of multi-factored decisions when modeling data, including:
 
 - normalization and de-normalization.
 
-  These decisions reflect degree to which the data model should store
-  related pieces of data in a single document **or** should the data
-  model describe relationships using :doc:`references
-  </applications/database-references>` between documents.
+  These decisions reflect the degree to which the data model should
+  store related pieces of data in a single document. Fully normalized
+  data models describe relationships using :doc:`references
+  </applications/database-references>` between documents, while
+  de-normalized models may store redundant information across related
+  models.
 
 - :doc:`indexing strategy </applications/indexes>`.
 
 - representation of data in arrays in :term:`BSON`.
 
 Although a number of data models may be functionally equivalent for a
-given application; however, different data models may have significant
-impacts on MongoDB and applications performance.
+given application, different data models may have significant impacts on
+MongoDB and applications performance.
 
 This document provides a high level overview of these data modeling
-decisions and factors. In addition, consider, the
+decisions and factors. In addition, examine the
 :ref:`data-modeling-examples` section which provides more concrete
 examples of all the discussed patterns.