Tap to unmute

Normalizacja Baz Danych Dla Początkujących + Praktyka

  Рет қаралды 18,350

nieinformatyk

nieinformatyk

Күн бұрын

Пікірлер: 82
@WronaMW
@WronaMW Жыл бұрын
Aż ciężko uwierzyć, że to darmowy kurs na yt. Świetnie wytłumaczone! Na pewno będę oglądał resztę kanału.
@nieinformatyk
@nieinformatyk Жыл бұрын
Dziękuję :)
@lepusepus9310
@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
@nieinformatyk 2 жыл бұрын
No niestety - oglądaj wszystkie jak idzie to nie będziesz musiał skakać :)
@michael_scarn_
@michael_scarn_ Жыл бұрын
Super wytłumaczone, czapki z głów! Dzięki za wszystkie Twoje materiały!😊🙌
@nieinformatyk
@nieinformatyk Жыл бұрын
Dziękuję :)
@robydj5289
@robydj5289 2 жыл бұрын
Kolejna wartościowa porcja wiedzy! Dzięki za świetną robotę! Newsletter już zasubskrybowany, bardzo ciekawy.
@nieinformatyk
@nieinformatyk 2 жыл бұрын
dzięki Roby :)
@marcinzale
@marcinzale 2 жыл бұрын
Jak zwykle, bardzo dobrze przekazana wiedza. Dzięki!
@nieinformatyk
@nieinformatyk 2 жыл бұрын
Dzięki za komentarz Marcin :)
@pawepuszka858
@pawepuszka858 2 жыл бұрын
Omówiłeś świetnie problem który swego czasu poruszyłem. Dzięki za materiał.
@nieinformatyk
@nieinformatyk 2 жыл бұрын
polecam się na przyszłość :)
@Shinigami_2029
@Shinigami_2029 8 ай бұрын
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
@nieinformatyk 8 ай бұрын
Powodzenia jutro :)
@Shinigami_2029
@Shinigami_2029 8 ай бұрын
@@nieinformatyk Dzięki!
@rumunxd5643
@rumunxd5643 29 күн бұрын
@@Shinigami_2029 poprawiles?
@Exathil
@Exathil Жыл бұрын
11:23 Ale kolumna Kierownik Działu ma dwie wartości, a nie jedną. Ok już widzę, w komentarzach, że to faktycznie błąd ;)
@mariaorowska3376
@mariaorowska3376 Жыл бұрын
Świetnie, zrozumiale opisane
@nieinformatyk
@nieinformatyk Жыл бұрын
Cieszę się, że pomogłem :)
@tomekzygon4633
@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
@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
@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
@nieinformatyk 2 жыл бұрын
@@tomekzygon4633 dzięki za odpowiedź :) systemy erp to fajna nisza dla bazodanowca, można się biznesowo wiele nauczyć
@simoniskierka
@simoniskierka 11 ай бұрын
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
@nieinformatyk 11 ай бұрын
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ć.
@gordon1533
@gordon1533 2 жыл бұрын
Dzięki!
@nieinformatyk
@nieinformatyk 2 жыл бұрын
proszę bardzo :)
@adamj1744
@adamj1744 2 жыл бұрын
Dzięki za materiał :)
@nieinformatyk
@nieinformatyk 2 жыл бұрын
Adam - dzięki za komentarz :)
@igorkwiatkowski7322
@igorkwiatkowski7322 2 жыл бұрын
Definicje 2 i 3 postaci normalnej są na odwrót. Oprócz tego świetny filmik.
@nieinformatyk
@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 :)
@JasiekH84
@JasiekH84 2 жыл бұрын
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
@nieinformatyk 2 жыл бұрын
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.
@Elomelo-320
@Elomelo-320 2 жыл бұрын
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
@wiktorgrabowski5237
@wiktorgrabowski5237 2 жыл бұрын
Zajebisty kanał!!!!!
@nieinformatyk
@nieinformatyk 2 жыл бұрын
dzięki :)
@lexxi2237
@lexxi2237 Жыл бұрын
gdyby tacy ludzi uczyli w szkołach życie byłoby lepsze
@joke4ey431
@joke4ey431 Ай бұрын
ziomek dobrze nawijasz
@nieinformatyk
@nieinformatyk Ай бұрын
dzięki :)
@henryknorris7294
@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
@nieinformatyk 2 жыл бұрын
Wiele rzeczy w bazach danych jest intuicyjnych i/lub oczywistych. Człowiek się uczy całe życie :)
@bothard22
@bothard22 11 ай бұрын
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
@nieinformatyk 11 ай бұрын
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
@bothard22 11 ай бұрын
:oo dobra, faktycznie przekonuje mnie to, dziękuję bardzo!
@MsMalymis
@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
@nieinformatyk 2 жыл бұрын
Okej, dodam do listy tematów: nie tyle schematy co kontenery(pluggable database), bo to kontenery wprowadzają zamieszanie :)
@Cartey95
@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
@nieinformatyk 2 жыл бұрын
instaluj najnowszą jaka jest w edycji XE(express edition) :)
@gavlosq846
@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
@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.
@Frish2010
@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
@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
@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 :)
@skam9434
@skam9434 Жыл бұрын
A czym moglibyśmy ustawić klucz główny jako PESEL?
@nieinformatyk
@nieinformatyk Жыл бұрын
czym? nie rozumiem pytania :)
@skam9434
@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
@skam9434 Жыл бұрын
@@nieinformatyk a i oczywiście chodziło mi o "czy" a nie o "czym" :)
@nieinformatyk
@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
@skam9434 Жыл бұрын
@@nieinformatyk ok, dzięki
@shortman769
@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
@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 :)
@jakub8186
@jakub8186 6 ай бұрын
te informacje nie pokrywają się w całości z poprzednim filmikiem o normalizacji
@nieinformatyk
@nieinformatyk 6 ай бұрын
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ł :)
@polishmix5382
@polishmix5382 3 күн бұрын
Czy pomogłbys w zadaniu chodzi o korki
@polishmix5382
@polishmix5382 3 күн бұрын
Chodzi o zrobieniu encji dokumentu faktura 3 postacie program software ideas modeler
@nieinformatyk
@nieinformatyk Күн бұрын
hej, jeśli masz konkretne pytanie to możesz je zadać tutaj. Zleceń jako takich nie przyjmuje, bo nie mam na nie aktualnie czasu :)
@skam9434
@skam9434 Жыл бұрын
I czy w 1NF nie powinniśmy rozdzielić KIEROWNIKA_DZIAŁU na jego imię i nazwisko?
@nieinformatyk
@nieinformatyk Жыл бұрын
tak, masz rację - w aktualnej postaci to jest to pole wielowartościowe :)
@skam9434
@skam9434 Жыл бұрын
@@nieinformatyk wow dzięki, że tak szybko odpowiedziałeś
@TomaszTomzik
@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
@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
@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
@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
@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
@nieinformatyk 2 жыл бұрын
@@TomaszTomzik Wychodzi na to, że zamysł miałem dobry a wyszło jak zwykle :)
@kacper.2574
@kacper.2574 10 ай бұрын
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
@nieinformatyk 10 ай бұрын
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
@kacper.2574 10 ай бұрын
@@nieinformatyk Racja +.
@giermekmezny663
@giermekmezny663 Жыл бұрын
renata kadłubek XD
@nieinformatyk
@nieinformatyk Жыл бұрын
Piękne nazwisko :)
Transakcja sql - to co jest i jak działa w bazie danych?
18:47
nieinformatyk
Рет қаралды 12 М.
Indeks w bazie danych   co to jest i jak działa #62
16:35
nieinformatyk
Рет қаралды 27 М.
99.9% IMPOSSIBLE
00:24
STORROR
Рет қаралды 31 МЛН
Co musi wiedzieć bazodanowiec w 2025 roku(oprócz SQL)?
22:31
nieinformatyk
Рет қаралды 2,3 М.
Na czym polega normalizacja w bazach danych? #65
12:55
nieinformatyk
Рет қаралды 25 М.
Jak bazy danych działają od środka?
12:13
Programowalny
Рет қаралды 6 М.
Learn Database Normalization - 1NF, 2NF, 3NF, 4NF, 5NF
28:34
Decomplexify
Рет қаралды 2,2 МЛН
Podstawy baz danych SQL, które musisz znać
13:44
nieinformatyk
Рет қаралды 13 М.
Do czego potrzebujemy baz danych? Podstawy pracy z bazami relacyjnymi (SQL)
19:56
Jak nauczyć się programowania
Рет қаралды 80 М.
NAJSZYBSZY sposób do zostania DATA ANALYST
8:48
O S J E | Data Science
Рет қаралды 36 М.