Normalizacja Baz Danych Dla Początkujących + Praktyka

Рет қаралды 15,900

Күн бұрын

✅Zastanawiasz się jak normalizować bazę danych? Czym są postacie normalne w relacyjnych bazach danych? Normalizacja tabel jest procesem, który ma na celu podzielić większą tabelę na kilka mniejszych. Po co to robić, co zyskasz i w jaki sposób doprowadzić do 3 postaci normalnej dowiesz się oglądając ten materiał. Zapraszam do oglądania.
🎁 ODBIERZ PREZENT - promo.plsql.pl/
== 🔗 Przydatne linki z nagrania:==
🏷️video klucz główny: • Kurs SQL 5: Co to jest...
🏷️video klucz obcy: • Kurs SQL 6: Co to jest...
🏷️video normalizacja: • Na czym polega normali...
🏷️video hurtownia danych: • Hurtownia danych - co ...
🏷️postacie normalne: pl.wikipedia.org/wiki/Posta%C...)
== 👌 Polecam obejrzeć:==
Implementacje baz danych: • Jak wybrać implementac...
Architektura baz danych: • Architektura baz danyc...
== ⏱️ Plan odcinka:==
00:00 start
00:11 wprowadzenie do odcinka
01:16 co to jest normalizacja tabel?
01:57 dlaczego należy normalizować bazę danych?
03:56 jakie problemy powoduje zdenormalizowana tabela(4 anomalie)
07:27 czego potrzeba do normalizacji tabel w bazie danych?
09:26 jak normalizować tabele?
09:50 jakie wymagania mają postacie normalne?
17:28 ile jest postaci normalnych?
18:53 podsumowanie
##bazodanowiec
== 👨‍💻 Poznaj mniej lepiej:==
* Moja strona: www.nieinformatyk.pl/
* Kod z odcinka: www.nieinformatyk.pl/pliki
* Facebook: / nieinformatyk
* Linkedin: / darekbutkiewicz
* Instagram: / nieinformatyk
* Twitter: / nieinformatyk
Zasubskrybuj mój kanał: kzfaq.info...
🏁 Witaj na moim kanale :)
Jestem programistą baz danych Oracle oraz developerem hurtownii danych (ETL). W tym miejscu dzielę się z oglądającymi wiedzą dotyczącą relacyjnych baz danych, praktycznych technik pisania SQL oraz optymalizacji kodu PL/SQL. Jeśli chcesz zdobyć praktyczną i rzetelną więdzę o bazach danych to trafiłeś na właściwe miejsce.
🚨 Więcej informacji o bazach danych znajdziesz zupełnie ZA DARMO na www.nieinformatyk.pl i nieinformatyk.pl/strona/plsql...
📧 Masz pytanie, prośbę, sugestię? Pisz śmiało na kontakt@nieinformatyk.pl

Пікірлер: 76

@marcinzale 2 жыл бұрын

Jak zwykle, bardzo dobrze przekazana wiedza. Dzięki!

@nieinformatyk 2 жыл бұрын

Dzięki za komentarz Marcin :)

@mariaorowska3376 Жыл бұрын

Świetnie, zrozumiale opisane

@nieinformatyk Жыл бұрын

Cieszę się, że pomogłem :)

@pawepuszka858 2 жыл бұрын

Omówiłeś świetnie problem który swego czasu poruszyłem. Dzięki za materiał.

@nieinformatyk 2 жыл бұрын

polecam się na przyszłość :)

@michael_scarn_ 11 ай бұрын

Super wytłumaczone, czapki z głów! Dzięki za wszystkie Twoje materiały!😊🙌

@nieinformatyk 11 ай бұрын

Dziękuję :)

@WronaMW Жыл бұрын

Aż ciężko uwierzyć, że to darmowy kurs na yt. Świetnie wytłumaczone! Na pewno będę oglądał resztę kanału.

@nieinformatyk Жыл бұрын

