PRESENTED BY TEAM 4 :

S I M O N T I UB R O W LY D OM O O N S O O C H O IJ A S O N C A IC H R I S T I N A Y O UL O R A I N E L IKAT Y N O M U R A

Nevada Partnership For Homeless Youth

Organization Overview

Nevada Partnership for Homeless Youth (NPHY) is an organization that focuses on eliminating homelessness among Nevada’s Youth.

In order to tackle this immense problem strategically, NPHY has mobilized a few successful programs: Drop-in Center Independent Living Emergency Center

Data not only enables NPHY to assess their effectiveness, it also allows NPHY to plan for future growth and projects.

Organization GoalsDonor Tracking and Analysis

• A system which can track past donors and potential future donors

• Analysis of a donor’s contribution to the organization

Client/Alumni information and updatability

• Management of daily Case File updates through user-friendly interface

• Tracking of AlumniResource Management and

Fundraising• Analysis of which events are most

effective• A system to track current

inventory and forecast future demands (client needs)

Project Review

DP 1• Project

Conceptualization

• Simplified EER Diagram

• Defined entities

DP 2• Query Creation• EER expansion

• Classes• Fundraising

Events• Implementation of

queries in relational algebra

• Relations implementedin Access

DP 3• Major query revision• Complexities added

with AMPL and sub-queries

• Query implementation in SQL

• Minor EER refinement

• Forms implemented Final Result• Query

Implementation• Analysis Options• Complete EER• Normalization

Analysis

Access Relationships

Query 1 – Demand Seasonality

Observation: Demand for services exhibits strong seasonality.

Purpose: Extract the data of how many services are provided for each different month over previous years during the same month. The query will count numbers of different services provided monthly.

Usage of the data: For each month, we apply a linear regression function .lm in R to find linear regression equation: ŷ = ax + b. Where ŷ is the estimated demand per month. X is the year we are looking at.

If the linear regression line shows strong confidence, NPHY can use the line to predict future demand for a specific month and type of service. If the linear equation shows a increasing or decreasing trend, it can also tell NPHY to expand or reallocate resources.

SQL:SELECT p.Program_Type AS ProgramType, s.Month AS [Month], s.Year AS [Year], Count(s.client_ID) AS CountOfclient_IDFROM service AS s, program AS pWHERE (((p.program_ID)=[s].[program_ID]))GROUP BY p.Program_Type, s.Month, s.Year, [p].[Program_Type] And [s].[Month] And [s].[Year]ORDER BY s.Month, s.Year;

Query 1 - Access

2002 2004 2006 2008 2010

6080

100

120

Demand for drop-in center for January, 2001-2011

Year

num

ber o

f ser

vice

pro

vide

d

Regression line summary:

lm(formula = demand[jan, ]$count ~ demand[jan, ]$year)Residuals: Min 1Q Median 3Q Max -13.182 -4.291 -3.309 4.691 21.764 Coefficients: Estimate Std. Error t value Pr(>|t|) (Intercept) -1.392e+04 1.973e+03 -7.054 5.96e-05 ***demand[jan, ]$year 6.982e+00 9.838e-01 7.097 5.69e-05 ***---Signif. codes: 0 ‘***’ 0.001 ‘**’ 0.01 ‘*’ 0.05 ‘.’ 0.1 ‘ ’ 1 Residual standard error: 10.32 on 9 degrees of freedomMultiple R-squared: 0.8484, Adjusted R-squared: 0.8316 F-statistic: 50.37 on 1 and 9 DF, p-value: 5.686e-05

Therefore, b = -1.392e+04 , a = 6.982e+00 for equation ŷ = ax + b

Query 2 – Event Analysis

Purpose: To aid in fundraising by looking at which events raise the most money and forecasting times in which demand is high.

Use: The organization will be able to observe which type of event cost less and profit more, and determine which type of events to hold more often. 

In addition, based on which type of resource is donated the least, for the future events, the organization may ask the donors for specific type of resources.

Observation: Not all events are created equal. In order to make fundraising more efficient, we want to visually observe the effectiveness of different events in terms of monetary benefit.

Query 2 - Access

