Organizacja danych i bazy danych

1

O

O

R

R

G

G

A

A

N

N

I

I

Z

Z

A

A

C

C

J

J

A

A

D

D

A

A

N

N

Y

Y

C

C

H

H

I

I

B

B

A

A

Z

Z

Y

Y

D

D

A

A

N

N

Y

Y

C

C

H

H

1

PODSTAWOWE POJĘCIA Z BAZ DANYCH ................................................................ 2

1.1

Baza danych ................................................................................................................. 2

1.2

System zarządzania bazą danych ................................................................................. 2

2

ARCHITEKTURA SYSTEMU BAZ DANYCH .............................................................. 4

2.1

Model zewnętrzny........................................................................................................ 5

2.2

Model pojęciowy ......................................................................................................... 5

2.3

Model wewnętrzny....................................................................................................... 5

3

PODSTAWOWE MODELE (pojęciowe) BAZ DANYCH ............................................... 5

3.1

Model hierarchiczny .................................................................................................... 6

3.2

Model sieciowy ............................................................................................................ 7

3.3

Relacyjny model bazy danych ..................................................................................... 8

3.4

Obiektowy model bazy danych.................................................................................... 9

4

WPROWADZENIE DO ZAGADNIEŃ PROJEKTOWANIA RELACYJNEJ BAZY
DANYCH ......................................................................................................................... 10

4.1

Etapy projektowania bazy danych ............................................................................. 10

4.2

Analiza wycinka rzeczywistości ................................................................................ 10

4.3

Projektowanie konceptualne ...................................................................................... 10

4.4

Logiczny model danych ............................................................................................. 13

4.5

Przykład ..................................................................................................................... 15

5

HURTOWNIE DANYCH ................................................................................................ 16

Organizacja danych i bazy danych

2

1

PODSTAWOWE POJ

Ę

CIA Z BAZ DANYCH

1.1

Baza danych

Baza danych – w rozumieniu ustawy z dnia 27 lipca 2001r. O ochronie baz danych:
Termin baza danych określa zbiór danych lub jakichkolwiek materiałów i elementów
zgromadzonych według określonej systematyki lub metody, indywidualnie dostępnych w
jakikolwiek sposób, w tym środkami elektronicznymi, wymagającymi istotnego, co do jakości
lub ilości, nakładu inwestycyjnego w celu sporządzenia, weryfikacji lub prezentacji jego
zawartości.

Precyzyjniej jest jednak powiedzieć, że:

- Baza Danych (BD) jest abstrakcyjnym informatycznym odzwierciedleniem wybranego

fragmentu rzeczywistości. Wszelkie zmiany w tym fragmencie rzeczywistości
odzwierciedlane są w BD.

- BD jest logicznie spójnym zbiorem powiązanych danych posiadających określone

znaczenie.

- BD to dane i tzw. schemat. Dane opisują cechy (własności) modelowanych obiektów.

Schemat określa jak interpretować dane

−

jest opisem struktury (formatu)

przechowywanych danych oraz wzajemnych powiązań między nimi.

1.2

System zarz

ą

dzania baz

ą

danych

System zarządzania bazą danych (ang. Database Management Systems - DBMS) jest to
zbiór programów umożliwiających tworzenie i eksploatację BD. Głównym zadaniem takiego
systemu jest zapewnienie użytkownikowi możliwości operowania danymi za pomocą pojęć
abstrakcyjnych w możliwie niewielkim stopniu odwołujących się do sposobu
przechowywania danych przez komputer .


Główne właściwości DBMS:

•

Współdzielenie danych

Informacje przechowywane w bazie danych są zazwyczaj przeznaczone do
wykorzystania przez wielu użytkowników, często w tym samym czasie. DBMS ma
więc za zadanie zapewnić efektywne mechanizmy wielodostępu. W tym celu często
stosuje się w budowie DBMS tzw. model klient-serwer: programy używane przez
użytkowników (klienci) są oddzielone od programu bezpośrednio wykonującego
operacje na danych (serwera); zazwyczaj klienci komunikują się z serwerem poprzez
mechanizmy sieciowe, korzystając z określonego protokołu komunikacji -- umożliwia
to uruchamianie klientów na innych komputerach niż serwer, co zwiększa
bezpieczeństwo (dostęp klientów do serwera jest ograniczony do operacji możliwych
w ramach protokołu) i odciąża serwer np. od zadań związanych z końcową obróbką i
prezentacją danych będących wynikiem zapytania.

Organizacja danych i bazy danych

3

•

Integracja danych

Centralne składowanie wszystkich danych dotyczących danego obszaru działalności
umożliwia uniknięcie zbędnych powtórzeń tych samych informacji -- ułatwiając
utrzymanie spójności, oraz usprawnia uzyskiwanie odpowiedzi na pytania złożone --
wymagające czerpania informacji z różnych logicznie zbiorów danych.

•

Integralność danych