Dziękuję :)

@robydj5289 Жыл бұрын

Kolejna wartościowa porcja wiedzy! Dzięki za świetną robotę! Newsletter już zasubskrybowany, bardzo ciekawy.

@nieinformatyk Жыл бұрын

dzięki Roby :)

@gordon1533 2 жыл бұрын

Dzięki!

@nieinformatyk 2 жыл бұрын

proszę bardzo :)

@adamj1744 2 жыл бұрын

Dzięki za materiał :)

@nieinformatyk 2 жыл бұрын

Adam - dzięki za komentarz :)

@lepusepus9310 2 жыл бұрын

te filmy to takie drzewko zależności, zawsze wchodzę na jeden i muszę przerwać w połowie, żeby obejrzeć kilka innych xd tak czy inaczej, dobry materiał mordo!

@nieinformatyk 2 жыл бұрын

No niestety - oglądaj wszystkie jak idzie to nie będziesz musiał skakać :)

@wiktorgrabowski5237 2 жыл бұрын

Zajebisty kanał!!!!!

@nieinformatyk 2 жыл бұрын

dzięki :)

@Shinigami_2029 3 ай бұрын

Chodzę do technikum i mam jutro poprawę kartkówki z normalizacji. Kompletnie nie rozumiałem tematu. Dzięki tobie zaczynam to rozumieć. Dzięki!

@nieinformatyk 3 ай бұрын

Powodzenia jutro :)

@Shinigami_2029 3 ай бұрын

@@nieinformatyk Dzięki!

@igorkwiatkowski7322 2 жыл бұрын

Definicje 2 i 3 postaci normalnej są na odwrót. Oprócz tego świetny filmik.

@nieinformatyk 2 жыл бұрын

Igor - dlaczego na odwrót? Druga postać to sprawdzenie czy wszystkie kolumn tabeli zależą od klucza głównego, a trzecia to sprawdzenie czy te kolumny nie zależą jeszcze od czegoś innego niż klucz główny. Można to oczywiście sprawdzić w drugą stronę, ale to moim zdaniem nie po kolei :)

@MsMalymis 2 жыл бұрын

Witam, Darku czy w którymś z twoich filmów poruszałeś tematykę schematów bazy danych??? Przejrzałem stare filmy, ale wprost o tym nie było :( Może coś nagrasz o tym :) Chciałbym to bardziej zrozumieć, bo przeszedłem niedawno z EPRa opartego na MS SQL do systemu na Oracle'u. W MS tez oczywiście były schematy, ale tam wszystko było przypisane do jednego 'dbo' i już :), a tutaj są schematy bardziej rozwinięte. Dzięki.

@nieinformatyk 2 жыл бұрын

Okej, dodam do listy tematów: nie tyle schematy co kontenery(pluggable database), bo to kontenery wprowadzają zamieszanie :)

@Exathil 9 ай бұрын

11:23 Ale kolumna Kierownik Działu ma dwie wartości, a nie jedną. Ok już widzę, w komentarzach, że to faktycznie błąd ;)

@JasiekH84 Жыл бұрын

Sorki za czepialstwo ale moim zdaniem tabela dział powinna być jeszcze dodatkowo rozbita na dział i kierownik. W tabeli kierownik powinniśmy widzieć 3 kolumny: ID, Imie, Nazwisko. Ponieważ w przypadku pojawienia się takiego wpisu w tabeli dział, w kolumnie Kierownik Działu => Jan Filip, nie jesteśmy w stanie określić które to imie a które nazwisko. Dodatkowo w niektórych firmach bywa tak że jeden kierownik może być dla kilku działów (bardzo rzadko ale takie przypadki są). Poza tym to świetna robota, gratki :D

@nieinformatyk Жыл бұрын

