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!
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
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.
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?
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ć.
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.
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?
@@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.
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 :)
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
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... >_
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.
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ę?
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.
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.
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?
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).
@@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 :)
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.
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 :)
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...
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ł :)
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
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.
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!
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.
@@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.
@@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.
@@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;)
![Blox Fruits Dragon Rework Update [Full Stream]](http://i.ytimg.com/vi/EqDAp8udhm0/mqdefault.jpg)
Aż ciężko uwierzyć, że to darmowy kurs na yt. Świetnie wytłumaczone! Na pewno będę oglądał resztę kanału.
Dziękuję :)
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!
No niestety - oglądaj wszystkie jak idzie to nie będziesz musiał skakać :)
Super wytłumaczone, czapki z głów! Dzięki za wszystkie Twoje materiały!😊🙌
Dziękuję :)
Kolejna wartościowa porcja wiedzy! Dzięki za świetną robotę! Newsletter już zasubskrybowany, bardzo ciekawy.
dzięki Roby :)
Jak zwykle, bardzo dobrze przekazana wiedza. Dzięki!
Dzięki za komentarz Marcin :)
Omówiłeś świetnie problem który swego czasu poruszyłem. Dzięki za materiał.
polecam się na przyszłość :)
Chodzę do technikum i mam jutro poprawę kartkówki z normalizacji. Kompletnie nie rozumiałem tematu. Dzięki tobie zaczynam to rozumieć. Dzięki!
Powodzenia jutro :)
@@nieinformatyk Dzięki!
@@Shinigami_2029 poprawiles?
Świetnie, zrozumiale opisane
Cieszę się, że pomogłem :)
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
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.
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?
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ć.
11:23 Ale kolumna Kierownik Działu ma dwie wartości, a nie jedną. Ok już widzę, w komentarzach, że to faktycznie błąd ;)
Dzięki!
proszę bardzo :)
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.
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?
@@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.
@@tomekzygon4633 dzięki za odpowiedź :) systemy erp to fajna nisza dla bazodanowca, można się biznesowo wiele nauczyć
Dzięki za materiał :)
Adam - dzięki za komentarz :)
Definicje 2 i 3 postaci normalnej są na odwrót. Oprócz tego świetny filmik.
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 :)
gdyby tacy ludzi uczyli w szkołach życie byłoby lepsze
Zajebisty kanał!!!!!
dzięki :)
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
ziomek dobrze nawijasz
dzięki :)
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... >_
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.
:oo dobra, faktycznie przekonuje mnie to, dziękuję bardzo!
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ę?
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.
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.
instaluj najnowszą jaka jest w edycji XE(express edition) :)
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?
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).
@@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 :)
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.
Okej, dodam do listy tematów: nie tyle schematy co kontenery(pluggable database), bo to kontenery wprowadzają zamieszanie :)
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?
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 :)
Czy pomogłbys w zadaniu chodzi o korki
Chodzi o zrobieniu encji dokumentu faktura 3 postacie program software ideas modeler
hej, jeśli masz konkretne pytanie to możesz je zadać tutaj. Zleceń jako takich nie przyjmuje, bo nie mam na nie aktualnie czasu :)
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...
Wiele rzeczy w bazach danych jest intuicyjnych i/lub oczywistych. Człowiek się uczy całe życie :)
te informacje nie pokrywają się w całości z poprzednim filmikiem o normalizacji
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ł :)
A czym moglibyśmy ustawić klucz główny jako PESEL?
czym? nie rozumiem pytania :)
@@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?
@@nieinformatyk a i oczywiście chodziło mi o "czy" a nie o "czym" :)
@@skam9434 tak - teoretycznie jest to możliwe, ale tu zaczyna się dyskusja klucz naturalny vs klucz sztuczny :) Możesz poczytać o tym w internecie.
@@nieinformatyk ok, dzięki
I czy w 1NF nie powinniśmy rozdzielić KIEROWNIKA_DZIAŁU na jego imię i nazwisko?
tak, masz rację - w aktualnej postaci to jest to pole wielowartościowe :)
@@nieinformatyk wow dzięki, że tak szybko odpowiedziałeś
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
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.
@@nieinformatyk Racja +.
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!
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.
@@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.
@@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.
@@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;)
@@TomaszTomzik Wychodzi na to, że zamysł miałem dobry a wyszło jak zwykle :)
renata kadłubek XD
Piękne nazwisko :)