Łatwiej jest również utrzymać poprawność i aktualność informacji składowanej
centralnie; ponadto powierzenie faktycznych operacji na danych jednemu, dobrze
sprawdzonemu programowi serwera zmniejsza ryzyko naruszenia integralności
danych w stosunku do sytuacji, gdy operacje te wykonywane są za pomocą wielu,
tworzonych niezależnie i często ad hoc narzędzi.

•

Bezpieczeństwo danych

Scentralizowanie dostępu do danych umożliwia zastosowanie w DBMS własnego
mechanizmu kontroli i autoryzacji dostępu, bardziej szczegółowego aniżeli umożliwia
to sam system operacyjny w stosunku do dostępu do plików. Dzięki wykorzystaniu
modelu klient-serwer nie jest konieczne, aby każdy użytkownik posiadał dostęp do
maszyny serwera bazy danych poprzez inne mechanizmy, aniżeli protokół
komunikacyjny danego DBMS.

•

Abstrakcja i niezależność danych

Ponieważ końcowy użytkownik bazy danych jest oddzielony przez DBMS od
wewnętrznych mechanizmów działania bazy danych, formatu zapisu itp., i ma tylko
do czynienia (poprzez program klienta i ew. protokół komunikacji) jedynie z logiczną
strukturą danych, to ułatwia to rozwijanie aplikacji korzystających z tych danych w
kierunku nowych zastosowań czy np. wprowadzenie zmian w wewnętrznej organizacji
bazy danych bez konieczności zmian w klientach.

Zadania realizowane przez DBMS można sklasyfikować w sposób następujący:

1. Zarządzanie zbiorami danych

o

tworzenie nowych zbiorów (jednostek logicznej struktury DBMS, tj. baz
danych, tabel, ...)

o

usuwanie zbiorów

o

modyfikowanie struktury zbiorów

o

wstawianie, aktualizowanie i usuwanie danych

2. Wyszukiwanie informacji

w odpowiedzi na zapytania otrzymane od programów klienckich, jądro bazy danych
zwraca dane będące wynikiem odpowiedniego przeszukania bazy danych, a programy
klienckie zajmują się ich prezentacją użytkownikowi po ewentualnej dalszej obróbce;

3. Zarządzanie bazą danych jako całością

o

tworzenie kont użytkowników

o

definiowanie uprawnień dostępu

o

monitorowanie działania bazy danych

Organizacja danych i bazy danych

4

Koncepcja działania systemu zarządzania bazą danych jest następująca:
(a) użytkownik zgłasza żądanie dostępu, używając do tego celu pewnego subjęzyka danych;
(b) system zarządzania bazą danych przyjmuje żądanie i je interpretuje;
(c) system zarządzania bazą danych bada kolejno schemat zewnętrzny, odwzorowanie

zewnętrzny/pojęciowy, schemat pojęciowy, odwzorowanie pojęciowy/wewnętrzny i
schemat wewnętrzny;

(d) system zarządzania bazą danych wykonuje niezbędne operacje na pamiętanej bazie
danych.

System bazy danych (SBD) składa się z BD i SZBD.

2

ARCHITEKTURA SYSTEMU BAZ DANYCH

W architekturze systemu bazy danych wydzielono trzy ogólne poziomy: wewnętrzny,
pojęciowy (koncepcyjny) i zewnętrzny. Ogólnie mówiąc, poziom wewnętrzny jest poziomem
najbliższym pamięci fizycznej i dlatego odnosi się do sposobu, w jaki dane są rzeczywiście
pamiętane. Poziom zewnętrzny jest poziomem najbliższym programiście zastosowań i dlatego
odnosi się przede wszystkim do sposobu, w jaki dane są widziane przez poszczególnych
użytkowników. Poziom pojęciowy (konceptualny) jest “poziomem pośrednim” między
dwoma poprzednimi. O ile poziom zewnętrzny odnosi się do obrazu danych widzianego przez
poszczególnych użytkowników, o tyle poziom pojęciowy można rozważać jako poziom
definiowania wspólnego dla wszystkich użytkowników obrazu danych.

Organizacja danych i bazy danych

5

2.1

Model zewn

ę

trzny

Użytkownik widzi bazę danych za pośrednictwem jej modelu zewnętrznego. Model
zewnętrzny jest zawartością bazy danych widzianej przez pewnego konkretnego użytkownika
(czyli dla tego użytkownika model zewnętrzny jest bazą danych). Każdy model zewnętrzny
jest określony za pomocą schematu zewnętrznego, który zawiera przede wszystkim opisy
każdego z różnych typów rekordu zewnętrznego w tym modelu zewnętrznym. Na przykład
typ rekordu zewnętrznego “pracownik” można określić jako 6-cyfrowe pole numeru
pracownika plus 20-znakowe pole nazwiska i tak dalej.

2.2

Model poj

ę

ciowy

