Bazy danych

1. Bazy danych dr Ewa Krok ewakrok@wp.pl konsultacje: poniedziałki: godz.10-12, pok. 240

2. Literatura: • Beynon-Davies P., Systemy baz danych, WNT, 2003 • Whitehorn M., Marklyn B., Relacyjne bazy danych, Helion, 2003 • Date C.J., Relacyjne bazy danych dla praktyków, Helion, 2005 • Dudek W., Bazy danych SQL. Teoria i praktyka, Helion, 2006

3. Baza danych Zbiór powiązanych danych opisujących pewną rzeczywistość, zorganizowanych tak, aby łatwo było je przeszukiwać, wyciągać z nich wnioski czy na ich podstawie podejmować decyzje. Każdy zbiór danych spełniający te funkcje nazywamy bazą danych, nawet jeżeli dane te nie są zapisane na komputerze.

4. Architektura bazy danych – model trzech płaszczyzn • logiczna (koncepcyjna) • wewnętrzna (fizyczna) • zewnętrzna

5. Płaszczyzna logiczna opisuje, jaka część rzeczywistości, w jakiej formie i z jakimi zależnościami odzwierciedlona jest w bazie danych.

6. Płaszczyzna wewnętrzna opisuje sposób w jaki dane faktycznie zapamiętywane są na nośniku danych. Jest to etap tworzenia pól, rekordów i wyboru najbardziej odpowiedniej formy przechowywania danych. Chodzi o fizyczną organizację danych i ustalenie ścieżek dostępu. Celem jest minimalny czas dostępu przy jednoczesnym optymalnym wykorzystaniu miejsca na dysku.

7. Płaszczyzna zewnętrzna jest to sposób widzenia danych przez poszczególnych użytkowników bazy. Inaczej mówiąc płaszczyzna ta opisuje zakresy danych dostępne dla różnych grup użytkowników.

8. Architektura bazy danych

9. Część koncepcyjna powinna być niezależna od specyfiki modelu danych i wykorzystanego systemu bazy danych. Zapewni to pożądaną uniwersalność i elastyczność bazy.

10. Przed zaprojektowaniem bazy danych należy ustalić: • zakres danych przechowywanych w bazie • strukturę danych i relację między danymi

11. ENTITY-RELATIONSHIP-DIAGRAMM Jest najczęściej wykorzystywanym sposobem prezentacji struktury danych i związków między danymi. Zaproponowany został w 1976 roku przez Petera Chena. Diagramy E-R charakteryzują się dużą przejrzystością w odzwierciedlaniu wycinka rzeczywistości, który znajdzie swoje odbicie w bazie danych.

12. Elementydiagramu E-R: • obiekt (Entity, encja) - obiekt ze świata rzeczywistego (np. student, samochód, abonent telefoniczny) opisywany w bazie danych za pomocą pewnych, wybranych atrybutów. W diagramach E‑R obiekty przedstawiane są w formie prostokątów. • typ obiektów (Entitytyp) - grupa obiektów charakteryzująca się tymi samymi cechami. • atrybut - cecha charakteryzująca obiekt np. nazwisko, wzrost lub kolor oczu. Typowi obiektów przypisany jest zawsze określony zbiór atrybutów, które mogą przyjmować różne wartości. Dzięki temu można rozróżniać poszczególne obiekty w grupie obiektów. W diagramach E‑R atrybuty przedstawiane są w formie kół lub elips.

13. Elementydiagramu E-R: • domena (Domain) - zakres wartości poszczególnych atrybutów, inaczej liczba wartości, którą dany atrybut może przyjąć. • relacja (Relation) - określa związek między obiektami. W diagramach E‑R relacje przedstawiane są w formie rombów. • typ relacji - związek między typami obiektów. W diagramach E‑R często jest tak, że typ relacji może mieć własne atrybuty. Co uznajemy za atrybut a co za typ relacji jest subiektywne i zależy od spojrzenia na model danych.

14. Rodzaje relacji • 1:1 (jeden do jednego) - relacja, w której każdemu obiektowi jednego typu odpowiada dokładnie jeden obiekt innego typu, np. każdy pracownik ma przyporządkowane jedno miejsce pracy i na danym miejscu pracy pracuje tylko jeden pracownik. • 1:N (jeden do wielu) - relacja, w której każdemu obiektowi jednego typu odpowiada jeden lub więcej obiektów innego typu, np. każda grupa dziekańska ma jednego lub więcej studentów, przy czym każdy student należy tylko to jednej grupy. • M:N (wiele do wielu)- relacja, w której N różnym obiektom jednego typu przyporządkowanych jest M różnych obiektów innego typu, np. gdy przy jednym projekcie pracuje wielu pracowników i jeden pracownik pracuje przy wielu projektach.

15. Rodzaje relacji - ćwiczenia I. Każdy pracownik pracuje dokładnie na jednym etacie. Jeden etat obsadzony jest najwyżej przez jednego pracownika.