Tak, to prawda. Tabela, która zawiera pola wielowartościowe nie spełnia teoretycznie wymagań nawet 1 postaci normalnej, więc imie i nazwisko należało by rozbić na oddzielne kolumny:) Co do oddzielnych tabel - to jak nie zakładałem scenariusza, że ktoś jest kierownikiem >1 działu. Ale jeśli taka sytuacja wystąpi to oczywiście Twoje rozwiązanie jest prawidłowe.

@Cartey95 2 жыл бұрын

Cześć. Zaczynam przygodę z nauką SQL i chciałem się zapytać, którą wersję database oracle zainstalować? Na Twoim kanale znalazłem poradnik do instalacji wersji 18c, ale wiem, że są nowsze.

@nieinformatyk 2 жыл бұрын

instaluj najnowszą jaka jest w edycji XE(express edition) :)

@Elomelo-320 Жыл бұрын

Zastanowiłbym się nad wydzielniem tabeli z osobami, osoba wtedy ma adres, oraz w zależności od użycia jej w tabeli, jest pracownikiem lub kierownikiem działu

@tomekzygon4633 2 жыл бұрын

Sam pracuję w branży mocno opartej na bazach danych (Wdrożenia systemów ERP) i widzę że temat normalizacji baz jest przez wielu osób omijany tudzież pomijany przy projektowaniu baz danych.

@nieinformatyk 2 жыл бұрын

Też kiedyś pracowałem w tej branży. Dobrze wspominam :) Jeśli to baza transakcyjna to prędzej czy później pojawią się problemy. Jak ta branża aktualnie stoi? Sporo ofert pracy? Duże zapotrzebowanie ze strony klientów?

@tomekzygon4633 2 жыл бұрын

@@nieinformatyk Rynek rozwija się prężnie, nie znajdziemy teraz firmy która w mniejszym lub większym stopniu nie wspiera się jakimś oprogramowaniem czy to prostym drobnym dmsem czy też już jakimś systemem ERP. Ofert jest coraz więcej jednakże ciężko się przebić gdyż często wymagania z góry są ukierunkowane na dany system typu Xl od comarchu enova od sonety, co wiążę się z tym że wymagane doświadczenie trzeba skądś pozyskać a materiałów sprecyzowanych na dany system nie ma za dużo w ogólno dostępnych źródłach jedynie znajomość baz danych czy danej dziedziny księgowość, logistyka itp jest dużym plusem na rekrutacji.

@nieinformatyk 2 жыл бұрын

@@tomekzygon4633 dzięki za odpowiedź :) systemy erp to fajna nisza dla bazodanowca, można się biznesowo wiele nauczyć

@lexxi2237 9 ай бұрын

gdyby tacy ludzi uczyli w szkołach życie byłoby lepsze

@gavlosq846 2 жыл бұрын

Pytanie za 100pkt, nie dotyczy do końca tego odcinka ale.. 😄 Co w przypadku gdy w nieunikalnym indeksie posiadamy zduplikowane klucze ? Skoro indeks jest drzewem, czy takie node'y tworzą wewnętrzną listę?

@nieinformatyk 2 жыл бұрын

Jak zjedziesz tutaj kawałek niżej to zobaczysz strukturę indeksu b-tree: docs.oracle.com/cd/E11882_01/server.112/e40540/indexiot.htm#CNCPT1170 Na moje oko to będziesz miał w jednym branch blocku kilka leaf nodów(inaczej index entries), które będą odnosiły się do tej samej wartości klucza indeksu, ale będą wskazywały na inny ROWID.

@simoniskierka 6 ай бұрын

Cześć, mam kilka pytań: - nie powinno się rozdzielić imienia i nazwiska kierownika oddzielnymi kolumnami? - czy pesel może być kluczem głównym? - jeśli zmienimy kierownika, to skąd będziemy później wiedzieć kto z nich miał np. lepsze wyniki sprzedaży?

@nieinformatyk 6 ай бұрын

