Przeciążenie informacją (ang. information overload) to zjawisko, które z biegiem czasu będziemy odczuwać coraz bardziej. Dotyczy to zarówno życia zawodowego jak i osobistego. Zgodnie z definicją, jest to sytuacja, w której mamy dostęp do zbyt dużej ilości informacji, aby podjąć decyzję. Bez wątpienia, w znacznym stopniu, do takiego stanu rzeczy przyczynił się dynamiczny rozwój Internetu i opartych na nim usług.

Badania przeprowadzone przez naukowców z MIT Center for Digital Business wskazują, że podejmowanie decyzji opartych na danych (ang. data-driven decision making) skutkuje wśród przedsiębiorstw średnio 4% wzrostem produktywności oraz 6% wzrostem dochodu. Coraz więcej branż zaczyna podejmować decyzje oparte na danych, odsyłając do przysłowiowego lamusa te oparte wyłącznie na obserwacji lub intuicji. Bezpośrednim rezultatem tej transformacji jest zwiększony popyt na rynku pracy na specjalistów od danych. Stanowiska takie jak analityk danych czy inżynier danych coraz częściej pojawiają się w ogłoszeniach o pracę.

Czy w swojej codziennej pracy podejmujesz decyzje oparte na danych? Czy w pełni wykorzystujesz moc ukrytą w danych? Na prostym przykładzie chciałbym pokazać Ci, jak znajomość podstaw języka SQL może pomóc w podejmowaniu trafnych decyzji.

Czym jest SQL?

SQL (ang. Structured Query Language) to, upraszczając, podstawowy język pozwalający na rozmowę z danymi. Tak jak język angielski stał się standardem w komunikacji międzynarodowej, tak bez SQL’a ani rusz w świecie danych. Uściślając, jest to oficjalny standard, wykorzystywany do komunikacji z relacyjnymi bazami danych (ang. relational database). Jego biegła znajomość to podstawowe wymaganie w prawie każdym ogłoszeniu o pracy na stanowiska z zakresu analizy danych. Jednak już nawet podstawowa znajomość może pozwolić na zrozumienie zależności kryjących się w danych.

Zacznijmy od prostego przykładu zapytania, jakie można zadać bazie danych za pośrednictwem języka SQL:

SELECT last_name FROM employees WHERE first_name = 'Olga';

Polski odpowiednik powyższego zapytania brzmiałby: Hej bazo! Zwróć mi nazwiska wszystkich pracowników, którzy mają na imię Olga.

Nie można jednak mówić o języku SQL, bez kilku zdań wprowadzenia na temat relacyjnych baz danych.

Relacyjne bazy danych

Relacyjna baza danych to duży worek na dane. Składa się z ona tabel, najczęściej wielu. Przykładem tabeli, z powyższego zapytania jest tabela o nazwie employees. Tabela jest to uporządkowany zbiór danych wewnątrz bazy danych. Każda tabela składa z wierszy (nazywanych fachowo krotkami, ang. tuple) i kolumn (ang. column). W naszym przykładzie wiersz odzwierciedla wszystkie dane opisujące jednego pracownika (imię, nazwisko, płeć i wiek). Kolumna natomiast to np. zbiór nazwisk wszystkich pracowników (nazywane atrybutami wiersza bądź krotki).

Relacyjne bazy danych to obecnie najczęściej wykorzystywany rodzaj baz danych. Dlaczego wyraz relacyjna zawiera się w nazwie? Relacja to zbiór (ang. set) wierszy posiadających te same atrybuty. Dla powyższego przykładu, wszyscy pracownicy (wiersze) z tabeli employees są relacją, ponieważ wszystkie opisane są tymi samymi atrybutami (wszystkie mają ustalone imię, nazwisko, płeć oraz wiek). Uściślając, każda tabela w relacyjnej bazie danych jest relacją.

Moc (prostego) SQL’a

Na potrzeby przykładu załóżmy, że jesteśmy zespołem produktowym odpowiedzialnym za stworzenie wewnętrznego systemu benefitowego dla pracowników firmy, w której pracujemy. Jednym z przyjętych założeń jest oferowanie benefitów dopasowanych do wieku pracowników. W celu podjęcia decyzji opartych na danych możemy wykorzystać tabelę employees, która zawiera podstawowe dane na temat wszystkich zatrudnionych pracowników. W celu lepszego dopasowania oferty benefitów istotnym wydaje się być zdobycie odpowiedzi, między innymi, na pytania:

1. Ile % pracowników stanowią mężczyźni, a ile kobiety?
2. Ile % pracowników przypada na poszczególne przedziały wiekowe:
   1. < 20,
   2. 20 – 30,
   3. 31 – 40,
   4. 41 – 50,
   5. > 50?

Dobra wiadomość jest taka, że już podstawowa znajomość języka SQL pozwoli nam uzyskać klarowne dane. Wykorzystując je, będziemy bliżej podjęcia trafnej decyzji opartej na danych, zamiast, często zgubnej, intuicji.

