BAZY DANYCH WYK AD 26 ST, Inne


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:

  1. danych lub informacji

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

  1. tworzy bazy danych ( tworzenie pliku lub plików bazy danych )

  2. tworzy tabele

  3. wprowadza i modyfikuje ( zmienia wartości ) dane

  4. pobiera informacje ( wybiera dane ) np.: użytkownik ma uzyskać informacje o studentach pierwszego roku SI

  5. usuwa dane

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

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:

  1. metoda kolejnych minimów ( maksimów )

  2. metoda bąbelkowa

  3. metoda kubełkowa

  4. 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 = 0x01 graphic

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

0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic

II 0 1 2 3 4 5 6 7 8 9

0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic

III 0 1 2 3 4 5 6 7 8 9

0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic

Metody wyszukiwania danych i typy baz danych.

Istnieją dwie metody wyszukiwania danych:

  1. metoda blokowa

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

  1. w pierwszym bloku, gdy poszukiwany indeks jest mniejszy od ostatniego

  2. w następnych blokach, gdy poszukiwany indeks jest większy od ostatniego

  3. 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 0x01 graphic
,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ń:

  1. szukany indeks jest równy ostatniemu elementowi pierwszej połowy tablicy, to przerywamy poszukiwania

  2. szukany indeks jest mniejszy od ostatniego elementu pierwszej połowy tablicy, to tablicę dzielimy znowu na połowę i postępujemy analogicznie

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

  1. operacyjne bazy danych np.: uczelni, szpitali

  2. 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:1 ( jeden do jednego )

  2. 1:w ( jeden do wielu )

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

0x08 graphic

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.

0x08 graphic

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.

0x08 graphic

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:

  1. hierarchiczny

  2. sieciowy

  3. relacyjny

  4. obiektowy:

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.

0x08 graphic

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.

0x08 graphic

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:

  1. kolejność pól i rekordów w bazach relacyjnych może być dowolna, tzn. użytkownik nie musi znać fizycznej struktury bazy danych

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

  1. pole segmentowe-zawiera więcej niż jeden typ tej samej wartości(nazwisko i imię)

  2. pole wyliczalne - wartością tego pola jest wynik operacji przeprowadzanymi nad kilkoma innymi polami ( koszt = ilość * cena )

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

  1. 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ą

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

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

        1. atrybuty ogólne

        2. atrybuty fizyczne

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

  1. wewnętrzny

  2. zewnętrzny

  3. koncepcyjny

0x08 graphic

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 )

  1. EMPP

  2. N_EMPPPCHR (6)

  3. SAL_FIXEDBIN (31)

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:

  1. numer pracownika ( EMPLOYEE_N) typu CHAR i długości 6 symboli

  2. numer działu (DEPART_N) typu CHAR i długości 4 symboli

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

  1. 6 bajtowy prefiks, który może posiadać informację zarządzającą wyglądem flag

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

    1. języka definiowanego danych DLL ( Data Definition Language )

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

0x08 graphic

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:

  1. definiowanie schematu koncepcyjnego bazy danych

  2. definiowanie wewnętrznych połączeń pomiędzy obiektami bazy danych. Proces definiowania połączeń nazywa się fizycznym projektowaniem bazy danych.

  3. definiowanie współdziałania bazy danych z pojedynczym użytkownikiem. Mogą to być jakieś formy, podjęzyki lub jakieś graficzne interfejsy.

  4. definiowanie zabezpieczeń w celu ochrony informacji

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

  1. serwer, czyli wewnętrzny komponent lub maszyna bazy danych

  2. klienci, czyli zewnętrzny komponent lub zewnętrzny interfejs

Taka struktura może mieć schemat:

0x08 graphic

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

0x08 graphic

Dla systemów klient - serwer istnieją systemy zarządzania takie jak:

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:

  1. suma relacyjna

  2. iloczyn ( z teorii mnogości )

  3. różnica

  4. iloczyn kartezjański ( Decart )

  5. wybór ( selekcja, określenie )

  6. projekcja

  7. splot lub konkatenacja

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

0x08 graphic

n1

A2

B2

0x08 graphic

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.

0x08 graphic

0x08 graphic

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

0x08 graphic
B3

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:

  1. Delphi Desktop ( Builder Desktop )

  2. Delphi Developer

  3. Delphi Client - Server

Bezpośrednie środowisko Delphi umożliwia połączenie z bazami danych MS Access i innymi.

0x08 graphic

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:

  1. tabela, rekord, kolumna, pole

  2. kontrolki dostępu do danych - komponenty wizualne zgrupowane na zakładce DataAccess. Należą do nich komponenty:

    1. TTable

    2. TDataSource

    3. TDataBase

    4. TdataSet - zapewnia dostęp do tabel i zbiorów danych będących wynikami zapytań SQL

    5. TQuery

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

  1. DataSource - wskazuje on na komponent TDataSource otworzony na formularzu

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

  1. analiza wymagań bazy

  2. modelowanie danych

  3. normalizacja i testowanie utworzonej bazy

Na etapie analizy wymagań osoba projektująca bazę powinna zastanowić się nad:

    1. dla kogo będzie przeznaczona baza danych

    2. w jakim celu tworzymy bazę danych

    3. kategoriami użytkowników i poziomem ich wiedzy

    4. możliwościami finansowymi firmy zlecającej

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

  1. definiowanie tabeli - ile i jakie tabele są nam potrzebne w bazie

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

