--
Informatyka jest nauką doświadczalną...

"To Alcohol! The cause of, and solution to, all of
life's problems."

1. mialo byc pod: "Tak na szybko... , Star-Ga-Te 19/01/09 22:43" , laciak88 19/01/09 22:53
   sorry :/

   "To Alcohol! The cause of, and solution to, all of
   life's problems."

"you don't need your smile when I cut
your throat"

1. haha, no to grubo :) , laciak88 20/01/09 10:46
   dzieki wielkie - zalozenia sa takie, ze mam zdac i ma byc to model dosc uproszczony, ktory my sobie wymyslimy, a robimy go w celu sprawdzenia sie.
   
   1. Moje intencje sa takie, ze wiele osob moze mieszkac pod jednym adresem, ale tylko jeden adres moze byc przypisany do danej osoby (przeciez nie zamelduje sie w kilku miejscach)
   
   2. Zwykle tak, ale ja chcialem uwzglednic niezwykle przypadki. Czyli jednak zmienic?
   
   3. Tak tez zrobie :)
   
   4. Myslalem raczej o czyms w stylu wersji wyposazeniowej - kilka wersji (komfort, city, avangarde itd.) z posrod ktorych klient moze wybierac kupujac samochod. Piszesz, ze stworzylbys slownik elementow wyposazenia, czyli co?
   
   5. Tak, tu jest blad - powinno byc analogicznie jak z wyposazeniem.
   
   6. Tak bylo na poczatku, ale przy normalizacji jakos sie rozjechalo. Chcialbym zachowac rozroznienie tych osob, bo nie potrzebuje w kliencie daty zatrudnienia i numeru jego konta
   
   7. Nie rozumiem. Przeciez sa klucze. To jest chyba najwazniejszy punkt, bo miedzy innymi o sprawdzenie normalizacji chodzi. A, ze ja to robie pierwszy raz w zyciu, to wytlumacz mi prosze :)
   
   8. Nie do konca wiem o co ci chodzi, jednak teraz dziek tobie zauwazylem, ze miejscowosc kluczem byc nie moze, ale kod moze. Dlaczego cos jeszcze tu mam zmieniac i jak to zrobic?
   
   9. Nie ma byc idealny, ale powinien byc mozliwie wierny. Poprawcuje nad nim.
   
   
   Dzieki za odpowiedz, troche mi rozjasnilo, ale jak mozesz, to rozjasnij wiecej. Pozdrawiam!

   "To Alcohol! The cause of, and solution to, all of
   life's problems."

   1. no to w takim razie... , bwana 20/01/09 12:00
      wymyśl sobie założenia, przemyśl je i przygotuj się na to, że ktoś Cię z nich odpyta przy pokazywaniu diagramu.
      
      1. Osoba może mieć wiele adresów: korespondencyjny, zamieszkania, zameldowania i inne. W przypadku ogólnym mogą to być: adres do PIT, adres dostawy, adres do konkretnego procesu biznesowego. W Twoim przypadku wystarczy chyba faktycznie jeden adres dla danej osoby, choć ja dałbym dwa. Korespondencyjny do wysyłania faktur i zameldowania do np. wysłania pozwu sądowego w przypadku niewywiązywania się ze zobowiązań (płatności).
      
      2. Nie znam takich niezwykłych przypadków. Stokłosy 52/8 w Warszawie to inny adres niż Stokłosy 52/8 w Zapiedkowie Dolnym - zakładam, że o taką sytuację Ci chodziło. Zmień.
      
      4. W takim razie w porządku. Choć, jak mówię, jeśli liczysz się z tym, że lista cech wyposażenia jest zmienna, to rozważ stworzenie układu takiego:
      
      element wyposażenia (1) - (n) element wyposażenia w wersji (n) - (1) wersja wyposażenia (n) - (1) dany samochód
      
      Wtedy w sytuacji, gdy dojdzie do modelu nowa cecha (lakier metalizowany na przykład), wystarczy dodać do tabeli cech (element wyposażenia) nową cechę, a nie kolejną kolumnę do tabeli wyposażenie. Niemniej, z teoretycznego punktu widzenia, model w tym miejscu jest poprawny. To co napisałem jest raczej uwagą praktyka.
      
      6. Atrybuty mogą być opcjonalne. Osoba, która nie jest pracownikiem, może mieć null w atrybucie nr_pracownika.
      
      8. Adres nie ma klucza. O ile VIN dla samochodu jest właściwym kluczem, to nr silnika (choć formalnie poprawny) nie jest właściwym kluczem dla "rodzaju silnika". Dlaczego? Bo istnieje wiele silników o tej samej pojemności, momencie obrotowym (itd), różniących się tylko numerami silnika. Typ silnika powinien być słownikiem.
      
      Grrr, muszę lecieć. Postaram się dokończyć później.

      "you don't need your smile when I cut
      your throat"

      1. no to lecim: , laciak88 20/01/09 12:41
         1,2. Ja mam jednak troche inna logike. Faktycznie masz racje - poprawie.
         
         4,6. Tu jestzcze sie zastanowie jak mi wygodniej bedzie, ale faktycznie, chyba sciagne pracownika i klienta w jedno.
         
         8. Czemu adres nie ma klucza? Silnik poleci do przebudowy tez.
         
         
         Jak znajdziesz chwilke, odpisz mi jeszcze na 7, bo normalizacja dla mnie wazna jest.

         "To Alcohol! The cause of, and solution to, all of
         life's problems."

         1. Ja ci jeszcze pofilozofuje: , ptoki 20/01/09 18:30
            Tak na przyszlosc:
            Przygotuj sie ze jesli ta twoja baza to produkt to na pewno bedziesz ja przerabiac.
            Nie zaluj kolumn znacznikowych w rodzaju - jest_pracownikiem, Aktywny, usuniety, zmieniony, ilosc_zmian.
            
            Takie dane nie zajmuja duzo miejsca ale w przyszlosci pozwola lepiej podzielic dane ze wzgledu na ich uzytecznosc, archiwalnosc, zastosowanie.
            Dajmy na to dzis masz tabelke osoba i w niej kilka ról zaznaczanych znacznikami (dostawca, odbiorca, pracownik, dyspozytor, doreczyciel itp) ale za jakis czas moze dojsc do sytuacji ze bedziesz chcial te role podzielic na osobne tabelki. Wtedy takie znaczniki ci sie przydadza.
            
            Przyklad z osobami jest kijowy bo osob malo wiec potrzeba rzadka ale jak bedziesz mial tabelke zamowienia czy produkt to taka potrzeba moze pojawic sie dosyc szybko.
            
            Generalnie znacznikow, dat, wlasciwosci nie zaluj, miejsca nie zajmuja duzo a moga bardzo pomoc (ale nie musza :( )w przyszlosci
            
            Ten projekt jest pewnie maly i takich problemow jak limit wielkosci bazy nie bedziesz mial ale w przyszlosci taki nawyk sie moze przydac :)

         2. no to dalej z tym koksem , bwana 20/01/09 19:56
            8. Adres faktycznie ma klucz, kluczem są wszystkie jego atrybuty, racja, ale...
            
            Wyobraź sobie, że zmianie (administracyjnej) ulega nazwa ulicy. Jeżeli wystąpi sytuacja (której teraz na diagramie nie ma, ale jest możliwa) że klucz adresu będzie musiał być kluczem obcym, to nastąpi anomalia aktualizacji (klucza). Tutaj, nawet budując model teoretyczny, zastrzegłbym, że musi istnieć sztuczny identyfikator adresu. Dlaczego? Bo identyfikator naturalny, z przyczyn leżących poza modelowaną bazą (modelowanym systemem) może ulegać zmianie.
            
            7. Oczywiście, klucze są, a ja niepotrzebnie zrobiłem tu zamieszanie. Dopuszczalne jest, że na diagramie nie umieszcza się kluczy obcych a ja właśnie o klucze obce się upominałem.
            
            O postaciach normalnych czytaj z wykładu. Nie pamiętam dokładnie definicji kolejnych postaci normalnych, bo, jak wspominałem, jestem praktykiem (od ostatnich wykładów na ten temat dzieli mnie z 10 lat).
            
            Tak naprawdę, powinienem był na samym wstępie zapytać, czy modelujesz system (bazę) na zajęcia z teorii baz danych czy też na zajęcia praktyczne podczas których masz zaprojektować i zaimplementować taką bazę. To pewnie pozwoliłoby mi zachować właściwy dla Twoich potrzeb aparat pojęciowy. W teorii baza składa się z relacji, relacja zawiera krotki a te składają się z atrybutów w domenach, a w praktyce baza składa się z tabel, tabele z wierszy, a te z kolumn o danym typie. Relacja w teorii to mniej więcej tabela w praktyce, relacja w praktyce to zależność atrybutów w teorii - ot, posrane nazewnictwo bo część się pokrywa a część kompletnie rozjeżdża.
            
            Pozdrawiam i powodzenia. Jakby co - pytaj.

            "you don't need your smile when I cut
            your throat"

            1. aha, ok , laciak88 20/01/09 20:40
               8. mialem sztuczny identyfikator, ale go wywalilem, bo pomyslalem sobie, ze moga byc 3 klucze. Ale tu tez masz racje i zastosuje sie do twojej rady
               
               7. wiem co to klucz, ale nie do konca rozumiem pojecie klucz obcy - jesli bys mogl krociotko wytlumaczyc, to bylbym wdzieczny.
               
               Zajecia w sumie z teorii (wyklad) i tylko schemat bedzie drukowany (zadnej implementacji), a co do nazewnictwa, to bardziej do mnie praktyczne trafia, chociaz wiem co to krotka :]. O postaciach czytalem w internecie, bo z wykladu nie wszystko rozumialem (zapisalem tylko ogoly i wzorki, a latwiej mi skomac z przykladow).

               "To Alcohol! The cause of, and solution to, all of
               life's problems."

               1. no dobra, o kluczu obcym , bwana 20/01/09 23:54
                  najlepiej na praktycznym przykładzie. Najlepiej z Twojego diagramu. Adres i miasto:
                  
                  adresy (adres_id, ulica, nr_domu, nr_lokalu, miasto_id)
                  miasta (miasto_id, nazwa_miasta)
                  
                  adres_id to klucz lokalny (klucz główny, jednoznaczny identyfikator rekordu w tabeli / krotki w relacji) adresy
                  
                  miasto_id w tabeli miasto to klucz lokalny (klucz główny) w tabeli miasta.
                  
                  miasto_id w tabeli adresy to klucz obcy, czyli "wskaźnik" na miasto przypisane do danego adresu. Jak tego się używa? Jeśli masz jakiś adres, to sprawdzasz jakie miasto_id jest w tym adresie. Jest to np 34517. Teraz w tabeli miasta szukasz takiego wiersza (miasta) gdzie miasto_id jest równe właśnie 34517. Już wiesz, jak się nazywa to miasto. Właśnie wykonałeś złączenie tabel po kluczu:-) Jasne?
                  
                  PS. Do Twojej ostatniej wypowiedzi - wybrałem Sieciowe Systemy Informacyjne, broniłem się z wyszukiwania w bazach dźwiękowych a zajmuję się systemami ERP (Oracle) i narzędziami Business Intelligence (też Oracle). Planowałem... hmmm, chyba właśnie to:-D

                  "you don't need your smile when I cut
                  your throat"

                  1. a ja nie powinienem miec takich , laciak88 21/01/09 07:07
                     kluczy obcych wszedzie? Czy wystarcza relacje do poprawnego dzialania?

                     "To Alcohol! The cause of, and solution to, all of
                     life's problems."

                     1. poprawny model bazy (teoretyczny) nie wymaga umieszczania kluczy obcych w tabelach , bwana 21/01/09 14:30
                        powiązanych. Przyjmuje się, że jeśli jest w danej tabeli klucz główny i zaznaczone jest, że po tym kluczu jest związek z inną tabelą, to w tej innej tabeli klucze obce są (implicite). Jeśli jednak mówisz o "działaniu", to chyba masz na myśli implementację relacyjnej bazy danych w SQL Serverze, MySQLu, Oraklu czy innym Accessie - tu oczywiście te klucze obce muszą istnieć, żeby mogły istnieć powiązania między rekordami w tabelach. Słowem - na diagramie nie trzeba, ale w definicji tabel w realnej bazie - trzeba.

                        "you don't need your smile when I cut
                        your throat"

                        1. aha, dzieki , laciak88 21/01/09 14:45
                           i teraz zrozum wykladowce i odczytaj z jego mysli czy powinienem dac klucze obce czy nie :/. Nie dam, ale zaznacze, ze wiem o co chodzi

                           "To Alcohol! The cause of, and solution to, all of
                           life's problems."

                           1. hehe, klucze obce niet w powerdesigner 15 , laciak88 21/01/09 16:54
                              nie chce dopuscic nawet i wywala komunikat, ze normalizacja nie pozwala :]

                              "To Alcohol! The cause of, and solution to, all of
                              life's problems."

