Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00350 006665 13245986 na godz. na dobę w sumie
Projektowanie baz danych dla każdego. Przewodnik krok po kroku - książka
Projektowanie baz danych dla każdego. Przewodnik krok po kroku - książka
Autor: Liczba stron: 504
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-7995-9 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> bazy danych >> inne
Porównaj ceny (książka, ebook, audiobook).

Praktyczny przewodnik dla projektantów baz danych!

Dzisiejszy świat opiera się na bazach danych. Są one sercem każdego przedsięwzięcia, począwszy od działalności banku, a na zakupach internetowych skończywszy. Ich projektowanie wymaga nie lada kunsztu, a drobny błąd może doprowadzić do nieoczekiwanych konsekwencji. Dlatego od projektantów baz danych wymaga się ogromnej wiedzy i dokładności, a doświadczenie w tej dziedzinie zdobywa się latami.

Dzięki tej książce będziesz w stanie zgłębić tajniki budowy baz danych, podane w przejrzysty, przystępny i rozsądny sposób. W trakcie lektury poznasz rodzaje baz, ich dostępne modele oraz cel ich projektowania. Kolejne rozdziały dotyczą procesu projektowania nowej bazy oraz analizowania baz istniejących. Ponadto dowiesz się z nich, jak istotne jest właściwe określenie kluczy i relacji oraz nałożenie więzów integralności. Szczególną uwagę powinieneś zwrócić na rozdział poświęcony najczęściej popełnianym błędom - jego dokładna lektura pozwoli Ci uniknąć wielu problemów. Książka ta jest obowiązkową lekturą dla wszystkich osób mających styczność z bazami danych w codziennej pracy.

Dzięki tej książce:

