Internetowe Bazy Danych -...

Bazy Danych

dr inż. Roman Ptak

Katedra Informatyki Technicznej

[email protected]

Sprawy organizacyjne

• dr inż. Roman Ptak

[email protected]

bud. C3, pok. 321

• Konsultacje: Śr. 8:30-9:30, 11:00-13:00, Cz. 8:45-9:45

• Wykłady: czwartki (TN) 15:15-16:55

– 21.04, 5.05, 19.05, 2.06

• Materiały odstępne pod adresem:

roman.ptak.staff.iiar.pwr.wroc.pl

2

Plan wykładu 5.

• Wprowadzenie

• Modelowanie danych

– Modelowanie konceptualne (ERD)

– Modelowanie logiczne

– Modelowanie fizyczne

• Normalizacja relacyjnych baz danych

• Modelowanie obiektowe (UML)

• Narzędzia CASE

3

WPROWADZENIE

Inżynieria oprogramowania

Niestrukturalizowane tworzenie

oprogramowania

„Kryzys oprogramowania”

Nowy dział informatyki: Inżynieria

oprogramowania (ang. Software

engineering)

1. Projektowanie

2. Implementacja

Inżynieria baz danych

5

Utrzymanie

Wdrożenie

Implementacja

Projektowanie

Analiza

Cykl życia systemu informatycznego

6

1. Kaskadowy

2. Typu V

3. Przyrostowy (ewolucyjny)

4. Szybkie prototypowanie (makietowanie)

5. Model spiralny

Modele procesu tworzenia oprogramowania

7

Model kaskadowy

Wymagania i specyfikacja

Projektowanie

Programowanie

Testowanie

Integracja

8

Paradygmaty programowania

• programowanie proceduralne

• programowanie strukturalne

• programowanie funkcyjne

• programowanie imperatywne

• programowanie obiektowe

• programowanie uogólnione

• programowanie sterowane zdarzeniami

• programowanie logiczne (np. Prolog)

• programowanie aspektowe (np. AspectJ)

• programowanie deklaratywne

• programowanie agentowe

• programowanie modularne

9

Obecnie stosowane są dwie główne

metodologie tworzenia systemów

informatycznych:

• Podejście strukturalne – starsze ale

mające wiele zastosowań praktycznych

• Podejście obiektowe – nowsze, znajdujące

coraz większą popularność

Metodologie tworzenia systemów

10

MODELOWANIE ERD

11

Testowanie systemu

Tworzenie aplikacji

Opracowanie modelu fizycznego

Opracowanie modelu logicznego

Opracowanie konceptualnego modelu danych

Analiza wycinka rzeczywistości

Sformułowanie problemu

Etapy projektowania systemów bazodanowych

12

• Faza analizy

1. Analiza wycinka rzeczywistości

2. Analiza wymagań funkcjonalnych

3. Analiza wymagań niefunkcjonalnych

Model konceptualny

I. Projektowanie (modelowanie)

konceptualne

13

1. Analiza wycinka rzeczywistości

• Wywiad z ekspertem dziedzinowym

• Zadanie dla analityka

14

• Należy zidentyfikować i opisać funkcje,

np.:

– Wprowadzenia, modyfikowanie, usuwanie

danych – operacje CRUD (od ang. Create, Read,

Update i Delete),

– Wyszukiwanie danych,

– Przetwarzanie danych,

– Sporządzanie statystyk,

– Przygotowywanie raportów.

2. Analiza wymagań funkcjonalnych

15

• Na tym etapie opisujemy wszystkie

pozostałe aspekty związane z

opracowywana bazą danych

3. Analiza wymagań niefunkcjonalnych

16

• Tryb pracy (np. graficzny)

• Czy program ma pracować w sieci?

• Platforma sprzętowa (np. procesor Intel i7)

• Platforma systemowa (np. Windows 7)

• Środowisko implementacyjne BD (np. MySQL)

• Środowisko programistyczne (Visual C++)

• Rodzaj bazy danych (np. relacyjna)

• Oszacowanie liczby danych wejściowych,

tempo przyrostu danych

3. Analiza wymagań niefunkcjonalnych (2)

17

MODELOWANIE KONCEPTUALNE

Modelowanie ERD

• Model konceptualny (koncepcyjny, pojęciowy,

ang. Conceptual Data Model – CDM)

• Model konceptualny to model dla informacji

używanej w przedsiębiorstwie (niezależny od

aspektów fizycznych)

• Opracowanie modelu konceptualnego polega na

wyodrębnieniu i zdefiniowaniu encji, związków

między nimi oraz atrybutów

I. Model konceptualny

19

ERD – ang. Entity Relationship Diagram

• ERD jest graficznym odpowiednikiem modelu związków encji ERM

ERM – ang. Entity Relationship Model

EER – ang. Enhanced Entity–Relationship

• ERD pozwala na graficzne zamodelowanie struktur danych oraz relacji pomiędzy nimi.

• Mając diagram ERD korzystając z systemów CASE często mamy możliwość wygenerowania gotowej bazy danych.

Diagram Związków Encji

20

• Encja – jest „rzeczą”, która w

modelowanym środowisku jest

rozpoznawana jako istniejący niezależnie

obiekt, zdarzenie lub pojęcie

• Związek – reprezentuje powiązania między

encjami, wynikające z opisu

modelowawnego fragmentu rzeczywistości

– Opcjonalność związków

– Krotność związków

ERD – podstawowe pojęcia

21