2. @8 moze byc jeszcze jeden przypadek: , ptoki 20/01/09 11:52
   Bardzo mnie wkurza ze tworzacy systemy nie przewiduja opcji ze poczta jest w innej miejscowosci niz miejscowosc zamieszkania.
   
   Taki mieszkaniec koziej wólki (jego bardzo mala miejscowosc) ma poczte w kielcach (taki sobie przyklad z sufitu).
   
   Na wielu drukach nie ma mozliwosci aby takie cos zapisac. Nawet urzędowe (państwowe!!!) druki tak maja.
   
   Jak ma byc dobrze to slowniki kodow i pole w miejscowosci na kod i sama miejscowosc zamieszkania. Zeby nie przesadzac to ze slownika mozna zrezygnowac. I doswiadczenie z zycia: zeby przesylki dobrze dochodzily trzeba pisac adres w postaci:
   
   imie nazwisko
   ulica
   miejscowosc zamieszkania
   kod pocztowy miejscowosc poczty
   
   Mimo ze kod i miejscowosc poczty sa tozsame to zdaza sie ze listy kraza po polsce bo sortownik (ludzki) nie czytal kodu tylko polecial po miejscowosci zza kodu...
   1. fakt, nie pomyslalem , laciak88 20/01/09 12:41
      zmienie na pewno :)

      "To Alcohol! The cause of, and solution to, all of
      life's problems."

   2. bo tak naprawdę Poczta powinna wiedzieć , bwana 20/01/09 19:59
      że jak jest kod pocztowy AB-CDE to kod ten podlega urzędowi pocztowemu w Zapiedkowie Górnym, mimo, że adresat mieszka w Zapierdkowie Dolnym. Tak samo jest z wieloma instytucjami, np Urzędem Skarbowym, który wymaga nazwiska, adresu, NIP-u, grupy krwi i próbki kału, chociaż sam NIP powinien wystarczyć do identyfikacji.

      "you don't need your smile when I cut
      your throat"

      1. oczywiscie masz racje. , ptoki 21/01/09 10:24
         Tyle ze rzeczywistosc jest taka:
         Poczta oraz prywatni kurierzy niejednokrotnie wozili przesylki do mnie po kraju bo nie uzyli kodu.
         Ani jedna przesylka ktora jezdzila po kraju nie miala zapisanego formatu z miejscowoscia, kodem, i miejscowoscia poczty. Wszystkie mialy tylko zapisana moja miejscowosc i kod.
         
         Jesli da sie inaczej niz zapisaniem obu miescowosci tem problem obejsc to bardzo chetnie skorzystam :) A narazie wszedzie gdzie mi zalezy wymuszam wpisywanie adresu w rozszerzonej formie.

"To Alcohol! The cause of, and solution to, all of
life's problems."