Skip to content

Test z Neo4J & InfluxDB

  • a) muszą mieć zdefiniowane jakieś właściwości
  • b) mogą mieć zdefiniowane jakieś właściwości
  • c) nie mogą mieć zdefiniowanych żadnych właściwości
  • d) nie powinny mieć zdefiniowanych żadnych właściwości

Wyjaśnienie: Właściwości są opcjonalne. Węzeł może istnieć bez nich.

2. Które oznaczenie węzła jest poprawne?

Section titled “2. Które oznaczenie węzła jest poprawne?”
  • a) (p:Person (name:‘Smith’))
  • b) (p:Person {name:Smith})
  • c) (p:Person {name Smith})
  • d) (p:Person {name:‘Smith’})

Wyjaśnienie: Właściwości zapisuje się w nawiasach klamrowych, jako pary klucz dwukropek wartość, a wartość tekstową w apostrofach. Opcja b nie ma apostrofów wokół tekstu, c nie ma dwukropka, a w opcji a użyto nawiasów okrągłych zamiast klamrowych.

3. Którym poleceniem usuniemy wszystkie węzły oraz wszystkie relacje?

Section titled “3. Którym poleceniem usuniemy wszystkie węzły oraz wszystkie relacje?”
  • a) MATCH (n) DETACH DELETE n
  • b) MATCH (n) DELETE n
  • c) MATCH (n) DETACH n
  • d) MATCH n DETACH n

Wyjaśnienie: DETACH DELETE usuwa węzeł razem z jego relacjami. Samo DELETE na węźle z relacjami zgłosiłoby błąd, a DETACH n bez DELETE nie jest pełnym poleceniem usuwania.

  • a) MATCH (m:Movie) RETURN m
  • b) MATCH (m:Movie)
  • c) MATCH (m:Movie) RETURN n
  • d) MATCH (m Movie) RETURN m

Wyjaśnienie: Zwracamy zmienną zdefiniowaną w MATCH (m). W b brakuje RETURN, w c zwracane jest niezdefiniowane n, w d brak dwukropka przy etykiecie.

5. Które oznaczenie relacji jest poprawne?

Section titled “5. Które oznaczenie relacji jest poprawne?”
  • a) <-[h:HIRED]->
  • b) -[h:HIRED]-
  • c) -[h:HIRED]=
  • d) <-[h:HIRED]<-

Wyjaśnienie: Poprawne formy to -[r]->, <-[r]- oraz -[r]- (bez kierunku). Opcja b to relacja bez wskazanego kierunku i jest poprawna. Opcja a ma strzałki po obu stronach, c używa =, a d ma obie strzałki w tę samą stronę, co jest błędne.

  • a) MATCH (m:Movie) RETURN m.title
  • b) MATCH (m:Movie) RETURN “*”
  • c) MATCH (m:Movie) RETURN m
  • d) MATCH (m:Movie) RETURN m:Movie

Wyjaśnienie: Zwrócenie całej zmiennej m odpowiada pobraniu wszystkich kolumn (*). Opcja a zwraca tylko jedno pole (title).

  • a) importować tylko dane węzłów
  • b) importować tylko relacje między węzłami
  • c) importować dane węzłów oraz relacji między nimi
  • d) zaimportować tylko etykiety węzłów

Wyjaśnienie: LOAD CSV pozwala tworzyć zarówno węzły, jak i relacje między nimi.

8. Usunięcie daty urodzenia z węzła (p:Person {name:'Piotr', data_ur:'01-09-22'})

Section titled “8. Usunięcie daty urodzenia z węzła (p:Person {name:'Piotr', data_ur:'01-09-22'})”
  • a) MATCH ({name:‘Piotr’}) SET n.data_ur = null
  • b) MATCH (n {name:‘Piotr’}) SET data_ur = null
  • c) MATCH (n {name:‘Piotr’}) DELETE data_ur
  • d) MATCH (n {name:‘Piotr’}) SET n.data_ur = null

Wyjaśnienie: Właściwość usuwa się, przypisując jej null (lub przez REMOVE). Tylko d ma poprawnie powiązaną zmienną n i pełną składnię SET n.data_ur. W a zmienna n nie jest powiązana w MATCH, w b brak prefiksu n., a DELETE (c) usuwa węzły lub relacje, nie właściwości.

  • a) MATCH (n {name:‘B’})-[r:XYZ]- DELETE r
  • b) MATCH (n {name:‘A’})-[r:XYZ]->() DELETE r
  • c) MATCH (n {name:‘B’})-[r:XYZ]->() DELETE r
  • d) MATCH (n {name:‘B’})-[r:XYZ]->() DROP r

Wyjaśnienie: Relacja wychodzi z B w stronę A, więc dopasowujemy ją od B ze strzałką -> i usuwamy przez DELETE. W b kierunek wychodzi z A (źle), w d DROP nie służy do usuwania relacji.