• Jest „rzeczą”, która w modelowanym

środowisku jest rozpoznawana jako

istniejący niezależnie obiekt, zdarzenie

lub pojęcie

Encja (ang. entity)

NAZWA ENCJI

22

• Encja

– silna

– słaba

• Atrybut

– opcjonalny (nieobowiązkowy)

– obligatoryjny (wymagany)

Identyfikowanie encji

23

Silne i słabe zbiory encji

24

• ENC/x NAZWA ENCJI

– Semantyka encji – opis encji danego typu

– Wykaz atrybutów – lista atrybutów, ich opis i

dziedzina (typ)

– Klucze kandydujące – zbiory atrybutów

jednoznacznie identyfikujących encje

– Klucz główny – jeden z kluczy kandydujących

wybrany jako główny

– Charakter encji – encja silna lub słaba

Sposób przedstawienia opisu encji:

25

Wykaz atrybutów w formie tabeli

Nazwa atrybutu Opis atrybutu Typ OBL (+)/OPC(-)

NrOsoby Identyfikator osoby Liczba naturalna +

Nazwisko Nazwisko osoby max 30 znaków +

Imię Imię osoby max 20 znaków +

DataUrodzenia Data urodzenia osoby Data +

NIP Numer identyfikacji

podatkowej

Znakowy w postaci

[999-999-99-99] +

PESEL Numer identyfikacyjny

PESEL

Ciąg 11 cyfr +

Wykształcenie Wykształcenie osoby {podstawowe,

średnie, wyższe} +

26


NrOsoby Identyfikator osoby Liczba naturalna +

Nazwisko Nazwisko osoby max 30 znaków +

Imię Imię osoby max 20 znaków +

DataUrodzenia Data urodzenia osoby Data +

NIP Numer identyfikacji

podatkowej

Znakowy w postaci

[999-999-99-99] +

PESEL Numer identyfikacyjny

PESEL

Ciąg 11 cyfr +

Wykształcenie Wykształcenie osoby {podstawowe,

średnie, wyższe} +

Przykład: ENC/001 OSOBA

Klucze kandydujące: NrOsoby, NIP, PESEL

Klucz główny: NrOsoby

Charakter encji: encja silna

Semantyka encji – encja zawiera dane dotyczące pracownika szkoły (nauczyciel,

pracownik administracyjny i techniczny, obsługa szkoły).

Wykaz atrybutów:

27


NrPrzedmiotu Numer

porządkowy

Liczba dwucyfrowa

całkowita dodatnia +

NazwaPrzedmiotu Nazwa przedmiotu

nauczanego w

szkole

max 30 znaków

+

Przykład: ENC/002 PRZEDMIOT

Klucze kandydujące: NrPrzedmiotu

Klucz główny: NrPrzedmiotu

Charakter encji: encja silna

Semantyka encji – encja zawiera dane o przedmiocie nauczanym w szkole.

Wykaz atrybutów:

28

ENCJA A ENCJA B

• Reprezentuje powiązania między encjami,

wynikające z opisu modelowawnego fragmentu

rzeczywistości

• Związek jest opisywany

– nazwą

– liczebnością/krotnością (jak wiele?)

– typem uczestnictwa (opcjonalny/obligatoryjny)

Związek (ang. relationship)

ENCJA A ENCJA B

Nazwa związku

29

• 1:1 – jeden do jeden encji odpowiada dokładnie jedna encja

• 1:N – jeden do wiele encji odpowiada jedna lub więcej encji

• N:M – wiele do wiele jednej lub więcej encjom odpowiada jedna lub więcej encji

• W przypadku związków N:M należy dokonać normalizacji diagramu, która polega na dodaniu encji pośredniczącej i zastąpienie związku N:M dwoma związkami 1:N, 1:M z nową encją.

Liczebność związków:

30

Przykłady diagramów ERD w różnych

notacjach

źródło: pl.wikipedia.org/wiki/Diagram_zwi%C4%85zk%C3%B3w_encji 31

Przykład (notacja Martina)

32

Przykład modelu konceptualnego (notacja Chena)

33

• 0..* - zero lub więcej (opcjonalność, wiele)

• 0..1 – zero lub jeden (opcjonalność, jeden)

• 1..* - co najmniej jeden (obligatoryjność, wiele)

• * - zero lub więcej (opcjonalność, wiele)

• 2..6 – co najmniej 2, co najwyżej 6

• 1, 5-7 – jeden, pięć, cześć lub siedem

• brak – 1..1 (obligatoryjność, jeden)

Oznaczenia krotności w UML

34

PROJEKTOWANIE LOGICZNE

Modelowanie logiczne

• Model logiczny jest modelem świata

rzeczywistego, wyrażony za pomocą reguł

pewnego architektonicznego modelu

danych.

– Relacyjny model danych

• Transformacja modelu konceptualnego do

modelu logicznego – Zamiast encji tabele

– Zamiast związków „wiązania” poprzez klucze głównie

i obce, itd.

II. Projektowanie logiczne

36

1. Usunięcie własności niekompatybilnych z

modelem relacyjnym

2. Wyznaczenie relacji (tabel) dla modelu

logicznego

3. Normalizacja relacji

4. Weryfikacja, czy relacje umożliwiają realizację

transakcji

5. Wyznaczenie węzłów integralności

6. Omówienie modelu logicznego z użytkownikiem

Tworzenie i weryfikacja modelu logicznego:

37

1. Usunięcie binarnych związków typu