SELECT COUNT(*) * 100 / (SELECT COUNT(*) FROM employees) FROM employees WHERE gender = 'male';

Hej bazo! Powiedz mi ile wierszy z tabeli employees posiada atrybut gender ustawiony na male. Uzyskaną wartości pomnóż przez sto, a następnie podziel przez łączna liczbę wierszy (pracowników) w tabeli, aby uzyskać wynik procentowy.

Wynik dla okrojonej wersji tabeli employees z artykułu: 50%.

SELECT COUNT(*) * 100 / (SELECT COUNT(*) FROM employees) FROM employees WHERE gender = 'female';

Hej bazo! Powiedz mi ile wierszy z tabeli employees posiada atrybut gender ustawiony na female. Uzyskaną wartości pomnóż przez sto, a następnie podziel przez łączna liczbę wierszy (pracowników) w tabeli, aby uzyskać wynik procentowy.

Wynik dla okrojonej wersji tabeli employees z artykułu: 50%.

SELECT COUNT(*) * 100 / (SELECT COUNT(*) FROM employees) FROM employees WHERE age < 19;

Hej bazo! Powiedz mi ile wierszy z tabeli employees posiada atrybut age ustawiony na wartość mniejszą lub równą 19. Uzyskaną wartości pomnóż przez sto, a następnie podziel przez łączna liczbę wierszy (pracowników) w tabeli, aby uzyskać wynik procentowy.

Wynik dla okrojonej wersji tabeli employees z artykułu: 0%.

SELECT COUNT(*) * 100 / (SELECT COUNT(*) FROM employees) FROM employees WHERE age BETWEEN 20 AND 30;

Wynik dla okrojonej wersji tabeli employees z artykułu: 50%.

Hej bazo! Powiedz mi ile wierszy z tabeli employees posiada atrybut age ustawiony na wartość większą niż 19, ale mniejszą niż 31. Uzyskaną wartości pomnóż przez sto, a następnie podziel przez łączna liczbę wierszy (pracowników) w tabeli, aby uzyskać wynik procentowy.

SELECT COUNT(*) * 100 / (SELECT COUNT(*) FROM employees) FROM employees WHERE age BETWEEN 31 AND 40;

Wynik dla okrojonej wersji tabeli employees z artykułu: 0%.

Hej bazo! Powiedz mi ile wierszy z tabeli employees posiada atrybut age ustawiony na wartość większą niż 30, ale mniejszą niż 41. Uzyskaną wartości pomnóż przez sto, a następnie podziel przez łączna liczbę wierszy (pracowników) w tabeli, aby uzyskać wynik procentowy.

SELECT COUNT(*) * 100 / (SELECT COUNT(*) FROM employees) FROM employees WHERE age BETWEEN 41 AND 50;

Wynik dla okrojonej wersji tabeli employees z artykułu: 25%.

Hej bazo! Powiedz mi ile wierszy z tabeli employees posiada atrybut age ustawiony na wartość większą niż 40, ale mniejszą niż 51. Uzyskaną wartości pomnóż przez sto, a następnie podziel przez łączna liczbę wierszy (pracowników) w tabeli, aby uzyskać wynik procentowy.

SELECT COUNT(*) * 100 / (SELECT COUNT(*) FROM employees) FROM employees WHERE age > 51;

Hej bazo! Powiedz mi ile wierszy z tabeli employees posiada atrybut age ustawiony na wartość większą lub równą 51. Uzyskaną wartości pomnóż przez sto, a następnie podziel przez łączna liczbę wierszy (pracowników) w tabeli, aby uzyskać wynik procentowy.

Wynik dla okrojonej wersji tabeli employees z artykułu: 25%.

Jak widzisz składnia powyższych zapytań SQL nie jest skomplikowana (część z nich nie jest zoptymalizowana, ale nie to jest celem tego artykułu). Podstawowa znajomość języka angielskiego wystarczy, aby w pełni je zrozumieć. Uzyskane dane pozwolą nam na lepsze dostosowanie oferty benefitów pracowniczych uwzględniająch charakterystykę ich potencjalnych adresatów. Na podstawie wykonanych zapytań wiemy, że:

1. Połowa pracowników to kobiety, a druga połowa to mężczyźni.
2. 50% pracowników mają od 20 do 30 lat.
3. 25% pracowników ma od 31 do 40 lat.
4. 25% pracowników ma powyżej 50 lat.

Wnioski te powinny pomóc nam w przygotowaniu oferty, która będzie lepiej dopasowana do grona odbiorców.

Nie taki diabeł straszny…

Popyt na rynku pracy na stanowiska z zakresu analizy danych będzie rósł. Posiadanie wartościowych danych, odpowiednich narzędzi oraz pracowników będących w stanie te dane obrobić to w dzisiejszym świecie istotna przewaga konkurencyjna.

Jednocześnie, już podstawowa znajomość języka SQL może pomóć w podejmowaniu decyzji opartych na danych. Takie podejście powinno być standardem w pracy na stanowisku Product Managera. W końcu nie taki SQL straszny jak go malują 🙂