SQL:SELECT a.DateofEvent, Sum(Donation.Monetary_Value) AS SumOfMonetary_Value, Count(Donation.Donor_ID) AS No_of_Donors, -1*Sum(Donation.Type_1_Food) AS Type_1_Food,-1*Sum(Donation.Type_2_Clothing) AS Type_2_Clothing,-1*Sum(Donation.Type_3_Money) AS Type_3_Money,-1*Sum(Donation.Type_4_Furniture) AS Type_4_Furniture, -1*Sum(Donation.Type_5_Other) AS Type_5_Other, a.Event_ID, a.Event_Type, Sum(a.Cost) AS Cost, Sum(a.Profit) AS Profit, ((a.Revenue)-(a.Cost))/((a.Cost)) AS Profit_Margin

FROM Donation, Fr_Event AS a WHERE (((Donation.Event_ID)=[a].[Event_ID])) GROUP BY a.DateofEvent, a.Event_ID, a.Event_Type, ((a.Revenue)-(a.Cost))/(a.Cost);

Query 3 – Asset Management Observation: The supply and

demand of inventory (food, supplies, etc.) can be modeled as a classic inventory problem.

Purpose: To optimize donation revenue while taking into consideration the event costs.

Implementation: This is an integer-programming problem that will be solved by using AMPL. The objective is to maximize the monthly donation from donors based on historical revenue subtracted by the cost of the selected held events. The costs of running events depend on the event location and month.

n

1ijjijij1-j

n

1ij1-jijij

n

1i

12

1jijij

1,...,12=j y=d-xe+y

1,...,12=j dyxe

F=y(0) s.t.

xc=z min:obj

cij: cost of event i during month jeij: donation received of event i during month jxij=1 if event i during month j will be held,

=0, otherwise

yj: the money leftoverdj: demand of money in month j

Query 3 – Access

SQL:TRANSFORM Avg(Fr_Event.Cost)SELECT Fr_Event.Event_ID, Avg(Fr_Event.Cost) AS [Yearly Avg]FROM Fr_EventGROUP BY Fr_Event.Event_IDPIVOT Format([DateofEvent],"mmm") In ("Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec");

Query 3 – Access

SQL:TRANSFORM Avg(Fr_Event.Profit) AS AvgOfProfitSELECT Fr_Event.Event_IDFROM Fr_EventGROUP BY Fr_Event.Event_IDPIVOT Format([DateofEvent],"mmm") In ("Jan","Feb","Mar","Apr","May","Jun","Jul","Aug","Sep","Oct","Nov","Dec");

Query 3 – Access Cont.

SQL:SELECT Format([Consumption Date],'mmm/yyyy') AS [Month/Year], Sum(Resources.[Monetary_Value]) AS TotalFROM Donation INNER JOIN (Resources INNER JOIN Resource_Consumption ON Resources.[Item_ID] = Resource_Consumption.Item_ID) ON Donation.Donation_ID = Resources.[Donation_ID]GROUP BY Format([Consumption Date],'mmm/yyyy');

SQL:SELECT Format([Month/Year],'mmm') AS [Month], Avg([Query 3: Monthly Demand (1/2)].Total) AS DemandFROM [Query 3: Monthly Demand (1/2)]GROUP BY Format([Month/Year], 'mmm');

Query 3—Massaging the Data

Query 3: AMPL

Query 3: AMPL

Running AMPL

Observation: We want to create a scale to measure donors. An effective ranking of donors will allow us to focus our fundraising efforts on areas of weakness and enable us to use a variety of other queries (i.e. Query 5)Purpose: Rank the donors according based on user-defined heuristics. Implementation: In order to rank these donor appropriately, we take into consideration the monetary values of the items that they donate and the variety of items. Our sample access implementation is as follows:

Query 4 – Ranking Donors

Item Type WeightFood 0.8Money 1Gift Card 0.8Furniture 0.6Other 0.5

Query 4 - Access

SQL:SELECT D.Donor_ID, (Sum (Monetary_Value * weight)) * (1 + Count (Item_type)/10) AS Donor_IndexFROM Donor AS D, Resource AS R, Resource_weight AS RWWHERE D.Donor_ID = R.Donor_ID AND R.Item_type = RW.Item_typeGROUP BY D.Donor_ID;