„wiele do wielu” (N:M)

2. Usunięcie rekurencyjnych związków

„wiele do wielu” (N:M)

3. Usunięcie związków złożonych

4. Usunięcie atrybutów wielowartościowych

Ad. 1. Usunięcie niekompatybilności z modelem

relacyjnym:

38

a. Wymagana obecność danych

b. Więzy dziedziny atrybutów

c. Integralność encji

d. Integralność referencyjna

e. Więzy ogólne

Ad. 5. Więzy integralności:

39

• Niektóre atrybuty zawsze muszą mieć

określoną wartość

• NN – not null

• N – nullable znacznik języka SQL NULL

Ad. 5a. Wymagana obecność danych

40

• Z każdym atrybutem związana jest

dziedzina – zbiór dopuszczalnych

wartości

• Np. atrybut płeć może przyjmować

wartości:

„K” i „M”

Ad. 5b. Więzy dziedziny atrybutów

41

• Klucz główny zbioru encji nie może

przyjmować wartości pustych (NULL)

Ad. 5c. Integralność encji

42

• Klucz obcy wiąże krotkę relacji

podrzędnej z krotką relacji nadrzędnej o

pasującej wartości odpowiedniego

klucza głównego.

Ad. 5d. Integralność referencyjna

43

1. Wstawienie krotki do relacji podrzędnej

2. Usuwanie krotki z relacji podrzędnej *

3. Modyfikacja klucza obcego krotki w relacji podrzędnej

4. Wstawienie krotki do relacji nadrzędnej *

5. Usunięcie krotki z relacji nadrzędnej NO ACTION, CASCADE, SET NULL, SET DEFAULT,

NO CHECK

6. Modyfikacja klucza głównego krotki nadrzędnej

* - Nie następuje naruszenie integralności ref.

Ad. 5d. Integralność referencyjna

44

• Reguły biznesowe

• Zasady działania

• Np. zasada, że personel obsługuje nie

więcej niż 10 nieruchomości

Ad. 5e. Więzy ogólne

45

Nazw

a a

trybutu

Dzie

dzin

a

Mask

a

OBL (

+)/

OPC

(-)

Wart

ość

dom

yśl

na

Ogra

nic

zenia

Unik

aln

ość

Klu

cz

Refe

rencji

e

Źró

dła

danych

NrKlienta Int+ + + PK SZBD

Nazwisko String[30] + USER

Imię String[15] + USER

DataUr Date ____-

__-__

- 1900.0

1.01

>{1899.0

1.01,

<{Date()

USER

NrMiasta Int+ + FK Miasta SZBD

Opis schematu relacji Klienci

46

Nazwa atrybutu Znaczenie

NrKlienta Unikalny identyfikator klienta, automatycznie nadawany

przez system, klucz główny

Nazwisko Nazwisko klienta, dowolny ciąg znaków, dozwolone litery

polskie

Imię Pierwsze imię klienta, dowolny ciąg znaków, dozwolone

litery polskie

DataUr Data urodzenia klienta

NrMiasta Identyfikator miasta, klucz obcy z tabeli Miasta

Znaczenie atrybutów w schemacie

relacji Klienci

47

NrKlienta Nazwisko Imię DataUr NrMiasta

1 Koperski Jan 1980.12.21 1

2 Walicki Łukasz 1979.11.11 1

3 Barycka Dorota 1977.03.18 2

4 Matacka Maria 5

5 Barycka Dorota 1981.03.18 3

6 Koperski Jan 1980.12.21 1

Przykładowe dane tabeli o schemacie

relacji Klienci

48

• ang. Databese schema

• Zbiór schematów relacji o różnych

nazwach

• Postać ogólna schematu bazy danych:

NAZWA BAZY DANYCH Nazwa_schematu_relacji_1(lista_atrybutów_schematu_relacji_1)

Nazwa_schematu_relacji_1(lista_atrybutów_schematu_relacji_1)

…

Schemat relacyjnej bazy danych

49

WYPOŻYCZALNIA Klienci(NrKlienta, Nazwisko, Imię, Miasto, UlicaNr)

Gatunki(KodGatunku, Rodzaj)

Filmy(KodFilmu, Tytuł, CzasTrwania, #KodGatunku)

Płyty(NrPłyty, Opis, #KodFilmu)

Wypożyczenia(NrWypożyczania, #NrKlienta, #NrPłyty,

DataWypożyczenia, DataZwrotu, Opłata)

Przykład

50

Model logiczny (fizyczny)

51

• ang. data dictionary

• „Baza danych” (almanach) projektanta baz

danych

• Zestawienie:

– Nazw kolumn

– Domen (dziedzin) – określające typy danych

– Ograniczeń

Słownik danych (atrybutów)

52

Nazwa atrybutu Dziedzina Przynależność do

schematu relacji

DataSprzedaży Date Faktury

DataUrodzenia Date Klienci

IdMiasta Int+ Miasta

IdTowaru Int+ Towary

SzczegółyFaktury

Liczba Int SzczegółyFaktury

Jednostki String[10] SzczegółyFaktury

Imię String[15] Klienci

NazwaMiasta String[15] Miejscowości

NazwaTowaru String[25] Towary

NazwiskoKlienta Nazwisko Klienci

NrKlienta Int+ Klienci

Fakrury

Słownik danych - przykład uporządkowanie alfabetyczne

maksymalna szerokość kolumny, liczba

miejsc po przecinku, wzorzec (maska)

wprowadzania danych, wartości

domyślne, ograniczenie zakresu

dozwolonych wartości, czy dopuszczalne

są wartości NULL itp.

własna domena Nazwisko – łańcuch co

najwyżej 25 znakowy, zawierający litery,

myślnik, apostrof i spację

53

PROJEKTOWANIE FIZYCZNE

Modelowanie fizyczne

• Modelowanie fizyczne obejmuje

konstruowanie modelu świata

rzeczywistego wyrażonego za pomocą

struktur danych i mechanizmów dostępu

istniejących w wybranym SZBD.

• Wybór konkretnego SZBD.

III. Projektowanie fizyczne

55

• Definicja zakresu i celów wyboru

• Wybór kilku produktów

– Oracle/MySQL, PostgreSQL, MS SQL Server, …

• Ocena produktów

• Rekomendacja wyboru i sporządzenie

raportu

Wybór SZBD

56

Typ Rozmiar Opis

CHAR[length] length bajtów Pole o stałej długości,

przechowuje od 0 do 255

znaków

VARCHAR[Length] Długość łańcucha + 1 bajt Pole tekstowe o zmiennej

długości do 255 znaków

TEXT Długość łańcucha + 2 bajty Łańcuch o maksymalnej

długości 65535 znaków

INT 4 bajty Liczba całkowita

FLOAT 4 bajty Liczba zmiennoprzecinkowa

DATE 3 bajty Data w formacie YYYY-MM-DD

TIME 3 bajty Data w formacie HH:MM:SS

DATETIME 8 bajtów Data w formacie YYYY-MM-DD

HH:MM:SS

Wybrane typy danych MySQL

57

• Widoki

• Indeksy

• Procedury składowane

• Wyzwalacze

Inne elementy baz danych:

58

• Logiczny byt (obiekt), osadzony na

serwerze baz danych. Umożliwia dostęp do

podzbioru kolumn i wierszy tabel lub

tabeli na podstawie zapytania w języku

SQL.

• Perspektywy nazywane w MS Access

kwerendami (wybierającymi)

Widoki (perspektywy)

59

Widoki (perspektywy)

Tabela B

Tabela A

Widok

Zapytanie SELECT …

60

• Struktura danych zwiększającą szybkość

wykonywania operacji wyszukiwania na

tabeli

Indeksy

61

• Procedury składowane są zbiorami instrukcji języka SQL zapisanymi pod wspólną nazwą i wywoływanymi jak pojedyncza instrukcja.

• Procedury składowane umożliwiają: 1. Przekazywanie parametrów wywołania.

2. Wykonywanie prawie wszystkich instrukcji języka SQL, w tym wywoływania innych procedur składowanych.

3. Zwracanie dowolnej liczby wyników do programu, który wywołał procedurę.

4. Zwracanie informacji o udanej lub niewykonanej procedurze.

Procedury składowane

62

• implementowania reguł logiki biznesowej,

• zabezpieczenia obiektów bazy danych przed bezpośrednim dostępem użytkowników,

• chronienia bazy danych przed atakami polegającymi na iniekcji kodu SQL,

• poprawienia wydajności często wykonywanych instrukcji,

• zminimalizowania obciążenia sieci (zamiast wysyłać całe instrukcje języka SQL użytkownik wywołuje jedynie procedurę, wysyłając jej nazwę i przekazując parametry jej wywołania).

Procedury składowane są powszechnie

wykorzystywane w celu:

63

• Wyzwalacze są specjalnym typem

procedur składowanych powiązanych z

wybranymi tabelami i wywoływanych

wykonaniem instrukcji języka SQL: INSERT,

UPDATE albo DELETE.

Wyzwalacze

64

Model związków encji (ERM)

Model konceptualny (CDM)

Model logiczny (LDM)

Model fizyczny (PDM)

BD

Powtórzenie: etapy projektowania

• Zawiera encje i związki

•Zidentyfikowane atrybuty

•Zidentyfikowane klucze kandydujące

•Zawiera relacje (tabele)

•Zdefiniowane atrybuty i wybrane klucze główne

•Normalizacja do 3NF

•Typy danych konkretnego SZBD

•Możliwa denormalizacja

•Zawiera indeksy, reguły walidacji, wyzwalacze, procedury składowane

65

Bazy nierelacyjne (NoSQL)

• NoSQL - Not Only SQL

– bazy klucz-wartość

– bazy dokumentowe

– bazy grafowe

• W tym przypadku model konceptualny

inaczej przekłada się na model logiczny i

fizyczny.

66

NORMALIZACJA RELACYJNYCH

BAZ DANYCH

Normalizacja baz danych

• Proces modyfikacji wybranej relacyjnej

bazy danych według ustalonych zasad.

• Proces ten polega na modyfikacji

schematu bazy danych, a nie na usuwaniu

danych.

• Mówimy o tzw. postaciach normalnych

(ang. Normal Form, NF).

68

W jakim celu normalizujemy?

• Bazy danych normalizujemy w celu

uniknięcia anomalii:

– Redundancji danych – dane powtarzają się w

kilku krotkach,

– Modyfikacji niespójność danych – dana

zostanie zmodyfikowana tylko w jednej

krotce,

– Problemów z dołączaniem i usuwaniem danych

– np. usuwając krotkę możemy stracić pewne

informacje. 69

Etapy normalizacji

70

Pierwsza postać normalna (1NF)

• „Najsłabsza” postać.

• Pierwsza postać normalna mówi o atomowości

danych.

• Dziedziny atrybutów elementarne.

• Rozbicie atrybutów na mniejsze czynniki.

• Wprowadza także pojęcie istnienia klucza

głównego identyfikującego bezpośrednio każdy

unikalny rekord.

71

1NF – przykład 1. NrOsoby Nazwisko Imię Imiona

dzieci

DatyUrDzieci

1 Adurska Janina

2 Badurska Genowefa Adam 1960.03.10

3 Badurska Maria Adam

Ewa

Hanna

1950.05.11

1954.01.01

1960.02.04

4 Wadurska Teresa Monika

Roland

1962.08.03

1962.08.03

NrOsoby Nazwisko Imię Imiona dzieci DatyUrDzieci

2 Badurska Genowefa Adam 1960.03.10

3 Badurska Maria Adam 1950.05.11

3 Badurska Maria Ewa 1954.01.01

3 Badurska Maria Hanna 1960.02.04

4 Wadurska Teresa Monika 1962.08.03

4 Wadurska Teresa Roland 1962.08.03

UNF

1NF

72

1NF – przykład 2.

• Brak normalizacji (UNF):

• Zastosowanie 1NF:

Imię i nazwisko Adres

Andrzej Kowalski Wrocław, 54-203, Legnicka 23

Adrian Tomaszewski Gdańsk, 75-400, Traugutta8

Imię Nazwisko Miasto Kod Ulica Numer

Andrzej Kowalski Wrocław 54-203 Legnicka 23

Adrian Tomaszewski Gdańsk 75-400 Traugutta 8

73

Druga postać normalna (2NF)

• Każdy atrybut, który nie jest kluczowy, jest

w pełni funkcyjnie zależny od każdego

potencjalnego klucza głównego

(kandydującego).

74

2NF - przykład

Imię Nazwisko Płeć Stanowisko Płaca

Antoni Gal Męska Tokarz 2200

Natalia Holender Żeńska Sekretarka 2500

Karolina Gal Żeńska Sekretarka 3100

Antoni Polak Męska Frezer 2300

Imię Nazwisko Stanowisko Płaca

Antoni Gal Tokarz 2200

Natalia Holender Sekretarka 2500

Karolina Gal Sekretarka 3100

Antoni Polak Frezer 2300

Imię Płeć

Antoni Męska

Natalia Żeńska

Karolina Żeńska

1NF

2NF

75

Trzecia postać normalna (3NF)

•Nie występują żadne pola, które nie zależą

wyłącznie od klucza głównego encji

– przechodnia (tranzytywna) zależność

funkcyjna

•Bada się zależności między atrybutami

niekluczowymi.

•Normalizacja do tej postaci polega na

przeniesieniu wszystkich pól zależnych

tranzytywnie do osobnej encji. 76

Przechodnia zależność funkcyjna

podzbioru atrybutów C od A

77

3NF - przykład

NrFaktury NazwaKlienta Miasto Kod Ulica Numer

100 Animex Wrocław 54-203 Legnicka 32

101 Animex Wrocław 54-203 Legnica 32

102 Betard Gdańsk 80-827 Długa 3

NrFaktury Nazwa Klienta

100 Animex

101 Animex

102 Betard

NazwaKlienta Miasto Kod Ulica Numer

Animex Wrocław 54-203 Legnicka 32

Betard Gdańsk 80-827 Długa 3

2NF

3NF

NrFaktury NazwaKlienta Miasto

78

Wyższe postacie normalne

• 3,5 NF (postać normalna Boyce’a-Codda) –

rozwiązuje problemy kluczy

kandydujących

• 4 NF – rozwiązuje problemy zależności

wielowartościowych

• 5 NF – rozwiązuje problemy zależności

złączeń

• 6 NF – wykorzystywana przede wszystkim

w odniesieniu do danych przestrzennych 79

• Zadanie zaprojektowania bazy danych dla małej firmy sprzedającej materiały do krycia dachów.

• Analiza przedsiębiorstwa doprowadziła do wniosku, że dla działu obsługi zamówień w firmie najbardziej odpowiednie będą dane: – NrZamówienia

– DataZamówienia

– NrOdbiorcy

– NazwaOdbiorcy

– NrProduktu

– NazwaProduktu

– Liczba

– CenaJednostkowa

Przykład

80

NrZamó

wienia

DataZamów

ienia

NrOdbi

orcy

NazwaOd

biorcy

NrProduktu NazwaProduktu Liczba CenaJednos

tkowa

23 2015.02.01 2235 Davies 487

340

dachówki (niebieskie)

zaprawa (1 kg)

200

10

0,25

1,25

24 2015.02.08 3444 Jones 488

340

342

dachówki (białe)

zaprawa

cement

300

30

30

0,20

1,25

1,50

25 2015.02.10 3444 Jones 489 dachówki (czerwone) 150 0,25

26 2015.02.01 2237 Evans 488 dachówki (białe) 400 0,20

Tabela nieznormalizowana

Zamówienia

81

NrZamó

wienia

DataZamówi

enia

NrOdbiorcy Nazwa

Odbiorcy

NrProdu

ktu

NazwaProduktu Liczba CenaJe

dnostko

wa

23 2015.02.01 2235 Davies 487 dachówki (niebieskie) 200 0,25

23 2015.02.01 2235 Davies 340 zaprawa (1 kg) 10 1,25

24 2015.02.08 3444 Jones 488 dachówki (białe) 300 0,20

24 2015.02.08 3444 Jones 340 zaprawa 30 1,25

24 2015.02.08 3444 Jones 342 cement 30 1,50

25 2015.02.10 3444 Jones 489 dachówki (czerwone) 150 0,25

26 2015.02.01 2237 Evans 488 dachówki (białe) 400 0,20

Relacja uniwersalna

Zamówienia

82

NrZamówienia DataZamówienia NrOdbiorcy NazwaOdbiorcy

23 2015.02.01 2235 Davies

23 2015.02.01 2235 Davies

24 2015.02.08 3444 Jones

24 2015.02.08 3444 Jones

24 2015.02.08 3444 Jones

25 2015.02.10 3444 Jones

26 2015.02.01 2237 Evans

Zamówienia

NrZamówienia NrProduktu NazwaProduktu Liczba CenaJednostkowa

23 487 dachówki (niebieskie) 200 0,25

23 340 zaprawa (1 kg) 10 1,25

24 488 dachówki (białe) 300 0,20

24 340 zaprawa (1 kg) 30 1,25

24 342 cement (1 kg) 30 1,50

25 489 dachówki (czerwone) 150 0,25


WierszeZamówienia

83


23 2015.02.01 2235 Davies

24 2015.02.08 3444 Jones

25 2015.02.10 3444 Jones

26 2015.02.01 2237 Evans

Zamówienia

WierszeZamówienia

NrZamówienia NrProduktu NazwaProduktu Liczba CenaJednostkowa

23 487 dachówki (niebieskie) 200 0,25

23 340 zaprawa (1 kg) 10 1,25


24 340 zaprawa (1 kg) 30 1,25

24 342 cement (1 kg) 30 1,50

25 489 dachówki (czerwone) 150 0,25

26 488 dachówki (białe) 400 0,20 84


23 2015.02.01 2235 Davies

24 2015.02.08 3444 Jones

25 2015.02.10 3444 Jones

26 2015.02.01 2237 Evans

Zamówienia

NrZamówienia NrProduktu Liczba

23 487 200

23 340 10

24 488 300

24 340 30

24 342 30

25 489 150

26 488 400

WierszeZamówienia

NrProduktu NazwaProduktu CenaJednostkowa

487 dachówki (niebieskie) 0,25

340 zaprawa (1 kg) 1,25

488 dachówki (białe) 0,20

340 zaprawa (1 kg) 1,25

342 cement (1 kg) 1,50

489 dachówki (czerwone) 0,25


Produkty

2NF

85


23 2015.02.01 2235 Davies

24 2015.02.08 3444 Jones

25 2015.02.10 3444 Jones

26 2015.02.01 2237 Evans

Zamówienia


23 487 200

23 340 10

24 488 300

24 340 30

24 342 30

25 489 150

26 488 400

WierszeZamówienia



340 zaprawa (1 kg) 1,25


342 cement 1,50


Produkty

2NF

NrZamówienia NrOdbiorcy NazwaOdbiorcy

86

NrZamówienia DataZamówienia NrOdbiorcy

23 2015.02.01 2235

24 2015.02.08 3444

25 2015.02.10 3444

26 2015.02.01 2237

Zamówienia


23 487 200

23 340 10

24 488 300

24 340 30

24 342 30

25 489 150

26 488 400

WierszeZamówienia

Produkty

NrOdbiorcy NazwaOdbiorcy

2235 Davies

3444 Jones

3444 Jones

2237 Evans

Odbiorcy

3NF



340 zaprawa (1 kg) 1,25


342 cement 1,50


87

NrZamówienia DataZamówienia NrOdbiorcy

23 2015.02.01 2235

24 2015.02.08 3444

25 2015.02.10 3444

26 2015.02.01 2237

Zamówienia


23 487 200

23 340 10

24 488 300

24 340 30

24 342 30

25 489 150

26 488 400

WierszeZamówienia

Produkty

NrOdbiorcy NazwaOdbiorcy

2235 Davies

3444 Jones

2237 Evans

Odbiorcy

3NF



340 zaprawa (1 kg) 1,25


342 cement 1,50


88

Wady normalizacji

• Zwiększenie liczby tabel = zmniejszenie

wydajności, poprzez konieczność

wykonywania złączeń przez RDBMS.

• Więc czasami decydujemy się na

denormalizację danych.

• Hurtownia danych jest przykładem

zdenormalizowanej postaci danych.

89

Hurtownia danych

• Analityczna baza danych wykorzystywana

jako podstawa systemu wspomagającego

podejmowanie decyzji.

• Projektowana dla dużej liczby stałych

danych.

90

Bez powtórzeń (1NF)

Dane zależą od klucza

Od całego klucza (2NF)

I tylko od klucza (3NF/BCNF)

Tak mi dopomóż Codd!

Przysięga normalizacyjna

Edgar Frank Codd (1923-2003)

91

JĘZYK UML

Modelowanie obiektowe

• Język modelowania UML

• Mapowanie obiektowo-relacyjne (ORM)

Obiektowy model danych

93

Modelowanie obiektowe

• Modelowania systemów informacyjnych z wykorzystaniem podejścia obiektowego i języka UML.

• Zastosowania języka UML w różnych obszarach, od projektowania systemów czasu rzeczywistego poprzez projektowanie baz danych aż po modelowanie systemów biznesowych.

94

Klasa a obiekt klasy

• Obiekt – konkretne wystąpienie abstrakcji

– byt o dobrze określonych granicach i tożsamości

– obejmuje stan i zachowanie

– egzemplarz klasy

• Klasa – opis zbioru obiektów, które mają takie same atrybuty, operacje,

związki i znaczenie

– częściowa lub całkowita definicja dla obiektów

– zbiór wszystkich obiektów mających wspólną strukturę i zachowanie

95

Definicja klasy wraz z kilkoma

obiektami (instancjami klasy)

Źródło: http://www.egrafik.pl/kurs-c-plus-plus/6.1.php 96

UML

• UML (ang. Unified Modeling Language) -

Ujednolicony Język Modelowania

• Aktualna wersja: 2.4.1

97

UML

• Graficzny język do obrazowania, specyfikowania,

tworzenia i dokumentowania elementów

systemów informatycznych.

• Diagramy UML to schematy przedstawiające

zbiór bytów i związków między nimi.

98

Literatura (wybór)

• G. Booch, J. Rumbaugh, I. Jacobson, UML

przewodnik użytkownika, WN-T, Warszawa

2002.

• R. A. Maksimchuk, E. J. Naiburg, UML dla

zwykłych śmiertelników, Warszawa 2007.

• http://www.uml.org/

• http://www.omg.org/spec/UML/

99

Historia UML

• Modelowanie obiektowe w latach 70 i 80

• 1996 r. – dokumentacja wersji 0.9

• 1997 r. – UML 1.0 w gestii Object

Management Group (OMG)

• Wersje: 1.1, 1.2, 1.3, 1.4, 1.4.2 (ta została

poddana standaryzacji ISO/IEC 19501), 1.5, 2.1.1,

2.1.2

• 2012 r. – najnowsza wersja: 2.4.1 (ISO/IEC 19505-1 i 19505-2)

100

101

Zastosowania

• tworzenie systemów informacyjnych przedsiębiorstw,

• usługi bankowe i finansowe,

• przemysł obronnym i lotniczy,

• rozproszone usługi internetowe,

• telekomunikacja,

• transport,

• sprzedaż detaliczna,

• elektronika w medycynie,

• nauka.

101

Diagramy UML

• Diagramy struktury

• Diagramy zachowania (dynamiki) Diagramy UML

Diagramy struktury Diagramy zachowania

Diagramy klas

Diagramy obiektów

Diagramy wdrożenia

Diagramy komponentów

Diagramy przypadków użycia

Diagramy stanów

Diagramy czynności

Diagramy interakcji

Diagramy przebiegu Diagramy kooperacji 102

Diagramy struktury UML

• Klas

• Obiektów

• Wdrożeniowy

– Komponentów

– Rozlokowania

• Pakietów

• Struktur połączonych

źródło: http://www.erudis.pl/pl/node/93

103

Diagramy dynamiki UML

• Przypadków użycia

• Czynności

• Interakcji

– Sekwencji

– Komunikacji

– Harmonogramowania

– Sterowania interakcją

• Maszyny stanowej źródło: http://www.erudis.pl/pl/node/93

104

Zastosowania w projektowaniu

systemów informatycznych • Projektując system informatyczny, rozpoczyna się

przeważnie od tworzenia diagramów w następującej kolejności: – Przypadków użycia,

– Klas,

– Czynności,

– Sekwencji.

• Są to najczęściej wykorzystywane diagramy. Pozostałe z nich bywają pomijane, zwłaszcza przy budowaniu niedużych systemów informatycznych.

105

Diagramy przypadków użycia

(Use Case Diagrams) • Definicja:

Diagramy służące do modelowania zachowania systemu. Opisują co system powinien robić z punktu widzenia obserwatora z zewnątrz. Przedstawiają scenariusze realizacji określonych zachowań (funkcji systemu).

• Zawartość: – przypadki użycia (ang. use case) - opisy zdarzeń,

– aktorzy - osoby/rzeczy inicjujące zdarzenia,

– powiązania między aktorami i przypadkami użycia,

– zależności, uogólnienia i powiązania między przypadkami użycia,

– pakiety, notatki i ograniczenia.

• Zastosowania: – modelowanie zachowania bytów - opis ciągu akcji zmierzających do realizacji

danej funkcji systemu,

– modelowanie otoczenia systemu - definiowanie aktorów i ich ról,

– modelowanie wymagań stawianych systemowi – określenie co system powinien robić,

– testowanie systemu.

106

107 107

Diagramy klas (Class Diagrams)

• Definicja:

Schemat przedstawiający zbiór klas, interfejsów, kooperacji oraz związki między nimi.

• Używa się ich do modelowania struktury systemu.

• Stanowią bazę wyjściową dla diagramów komponentów i diagramów wdrożenia.

• Szczególnie przydatne do tworzenia systemów (inżynieria do przodu i wstecz).

• Zawartość: – klasy,

– interfejsy,

– kooperacje,

– zależności, uogólnienia, powiązania,

– notatki, ograniczenia, pakiety, podsystemy.

• Zastosowania: – modelowanie słownictwa systemu (struktura systemu),

– modelowanie prostych kooperacji,

– modelowanie schematu logicznej bazy danych.

108

Diagramy czynności

(Activity Diagrams)

• Definicja:

Diagramy czynności (schematy blokowe) przedstawiają przepływ sterowania od czynności do czynności. Większość diagramów czynności przedstawia kroki procesu obliczeniowego.

• Zawartość: – stany akcji i stany czynności,

– przejścia,

– obiekty,

– notatki i ograniczenia.

• Zastosowania: – modelowanie przepływu czynności

– Modelowanie operacji

110

Diagramy interakcji

• Definicja:

Diagramy interakcji (ang. Interaction Diagrams) służą do modelowania zachowania systemu. Ilustrują kiedy i w jaki sposób komunikaty przesyłane są pomiędzy obiektami.

• Diagramy przebiegu (ang. Sequence Diagrams)

• Diagramy kooperacji (ang. Collaboration Diagrams)

112

Diagramy interakcji

Na diagramie przebiegu uwypukla się kolejność wysyłania komunikatów w czasie.

Na diagramie kooperacji kładzie się nacisk na związki strukturalne między obiektami wysyłającymi i odbierającymi komunikaty.

Zawartość: – obiekty,

– wiązania,

– komunikaty,

– notatki i ograniczenia.

• Zastosowania: – modelowanie przepływu sterowania z uwzględnieniem

kolejności

– komunikatów w czasie,

– modelowanie przepływu sterowania z uwzględnieniem organizacji strukturalnej obiektów 113

Wybrane aplikacje wspomagające

tworzenie diagramów (darmowe) • ArgoUML - napisany w Javie, zaawansowane generowanie

kodu i podpowiedzi, ciągle tworzony,

• StarUML - środowiska modelowania pod platformę Windows,

• Dia - ogólne narzędzie do rysowania diagramów,

• UML Sculptor - prosty, łatwy w użyciu program do tworzenia diagramów klas,

• Umbrello - program dla Linuksa, część KDE,

• UMLpad,

• JUDE Community,

• NetBeans.

115

Wybrane aplikacje wspomagające

tworzenie diagramów (komercyjne)

• Borland Together - rodzina programów integrujących się z różnymi IDE, jest wersja darmowa,

• Poseidon for UML - zaawansowane narzędzie bazujące na ArgoUML, darmowa edycja Community,

• Enterprise Architect - Profesjonalne narzędzie w przystępnej cenie o wygodnym interfejsie działające na platformach Windows i Linux. Wspiera UML 2.0,

• Rodzina programów iGrafx - narzędzia począwszy od iGrafx FlowCharter wspierają tworzenie diagramów UML. Wersja testowa na witrynie iGrafx,

• Visual Paradigm for UML,

• IBM Rational Rose,

• Telelogic Tau G2,

• Visio. 116

Przykłady

• Stanisław Wrycza (red.), UML 2.1,

Ćwiczenia, Helion 2006.

117 117

DPU (ang. Use Case)

118

NARZĘDZIA DO MODELOWANIA

BAZ DANYCH

CASE (ang. Computer-Aided Software Engineering)

Wybrane narzędzia do modelowania

• Oracle MySQL Workbench

• Oracle SQL Developer Data Modeler

• SAP Sybase PowerDesigner DataArchitect

• IBM Rational Data Architect

• Microsoft Visio

124

Oracle MySQL Workbench

• Narzędzie do zarządzania i modelowania baz

danych MySQL

• Wsparcie dla projektowania baz na poziomach

koncepcyjnym, logicznym i fizycznym

• Wsparcie dla procesów reverse-engineeringu

• Możliwość generowania skryptów SQL

• Wersja: 6.2.5.0

• Licencja: GNU GPLicense lub zamknięta EULA

• http://www.mysql.com/products/workbench

125

MySQL Workbench

126

Oracle SQL Developer Data Modeler

• Zintegrowane środowisko programistyczne

dla użytkowników zajmujących się

programowaniem baz firmy Oracle

• Wersja: 4.0.3.853

• Licencja: zamknięta • http://www.oracle.com/technetwork/developer-

tools/datamodeler/overview/index.html

• http://www.oracle.com/technetwork/developer-

tools/datamodeler/downloads/datamodeler-087275.html

127

Oracle SQL Developer Data Modeler

128

SAP Sybase PowerDesigner DataArchitect

• Narzędzie do modelowania systemów: baz

danych, hurtowni danych, modelowanie

obiektowe, modelowanie procesów

biznesowych i in.

• Wersja: 16.5

• Licencja: zamknięta

• Cena: ~2000 € - ~10000 € źródło: www.powerdesigner.de/en/pricing/

129

SAP Sybase PowerDesigner DataArchitect

130

Porównanie narzędzi

Sebastian Łacheciński, Analiza porównawcza Wybranych narzędzi CASE

do modelowania danych w procesie projektowania relacyjnych baz

danych, (w:) Informatyka Ekonomiczna Business Informatics, nr 1 (31),

2014, s. 239-258.

http://www.dbc.wroc.pl/dlibra/doccontent?id=25198

131

Testom poddane zostały:

• ER Studio XE5 Data Architect 9.7

• CA ERWin 9.5 Workgroup

• SAP Sybase Power Designer 16.5 Data Architect RE

• Oracle SQL Developer Data Modeler 4.0.1

• MySQL Workbench 6.1.4

• MS Visio 2010/2013 Professional

• IBM InfoSphere Data Architect 9.1 132

Wyniki

• Najlepszy: SAP Sybase PowerDesigner 16.5

• Dla darmowych narzędzi najlepszy wynik

osiągnął: Oracle SQL Developer Data

Modeler v. 4

• Dla wdrożeń w oparciu o serwer MySQL

rozsądnym wyborem jest: MySQL

Workbench 6.1.4.

133

DZIĘKUJĘ ZA UWAGĘ

Pytania?

Internetowe Bazy Danych -...

Documents

Transcript of Internetowe Bazy Danych -...