1. Tak, powinno się. Nie zauważyłem tego. 2. Może, ale lepiej zdecydować się na klucz sztuczny(id). 3. Od tego są DWH(hurtownie danych) i implementowane tam SDC(slowly changing dimension). W OLTP jeśli nadpiszesz starą wartość nową to nie będziesz w stanie tego przeanalizować.

@Frish2010 2 жыл бұрын

Mam pytanie co do baz danych,. Chodzi mi o kwestie czy projektując bazę danych do programu w którym mieliby logować się userzy którzy będą przetwarzać duże ilości informacji i zapisywać save swoich osiągnięć jako tabele to każdy taki użytkownik powinien mieć osobną bazę danych? czy może powinno się zrobić jedną bazę danych dla wszystkich userów? i czy znowu w tym przypadku taka pojedyncza baza danych nie będzie za bardzo obciążona ilością zapytań? Jak to jest robione w praktyce? przykładowo na jakichkolwiek portalach w których jest dodawanych dużo postów i informacji, czy jako urzytkownik mam osobną bazę danych i operuję na danych z tablic znajdujących się w bazie nazwanej np. moim nickiem, czy całość portalu jest oparata na jednej bazie danych i relacjach między tablicami a moj nick to tylko rekord w tabeli?

@nieinformatyk 2 жыл бұрын

Myślę, że ile projektów tyle rozwiązań, ale te drugie rozwiązanie jest najczęściej spotykane(użytkownik to tylko rekord w tabeli). Tworzenie osobnej bazy danych dla pojedynczego użytkownika to mocno nietrafiany pomysł :) Wyboraź sobie, że chciałbyś potem zliczyć liczbę użytkowników lub użytkownik usuwałby konto. Baza danych byłaby mega trudna do utrzymania. Zazwyczaj jedna baza danych wystarcza, a to co można ewentualnie zrobić to stworzyć bazę danych rozproszoną(skalowanie poziome), czyli jedna baza danych fizycznie znajduje się na kilku/kilkunastu, itd. komputerach. Bazy nosql obsługujące często serwisy społecznościowe działają właśnie w ramach wielu, tzn. nodów. W ramach tabel dane można też partycjonować, ale to raczej dotyczy hurtowni danych(table partitioning).

@Frish2010 2 жыл бұрын

@@nieinformatyk Dziękuję za tak szybką odpowiedź. Zastanawiałem się właśnie nad tym ponieważ piszę sobie aplikację z opcja logowania, a nigdy nie wchodziłem w ten temat głębiej i nie zdawałem sobie sprawy z tego jaka opcja byłaby lepsza dla pojedynczego użytkownika. A tak na marginesie fajnie że rozwijasz kanał i wrzucasz filmiki. Wrzucaj jak będziesz miał coś ciekawego bo fajnie się słucha i zdecydowanie sporo przydatnych rzeczy u Ciebie można znaleźć o SQL. :) pozdrawiam i zapewne odezwę się jak będę miał kolejne niejasne sprawy :)

@shortman769 2 жыл бұрын

Czy przerzucenie kierowników działu do tabeli z pracownikami i odwoływanie się do nich po id z poziomu tabeli działów to nie część normalizacji?

@nieinformatyk 2 жыл бұрын

Nie, bo kierownik działu to kolumna tabeli z działami(kierownik jest przypisany do działu, a nie do pracownika). Dlaczego chciałbyś taką informację chciałbyś przechowywać w tabeli z pracownikami? Trudno mówić o normalizacji, gdy tabela nie spełnia wymogów 2 postaci normalnej :)

@henryknorris7294 2 жыл бұрын

Pracując w excelu i mając zerowe pojęcie o bazach danych nie wiedziałem że stosuję zasady normalizacji np. atomowość oraz klucz podstawowy czyli id (przydatne przy wielu rzeczach jak np. wyszukaj.pionowo). Żałuję, że wcześniej nie znalazłem tak przystępnych materiałów odnośnie baz danych. No ale nie jest za późno póki się żyje...

