質問 |
答え |
W modelu relacyjnym – tabela SŁOWNIKOWA pozwala na: kontrolę dopuszczalnych wartości "powiązanego z nią" atrybutu 学び始める
|
|
|
|
|
W modelu relacyjnym – tabela SŁOWNIKOWA pozwala na: przechowywanie wartości atrybutu o różniących się typach danych 学び始める
|
|
|
|
|
W modelu relacyjnym – tabela SŁOWNIKOWA pozwala na: ułatwia aktualizację dużych ilości jednakowych wartości danych 学び始める
|
|
|
|
|
W modelu relacyjnym – tabela SŁOWNIKOWA pozwala na: z reguły istotne zmniejszenie objętości bazy danych 学び始める
|
|
|
|
|
Dlaczego najczęściej obecnie używane bazy danych nazywamy bazami RELACYJNYMI? Bo związek pomiędzy dwoma lub większą ilością tabel jest implementacją pewnej relacji? 学び始める
|
|
|
|
|
Dlaczego najczęściej obecnie używane bazy danych nazywamy bazami RELACYJNYMI? Bo „formalnie” Tabele schematu bazy danych są Relacjami 学び始める
|
|
|
|
|
Dlaczego najczęściej obecnie używane bazy danych nazywamy bazami RELACYJNYMI? Bo dane można przechowywać wraz z ich związkami logicznymi, czyli relacjami 学び始める
|
|
|
|
|
Własności wymagane od atrybutów wchodzących w skład Klucza Głównego to: Wartości atrybutu MUSZĄ być typu liczbowego 学び始める
|
|
|
|
|
Własności wymagane od atrybutów wchodzących w skład Klucza Głównego to: Unikalna wartość atrybutu w całej tabeli 学び始める
|
|
|
|
|
Własności wymagane od atrybutów wchodzących w skład Klucza Głównego to: Nigdy po zapisie wartość nie będzie aktualizowana przez użytkowników 学び始める
|
|
|
|
|
Własności wymagane od atrybutów wchodzących w skład Klucza Głównego to: Zakaz przyjmowania wartości NULL 学び始める
|
|
|
|
|
tabela słownikowa musi mieć zdefiniowane minimum trzy atrybuty, a w tym przynajmniej jeden typu znakowego 学び始める
|
|
|
|
|
warunki integralności referencyjnej "pilnują" zdefiniowanego charakteru powiązań pomiędzy wierszami dwóch lub nawet tej samej tabeli 学び始める
|
|
|
|
|
w przypadku niespełniania przez tabele warunków kolejnych Form Normalnych jedyną metodą postępowania jest dekompozycja tych tabel 学び始める
|
|
|
|
|
trigger definiuje procedurę, której realizacja ma odpowiadać za utrzymanie spójności bazy danych nawet przy bardzo złożonych powiązaniach logicznych pomiędzy danymi 学び始める
|
|
|
|
|
proces Normalizacji to 8 etapów dobrze zdefiniowanych czynności doprowadzających do dobrego Schematu bez Anomalii 学び始める
|
|
|
|
|
w zasadzie ACID Izolacja transakcji dotyczy praktycznie tylko transakcji w systemach wielodostępnych 学び始める
|
|
|
|
|
ROLLBACK to polecenie wielokrotnego wykonania transakcji zdefiniowanej po tym poleceniu 学び始める
|
|
|
|
|
ważnym elementem realizacji transakcji przez SZBD jest zachowanie zasady Atomowości transakcji, czyli konieczność jej wykonania w całości 学び始める
|
|
|
|
|
realizacja przez SZBD protokołu 2PL (dwufazowego blokowania transakcji) ma za zadanie podniesienie bezpieczeństwa bazy danych przez podwójne sprawdzenie uprawnień użytkownika 学び始める
|
|
|
|
|
ciągu operacji zapisany w programie aplikacji może stanowić dla SZBD transakcję pod warunkiem, że zapis tych operacji w kodzie aplikacji zaczyna się od BEGIN TRANSACTION, a kończy poleceniem COMMIT 学び始める
|
|
|
|
|
realizacja związku logicznego n: m (wiele do wiele) pomiędzy danymi w dwóch tabelach wymaga w definicji Schematu BD powołania do życia dodatkowej tabeli tzw. łącznikowej 学び始める
|
|
|
|
|
CEL realizacji systemu opisuje zakres funkcjonalny przyszłego systemu BD 学び始める
|
|
|
|
|
Schemat Bazy Danych (w zakresie struktury danych) jest zawsze dokładnym odwzorowaniem (1:1 ) struktury danych opisanych w diagramie ERD 学び始める
|
|
|
|
|
model Konceptualny zawiera szczegółową koncepcję architektury i technik realizacji tworzonego systemu BD 学び始める
|
|
|
|
|
model Logiczny/Implementowalnyto projekt systemu uwzględniający możliwości realizacyjne przyszłego Systemu Zarządzania Bazą Danych 学び始める
|
|
|
|
|
moduł Pomiarów Eksploatacyjnych to najistotniejsze miejsce w SZBD z uwagi na kontrolę integralności bazy danych wynikającą z realizacji Triggerów 学び始める
|
|
|
|
|
podstawowymi danymi dla funkcji Autoryzacji SZBD są dane zawarte w Słowniku Bazy Danych (definicji "rozszerzonego" schematu bd) 学び始める
|
|
|
|
|
funkcjonalność Optymalizatora kosztowego to standardowa funkcja Manipulatora SZBD praktycznie identyczna dla wszystkich SZBD różnych producentów 学び始める
|
|
|
|
|
ważnym elementem realizacji funkcji Dostępności systemu bazy danych jest moduł odtwarzania zawartości bazy danych po awarii 学び始める
|
|
|
|
|
wykorzystywanie technik Mirroringu i Stripingu to standard w Macierzach Dyskowych typu RAID 学び始める
|
|
|
|
|
procedura zdefiniowana w triggerze, dla względów bezpieczeństwa, musi się zawsze wykonać przed zdarzeniem, które aktywuje wykonanie triggera 学び始める
|
|
|
|
|
ochrona danych bazy danych jest istotnym elementem bezpieczeństwa całego systemu 学び始める
|
|
|
|
|
warunki integralności referencyjnej "pilnują" zdefiniowanego charakteru powiązań pomiędzy wierszami dwóch lub nawet tej samej tabeli 学び始める
|
|
|
|
|
trigger definiuje procedurę, której realizacja odpowiada za utrzymanie spójności bazy danych nawet przy bardzo złożonych powiązaniach logicznych pomiędzy danymi 学び始める
|
|
|
|
|
procesy Autoryzacji dostępu do danych w bazie danych (ochronę danych przed nieupoważnionym dostępem) realizują procesy Aplikacji bazodanowych wykorzystując SQL 学び始める
|
|
|
|
|
związek 1:1 pozwala w prosty sposób uniknąć dużej ilości wartości NULL w tabeli 学び始める
|
|
|
|
|
na Klucz Obcy składają się takie same atrybuty jak Kluczu Głównym tabeli, na którą wskazuje Klucz Obcy 学び始める
|
|
|
|
|
tabela łącznikowa może spełniać rolę "łącznika" dla dwóch a nawet większej ilości tabel 学び始める
|
|
|
|
|
tabela łącznikowa zawiera jedynie atrybuty wchodzące w skład Kluczy Głównych tabel, dla których jest łącznikiem 学び始める
|
|
|
|
|
związek Unarny to związek pomiędzy danymi w trzech lub większej ilości tabel 学び始める
|
|
|
|
|
Możliwość definiowania tabel WIDOKÓW (tabel wirtualnych): Daje możliwość nadawania uprawnień na pewne podzbiory danych z tabel 学び始める
|
|
|
|
|
Możliwość definiowania tabel WIDOKÓW (tabel wirtualnych): Szczególnie obciąża SZBD w stosunku do definiowania takich tabel w aplikacji 学び始める
|
|
|
|
|
Możliwość definiowania tabel WIDOKÓW (tabel wirtualnych): Powoduje znaczne spowolnienie dostępu do tabel Widoków Zmaterializowanych 学び始める
|
|
|
|
|
Możliwość definiowania tabel WIDOKÓW (tabel wirtualnych): Ułatwia korzystanie z poziomu aplikacji z danych zgromadzonych w wielu tabelach 学び始める
|
|
|
|
|
w jednej bazie danych nie może być dwóch atrybutów o takich samych nazwach 学び始める
|
|
|
|
|
pojęcia Klucz Właściwy i Klucz Kandydujący logicznie oznaczają to samo 学び始める
|
|
|
|
|
definicja tabeli zawiera dane określające ilości jej kolumn oraz wierszy 学び始める
|
|
|
|
|
nie można aktualizować wartości atrybutów wchodzących w skład Klucza Głównego 学び始める
|
|
|
|
|
deklaracja NOT NULL przy dowolnym atrybucie tabeli oznacza, że w całej tabeli nie mogą się pojawić żadne wartości NULL 学び始める
|
|
|
|
|
w konwencji przyjętej na wykładzie SCHEMAT ++ to rozszerzenie definicji Schematu relacyjnej bazy danych upraszczające tworzenie aplikacji do tej bd 学び始める
|
|
|
|
|
istnienie w schemacie bazy danych dużej ilości definicji tabel typu Widoki (klasyczne) powoduje znaczący wzrost fizycznej przestrzeni dyskowej potrzebnej dla danych tych tabel 学び始める
|
|
|
|
|
istnienie w schemacie bazy danych definicji Tabel Widoków Zmaterializowanych powoduje możliwość korzystania przez użytkowników z danych, których wartość jest już nieaktualna 学び始める
|
|
|
|
|
Transact SQL to rozszerzenie języka SQL pozwalające na definiowanie nawet złożonych algorytmów "rozumianych" przez SZBD 学び始める
|
|
|
|
|
w tabelach będących Widokami (wirtualnymi) dodefiniowanie dla nich Indeksowania wybranych atrybutów wyraźnie przyspiesza proces wyszukiwania w tych tabelach (po tych atrybutach) 学び始める
|
|
|
|
|
Język Algebry Relacji to jeden z najważniejszych języków Deklaratywnych używany w systemach baz danych 学び始める
|
|
|
|
|
podstawą dla konstrukcji języka bd, Języka Algebry Relacji jest Teoria Mnogości "zajmująca" się operacjami na zbiorach 学び始める
|
|
|
|
|
operator Iloczynu Kartezjańskiego operując na dwóch tabelach tworzy tabelę wynikową o ilości wierszy większej niż suma ilości wierszy tabel będących argumentami tej operacji 学び始める
|
|
|
|
|
języki typu QBE (Query Bay Example) zawierają znaczne rozszerzenie możliwości zapytań do baz danych, w stosunku do języka SQL 学び始める
|
|
|
|
|
tabela będąca wynikiem operacji Rzutu (Projekcji) zawsze posiada tyle samo wierszy, ile posiadała tabela będąca argumentem tej operacji 学び始める
|
|
|
|
|
definicja tabeli zawiera dane określające ilości jej kolumn oraz wierszy 学び始める
|
|
|
|
|
w schemacie bazy danych nie mogą występować dwa atrybuty o takich samych nazwach 学び始める
|
|
|
|
|
klucz kandydujący (klucz potencjalny) to klucz zawierający minimalną liczbę kolumn unikatowo identyfikujących krotki relacji 学び始める
|
|
|
|
|
nie można aktualizować wartości atrybutów wchodzących w skład klucza głównego posiadającego właściwość IDENTITY 学び始める
|
|
|
|
|
deklaracja NOT NULL oznacza, że w całej tabeli nie mogą się pojawić wartości NULL 学び始める
|
|
|
|
|
warunki integralności referencyjnej "pilnują" zdefiniowanego charakteru powiązań pomiędzy wierszami dwóch tabel (lub nawet tej samej tabeli) 学び始める
|
|
|
|
|
procesy Autoryzacji dostępu do danych w bazie danych (ochronę danych przed nieupoważnionym dostępem) realizują procesy Aplikacji bazodanowych wykorzystując SQL 学び始める
|
|
|
|
|
dane w systemach baz danych to wyjątkowa część systemu, która musi być poddana szczególnym procedurom ich zabezpieczenia przed utratą 学び始める
|
|
|
|
|
umieszczenie warunków integralności dziedziny w Aplikacjach bazodanowych jest skutecznym środkiem dla zabezpieczenia spójności bazy danych nawet podczas jej rozwoju o nowe aplikacje 学び始める
|
|
|
|
|
trigger definiuje procedurę, której realizacja ma odpowiadać za utrzymanie spójności bazy danych nawet przy bardzo złożonych powiązaniach logicznych pomiędzy danymi 学び始める
|
|
|
|
|
W modelu relacyjnym – tabela SŁOWNIKOWA pozwala na: kontrolę dopuszczalnych wartości "powiązanego z nią" atrybutu 学び始める
|
|
|
|
|
W modelu relacyjnym – tabela SŁOWNIKOWA pozwala na: przechowywanie wartości atrybutu o różniących się typach danych 学び始める
|
|
|
|
|
W modelu relacyjnym – tabela SŁOWNIKOWA pozwala na: ułatwia aktualizację dużych ilości jednakowych wartości danych 学び始める
|
|
|
|
|
W modelu relacyjnym – tabela SŁOWNIKOWA pozwala na: z reguły istotne zmniejszenie objętości bazy danych 学び始める
|
|
|
|
|
Dlaczego najczęściej obecnie używane bazy danych nazywamy bazami RELACYJNYMI? Bo związek pomiędzy dwoma lub większą ilością tabel jest implementacją pewnej relacji? 学び始める
|
|
|
|
|
Dlaczego najczęściej obecnie używane bazy danych nazywamy bazami RELACYJNYMI? Bo „formalnie” Tabele schematu bazy danych są Relacjami 学び始める
|
|
|
|
|
Dlaczego najczęściej obecnie używane bazy danych nazywamy bazami RELACYJNYMI? Bo dane można przechowywać wraz z ich związkami logicznymi, czyli relacjami 学び始める
|
|
|
|
|
Własności wymagane od atrybutów wchodzących w skład Klucza Głównego to: Wartości atrybutu MUSZĄ być typu liczbowego 学び始める
|
|
|
|
|
Własności wymagane od atrybutów wchodzących w skład Klucza Głównego to: Unikalna wartość atrybutu w całej tabeli 学び始める
|
|
|
|
|
Własności wymagane od atrybutów wchodzących w skład Klucza Głównego to: Nigdy po zapisie wartość nie będzie aktualizowana przez użytkowników 学び始める
|
|
|
|
|
Własności wymagane od atrybutów wchodzących w skład Klucza Głównego to: Zakaz przyjmowania wartości NULL 学び始める
|
|
|
|
|
tabela słownikowa musi mieć zdefiniowane minimum trzy atrybuty, a w tym przynajmniej jeden typu znakowego 学び始める
|
|
|
|
|
warunki integralności referencyjnej "pilnują" zdefiniowanego charakteru powiązań pomiędzy wierszami dwóch lub nawet tej samej tabeli 学び始める
|
|
|
|
|
w przypadku niespełniania przez tabele warunków kolejnych Form Normalnych jedyną metodą postępowania jest dekompozycja tych tabel 学び始める
|
|
|
|
|
trigger definiuje procedurę, której realizacja ma odpowiadać za utrzymanie spójności bazy danych nawet przy bardzo złożonych powiązaniach logicznych pomiędzy danymi 学び始める
|
|
|
|
|
proces Normalizacji to 8 etapów dobrze zdefiniowanych czynności doprowadzających do dobrego Schematu bez Anomalii 学び始める
|
|
|
|
|
w zasadzie ACID Izolacja transakcji dotyczy praktycznie tylko transakcji w systemach wielodostępnych 学び始める
|
|
|
|
|
ROLLBACK to polecenie wielokrotnego wykonania transakcji zdefiniowanej po tym poleceniu 学び始める
|
|
|
|
|
ważnym elementem realizacji transakcji przez SZBD jest zachowanie zasady Atomowości transakcji, czyli konieczność jej wykonania w całości 学び始める
|
|
|
|
|
realizacja przez SZBD protokołu 2PL (dwufazowego blokowania transakcji) ma za zadanie podniesienie bezpieczeństwa bazy danych przez podwójne sprawdzenie uprawnień użytkownika 学び始める
|
|
|
|
|
ciągu operacji zapisany w programie aplikacji może stanowić dla SZBD transakcję pod warunkiem, że zapis tych operacji w kodzie aplikacji zaczyna się od BEGIN TRANSACTION, a kończy poleceniem COMMIT 学び始める
|
|
|
|
|
realizacja związku logicznego n: m (wiele do wiele) pomiędzy danymi w dwóch tabelach wymaga w definicji Schematu BD powołania do życia dodatkowej tabeli tzw. łącznikowej 学び始める
|
|
|
|
|
CEL realizacji systemu opisuje zakres funkcjonalny przyszłego systemu BD 学び始める
|
|
|
|
|
Schemat Bazy Danych (w zakresie struktury danych) jest zawsze dokładnym odwzorowaniem (1:1 ) struktury danych opisanych w diagramie ERD 学び始める
|
|
|
|
|
model Konceptualny zawiera szczegółową koncepcję architektury i technik realizacji tworzonego systemu BD 学び始める
|
|
|
|
|
model Logiczny/Implementowalny to projekt systemu uwzględniający możliwości realizacyjne przyszłego Systemu Zarządzania Bazą Danych 学び始める
|
|
|
|
|
moduł Pomiarów Eksploatacyjnych to najistotniejsze miejsce w SZBD z uwagi na kontrolę integralności bazy danych wynikającą z realizacji Triggerów 学び始める
|
|
|
|
|
podstawowymi danymi dla funkcji Autoryzacji SZBD są dane zawarte w Słowniku Bazy Danych (definicji "rozszerzonego" schematu bd) 学び始める
|
|
|
|
|
funkcjonalność Optymalizatora kosztowego to standardowa funkcja Manipulatora SZBD praktycznie identyczna dla wszystkich SZBD różnych producentów 学び始める
|
|
|
|
|
ważnym elementem realizacji funkcji Dostępności systemu bazy danych jest moduł odtwarzania zawartości bazy danych po awarii 学び始める
|
|
|
|
|
wykorzystywanie technik Mirroringu i Stripingu to standard w Macierzach Dyskowych typu RAID 学び始める
|
|
|
|
|
procedura zdefiniowana w triggerze, dla względów bezpieczeństwa, musi się zawsze wykonać przed zdarzeniem, które aktywuje wykonanie triggera 学び始める
|
|
|
|
|
ochrona danych bazy danych jest istotnym elementem bezpieczeństwa całego systemu 学び始める
|
|
|
|
|
warunki integralności referencyjnej "pilnują" zdefiniowanego charakteru powiązań pomiędzy wierszami dwóch lub nawet tej samej tabeli 学び始める
|
|
|
|
|
trigger definiuje procedurę, której realizacja odpowiada za utrzymanie spójności bazy danych nawet przy bardzo złożonych powiązaniach logicznych pomiędzy danymi 学び始める
|
|
|
|
|
procesy Autoryzacji dostępu do danych w bazie danych (ochronę danych przed nieupoważnionym dostępem) realizują procesy Aplikacji bazodanowych wykorzystując SQL 学び始める
|
|
|
|
|
związek 1:1 pozwala w prosty sposób uniknąć dużej ilości wartości NULL w tabeli 学び始める
|
|
|
|
|
na Klucz Obcy składają się takie same atrybuty jak Kluczu Głównym tabeli, na którą wskazuje Klucz Obcy 学び始める
|
|
|
|
|
tabela łącznikowa może spełniać rolę "łącznika" dla dwóch a nawet większej ilości tabel 学び始める
|
|
|
|
|
tabela łącznikowa zawiera jedynie atrybuty wchodzące w skład Kluczy Głównych tabel, dla których jest łącznikiem 学び始める
|
|
|
|
|
związek Unarny to związek pomiędzy danymi w trzech lub większej ilości tabel 学び始める
|
|
|
|
|
Możliwość definiowania tabel WIDOKÓW (tabel wirtualnych): Daje możliwość nadawania uprawnień na pewne podzbiory danych z tabel 学び始める
|
|
|
|
|
Możliwość definiowania tabel WIDOKÓW (tabel wirtualnych): Szczególnie obciąża SZBD w stosunku do definiowania takich tabel w aplikacji 学び始める
|
|
|
|
|
Możliwość definiowania tabel WIDOKÓW (tabel wirtualnych): Powoduje znaczne spowolnienie dostępu do tabel Widoków Zmaterializowanych 学び始める
|
|
|
|
|
Możliwość definiowania tabel WIDOKÓW (tabel wirtualnych): Ułatwia korzystanie z poziomu aplikacji z danych zgromadzonych w wielu tabelach 学び始める
|
|
|
|
|
w jednej bazie danych nie może być dwóch atrybutów o takich samych nazwach 学び始める
|
|
|
|
|
pojęcia Klucz Właściwy i Klucz Kandydujący logicznie oznaczają to samo 学び始める
|
|
|
|
|
definicja tabeli zawiera dane określające ilości jej kolumn oraz wierszy 学び始める
|
|
|
|
|
nie można aktualizować wartości atrybutów wchodzących w skład Klucza Głównego 学び始める
|
|
|
|
|
deklaracja NOT NULL przy dowolnym atrybucie tabeli oznacza, że w całej tabeli nie mogą się pojawić żadne wartości NULL 学び始める
|
|
|
|
|
w konwencji przyjętej na wykładzie SCHEMAT ++ to rozszerzenie definicji Schematu relacyjnej bazy danych upraszczające tworzenie aplikacji do tej bd 学び始める
|
|
|
|
|
istnienie w schemacie bazy danych dużej ilości definicji tabel typu Widoki (klasyczne) powoduje znaczący wzrost fizycznej przestrzeni dyskowej potrzebnej dla danych tych tabel 学び始める
|
|
|
|
|
istnienie w schemacie bazy danych definicji Tabel Widoków Zmaterializowanych powoduje możliwość korzystania przez użytkowników z danych, których wartość jest już nieaktualna 学び始める
|
|
|
|
|
Transact SQL to rozszerzenie języka SQL pozwalające na definiowanie nawet złożonych algorytmów "rozumianych" przez SZBD 学び始める
|
|
|
|
|
w tabelach będących Widokami (wirtualnymi) dodefiniowanie dla nich Indeksowania wybranych atrybutów wyraźnie przyspiesza proces wyszukiwania w tych tabelach (po tych atrybutach) 学び始める
|
|
|
|
|
Język Algebry Relacji to jeden z najważniejszych języków Deklaratywnych używany w systemach baz danych 学び始める
|
|
|
|
|
podstawą dla konstrukcji języka bd, Języka Algebry Relacji jest Teoria Mnogości "zajmująca" się operacjami na zbiorach 学び始める
|
|
|
|
|
operator Iloczynu Kartezjańskiego operując na dwóch tabelach tworzy tabelę wynikową o ilości wierszy większej niż suma ilości wierszy tabel będących argumentami tej operacji 学び始める
|
|
|
|
|
języki typu QBE (Query Bay Example) zawierają znaczne rozszerzenie możliwości zapytań do baz danych, w stosunku do języka SQL 学び始める
|
|
|
|
|
tabela będąca wynikiem operacji Rzutu (Projekcji) zawsze posiada tyle samo wierszy, ile posiadała tabela będąca argumentem tej operacji 学び始める
|
|
|
|
|
definicja tabeli zawiera dane określające ilości jej kolumn oraz wierszy 学び始める
|
|
|
|
|
w schemacie bazy danych nie mogą występować dwa atrybuty o takich samych nazwach 学び始める
|
|
|
|
|
klucz kandydujący (klucz potencjalny) to klucz zawierający minimalną liczbę kolumn unikatowo identyfikujących krotki relacji 学び始める
|
|
|
|
|
nie można aktualizować wartości atrybutów wchodzących w skład klucza głównego posiadającego właściwość IDENTITY 学び始める
|
|
|
|
|
deklaracja NOT NULL oznacza, że w całej tabeli nie mogą się pojawić wartości NULL 学び始める
|
|
|
|
|
warunki integralności referencyjnej "pilnują" zdefiniowanego charakteru powiązań pomiędzy wierszami dwóch tabel (lub nawet tej samej tabeli) 学び始める
|
|
|
|
|
procesy Autoryzacji dostępu do danych w bazie danych (ochronę danych przed nieupoważnionym dostępem) realizują procesy Aplikacji bazodanowych wykorzystując SQL 学び始める
|
|
|
|
|
dane w systemach baz danych to wyjątkowa część systemu, która musi być poddana szczególnym procedurom ich zabezpieczenia przed utratą 学び始める
|
|
|
|
|
umieszczenie warunków integralności dziedziny w Aplikacjach bazodanowych jest skutecznym środkiem dla zabezpieczenia spójności bazy danych nawet podczas jej rozwoju o nowe aplikacje 学び始める
|
|
|
|
|
trigger definiuje procedurę, której realizacja ma odpowiadać za utrzymanie spójności bazy danych nawet przy bardzo złożonych powiązaniach logicznych pomiędzy danymi 学び始める
|
|
|
|
|
dane w systemach baz danych to wyjątkowa część systemu, która musi być poddana szczególnym procedurom ich zabezpieczenia przed utratą 学び始める
|
|
|
|
|
warunki integralności referencyjnej "pilnują" zdefiniowanego charakteru powiązań pomiędzy wierszami dwóch tabel (lub nawet tej samej tabeli) 学び始める
|
|
|
|
|
trigger definiuje procedurę, której realizacja ma odpowiadać za utrzymanie spójności bazy danych nawet przy bardzo złożonych powiązaniach logicznych pomiędzy danymi 学び始める
|
|
|
|
|
procesy Autoryzacji dostępu do danych w bazie danych (ochronę danych przed nieupoważnionym dostępem) realizują procesy Aplikacji bazodanowych wykorzystując SQL 学び始める
|
|
|
|
|
umieszczenie warunków integralności dziedziny w Aplikacjach bazodanowych jest skutecznym środkiem dla zabezpieczenia spójności bazy danych nawet podczas jej rozwoju o nowe aplikacje 学び始める
|
|
|
|
|
Model Logiczny/Implementowany to projekt systemu uwzględniający możliwości realizacyjne przyszłego Systemu Zarządzania Bazą Danych 学び始める
|
|
|
|
|
Realizacja związku logicznego n: m (wiele do wiele) pomiędzy danymi w dwóch tabelach wymaga w definicji Schematu BD powołania do życia dodatkowej tabeli tzw. Łącznikowej 学び始める
|
|
|
|
|
Ważnym elementem realizacji funkcji Dostępności systemu bazy danych jest moduł odtwarzania zawartości bazy danych po awarii. 学び始める
|
|
|
|
|
Dobry schemat bazy danych to schemat wynikający z analizy danych w rzeczywistości a nie z funkcji jakie system będzie musiał realizować 学び始める
|
|
|
|
|
Klucz kandydujący (klucz potencjalny) to klucz zawierający minimalną liczbę kolumn unikatowo identyfikujących krotki relacji 学び始める
|
|
|
|
|
Dekompozycja tabeli to sposób na usunięcie anomalii jakie ona powoduje w schemacie 学び始める
|
|
|
|
|
Podstawą dla konstrukcji języka bd, Języka Algebry Relacji jest Teoria Mnogości "zajmująca"się operacjami na zbiorach 学び始める
|
|
|
|
|
W konwencji przyjętej na wykładzie SCHEMAT ++ to rozszerzenie definicji Schematu relacyjnej bazy danych upraszczające tworzenie aplikacji do tej bd 学び始める
|
|
|
|
|
Ochrona danych bazy danych jest istotnym elementem bezpieczeństwa całego systemu 学び始める
|
|
|
|
|
Procesy Autoryzacji dostępu do danych w bazie danych (ochronę danych przed nieupoważnionym dostępem) realizują procesy Aplikacji bazodanowych wykorzystując SQL 学び始める
|
|
|
|
|
W procesie Normalizacji, Zależności Nietrywialne pomiędzy atrybutami to takie które odwzorowują logikę zależności w odwzorowywanej rzeczywistości 学び始める
|
|
|
|
|
ważnym elementem realizacji transakcji przez SZBD jest zachowanie zasady Atomowości transakcji czyli konieczność jej wykonania w całości 学び始める
|
|
|
|
|
ciągu operacji zapisany w programie aplikacji może stanowić dla SZBD transakcję pod warunkiem, że zapis tych operacji w kodzie aplikacji zaczyna się od BEGIN TRANSACTION, a kończy poleceniem COMMIT 学び始める
|
|
|
|
|
SQL3 to jeden z najważniejszych standardów języka SQL uznany i ogłoszony przez ISO 学び始める
|
|
|
|
|
Podstawową dla konstrukcji bd, Języka Algebry Relacji jest Teoria Mnogości “zajmująca” się operacjami na zbiorach 学び始める
|
|
|
|
|
warunki integralności referencyjnej "pilnują" zdefiniowanego charakteru powiązań pomiędzy wierszami dwóch tabel (lub nawet tej samej tabeli) 学び始める
|
|
|
|
|
trigger definiuje procedurę, której realizacja ma odpowiadać za utrzymanie spójności bazy danych nawet przy bardzo złożonych powiązaniach logicznych pomiędzy danymi 学び始める
|
|
|
|
|
Indeksowanie zawartości tabel będących widokami zmaterializowanymi przyspiesza proces wyszukiwania w tych tabelach ale opóźnia procesy aktualizacji 学び始める
|
|
|
|
|
dane w systemach baz danych to wyjątkowa część systemu która musi być poddana szczególnym procedurom ich zabezpieczenia przed utratą 学び始める
|
|
|
|
|
Transact SQL to rozszerzenie języka SQL pozwalające na definiowanie nawet złożonych procedur już na etapie projektowania schematu bazy danych 学び始める
|
|
|
|
|
to nie Ch. Bachman ale E.F. Codd jest pomysłodawcą i twórcą relacyjnego logicznego modelu danych 学び始める
|
|
|
|
|
tabela łącznikowa może spełniać rolę „łącznika” dla dwóch a nawet większej ilości tabel 学び始める
|
|
|
|
|
w wielu przypadkach rozbicie tabeli na dwie ze związkiem 1:1 pozwala uniknąć przechowywania w tabeli dużej ilości wartości NULL 学び始める
|
|
|
|
|
w aplikacji użytkownika ciąg operacji może stanowić dla SZBD transakcję pod warunkiem że zapis tych operacji zaczyna się od BEGIN TRANSACTION a kończy poleceniem COMMIT 学び始める
|
|
|
|
|
transakcje realizowane przez SZBD muszą być realizowane w całości lub nie mogą pozostawić w danych bazy danych żadnego śladu ich częściowej realizacji 学び始める
|
|
|
|
|
moduł administracji SZBD dostarcza administratorowi systemu bd narzędzi umożliwiających aktualizację danych błędnie wprowadzonych przez użytkowników 学び始める
|
|
|
|
|
podstawą do konstrukcji języka bd języka algebry relacji jest teoria mnogości „zajmująca się” operacjami na zbiorach 学び始める
|
|
|
|
|
schemat bazy danych wynika nie tylko z analizy danych ale i procedur realizowanych w odwzorowywanej rzeczywistości 学び始める
|
|
|
|
|
dla projektanta schematu relacyjnej bd absolutnym wymogiem jest doprowadzenie tego tematu do 3 Formy Normalnej 学び始める
|
|
|
|
|
możliwość definiowania w związkach pomiędzy tabelami także różnych klas kasowania może upraszczać procedury aplikacji użytkowników 学び始める
|
|
|
|
|
istnienie w schemacie bazy danych definicji tabel widoków zmaterializowanych powoduje możliwość wystąpienia niespójności danych w tej bazie 学び始める
|
|
|
|
|
Odtwarzanie zawartości bazy danych po awarii to istotne wymaganie od podsystemu SZBD zapewniającego dostępność bd 学び始める
|
|
|
|
|
W schemacie bazy danych, w definicji żadnej tabeli nie mogą się powtórzyć atrybuty o tych samych nazwach 学び始める
|
|
|
|
|
od lat do największych dostawców systemów SZBD należą firmy takie jak Microsoft Oracle IBM 学び始める
|
|
|
|
|
system SQLLite przechowuje, jednoplikową” bazę danych w jednym pliku fizycznym co ułatwia przenoszalność tych danych a w tym realizację wersji systemu „in memory” 学び始める
|
|
|
|
|
definicja tabeli zawiera dane określające ilości jej kolumn oraz wierszy 学び始める
|
|
|
|
|
istnienie w schemacie bazy danych definicji Tabel Widoków Zmaterializowanych powoduje możliwość korzystania przez użytkowników z danych, których wartość jest już nieaktualna 学び始める
|
|
|
|
|
CEL realizacji systemu opisuje zakres funkcjonalny przyszłego systemu BD 学び始める
|
|
|
|
|
realizacja związku logicznego n: m (wiele do wiele) pomiędzy danymi w dwóch tabelach wymaga w definicji Schematu BD powołania do życia dodatkowej tabeli tzw. Łącznikowej 学び始める
|
|
|
|
|
warunki integralności referencyjnej "pilnują" zdefiniowanego charakteru powiązań pomiędzy wierszami dwóch lub nawet tej samej tabeli 学び始める
|
|
|
|
|
Możliwość definiowania tabel WIDOKÓW (tabel wirtualnych): Daje możliwość nadawania uprawnień na pewne podzbiory danych z tabel 学び始める
|
|
|
|
|
Możliwość definiowania tabel WIDOKÓW (tabel wirtualnych Ułatwia korzystanie z poziomu aplikacji z danych zgromadzonych w wielu tabelach 学び始める
|
|
|
|
|
Własności wymagane od atrybutów wchodzących w skład Klucza Głównego to: 1) Unikalna wartość atrybutu w całej tabeli 学び始める
|
|
|
|
|
Własności wymagane od atrybutów wchodzących w skład Klucza Głównego to Zakaz przyjmowania wartości NULL 学び始める
|
|
|
|
|
Dlaczego najczęściej obecnie używane bazy danych nazywamy bazami RELACYJNYMI? 1) Bo „formalnie” Tabele schematu bazy danych są Relacjami 学び始める
|
|
|
|
|
W modelu relacyjnym – tabela SŁOWNIKOWA pozwala na: 1) kontrolę dopuszczalnych wartości "powiązanego z nią" atrybutu 学び始める
|
|
|
|
|
Dekompozycja tabel to jedyna metoda postępowania w przypadku nie spełnienia przez tabelę warunków kolejnych Form Normalnych 学び始める
|
|
|
|
|
w procesie Normalizacji, Zależności Nietrywialne pomiędzy atrybutami to takie które odwzorowują logikę zależności w odwzorowywanej rzeczywistości 学び始める
|
|
|
|
|
proces Normalizacji to 8 etapów dobrze zdefiniowanych czynności doprowadzających do dobrego Schematu bez Anomalii 学び始める
|
|
|
|
|
absolutnym wymogiem jest doprowadzenie Schematu do 3 Formy Normalnej 学び始める
|
|
|
|
|
wymogiem 1. Formy Normalnej jest pozbycie się w tabelach Zależności wielowartościowych 学び始める
|
|
|
|
|
dobry schemat bazy danych to schemat wynikający z analizy danych w rzeczywistości a nie z funkcji jakie system będzie musiał realizować 学び始める
|
|
|
|
|
anomalia przy aktualizacji oraz anomalia wynikająca z redundancji danych w tabeli to praktycznie jedno i to samo 学び始める
|
|
|
|
|
dekompozycja tabeli to sposób na usunięcie anomalii jakie ona powoduje w schemacie 学び始める
|
|
|
|
|
tabela łącznikowa zawiera jedynie atrybuty wchodzące w skład Kluczy Głównych tabel, dla których jest łącznikiem 学び始める
|
|
|
|
|
tabela łącznikowa może spełniać rolę "łącznika" dla dwóch a nawet większej ilości tabel 学び始める
|
|
|
|
|
związek 1:1 pozwala w prosty sposób uniknąć dużej ilości wartości NULL w tabeli 学び始める
|
|
|
|
|
tabela łącznikowa zawiera jedynie atrybuty wchodzące w skład Kluczy Głównych tabel, dla których jest łącznikiem 学び始める
|
|
|
|
|
związek Unarny to związek pomiędzy danymi w trzech lub większej ilości tabel 学び始める
|
|
|
|
|
na Klucz Obcy składają się takie same atrybuty jak Kluczu Głównym tabeli na którą wskazuje Klucz Obcy 学び始める
|
|
|
|
|
Wykorzystywanie technik Mirroringu i Stripingu to standard w Macierzach Dyskowych typu RAID 学び始める
|
|
|
|
|
Podstawowymi danymi dla funkcji Autoryzacji SZBD są dane zawarte w Słowniku Bazy Danych (definicji "rozszerzonego" schematu bd) 学び始める
|
|
|
|
|
Nie można aktualizować wartości atrybutów wchodzących w skład klucza głównego posiadającego właściwość IDENTITY 学び始める
|
|
|
|
|
Na Klucz Obcy składają się takie same atrybuty jak Kluczu Głównym tabeli na którą wskazuje Klucz Obcy 学び始める
|
|
|
|
|
Związek 1:1 pozwala w prosty sposób uniknąć dużej ilości wartości NULL w tabeli 学び始める
|
|
|
|
|
W tabelach będących Widokami (wirtualnymi) dodefiniowanie dla nich Indeksowania wybranych atrybutów wyraźnie przyspiesza proces wyszukiwania w tych tabelach (po tych atrybutach) 学び始める
|
|
|
|
|
umieszczenie warunków integralności dziedziny w Aplikacjach bazodanowych jest skutecznym środkiem dla zabezpieczenia spójności bazy danych nawet podczas jej rozwoju o nowe aplikacje 学び始める
|
|
|
|
|
Na klucz obcy składają się takie atrybuty jak na kluczu Główny w tabeli na którą wskazuje ten klucz obcy 学び始める
|
|
|
|
|
Operator iloczynu kartezjańskiego tworzy tabelę wynikową o ilości wierszy większej niż suma ilości wierszy tabel będących argumentami tej operacji 学び始める
|
|
|
|
|
SQL2 to jeden z najważniejszych standardów języka SQL uznany i ogłoszony przez ISO (International Standard Organization) (SQL3) 学び始める
|
|
|
|
|
W przypadku nie spełniania przez tabelę warunków kolejnych form normalnych jedyną metodą postępowania jest ich dekompozycja 学び始める
|
|
|
|
|
Najnowsze wersje SZBD PostgreSQL oraz mySQL to systemy o podobnej funkcjonalności i udostępniane na licencji GPL (General Public License) 学び始める
|
|
|
|
|
deklaracja NOT NULL oznacza, że w całej tabeli nie mogą się pojawić wartości NULL 学び始める
|
|
|
|
|
deklaracja NOT NULL przy dowolnym atrybucie tabeli oznacza, że w całej tabeli nie mogą się pojawić żadne wartości NULL 学び始める
|
|
|
|
|
w przypadku niespełniania przez tabele warunków kolejnych Form Normalnych jedyną metodą postępowania jest dekompozycja tych tabel 学び始める
|
|
|
|
|