16. Rodzaje relacji - ćwiczenia II. Na każdym etacie można pełnić tylko jedną funkcję. Każda funkcja może być pełniona na jednym lub wielu etatach.

17. Rodzaje relacji - ćwiczenia III. W każdym oddziale może być pełniona jedna lub więcej funkcji. Każda funkcja może być pełniona w jednym lub więcej oddziałów.

18. Rodzaje relacji - ćwiczenia IV. Każdy pracownik ma jedną lub więcej specjalizacji. Każda specjalizacja może być posiadana przez jednego lub więcej pracowników.

19. Tworzenie diagramu E-R • Identyfikacja obiektów i relacji między obiektami • Pogrupowanie obiektów w typy i przypisanie im atrybutów (jednoznacznie identyfikujących i opisujących) • Graficzne odzwierciedlenie typów obiektów, relacji i atrybutów • Bliższe opisanie rodzaju relacji między typami obiektów (1:1, 1:N lubM:N)

20. Diagram E-R -przykład

21. Modele baz danych • liniowy • hierarchiczny • sieciowy • relacyjny • obiektowy

22. Modelhierarchiczny

23. Model sieciowy

24. Model relacyjny Opracowany przez Amerykanina E.F. Codda w latach 1968 - 1973, który po raz pierwszy zrezygnował z graficznej formy prezentacji na rzecz tabelarycznej

25. Właściwości relacji • relacja ma jednoznaczną nazwę; • każdy rekord w relacji jest różny; • porządek rekordów jest nieistotny; • porządek kolumn jest nieistotny; • wartości w kolumnie są tego samego typu; • wszystkie rekordy danej tabeli mają jednakową długość • nie może być dwóch kolumn o takich samych nazwach

26. Model obiektowy • Trend rozwijający się w ostatnich latach • Podstawą modeli danych zorientowanych obiektowo są obiekty i logiczne połączenia między danymi. Poszczególne obiekty komunikują się ze sobą za pomocą tzw. metod, które są częścią składową obiektu. Obiekty określonej klasy mają szereg predefiniowanych metod.

27. System zarządzania bazą danych - DBMS (Data Base Management System) Programpozwalający zarządzać zasobami danych, zapewniając przechowanie danych, ich organizację i możliwości wyszukiwania.

28. Wymagania wobec DBMS: • niezależność danych • przyjazność użytkownikowi • wielodostępowość • efektywność • elastyczność • ochrona danych • bezpieczeństwo danych • integralność danych • brak redundancji

29. Normalizacja Czynność polegająca na podziale normalizowanej tabeli na kilka mniejszych tabel, będących w tzw. postaci normalnej.

30. Tak ukształtować strukturę bazy danych, by przetwarzanie danych było proste, a między atrybutami nie występowały niepożądane zależności podczas dodawania, usuwania i zmiany danych. Cel normalizacji

31. Powody normalizacji • uniknięcie redundancji. Jest to cecha niepożądana, powodująca niekorzystne zachowania bazy danych np. marnotrawstwo pamięci dyskowej albo problemy przy usuwaniu lub wstawianiu danych • uniknięcie niezgodności danych • uniknięcie błędów przy zmianie danych (tzw. anomalie Update/Insert/Delete) • uniknięcie pustych pól (mogą prowadzić do problemów przy przetwarzaniu danych)

32. Problemy: • Nadmiarowość (redundancja). Dane powtarzają się w kilku (wielu) wierszach. Adres1 niepotrzebnie się powtarza. W przypadku dodawania nowego zakupu przez Firmę1, gdy osoba wpisująca pomyli się i źle wpisze adres lub nazwę firmy, baza utraci spójność danych (nie będzie wiadomo która wartość jest prawidłowa). • Anomalie modyfikacji. W przypadku gdy Firma1 zmieni swój adres, trzeba zmienić wszystkie wiersze w tej tabeli. Jeśli nie zostanie zmieniony choćby jeden wiersz, baza utraci spójność danych. • Anomalie usunięć. Usunięcie jedynego zamówienia dla Firmy2 z tabeli powyżej spowoduje usunięcie wszelkich informacji o firmie, a tymczasem celowe może być zachowanie informacji o adresie firmy. W tej tabeli jest to niemożliwe. http://pl.wikipedia.org/wiki/Anomalie_%28bazy_danych%29

33. Wszystkie wartości atrybutów są elementarne. Inaczej: pola tabeli zawierają wartości elementarne Pierwsza postać normalna

34. Tabela przed normalizacją: Pierwsza postać normalna: http://pl.wikipedia.org/wiki/Posta%C4%87_normalna_%28bazy_danych%29

35. Druga postać normalna Pierwsza postać normalna + wszystkie pola tabeli niewchodzące w skład klucza głównego tabeli są w pełni funkcjonalnie od niego zależne. Pełna funkcjonalna zależność oznacza, że każdy atrybut niebędący kluczem może być zidentyfikowany jedynie przez podanie wszystkich wartości atrybutów stanowiących klucz główny.