Model pojęciowy reprezentuje informacje zawarte w bazie danych - jest reprezentacją całej
zawartości informacyjnej bazy danych, znów w postaci nieco abstrakcyjnej w porównaniu ze
sposobem, w jaki dane są fizycznie pamiętane. Może się on całkowicie różnić od sposobu
widzenia tych danych przez konkretnego użytkownika. Ogólnie mówiąc, model pojęciowy
jest planowany tak, by był obrazem danych “jakie one rzeczywiście są”, a nie takim, jaki
muszą widzieć użytkownicy przez ograniczenia np. używanych języków i sprzętu. Model
pojęciowy jest obrazem całej zawartości bazy danych, a schemat pojęciowy jest definicją tego
obrazu. Struktury schematu pojęciowego są strukturami, operacjami i ograniczeniami
wykorzystywanego modelu danych (relacyjnego, obiektowego, itp.)

2.3

Model wewn

ę

trzny

M.w. opisuje strukturę magazynowania danych. Jest to rzeczywista struktura bazy danych,
zawierająca indeksy, uporządkowania pól, zestawy znaków, itp. Składa się on z wielu
wystąpień różnych typów rekordu wewnętrznego. “Rekord wewnętrzny” jest to zbiór danych
pamiętanych w bazie danych. Model wewnętrzny opisuje się za pomocą schematu
wewnętrznego, który nie tylko określa różne typy rekordu wewnętrznego, lecz także
specyfikuje istniejące indeksy, sposób reprezentacji pól pamiętanych w bazie,
uporządkowanie fizyczne rekordów wewnętrznych itp.

3

PODSTAWOWE MODELE (poj

ę

ciowe) BAZ DANYCH

Dane i relacje stanowią strukturę danych. Struktury danych plus operacje decydują o
modelu bazy danych.

Model danych można rozumieć jako zbiór ogólnych zasad posługiwania się danymi. Zbiór ten
obejmuje trzy główne części:

- Definicja danych: zbiór reguł określających strukturę danych, tj. to co wcześniej

określałem jako logiczną strukturę bazy danych (w odróżnieniu od niższego poziomu
organizacji zapisu stosowanego wewnętrznie przez jądro bazy danych);

- Operowanie danymi: zbiór reguł dotyczących procesu dostępu do danych i ich

modyfikacji;

- Integralność danych: zbiór reguł określających, które stany bazy danych są poprawne (a

więc zarazem jakie operacje prowadzące do modyfikacji danych są dozwolone).

Organizacja danych i bazy danych

6

Rozróżnia się trzy główne typy (lub generacje) modeli danych:

- Proste modele danych. Dane zorganizowane są w strukturę rekordów zgrupowanych w

plikach. Głównymi dostępnymi operacjami są operacje na rekordach (ewentualnie na ich
poszczególnych polach).

- Klasyczne modele danych. Należą do nich modele hierarchiczne, sieciowe i relacyjne.

Modele relacyjne stanowią najbardziej popularną obecnie podstawę architektur systemów
baz danych.

- Semantyczne modele danych. Semantyka to inaczej znaczenie. Klasyczne modele danych

nie dostarczają łatwego sposobu odczytania informacji o semantyce danych, stąd
podejmuje się próby stworzenia innych modeli, uzupełniających ten brak. Przykładem
częściowej realizacji tego programu są obiektowe modele danych.

3.1

Model hierarchiczny

Dane są przedstawione w postaci drzewa. Wyróżnia się jeden typ rekordu jako rekord główny
(nadrzędny, owner), z którym mogą być związane rekordy podrzędne (members):
- typ rekordu zadeklarowany jako rekord główny stanowi korzeń drzewa,
- rekordy podrzędne nie mogą istnieć bez nadrzędnych (mogą być producenci, którzy nic nie

produkują, ale nie może być części bez producenta),

- reprezentacją tego modelu jest uporządkowane drzewo, jego węzły to obiekty (rekordy),

łuki drzewa to powiązania (typu ojciec – syn) pomiędzy obiektami,

- występuje tylko jeden rodzaj związku 1:N, każdy rekord podrzędny może mieć tylko jeden

rekord nadrzędny (w czystym modelu hierarchicznym związki N:M nie są możliwe,
istnieją rozszerzenia tego modelu, które umożliwiają tego typu powiązania),

- odwołania w tym modelu przy pomocy języka nawigacyjnego: istnieje wskaźnik

aktualnego rekordu w drzewie. Kolejne operacje dostępu tworzą drogę wg. porządku
zstępującego:

a) odwiedź rekord nieodwiedzony
b) w przypadku, gdy nie ma takiego odwiedź syna położonego najbardziej na lewo
c) gdy nie ma takiego wróć do ojca i kontynuuj od a)

Zalety modelu hierarchicznego:

1. Szybki dostęp do danych, ponieważ tabele są ze sobą bezpośrednio powiązane,

2. Automatyczna integralność odwołań (rekord w tabeli-synu musi mieć powiązanie z

rekordem w tabeli-ojcu, usuwanie ojca powoduje usunięcie synów). Ale nie zawsze
jest to zaletą.

POŚREDNICY

MUZYCY

STYLE MUZYCZNE

KLIENCI

UMOWY

ROZLICZENIA

?

Organizacja danych i bazy danych

