[ Pobierz całość w formacie PDF ]
.Gwarantowany dostêpPoprzez u¿ycie kombinacji wartoœci klucza podstawowego, nazwy tabeli i nazwykolumny, musi istnieæ dostêp do dowolnej partii danychAccess przestrzega tej zasady poprzez u¿ycie kluczy g³Ã³wnych.Jeœli sam nieutworzysz w tabeli klucza g³Ã³wnego, Access za¿¹da, abyœ to zrobi³Zasada 3.Brakuj¹ce informacjeProgram musi obs³ugiwaæ wartoœci Null.Wartoœci te przedstawiaj¹ brakuj¹ce lubbezu¿yteczne informacjeAccess obs³uguje wartoœci Null dla brakuj¹cych informacji.Jednoczeœnie pozwalaunikn¹æ wprowadzania wartoœci Null poprzez u¿ycie pól wymaganych.Zasada 4.Katalog systemuOpis bazy danych lub „katalog” na poziomie logicznym jako wartoœcitabelaryczne.Jêzyk relacyjny (SQL) powinien móc dzia³aæ na projekcie bazydanych w taki sam sposób, w jaki dzia³a na danych przechowywanych w strukturzeKatalog ten umieszczony jest w aparacie bazy danych Microsoft Jet.Dostworzenia zapytania dotycz¹cego katalogu systemu mo¿esz u¿yæ obiektu ActiveData o nazwie OpenSchema (patrz rozdzia³ 5.„Jet 4.0 – silnik baz danychMicrosoft).SQL DDL daje Ci mo¿liwoœæ tworzenia tabel, indeksów itp.Tabela 3.1.Zasady relacyjne dr Codda (ci¹g dalszy)Zasada dr CoddaNazwa zasadyOpisKomentarz dotycz¹cy AccessaZasada 5.Kompletny jêzykProgram typu RDBMS musi obs³ugiwaæ jasno okreœlony jêzyk do operowania danymi(SQL), który w pe³ni obs³uguje definiowanie i operowanie danymi, okreœlaniewidoku, ograniczenia integralnoœci, ograniczenia transakcyjne i autoryzacjêAccess (Jet) w pe³ni obs³uguje SQL dla operowania danymi, okreœlania widoków(kwerendy wybieraj¹ce) i ograniczeñ integralnoœci (Okno Relacje i komendaUTWÓRZ OGRANICZENIE)Zasada 6.Uaktualnianie widokówWszystkie widoki mog¹ byæ systemowo uaktualnione.W prawdziwym programie typuRDBMS, wiêkszoœæ (ale nie wszystkie) widoków mo¿e byæ uaktualnianaAccess by³ pierwsz¹ baz¹ danych, umo¿liwiaj¹c¹ u¿ycie kwerend aktualizuj¹cychZasada 7.Ustawianie poziomu uaktualnieñProgram typu RDBMS musi nie tylko potrafiæ pobieraæ zestawy danych.Musi tak¿epotrafiæ wstawiaæ, aktualizowaæ i usuwaæ dane jako zestaw relacyjnyAccess spe³nia to wymaganie poprzez u¿ycie kwerend funkcjonalnychZasada 8.Fizyczna niezale¿noœæ danychDane i aplikacja musz¹ byæ od siebie fizycznie niezale¿ne.Odpowiedni programtypu RDBMS lub „optymalizator” powinny móc œledziæ fizyczne zmiany w danych.Przyk³adowo, aplikacje RDBMS nie powinny ulegaæ modyfikacji na skutek dodaniab¹dŸ usuniêcia z tabeli indeksuAccess umo¿liwia Ci modyfikowanie obiektów bazy danych, bez koniecznoœcidokonywania zmian w reszcie aplikacji.Jet zawiera tak¿e logiczny aparatprzechowywaniaZasada 9.Logiczna niezale¿noœæ danychGdy to tylko mo¿liwe, aplikacja powinna byæ niezale¿na od zmian dokonywanychw tabelach podstawowych.Przyk³adowo, gdy tabele s¹ ³¹czone w widok,nie powinny nastêpowaæ zmiany w kodzieGdy tworzysz w Accessie kwerendê, mo¿esz j¹ z ³atwoœci¹ po³¹czyæ z formularzemlub raportem, jakby to by³a tabelaZasada 10.Niezale¿noœæ integralnoœciIntegralnoœæ danych musi byæ definiowalna w jêzyku relacyjnym i przechowywanaw katalogu.Ograniczenia w integralnoœci danych mog¹ byæ wbudowane w aplikacjê,jednak¿e podejœcie to jest obce dla modelu relacyjnego.W modelu relacyjnymintegralnoœæ powinna byæ naturaln¹ cech¹ projektu bazy danych.Mimo i¿ Microsoft nie umieœci³ w dokumentacji informacji na tematprzechowywania integralnoœci przez aparat Jet, mo¿esz tworzyæ zasadyintegralnoœci poprzez SQL.Jet przechowuje te informacje w projekcie bazydanych jako czêœæ katalogu.Tabela 3.1.Zasady relacyjne dr Codda (ci¹g dalszy)Zasada dr CoddaNazwa zasadyOpisKomentarz dotycz¹cy AccessaZasada 11.Niezale¿noœæ podzia³uZdolnoœci programu typu RDBMS nie bêd¹ ograniczone dziêki umieszczeniu jegokomponentów w osobnych bazach danych.Poniewa¿ silnik Jet przechowuje swoje zasady integralnoœci danych na poziomieaparatu, pozosta³e jego komponenty nie maj¹ wp³ywu na zasady integralnoœci.Zasada 12
[ Pobierz całość w formacie PDF ]