diff --git a/02_activities/assignments/DC_Cohort/Assignment1.md b/02_activities/assignments/DC_Cohort/Assignment1.md index f78778f5b..abafb10b6 100644 --- a/02_activities/assignments/DC_Cohort/Assignment1.md +++ b/02_activities/assignments/DC_Cohort/Assignment1.md @@ -205,5 +205,7 @@ Consider, for example, concepts of fariness, inequality, social structures, marg ``` -Your thoughts... +Data systems and databases are organized collections of data that allow efficient processing over multiple datasets, including up-to-date maintenance, comparisons, storage, and retrieval. These are highly useful, as they provide access to a multitude of up-to-date information regarding a person/system. For example, libraries can use it to catalog books, which books are signed out, and when a book was returned. This can extend to more critical systems such as medical history, tax records, and government-issued IDs/SINs, allowing us to have access to records in emergency and identity cases. For medical records, having a complete medical history per person in a shared database (provincial or federal) would allow easy transfer of data. Thus, if you switch doctors or end up in the ER, all past medical history would be available without having to rely on the patient’s memory, leading to a reduced chance of medical error. Similarly, if tax records are centralized, then all past history regarding employment and income would be readily available if anyone ever needs to dispute any claims or if they made an error while filing. Government ID/SIN-like databases are also of importance since they act as easily verifiable unique identifiers compiled from multiple parameters, thus allowing access to benefits, services, and the ability to work legally (to name a few). +On a day-to-day basis we encounter many systems that rely on databases to store our information: banks (e.g. accounts, investments, loans, credit), government-related systems (e.g. CRA, SINs, census), health-related systems (e.g. pharmacy, insurance, OHIP, blood banks), education (e.g. courses, degree eligibility, tuition), subscriptions (e.g. shopping, newsletters), and social media/emails, to name a few. Most of these data systems have our full names, work/home address, email, age, ethnicity, sex, and gender. Generally, we provide this information freely. However, we usually don't stop to contemplate how this information could be (mis)used. One major possible issue is the potential for discrimination by people that have access to these databases (directly or indirectly). This includes discrimination based on sex, gender, age, class (via last name or familial ties/history), marital status, ethnicity, citizenship, socioeconomic status (SES), education status, or medical history (e.g. for employment or insurance claims). Unfortunately, the given reason for rejection does not have to be from the bias, thus resulting in "legal" rejections fueled by hidden biases. Another problem is many of these digital databases rely heavily on people knowing how to use and having access to technology, requiring a certain skill level from the user (which can be impacted by education, SES, and age). Other issues are related to security (like cyberattacks, e.g. Microsoft/Qantas) leading to identity theft/misuse, lack of flexibility for updating categories (e.g. adding more options to gender and ethnicity in recent times), and relying solely on digital data systems (could result in a lack of access to the database in the event of outages, e.g. Bell Canada/CRA/AWS). +We work under the assumption that databases are a secure and objective compilation of information, which will not be misused. While this might be true in the majority of cases, it is always good to remain vigilant. Blinding/coding sensitive/identifier data where possible, making it accessible to less technologically experienced people, make disputes regarding stored data easy to update (when provided in conjunction with verification), keeping the data and security up to date, having backup measures in case the digital database fails, and keeping the database fluid so that it can be amended based on the societal norms of the time are some of the many ways we can use data systems to their full potential while accounting for various systemic issues. ``` diff --git a/02_activities/assignments/DC_Cohort/Assignment1_LogicDataModel_DC.png b/02_activities/assignments/DC_Cohort/Assignment1_LogicDataModel_DC.png new file mode 100644 index 000000000..bbd4475f6 Binary files /dev/null and b/02_activities/assignments/DC_Cohort/Assignment1_LogicDataModel_DC.png differ diff --git a/02_activities/assignments/DC_Cohort/assignment1.sql b/02_activities/assignments/DC_Cohort/assignment1.sql index c992e3205..fa8210e1e 100644 --- a/02_activities/assignments/DC_Cohort/assignment1.sql +++ b/02_activities/assignments/DC_Cohort/assignment1.sql @@ -4,17 +4,38 @@ --SELECT /* 1. Write a query that returns everything in the customer table. */ +SELECT + customer_id, + customer_first_name, + customer_last_name, + customer_postal_code +FROM customer; - -/* 2. Write a query that displays all of the columns and 10 rows from the cus- tomer table, +/* 2. Write a query that displays all of the columns and 10 rows from the customer table, sorted by customer_last_name, then customer_first_ name. */ - +SELECT + customer_id, + customer_first_name, + customer_last_name, + customer_postal_code +FROM customer +ORDER BY customer_last_name ASC, customer_first_name ASC +LIMIT 10; --WHERE /* 1. Write a query that returns all customer purchases of product IDs 4 and 9. */ - +SELECT + product_id, + vendor_id, + market_date, + customer_id, + quantity, + cost_to_customer_per_qty, + transaction_time +FROM customer_purchases +WHERE product_id IN (4, 9); /*2. Write a query that returns all customer purchases and a new calculated column 'price' (quantity * cost_to_customer_per_qty), @@ -22,11 +43,31 @@ filtered by customer IDs between 8 and 10 (inclusive) using either: 1. two conditions using AND 2. one condition using BETWEEN */ --- option 1 - - --- option 2 - +-- option 1 (using AND) +SELECT + product_id, + vendor_id, + market_date, + customer_id, + quantity, + cost_to_customer_per_qty, + transaction_time, + (quantity * cost_to_customer_per_qty) AS price +FROM customer_purchases +WHERE customer_id >=8 AND customer_id <=10; + +-- option 2 (using BETWEEN) +SELECT + product_id, + vendor_id, + market_date, + customer_id, + quantity, + cost_to_customer_per_qty, + transaction_time, + (quantity * cost_to_customer_per_qty) AS price +FROM customer_purchases +WHERE customer_id BETWEEN 8 AND 10; --CASE @@ -34,20 +75,50 @@ filtered by customer IDs between 8 and 10 (inclusive) using either: Using the product table, write a query that outputs the product_id and product_name columns and add a column called prod_qty_type_condensed that displays the word “unit” if the product_qty_type is “unit,” and otherwise displays the word “bulk.” */ - +SELECT + product_id, + product_name, + CASE + WHEN product_qty_type = 'unit' THEN 'unit' + WHEN product_qty_type IS NULL THEN NULL + ELSE 'bulk' + END AS prod_qty_type_condensed +FROM product; /* 2. We want to flag all of the different types of pepper products that are sold at the market. add a column to the previous query called pepper_flag that outputs a 1 if the product_name contains the word “pepper” (regardless of capitalization), and otherwise outputs 0. */ - +SELECT + product_id, + product_name, + CASE + WHEN product_qty_type = 'unit' THEN 'unit' + WHEN product_qty_type IS NULL THEN NULL + ELSE 'bulk' + END AS prod_qty_type_condensed, + CASE + WHEN lower(product_name) LIKE '%pepper%' THEN 1 + ELSE 0 + END AS pepper_flag +FROM product; --JOIN /* 1. Write a query that INNER JOINs the vendor table to the vendor_booth_assignments table on the vendor_id field they both have in common, and sorts the result by vendor_name, then market_date. */ - - +SELECT + v.vendor_id, + v.vendor_name, + v.vendor_type, + v.vendor_owner_first_name, + v.vendor_owner_last_name, + vba.booth_number, + vba.market_date +FROM vendor AS v +INNER JOIN vendor_booth_assignments AS vba + ON v.vendor_id = vba.vendor_id +ORDER BY vendor_name ASC, market_date ASC; /* SECTION 3 */ @@ -55,7 +126,11 @@ vendor_id field they both have in common, and sorts the result by vendor_name, t -- AGGREGATE /* 1. Write a query that determines how many times each vendor has rented a booth at the farmer’s market by counting the vendor booth assignments per vendor_id. */ - +SELECT + vendor_id, + count(vendor_id) AS booth_count +FROM vendor_booth_assignments +GROUP BY vendor_id; /* 2. The Farmer’s Market Customer Appreciation Committee wants to give a bumper @@ -63,7 +138,17 @@ sticker to everyone who has ever spent more than $2000 at the market. Write a qu of customers for them to give stickers to, sorted by last name, then first name. HINT: This query requires you to join two tables, use an aggregate function, and use the HAVING keyword. */ - +SELECT + c.customer_id, + c.customer_first_name, + c.customer_last_name, + round(sum(cp.quantity * cp.cost_to_customer_per_qty), 2) AS total_price +FROM customer AS c +INNER JOIN customer_purchases AS cp + ON c.customer_id = cp.customer_id +GROUP BY c.customer_id +HAVING sum(cp.quantity * cp.cost_to_customer_per_qty) > 2000 +ORDER BY customer_last_name ASC, customer_first_name ASC; --Temp Table @@ -77,15 +162,27 @@ When inserting the new vendor, you need to appropriately align the columns to be -> To insert the new row use VALUES, specifying the value you want for each column: VALUES(col1,col2,col3,col4,col5) */ +DROP TABLE IF EXISTS temp.new_vendor; +CREATE TABLE temp.new_vendor AS +SELECT * +FROM vendor; + +INSERT INTO new_vendor (vendor_id, vendor_name, vendor_type, vendor_owner_first_name, vendor_owner_last_name) +VALUES (10, 'Thomass Superfood Store', 'Fresh Focused', 'Thomas', 'Rosenthal'); - +SELECT * +FROM new_vendor; -- Date /*1. Get the customer_id, month, and year (in separate columns) of every purchase in the customer_purchases table. HINT: you might need to search for strfrtime modifers sqlite on the web to know what the modifers for month and year are! */ - +SELECT + customer_id, + strftime('%m', market_date) AS month, + strftime('%Y', market_date) AS year +FROM customer_purchases; /* 2. Using the previous query as a base, determine how much money each customer spent in April 2022. @@ -93,4 +190,11 @@ Remember that money spent is quantity*cost_to_customer_per_qty. HINTS: you will need to AGGREGATE, GROUP BY, and filter... but remember, STRFTIME returns a STRING for your WHERE statement!! */ - +SELECT + customer_id, + strftime('%m', market_date) AS month, + strftime('%Y', market_date) AS year, + sum(quantity * cost_to_customer_per_qty) AS total_price2 +FROM customer_purchases +WHERE strftime('%m', market_date) = '04' AND strftime('%Y', market_date) = '2022' +GROUP BY customer_id;