update model page

docs/concepts/models/models.md

@@ -16,45 +16,58 @@ Typically business logic is stored as SQL files.
 
 <details>
 <summary> My SQL file </summary>
-customer_data AS (
-
-SELECT
-in0.first_name AS first_name,<N></N>
-in0.last_name AS last_name,<N></N>
-in1.customer_id AS customer_id,<N></N>
-in1.total_amount AS total_amount,<N></N>
-in2.first_order AS first_order,<N></N>
-in2.most_recent_order AS most_recent_order,<N></N>
-in2.number_of_orders AS number_of_orders
-
-FROM raw_customers AS in0<N></N>
-INNER JOIN customer_total_payments AS in1<N></N>
-ON in0.id == in1.customer_id<N></N>
-INNER JOIN ordercount AS in2<N></N>
-ON in0.id == in2.customer_id<N></N>
+with import_orders as (
 
-)
+    select * from {{ ref('orders') }}
+
+),
+aggregate_orders as (
+
+    select
+
+        customer_id,
+        count(order_id) as count_orders
+
+    from import_orders
+    where status not in ('returned', 'return pending')
+    group by 1
 
-SELECT \*
+),
+segment_users as (
 
-FROM customer_data
+    select
+
+        *,
+        case
+            when count_orders >= 3 then 'super_buyer'
+            when count_orders <3 and count_orders >= 2 then
+                'regular_buyer'
+            else 'single_buyer'
+        end as buyer_type
+
+    from aggregate_orders
+
+)
+select \* from segment_users
 
 </details>
 
 But defining the business logic in a SQL file is only the first step. Data-ready teams know that data Modeling with ad-hoc SQL statements is error-prone. How are the SQL files stored? How can the relationships between SQL files be understood? Or the relationships between tables? How is this logic shared? Can the business logic evolve as many team members contribute?
 
 **Teams shouldn't have to puzzle through storing, sharing, and understanding which tables rely on which others. Business logic should be reusable and referenceable in subsequent work.**
 
-In Prophecy and dbt, **Data Models** are SQL statements that incorporate the step-by-step logic to transform raw data to some intermediate or final state. Each Model, stored as a `.sql` file in Git, generally builds a single table or view. The Model can include Common Table Expressions (CTEs) and refer to other Models. Importantly, SQL statements with Prophecy and dbt are re-usable. When a Model is updated, any reference to that Model is likewise updated.
+In Prophecy and dbt, **Data Models** are SQL statements that build a single table or view - and allow for better management.
+
+Data models incorporate the step-by-step logic to transform raw data to some intermediate or final state. Each Model, stored as a `.sql` file on Git, is managed as software - with best practices like peer review and version control. The Model can include Common Table Expressions (CTEs) and [refer](https://docs.getdbt.com/docs/build/sql-models#building-dependencies-between-models) to other Models. Importantly, SQL statements with Prophecy and dbt are re-usable. When a Model is updated, any reference to that Model is likewise updated.
 
-Here we explore how to use Models in Prophecy, adopting the concept and vernacular from dbt Core™. After you've read this page, get hands on with Models in this getting started [guide](/docs/getting-started/getting-started-with-low-code-sql.md#44-develop-your-first-model).
+Here we explore how to use Models in Prophecy, adopting the concept and vernacular from dbt Core™. After you've read this page, get hands on with Models in this getting started [guide](/docs/getting-started/getting-started-with-low-code-sql.md#44-Develop-your-first-model).
 
 ### Using Models in Prophecy
 
 Prophecy displays Models using a lineage view, a visual view, and a code view.
 
 ![lineage-view](./img/lineage-view.png)
-Open the HelloWorld_SQL Project. See the **(1)Lineage** for the HelloWorld_SQL Project pictured above. Each **(2)Project** contains folders of Models, [seeds](/docs/getting-started/getting-started-with-sql.md#431-create-seeds), and sources. The Lineage provides a high level view of the Project's **(3)Models** with **(4)dependencies** displayed from left to right. The `customers` Model depends on seed `raw_customers` and Models `stg_orders` and `stg_payments`. Click to open the `customers` Model as shown in the figure below.
+Open the HelloWorld_SQL Project. See the **(1)Lineage** for the HelloWorld_SQL Project pictured above. Each **(2)Project** contains folders of Models, [seeds](/docs/getting-started/getting-started-with-low-code-sql.md#431-create-seeds), and sources. The Lineage provides a high level view of the Project's **(3)Models** with **(4)dependencies** displayed from left to right. The `customers` Model depends on seed `raw_customers` and Models `stg_orders` and `stg_payments`. Click to open the `customers` Model as shown in the figure below.
 
 ![model-view](./img/model-view.png)
 Now we can explore the `customers` Model more closely. The Model is easy to understand with interchangable **(1)visual** and **(2)code** views. The visual view depicts each small step needed to move from the referenced tables/seeds/Models to the final `customers` Model. Each transformation step or Common Table Expression (CTE) is called a **(3)Gem** in Prophecy.