Quest: Zasady projektowania baz danych

1. Zasada pojedynczej odpowiedzialności encji

Każda tabela powinna reprezentować jeden, jasno zdefiniowany byt (encję) w modelu danych.
(Jedna tabela = jeden typ rzeczy, np. klienci osobno, produkty osobno)

2. Zasada eliminacji redundancji danych

Dane nie powinny być przechowywane wielokrotnie w różnych miejscach, o ile nie jest to uzasadnione wydajnością.
(Nie kopiuj tych samych danych w wielu miejscach – to się później rozjeżdża)

3. Zasada normalizacji (co najmniej do 3NF)

Struktura bazy powinna spełniać wymagania trzeciej postaci normalnej, eliminując zależności przechodnie i częściowe.
(Podziel dane tak, żeby nie było bałaganu i ukrytych powiązań)

  • 1NF – Pierwsza postać normalna
    Każde pole = jedna konkretna wartość, żadnych list w komórkach
  • 2NF – Druga postać normalna
    Jeśli klucz jest złożony, to wszystkie dane muszą zależeć od CAŁEGO klucza, a nie tylko jego części
  • 3NF – Trzecia postać normalna (najważniejsza)
    Kolumny nie mogą zależeć od innych kolumn – tylko od klucza głównego

4. Zasada atomowości atrybutów

Każda kolumna powinna przechowywać wartości niepodzielne (atomowe), a nie złożone struktury.
(Nie wrzucaj list typu „a,b,c” do jednej kolumny)

5. Zasada jednoznacznej identyfikacji

Każda tabela powinna posiadać klucz główny jednoznacznie identyfikujący każdy rekord.
(Każdy wiersz musi mieć swoje unikalne ID)

6. Zasada integralności referencyjnej

Relacje między tabelami powinny być wymuszane poprzez klucze obce.
(Powiązania między tabelami mają być pilnowane przez bazę, nie „na słowo”)

7. Zasada jawnego modelowania relacji

Relacje typu wiele-do-wielu powinny być realizowane poprzez tabelę pośrednią.
(Jeśli coś łączy się z wieloma rzeczami – robisz dodatkową tabelę)

8. Zasada minimalizacji NULL

Kolumny powinny dopuszczać wartości NULL tylko wtedy, gdy jest to semantycznie uzasadnione.
(Nie zostawiaj pustych pól bez powodu)

9. Zasada spójności typów danych

Typy danych powinny być dobrane adekwatnie do przechowywanej informacji.
(Nie zapisuj liczb jako tekst – to proszenie się o problemy)

10. Zasada niezależności danych od logiki aplikacji

Struktura bazy danych powinna być projektowana niezależnie od konkretnej implementacji aplikacyjnej.
(Baza ma mieć sens sama w sobie, nie tylko „bo tak działa kod”)

11. Zasada przewidywania rozszerzalności

Projekt powinien umożliwiać przyszłą rozbudowę bez konieczności gruntownych zmian struktury.
(Myśl do przodu – system prawie na pewno się rozrośnie)

12. Zasada separacji danych operacyjnych i wyliczanych

Dane wyliczalne nie powinny być przechowywane, jeśli mogą być obliczone na podstawie innych danych.
(Nie zapisuj czegoś, co możesz policzyć)

13. Zasada spójności nazewnictwa

Nazwy tabel i kolumn powinny być jednoznaczne, konsekwentne i zgodne z przyjętą konwencją.
(Nazwy mają być czytelne i spójne – nie „x1”, „dane2”)

Najważniejsza meta-zasada

Model danych powinien odzwierciedlać rzeczywistość biznesową, a nie przypadkową strukturę techniczną.
(Baza ma odzwierciedlać prawdziwy świat, nie być „jakimś zbiorem tabel”)

Zadanie

Na kolejnych stronach są błędne struktury. Popraw je.

Strony: 1 2 3

Quest: WordPress + Elementor

Utwórz stronę startową dla fikcyjnej szkoły akrobatyki „YOU CAN”:

  • wykorzystanie gotowego szablonu w Elementorze
  • dopuszczalne odwzorowanie istniejącej strony (układ 1:1)
  • zmiana treści i grafik na własne
  • strona musi być:
    • w pełni klikalna
    • interaktywna (np. przyciski, linki, sekcje)
    • responsywna (desktop + mobile)
  • podstrony nie będą oceniane, ale muszą być

Szablon

W wyborze szablonu może pomóc jedna ze stron jak ta: elements.envato.com lub inna wyszukiwarka

Dokumentacja

  • Minimum 5 zrzutów ekranu (po jednym z każdego etapu modyfikacji strony startowej)
  • Na pierwszym ma być widoczny wygląd strony startowej po instalacji wybranego szblonu
  • Na ostatnim widać docelowy wygląd startówki
  • Zrzuty umieszczone w galerii
  • Wszystkie zrzuty mają być w tej samej skali