0x08 graphic

Środkowy stan struktury może być przedstawiony przy pomocy ER-diagramów.

0x08 graphic

lub

Często podajemy także typ uczestnictwa:

  1. 0x08 graphic
    opcjonalny - obiekt tabeli A niekoniecznie musi być przypisany obiektowi tabeli B Ten typ uczestnictwa oznaczamy

  2. obowiązkowy

Ostateczny wygląd projektu bazy danych ma postać:

Nazwa tabeli

Nazwa tabeli

0x08 graphic
0x08 graphic
Pole 1 KP

Pole 2

:

:

0x08 graphic
0x08 graphic
0x08 graphic
0x08 graphic

Pole 1 KP

Pole 2 KO

:

:

Nazwa tabeli

0x08 graphic

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:

      1. analiza wymagań - baza danych przeznaczona do ułatwienia procesu zarządzania szkołą. Od bazy wymaga się możliwości:

  1. dodawania, usuwania i modyfikowania informacji o:

    1. uczniach i nauczycielach

    2. klasach

    3. dodatkowych zajęciach

  2. przydzielania lub odwoływania obowiązków nauczyciela

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

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

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

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

0x08 graphic

0x08 graphic
.

0x08 graphic
:

0x08 graphic

1

0x08 graphic

n

0x08 graphic
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

0x08 graphic
Id_rod KP

Imie_rod

Nazwisko_rod

Telefon_rod

Ulica_rod

Nrdomu_rod

Nrmieszk_rod

Kodpoczt_rod

Miasto_rod

0x08 graphic

Id_ucz KP

Id_rod KO

Id_kl KO

Imie_ucz

Nazwisko_ucz

Dataur_ucz

0x08 graphic
0x08 graphic

0x08 graphic
Id_pr KP

Imie_pr

Nazwisko_pr

Dataur_pr

Wykszt_pr

Ulica_pr

Nrdomu_pr

Nrmieszk_pr

Kopoczt_pr

Miasto_pr

0x08 graphic
0x08 graphic
0x08 graphic

Id_p KP

Nazwa_p

Opis_p

0x08 graphic

0x08 graphic
0x08 graphic

Sale

0x08 graphic
0x08 graphic

Id_s KP

Numer_s

Opis_s

Klasy

0x08 graphic

0x08 graphic
Id_kl KP

0x08 graphic
Id_wych KO

Nazwa_kl

Profil_kl

Opis_kl

0x08 graphic

Lokalizacja

Id_lok KP

Id_z KO

Id_s KO

Czaspocz_lok

Czaskon_lok

Zajęcia

0x08 graphic
0x08 graphic

Id_zaj KP

Id_pr KO

Id_p KO

Id_kl KO

0x08 graphic
0x08 graphic

0x08 graphic

0x08 graphic
0x08 graphic


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:

  1. przygotowanie graficznej struktury formularza

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

  1. zastosowaniu komponentu TDataBase w aplikacji

  2. definiowaniu aliasów BDE ( w Delphi )

  3. tworzeniu modułów danych

  4. tworzeniu formularzy dla powiązania tabel typu nadrzędnego z podrzędnymi

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

  1. komponentach TTable ( MasterSource, MasterField)

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

  1. 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)

  2. określenie na poziomie bazy danych - właściwość EditMaske jest efektywna przy zastosowaniu pojedynczej aplikacji ( tabeli )

  3. Cancel - polega ona na procedurach autorskich

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

    1. dublowanie kluczy

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

  1. uruchomieniu administratora ODBC

  2. kliknięciu zakładki config, Draywers, ODBC i wybraniu polecenia new

  3. ustaleniu nazwy sterowników ODBC

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



Wyszukiwarka

Podobne podstrony:
bazy danych wyk id 81390 Nieznany (2)
BAZY danych wyk id 81710 Nieznany (2)
przeprowadzenie analizy bazy danych uslugi AD, Informatyka HELP
Wyk ad 4 06, st. Politologia materiały
WYK AD Z RACHUNKU PRAWDO000, Inne
WYK AD Z RACHUNKU PRAWDOPOD, Inne
Zielarstwo - wyk-ad 4 - 26.10.2010, OGRODNICTWO UP LUBLIN (buka), Semestr III, ZIELARSTWO
Bazy danych - wyk, POLITECHNIKA ŚLĄSKA Wydział Mechaniczny-Technologiczny - MiBM POLSL, Inżynierskie
Budowa bazy danych, Dokumenty do szkoły, przedszkola; inne, Metody, metody badań pedagogicznych
Rynek Finansowy, Wyk ad 1 26 IX 2009
Ekonomia rynkowa - wyk+éad 05, Studia, Informatyka Stosowana PWSZ Tarnów st 1, Semestr I, Ekonomia,
Ekonomia rynkowa - wyk+éad 04, Studia, Informatyka Stosowana PWSZ Tarnów st 1, Semestr I, Ekonomia,
Ekonomia rynkowa - wyk+éad 06, Studia, Informatyka Stosowana PWSZ Tarnów st 1, Semestr I, Ekonomia,
Ekonomia rynkowa - wyk+éad 01, Studia, Informatyka Stosowana PWSZ Tarnów st 1, Semestr I, Ekonomia,
Ekonomia rynkowa - wyk+éad 03, Studia, Informatyka Stosowana PWSZ Tarnów st 1, Semestr I, Ekonomia,

więcej podobnych podstron