10. Migracja 4 tabel (10, 20, 30, 40 rekordów) do Neo4J

Section titled “10. Migracja 4 tabel (10, 20, 30, 40 rekordów) do Neo4J”
  • a) 4 węzły i 100 etykiet
  • b) 100 węzłów i 100 etykiet
  • c) 100 węzłów i 4 etykiety
  • d) 100 węzłów i 40 etykiet

Wyjaśnienie: Każdy rekord staje się węzłem (10+20+30+40 = 100), a każda tabela odpowiada jednej etykiecie (4 tabele = 4 etykiety).

  • a) grupowania węzłów w logiczne zbiory
  • b) definiowania relacji między węzłami
  • c) grupowania etykiet w logiczne zbiory
  • d) grupowania relacji w logiczne zbiory

Wyjaśnienie: Etykieta klasyfikuje węzły (np. :Person, :Movie), grupując je w logiczne kategorie. Relacje opisuje się typem, a nie etykietą.

  • a) grafu nieskierowanego
  • b) grafu skierowanego
  • c) grafu skierowanego oraz nieskierowanego
  • d) grafu skierowanego z możliwością tworzenia pętli w grafie

Wyjaśnienie: Każda relacja w Neo4j jest tworzona z kierunkiem, więc model to graf skierowany (przy zapytaniach można kierunek pominąć i traktować relację jako nieskierowaną). Uwaga: opcja d też jest prawdziwa, bo Neo4j dopuszcza pętle (relacja węzła do samego siebie); jeśli pytanie oczekuje najbardziej szczegółowej odpowiedzi, wskazaniem byłoby d. Odpowiedzią wzorcową jest jednak b.

  • a) nawiasami klamrowymi
  • b) nawiasami okrągłymi
  • c) nawiasami kwadratowymi
  • d) nawiasami klamrowymi, a czasami kwadratowymi

Wyjaśnienie: Węzły zapisuje się w nawiasach okrągłych, np. (p:Person). Nawiasy kwadratowe oznaczają relacje, a klamrowe właściwości.

14. Po CREATE (a)-[:CONNECTS_TO]->(b) wykonujemy MATCH (n:Person {name:'A'}) DELETE n. Czy wykona się poprawnie?

Section titled “14. Po CREATE (a)-[:CONNECTS_TO]->(b) wykonujemy MATCH (n:Person {name:'A'}) DELETE n. Czy wykona się poprawnie?”
  • a) nie
  • b) tak
  • c) pytanie nie jest jednoznaczne
  • d) tak, ale pod pewnymi warunkami

Wyjaśnienie: Węzeł A ma relację. DELETE na węźle z relacjami zgłasza błąd, bo zostałaby osierocona relacja. Aby usunąć taki węzeł, trzeba użyć DETACH DELETE n.

15. Właściwości (ang. properties) w Neo4J

Section titled “15. Właściwości (ang. properties) w Neo4J”
  • a) mogą być przypisane tylko do węzłów
  • b) mogą być przypisane tylko do relacji
  • c) mogą być przypisane do węzłów i relacji
  • d) są przechowywane w osobnych tabelach

Wyjaśnienie: Właściwości (pary klucz-wartość) można nadawać zarówno węzłom, jak i relacjom.

16. Co zwróci MATCH (a)-[:FRIEND]->(b) RETURN a, count(b)?

Section titled “16. Co zwróci MATCH (a)-[:FRIEND]->(b) RETURN a, count(b)?”
  • a) liczbę relacji FRIEND w całym grafie
  • b) liczbę znajomych (FRIEND) dla każdego węzła a
  • c) wszystkie pary węzłów a i b
  • d) błąd składni

Wyjaśnienie: Gdy w RETURN obok funkcji agregującej count(b) jest niezagregowana zmienna a, Cypher grupuje wynik po a. Dla każdego węzła a otrzymamy liczbę wychodzących relacji FRIEND, czyli liczbę jego znajomych.

17. Które stwierdzenie NIE jest prawdziwe?

Section titled “17. Które stwierdzenie NIE jest prawdziwe?”
  • a) relacje w Neo4J zawsze mają kierunek
  • b) relacje mogą mieć właściwości
  • c) węzeł może mieć wiele etykiet
  • d) relacje mogą istnieć bez węzłów

Wyjaśnienie: Relacja zawsze łączy dwa węzły (lub węzeł z samym sobą), więc nie może istnieć bez węzłów. Pozostałe zdania są prawdziwe.

18. Jakiego typu danych nie można zapisać jako field w InfluxDB?

Section titled “18. Jakiego typu danych nie można zapisać jako field w InfluxDB?”
  • a) integer
  • b) float
  • c) boolean
  • d) array

