De berekening steunt op de methode van de kleinste kwadraten. De slope (β) wordt gedefinieerd als de covariantie van de onafhankelijke variabele X en de afhankelijke variabele Y gedeeld door de variantie van X. De intercept (α) wordt afgeleid van het gemiddelde van Y min het product van de slope en het gemiddelde van X. In ANSI SQL implementeer je deze algebraïsche definities met behulp van SUM, AVG, en COUNT aggregaten, typisch binnen een GROUP BY clausule of als vensterfuncties met een OVER clausule. De query moet expliciet de som van de kruisproducten (Σ(X - X̄)(Y - Ȳ)) en de som van de gekwadrateerde afwijkingen voor X (Σ(X - X̄)²) berekenen om de uiteindelijke coëfficiënten te bepalen.
Een retail analytics team moest de prijsgevoeligheid van de vraag voor elke productcategorie bepalen om dynamische prijsstrategieën te optimaliseren. Ze beschikten over een transactietabel met unit_price en quantity_sold, en hadden een trendlijn nodig die quantificeerde hoe de verkochte hoeveelheid veranderde met de prijs voor elke afzonderlijke category_id.
Een voorgestelde oplossing was het exporteren van dagelijkse aggregaten naar een extern Python-script dat gebruik maakte van scikit-learn om regressiemodellen te passen. Deze benadering bood eenvoud in implementatie en toegang tot rijke statistische diagnostiek. Echter, het introduceerde significante datalatenstijd, schond strikte gegevensbeheerbeleid door externe kopieën van gevoelige verkoopgegevens te creëren, en verhinderde de benodigde realtime dashboardupdates voor geautomatiseerde prijsalgoritmen.
Een andere optie die werd overwogen was het creëren van een gebruikersgedefinieerde aggregatiefunctie (UDAF) binnen de database-engine, die syntaxis mogelijk zou maken zoals REGRESS_SLOPE(price, quantity). Hoewel elegant en herbruikbaar, zou dit de draagbaarheid over verschillende databasesystemen opofferen en vereiste het verhoogde administratieve rechten om te implementeren, waardoor het ongeschikt werd voor een afgeschermde, multi-tenant cloud datawarehouse omgeving.
De gekozen oplossing implementeerde de algebraïsche formules direct in ANSI SQL met gebruik van standaardaggregaten. Het team maakte gebruik van SUM en AVG vensterfuncties gepartitioneerd op category_id om de benodigde covariantie- en variantietermen in één doorgang over de gegevens te berekenen. Deze aanpak hield de berekening samen met de data, elimineerde extract-transform-load (ETL) vertragingen, en hield zich strikt aan de draagbare ANSI SQL-normen zonder proprietaire extensies. Het resultaat was een sub-seconde latentie prijs elasticiteitsdashboard dat automatisch werd bijgewerkt zodra er nieuwe transacties binnenkwamen, waardoor de geautomatiseerde prijsalgoritmen in realtime marges konden aanpassen.
Hoe ga je om met NULL-waarden in X of Y zonder de berekening van de hele groep ongeldig te maken?
Kandidaten vergeten vaak dat, hoewel ANSI SQL aggregatiefuncties NULL's negeren, rekenkundige bewerkingen met betrokken NULL's NULL retourneren. Bij het berekenen van de covariatieterm SUM((x - avg_x) * (y - avg_y)), als een van beide x of y NULL is voor een specifieke rij, wordt het product NULL en wordt die rij uitgesloten van de som. Dit voert effectief pairwise verwijdering uit, wat meestal gewenst is, maar men moet ervoor zorgen dat de COUNT die wordt gebruikt voor vrijheidsgraden in variantieberekeningen het aantal niet-NULL paren weerspiegelt, niet het totale aantal rijen. De oplossing is om te filteren WHERE x IS NOT NULL AND y IS NOT NULL in een subquery of COUNT(x) te gebruiken (wat gelijk is aan COUNT(y) na filtering) in plaats van COUNT(*), wat zorgt voor consistente noemers in alle aggregatietermen.
Wat is het onderscheid tussen het berekenen van regressie over een populatie versus een steekproef, en hoe beïnvloedt dit je SQL-query?
Veel kandidaten passen de steekproefvariantieformule (delen door n - 1) inconsistent toe bij de covariantieformule. In ANSI SQL behandelen ingebouwde functies zoals VAR_POP en VAR_SAMP dit onderscheid, maar wanneer je zelf variantie berekent als SUM(POWER(x - avg_x, 2)) / COUNT(*), moet je bewust kiezen welke noemer je gebruikt. Voor de berekening van de slope, als je de variantie van X handmatig in de noemer berekent, moet je deze matchen met de deler van de covariantieberekening. Als je ze mengt (bijvoorbeeld steekproefcovariantie gedeeld door populatievariantie) krijg je een bevooroordeelde slope. De gecorrigeerde aanpak is om te beslissen over het statistische kader (populatie vs. steekproef) en dezelfde delerlogica (of n of n-1) op zowel de covariantiemeter als de variantie noemer toe te passen.
Hoe zou je de coëfficiënt van determinatie (R²) berekenen om de geschiktheid van de pasvorm binnen dezelfde query te meten?
Kandidaten vergeten vaak validatiemetrics. R² wordt berekend als 1 - (SS_res / SS_tot), waar SS_res de som van de gekwadrateerde residuen (Σ(y - ŷ)²) is en SS_tot de totale som van de kwadraten (Σ(y - ȳ)²) is. Het berekenen van ŷ (voorspeld y) vereist de slope en intercept die in eerdere stappen zijn berekend. In ANSI SQL kun je dit berekenen met gestapelde Common Table Expressions (CTE's): bereken eerst de gemiddelden, bereken dan de slope en intercept in een tweede CTE, en bereken ten slotte de gekwadrateerde verschillen tussen werkelijke en voorspelde waarden in de buitenste query. Een veelgemaakte fout is te proberen de berekende slope binnen hetzelfde aggregatieniveau waar hij is berekend te refereren, wat de logische verwerkingsvolgorde schendt. De oplossing is om de logica in sequentiële CTE's te scheiden, zodat de berekende coëfficiënten kunnen worden hergebruikt als constanten in de finale aggregatie voor R².