Wykład 1. - dr inż. Roman Ptak

Bazy Danych
dr inż. Roman Ptak
Katedra Informatyki Technicznej
[email protected]
Plan wykładu 2.
•
•
•
•
2
Modelowanie danych (ERD)
Normalizacja relacyjnych baz danych
Modelowanie obiektowe (UML)
Narzędzia CASE
WPROWADZENIE
3
Inżynieria oprogramowania
4
Niestrukturalizowane tworzenie
oprogramowania
„Kryzys oprogramowania”
Nowy dział informatyki: Inżynieria
oprogramowania (ang. Software
engineering)
1. Projektowanie
2. Implementacja
 Inżynieria baz danych
Cykl projektowy systemu informatycznego
Analiza
Projektowanie
Implementacja
Wdrożenie
Utrzymanie
5
Modele procesu tworzenia oprogramowania
1.
2.
3.
4.
5.
6
Kaskadowy
Typu V
Przyrostowy (ewolucyjny)
Szybkie prototypowanie (makietowanie)
Model spiralny
Model kaskadowy
Wymagania i specyfikacja
Projektowanie
Programowanie
Testowanie
Integracja
7
Paradygmaty programowania
•
•
•
•
•
•
•
•
•
•
•
•
8
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
Metodologie tworzenia systemów
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ść
9
Obiektowy model danych
• Język modelowania UML
• Mapowanie obiektowo-relacyjne (ORM)
10
MODELOWANIE ERD
11
Etapy projektowania systemów bazodanowych
Sformułowanie problemu
Analiza wycinka rzeczywistości
Opracowanie konceptualnego modelu danych
Opracowanie modelu logicznego
Opracowanie modelu fizycznego
Tworzenie aplikacji
Testowanie systemu
12
I. Projektowanie (modelowanie)
konceptualne
• Faza analizy
1. Analiza wycinka rzeczywistości
2. Analiza wymagań funkcjonalnych
3. Analiza wymagań niefunkcjonalnych
Model konceptualny
13
1. Analiza wycinka rzeczywistości
• Wywiad z ekspertem dziedzinowym
14
2. Analiza wymagań funkcjonalnych
• 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.
15
3. Analiza wymagań niefunkcjonalnych
• Na tym etapie opisujemy wszystkie
pozostałe aspekty związane z
opracowywana bazą danych
16
Analiza wymagań niefunkcjonalnych (2)
•
•
•
•
•
•
•
•
17
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
Diagram Związków Encji
 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.
18
Przykład diagramu ERD
19
19
ERD – podstawowe pojęcia
• 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
20
Liczebność związków:
• 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ą.
21
Przykłady diagramów ERD w różnych
notacjach
22
źródło: pl.wikipedia.org/wiki/Diagram_zwi%C4%85zk%C3%B3w_encji
II. Projektowanie 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
23
III. Projektowanie 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.
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):
Imię i nazwisko
Adres
Andrzej Kowalski
Wrocław, 54-203, Legnicka 23
Adrian Tomaszewski Gdańsk, 75-400, Traugutta 8
• Zastosowanie 1NF:
Imię
Andrzej
Adrian
30
Nazwisko
Miasto
Kowalski
Wrocław
Tomaszewski Gdańsk
Kod
54-203
75-400
Ulica
Legnicka
Traugutta
Numer
23
8
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
32
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
Imię
Płeć
Antoni
Gal
Tokarz
2200
Antoni
Męska
Natalia
Holender
Sekretarka
2500
Natalia
Żeńska
Karolina
Gal
Sekretarka
2500
Karolina
Żeńska
Antoni
Polak
Frezer
2300
1NF
2NF
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
34
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
Animex
Betard
Kod
3NF
Ulica
Numer
Wrocław 54-203
Legnicka
32
Gdańsk
Długa
3
80-827
2NF
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
Modelowanie obiektowe
JĘZYK UML
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)
40
Źródło: http://www.egrafik.pl/kurs-c-plus-plus/6.1.php
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
44
(ISO/IEC 19505-1 i 19505-2)
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
45
Diagramy UML
• Diagramy struktury
• Diagramy zachowania (dynamiki)
Diagramy UML
Diagramy struktury Diagramy zachowania
Diagramy klas
46
Diagramy przypadków użycia
Diagramy obiektów
Diagramy stanów
Diagramy wdrożenia
Diagramy czynności
Diagramy komponentów
Diagramy interakcji
Diagramy przebiegu
Diagramy kooperacji
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
47
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
48
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:
–
–
–
–
50
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.
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:
–
–
–
52
modelowanie słownictwa systemu (struktura systemu),
modelowanie prostych kooperacji,
modelowanie schematu logicznej bazy danych.
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:
57
– modelowanie przepływu sterowania z uwzględnieniem
kolejności
– komunikatów w czasie,
– modelowanie przepływu sterowania z uwzględnieniem
organizacji strukturalnej obiektów
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)
60
• 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.
Przykłady
• Stanisław Wrycza (red.), UML 2.1,
Ćwiczenia, Helion 2006.
61
61
DPU (ang. Use Case)
62
63
64
65
66
CASE (ang. Computer-Aided Software Engineering)
NARZĘDZIA DO MODELOWANIA
BAZ DANYCH
67
Wybrane narzędzia do modelowania
•
•
•
•
•
68
Oracle MySQL Workbench
Oracle SQL Developer Data Modeler
SAP Sybase PowerDesigner DataArchitect
IBM Rational Data Architect
Microsoft Visio
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/developertools/datamodeler/overview/index.html
• http://www.oracle.com/technetwork/developertools/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
Pytania?
DZIĘKUJĘ ZA UWAGĘ