Wyjaśnienie: Pola w InfluxDB przyjmują wartości typu float, integer, unsigned integer, string oraz boolean. Tablica (array) nie jest dozwolonym typem pola.

19. Czy w tagach InfluxDB można używać białych znaków?

Section titled “19. Czy w tagach InfluxDB można używać białych znaków?”
  • a) tak
  • b) nie
  • c) tak, ale zaleca się wówczas ich escapowanie
  • d) tak, ale nie mogą to być tylko tabulatory, a nie spacje

Wyjaśnienie: W line protocol białe znaki w kluczach i wartościach tagów są dozwolone, ale trzeba je poprzedzić znakiem ucieczki (backslash), inaczej zostaną zinterpretowane jako separatory.

20. Znacznik czasowy ma wartość 1750665600. Z jaką dokładnością jest zapisany?

Section titled “20. Znacznik czasowy ma wartość 1750665600. Z jaką dokładnością jest zapisany?”
  • a) do 1 sekundy
  • b) do 10 sekund
  • c) do 1 milisekundy
  • d) do 1 mikrosekundy

Wyjaśnienie: Liczba ma 10 cyfr, co odpowiada uniksowemu czasowi liczonemu w sekundach. Milisekundy miałyby 13 cyfr, mikrosekundy 16, a nanosekundy 19. Dokładność to więc 1 sekunda.

21. Czy w InfluxDB 3 Core można nadawać użytkownikom hasła?

Section titled “21. Czy w InfluxDB 3 Core można nadawać użytkownikom hasła?”
  • a) tak, ale hasła muszą być zapisane w pliku konfiguracyjnym, co obniża bezpieczeństwo systemu
  • b) tak
  • c) nie
  • d) tak, ale hasło z powodów bezpieczeństwa musi być zapisane w tokenie autoryzacyjnym

Wyjaśnienie: Uwierzytelnianie w InfluxDB 3 Core opiera się na tokenach, a nie na parach użytkownik-hasło. Klasycznych haseł użytkowników się tu nie nadaje.

22. Czy wygenerowany token autoryzacyjny można w dowolnym momencie ponownie wyświetlić w konsoli?

Section titled “22. Czy wygenerowany token autoryzacyjny można w dowolnym momencie ponownie wyświetlić w konsoli?”
  • a) tak
  • b) tak, ale trzeba mieć odpowiednie uprawnienia
  • c) tak, ale nie powinno się tego robić z powodów bezpieczeństwa
  • d) nie

Wyjaśnienie: Token pokazywany jest tylko raz, w chwili utworzenia. System przechowuje go w postaci uniemożliwiającej odczyt, więc później nie da się go ponownie wyświetlić, trzeba wygenerować nowy.

23. Czy wpisując dane do InfluxDB trzeba zawsze podawać znacznik czasowy (timestamp)?

Section titled “23. Czy wpisując dane do InfluxDB trzeba zawsze podawać znacznik czasowy (timestamp)?”
  • a) tak
  • b) nie
  • c) tak, ale tylko gdy domyślny znacznik zostanie zapisany w pliku konfiguracyjnym
  • d) tak, choć nie jest to zwykle zalecane

Wyjaśnienie: Jeśli nie podamy znacznika czasowego, InfluxDB automatycznie przypisze aktualny czas serwera. Podawanie go nie jest więc obowiązkowe.

24. Jak reaguje InfluxDB, gdy próbujemy wpisać dane będące dublami?

Section titled “24. Jak reaguje InfluxDB, gdy próbujemy wpisać dane będące dublami?”
  • a) zduplikowane dane zostaną zapisane poprawnie
  • b) zduplikowane dane zostaną zapisane poprawnie i serwer wyświetli stosowny komunikat ostrzegawczy
  • c) wyświetli stosowny komunikat ostrzegawczy i zduplikowane dane nie zostaną zapisane
  • d) zduplikowane dane nie zostaną zapisane i żaden komunikat ostrzegawczy nie pojawi się

Wyjaśnienie: Punkt jest identyfikowany przez measurement, zestaw tagów i znacznik czasowy. Zapis o tym samym kluczu i czasie nadpisuje istniejący punkt (zasada last write wins) bez błędu i bez ostrzeżenia, więc operacja kończy się powodzeniem. Odpowiedzi b i c są błędne, bo InfluxDB nie wyświetla ostrzeżenia.

25. Jakie typy danych mogą być przechowywane w polach (fields)?

Section titled “25. Jakie typy danych mogą być przechowywane w polach (fields)?”
  • a) liczby, stringi
  • b) tylko teksty
  • c) tylko liczby
  • d) liczby, stringi, boolean

Wyjaśnienie: Pola obsługują wartości liczbowe (float, integer), tekstowe (string) oraz logiczne (boolean), więc najpełniejsza odpowiedź to d.