@nieinformatyk 2 жыл бұрын

Wiele rzeczy w bazach danych jest intuicyjnych i/lub oczywistych. Człowiek się uczy całe życie :)

@bothard22 6 ай бұрын

Jeśli mówisz, że przy tworzeniu 2NF mają nam nie dochodzić żadne dane, to dodanie numerycznego klucza głównego przypadkiem nie dodaje nam danych? W sensie, że kluczem głównym mogłaby być przecież nazwa_działu? tak samo jak pesel mógłby być kluczem głównym tabelki pracowników... >_

@nieinformatyk 6 ай бұрын

Z tym tworzeniem danych chodzi o dane biznesowe, tzn. by nie rozdzielić danych na tabelki w taki sposób, że ich późniejsze JOIN-owanie wygeneruje kombinacje rekordów, która nie istniała na początku. Co do drugiego pytania to masz całkowitą rację - poczytaj o kluczu naturalnym(natural key) i kluczu sztucznym(surrogate key). W skrócie chodzi o to, że klucz sztuczny jest wydajniejszym i bezpieczniejszym rozwiązaniem niż klucz naturalny. Dlaczego? - wydajność: pesel to typ VARCHAR(13 bajtów), id to INTEGER(4 bajty). Dla każdego rekordu będziesz przechowywał 9 bajtów mniej. Tabela może mieć miliony rekordów, do tego te wartości mogą być w kilkudziesięciu tabelach połączonych FK(klucz obcy). W ten sposób zajmujemy na dysku znacznie mniej miejsca i wszystkie operacje filtrowania(WHERE) czy łączenia tabel(JOIN) są wydajniejsze, bo baza ma mniej pracy - bezpieczeństwo - istnieje ryzyko, że klucz naturalny się zmieni, np. jeśli id_departamentu to "sprzedaż", a nie liczba całkowita to za jakiś czas możemy chcieć zmienić nazwę na "sprzedaż i marketing". Updatowanie klucza głównego jest problematyczne(dużo zależności jak tabele FK czy indeksy). Klucza sztucznego nie będziesz nigdy potrzebował zmieniać, bo to wartość stricte techniczna.

@bothard22 6 ай бұрын

:oo dobra, faktycznie przekonuje mnie to, dziękuję bardzo!

@jakub8186 Ай бұрын

te informacje nie pokrywają się w całości z poprzednim filmikiem o normalizacji

@nieinformatyk Ай бұрын

Zgadza się, dlatego przesłuchaj uważnie wstęp do tego nagrania i przypięty komentarz oraz opis poprzedniego nagrania. To jest powód, dla którego nagrałem ten materiał :)

@skam9434 Жыл бұрын

A czym moglibyśmy ustawić klucz główny jako PESEL?

@nieinformatyk Жыл бұрын

czym? nie rozumiem pytania :)

@skam9434 Жыл бұрын

@@nieinformatyk Chodzi mi o to, że jeżeli każda osoba ma inny PESEL, to czy nie moglibyśmy zamiast dodawać ID, wszystko uniezależnić od PESELU?

@skam9434 Жыл бұрын

@@nieinformatyk a i oczywiście chodziło mi o "czy" a nie o "czym" :)

@nieinformatyk Жыл бұрын

@@skam9434 tak - teoretycznie jest to możliwe, ale tu zaczyna się dyskusja klucz naturalny vs klucz sztuczny :) Możesz poczytać o tym w internecie.

@skam9434 Жыл бұрын

@@nieinformatyk ok, dzięki

@skam9434 Жыл бұрын

I czy w 1NF nie powinniśmy rozdzielić KIEROWNIKA_DZIAŁU na jego imię i nazwisko?

@nieinformatyk Жыл бұрын

tak, masz rację - w aktualnej postaci to jest to pole wielowartościowe :)

@skam9434 Жыл бұрын

@@nieinformatyk wow dzięki, że tak szybko odpowiedziałeś

