Podstawowe pojęcia z teorii budowy baz danych.
Komputerowa baza danych to system dla strukturalnego przechowywania różnych spisów, np.: studentów
Nr indeksu |
Nazwisko |
Imie |
53 |
Małysz |
Adam |
55 |
Michałek |
Gosia |
: |
: |
: |
Tabela jest podstawową jednostką strukturalną współczesnych baz danych. Współczesne bazy danych składają się z kilku tabel ( od 3 do 25 ) np.: baza danych uczelni składa się z tabel: studenci, wykładowcy, zajęcia, itd.
Każda tabela ma informacje o konkretnych obiektach. Pojedyncza tabela posiada informacje o obiektach określonej dziedziny np.: tabela studenci posiada informacje o pojedynczych studentach.
Ilość tabel w bazie danych jest uzależniona od projektanta, gdyż musi on mieć na uwadze przeznaczenie bazy danych.
Baza danych spełnia swoje funkcje w oparciu o oprogramowanie, zwane systemem zarządzania bazą danych ( Data Base Managment System ). W ten sposób komputerowa baza danych składa się z dwóch części:
danych lub informacji
systemu zarządzania bazą danych
Dane są wartościami statycznymi w bazie danych, tzn. zachowują swój stan aż do zmodyfikowania ich ręcznie lub przez jakiś automatyczny proces.
System zarządzania bazą danych pełni następujące funkcje:
tworzy bazy danych ( tworzenie pliku lub plików bazy danych )
tworzy tabele
wprowadza i modyfikuje ( zmienia wartości ) dane
pobiera informacje ( wybiera dane ) np.: użytkownik ma uzyskać informacje o studentach pierwszego roku SI
usuwa dane
usuwa całe tabele i bazy danych
Dla wypełnienia tego systemu stworzony został język zapytań. Najczęściej wykorzystywany jest tutaj język SQL ( Structured Query Language - język zapytań strukturalnych ). Ten język wypełnia funkcje w oparciu o standardowe operacje:
Create - stwórz
Update - zmodyfikuj
Select - wybierz dane
Delete - usuń informację
Informacje w bazie danych powinny mieć taki wygląd, aby czas pobierania danych był minimalny. Dlatego podstawowymi operacjami wykonywanymi przez bazy danych są: sortowanie i wyszukiwanie danych.
Sortowanie to kolejność rozmieszczenia obiektu w tabeli. Aby to rozmieszczenie uzyskać trzeba obowiązkowo podać kryterium sortowania np.: od minimalnego do maksymalnego numeru indeksu.
Podstawowe metody sortowania danych:
metoda kolejnych minimów ( maksimów )
metoda bąbelkowa
metoda kubełkowa
metoda QuickSort
Głównym parametrem charakteryzującym każdą z tych metod jest ilość porównań elementów ze sobą i ilość przestawień liczb.
Metoda kolejnych minimów polega na porównaniu ze sobą wszystkich elementów tablicy. Pierwsza pętla tych porównań skończy się tym, że pod numerem 1 będzie umieszczony minimalny element. Druga pętla tych porównań skończy się tym, że pod numerem 2 będzie umieszczony minimalny element wśród pozostałych, itd.
Załóżmy zbiór A = {30, 2, 345, 8, 53, 120 }
I pętla - wykonamy n - 1 porównań i zamienimy 1 element { 2, 30, 345, 8, 53, 120 }
II pętla - wykonamy n - 2 porównań i zamienimy 1 element { 2, 8, 30, 345, 53, 120 }
Suma wszystkich porównań wynosi n - 1 + n - 2 + ... + 1 =
Metoda bąbelkowa polega na porównaniu par sąsiednich elementów ze sobą i przestawieniu elementów według podanego kryterium.
Załóżmy zbiór A = {30, 2, 345, 8, 53,120 }
I pętla 30 porównujemy z 2 i przestawiamy {2, 30, 345, 8, 53, 120 }
II pętla 30 porównujemy z 345 i pozostawiamy {2, 30, 345, 8, 53, 120 }
Metoda bąbelkowa charakteryzuje się taką samą ilością porównań ( n - 1 ) jak metoda kolejnych minimów, lecz ma ona większą ilość przestawień elementów. Tak więc im większa liczba elementów, tym większa różnica w wielkości przestawień.
Metoda kubełkowa polega na utworzeniu wirtualnych kieszeniu do umieszczania w nich odpowiednich danych. Dla każdego rzędu liczby ( jednostek, dziesiątek, itd. ) powinno być utworzonych 10 kubełków. Zastosowanie tej metody jest efektywne, jeżeli liczby po sortowaniu mają mocno różniące się ilości cyfr.
Załóżmy zbiór A = {30, 2, 345, 8, 53,120 }
I 0 1 2 3 4 5 6 7 8 9
II 0 1 2 3 4 5 6 7 8 9
III 0 1 2 3 4 5 6 7 8 9
Metody wyszukiwania danych i typy baz danych.
Istnieją dwie metody wyszukiwania danych:
metoda blokowa
metoda dzielenia binarnego ( bisekcji )
W metodzie blokowej dane powinny być najpierw posortowane w celu zmniejszenia
czasu poszukiwania. Metoda ta polega na uprzednim rozdzieleniu tablicy obiektów na ustaloną ilość bloków. Ilość elementów w każdym bloku ( oprócz ostatniego ) zawsze musi być taka sama, a w bloku ostatnim musi być mniejsza od bloków poprzednich.
W pierwszym kroku szukany obiekt ( np.: numer indeksu ) będzie porównany z numerem indeksu ostatniego obiektu w pierwszym bloku. W zależności od wyniku poszukiwania szukany element może być:
w pierwszym bloku, gdy poszukiwany indeks jest mniejszy od ostatniego
w następnych blokach, gdy poszukiwany indeks jest większy od ostatniego
ostatnim elementem bloku, gdy szukany indeks jest równy ostatniemu w bloku
Jeżeli szukany element jest wśród elementów pierwszego bloku, to może być znaleziony przez metodę kolejnych porównań. W drugim przypadku indeks szukanego elementu porównujemy analogicznie z indeksem ostatniego elementu bloku drugiego, trzeciego, itd.
W metodzie tej szybkość wyszukiwania zależy od ilości porównań, a nie ilości przestawień, a maksymalna ilość porównań wynosi
,a minimalna 1.
Optymalna ilość porównań zależy od miejsca rozmieszczenia szukanego elementu, ilości bloków i ilości elementów.
Metoda dzielenia binarnego polega na początkowym dzieleniu tablicy elementów na połowę i porównaniu indeksu szukanego elementu z indeksem ostatniego elementu w pierwszej połowie tablicy. W takiej sytuacji mogą wystąpić następujące wyniki, od których uzależniony jest dalszy tok poszukiwań:
szukany indeks jest równy ostatniemu elementowi pierwszej połowy tablicy, to przerywamy poszukiwania
szukany indeks jest mniejszy od ostatniego elementu pierwszej połowy tablicy, to tablicę dzielimy znowu na połowę i postępujemy analogicznie
szukany indeks jest większy od ostatniego elementu pierwszej połowy tablicy, to drugą połowę tablicy dzielimy na połowę i postępujemy analogicznie
Maksymalna ilość porównań w tej metodzie jest większa, bądź równa log2 n.
Wybór tej lub innej metody wyszukiwania zależy od ilości obiektów w bazie danych i jest też uzależniony od zaleceń projektanta.
Wszystkie bazy danych możemy podzielić na dwie klasy:
operacyjne bazy danych np.: uczelni, szpitali
analityczne bazy danych np.: informacje o pogodzie, długoterminowych kursach walut, itp.
Informacje w pierwszej klasie baz danych w odróżnieniu od klasy drugiej podlegają zmianom. Natomiast operacyjne bazy danych przeznaczone są przede wszystkim do wypracowania prognozy zmian, rozwoju elementu.
Elementy strukturalne i logiczne baz danych.
Tabela jest podstawową jednostką strukturalną bazy danych. Każda tabela ma swoją nazwę, pisaną najczęściej dużymi literami, ze względu na możliwość jej importowania do innych systemów baz danych. Nazwa tabeli powinna odpowiadać przechowywanym w niej obiektom. Każda tabela składa się z pół ( kolumn ) i rekordów ( wierszy ).
Pole to taka jednostka strukturalna tabeli, która przeznaczona jest do przechowywania jednakowej informacji o wszystkich obiektach rozmieszczonych w tabeli.. Każde pole posiada informacje tego samego typu, np.: dane liczbowe, data, itd. Każde pole ma swoją nazwę, odpowiadającą przechowywanej informacji. W nazwach pól i tabel nie należy stosować znaków spacji, itp.
Rekord jest jednostką strukturalną tabeli przechowującą informację o pojedynczym obiekcie.
Baza danych zawierająca kilka tabel będzie jednostką w logicznym i integralnym sensie, tylko wtedy, kiedy wszystkie tabele będą powiązane ze sobą, czyli wtedy, gdy będą zdefiniowane relacje między tabelami. Żadna z tabel nie może nie mieć relacji, w związku z tym maksymalna ilość relacji odpowiada ilości tabel w bazie danych. Istnieją trzy podstawowe typy relacji między tabelami:
1:1 ( jeden do jednego )
1:w ( jeden do wielu )
w:w ( wiele do wielu )
Relacja jeden do jednego odpowiada sytuacji, gdy pojedynczemu rekordowi jednej
Tabeli odpowiada pojedynczy rekord drugiej tabeli i na odwrót.
Relacja jeden do wielu odpowiada sytuacji, kiedy pojedynczy rekord pierwszej tabeli powiązany jest z jednym lub kilkoma rekordami drugiej tabeli, natomiast jeden rekord drugiej tabeli powiązany jest tylko z jednym rekordem pierwszej tabeli.
Ze strony pierwszej tabeli w odniesieniu do tabeli drugiej występuje relacja jeden do wielu, a ze strony tabeli drugiej relacja wiele do jednego.
Relacja wiele do wielu odpowiada sytuacji, gdy pojedynczy rekord pierwszej tabeli odpowiada jednemu lub kilku rekordom drugiej tabeli, natomiast pojedynczemu rekordowi drugiej tabeli odpowiada jeden lub kilka rekordów pierwszej tabeli.
W relacyjnych bazach danych zdefiniowanie relacji wiele do wielu jest możliwe tylko z pomocą dodatkowej tabeli ( mieszającej ).
Modele baz danych.
Istnieją cztery podstawowe modele baz danych:
hierarchiczny
sieciowy
relacyjny
obiektowy:
obiektowo orientowany
obiektowo relacyjny
Model bazy danych wskazuje nam na logiczną i fizyczną zasadę opisu obiektów bazy danych, relacji pomiędzy nimi i sposobu wyszukiwania danych.
W modelu hierarchicznym dane ułożone są w strukturę o wyglądzie odwróconego drzewa. Jedna z tabel pełni tu rolę korzenia, a pozostałe maja postać gałęzi mających swój początek w korzeniu lub w innej gałęzi. Relacje pomiędzy tabelami noszą tu nazwę ojciec-syn i są odpowiednikami relacji jeden do wielu.
Korzeń
Gałęzie poziom 1
Gałęzie
poziom 2
W przytoczonej bazie danych manager może mieć jednego lub kilku klientów i jednego lub kilku muzyków. Klient zawiera umowę z muzykiem poprzez managera.
Ten typ relacji ojciec-syn oznacza, że pojedyncza tabela ze strony ojca może by powiązana z jedną lub kilkoma tabelami ze strony syna, a pojedyncza tabela ze strony syna może mieć tylko pojedynczego ojca.
Główną wadą tego modelu jest to, że każdy użytkownik powinien dokładnie znać strukturę powiązań, gdyż w celu odnalezienia informacji musi chodzić po gałęziach. W modelu tym wbudowano automatyczną kontrolę integralności danych, tzn. że pomiędzy obiektami powiązanych tabel zawsze obowiązkowo istnieje relacja. Zaletą jest tutaj wysoka szybkość wyszukiwania danych. Teoretyczną bazą tego modelu teoria grafów. Niektóre bazy danych odpowiadające temu modelowi można transformować w relacyjny model, tzn. umożliwia to zastosowanie ODBC ( Open Data Base Connetivity ).
Model sieciowych baz danych został stworzony w celu rozwiązania problemów związanych z modelem hierarchicznym. Strukturę tego modelu można także przedstawić jako odwrócone drzewo, jednak różnica między tymi modelami polega na tym, że w modelu sieciowym kilka drzew może dzielić ze sobą gałęzie. Relacje występujące w tym modelu są zdefiniowane przez kolekcję. Jest to niejawna konstrukcja łącząca ze sobą przez przypisanie jednej roli właściciela, a dwóch członków. Między dwoma tabelami można zdefiniować dowolną ilość kolekcji, czyli powiązań. Kolekcje umożliwiają relację jeden do wielu.
Korzeń
Gałęzie poziom 1
Gałęzie
poziom 2
Zaletą tego modelu jest duża szybkość odczytu informacji oraz możliwość utworzenia o wiele większej liczby zapytań do bazy danych przez użytkownika. Model ten ma podobną wadę do modelu hierarchicznego, gdyż użytkownik także powinien znać strukturę powiązań.
Obydwa modele charakteryzują się dużą nadmiarowością danych, czyli powtarzaniem tych samych danych w różnych tabelach.
Model relacyjnych baz danych różni się od poprzednich doskonałą bazą teoretyczną opartą na dwóch gałęziach matematyki: teorii mnogości i rachunku prawdopodobieństwa.
Dane w relacyjnych bazach danych istnieją tylko w wyglądzie tabelarycznym. Bazy danych relacyjne różnią się od wcześniej omówionych między innymi:
kolejność pól i rekordów w bazach relacyjnych może być dowolna, tzn. użytkownik nie musi znać fizycznej struktury bazy danych
w modelu relacyjnym między tabelami mogą wystąpić wszystkie trzy typy relacji
W relacyjnych bazach danych może wystąpić wartość zerowa ( NULL ), co oznacza, że dane pole pozostawiamy puste. Pożądane jest aby żadna z tabel nie zawierała wartości NULL.
W bazach danych wyróżniamy następujące typy pól:
pole segmentowe-zawiera więcej niż jeden typ tej samej wartości(nazwisko i imię)
pole wyliczalne - wartością tego pola jest wynik operacji przeprowadzanymi nad kilkoma innymi polami ( koszt = ilość * cena )
pole wielowartościowe - pole które zawiera dane różnego typu np.:adres:Garbary2
Modyfikując już istniejące bazy danych należy mieć na uwadze typy pól.
Poprzez pojęcie integralności danych rozumiemy ich spójność i dokładność. Rozróżniamy typy integralności danych:
integralność na poziomie tablicy - gwarantuje, że pole identyfikuje każdy rekord danej tabeli, ze ma ono unikalną wartość i nigdy nie jest wartością zerową
integralność na poziomie pól - gwarantuje, że struktura każdego pola jest poprawna, a zawarte wartości są logiczne oraz wszystkie dane w tym polu są tego samego typu
integralność na poziomie relacji ( integralność referencyjna ) - gwarantuje, że wszystkie relacje są poprawnie zdefiniowane i że dane w powiązanych tabelach są ze sobą zsynchronizowane.
Klucz tabeli - identyfikator obiektów bazy danych. Każda tabela posiada swój klucz. Klucz jest to kilka lub jedno pole identyfikujące jednoznacznie rekordy tabeli. Za pomocą kluczy definiujemy relacje pomiędzy tabelami. Definiowanie relacji odbywa się poprzez przeniesienie klucza z jednej do drugiej tabeli. Rozróżniamy relacje obowiązkowe i opcjonalne. Jeśli pole jest kluczem podstawowym, to mówimy że jest to pole unikatowe.
Poprzez pojęcie atrybutu pola rozumiemy zbiór cech określających każdą jego wartość. Wyróżniamy trzy podstawowe grupy atrybutów:
atrybuty ogólne
atrybuty fizyczne
atrybuty logiczne
Do atrybutów ogólnych zaliczamy między innymi nazwę pola, która jest unikatowym
identyfikatorem danego pola. Tabela, z której pochodzi dane pole jest nazywana tabelą matką. Jedno pole może występować w innych tabelach, pod warunkiem, że łączy tabele w podzbiory lub jest przeznaczone do definiowania relacji.
Indeks jest elementem zarządzania bazą danych, czyli elementem strukturalnym. Indeks i klucz są różnymi pojęciami, gdyż indeks nie jest związany z logiczną strukturą bazy danych. Indeks jest elementem fizycznym, przeznaczonym do usprawnienia wykonywania operacji na tabelach. Natomiast klucz jest elementem logicznym przeznaczonym do identyfikacji rekordów w tabeli.
Architektura systemu baz danych.
Architektura systemu baz danych jest najczęściej opisana za pomocą architektury ANSI/SPARC. W architekturze tej istnieją trzy poziomy architektury:
wewnętrzny
zewnętrzny
koncepcyjny
poziom zewnętrzny
poziom koncepcyjny
poziom wewnętrzny
Na poziomie wewnętrznym następuje przedstawienie poziomu przechowywania danych.
Na poziomie koncepcyjnym następuje ogólne przedstawienie się użytkowników, a na poziomie zewnętrznym następuje przedstawienie pojedynczego użytkownika z punktu widzenia tego w jakim wyglądzie otrzymuje on informacje z bazy danych.
W ten sposób zewnętrzny poziom odpowiada za indywidualną reprezentację pojedynczego użytkownika, czyli może istnieć dowolna ilość takich reprezentacji. Można to przedstawić na przykładzie bazy danych personelu napisanej w dwóch językach programowania: PL / 1 i COBOL.
Poziom zewnętrzny |
Użytkownik 1 ( PL / 1 )
|
Użytkownik 2 ( COBOL )
01 EMPC 02 EMPNO PICX (6) 03 DEMPNO PICX (4) |
Poziom koncepcyjny |
EMPLOYEE EMPLOYEE_N CHAR (6) DEPART_N CHAR (4) SALARY NUMERIC (5)
|
|
Poziom wewnętrzny |
STORED_EMP BYTES (20), PREFIX TYPE = BYTE (6), EMP_N TYPE = BYTE (8), INDEX = EMPX, DEPT_N TYPE = BYTE(4), PAY TYPE =FULLWORD
|
Na poziomie koncepcyjnym baza posiada informacje o typie obiektów i ma nazwę EMPLOYEE. Każdy obiekt tabeli EMPLOYEE posiada pola:
numer pracownika ( EMPLOYEE_N) typu CHAR i długości 6 symboli
numer działu (DEPART_N) typu CHAR i długości 4 symboli
pensji (SALARY) typu NUMERIC o długości 5 cyfr dziesiątkowych
Na poziomie wewnętrznym pracownicy są reprezentowani przez typ rekordu STORED_EMP o długości 20 bajtów. Każdy z rekordów posiada 4 pola:
6 bajtowy prefiks, który może posiadać informację zarządzającą wyglądem flag
3 pola danych, które reprezentują pracownika ( EMP_N, EMPX, DEPT_N )
Na poziomie zewnętrznym analizujemy dwóch użytkowników. Użytkownik 1 w celu otrzymania informacji z bazy danych stosuje język PL/1, a drugi użytkownik stosuje język COBOL. W pierwszym przypadku każdy pracownik będzie reprezentowany przez dwa pola: numer pracownika i pensję. W drugim przypadku użytkownik otrzymuje informacje o numerze pracownika i wydziale, w którym on pracuje.
Nazwy pół na każdym poziomie architektury mogą być różne, np.: N_EMP i EMPLOYEE_N. Systemowi zarządzania bazy danych wymienione różnice powinny być znane, tak jak i odpowiadające sobie pola na każdym poziomie, zwane odwzorowaniami.
Trzy poziomy architektury w modelu relacyjnych baz danych.
Na zewnętrznym poziomie architektury każdy z użytkowników otrzymuje informacje z bazy danych w innym wyglądzie. Użytkownikiem bazy może być także administrator bazy danych lub programista. Zwykły użytkownik komunikuje się z bazą za pomocą specjalnego języka zapytań ( np.: SQL ) lub za pomocą języka bazowanego na poleceniach i menu (C++ Builder)
Te języki kontaktów z bazą muszą posiadać podjęzyk danych ( podzbiór operatorów, które odnoszą się tylko do obiektów baz danych i wykonywania operacji nad tymi obiektami ). Standardowym językiem zapytań jest język SQL. Podjęzyk danych jest kombinacją dwóch podrzędnych języków:
języka definiowanego danych DLL ( Data Definition Language )
języka manipulowania danych DML ( Data Manipulation Language )
Według terminologii ANSI / SPARC przedstawienie pojedynczego użytkownika bazie danych nazywa się zewnętrznym przedstawieniem. Każde zewnętrzne przedstawienie definiujemy za pośrednictwem zewnętrznego schematu, co polega na definiowaniu każdego pola w tym przedstawieniu.
Na poziomie koncepcyjnym przedstawiamy wszystkie informacje z bazy danych w formie abstrakcyjnej.
Poziom wewnętrzny to nisko poziomowe przedstawienie całej bazy. Wewnętrzne przedstawienie nie jest całkiem adekwatne fizycznemu poziomowi, gdyż na tym poziomie nie analizujemy fizycznych rekordów, które nazywamy stronami lub blokami.
Schemat architektury ANSI / SPARC.
I - podstawowy język + podjęzyk danych pojedynczego użytkownika.
Zewnętrzne przedstawienie, czyli interfejs użytkowników grup A i B.
II - poziom koncepcyjny bazy danych
III - dane na poziomie wewnętrznym bazy danych
Przejścia między poziomami są odwzorowaniami danego poziomu dla użytkowników grup.
Każdym elementem i odwzorowaniem zarządza system zarządzani bazą danych. Jak widzimy odwzorowanie to pełne przekształcenie, czyli bufor.
Administrator bazy danych.
Administrator bazy danych jest fizyczną osobą, która odpowiada za realizację techniki polityki ochrony danych i organizacji dostępu do nich, według wypracowanych praw dostępu. Często dodatkowo istnieje także administrator danych, który odpowiada za to, jakie dane są przechowywane w bazie. Najczęściej administratorem danych jest kierownik zakładu, a administratorem bazy jest programista.
Funkcje administratora bazy danych:
definiowanie schematu koncepcyjnego bazy danych
definiowanie wewnętrznych połączeń pomiędzy obiektami bazy danych. Proces definiowania połączeń nazywa się fizycznym projektowaniem bazy danych.
definiowanie współdziałania bazy danych z pojedynczym użytkownikiem. Mogą to być jakieś formy, podjęzyki lub jakieś graficzne interfejsy.
definiowanie zabezpieczeń w celu ochrony informacji
definiowanie procedur tworzenia kopii zapasowych baz danych ( każda baza danych powinna posiadać kopię zapasową )
Architektura klient - serwer.
Zwykła architektura bazy danych może być podzielona na dwie części:
serwer, czyli wewnętrzny komponent lub maszyna bazy danych
klienci, czyli zewnętrzny komponent lub zewnętrzny interfejs
Taka struktura może mieć schemat:
Rozproszone opracowanie danych.
Rozproszone opracowanie danych oznacza, że różne serwery połączone są ze sobą w celu równoległego wykonywania zadań. Jednym z wariantów rozproszonego opracowania danych jest ten, kiedy serwer i klient znajdują się na innych komputerach. Główną cechą rozproszonego opracowania danych jest zmniejszenie czasu opracowania problemu.
Architektura klient - serwer daje możliwość skoncentrowania całej bazy na jednym komputerze o większych możliwościach od komputerów użytkowników. Do jednego serwera może mieć dostęp jednocześnie kilku klientów, co jest bardzo istotną rzeczą.
Dla systemów klient - serwer istnieją systemy zarządzania takie jak:
Oracle
Informix
InterBase
DB2
MS SQL
Pozwalają one eksportować i importować bazy danych w innych formatach.
Podstawy algebry relacyjnej.
Dla opisania operacji nad danymi w bazach komputerowych stosuje się 8 operatorów:
suma relacyjna
iloczyn ( z teorii mnogości )
różnica
iloczyn kartezjański ( Decart )
wybór ( selekcja, określenie )
projekcja
splot lub konkatenacja
dzielenie
Operacja sumy relacyjnej może być wykonana nad dwoma tabelami. Wynikiem operacji jest tablica, która posiada wszystkie rekordy, które należą do pierwszej lub drugiej tablicy lub jednocześnie do obu tablic.
W operacji iloczynu wynikiem jest tabela, która posiada tylko te kolumny, które zawiera zarówno pierwsza, jak i druga tabela.
Wynikiem operacji różnicy jest tabela posiadająca tylko rekordy, które należą do jednej z tabel.
Wynikiem iloczynu kartezjańskiego jest tabela, która posiada wszystkie możliwe kombinacje rekordów obu podanych tabel, np..:
A |
|
B |
|
C |
|
A1 B1 C1 D1 |
n1 |
A2 B2 |
n2 |
A1 A1 B1 B1 C1 C1 D1 D1 |
A2 B2 A2 B2 A2 B2 A2 B2 |
Ilość rekordów w tabeli wynikowej jest iloczynem n1 x n2. Ilość pół w każdym z rekordów tabeli wynikowej jest równa sumie pól w obu podanych tabelach. Operacja ta musi być wykonywana przynajmniej nad dwoma tabelami.
Operacja wyboru jest wykonywana zwykle nad jedną tabelą. Wynikiem jej jest nowa tabela, która posiada część rekordów z podanej tabeli, odpowiadających podanym kryteriom. Ilość rekordów w wynikowej tabeli nie może przekroczyć ilości rekordów podanej tabeli.
Wynikiem operacji projekcji jest tabela, która posiada wszystkie lub część rekordów z podanej tabeli, ale ma mniejszą ilość pól.
Operacja splotu jest wykonywana nad dwoma tabelami. Wynikiem jest tabela posiadająca wszystkie możliwe rekordy, będące kombinacją pól dwóch rekordów będących obiektami dwóch tabel pod warunkiem, że w dwóch kombinowanych rekordach są obecnie jednakowe wartości w jednym lub kilku ogólnych rekordach z podanych tabel. Ponadto te ogólne znaczenia w rekordzie wynikowym mogą się pojawić tylko raz.
A1 A2 A3 |
B1 B2
|
|
B1 B2 B3 |
C1 C2 C3 |
|
A1 A2 A3 |
B1 B2 B3 |
C1 C2 C3 |
pole ogólne
Operacja dzielenia jest wykonywana nad dwoma unarnymi tabelami ( posiadającymi jedno pole ) i jedną tabelą binarną ( posiadającą dwa pola ). Wynikiem będzie tabela, która posiada wszystkie rekordy z pierwszej unarnej tabeli, które posiada binarna tabela i odpowiadają one rekordom z drugiej unarnej tabeli.
Ex. 1
Wykonaj operacje nad tabelami:
Tabela A - Spis producentów z Bydgoszczy
|
|||
ID_p |
Imię_p |
Status_p |
Adres_p |
S1 S2 |
Aaab Bcd |
20 20 |
Bydgoszcz Bydgoszcz |
|
|
|
|
Tabela B - producenci narzędzia „p”
|
|||
ID_p |
Imię_p |
Status_p |
Adres_p |
S1 S4 |
Aaab Mcd |
20 10 |
Bydgoszcz Toruń |
A union B ( A suma B )
Wynikiem będą nie powtarzające się rekordy obu tabel, czyli wynikiem będą rekordy S1, S2 ( z pierwszej tabeli ), S4 ( z drugiej tabeli ).
A intersset B ( A iloczyn mnogościowy B )
Wynikiem będzie rekord będący częścią obu tabel, czyli rekord S1.
A minus B
Wynikiem będą te rekordy, które są obiektami tabeli A, ale nie są obiektami tabeli B, czyli wynikiem będzie rekord S2 z tabeli A.
B minus A = S4
Ex. 2.
Wykonaj operację iloczynu kartezjańskiego, selekcji i projekcji nad tabelami:
Tabela A |
Tabela B |
|||
ID_p |
Imię_p |
|
Nazwisko_p |
Adres_p |
S1 S2 |
Aaab Bcd |
|
Mnk Opr |
Bydgoszcz Bydgoszcz |
A times B ( iloczyn kartezjański )
Tabele A i B nie posiadają żadnych ogólnych pól. W ten sposób wynikiem tej operacji będzie tabela posiadająca wszystkie kombinacje rekordów obu tabel
ID_p |
Imię_p |
Nazwisko_p |
Adres_p |
S1 S1 S2 S2 |
Aaab Aaab Bcd Bcd |
Mnk Opr Mnk Opr |
Bydgoszcz Bydgoszcz Bydgoszcz Bydgoszcz |
Selekcja
Operacji selekcji zawsze dokonujemy za pomocą polecenia select w języku SQL pod warunkiem where np.: select* from A where zam_p='Bydgoszcz”; Wynikiem takiej operacji będzie cała tabela A, gdyż * oznacza wybór właściwości wszystkich pól.
Projekcja
Select ID_p, Imię_p from A; Wynikiem takiej operacji będzie tabela:
ID_p |
Imię_p |
S1 S2 |
Aaab Bcd |
We frazie where w operacji selekcji może być podane kilka kryteriów wyboru. Mogą one być łączone ze sobą poprzez operatory logiczne ( OR, AND, NOT ) np.:
select*from B where Adres_p='Bydgoszcz' OR Status_p<20;
Splot
Niech tabela A i B posiadają pola A-> { X1. X2, ... XM; Y1, Y2, ... , YN }
B-> { Y1, Y2, ..., YN; Z1, Z2, ..., ZP }, czyli pola Y są ogólne dla obu tabel. Operację tego łączenia zapisujemy w SQL za pomocą operatora join, np..: A join B.
Podsumowując operacje selekcji i projekcji polegają na zastosowaniu zdania select z języka SQL. Wynikiem jest tabela, która posiada całą lub częściową zawartość podanej tabeli. Zdanie select może posiadać operację join, czyli za pomocą całego zdania select można pobierać dane z połączonych tabel.
Bazy danych w środowiskach Delphi i C++ Builder.
Wspólnym dla tych środowisk jest system poleceń i graficzny interfejs, czyli wspólnym jest odwzorowanie między zewnętrznym a koncepcyjnym poziomem bazy danych.
Przeanalizujmy bazy danych tworzone w środowisku Delphi. Istnieją trzy wersje Delphi:
Delphi Desktop ( Builder Desktop )
Delphi Developer
Delphi Client - Server
Bezpośrednie środowisko Delphi umożliwia połączenie z bazami danych MS Access i innymi.
Delphi Desktop za pomocą specjalnego narzędzia Borand DataBase Engine umożliwia kontaktowanie ( połączenie ) za pomocą zestawu bibliotek DLL w wersji Delphi Desktop.
W Delphi Developer istnieje możliwość połączenia z bazami danych innych formatów za pomocą narzędzia ODBC ( Open DataBase Connectivity ). ODBC to specjalizowany sterownik, który posiada specjalny zestaw oprogramowania zwany API ( Application Programing Interface ).
Delphi Client - Server polega na zastosowaniu języka SQL i oprogramowania SQL - Links.
Ważniejsze terminy i komponenty interfejsu w C++ Builder i Delphi:
tabela, rekord, kolumna, pole
kontrolki dostępu do danych - komponenty wizualne zgrupowane na zakładce DataAccess. Należą do nich komponenty:
TTable
TDataSource
TDataBase
TdataSet - zapewnia dostęp do tabel i zbiorów danych będących wynikami zapytań SQL
TQuery
TStoredProc
Komponent TTable umożliwia skojarzenie tego komponentu z tabelą, co odbywa się za pośrednictwem TTableName, który znajduje się w Object Inspectorze.
Komponent TQuery umożliwia konstruowanie, wykonywanie i opracowanie zapytań SQL.
Komponent DataSource łączy zbiory danych i kontrolki powiązane z tymi danymi.
Komponent TStoredProc umożliwia uruchomienie skomplikowanych procedur SQL - owych.
Kontrolki powiązane z danymi są to komponenty graficzne, które za pomocą narzędzi graficznych umożliwiają przeglądanie i modyfikację bazy danych. Są one zgrupowane na zakładce DataControls. Nowa klasa obiektów Tfield zapewnia możliwości dostępu środowisku do pól.
Formularz tworzony przez kreatora DataBase Form Wizard powinien być zaopatrzony we własne komponenty TTable i TDataSource, a także w zestaw kontrolek powiązanych z danymi.
Jeżeli myszą klikniemy na komponent TTable oraz naciśniemy F11, to przejdziemy do okna Object Inspectora, które zawiera dwie części.
Atrybut DataSet komponentu TDataSource zawiera odwołanie do komponentu TTable. Oznacza to, że komponent TDataSource przekazuje dane z kontrolek i do kontrolek powiązanych z danymi i odczytuje te dane z tabeli wskazanej w komponencie TTable.
Atrybut AutoEdit ma automatycznie nadaną wartość logiczną TRUE, tzn. że jakakolwiek modyfikacja danych w skojarzonej kontrolce spowoduje przełączenie komponentu TDataSource w tryb edycji.
Komponent TDataBaseEdit ma dwa atrybuty:
DataSource - wskazuje on na komponent TDataSource otworzony na formularzu
TdataField - wskazuje z którym polem tabeli związana jest dana kontrolka
Komponenty TDataSource, TTable, TDataBaseEdit są ściśle powiązane ze sobą. Komponent TTable jest podstawowym łącznikiem między formularzem a tabelami. Komponent TDataSource pełni funkcję pośrednika pomiędzy komponentem TTable i powiązanymi z nim kontrolkami. Natomiast komponent TDataBaseEdit dostarcza i pobiera dane z komponentu TDataSource.
Definiowanie relacji pomiędzy tabelami.
Relacja 1:1 tworzona jest pomiędzy dwoma tabelami. Wymaga ona utworzenia kopii klucza podstawowego z tabeli nadrzędnej w tabeli podrzędnej, w której to ten klucz będzie kluczem obcym.
Relacja 1:wielu wymaga również utworzenia kopii klucza podstawowego z tabeli ze strony 1 w tabeli ze strony wielu. Tabelą nadrzędną jest tu tabela za strony 1.
Projektowanie baz danych.
Projektowanie baz danych składa się z 3 etapów:
analiza wymagań bazy
modelowanie danych
normalizacja i testowanie utworzonej bazy
Na etapie analizy wymagań osoba projektująca bazę powinna zastanowić się nad:
dla kogo będzie przeznaczona baza danych
w jakim celu tworzymy bazę danych
kategoriami użytkowników i poziomem ich wiedzy
możliwościami finansowymi firmy zlecającej
stopniem bezpieczeństwa informacji zamieszczonych w bazie
Na podstawie powyższej analizy tworzymy cel projektu, a następnie modelujemy dane. Proces ten składa się z kilku etapów:
definiowanie tabeli - ile i jakie tabele są nam potrzebne w bazie
przypisanie pól tabelom - definiowanie: typów pół tabeli, kluczy podstawowych dla każdej z tabel, relacji między tabelami
Normalizacja to proces zmiany właściwości tabel w celu wyeliminowania nadmiarowości danych i spełnienia potrzeb integralności danych na różnych poziomach. Normalizacja często polega na podzieleniu tabeli na mniejsze tabele.
Testowanie ma na celu sprawdzenie w jakim stopniu zaprojektowana baza odpowiada kryteriom poprawności działania, integralności danych, bezpieczeństwa danych oraz w jakim stopniu interfejs bazy jest przyjazny użytkownikowi. Wynikiem testowania będzie wniosek w jakim stopniu zaprojektowana baza odpowiada celom projektu. Jeżeli baza odpowiada celom to proces projektowania będzie zakończony, natomiast w przeciwnym wypadku należy powrócić do któregoś z etapów i poprawić błędy. Dowolny proces projektowania jest procesem iteracyjnym ( pętlowym ). Testowanie powinno być przeprowadzone razem z użytkownikiem, bądź przez osoby niezależne.
Schemat łączenia tabel na każdym z etapów może być wykonany w różny sposób. Na przykład na początku procesu projektowania może to być szkic o wyglądzie:
Środkowy stan struktury może być przedstawiony przy pomocy ER-diagramów.
lub
Często podajemy także typ uczestnictwa:
opcjonalny - obiekt tabeli A niekoniecznie musi być przypisany obiektowi tabeli B Ten typ uczestnictwa oznaczamy
obowiązkowy
Ostateczny wygląd projektu bazy danych ma postać:
Nazwa tabeli |
|
|
|
Nazwa tabeli |
Pole 2 : : |
|
|
|
Pole 1 KP Pole 2 KO : : |
|
|
Nazwa tabeli |
|
|
|
|
Pole 1 KO Pole 2 KP Pole 3 : |
|
|
Normalizacja.
Przedmiotem i celem normalizacji jest opracowanie zagadnienia „w każdym miejscu tylko jeden fakt”, które można scharakteryzować jako maksymalne zmniejszenie nadmiarowości danych, które zawiera każda tabela.
Proces normalizacji bazuje na koncepcji 5 postaci normalnych, z których analizujemy jednak tylko 3 początkowe. Tabela znajdująca się w odpowiedniej postaci normalnej powinna odpowiadać zdefiniowanym kryteriom. Zakładamy, że każda zaprojektowana tabela z zdefiniowanymi elementami zarządzania danymi odpowiada pierwszej postaci normalnej. Dlatego aby tabela odpowiadała drugiej postaci normalnej powinna ona odpowiadać pierwszej postaci normalnej oraz pewnym dodatkowym kryteriom, itd.
Pierwsze trzy postacie normalne były opisane przez Codda. Podkreślił on, że postać o większym numerze jest lepsza od poprzedniej.
Z normalizacją jest związana zasada odwrotności danych. Oznacza to, że jakiekolwiek przekształcenia tabel nie powinno skutkować w żadnym stopniu utratą informacji.
Rozważmy to na przykładzie tabeli producentów „S”.
Nr_S |
Status_S |
Miasto_S |
S3 S5 |
30 30 |
Paryż Londyn |
W takim przypadku mamy dwa warianty normalizacji. Tabelę S możemy zastąpić tabelami:
SST |
Nr_S |
Status_S |
SC |
Status_S |
Miasto_S |
|
S3 S5 |
30 30 |
|
30 30 |
Paryż Londyn |
lub
SST |
Nr_S |
Status_S |
NC |
Nr_S |
Miasto_S |
|
S3 S5 |
30 30 |
|
S3 S5 |
Paryż Londyn |
W drugim przypadku informacja nie będzie stracona, gdyż tabele SST i NC zawierają dane, że producent S3 ma status 30 i ma siedzibę w Paryżu. Jest to dekompozycja bez strat, gdyż pole Nr_S jest ogólne dla obu tabel. Wynika z tego, że odwrotna konkatenacja tabel jest tu możliwa i otrzymamy w jej wyniku tabelę początkową S, w tym samym wyglądzie, czyli bez strat informacji.
W przypadku pierwszym mamy sytuację odwrotną i niektóre informacje mogą być stracone, gdyż obaj producenci mają status 30 i nie można określić, który ma siedzibę w Paryżu, a który w Londynie.
Postacie normalne.
Pole niekluczowe to pole nie będące częścią klucza podstawowego danej tabeli.
Nawzajem niezależne pola to takie pola, w których żadne z pól funkcjonalnie nie zależy od dowolnej kombinacji innych pól. W praktyce oznacza to, że każde pole może być modyfikowane niezależnie od zawartości innych pól.
Mówimy, że tabela jest w postaci normalnej pierwszej wtedy i tylko wtedy, gdy każde jej pole w każdym z rekordów posiada tylko jeden typ i jedno znaczenie. Tabela jest w postaci normalnej pierwszej jeżeli nie posiada pól segmentowych, wielowartościowych i wyliczalnych.
Załóżmy, że informacja o producentach i towarach jest podana w jednej tabeli o nazwie First składającej się z pól Nr_S, Status_S, Miasto_S, Nr_P, QTY. Klucz podstawowy składa się tu z pól Nr_S i Nr_P. W tej sytuacji pole status funkcjonalnie zależy od miejsca zamieszkania producenta, biorąc pod uwagę, że status zależy od miejsca zamieszkania. W tej tabeli nie wszystkie pola nie kluczowe są nawzajem niezależne, dlatego atrybuty Status_S i Miasto_S zależą od pola Nr_S. Ten stan nazywa się nierozkładalną zależnością od klucza. Aby spełnić potrzebę integralności danych tabela First może mieć wygląd:
Nr_S |
Status_S |
Miasto_S |
Nr_P |
QTY |
S1 S1 S1 S2 S2 |
20 20 20 10 10 |
Londyn Londyn Londyn Paryż Paryż |
P1 P2 P3 P1 P2 |
300 200 100 300 400 |
Widzimy tu dużą nadmiarowość, co utrudnia spełnienie operacji wstawiania, usuwania i modyfikowania danych w tej tabeli. W celu rozwiązania tego problemu należy rozdzielić tabelę First na dwie tabele Second i SP. Tabela Second będzie miała pola Nr_S, Status_S, Miasto_S, a tabela SP pola: Nr_P, Nr_S, QTY. Celem tego rozdzielenia było zlikwidowanie zależności pól, które nie są nierozkładalnymi.
W tabeli Second nie wszystkie pola są nawzajem niezależne, gdyż pole Status_S zależy od pola Nr_S. Oznacza to, że dowolny wpis w pole Nr_S definiuje pole Status_S. W celu rozwiązania tego problemu tabelę Second należy zastąpić dwiema tabelami S.C. zawierającą pola Nr_S i Miasto_S otraz tabelą CS o polach Miasto_S, Status_S.
Mówimy, że tabela jest w postaci normalnej pierwszej wtedy i tylko wtedy, gdy znajduje się ona w postaci normalnej pierwszej i każde jej kluczowe pole nierozkładalne zależy od klucza. Obydwie tabele Second i SP znajdują się w drugiej postaci normalnej. Pierwsza tabela ma klucz Nr_S, a druga ma klucz złożony z dwóch pól Nr_S i Nr_P. Proces transformacji tabeli z postaci normalnej pierwszej w postać normalną drugą polega na zamianie tabeli z postaci normalnej pierwszej odpowiednim zbiorem projekcji w tym sensie, że odwrotna operacja nie prowadzi do strat informacji. W ten sposób pierwszy etap procedury normalizacji posiada tworzenie projekcji umożliwiającej wyłączenie funkcjonalnych zależności nie będących nierozkładalnymi.
Załóżmy, że mamy tabelę R składającą się z pól A, B, C, D o kluczu złożonym z pól A i B. Zakładamy, że istnieje funkcjonalna zależność między polem A i D. Procedura normalizacji polega na zamianie tabeli R na tabelę R1 o polach A i D z kluczem w polu A oraz tabelę R2 o polach A, B, C i kluczu podstawowym w polu B oraz kluczu obcym w polu A.
Mówimy, że tabela jest w postaci normalnej trzeciej wtedy i tylko wtedy, gdy tabela ma tylko jeden potencjalny klucz, który jest kluczem podstawowym oraz nie ma innych kluczy kandydujących. Tabela jest w postaci normalnej trzeciej wtedy i tylko wtedy, gdy jest ona w postaci normalnej drugiej i każde pole niekluczowe bezpośrednio zależy tylko od pola kluczowego. Tabele S.C., CS i Second znajdują się w postaci normalnej trzeciej.
Analiza praktycznych projektów baz danych.
Ex. 1. Przeanalizujmy projekt bazy danych szkoły:
analiza wymagań - baza danych przeznaczona do ułatwienia procesu zarządzania szkołą. Od bazy wymaga się możliwości:
dodawania, usuwania i modyfikowania informacji o:
uczniach i nauczycielach
klasach
dodatkowych zajęciach
przydzielania lub odwoływania obowiązków nauczyciela
projekt bazy danych - na początek wymieńmy obiekty naszej bazy:
Obiekt |
Atrybut |
Uwagi |
Uczeń |
Imei Nazwisko Data urodzenia |
Adresu nie potrzeba, gdyż jest taki sam jak opiekuna |
Pracownik |
Imie Nazwisko Data urodzenia Wykształcenie Ulica Numer domu Numer mieszkania Kod pocztowy Miejscowość Numer telefonu |
Pracownicy, którzy mają zajęcia z uczniami są nauczycielami |
Rodzice |
Imię Nazwisko Numer domu Numer mieszkania Kod pocztowy Miejscowość Numer telefonu |
Opiekun odpowiedzialny za ucznia |
Klasy |
Nazwa Profil Opis |
W szkołach z profilowaniem |
Przedmioty |
Nazwa Opis |
|
Sale |
Opis |
|
Miejsce zajęć |
Czas rozpoczęcia Czas zakończenia |
|
Przykładowe związki między obiektami i ich cechy:
przynależność do klasy - uczniowie należą do klas. W jednej klasie jest wielu uczniów, ale jeden uczeń należy tylko do jednej klasy. Każda klasa powinna składać się z pewnej liczby uczniów. Jest to relacja 1:wielu, w której uczestnictwo jest obowiązkowe z obu stron
dzieci i rodzice - każde dziecko ma rodziców ( 1 lub 2 ) lub opiekunów w sensie prawnym. Jednocześnie rodzice mogą mieć wiele dzieci w danej szkole. Jest to więc także relacja 1: wielu
zajęcia i klasy - jest to powiązanie między klasą, przedmiotem i nauczycielem, czyli analizujemy łącznie trzy typy obiektów. Każde zajęcie charakteryzuje dokładnie jedna klasa, jeden przedmiot i jeden nauczyciel prowadzący. Jest to więc relacja 1:1:1.
Opis bazy danych na podstawie ER-diagramów.
.
:
1
n
n 1 n 1
1 1
.......
n
1 n n
n
n
Widzimy, że tabela miejsce zajęć ma relację wiele do wielu i dlatego powinniśmy ją zastąpić dwoma tabelami z relacjami 1:wielu i wiele:1.
Ostateczny wygląd projektu bazy danych ma postać:
Rodzice |
|
Uczniowie |
|
Pracownicy |
|
Przedmioty |
Imie_rod Nazwisko_rod Telefon_rod Ulica_rod Nrdomu_rod Nrmieszk_rod Kodpoczt_rod Miasto_rod |
|
Id_ucz KP Id_rod KO Id_kl KO Imie_ucz Nazwisko_ucz Dataur_ucz |
|
Imie_pr Nazwisko_pr Dataur_pr Wykszt_pr Ulica_pr Nrdomu_pr Nrmieszk_pr Kopoczt_pr Miasto_pr |
|
Id_p KP Nazwa_p Opis_p |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Sale |
|
|
|
|
|
|
Id_s KP Numer_s Opis_s |
|
|
|
|
|
|
|
|
|
Klasy |
|
|
|
|
|
|
Nazwa_kl Profil_kl Opis_kl |
|
|
|
|
|
|
|
|
|
|
Lokalizacja |
|
|
|
|
|
|
Id_lok KP Id_z KO Id_s KO Czaspocz_lok Czaskon_lok |
|
|
|
|
Zajęcia |
|
|
|
|
|
|
Id_zaj KP Id_pr KO Id_p KO Id_kl KO |
|
|
|
|
|
|
|
|
|
Tworzenie tabel i formularzy autorskich w środowisku Delphi i C++ Builder.
Do tworzenia tabel stosuje się program DataBase Desktop lub tworzy się formularze autorskie, czyli projektuje się formularze przez rozmieszczenie na formie odpowiednich komponentów. Najczęściej używanymi komponentami są TTable, TDataSource i TDBNavigator. Proces tworzenia formy dzielimy na dwa etapy:
przygotowanie graficznej struktury formularza
umieszczenie na formularzu odpowiednich komponentów
Podczas przygotowania graficznego należy załadować formularz pusty, a następnie umieścić na nim dwa komponenty TPanel. Które znajdują się na zakładce Standard. Jeden z tych komponentów jest przeznaczony do rozmieszczenia obiektów zarządzających opracowaniem danych, a drugi służy do rozmieszczenia pól.
Aby umożliwić dostęp użytkownikom do większej liczby komponentów, czyli atrybutów, które nie muszą się mieścić na formularzu na danym panelu umieścimy kontrolkę TSCrollBox znajdującą się na zakładce Edit paska narzędzi.
Podczas umieszczania komponentów na formularzu, oprócz komponentów TTable i TDataSource, rozmieszczamy na formularzu kontrolki powiązane z danymi, które będą pełniły rolę interfejsu użytkownika. Rolę tę pełni TDBNavigator z zakładki DataControls, który powinien być umieszczony na górnym elemencie formularza. Atrybutowi DataSource tego komponentu należy przypisać znaczenie TDataSource1.
Komponent Tfield przeznaczony jest do modyfikowania i edycji struktury pól za pomocą elementu FieldsEditor, który można uruchomić po dwukrotnym kliknięciu komponentu TTable.
Tworzenie systemu zarządzania bazą danych.
Tworzenie aplikacji do obsługi bazy wymaga rozwiązania problemów polegających na:
zastosowaniu komponentu TDataBase w aplikacji
definiowaniu aliasów BDE ( w Delphi )
tworzeniu modułów danych
tworzeniu formularzy dla powiązania tabel typu nadrzędnego z podrzędnymi
umożliwienia generowania raportów
Budowa bazy danych oparta jest przede wszystkim na komponencie TTable, bądź aplikacji do obsługi TQuery.
Komponent TDataBase służy do ułatwienia dostępu do danych. Ten stopień dostępu można zmieniać za pomocą atrybutu TtransIsolation. Aby wykorzystać domyślną sekwencję logowania można dołączyć odpowiedni fragment kodu do procedury obsługi zdarzenia OnLogin komponentu TDataBase. Aby określić specyficzne parametry do obsługi bazy należy wypełnić wpis do atrybutu Params.
Definiowanie aliasów BDE.
Dostęp do baz odbywa się poprzez BDE. Ten termin oznacza, że nazwa bazy danych jest tylko pseudonimem. Alias BDE można przyrównać do źródła danych ODBC. Stanowi on zestaw parametrów sposobu podłączenia do bazy lub systemu zarządzania bazą.
Moduły danych ( data module )- specjalny typ formularzy przeznaczony do przechowywania komponentów do kontroli danych. Umożliwia on rozmieszczenie wszystkich reguł, tabel bazy danych w jednym miejscu, co daje możliwość ich wspólnego zastosowania przez oddzielne instrukcje. W bibliotece VCL moduły danych są zawarte w klasie TDataModule.
Relacje w tabeli można tworzyć przy pomocy kreatora opartego na:
komponentach TTable ( MasterSource, MasterField)
zastosowaniu kreatora DataBase Form Wizard
Kreator DataBase Form Wizard jest oparty na komponentach TQuery. W celu przyłączenia tabeli należy uruchomić kreatora, który znajduje się w menu DataBase i wykonać odpowiednie czynności. Następnie należy wybrać alias, czyli katalog, w którym znajdują się podlegające łączeniu tabele i dawać odpowiedzi na pytania kreatora. Ważne jest tu jakie pole będzie kluczem podstawowym w tabeli nadrzędnej, gdyż powinno ono być łączone z kopią klucza w tabeli podrzędnej.
Indeks jest to element logicznej struktury bazy danych przeznaczony do sortowania i wyszukiwania elementów tabeli. Relacyjne tabele posiadające klucz nie muzą posiadać indeksu.
Pola wyliczalne.
W fizycznych tabelach nie należy stosować pól wyliczalnych. Pola takie tworzymy przez pobieranie danych z jednej lub kilku tabel. Do tworzenia tego typu pola zastosujemy komponent TTable, a mianowicie jego pole FieldsEditor.
Głównym krokiem jest tu napisanie procedury, która powinna znajdować się w obsłudze zdarzeń. Pola wyliczalne często umieszczamy w raportach.
Kontrola wprowadzania danych.
Kontrola wprowadzania danych ma na celu kontrolować typy i długość wprowadzanych danych. Istnieją następujące metody kontroli:
maski wejściowe - służą do wprowadzania danych typu data, czas. Aby nałożyć maskę należy zastosować komponent TField i jego właściwość EditMaske (TField-EditMaske)
określenie na poziomie bazy danych - właściwość EditMaske jest efektywna przy zastosowaniu pojedynczej aplikacji ( tabeli )
Cancel - polega ona na procedurach autorskich
Kontrola właściwości na poziomie pól i tabel - przeznaczona do analizy właściwości będących rozwiązaniem operacji nad innymi polami. Ta metoda polega na zastosowaniu zdarzeń i wyjątków
Wyjątki w metodach kontroli wprowadzania danych stanowią:
dublowanie kluczy
błąd kontroli bazy danych
Programy obsługi ODBC.
Do tworzenia i zarządzania ODBC służy aplikacja ODBC administrator z panelu sterowania Windows. Sterownik ODBC zawiera kod, który rozumie specyfikę konkretnej bazy danych i umożliwia dostęp do niej przez standardowe elementy.
Aby połączyć Buildera z Delphi należy stworzyć sterownik Borland DataBase Engine. ODBC posiada także sterowniki danych. Sterownik bazy danych należy tak skonfigurować, aby można było uruchomić sterownik ODBC. Polega to na następujących ruchach:
uruchomieniu administratora ODBC
kliknięciu zakładki config, Draywers, ODBC i wybraniu polecenia new
ustaleniu nazwy sterowników ODBC
wybraniu sterownika ODBC
1
2
53
345
8
120
30
08
02
53
345
30
120
053,030
002,008
120
345
Manager
Muzycy
Klienci
Terminy
Umowy
Rozliczenia
Manager
Klienci
Muzycy
Rozliczenia
Umowy
Terminy
Użytkownik A1
I
Użytkownik A2
I
Użytkownik B1
I
Użytkownik B2
I
Zewnętrzne przedstawienie użytkowników A
I
Zewnętrzne przedstawienie użytkowników B
I
II
III
System zarządzania bazą danych (SZBD)
Użytkownicy - fizyczne osoby
System zarządzania bazą danych
Aplikacje
Serwer ( dane )
Serwer ( dane )
PC klient 1
PC klient 3
PC klient n
PC klient 2
Delphi
Aplikacja
MS Acces dBase
FoxPro
ODBC
Tabela uczniowie
Nauczyciele
ID
Adres
Klasa
ID
Adres
Adres
ID
Tabela 3
Uczniowie
Nauczyciele
w : w
1 : w
Tabela 3
Tabela 3
Imię
Nazwisko
Nauczyciele
Uczniowie
Telefon
rodzic
Dzieci rodziców
uczeń
Telefon
Nazwisko
Imię
Uczniowie w klasie
klasa
pracownik
Uczniowie w klasie
Nazwa
Profil
Opis
Imię
Nazwisko
Miasto
Prowadzący zajęcia
zajęcia
Zajęcia z przedmiotów
przedmiot
zajęcia dla klasy
Opis
Nazwa
Miejsce zajęć
sale
Rozpoczęcie
Zakończenie
Opis