7

Wady modelu hierarchicznego:

1. Aplikacje i użytkownicy muszą posiadać dużą wiedzę na temat organizacji bazy

danych,

2. Integralność odwołania zabrania wprowadzenia rekordów-synów bez rekordu ojca,

co nie zawsze znajduje odzwierciedlenie w modelowanej rzeczywistości. Obejście
tego ograniczenia wymaga wprowadzania sztucznych danych,

3. Trudności w modelowaniu relacji wiele-do-wielu (np. klienci-muzycy). Konieczne

staje się wprowadzanie nadmiarowych danych (niekonsekwencje, zaburzenia
integralności na skutek powielania danych) lub tworzenie wielu baz hierarchicznych i
relacji logicznych między nimi.

3.2

Model sieciowy

Model sieciowy jest rozszerzeniem modelu hierarchicznego - nie nakłada żadnych

ograniczeń tworzenia powiązań pomiędzy rekordami. Jeden rekord może mieć wiele
rekordów nadrzędnych, czyli kilka drzew może dzielić ze sobą gałęzie, a każde drzewo
stanowi część ogólnej struktury bazy danych.

Relacje w SMBD są definiowane przez kolekcje (ang. set structures). Kolekcja jest

niejawną konstrukcją łączącą dwie tabele przez przypisanie jednej z nich roli właściciela,
drugiej - roli członka. Kolekcje pozwalają wprowadzić relacje jeden-do-wielu. W obrębie
danej struktury, każdy rekord z tabeli-właściciela może być powiązany z dowolną ilością
rekordów tabeli-członka, a pojedynczemu rekordowi z tabeli-członka może odpowiadać tylko
jeden rekord w tabeli-właściciela. Ponadto każdy rekord z tabeli-członka musi mieć
przyporządkowany rekord z tabeli-właściciela. Między każdymi tabelami można zdefiniować
dowolną liczbę powiązań, a każda tabela może uczestniczyć w wielu kolekcjach.

Zalety modelu sieciowego:

1. Szybki dostęp do danych, ponieważ tabele są ze sobą bezpośrednio powiązane,

2. Automatyczna integralność odwołań. Podobnie, jak modelu hierarchicznym, nie

zawsze jest to zaletą,

3. Możliwość zadawania złożonych zapytań i modelowania bardziej złożonych

struktur.

Wady modelu sieciowego:

1. Aplikacje i użytkownicy nadal muszą posiadać dużą wiedzę na temat organizacji

bazy danych.

2. Niemożność zmiany struktury bazy danych bez zmian w obsługujących ją programach
(zmiana kolekcji = zmiana zapytań w aplikacji).

POŚREDNICY

MUZYCY

STYLE MUZYCZNE

KLIENCI

UMOWY

ROZLICZENIA

kieruje

reprezentuje

gra

zawiera

uiszcza

wypełnia

Organizacja danych i bazy danych

8

3.3

Relacyjny model bazy danych

Podstawowym pojęciem jest n-członowa relacja definiująca połączenie pomiędzy elementami
kilku niekoniecznie rozłącznych zbiorów. Jest podzbiorem iloczynu kartezjańskiego tych
zbiorów. Różni się jednak od matematycznego modelu relacji tym, że jest zmienna w czasie.

W RMBD dane przechowuje się w postaci relacji, czyli tabel.

TABELA ( = RELACJA)
Jest podstawow

ą

struktur

ą

relacyjnej bazy danych. Obejmuje ona

okre

ś

lony temat, którym mo

ż

e by

ć

obiekt lub zdarzenie.

Je

ś

li tabela opisuje obiekt, wówczas reprezentuje co

ś

fizycznie

istniej

ą

cego, jak: osob

ę

, miejsce, przedmiot. Przykłady: studenci,

prowadz

ą

cy, zaj

ę

cia, sale.

Je

ś

li tematem tabeli jest wydarzenie, wówczas tabela reprezentuje

co

ś

, co ma miejsce w okre

ś

lonym czasie. Przykłady: ucz

ę

szcza.

Każda tabela składa się atrybutów, czyli pól (lub kolumn) i z krotek, czyli rekordów (lub
wierszy). Fizyczna kolejność wierszy i kolumn w tabeli jest bez znaczenia.

POLE ( = ATRYBUT, kolumna)
Jest najmniejsz

ą

struktur

ą

w relacyjnym modelu logicznym. Pole

reprezentuje pewn

ą

cech

ę

tematu tabeli, której jest elementem.

Wykorzystywane jest do przechowywania jednostkowych danych.
Przykładowo imi

ę

jest jedn

ą

z cech charakteryzuj

ą

cych studenta. Imi

ę

stanowi wi

ę

c pole tabeli studenci. Lub inaczej: jest atrybutem

relacji studenci.

REKORD ( = KROTKA, wiersz)
Jest struktur

ą

składow

ą

tabeli i reprezentuje pojedyncz

ą

instancj

ę

(wyst

ą

pienie) jej tematu. Rekord składa si

ę

z pełnego zestawu pól