@giermekmezny663 10 ай бұрын

renata kadłubek XD

@nieinformatyk 10 ай бұрын

Piękne nazwisko :)

@kacper.2574 4 ай бұрын

Przecież to są całkowicie równoważne stwierdzenia :D 2NF: 1NF + wszystkie kolumny niekluczowe muszą zależeć od klucza głównego 3NF: 2NF + żadna kolumna niekluczowa nie zależy od kolumny innej niż klucz główny

@nieinformatyk 4 ай бұрын

Nie są równoznaczne, ponieważ może istnieć kolumna, która zależy od klucza głównego i jednocześnie innej niekluczowej kolumny. Wtedy spełniasz wymagania 2NF, ale nie 3NF.

@kacper.2574 4 ай бұрын

@@nieinformatyk Racja +.

@TomaszTomzik 2 жыл бұрын

Drastycznie nie zgadzam się z nieatomowym przechowywaniem adresów, później zawsze istnieje potrzeba odwołania się do albo miasta albo adresu, ZAWSZE! ps. podałeś złe definicje 2 i 3 postaci normalnej!

@nieinformatyk 2 жыл бұрын

Co jest nie tak z tymi definicjami 2 i 3 postaci? Adresy oczywiście lepiej przechowywać w oddzielnych polach, co nie znaczy, że wszędzie się tak robi :) Z tym "zawsze" byłbym ostrożny -> jeśli adres jest Ci potrzebny wyłącznie w całości, np. jako adres wysyłki, a nie grupowanie klientów po miastach to taka denormalizacja ma sens.

@TomaszTomzik 2 жыл бұрын

@@nieinformatyk a nie źle popatrzyłem na to co napisałeś, "niekluczowa kolumna nie może zależeć od innej niekluczowej kolumny" - Ty napisałeś w sumie to samo tylko inaczej. Ps. "zawsze" znajdzie się taki co będzie chciał odległości między miastami, etc... zawsze to takie przysłowiowe, które może się przydarzyć i staniemy w sytuacji bardzo trudnej, do której nie powinno się dopuścić. Bo jaki cel miało by przetrzymywanie adresów w sposób nie atomowy? Żeby programista miał łatwiej? Nie o to chodzi w programach aby programista miał łatwiej... bo później będzie miał trudniej, a dwa. liczy się klient a nie programista. Krótko mówiąc nie widzę racjonalnego powodu aby odstępować od normy.

@nieinformatyk 2 жыл бұрын

@@TomaszTomzik Ale ja się zgadzam, co do tego, że lepiej rozdzielać te pola na oddzielne kolumny. Jestem w stanie sobie jednak wyobrazić sytuację, gdzie w jednej tabeli (znormalizowanej) przechowujemy adres zamieszkania, adres zameldowania, adres dostawy, itd. Jeden adres to może być około 10 kolumn(ulica, powiat, gmina, kraj, kod, itd.). Razem mamy 30 kolumn zamiast 3 i konieczność pisania funkcji konkatenującej te kolumny w jeden adres, który chcemy umieścić, np. na etykiecie, paragonie, raporcie. Może niepotrzebnie wspominałem o tym w nagraniu? Główne przesłanie miało być takie: Teoria z praktyką czasami się rozmija i warto być tego świadomym. Tylko tyle i aż tyle. Pozdrawiam.

@TomaszTomzik 2 жыл бұрын

@@nieinformatyk ja bym to nazwał szerzeniem złych praktyk ;) Ja zawsze robię jedną tabele z adresami i podpinam je tam gdzie trzeba, a równocześnie walczę z innymi systemami w których tego nie rozdzielono, a walka przeważnie sprowadza się do dodatkowej pracy klienta lub błędnego działa funkcjonalności której się oczekuje;)

@nieinformatyk 2 жыл бұрын

@@TomaszTomzik Wychodzi na to, że zamysł miałem dobry a wyszło jak zwykle :)