36. Schemat zależności funkcjonalnych Informację, że atrybut A identyfikuje B (tzn. że B jest funkcjonalnie zależny od A) zaznaczono strzałkami biegnącymi od A do B. Źródło: http://galaxy.uci.agh.edu.pl/~chwastek/lectures/db/dbnormd.html

37. Zamówienia Części Dostawcy

38. Trzecia postać normalna Druga postać normalna + nie ma zależności przechodniości między atrybutami klucza głównego i atrybutami niestanowiącymi klucza. Np. przy relacjach: X→Y i Y→Z , X jest przechodnio zależne od Z. inaczej mówiąc: każda kolumna tabeli jest funkcjonalnie zależna od klucza tabeli, a nie od innych atrybutów.

39. Tabela niespełniająca 3 postaci normalnej: Po sprowadzeniu tabeli do 3 postaci normalnej: pracownicy stawki godzinowe

40. Normalizacja nrStud - numer studenta, nazStud - nazwisko studenta, adresStud - adres studenta, data - data egzaminu, nrPrzed - numer przedmiotu, nazPrzed - nazwa przedmiotu, nazGrPrzed - nazwa grupy przedmiotów, Pkt - punkty za grupę przedmiotów

41. Normalizacja Relacja w pierwszej postaci normalnej:

42. Normalizacja Relacja w drugiej postaci normalnej: studenci przedmioty oceny

43. Normalizacja Relacja w drugiej postaci normalnej: studenci oceny przedmioty

44. Normalizacja Relacja w trzeciej postaci normalnej: studenci przedmioty oceny grupy przedmiotów

45. Przy tworzeniu tabel na bazie diagramów E-R obowiązują następujące reguły: • Typy obiektów stają się tabelami. • Atrybuty każdego typu obiektów stają się kolumnami odpowiedniej tabeli. Atrybuty jednoznacznie identyfikujące obiekty stają się kluczami głównymi tabeli. • Relacje M:N stają się tabelami. Kolumnami tych tabel są atrybuty relacji oraz atrybuty jednoznacznie identyfikujące obiekty, których dotyczy relacja. • Przy relacji 1:N klucz główny typu obiektów leżącego po stronie 1 staje się kolumną tabeli, która odpowiada typowi obiektów leżącemu po stronie N. Dodatkowo tabela ta przejmuje atrybuty relacji. • Przy relacji 1:1 klucz główny typu obiektów staje się kolumną tabeli stworzonej z drugiego typu obiektów powiązanego relacją.

46. Sklep W sklepie jest do nabycia wiele różnych artykułów. Każdy klient może złożyć jedno lub więcej zamówień. Każde zamówienie ma swój unikalny numer i zawiera spis artykułów (wraz z ilością), które dany klient chce kupić. O klientach rejestrowane są następujące dane: nr, nazwa, adres; natomiast o artykułach: nr, nazwa i cena.

47. Lotnisko Okęcie Piloci latają samolotami w konkretne dni tygodnia. Jeden pilot może odbyć w jednym dniu wiele lotów. Jeden lot może być przeprowadzony w danym dniu przez wielu pilotów. Diagram zawiera informacje na temat numeru lotu, numeru samolotu, miejscowości docelowej oraz danych pilota (numer, nazwisko).

48. Firma Firma składa się z 5 oddziałów. Nazwy oddziałów są unikalne. W każdym oddziale zatrudniony jest przynajmniej jeden pracownik. O każdym pracowniku podane są takie informacje jak: imię, nazwisko oraz data urodzenia. Każdy z pracowników pracuje tylko w jednym oddziale, ale może wypełniać tam jedną lub wiele funkcji. Dana funkcja może być wypełniana przez jednego lub wielu pracowników. Nazwa funkcji jednoznacznie identyfikuje daną funkcję. Każda funkcja przypisana jest do jednej określonej taryfy, która decyduje o wysokości wynagrodzenia. Do tej samej taryfy może być przypisanych wiele funkcji. Nazwa taryfy jest jej jednoznacznym identyfikatorem.

49. Rozbuduj diagram tak, by rejestrował następujący fakt: Pracownik mógł zrealizować jeden lub wiele określonych projektów. Przy projekcie mógł pracować indywidualnie lub zespołowo. Każdy projekt miał określoną jednoznacznie identyfikującą go nazwę oraz należał do określonej kategorii projektów, od której uzależniona była premia dla pracownika. Do danej kategorii może należeć wiele projektów.

50. Relacyjna baza danych W 1990 roku E.F. Codd opracował listę 333 kryteriów, które powinny spełniać bazy danych, by można je nazwać relacyjnymi.Podstawą jest by RDBMS zawierał:DDL-Data Definition Language i DML-Data Manipulation Language. Oba te wymagania w wielu RDBMS spełnia SQL (Structured Query Language). Za pomocą SQLa można tworzyć bazę i przetwarzać dane.