danej tabeli.
Przykładowo Jan Malinowski, o numerze albumu 123456 jest konkretn

ą

instancj

ą

tematu studenci. Jest to jeden rekord tabeli studenci (a

mówi

ą

c j

ę

zykiem relacyjnych baz danych jest to jedna krotka relacji

studenci).

Każdy rekord jest wyróżniany przez jedno pole, lub zestaw kilku pól zawierających unikalną
wartość. Atrybut taki (lub zbiór atrybutów) nazywany jest kluczem głównym. Klucz
jednoznacznie identyfikuje entkę. Kluczy potencjalnych może być wiele, jeden z nich
wybierany jest jako klucz główny. Żaden z atrybutów wchodzących w skład klucza nie może
mieć wartości nieokreślonej.

KLUCZ

PODSTAWOWY

(GŁÓWNY)–

jest

polem,

które

jednoznacznie

identyfikuje dany rekord w tabeli. Przykładowo w tabeli studenci mamy
pole

ID

studenta,

które

przyjmuje

warto

ść

niepowtarzaln

ą

i

jednoznacznie wskazuje na danego studenta.
KLUCZ OBCY – jest wykorzystywany do utworzenia relacji pomi

ę

dzy

ró

ż

nymi tabelami. Ma t

ą

sam

ą

nazw

ę

, co klucz podstawowy tabeli, z

której został skopiowany oraz przybiera wył

ą

cznie istniej

ą

ce warto

ś

ci

klucz podstawowego. Przykładowo w tabeli ucz

ę

szcza mamy pole ID

studenta, zapo

ż

yczone z tabeli studenci.

Organizacja danych i bazy danych

9

Zalety modelu relacyjnego:

1.Wielopoziomowa integralność danych - na poziomie kolumn (pól), tabel i relacji między
tabelami.

2.Logiczna i fizyczna niezależność aplikacji bazodanowych - zarówno zmiany wprowadzane
przez użytkownika do projektu logicznego (oczywiście w rozsądnym zakresie), jak i
modyfikacje sposobów fizycznej implementacji mają znikomy wpływ na aplikacji
obsługującej bazę.

3. Zagwarantowana dokładność i poprawność danych - dzięki wielopoziomowej integralności.

4. Łatwy dostęp do danych - dane można w prosty sposób odczytywać z pojedynczych tabel
lub z całych grup tabel powiązanych ze sobą.

Wady modelu relacyjnego:

1.Do niedawna mała wydajność ze względu na duże zapotrzebowanie na moc obliczeniową.
Obecnie coraz mniej istotna przeszkoda.

2.RMBD niezbyt dobrze radzi sobie z modelowaniem zjawisk i danych o charakterze
obiektowym (w sensie OOP).

3.4

Obiektowy model bazy danych

Najnowocześniejszy model bazy danych. Dane nie są przechowywane w postaci

rekordów, ale w formie obiektów, co wiąże się z udostępnieniem metod ich obsługi i
interpretacji. Bazy obiektowe pozwalają na rozszerzenie zbioru możliwych do zapamiętania
typów danych. Oprócz klasycznych danych prostych (char, int ...) można zapamiętywać np.
obrazy, dźwięki etc. Możliwe jest definiowanie procedur przeszukujących taką bazę, co daje
np. możliwość wyszukiwania w dużej bazie danych obrazów podobnych do bieżąco
szkicowanego przez użytkownika w czasie rzeczywistym

Dla modelu obiektowego nie definiuje się na razie formalnego języka dostępu, dlatego

właśnie najczęściej spotyka się bazy oparte o model relacyjno - obiektowy.
Zalety modelu
1. dość naturalna reprezentacja świata
2. łatwość działania na złożonych obiektach
3. duża podatność na zmiany

POŚREDNICY

MUZYCY

STYLE

MUZYCZNE

KLIENCI

UMOWY

ROZLICZENIA

STYLE

/MUZYCY

Organizacja danych i bazy danych

10

4

WPROWADZENIE DO ZAGADNIE

Ń

PROJEKTOWANIA

RELACYJNEJ BAZY DANYCH

4.1

Etapy projektowania bazy danych

Projektowanie baz danych przebiegać może następująco:
1. Analiza wycinka rzeczywistości

-

Podzbiór języka naturalnego (wypowiedzi o faktach w świecie rzeczywistym);

2. Projektowanie konceptualne (pojęciowe)

-

Abstrakcyjny model świata rzeczywistego modelowany przy pomocy diagramów
ERD (obiekt-związek)

3. Opracowanie logicznego modelu danych

-