1 2 3 4 5 6 7 8 9 10 11 12 130

2000400060008000

10000

Donor Effectiveness

Donor ID

Don

or I

ndex

Observation: In order to raise money most effectively, events should be placed closer to donors who will contribute more. Calculating an event location closer to the more important donors as rated by our previous query will give us a better sense of an optimal location.Purpose: Find an optimal location for events considering donor importance.

Query 5 – Event Planning

Implementation: 1) From SQL, we get two tables: one for latitude and

longitude of the potential locations for the fundraising events (Plat, Plong) and another for the location of donors (Donor_ID, latitude, longitude).

2) Input the data extracted from SQL and construct a function in Matlab to find out the optimum location of the fundraising event.

3) For each potential location i, sum up the weighted distance to every donor according to the formula: The max of the sum of these weights will give us the best location.

Query 5 - Access

Select L.Latitude AS Plat, L.Longitude AS PlongFrom Donor AS D, Location AS LWhere D.Location_ID = L.Location_ID AND D.Hold_event = 1UNION Select L.Latitude AS Plat, L.Longitude AS PlongFrom FR_Event AS E, Location AS LWhere E.Location_ID = L.Location_ID

Possible Locations

SELECT Donor.Donor_ID, Location.Latitude, Location.LongitudeFROM Location, DonorWHERE (((Location.Location_ID)=[Donor].[Location_ID]))ORDER BY Donor.Donor_ID;

MatLab

Normalization Analysis

Donor Relation Donor(SSN27, Donor_ID, Last_Name,

First_Name, E-mail, Phone, Address, City, State/Province, Zip_Code, Country/Region, Location_ID44)

This is already in first normalized form because it contains no multivalued attributes.

Functional Dependencies

{SSN, Donor_id} {Add,City,State} {SSN} {Fname,Lname} {Donor_id} -> {E-mail,Phone, Location_id} {State} {Country} {Add,City,State} {Zip} {Zip} {City,State}

2NF Normalization

Dname(SSN27, Fname, Lname) DContact(Donor_id, E-mail, Phone, Location_ID44) DAdd(SSN27, Donor_id, Add, City, State, Zip,

Country) This removes all partial dependencies that the

non-prime attributes have on the CK by making them each their own relation.

Donor(SSN27, Donor_ID, Last_Name, First_Name, E-mail, Phone, Address, City, State/Province, Zip_Code, Country/Region, Location_ID44)

3NF Normalization

Dname(SSN27, Fname, Lname) DContact(Donor_id, E-mail, Phone, Location_ID44) DAdd(SSN27, Donor_id, Add, City, State) LocationofDonor(Add, City, State, Zip) CountryLocation(State, Country) LocationofDonor removes the transitive dependency that

exists from Add, City, and State determining country, and zip. Moreover, the State determines the Country.

Dname(SSN27, Fname, Lname)DContact(Donor_id, E-mail, Phone, Location_ID44)DAdd(SSN27, Donor_id, Add, City, State, Zip, Country)

BCNF Normalization

Dname(SSN27, Fname, Lname) DContact(Donor_id, E-mail,

Phone, Location_ID44) DAdd(SSN27, Donor_id, Add,

City, State) LocationofDonor(Add, zip) ZipofDonor(Zip, City, State) CountryLocation(State,

Country)

Dname(SSN27, Fname, Lname)DContact(Donor_id, E-mail, Phone, Location_ID44)DAdd(SSN27, Donor_id, Add, City, State)LocationofDonor(Add, City, State, Zip)CountryLocation(State, Country)

Because Add, City, State determine zip, but zip determines city and state, the previous normalization was in 3NF but not in BCNF. By breaking up the LocationofDonor relation into two relations LocationofDonor and ZipofDonor, the relation can be normalized into BCNF.

Future Work

Add More Queries Ex: add a query that will produce a schedule for

employees and volunteers Ex: add a query that will help plan future outreach,

possibly via social networking Improve Current Queries

Ex: add more graphs and features to the current queries to improve functionality

Automation of the Process Add functionality that will read files to automate data

entry Write macros to automate usage of the database