Wiedza dotycząca baz danych w pigułce!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Tytuł oryginału: Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design (3rd Edition) Tłumaczenie: Katarzyna Żarnowska (wstęp, rozdz. 1 – 6, 8, 9), Radosław Meryk (rozdz. 7, 13 – 15, dodatki), Ireneusz Jakóbik (rozdz. 10 – 12) ISBN: 978-83-246-7995-9 Authorized translation from the English language edition, entitled: DATABASE DESIGN FOR MERE MORTALS: A HANDS-ON GUIDE TO RELATIONAL DATABASE DESIGN, Third Edition; ISBN 0321884493; by Michael J. Hernandez; published by Pearson Education, Inc, publishing as Addison Wesley. Copyright © 2013 Michael J. Hernandez. All rights reserved. No part of this book may by reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc. Polish language edition published by HELION S.A. Copyright © 2014. Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Wydawnictwo HELION dołożyło wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie bierze jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Wydawnictwo HELION nie ponosi również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Materiały graficzne na okładce zostały wykorzystane za zgodą Shutterstock Images LLC. Wydawnictwo HELION ul. Kościuszki 1c, 44-100 GLIWICE tel. 32 231 22 19, 32 230 98 63 e-mail: helion@helion.pl WWW: http://helion.pl (księgarnia internetowa, katalog książek) Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/projbd Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. Printed in Poland. • Kup książkę • Poleć książkę • Oceń książkę • Księgarnia internetowa • Lubię to! » Nasza społeczność Spis tre(cid:295)ci O autorze ........................................................................ 15 S(cid:273)owo wst(cid:250)pne ................................................................ 17 Do wydania trzeciego ...............................................................................................17 Z wydania drugiego... ........................................................................................17 Z wydania pierwszego... ....................................................................................18 Przedmowa ..................................................................... 19 Podzi(cid:250)kowania ................................................................ 21 Wprowadzenie ................................................................. 23 Co nowego w trzecim wydaniu ..............................................................................25 Kto powinien przeczytać tę książkę .......................................................................25 Cel niniejszej książki ................................................................................................26 Jak czytać tę książkę .................................................................................................27 Organizacja książki ...................................................................................................28 Część I: Projektowanie relacyjnych baz danych ...............................................28 Część II: Proces projektowania ........................................................................28 Część III: Inne problemy projektowania baz danych ...................................29 Część IV: Dodatki ..............................................................................................29 Słowo na temat przykładów i technik opisywanych w tej książce .....................30 Nowe podejście do nauki ........................................................................................30 Cz(cid:250)(cid:295)(cid:232) I Projektowanie relacyjnych baz danych ...... 33 Rozdzia(cid:273) 1. Relacyjna baza danych .................................................... 35 Tematy omówione w tym rozdziale .......................................................................35 Rodzaje baz danych ..................................................................................................36 Wczesne modele baz danych ..................................................................................36 Hierarchiczny model bazy danych ..................................................................37 Sieciowy model baz danych .............................................................................39 Kup książkęPoleć książkę 6 Projektowanie baz danych dla ka(cid:318)dego. Przewodnik krok po kroku Model relacyjnych baz danych ...............................................................................41 Pozyskiwanie danych ........................................................................................42 Zalety relacyjnych baz danych .........................................................................44 Zarządzanie relacyjną bazą danych ........................................................................45 Poza modelem relacyjnym ......................................................................................46 Co niesie przyszłość .................................................................................................47 Ostatnia uwaga ...................................................................................................48 Podsumowanie ..........................................................................................................48 Pytania kontrolne .....................................................................................................49 Rozdzia(cid:273) 2. Cele projektowania .......................................................... 51 Tematy omówione w tym rozdziale .......................................................................51 Dlaczego projektowanie baz danych powinno nas interesować? ......................51 Znaczenie teorii ........................................................................................................53 Zalety poznania dobrej metodologii projektowania ...........................................54 Cele dobrego projektowania ...................................................................................55 Korzyści wynikające z dobrego projektowania ....................................................55 Metody projektowania baz danych ........................................................................56 Tradycyjne metody projektowania .................................................................56 Metoda projektowania zaprezentowana w tej książce .................................57 Normalizacja .............................................................................................................58 Podsumowanie ..........................................................................................................60 Pytania kontrolne .....................................................................................................61 Rozdzia(cid:273) 3. Terminologia ................................................................... 63 Tematy omówione w tym rozdziale .......................................................................63 Dlaczego terminologia jest ważna ..........................................................................64 Pojęcia związane z wartością ...................................................................................64 Dane .....................................................................................................................64 Informacje ..........................................................................................................65 Null ......................................................................................................................66 Wartość znaczników null .................................................................................67 Problem ze znacznikami null ...........................................................................68 Pojęcia związane ze strukturą .................................................................................69 Tabele ..................................................................................................................69 Pole ......................................................................................................................71 Rekord .................................................................................................................72 Widok (perspektywa) ........................................................................................73 Klucze ..................................................................................................................74 Indeks ..................................................................................................................76 Kup książkęPoleć książkę Spis tre(cid:295)ci 7 Pojęcia związane z zależnościami ...........................................................................76 Zależności ...........................................................................................................76 Typy zależności ..................................................................................................77 Rodzaje udziału ..................................................................................................80 Stopień udziału ..................................................................................................81 Pojęcia związane z integralnością ..........................................................................82 Specyfikacja pola ................................................................................................82 Integralność danych ..........................................................................................82 Podsumowanie ..........................................................................................................83 Pytania kontrolne .....................................................................................................84 Cz(cid:250)(cid:295)(cid:232) II Proces projektowania .............................. 87 Rozdzia(cid:273) 4. Przegl(cid:230)d koncepcyjny ..................................................... 89 Tematy omówione w tym rozdziale .......................................................................89 Dlaczego ważna jest realizacja całego procesu projektowania ...........................90 Formułowanie definicji celu i założeń wstępnych ...............................................91 Analiza istniejącej bazy danych ..............................................................................91 Tworzenie struktur danych .....................................................................................92 Określanie i ustalanie relacji w tabelach ...............................................................93 Określanie reguł biznesowych ................................................................................93 Definiowanie widoków ............................................................................................94 Kontrola integralności danych ...............................................................................94 Podsumowanie ..........................................................................................................95 Pytania kontrolne .....................................................................................................96 Rozdzia(cid:273) 5. Rozpocz(cid:250)cie procesu projektowania ................................ 99 Tematy omówione w tym rozdziale .......................................................................99 Przeprowadzanie wywiadów .................................................................................100 Wytyczne dotyczące rozmówców .................................................................101 Wytyczne dotyczące osoby przeprowadzającej wywiad ..........................102 Formułowanie definicji celu .................................................................................106 Poprawnie sformułowana definicja celu ......................................................106 Układanie definicji celu ..................................................................................107 Formułowanie założeń wstępnych .......................................................................109 Poprawnie sformułowane założenia wstępne .............................................109 Układanie założeń wstępnych .......................................................................111 Podsumowanie ........................................................................................................114 Pytania kontrolne ...................................................................................................114 Kup książkęPoleć książkę 8 Projektowanie baz danych dla ka(cid:318)dego. Przewodnik krok po kroku Rozdzia(cid:273) 6. Analiza istniej(cid:230)cej bazy danych ..................................... 117 Tematy omówione w tym rozdziale .....................................................................117 Poznanie istniejącej bazy danych .........................................................................118 Papierowe bazy danych ..................................................................................120 Spadkowe bazy danych ...................................................................................120 Przeprowadzenie analizy .......................................................................................121 Spojrzenie na sposób gromadzenia danych .................................................121 Spojrzenie na sposób prezentowania informacji ...............................................124 Przeprowadzanie wywiadów .................................................................................127 Podstawowe techniki przeprowadzania wywiadów ...................................127 Zanim rozpoczniesz przeprowadzanie wywiadów... ..................................132 Wywiady z użytkownikami ...................................................................................132 Przegląd typów danych i sposobów ich wykorzystania .............................132 Przegląd próbek ...............................................................................................134 Przegląd wymagań informacyjnych ..............................................................137 Wywiady z kierownictwem ...................................................................................143 Przegląd obecnych wymagań informacyjnych ............................................143 Przegląd dodatkowych wymagań informacyjnych .....................................144 Przegląd przyszłych wymagań informacyjnych ..........................................144 Przegląd ogólnych wymagań informacyjnych ............................................145 Stworzenie kompletnej listy pól ...........................................................................145 Wstępna lista pól .............................................................................................145 Lista pól obliczeniowych ................................................................................150 Przegląd obu list wraz z pracownikami i kierownictwem .........................151 Podsumowanie ........................................................................................................155 Pytania kontrolne ...................................................................................................156 Rozdzia(cid:273) 7. Tworzenie struktur tabel ............................................... 159 Tematy omówione w tym rozdziale .....................................................................159 Definiowanie wstępnej listy tabel .........................................................................160 Identyfikacja domniemanych podmiotów ...................................................160 Korzystanie z listy podmiotów ......................................................................161 Korzystanie z celów misji ...............................................................................165 Definiowanie ostatecznej listy tabel .....................................................................167 Dostrajanie nazw tabel ....................................................................................168 Wskazywanie typów tabel ..............................................................................172 Redagowanie opisów tabel .............................................................................172 Powiązanie pól z każdą z tabel ..............................................................................177 Kup książkęPoleć książkę Spis tre(cid:295)ci 9 Dostrajanie pól ........................................................................................................179 Poprawianie nazw pól .....................................................................................179 Korzystanie z idealnego pola do eliminowania anomalii ..........................182 Eliminacja pól wieloczęściowych ..................................................................185 Eliminacja pól wielowartościowych ..............................................................186 Dostrajanie struktur tabel .....................................................................................192 Kilka słów o nadmiarowych danych i duplikatach pól ..............................192 Wykorzystanie warunków idealnej tabeli w celu dostrojenia struktur tabel ................................................................193 Wyznaczanie tabel-podzbiorów ....................................................................198 Podsumowanie ........................................................................................................208 Pytania kontrolne ...................................................................................................209 Rozdzia(cid:273) 8. Klucze .......................................................................... 211 Tematy omówione w tym rozdziale .....................................................................211 Dlaczego klucze są ważne ......................................................................................212 Definiowanie kluczy dla tabel ...............................................................................212 Klucze kandydujące .........................................................................................212 Klucze główne ..................................................................................................218 Klucze zastępcze ..............................................................................................222 Pola niekluczowe .............................................................................................223 Integralność na poziomie tabeli ...........................................................................223 Przegląd wstępnych struktur tabel .......................................................................224 Podsumowanie ........................................................................................................229 Pytania kontrolne ...................................................................................................230 Rozdzia(cid:273) 9. Specyfikacje pól ............................................................ 231 Tematy omówione w tym rozdziale .....................................................................231 Dlaczego specyfikacje pól są ważne .....................................................................232 Integralność na poziomie pól ...............................................................................233 Anatomia specyfikacji pól .....................................................................................233 Elementy ogólne ..............................................................................................234 Elementy fizyczne ............................................................................................239 Elementy logiczne ............................................................................................244 Wykorzystywanie unikatowych, ogólnych i replikowanych specyfikacji pól ...250 Definiowanie specyfikacji pól dla każdego pola w bazie danych ....................255 Podsumowanie ........................................................................................................256 Pytania kontrolne ...................................................................................................259 Kup książkęPoleć książkę 10 Projektowanie baz danych dla ka(cid:318)dego. Przewodnik krok po kroku Rozdzia(cid:273) 10. Relacje mi(cid:250)dzy tabelami ............................................... 261 Tematy omówione w tym rozdziale .....................................................................261 Dlaczego relacje są ważne ......................................................................................262 Rodzaje relacji .........................................................................................................263 Relacja jeden-do-jednego ...............................................................................264 Relacja jeden-do-wielu ....................................................................................265 Relacja wiele-do-wielu ....................................................................................267 Relacja zwrotna ................................................................................................273 Identyfikowanie istniejących relacji .....................................................................276 Ustanawianie wszystkich relacji ...........................................................................284 Relacje jeden-do-jednego i jeden-do-wielu .................................................284 Relacja wiele-do-wielu ....................................................................................290 Relacje zwrotne ................................................................................................294 Sprawdzanie struktury wszystkich tabel ......................................................298 Dokładna analiza wszystkich kluczy obcych ...............................................299 Ustanawianie charakterystyk relacji ....................................................................304 Definiowanie reguły usuwania dla każdej relacji ........................................304 Identyfikowanie rodzaju udziału każdej z tabel ..........................................308 Identyfikowanie stopnia udziału każdej z tabel ..........................................310 Weryfikowanie z użytkownikami i zarządem relacji istniejących między tabelami ...........................................................312 Uwaga końcowa ...............................................................................................312 Integralność na poziomie relacji ..........................................................................313 Podsumowanie ........................................................................................................317 Pytania kontrolne ...................................................................................................318 Rozdzia(cid:273) 11. Regu(cid:273)y biznesowe .......................................................... 321 Tematy omówione w tym rozdziale .....................................................................321 Czym są reguły biznesowe? ...................................................................................321 Rodzaje reguł biznesowych ............................................................................324 Kategorie reguł biznesowych ................................................................................326 Reguły biznesowe specyficzne dla pól ..........................................................326 Reguły biznesowe specyficzne dla relacji .....................................................327 Definiowanie i ustanawianie reguł biznesowych ...............................................328 Praca z użytkownikami oraz zarządem ........................................................328 Definiowanie i ustanawianie reguł biznesowych specyficznych dla pola ..................................................................................329 Definiowanie i ustanawianie reguł biznesowych specyficznych dla relacji ...............................................................................334 Kup książkęPoleć książkę Spis tre(cid:295)ci 11 Tabele walidacji ......................................................................................................341 Czym są tabele walidacji? ...............................................................................341 Korzystanie z tabel walidacji w celu realizowania reguł biznesowych ....342 Sprawdzanie arkuszy specyfikacji reguł biznesowych ......................................346 Podsumowanie ........................................................................................................352 Pytania kontrolne ...................................................................................................353 Rozdzia(cid:273) 12. Widoki .......................................................................... 355 Tematy omówione w tym rozdziale .....................................................................355 Czym są widoki? .....................................................................................................355 Anatomia widoku ...................................................................................................357 Widok danych ..................................................................................................357 Widok zagregowany ........................................................................................361 Widok walidacji ...............................................................................................364 Określanie i definiowanie widoków ....................................................................366 Praca z użytkownikami i zarządem ...............................................................366 Identyfikowanie widoków ..............................................................................367 Przeglądanie dokumentacji każdego widoku ..............................................373 Podsumowanie ........................................................................................................378 Pytania kontrolne ...................................................................................................380 Rozdzia(cid:273) 13. Sprawdzanie integralno(cid:295)ci danych ................................ 383 Tematy omówione w tym rozdziale .....................................................................383 Dlaczego należy sprawdzać integralność danych? .............................................384 Sprawdzanie i korygowanie integralności danych .............................................384 Integralność na poziomie tabel ......................................................................385 Integralność na poziomie pól ........................................................................385 Integralność na poziomie relacji ...................................................................385 Reguły biznesowe ............................................................................................386 Widoki ...............................................................................................................386 Kompletowanie dokumentacji bazy danych ....................................................387 W końcu zrobione! .................................................................................................388 Podsumowanie ........................................................................................................388 Cz(cid:250)(cid:295)(cid:232) III Inne problemy projektowania baz danych ..................... 389 Rozdzia(cid:273) 14. Czego nie nale(cid:318)y robi(cid:232)? ................................................ 391 Tematy omówione w tym rozdziale .....................................................................391 Płaskie pliki ..............................................................................................................392 Kup książkęPoleć książkę 12 Projektowanie baz danych dla ka(cid:318)dego. Przewodnik krok po kroku Projekt na bazie arkusza kalkulacyjnego .............................................................393 Rozwiązywanie problemów związanych z przyzwyczajeniami do widoku arkusza kalkulacyjnego .......................394 Projekt bazy danych pod kątem konkretnego oprogramowania ....................396 Wnioski końcowe ...................................................................................................397 Podsumowanie ........................................................................................................397 Rozdzia(cid:273) 15. Naginanie b(cid:230)d(cid:316) (cid:273)amanie regu(cid:273) ........................................ 399 Tematy omówione w tym rozdziale .....................................................................399 Kiedy można nagiąć lub złamać reguły? .............................................................399 Projektowanie analitycznej bazy danych .....................................................399 Poprawianie wydajności obliczeń .................................................................400 Dokumentowanie działań .....................................................................................402 Podsumowanie ........................................................................................................403 Na zako(cid:275)czenie ............................................................. 405 .............................................................. 407 Dodatki Dodatek A Odpowiedzi na pytania kontrolne .................................. 409 Dodatek B Diagram procesu projektowania baz danych .................. 427 Dodatek C Wytyczne projektowe .................................................... 445 Definiowanie i wprowadzanie reguł biznesu specyficznych dla pól ...............445 Definiowanie i wprowadzanie reguł biznesu specyficznych dla relacji ..........445 Warunki klucza kandydującego ...........................................................................446 Warunki klucza obcego .........................................................................................446 Warunki klucza głównego .....................................................................................446 Reguły tworzenia kluczy głównych ...............................................................447 Warunki idealnego pola ........................................................................................447 Warunki idealnej tabeli .........................................................................................447 Integralność na poziomie pól ...............................................................................448 Wytyczne tworzenia opisów pól ..........................................................................448 Wytyczne tworzenia opisów tabel ........................................................................448 Wytyczne tworzenia nazw pól ..............................................................................449 Wytyczne tworzenia nazw tabel ...........................................................................449 Identyfikowanie relacji ..........................................................................................450 Identyfikacja wymagań dotyczących perspektyw ..............................................450 Wytyczne dotyczące prowadzonych rozmów ..................................................451 Wskazówki związane z uczestnikami ...........................................................451 Wskazówki dotyczące prowadzącego rozmowę .........................................451 Kup książkęPoleć książkę Spis tre(cid:295)ci 13 Misje .........................................................................................................................451 Cele misji .................................................................................................................452 Integralność na poziomie relacji ..........................................................................452 Eliminowanie pól wielowartościowych ...............................................................452 Integralność na poziomie tabel .............................................................................453 Dodatek D Formularze dokumentacyjne ......................................... 455 Dodatek E Symbole u(cid:318)ywane w diagramach stosowanych w procesie projektowania baz danych ............................ 459 Dodatek F Przyk(cid:273)adowe projekty .................................................... 461 Dodatek G O normalizacji .............................................................. 467 Uwaga... ....................................................................................................................467 Krótkie przypomnienie ..........................................................................................468 W jaki sposób normalizacja jest zintegrowana z moją metodologią projektowania? .....................................................................................................471 Projekt logiczny a projekt fizyczny i implementacja .........................................473 Dodatek H Zalecana lektura ............................................................ 475 S(cid:273)owniczek .................................................................... 477 Literatura ..................................................................... 489 Skorowidz ..................................................................... 491 Kup książkęPoleć książkę 14 Projektowanie baz danych dla ka(cid:318)dego. Przewodnik krok po kroku Kup książkęPoleć książkę 1 Relacyjna baza danych Ryba musi p(cid:239)ywa(cid:202) trzy razy — w wodzie, w ma(cid:258)le i w winie — przys(cid:239)owie Tematy omówione w tym rozdziale Rodzaje baz danych Wczesne modele baz danych Model relacyjnych baz danych Zarządzanie relacyjną bazą danych Poza modelem relacyjnym Co niesie przyszłość Podsumowanie Pytania kontrolne Relacyjne bazy danych istnieją od ponad 40 lat. Ten najbardziej rozpowszechniony na świecie typ baz danych niezbędnych w naszym codziennym życiu rozkręcił branżę wartą miliony dolarów. Jest bardzo prawdopodobne, że korzystasz z relacyjnej bazy danych za każdym razem, kiedy robisz zakupy przez internet lub w lokalnym sklepie, układasz plan podróży lub wypożyczasz książki. Zanim zagłębimy się w proces projektowania, przyjrzyjmy się krótkiej historii relacyjnych baz danych — skąd się wzięły, gdzie są teraz i w jakim kierunku podążają. Kup książkęPoleć książkę 36 Rozdzia(cid:273) 1. Relacyjna baza danych Rodzaje baz danych Co to jest baza danych? Jak zapewne wiesz, baza danych to zorganizowana kolekcja danych wykorzystywanych do modelowania niektórych typów organizacji lub ich procesów. Nie ma znaczenia, czy do zbierania i przechowywania danych używasz papieru, czy aplikacji komputerowej. Jeśli tylko zbierasz dane w zorganizowany sposób i w konkretnym celu, masz bazę danych. W dalszej części tej książki przyjmiemy, że do zbierania i przechowywania danych będziemy wykorzystywać aplikacje. Istnieją dwa rodzaje baz danych: operacyjne i analityczne. Operacyjne bazy danych są kręgosłupem wielu firm, organizacji oraz instytucji na całym świecie. Ten rodzaj bazy danych jest wykorzystywany głównie do przetwarzania transakcji internetowych (OLTP) w sytuacjach, kiedy istnieje potrzeba zbierania, modyfikacji i utrzymania danych każdego dnia. Dane przechowywane w operacyjnej bazie danych są dynamiczne, co znaczy, że wciąż się zmieniają i zawsze odzwierciedlają aktualne informacje. Organizacje takie jak sklepy, wytwórnie i wydawnictwa korzystają z operacyjnych baz danych, ponieważ ich dane ciągle się zmieniają. Analityczne bazy danych są głównie wykorzystywane przy analitycznym przetwarzaniu online (OLAP) w sytuacjach, kiedy istnieje potrzeba przechowywania i śledzenia danych historycznych i zależnych od czasu. Analityczna baza danych jest cennym atutem, jeśli potrzebujemy prześledzić trendy, przejrzeć dane statystyczne z długiego zakresu czasu oraz stworzyć taktyczne lub strategiczne projekcje biznesowe. Ten typ bazy danych przechowuje dane statyczne, co oznacza, że dane te nie zmieniają się nigdy (lub bardzo rzadko). Informacje zebrane w analitycznej bazie danych pokazują dane dotyczące konkretnego momentu w czasie. Laboratoria chemiczne, firmy geologiczne oraz agencje marketingowe zajmujące się analizą to przykłady firm, które mogą wykorzystywać analityczne bazy danych. Analityczne bazy danych często wykorzystują dane z baz operacyjnych jako główne źródło, mogą więc istnieć między nimi powiązania. Jednakże operacyjne i analityczne bazy danych spełniają bardzo specyficzne potrzeby w zakresie przetwarzania danych, a tworzenie ich struktur wymaga radykalnie odmiennych metodologii projektowych. Ta książka skupia się na projektowaniu operacyjnych baz danych, ponieważ są one najbardziej rozpowszechnione. Wczesne modele baz danych Zanim narodził się model relacyjnych baz danych, w powszechnym użyciu były dwa inne modele, wykorzystywane do utrzymania danych i wykonywania na nich operacji — model hierarchiczny oraz model sieciowy. Niektóre pojęcia, z którymi zetkniesz się w tym rozdziale, zostały szczegółowo wyjaśnione w rozdziale 3. Kup książkęPoleć książkę Wczesne modele baz danych 37 Uwaga Krótki opis ka(cid:318)dego z tych modeli przedstawiony jest tu tylko ze wzgl(cid:250)dów historycznych. Uwa(cid:318)am, (cid:318)e warto wiedzie(cid:232), co poprzedzi(cid:273)o model relacyjny, aby lepiej zrozumie(cid:232), co doprowadzi(cid:273)o do jego powstania i ewolucji. W tym przegl(cid:230)dzie opisuj(cid:250) pokrótce struktur(cid:250) danych w ka(cid:318)dym mo- delu, dost(cid:250)p do nich, a tak(cid:318)e prezentuj(cid:250) zale(cid:318)no(cid:295)ci pomi(cid:250)dzy dwiema tabe- lami i kilka wad oraz zalet ka(cid:318)dego z modeli. Hierarchiczny model bazy danych Dane w tym typie bazy mają strukturę hierarchiczną, a typowy diagram ma kształt odwróconego drzewa. Pojedyncza tabela w bazie danych pełni rolę korzeni odwróconego drzewa, a inne tabele są gałęziami wyrastającymi z tych korzeni. Rysunek 1.1 pokazuje diagram typowej struktury hierarchicznej bazy danych. Rysunek 1.1. Diagram typowej hierarchicznej bazy danych Baza danych agentów W przyk(cid:273)adzie pokazanym na rysunku 1.1 agent zajmuje si(cid:250) rezerwacjami kilku artystów estradowych, a ka(cid:318)dy artysta ma swój harmonogram. Agent ma równie(cid:318) kilku klientów, których potrzebami musi si(cid:250) zaj(cid:230)(cid:232). Klient re- zerwuje wyst(cid:250)p poprzez agenta i p(cid:273)aci mu za us(cid:273)ug(cid:250). Zależność w hierarchicznej bazie danych reprezentowana jest przez pojęcia rodzic i dziecko. W tym typie zależności tabela-rodzic może być powiązana z jedną lub kilkoma tabelami-dziećmi, ale pojedyncza tabela-dziecko może być powiązana tylko z jedną tabelą-rodzicem. Te tabele są wyraźnie ze sobą połączone poprzez wskaźnik lub fizyczne uporządkowanie rekordów w tabeli. W tym modelu użytkownik dostaje się do danych, zaczynając od głównej tabeli, a kierując się w dół hierarchii, dociera do danych docelowych. Taka metoda dostępu wymaga od użytkownika obeznania ze strukturą bazy danych. Kup książkęPoleć książkę 38 Rozdzia(cid:273) 1. Relacyjna baza danych Jedną z zalet korzystania z hierarchicznej bazy danych jest to, że użytkownik może bardzo sprawnie uzyskać dane, ponieważ wewnątrz struktury tabeli istnieją wyraźne połączenia. Kolejną zaletą jest wbudowana integralność odniesień, która jest wykonywana automatycznie. Dzięki temu mamy pewność, że rekord w tabeli-dziecku będzie połączony z istniejącym rekordem w tabeli-rodzicu oraz że usunięty rekord w tabeli-rodzicu spowoduje usunięcie wszystkich powiązanych z nim rekordów w tabeli-dziecku. Problem w hierarchicznej bazie danych pojawia się, kiedy użytkownik potrzebuje przechować w tabeli-dziecku rekord, który w danym momencie nie jest połączony z żadnym rekordem z tabeli-rodzica. Przyjrzyj się przykładowi wykorzystania bazy danych agentów z rysunku 1.1. Użytkownik nie może wprowadzić danych nowego artysty do tabeli Arty(cid:258)ci, dopóki ten artysta nie zostanie przypisany do agenta z tabeli Agenci. Przypomnij sobie, że rekord w tabeli-dziecku (w tym przypadku w tabeli Arty(cid:258)ci) musi być powiązany z rekordem w tabeli-rodzicu (Agenci). Jednak w prawdziwym życiu artyści zazwyczaj najpierw zapisują się do agencji, a dopiero później zostaje im przypisany agent. Taki scenariusz jest trudny do wprowadzenia w hierarchicznej bazie danych. Możemy obejść te zasady, zakładając fikcyjny rekord w tabeli Agenci. Taka opcja nie jest niestety optymalna. Ten typ baz danych nie wspiera złożonych zależności i często generuje problemy związane ze zbędnymi danymi. Na przykład pomiędzy klientami i artystami istnieje zależność „wiele do wielu” — artysta pracuje dla wielu klientów, a klient zatrudnia wielu artystów. Ten typ zależności nie może być modelowany w hierarchicznej bazie danych, należy więc wprowadzić dodatkowe dane zarówno do tabeli Harmonogram, jak i Anga(cid:285)e. 1. Tabela Harmonogram będzie teraz zawierała dane klienta (takie jak nazwisko, adres i numer telefonu), by pokazać, dla kogo i gdzie będzie występował artysta. Te dane są tutaj zbędne, ponieważ są one przechowywane w tabeli Klienci. 2. Tabela Anga(cid:285)e będzie teraz zawierała dane artystów (takie jak nazwisko, numer telefonu, rodzaj działalności artysty), aby pokazać, którzy artyści pracują dla których klientów. Te dane również są zbędne, ponieważ są aktualnie przechowywane w tabeli Arty(cid:258)ci. Problem z dodatkowymi danymi polega na tym, że możliwy jest brak konsekwencji we wprowadzaniu danych. To z kolei prowadzi do tworzenia niedokładnych informacji. Użytkownik może obejść ten problem, tworząc jedną hierarchiczną bazę danych specjalnie dla artystów, a drugą specjalnie dla agentów. Nowa baza danych dla artystów będzie się składała tylko z tabeli Arty(cid:258)ci, a zaktualizowana baza agentów będzie zawierała tabele Agenci, Klienci, P(cid:239)atno(cid:258)ci oraz Anga(cid:285)e. Tabela Harmonogram nie będzie już potrzebna w bazie danych artystów, ponieważ można określić logiczną zależność (tabela-dziecko) pomiędzy tabelą Anga(cid:285)e w bazie danych agentów a tabelą Arty(cid:258)ci w bazie danych artystów. Mając tę zależność ustaloną, jesteś w stanie wyszukać różnorodne informacje, na przykład listę zamówionych przez danego klienta artystów lub harmonogram występów dla danego artysty. Rysunek 1.2 pokazuje diagram nowego modelu. Kup książkęPoleć książkę Wczesne modele baz danych 39 Rysunek 1.2. Wykorzystywanie hierarchicznej bazy danych do rozwi(cid:241)zywania problemów z zale(cid:276)no(cid:264)ci(cid:241) „wiele do wielu” Jak łatwo zauważyć, osoba projektująca hierarchiczną bazę danych musi być zdolna do rozpoznania potrzeby wykorzystania tej techniki dla zależności typu „wiele do wielu”. Tutaj potrzeba ta była w miarę oczywista, ale wiele zależności jest znacznie bardziej niejasnych i mogą zostać zidentyfikowane dopiero na bardzo późnym etapie projektowania lub, co gorsza, już po oddaniu bazy danych do użytku. Hierarchiczne bazy danych były bardzo popularne i sprawdziły się dobrze w systemach pamięci taśmowej wykorzystywanej przez komputery mainframe w latach 70. Jednak mimo że zapewniały szybki i bezpośredni dostęp do danych i w wielu przypadkach okazały się bardzo przydatne, potrzebny był nowy model baz danych, który rozwiązałby rosnący problem zbędnych danych oraz złożonych zależności pomiędzy nimi. Sieciowy model baz danych Sieciowe bazy danych zostały stworzone głównie w celu rozwiązania niektórych problemów istniejących w hierarchicznych bazach danych. Ich struktura reprezentowana jest przez węzły oraz zestawy struktur. Rysunek 1.3 pokazuje diagram typowej sieciowej bazy danych. Węzeł przedstawia kolekcję rekordów, a zestaw struktur ustala i prezentuje zależność w sieciowej bazie danych. Wzajemny stosunek pary węzłów prezentuje przejrzysta konstrukcja, pokazując jeden węzeł jako właściciela (ang. owner), a drugi jako uczestnika (ang. member), co jest znacznym postępem w stosunku do zależności rodzic – dziecko. Zestaw struktur wspiera zależność „jeden do wielu”, co oznacza, że rekord w węźle- -właścicielu może być powiązany z jednym lub wieloma rekordami w węźle-uczestniku, Kup książkęPoleć książkę 40 Rozdzia(cid:273) 1. Relacyjna baza danych Rysunek 1.3. Diagram typowej sieciowej bazy danych ale pojedynczy rekord w węźle-uczestniku może być powiązany tylko z jednym rekordem w węźle-właścicielu. Dodatkowo rekord w węźle-uczestniku nie może istnieć bez odwołania do istniejącego rekordu w węźle-właścicielu. Na przykład klient musi być przypisany do agenta, ale agent może wciąż występować w bazie danych bez przypisanych klientów. Rysunek 1.4 pokazuje diagram prostego zestawu struktur. Jeden lub kilka zestawów (połączeń) może być zdefiniowanych pomiędzy konkretną parą węzłów, a pojedynczy węzeł może być powiązany również z innymi węzłami w bazie danych. Na rysunku 1.3 na przykład węzeł Klienci jest powiązany z węzłem P(cid:239)atno(cid:258)ci poprzez strukturę P(cid:239)ac(cid:200). Jest on także powiązany z węzłem Anga(cid:285)e poprzez strukturę Wyst(cid:218)puj(cid:200). Oprócz odnoszenia się do węzła Klienci węzeł Anga(cid:285)e łączy się także z węzłem Arty(cid:258)ci za pomocą struktury Wyst(cid:218)puj(cid:200). Rysunek 1.4. Podstawowa struktura z(cid:228)o(cid:276)ona W sieciowej bazie danych użytkownik może uzyskać dostęp do danych poprzez odpowiednie struktury złożone. Inaczej jest w hierarchicznej bazie danych, gdzie dostęp można uzyskać poprzez główną tabelę. Tutaj użytkownik ma dostęp do danych z bazy sieciowej, a zacząć może od dowolnego węzła i poruszać się do tyłu lub do przodu Kup książkęPoleć książkę Model relacyjnych baz danych 41 poprzez powiązane zestawy. Przyjrzyjmy się jeszcze raz bazie danych agentów na rysunku 1.3. Przyjmijmy, że użytkownik chce znaleźć agenta, który dokonał rezerwacji określonego występu. Użytkownik zaczyna od zlokalizowania odpowiedniego rekordu występu w węźle Anga(cid:285)e, a następnie poprzez strukturę Wyst(cid:218)puj(cid:200) określa, który agent „zarządza” rekordem tego występu. W końcu użytkownik poprzez strukturę Reprezentuj(cid:200) odnajduje odpowiedniego agenta, który „zarządza” rekordem klienta. Użytkownik może znaleźć odpowiedź na wiele pytań, o ile potrafi poprawnie nawigować w odpowiednich strukturach. Zaletą sieciowej bazy danych jest szybki dostęp do danych. Pozwala ona również użytkownikom na tworzenie bardziej skomplikowanych kwerend, niż byłoby to możliwe w przypadku hierarchicznej bazy danych. Główną wadą sieciowej bazy danych jest to, że aby móc poruszać się w strukturach, użytkownik musi być dobrze zaznajomiony z bazą. Jeszcze raz przyjrzyjmy się bazie danych agentów z rysunku 1.3. To na użytkowniku spoczywa obowiązek zaznajomienia się z zestawami struktur, jeśli chce sprawdzić, czy opłata za określony występ została wniesiona. Kolejną wadą jest trudność w takim wprowadzaniu zmian do struktury bazy danych, aby nie wpływało to negatywnie na aplikacje, które z nią współpracują. Przypominam, że w sieciowej bazie danych zależność zdefiniowana jest jako zestaw struktur. Nie możesz zmieniać zestawu struktur bez wpływania na aplikacje, które wykorzystują te struktury do poruszania się pomiędzy danymi. Jeśli zmienisz zestaw struktur, musisz również zmodyfikować wszystkie powiązania tej struktury z zewnętrznymi aplikacjami. Mimo iż sieciowe bazy danych były krokiem naprzód w porównaniu z bazami hierarchicznymi, niektórzy wciąż wierzyli, że musi istnieć lepszy sposób na zarządzanie i utrzymywanie dużych ilości danych. W miarę pojawiania się kolejnych modeli danych użytkownicy przekonywali się, że mogą zadawać coraz bardziej złożone pytania, zwiększając tym samym wymagania stawiane przed bazami danych. W ten sposób doszliśmy do modelu relacyjnych baz danych. Model relacyjnych baz danych Relacyjna baza danych powstała w 1969 roku i jest wciąż jednym z najszerzej wykorzystywanych modeli w zarządzaniu danymi. Ojcem modelu relacyjnego jest dr Edgar F. Codd, który w późnych latach 60. pracował jako naukowiec w IBM i szukał nowych sposobów na radzenie sobie z dużymi ilościami danych. Jego niezadowolenie z ówczesnych modeli baz danych doprowadziło go do rozważań na temat wykorzystania dyscyplin i struktur matematycznych do rozwiązania niezliczonych problemów, które napotykał. Jako zawodowy matematyk mocno wierzył, że może wykorzystać określone gałęzie matematyki do rozwiązania problemów takich jak zbędne dane, ich słaba integralność oraz zbytnia zależność struktur baz danych od ich fizycznej implementacji. Dr Codd oficjalnie przedstawił nowy model relacyjny w swojej książce zatytułowanej A Relational Model of Data for Large Shared Databanks1 w czerwcu 1970 roku. Swój 1 Edgar F. Codd, A Relational Model of Data for Large Shared Databanks, „Communications of the ACM”, czerwiec 1970, s. 377 – 387. Kup książkęPoleć książkę 42 Rozdzia(cid:273) 1. Relacyjna baza danych nowy model oparł na dwóch gałęziach matematyki — teorii zbiorów i logice predykatów pierwszego rzędu. Sama nazwa modelu pochodzi od terminu relacja, który jest częścią teorii zbiorów. Szeroko rozpowszechniona błędna koncepcja głosi, że model relacyjny zapożyczył swoją nazwę od powiązań pomiędzy tabelami relacyjnej bazy danych. Relacyjna baza danych przechowuje dane w relacjach, które są przez użytkowników postrzegane jako tabele. Każda relacja składa się z krotek, zwanych rekordami, oraz atrybutów, zwanych polami. W dalszej części książki będę używał terminów tabele, rekordy oraz pola. Fizyczny układ rekordów lub pól jest zupełnie niematerialny, a każdy rekord w tabeli jest możliwy do zidentyfikowania poprzez pole zawierające unikatową wartość. To są dwie cechy charakterystyczne relacyjnej bazy danych, które pozwalają, by dane istniały niezależnie od sposobu ich fizycznego przechowywania w komputerze. W związku z tym, by wydobyć dane, użytkownik nie musi znać fizycznej lokalizacji rekordu. Różni się to zupełnie od modeli hierarchicznych oraz sieciowych, w których znajomość struktur była niezbędna do wydobycia danych z bazy. Model relacyjny kategoryzuje zależności na „jeden do jednego”, „jeden do wielu” oraz „wiele do wielu”. Te zależności zostaną szczegółowo omówione w rozdziale 10. Zależność pomiędzy parą tabel jest bezwzględnie ustalona przez pasujące wartości wspólnego pola. Na rysunku 1.5 na przykład tabele Klienci i Agenci są ze sobą powiązane poprzez pole Nr agenta. Konkretny klient jest powiązany z agentem poprzez pasujący Nr agenta. W ten sam sposób tabele Arty(cid:258)ci oraz Anga(cid:285)e powiązane są ze sobą poprzez Nr artysty. Rekord w tabeli Arty(cid:258)ci może być powiązany z rekordem w tabeli Anga(cid:285)e poprzez pasujący Nr artysty. O ile użytkownik zna się na zależnościach występujących pomiędzy tabelami w bazie danych, może mieć dostęp do danych na niemal nieskończoną ilość sposobów. Może wydobywać dane z tabel, które są ze sobą powiązane bezpośrednio oraz pośrednio. Przyjrzyj się bazie danych agentów na rysunku 1.5. Mimo że tabela Klienci łączy się z tabelą Anga(cid:285)e pośrednio, użytkownik jest w stanie uzyskać listy klientów i artystów, którzy dla nich pracowali (to oczywiście zależy od tego, jak skonstruowane są tabele, ale dla naszych potrzeb ten przykład jest wystarczający). Użytkownik zrobi to z łatwością, ponieważ tabela Klienci łączy się bezpośrednio z tabelą Anga(cid:285)e, a ta z kolei z tabelą Arty(cid:258)ci. Pozyskiwanie danych W bazie relacyjnej dane pozyskuje się, wykorzystując strukturalny język zapytań SQL. SQL to standardowy język wykorzystywany do tworzenia, modyfikowania, utrzymywania relacyjnej bazy danych oraz tworzenia zapytań. Poniższy przykład pokazuje deklarację SQL, którą możesz wykorzystać do otrzymania listy klientów w mieście Katowice: SELECT Nazwisko klienta, Imi(cid:218) klienta, Telefon klienta FROM Klienci WHERE City = Katowice ORDER BY Nazwisko klienta, Imi(cid:218) klienta Kup książkęPoleć książkę Model relacyjnych baz danych 43 Rysunek 1.5. Przyk(cid:228)ady tabel powi(cid:241)zanych w relacyjnej bazie danych Podstawowa kwerenda SQL składa się z trzech komponentów: deklaracji SELECT...FROM, warunku WHERE oraz warunku ORDER BY. Warunek SELECT wykorzystujesz, by wskazać pola, których chcesz użyć w kwerendzie, a warunek FROM, by wskazać tabelę lub tabele, do których należą te pola. Możesz filtrować rekordy, które zwraca kwerenda, poprzez narzucanie kryteriów na jedno lub wiele pól za pomocą warunku WHERE, a następnie sortować rezultaty w porządku rosnącym lub malejącym za pomocą warunku ORDER BY. Większość dzisiejszych programów obsługujących relacyjne bazy danych zawiera w sobie różne formy implementacji SQL, poczynając od okien, w których użytkownicy wpisują „surowe” komendy SQL, aż po narzędzia pozwalające użytkownikom na budowanie kwerend za pomocą elementów graficznych. Na przykład użytkownik pracujący z oprogramowaniem R:BASE firmy R:BASE Technologies może wybrać budowanie i wykonywanie poleceń SQL wprost z okna poleceń, a ktoś korzystający z Microsoft SQL Kup książkęPoleć książkę 44 Rozdzia(cid:273) 1. Relacyjna baza danych Server może uznać, że łatwiej jest budować kwerendy, wykorzystując narzędzie graficzne. Bez względu na sposób budowy kwerend użytkownik może je zachować do następnego wykorzystania. Do pracy z bazami danych nie zawsze konieczna jest znajomość języka SQL. Jeśli oprogramowanie daje możliwość graficznego tworzenia kwerend lub jest zbudowane specjalnie dla Twojej bazy danych, samodzielne wpisywanie komend nie jest konieczne. Dobrze jest jednak poznać podstawy SQL. Osobom korzystającym z narzędzi tworzenia kwerend pomoże to w zrozumieniu i poprawieniu ewentualnych błędów w kwerendach, przyda się także w przypadku konieczności skorzystania z oprogramowania wyższej klasy, takiego jak Oracle lub Microsoft SQL Server. Uwaga Mimo i(cid:318) szczegó(cid:273)owa analiza j(cid:250)zyka SQL wykracza poza zakres tej ksi(cid:230)(cid:318)ki, musisz zrozumie(cid:232), (cid:318)e SQL to j(cid:250)zyk bezpo(cid:295)rednio powi(cid:230)zany z modelem relacyjnych baz danych. Je(cid:295)li masz potrzeb(cid:250) lub ochot(cid:250) pozna(cid:232) SQL, mo(cid:318)esz zacz(cid:230)(cid:232) od przeczytania innej z moich ksi(cid:230)(cid:318)ek SQL Queries for Mere Mortals, a nast(cid:250)pnie zapozna(cid:232) si(cid:250) z innymi ksi(cid:230)(cid:318)kami dotycz(cid:230)cymi SQL, które wymienione s(cid:230) w dodatku H. Zalety relacyjnych baz danych Relacyjna baza danych posiada więcej zalet, niż poprzednio omówione. Należą do nich: (cid:132) Wbudowana, wielopoziomowa integralność. Integralność danych jest wbudowana w model na poziomie pola, aby zapewnić dokładność danych; na poziomie tabeli, by upewnić się, że rekordy nie są duplikowane oraz by wykryć brakujące wartości klucza głównego; na poziomie zależności, by upewnić się, że zależność pomiędzy dwiema tabelami jest ważna; na poziomie firmy, by przekonać się, że dane są dokładne w sensie biznesowym. Temat integralności będzie poruszany w miarę omawiania procesu projektowego. (cid:132) Logiczna i fizyczna niezależność danych od aplikacji baz danych. Ani zmiany poczynione przez użytkownika na poziomie logicznego projektu bazy danych, ani też zmiany oprogramowania wprowadzane przez producenta na poziomie fizycznej implementacji nie wpłyną niekorzystnie na aplikacje zbudowane w oparciu o bazę danych. (cid:132) Gwarantowana konsekwencja i dokładność danych. Dane są podawane konsekwentnie i dokładnie dzięki wielu poziomom integralności, które możesz narzucić bazie danych. Ten temat stanie się jasny w miarę omawiania procesu projektowego. (cid:132) Łatwe pozyskiwanie danych. Dane mogą być pozyskane z konkretnej tabeli lub z dowolnej liczby tabel powiązanych w bazie danych przy wykorzystaniu komend użytkownika. To pomaga użytkownikowi przeglądać informacje na wiele różnych sposobów. Kup książkęPoleć książkę Zarz(cid:230)dzanie relacyjn(cid:230) baz(cid:230) danych 45 Te i inne zalety okazały się korzystne dla środowiska biznesowego oraz dla tych wszystkich, którzy zbierają dane i zarządzają nimi. W wielu przypadkach relacyjna baza danych stała się pożądanym wyborem. Główną wadą relacyjnych baz danych jest to, że bazujące na nich oprogramowanie działa bardzo wolno. Nie jest to wina samego modelu relacyjnego, lecz dostępności technologii pomocniczych w momencie wprowadzania modelu. Szybkość przetwarzania, pamięć oraz pojemność były po prostu niewystarczające, by zapewnić producentom oprogramowania do tworzenia baz danych platformę, na której mogliby zbudować pełną implementację relacyjnej bazy danych. Z tego powodu pierwsze programy do tworzenia relacyjnych baz danych nie pozwalały na rozwinięcie ich pełnego potencjału. Postępy zarówno w technologii tworzenia oprogramowania, jak i sprzętu sprawiły, że w ciągu ostatnich 20 lat prędkość przetwarzania przestała mieć znaczenie, a producenci zdołali wygenerować zyski poprzez swe działania służące lepszemu wsparciu modelu. Więcej na temat modelu relacyjnych baz danych dowiesz się z dalszej części tej książki. Niektóre z poruszonych tematów będą dotyczyły tworzenia tabel, ustalania integralności danych, pracy z zależnościami i ustalania reguł biznesowych. Zarz(cid:230)dzanie relacyjn(cid:230) baz(cid:230) danych System zarządzania relacyjną bazą danych (SZRBD) jest aplikacją wykorzystywaną do tworzenia, utrzymywania i modyfikacji relacyjnej bazy danych oraz do manipulacji nią. Wiele system SZRBD zapewnia także narzędzia niezbędne do tworzenia aplikacji dla użytkownika, które wchodzą w interakcje z danymi przechowywanymi w bazie danych. Oczywiście jakość SZRBD zależy od tego, w jakim stopniu wspiera on model relacyjnych baz danych. Nawet w przypadku „prawdziwych” systemów SZRBD poziom wsparcia dla relacyjnych baz danych różni się w zależności od producenta, a nikt jeszcze nie wykorzystał pełnego potencjału tego modelu. Bez względu na to wszystkie systemy SZRBD ewoluują i stają się coraz potężniejsze. Początkowo systemy SZRBD były przeznaczone do użytku na komputerach mainframe (czy nie wszystkie programy tak zaczynały?). Dwoma najbardziej rozpowszechnionymi systemami SZRBD we wczesnych latach 70. były System R, stworzony przez IBM w San Jose Research Laboratory w Kalifornii, oraz Interactive Graphics Retrieval System (INGRES), stworzony na Uniwersytecie Kalifornijskim w Berkeley. Te dwa programy znacząco przyczyniły się do powszechnego zrozumienia wartości modelu relacyjnych baz danych. Kiedy z czasem korzyści wynikające z używania relacyjnych baz danych stały się bardziej oczywiste, wiele firm zdecydowało się na ostrożną wymianę hierarchicznych i sieciowych modeli baz danych na relacyjne, tworząc w ten sposób zapotrzebowanie na lepsze systemy SZRBD dla komputerów mainframe. W latach 80. dla tych komputerów komercyjne oprogramowanie zaczęły produkować firmy takie jak Oracle i IBM. Na początku i w połowie lat 80. nastąpił znaczny wzrost użytkowania komputerów osobistych, a wraz z tym rozwój systemów SZRBD dla tych komputerów. Pierwsze próby Kup książkęPoleć książkę 46 Rozdzia(cid:273) 1. Relacyjna baza danych w tej kategorii, podejmowane między innymi przez Ashton-Tate oraz Fox Software, nie różniły się niczym od prostego systemu zarządzania bazą danych opartego na plikach. Prawdziwe systemy SZRBD dla komputerów PC zaczęły dopiero produkować firmy takie jak Microrim oraz Ansa Software. Te firmy rozpowszechniły ideę oraz potencjał zarządzania bazami danych i pomogły im przejść ze zdominowanych przez komputery mainframe działów zarządzania informacjami do komputerów na biurkach zwykłych użytkowników. Potrzeba dzielenia się danymi stawała się oczywista, w miarę jak coraz większa liczba użytkowników rozpoczynała pracę z bazami danych na przełomie lat 80. i 90. Koncepcja centralnie zlokalizowanej bazy danych, która mogła być dostępna dla wielu użytkowników, wydawała się bardzo obiecującym pomysłem. Mogło to znacznie uprościć zarządzanie danymi oraz zapewnienie bezpieczeństwa całej bazie. Producenci baz danych, tacy jak Microsoft i Oracle, odpowiedzieli na te potrzeby, wytwarzając systemy SZRBD typu klient-serwer. W środowisku klient-serwer dane przechowywane są w komputerze, który pełni rolę serwera bazy danych, a użytkownicy wchodzą w interakcje z danymi poprzez aplikacje umieszczone w ich własnych komputerach, czyli klientach bazy danych. Programiści baz danych wykorzystują systemy SZRBD do stworzenia i utrzymania bazy danych oraz towarzyszących im aplikacji użytkownika. Integralność danych oraz ich bezpieczeństwo zapewniane są na serwerze, co pozwala na uzyskanie dostępu do tego samego zestawu danych wielu różnym aplikacjom użytkownika, bez wpływu na integralność oraz bezpieczeństwo tych danych. Poza modelem relacyjnym Mimo że systemy SZRBD są powszechnie wykorzystywane w typowych aplikacjach biznesowych, takich jak kontrola inwentaryzacyjna, zarządzanie pacjentami, usługi bankowe, przetwarzanie zamówień oraz planowanie wydarzeń, nie sprawdziły się one w przypadku aplikacji typu CAD (ang. computer-aided design, projektowanie wspomagane komputerowo), GIS (ang. geographic information system, system informacji przestrzennej) oraz systemów przechowywania multimediów. Odpowiedzią na ten problem było pojawienie się dwóch nowych modeli baz danych: obiektowych oraz obiektowo-relacyjnych. Model obiektowy zawiera wszystkie cechy charakterystyczne dla obiektowego języka programowania i degraduje relacyjną bazę danych do statusu magazynu danych. Podstawowym założeniem jest tutaj to, że programista bazy danych zajmuje się każdym jej aspektem, także operacjami mającymi na celu manipulację danymi z poziomu oprogramowania obiektowej bazy danych. Nie istnieje już jasny podział na oprogramowanie bazy danych i aplikację. Tak jak w przypadku każdego innego modelu to podejście ma swoje wady i zalety. Versant Corporation i IBM to dwaj producenci wytwarzający oprogramowanie obiektowych baz danych. Kup książkęPoleć książkę Co niesie przysz(cid:273)o(
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Projektowanie baz danych dla każdego. Przewodnik krok po kroku
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: