internetowe bazy danychroman.ptak.staff.iiar.pwr.wroc.pl/bd_wyklad_1.pdf · •stanisław wrycza...

Bazy Danych

dr inż. Roman Ptak

Katedra Informatyki Technicznej

roman.ptak@pwr.edu.pl

Plan wykładu 2.

• Modelowanie danych (ERD)

• Normalizacja relacyjnych baz danych

• Modelowanie obiektowe (UML)

• Narzędzia CASE

2

WPROWADZENIE

3

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

4

Utrzymanie

Wdrożenie

Implementacja

Projektowanie

Analiza

Cykl projektowy systemu informatycznego

5

1. Kaskadowy

2. Typu V

3. Przyrostowy (ewolucyjny)

4. Szybkie prototypowanie (makietowanie)

5. Model spiralny

Modele procesu tworzenia oprogramowania

6

Model kaskadowy

Wymagania i specyfikacja

Projektowanie

Programowanie

Testowanie

Integracja

7

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

8

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

9

• Język modelowania UML

• Mapowanie obiektowo-relacyjne (ORM)

Obiektowy model danych

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

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

Analiza wymagań niefunkcjonalnych (2)

17

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

18

19

Przykład diagramu ERD

19

• 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

20

• 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 z nową encją.

Liczebność związków:

21

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

notacjach

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

• Model logiczny jest modelem świata

rzeczywistego, wyrażony za pomocą reguł

pewnego architektonicznego modelu

danych.

– Relacyjny model danych

• Transformacja modelu konceptualnego do

modelu logicznego

II. Projektowanie logiczne

23

• 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

24

NORMALIZACJA RELACYJNYCH

BAZ DANYCH

25

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).

26

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. 27

Etapy normalizacji

28

Pierwsza postać normalna – 1NF

• „Najsłabsza” postać.

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

danych.

• Wprowadza także pojęcie istnienia klucza

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

unikalny rekord.

• Dziedziny atrybutów elementarne.

• Rozbicie atrybutów na mniejsze czynniki.

29

1NF - przykład

• Brak normalizacji (UNF):

• Zastosowanie 1NF:

Imię i nazwisko Adres

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

Adrian Tomaszewski Gdańsk, 75-400, Traugutta 8

Imię Nazwisko Miasto Kod Ulica Numer

Andrzej Kowalski Wrocław 54-203 Legnicka 23

Adrian Tomaszewski Gdańsk 75-400 Traugutta 8

30

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).

31

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 2500

Antoni Polak Męska Frezer 2300

Imię Nazwisko Stanowisko Płaca

Antoni Gal Tokarz 2200

Natalia Holender Sekretarka 2500

Karolina Gal Sekretarka 2500

Antoni Polak Frezer 2300

Imię Płeć

Antoni Męska

Natalia Żeńska

Karolina Żeńska

1NF

2NF

32

Trzecia postać normalna (3NF)

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

od klucza głównego encji.

•Normalizacja do tej postaci polega na

przeniesieniu wszystkich pól niezależnych

od klucza do osobnej encji.

33

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

34

Wyższe postacie normalne

• 3,5 NF - Postać normalna Boyce’a-Codda

• 4 NF

• 5 NF

35

Wady normalizacji

• Zwiększenie ilości 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.

36

JĘZYK UML

Modelowanie obiektowe

37

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.

38

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

39

Definicja klasy wraz z kilkoma

obiektami (instancjami klasy)

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

UML

• UML (ang. Unified Modeling Language) -

Ujednolicony Język Modelowania

• Aktualna wersja: 2.4.1

41

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.

42

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/

43

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)

44

45

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.

45

Diagramy UML

• Diagramy struktury

• Diagramy zachowania (dynamiki)

46

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

Diagramy struktury UML

• Klas

• Obiektów

• Wdrożeniowy

– Komponentów

– Rozlokowania

• Pakietów

• Struktur połączonych

47

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

Diagramy dynamiki UML

• Przypadków użycia

• Czynności

• Interakcji

– Sekwencji

– Komunikacji

– Harmonogramowania

– Sterowania interakcją

• Maszyny stanowej

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

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.

49

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.

50

51 51

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.

52

53

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

54

55

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)

56

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 57

58

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.

59

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. 60

Przykłady

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

Ćwiczenia, Helion 2006.

61 61

DPU (ang. Use Case)

62

63

64

65

66

NARZĘDZIA DO MODELOWANIA

BAZ DANYCH

CASE (ang. Computer-Aided Software Engineering)

67

Wybrane narzędzia do modelowania

• Oracle MySQL Workbench

• Oracle SQL Developer Data Modeler

• SAP Sybase PowerDesigner DataArchitect

• IBM Rational Data Architect

• Microsoft Visio

68

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

69

MySQL Workbench

70

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

71

Oracle SQL Developer Data Modeler

72

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/

73

SAP Sybase PowerDesigner DataArchitect

74

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

75

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 76

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.

77

DZIĘKUJĘ ZA UWAGĘ

Pytania?