2_bazy_danych

Organizacja danych i bazy danych

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

1.1

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

1.2

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

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

2.1

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

2.2

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

2.3

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

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

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

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

Organizacja danych i bazy danych

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

•

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

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

usuwanie zbiorów

modyfikowanie struktury zbiorów

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ą

tworzenie kont użytkowników

definiowanie uprawnień dostępu

monitorowanie działania bazy danych

Organizacja danych i bazy danych

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.

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

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.

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

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

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

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.

li tabela opisuje obiekt, wówczas reprezentuje co

fizycznie

istniej

cego, jak: osob

, miejsce, przedmiot. Przykłady: studenci,

prowadz

cy, zaj

cia, sale.

li tematem tabeli jest wydarzenie, wówczas tabela reprezentuje

, 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

studenta,

które

przyjmuje

warto

ść

niepowtarzaln

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

klucz podstawowego. Przykładowo w tabeli ucz

szcza mamy pole ID

studenta, zapo

yczone z tabeli studenci.

Organizacja danych i bazy danych

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

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

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

REG/001

Nowe towary wprowadza kierownik;

REG/002

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

8%;

ograniczenia dziedzinowe, np.:

OGR/001

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

dowolną cyfrę;

OGR/002

Data zatrudnienia pracownika musi być wcześniejsza niż

zwolnienia;

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

wprowadzanie, modyfikowanie, usuwanie danych;

wyszukiwanie danych;

sporządzanie statystyk;

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

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

ĘŚĆ

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

ĘŚĆ

(1,n)

(0,n)

składo-

wane

MAGAZYN

Organizacja danych i bazy danych

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

ĘŚĆ

składo-

wane

MAGAZYN

dostarcza

DOSTAWCA

ĘŚĆ

składo-

wane

MAGAZYN

dostarcza

DOSTAWCA

ĘŚĆ

składo-

wane

MAGAZYN

Organizacja danych i bazy danych

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

dostarcza

DOSTAWCA

CZĘŚCI

N, OPC

Id_dostawcy

Nazwa

Adres

<- atrybuty

<- encje

Id_części

Symbol

Kolor

Ilość

dostarcza

DOSTAWCA

CZĘŚCI

0..1

Organizacja danych i bazy danych

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

dostarcza

DOSTAWCA

CZĘŚCI

0..N

PROJEKT

0..N

Organizacja danych i bazy danych

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

ĘŚĆ

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

Organizacja danych i bazy danych

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

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

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.