Transformacja modelu konceptualnego do modelu logicznego (np. relacyjnego), gdzie
określana jest struktura przechowywanych danych (np. schematy

4.2

Analiza wycinka rzeczywisto

ś

ci

Na tym etapie należy wyodrębnić:

-

obiekty, których dane mają być przechowywane w bazie danych;

-

atrybuty obiektów i ich dziedziny, czyli zbiory wartości;

-

powiązania między obiektami;

-

reguły funkcjonowania, np.:

o

REG/001

Nowe towary wprowadza kierownik;

o

REG/002

Możliwe jest udzielenie rabatu na towar w wysokości 3% lub

8%;

-

ograniczenia dziedzinowe, np.:

o

OGR/001

Kod pocztowy w adresie ma postać 99-999, gdzie 9 oznacza

dowolną cyfrę;

o

OGR/002

Data zatrudnienia pracownika musi być wcześniejsza niż

zwolnienia;

-

wymagania funkcyjne, czyli operacje, jakie przyszli użytkownicy będą chcieli
wykonywać, np.:

o

wprowadzanie, modyfikowanie, usuwanie danych;

o

wyszukiwanie danych;

o

sporządzanie statystyk;

o

drukowanie raportów;

-

grupy użytkowników bazy danych;

4.3

Projektowanie konceptualne

Model konceptualny polega na zdefiniowaniu encji oraz związków między nimi. Po
wyodrębnieniu encji i związków opracowuje się model graficzny, zwany diagramem
związków encji (diagram obiekt-związek).

ENCJA – jest to pewien obiekt, rzecz. zjawisko, zdarzenie, pewien byt. Encja może posiadać
atrybuty, czyli cechy, które ją charakteryzują, opisują i są istotne z punktu widzenia tworzonej
bazy danych, np.:

Organizacja danych i bazy danych

11

Atrybuty przyjmują wartości z określonego zbioru – dziedziny.
Atrybuty mogą być:

-

opcjonalne (nieobowiązkowe), czyli ich wartość może być nieokreślona, pusta,
nieznana (NULL);

-

obligatoryjne (wymagane), czyli jego wartość zawsze musi być określona.

ZWIĄZEK
Związek stanowi naturalne powiązanie pomiędzy dwoma lub więcej encjami w danej
dziedzinie konceptualnej (relacja między encjami).
W modelowaniu związku istotne są:
- liczebność związku - stosunek liczebnościowy między wystąpieniami encji uczestniczącymi
w danym związku
- typ uczestnictwa w związku (opcjonalność, obligatoryjność)

Ogólny podział związków:

-

binarne - obejmuje dwie encje,

-

wielorakie - obejmuje więcej niż dwie encje.

Istnieją różne rodzaje notacji:

Model (notacja) Martina





1 – jeden i dokładnie jeden (obligatoryjne)
* - wiele (zero lub wiele – opcjonalne)
1...* - jeden lub wiele (obligatoryjne)
0...1 – zero lub jeden (opcjonalne)
(0,1) – zero lub jeden (opcjonalne)
(1,n) – jeden lub wiele
(0,n) – zero lub wiele
(1,1) – jeden i dokładnie jeden (obligatoryjne)

DOSTAWCA

Id_dostawcy

Nazwa

Adres

<- atrybuty

<- encja

dostarcza

DOSTAWCA

CZ

ĘŚĆ

N, OBL

N, OPC

składo-

wane

MAGAZYN

1, OBL

N, OPC

Dostawca może (ale nie musi) dostarczać wiele części.
Każda z części może być dostarczana przez różnych
dostawców (a przynajmniej przez jednego).

Dana część jest przechowywana w jednym magazynie.
W magazynie może (ale nie musi) być
przechowywanych wiele części.

dostarcza

DOSTAWCA

CZ

ĘŚĆ

(1,n)

(0,n)

składo-

wane

MAGAZYN

1

*

Organizacja danych i bazy danych

12

Model (notacja) Chena





1:N (n=0,1,2,3,...) – relacja jeden do zero lub wiele
M:N (m i n=0,1,2,3,...) – relacja zero lub wiele do zero lub wiele
1:1 – relacja jeden do jeden

Model (notacja) Information Engineering (IE)






więcej niż jeden

zero lub wiele (opcjonalne)

jeden lub wiele (obligatoryjne)

zero lub jeden (opcjonalne)

jeden i tylko jeden (obligatoryjne)


Model (notacja) Bachmana






jeden do jeden

zero lub wiele do jeden lub wiele

jeden do jeden lub wiele

M:N

DOSTAWCA

CZ

ĘŚĆ

składo-

wane

MAGAZYN

1

N

dostarcza

DOSTAWCA

CZ

ĘŚĆ

składo-

wane

MAGAZYN

dostarcza

DOSTAWCA

CZ

ĘŚĆ

składo-

wane

MAGAZYN

Organizacja danych i bazy danych

13

4.4

Logiczny model danych

Schematem (logicznym) relacyjnej bazy danych nazywamy zbiór wszystkich relacji, jakie w
tej bazie danych występują. Projektowanie logiczne bazy danych ma na celu skonstruowanie
bazy, która określi sposób zgrupowania danych i powiązań między nimi. Transformacja
modelu konceptualnego bazy danych do modelu logicznego jest wykonywana według
pewnych reguł, opisanych poniżej.

Reguły transformacji z modelu konceptualnego do relacyjnej bazy danych:

1. Dla każdej encji z diagramu ERD tworzymy relację (tabelę).
2. Atrybuty encji stają się kolumnami tabeli o tej samej nazwie. Dla kolumn obieramy

odpowiednie formaty danych. Kolumny odpowiadające kluczom głównym encji stają
się kluczami głównymi tabel.

3. Dla każdego związku binarnego jeden do jeden lub jeden do wiele obligatoryjnego po

stronie wiele wstawiamy klucz główny ze strony jeden do tabeli reprezentującej stronę
wiele linii związku. W ten sposób otrzymujemy klucz obcy w tabeli ze strony wiele.

4. Związek binarny typu jeden do wiele, opcjonalny po stronie wiele lub związek binarny

wiele do wiele, reprezentujemy zazwyczaj dodatkową tabelą, w której umieszczamy
klucze główne obu encji i stają się one kluczami obcymi.

Przykłady:










1) Dostawca dostarcza tylko jedną część, każda z części jest dostarczana przez jednego
dostawcę.




