ORGANIZACJA
ORGANIZACJA
DANYCH
DANYCH
I BAZY DANYCH
I BAZY DANYCH
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 ZAGADNIEC
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
1
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
2
" 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
A
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
3
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
4
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
5
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 wskaz
nik
aktualnego rekordu w drzewie. Kolejne operacje dostępu tworzą drogę wg. porządku
zstępującego:
a) odwiedz
rekord nieodwiedzony
b) w przypadku, gdy nie ma takiego odwiedz
syna położonego najbardziej na lewo
c) gdy nie ma takiego wróć do ojca i kontynuuj od a)
POŚREDNICY
MUZYCY KLIENCI
?
STYLE MUZYCZNE UMOWY ROZLICZENIA
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ą.
Organizacja danych i bazy danych
6
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.
POŚREDNICY
kieruje reprezentuje
MUZYCY KLIENCI
wypełnia zawiera uiszcza
gra
STYLE MUZYCZNE UMOWY ROZLICZENIA
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).
Organizacja danych i bazy danych
7
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 (GA
Ó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
8
POŚREDNICY
MUZYCY KLIENCI
STYLE STYLE UMOWY ROZLICZENIA
MUZYCZNE /MUZYCY
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. A
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, dz
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
Organizacja danych i bazy danych
9
4 WPROWADZENIE DO ZAGADNIEC
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
10
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.
Id_dostawcy Nazwa Adres
<- atrybuty
DOSTAWCA <- encja
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ść)
N, OPC
N, OBL składo- 1, OBL
dostarcza N, OPC
DOSTAWCA CZ
ŚĆ MAGAZYN
wane
Dostawca może (ale nie musi) dostarczać wiele części. Dana część jest przechowywana w jednym magazynie.
Każda z części może być dostarczana przez różnych W magazynie może (ale nie musi) być
dostawców (a przynajmniej przez jednego). przechowywanych wiele części.
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
(0,n) * 1
(1,n) składo-
dostarcza
DOSTAWCA CZ
ŚĆ MAGAZYN
wane
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)
Organizacja danych i bazy danych
11
Model (notacja) Chena
N 1
składo-
M:N
DOSTAWCA CZ
ŚĆ MAGAZYN
wane
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)
składo-
dostarcza
DOSTAWCA CZ
ŚĆ MAGAZYN
wane
więcej niż jeden
zero lub wiele (opcjonalne)
jeden lub wiele (obligatoryjne)
zero lub jeden (opcjonalne)
jeden i tylko jeden (obligatoryjne)
Model (notacja) Bachmana
składo-
dostarcza
DOSTAWCA CZ
ŚĆ MAGAZYN
wane
jeden do jeden
zero lub wiele do jeden lub wiele
jeden do jeden lub wiele
Organizacja danych i bazy danych
12
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:
Id_części Kolor
Id_dostawcy Adres Ilość
<- atrybuty
Symbol
Nazwa
dostarcza CZ
ŚCI <- encje
DOSTAWCA N, OPC
N, OPC
1) Dostawca dostarcza tylko jedną część, każda z części jest dostarczana przez jednego
dostawcę.
dostarcza
DOSTAWCA CZ
ŚCI
1 1
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ą).
dostarcza
DOSTAWCA CZ
ŚCI
0..1 1
2 tabele
Id_dostawcy Nazwa Adres Id_części Symbol Kolor Id_dostawcy Ilość
Organizacja danych i bazy danych
13
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ą).
dostarcza
DOSTAWCA CZ
ŚCI
0..1 1..N
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.
dostarcza
DOSTAWCA CZ
ŚCI
0..1 0..N
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.
dostarcza
DOSTAWCA CZ
ŚCI
0..N 0..N
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.
dostarcza
DOSTAWCA CZ
ŚCI
0..N 0..N
0..N
PROJEKT
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ść
Organizacja danych i bazy danych
14
4.5 Przykład
* *
DOSTAWCA PROJEKT
D-P
*
1..* *
D-P-C
D-C C-P
udział kieruje
* *
*
MAGAZYN 1..* M-C CZ
ŚĆ
PRACOWNIK
1
* * *
1..* *
D-L P-P
P-F
M-L
M-P
1..* 1 1..*
1..* *
LOKALIZACJA FIRMA
L-F
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.
Organizacja danych i bazy danych
15
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
16
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 z
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.
Organizacja danych i bazy danych
17