Quest: Logika a CSS

Jak zasady logiki formalnej pojawiają się w CSS – każdy selektor to tak naprawdę mała „formuła logiczna”, określająca, które elementy spełniają dane warunki. Przeanalizuj poniższy kod, a następnie sprawdź czy rozumiesz, wykonując polecenie podane na końcu questa.

<!DOCTYPE html>
<html lang="pl">
<head>
<meta charset="UTF-8">
<title>Logika → selektory CSS</title>
<style>
body {
    font-family: Arial, sans-serif;
}
div {
    border: 1px solid #ccc;
    margin: 10px;
    padding: 10px;
}

/* 1. A: wszystkie p */
#d1 p {
    background: lightblue; /* Logika: A */
}

/* 2. A ∧ B: p w div.inner */
#d2 .inner p {
    background: lightgreen; /* Logika: A ∧ B */
}

/* 3. A ∨ B: p lub a */
#d3 p,
#d3 a {
    background: lightyellow; /* Logika: A ∨ B */
}

/* 4. A ∧ ¬B: p, ale NIE z klasą alert */
#d4 p:not(.alert) {
    background: lightpink; /* Logika: A ∧ ¬B */
}

/* 5. A ∧ ¬B ∧ ¬C: a w menu, nie active i nie disabled */
#d5 .menu a:not(.active):not(.disabled) {
    background: lightcoral; /* Logika: A ∧ ¬B ∧ ¬C */
}

/* 6. ¬A: wszystko co NIE jest h3 */
#d6 :not(h3) {
    background: lightseagreen; /* Logika: ¬A */
}

/* 7. ¬A ∧ B: button.special, który NIE jest w form */
#d7 button.special:not(form button) {
    background: lightgoldenrodyellow; /* Logika: ¬A ∧ B */
}

/* 8. (A ∧ B) ∧ ¬C: p w article, NIE footnote */
#d8 article p:not(.footnote) {
    background: lightcyan; /* Logika: (A ∧ B) ∧ ¬C */
}

/* 9. ¬(A ∨ B): wszystko co nie jest p ani a */
#d9 :not(p):not(a) {
    background: lightsteelblue; /* Logika: ¬(A ∨ B) = ¬A ∧ ¬B */
}

/* 10. A ∧ ¬(B ∧ C): a w menu, nie jednocześnie active i disabled */
#d10 .menu a:not(.active.disabled) {
    background: lightgray; /* Logika: A ∧ ¬(B ∧ C) */
}
</style>
</head>
<body>

<h1>Przykład selektorów CSS i logiki</h1>

<!-- 10 divów, każdy z prostymi elementami -->
<div id="d1">
<h2>D1</h2>
<p>Paragraf 1</p>
<p class="alert">Paragraf alert</p>
<a href="#">Link 1</a>
<div class="inner"><p>Paragraf w inner</p></div>
</div>

<div id="d2">
<h2>D2</h2>
<p>Paragraf 2</p>
<a href="#">Link 2</a>
<div class="inner"><p>Paragraf w inner</p></div>
</div>

<div id="d3">
<h2>D3</h2>
<p>Paragraf 3</p>
<a href="#">Link 3</a>
</div>

<div id="d4">
<h2>D4</h2>
<p>Paragraf 4</p>
<p class="alert">Paragraf alert</p>
<a href="#">Link 4</a>
</div>

<div id="d5">
<h2>D5</h2>
<div class="menu">
<a href="#">Link normalny</a>
<a class="active" href="#">Link active</a>
<a class="disabled" href="#">Link disabled</a>
</div>
</div>

<div id="d6">
<h2>D6</h2>
<h3>Nagłówek</h3>
<p>Paragraf 6</p>
<a href="#">Link 6</a>
</div>

<div id="d7">
<h2>D7</h2>
<form>
<button class="special">Special w form</button>
</form>
<button class="special">Special poza form</button>
</div>

<div id="d8">
<h2>D8</h2>
<article>
<p>Paragraf w artykule</p>
<p class="footnote">Przypis</p>
</article>
</div>

<div id="d9">
<h2>D9</h2>
<p>Paragraf 9</p>
<a href="#">Link 9</a>
<div>Div 9</div>
</div>

<div id="d10">
<h2>D10</h2>
<div class="menu">
<a href="#">Link 10 normalny</a>
<a class="active disabled" href="#">Link active+disabled</a>
<a class="active" href="#">Link active</a>
<a class="disabled" href="#">Link disabled</a>
</div>
</div>

</body>
</html>

Używając narzędzi developerskich w przeglądarce (DevTools – F12 lub RMB > „Zbadaj”) zmodyfikuj lokalnie wygląd skomplikowanej strony (np. opartej na WordPressie). Szczególnie ciekawe będą te elementy strony, które nie mają swojego id, a przypisana klasa jest używana też dla innych elementów, których nie chcesz formatować.