1 tabela
Id_dostawcy Nazwa

Adres

Id_części

Symbol

Kolor

Ilość

2) Dostawca dostarcza jedną część (ale nie musi), każda z części jest dostarczana przez
jednego dostawcę (nie istnieje w bazie bez powiązania z dostawcą).




2 tabele
Id_dostawcy Nazwa Adres

Id_części

Symbol Kolor Id_dostawcy Ilość

dostarcza

DOSTAWCA

CZĘŚCI

1

1

dostarcza

DOSTAWCA

CZĘŚCI

N, OPC

N, OPC

Id_dostawcy

Nazwa

Adres

<- atrybuty

<- encje

Id_części

Symbol

Kolor

Ilość

dostarcza

DOSTAWCA

CZĘŚCI

0..1

1

Organizacja danych i bazy danych

14

3) Dostawca dostarcza N części (ale nie musi), każda z części jest dostarczana przez jednego
dostawcę (nie istnieje w bazie bez powiązania z dostawcą).




2 tabele
Id_dostawcy Nazwa Adres

Id_części

Symbol Kolor Id_dostawcy Ilość

4) Dostawca dostarcza N części (ale nie musi), każda z części jest dostarczana tylko przez
jednego dostawcę lub przez żadnego.




3 tabele
Id_dostawcy Nazwa Adres

Id_części Symbol Kolor

Id_dostawcy Id_części Ilość

5) Dostawca dostarcza N części (ale nie musi), każda z części może dostarczana przez wielu
dostawców lub przez żadnego.




3 tabele
Id_dostawcy Nazwa Adres

Id_części Symbol Kolor

Id_dostawcy Id_części Ilość

6) Zbiór związku trzyargumentowego – DOSTAWCA może dostarczać wiele CZĘŚCI dla
wielu PROJEKTÓW, dana CZĘŚĆ może być dostarczana przez różnych DOSTAWCÓW do
różnych PROJEKTÓW, jeden PROJEKT może wykorzystywać wiele CZĘŚCI od różnych
DOSTAWCÓW.

4 tabele

Id_dostawcy Nazwa Adres

Id_części Symbol Kolor

Id_projektu Nazwa_p Budżet

Id_dostawcy

Id_części

Id_projektu Ilość

dostarcza

DOSTAWCA

CZĘŚCI

0..1

1..N

dostarcza

DOSTAWCA

CZĘŚCI

0..1

0..N

dostarcza

DOSTAWCA

CZĘŚCI

0..N

0..N

dostarcza

DOSTAWCA

CZĘŚCI

0..N

0..N

PROJEKT

0..N

Organizacja danych i bazy danych

15

4.5

Przykład

Firma o pewnej lokalizacji (jednej lub wielu) zatrudnia wielu pracowników. Każdy pracownik
jest zatrudniony przynajmniej w jednej firmie.

Pracownicy mogą być przydzielani do realizacji różnych, czasami kilku projektów, a
niektórzy z nich pełnią przy projektach (czasami kilku) funkcję kierownika. Przy danym
projekcie zwykle pracuje kilku ludzi, i każdy projekt ma dokładnie jednego kierownika.

Przy każdym projekcie może być przewidziane wykorzystanie pewnych części, które
dostarczają dostawcy zakontraktowani pod ten konkretny projekt. Zlecenie na każdą z części
może być realizowane przez różnych dostawców dla różnych projektów.

Dostawcy mogą (ale nie muszą) dostarczać różne części, natomiast każda z części musi mieć
przynajmniej jednego dostawcę. Dostawca może mieć wiele różnych siedzib (lokalizacji)

Zdarza się, że dana część składa się z kilku elementów, sprowadzanych jako osobne części.

Części przechowywane są w magazynach. W każdym magazynie pracuje przynajmniej jeden
pracownik. Magazyn ma ściśle określoną lokalizację.

W danym miejscu (lokalizacji) może być umiejscowionych kilka firm, magazynów lub
dostawców.

D-P

DOSTAWCA

CZ

ĘŚĆ

MAGAZYN

kieruje

PRACOWNIK

PROJEKT

D-P-C

C-P

D-C

udział

M-C

FIRMA

LOKALIZACJA

P-F

P-P

M-P

L-F

M-L

D-L

*

*

*

*

*

*

*

*

*

*

*

*

1..*

1..*

1..*

1..*

1..*

1..*

1

1

Organizacja danych i bazy danych

16

5

HURTOWNIE DANYCH

Otoczenie, w którym obecnie funkcjonują przedsiębiorstwa to gwałtownie rozwijające

się rynki (lokalne, krajowe, międzynarodowe) o wzrastającym stopniu ryzyka i
konkurencyjności. Presja konkurencyjności skłania przedsiębiorstwa do podniesienia
wiarygodności swoich usług i uzyskania przewagi nad innymi konkurentami. W dużych
współczesnych organizacjach pojawiła się potrzeb analizowania danych dotyczących bieżącej
i przeszłej działalności przedsiębiorstwa. Analiza taka może stanowić podstawę do
podejmowania decyzji dotyczących zarządzania przedsiębiorstwem.

Okazało się jednak, że istniejące w organizacjach systemy informatyczne nie mogą

dostarczyć potrzebnych danych. Dane zgromadzone w istniejących dotychczas bazach danych
są bowiem rozproszone, niejednorodne, a systemy informatyczne często nie są zintegrowane
ani nawet połączone.

W tej sytuacji konieczne stało się znalezienie specjalnych rozwiązań, umożliwiających

efektywną analizę danych zgromadzonych w organizacji. Osiągnięcie tego celu jest możliwie
między innymi w oparciu o wykorzystanie wiarygodnej i szybko dostarczonej informacji na
bazie wydajnego systemu informatycznego takiego jak systemy klasy hurtowni danych.
Hurtownie danych to obszar niezmiernie dynamicznego rozwoju innowacyjnych produktów,
umożliwiających wykorzystanie w procesach decyzyjnych wielu wyrafinowanych rozwiązań
informatycznych - graficznej wizualizacji danych, zaawansowanych statystyk, czy elementów
systemów eksperckich. Do tego służą m.in. aplikacje OLAP (OnLine Analythical Processing).

Organizacja danych i bazy danych

17

Bill Inmon, w opublikowanej w 1991 r. książce na temat hurtowni danych (W. H.

Inmon: Building the Data Ware-house, Wiley, 1991 r.), zdefiniował hurtownię oraz podał
najważniejsze zasady i zalecenia jej tworzenia: "Hurtownia danych to tematyczna,
zintegrowana, zmienna w czasie składnica nieulotnych danych, przeznaczona do wspierania
procesów podejmowania decyzji".

"Orientacja

tematyczna"

oznaczała

przekroje

danych

z

różnych

ź

ródeł,

wykorzystywane do zaspokajania różnych potrzeb użytkowników. "Integracja" dotyczyła
danych (nie organizacji) i polegała na odwzorowaniu różnych sposobów kodowania danych
do wspólnej bazy, opracowaniu spójnej prezentacji elementów i dostarczaniu
zestandaryzowanych danych. Zasadnicze znaczenie ma "zmienność w czasie". Oznacza
zapamiętywanie różnych kopii danych w agregacjach o różnych przedziałach czasowych. Na
przykład dane szczegółowe z wielu lat mogą być zapisane w agregacjach tygodniowych,
miesięcznych, kwartalnych, rocznych. Zmienność w czasie ma zasadnicze znaczenie w
utrzymywaniu spójności danych i zapewnieniu odpowiedniej wydajności. "Nieulotność
danych" to podstawowa cecha tradycyjnej hurtowni, chociaż rzadko zachowywana. Zakłada,
ż

e jeśli do hurtowni wpisze się rekord danych - nigdy się on nie zmienia. Jest też niezbędna

do zapewnienia pełnej historii danych i rejestrowania zmian. Przepisanie jakiegoś rekordu
niszczy informację i nie da się jej już odtworzyć. Podstawowe założenie przyjęte przez B.
Inmona polegało na tym, że hurtownia służy jedynie do przechowywania danych do
wspierania procesów podejmowania decyzji - bez aplikacji raportowania operacyjnego.

Hurtownie danych mają możliwość zgromadzenia setek gigabajtów informacji,

rozproszonych w wielu oddziałowych systemach organizacji. Mogą efektywnie konwertować
surowe dane operacyjne przedsiębiorstwa do postaci użytecznej wiedzy, która może być
wykorzystywana do podejmowania strategicznych decyzji, prowadzących do poprawy jakości
produkcji, zwiększenia wydajności, obniżenia kosztów lub wyznaczania obszarów
generujących straty. Przy pomocy nowoczesnych aplikacji dla hurtowni danych, osoby
zarządzające przedsiębiorstwem mogą śledzić wydajność organizacji w dowolnym obszarze -
jakości, dochodowości przy podziale na regiony, produktywności - na podstawie aktualnych
informacji i podejmować natychmiastowe, uzasadnione działania.