Bazy Danych 2008 Część 1 Egzamin Pisemny



Podobne dokumenty
030 PROJEKTOWANIE BAZ DANYCH. Prof. dr hab. Marek Wisła

Technologia informacyjna

Bazy danych 1. Wykład 5 Metodologia projektowania baz danych. (projektowanie logiczne)

Definicja bazy danych TECHNOLOGIE BAZ DANYCH. System zarządzania bazą danych (SZBD) Oczekiwania wobec SZBD. Oczekiwania wobec SZBD c.d.

KaŜdemu atrybutowi A przyporządkowana jest dziedzina Dom(A), czyli zbiór dopuszczalnych wartości.

Bazy Danych. Modele danych. Krzysztof Regulski WIMiIP, KISiM,

Projektowanie Systemów Informacyjnych

Wykład 2. Relacyjny model danych

Wykład II Encja, atrybuty, klucze Związki encji. Opracowano na podstawie: Podstawowy Wykład z Systemów Baz Danych, J.D.Ullman, J.

Zasady transformacji modelu DOZ do projektu tabel bazy danych

Relacyjny model baz danych, model związków encji, normalizacje

PLAN WYKŁADU BAZY DANYCH ZALEŻNOŚCI FUNKCYJNE

Plan wykładu: Relacyjny model danych: opis modelu, podstawowe pojęcia, ograniczenia, więzy.

Pojęcie zależności funkcyjnej

W poniŝszej tabeli zestawiono charakterystyki poszczególnych postaci normalnych bazy.

Normalizacja baz danych

System zarządzania bazą danych SZBD (ang. DBMS -Database Management System)

Modelowanie danych, projektowanie systemu informatycznego

Systemy baz danych. mgr inż. Sylwia Glińska

Bazy danych. Andrzej Łachwa, UJ, /15

Krzysztof Kadowski. PL-E3579, PL-EA0312,

Podstawowe pojęcia dotyczące relacyjnych baz danych. mgr inż. Krzysztof Szałajko

Modelowanie związków encji. Oracle Designer: Diagramy związków encji. Encja (1)

Pierwsza postać normalna

Baza danych. Modele danych

Relacyjny model danych

1 Projektowanie systemu informatycznego

Diagramy związków encji. Laboratorium. Akademia Morska w Gdyni

Bazy danych i usługi sieciowe

Bazy danych. wprowadzenie teoretyczne. Piotr Prekurat 1

Cel normalizacji. Tadeusz Pankowski

Baza danych. Baza danych to:

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Modelowanie danych Diagramy ERD

WYKŁAD 1. Wprowadzenie do problematyki baz danych

KURS ACCESS 2003 Wiadomości wstępne

Uniwersytet Zielonogórski Instytut Sterowania i Systemów Informatycznych Bazy Danych - Projekt. Zasady przygotowania i oceny projektów

Zależności funkcyjne

Normalizacja. Pojęcie klucza. Cel normalizacji

Bazy Danych. Bazy Danych i SQL Podstawowe informacje o bazach danych. Krzysztof Regulski WIMiIP, KISiM,

BAZY DANYCH model związków encji. Opracował: dr inż. Piotr Suchomski

Bazy Danych i Usługi Sieciowe

Bazy danych w sterowaniu

Utwórz klucz podstawowy relacji na podstawie unikalnego identyfikatora encji. podstawie kluczy podstawowych wiązanych relacji.

Pożyczkobiorcy. Anomalia modyfikacji: Anomalia usuwania: Konta_pożyczkowe. Anomalia wstawiania: Przykłady anomalii. Pożyczki.

Związki pomiędzy tabelami

Pierwsza postać normalna

Program wykładu. zastosowanie w aplikacjach i PL/SQL;

BAZY DANYCH. Anomalie. Rozkład relacji i normalizacja. Wady redundancji

BAZY DANYCH NORMALIZACJA BAZ DANYCH. Microsoft Access. Adrian Horzyk. Akademia Górniczo-Hutnicza

PODSTAWY BAZ DANYCH. 5. Modelowanie danych. 2009/ Notatki do wykładu "Podstawy baz danych"

Systemy informatyczne. Modelowanie danych systemów informatycznych

Technologie baz danych

BAZY DANYCH model relacyjny. Opracował: dr inż. Piotr Suchomski

Księgarnia PWN: Michael J. Hernandez Bazy danych dla zwykłych śmiertelników

jest rozwiązaniem równania jednorodnego oraz dla pewnego to jest toŝsamościowo równe zeru.

Podstawowe pakiety komputerowe wykorzystywane w zarządzaniu przedsiębiorstwem. dr Jakub Boratyński. pok. A38

1 Przygotował: mgr inż. Maciej Lasota

Normalizacja relacji

Bazy danych. Zachodniopomorski Uniwersytet Technologiczny w Szczecinie. Wykład 3: Model związków encji.

K1A_W11, K1A_W18. Egzamin. wykonanie ćwiczenia lab., sprawdzian po zakończeniu ćwiczeń, egzamin, K1A_W11, K1A_W18 KARTA PRZEDMIOTU

BAZY DANYCH NORMALIZACJA BAZ DANYCH. Microsoft Access. Adrian Horzyk. Akademia Górniczo-Hutnicza

Diagramy związków encji ERD Ćwiczenia w modelowaniu danych

Bazy danych. Zasady konstrukcji baz danych

Transformacja modelu ER do modelu relacyjnego

Zaawansowane Modelowanie I Analiza Systemów Informatycznych

Jak wiernie odzwierciedlić świat i zachować występujące w nim zależności? Jak implementacja fizyczna zmienia model logiczny?

2017/2018 WGGiOS AGH. LibreOffice Base

Instytut Mechaniki i Inżynierii Obliczeniowej Wydział Mechaniczny technologiczny Politechnika Śląska

PROJEKT CZĘŚCIOWO FINANSOWANY PRZEZ UNIĘ EUROPEJSKĄ. Opis działania raportów w ClearQuest

Literatura. Bazy danych s.1-1

Wydział Elektroniki Politechniki Wrocławskiej. Kierunek: Informatyka Specjalność: InŜynieria Systemów Informatycznych

Model relacyjny. Wykład II

Pojęcie bazy danych. Funkcje i możliwości.

Bazy danych. Algebra relacji

Relacyjne bazy danych. Normalizacja i problem nadmierności danych.

Program nauczania. Systemy baz danych. technik informatyk

PLAN WYKŁADU BAZY DANYCH MODEL DANYCH. Relacyjny model danych Struktury danych Operacje Integralność danych Algebra relacyjna HISTORIA

Bazy danych 1. Wykład 4 Metodologia projektowania baz danych

Autor: Joanna Karwowska

Relacyjne Bazy Danych Andrzej M. Borzyszkowski. Projekt bazy danych normalizacja. PJATK/ Gdańsk. Dwie metodologie. Formalne zasady projektowe

1 Wstęp do modelu relacyjnego

Bazy danych. Andrzej Grzybowski. Instytut Fizyki, Uniwersytet Śląski

Algorytmy i struktury danych

Wykład I. Wprowadzenie do baz danych

Wykład 5 Charakterystyka języka SQL. Elementy obliczeń relacyjnych.

Teoretyczne podstawy informatyki

S y s t e m y. B a z D a n y c h

Teoretyczne podstawy informatyki

Normalizacja baz danych

Projektowanie relacyjnych baz danych

Bazy Danych. Bazy Danych i SQL Podstawowe informacje o bazach danych. Krzysztof Regulski WIMiIP, KISiM, regulski@metal.agh.edu.pl

Bazy danych. Plan wykładu. Diagramy ER. Podstawy modeli relacyjnych. Podstawy modeli relacyjnych. Podstawy modeli relacyjnych

Normalizacja Projektowanie Diagramy encji. Bazy Danych i Systemy informacyjne Wykład 7. Piotr Syga

WPROWADZENIE DO BAZ DANYCH

Informatyka Ćwiczenie 10. Bazy danych. Strukturę bazy danych można określić w formie jak na rysunku 1. atrybuty

Bazy Danych i Systemy informacyjne Wykład 7. Piotr Syga

CREATE TABLE pracownik (id int auto_increment primary key, adres char(100), dzial char(100), imie char(30), nazwisko char(50))

Bazy danych i usługi sieciowe

ZSE - Systemy baz danych 1 ZASADY PROJEKTOWANIA BAZ DANYCH

Bazy Danych. C. J. Date, Wprowadzenie do systemów baz danych, WNT - W-wa, (seria: Klasyka Informatyki), 2000

Transkrypt:

Bazy Danych 2008 Część Egzamin Pisemny. Zagadnienia związane z CDM a) Model danych SłuŜy do wyraŝania struktury danych, projektowanego lub istniejącego systemu. Przez strukturę rozumiemy typ danych, powiązania między danymi i ograniczenia nałoŝone na dane. Modele konceptualne Opisują dane za pomocą pojęć zrozumiałych dla uŝytkowników, z pominięciem szczegółów implementacyjnych. Modele fizyczne Opisują dane za pomocą pojęć zrozumiałych dla uŝytkowników z uwzględnieniem szczegółów implementacyjnych ( z punktu widzenia pamięci komputera). Inne typy modeli danych : hierarchiczne, sieciowe, relacyjne. b) Encja - Jest to obiekt, przedstawiający np. pojęcia abstrakcyjne, byty rzeczywiste. Posiada nazwę oraz cechy własności, czyli atrybuty. E Entity elationship ( Model związków encji) ED Diagram związków encji Encja Asocjacyjna Encja wtrącona. Atrybut jest funkcją przypisującą obiektowi wartości cechy ze zbioru dziedziny. Atrybut kluczowy - Jeden lub kilka, w których wartości w sposób jednoznaczny identyfikują kaŝdy obiekt w zbiorze obiektów c) Związki KaŜdy związek opisujemy poprzez: - arność związku (liczba obiektów) - nazwę związku - rolę, jaką pełni w związku - liczebność związku ( ) Uczestnictwo: - Obligatoryjne czyli obowiązkowe (mandatory musi), oznaczamy pionową kreską. - Opcjonalne czyli moŝe nie musi wystąpić w związku, oznaczamy pustym kołkiem.

d) Przykładowe zadania Treść : Firma zatrudnia wielu pracowników, a pracownik pracuje w jednej firmie. ozwiązanie: Pracownik nr_pracownika imie nazwisko Identifier_ pracuje Zatrudnienie zatrudnia regon nazwa liczb_pracownikow Identifier_ Firma Treść: KsiąŜka składa się z wielu rozdziałów. Jeden autor moŝe napisać wiele rozdziałów, ale jeden rozdział jest napisany tylko przez jednego autora. Pisarz moŝe być współautorem wielu ksiąŝek oraz jedna ksiąŝka jest napisana przez wielu współautorów. Autor moŝe robić korektę jednej, wielu lub Ŝadnej ksiąŝki, korektę do ksiąŝki robi jeden autor. ozwiązanie: Ksiazka cena rok_wydania Characters (50) Characters (50) Zawiera Przynaleznosc NaleŜy nr_rodzialu liczba_stron nr_rozdzialu ozdzial Jest pisany Pisanie ozdziału MoŜe napisać id_korekty rodzaj_korekty id_korekty Korekta Wprowadzanie Korekty Jest sporządzana MoŜe sporządzić nr_autora imie nazwisko nr_autora Autor

2. Zagadnienia związane z PDM a) PDM (fizyczny model danych) Porównanie PDM a CDM CDM Encje Atrybuty elacje Atrybut kluczowy PDM Tabele Kolumny eferencje Klucz główny (PK) Klucz obcy (FK) Klucz główny kolumna lub gruba kolumn których wartość jednoznacznie identyfikuje kaŝdy wiersz w tabeli. Klucz obcy kolumna lub gruba kolumn w tabeli która czerpie swoje wartości z tej samej dziedziny co klucz główny powiązany z nią w bazie danych. b) Związki do związek jednoznaczny. do wiele związek jednorodny. wiele do wiele jest to związek wieloznaczny. c) Przykład przejścia z CDM do PDM CDM cena rok_wydania Ksiazka Characters (50) Characters (50) nr_rodzialu liczba_stron nr_rozdzialu ozdzial elationship_2 elationship_3 Przynaleznosc id_przynaleznosc id_przynaleznosc PDM cena rok_wydania Ksiazka char(50) char(50) integer <pk> nr_rodzialu=nr_rodzialu nr_rodzialu liczba_stron ozdzial char(256) integer <pk> = Przynaleznosc nr_rodzialu id_przynaleznosc char(50) char(256) integer <pk,fk> <pk,fk2> <pk>

3. Zagadnienia związane z elacyjnym Modelem Danych a) elacja struktura danych w elacyjnym Modelu Danych gdzie: - wiersze to krotki - kolumny to atrybuty b) ZałoŜenia Codda: - KaŜda relacja ma jednoznaczną nazwę w Bazie Danych. - KaŜda kolumna ma jednoznaczną nazwę w relacji. - Wszystkie wartości w kolumnie muszą być tego samego typu. - Porządek kolumn i wierszy nie jest istotny. - KaŜdy wiersz w relacji musi być róŝny. - KaŜde pole leŝące na przecięciu kolumn i wierszy w relacji powinno zawierać wartość atomową, tzn. Ŝe zbiór wartości w jednym polu relacji nie jest dozwolony c) Normalizacja jest to proces przekształcania relacji do dogodnej dla systemu postaci, jest to proces zagnieŝdŝony to znaczy Ŝe relacja w wyŝszej postaci normalnej musi być w niŝszej postaci normalnej. Pierwsza Postać Normalna elacja jest w NF jeŝeli kaŝda wartość atrybutów w kaŝdej krotce tej relacji jest wartością elementarną. NF jest cechą kaŝdej relacji gdyŝ wymagania tej postaci są zawarte w definicji relacji. Druga Postać Normalna elacja jest w 2 NF jeŝeli jest w NF i kaŝdy atrybut nie kluczowy jest w pełni funkcjonalnie zaleŝny od klucza głównego. Trzecia Postać Normalna elacja jest w 3 NF jeŝeli jest w 2 NF i kaŝdy jej atrybut nie kluczowy jest bezpośrednio, a nie przechodnio zaleŝny od klucza głównego. ZaleŜność funkcjonalna atrybut B relacji jest funkcjonalnie zaleŝny od atrybutu A tej relacji jeŝeli kaŝdej wartości a atrybutu A odpowiada dokładnie jedna wartość b atrybutu B ( mówimy Ŝe a identyfikuje b) np. nr albumu nazwisko studenta. Pełna ZaleŜność funkcjonalna atrybut B relacji jest w pełni funkcjonalnie zaleŝny od Atrybutu A tej relacji (który moŝe być atrybutem złoŝonym) jeŝeli jest funkcjonalnie zaleŝny od Atrybutu A i nie jest zaleŝny od Ŝadnego podzbioru atrybutu A. ZaleŜność przechodnia niech ABC będą trzema rozłącznymi podzbiorami atrybutów w relacji. Atrybut C jest przechodnio funkcjonalnie zaleŝny od atrybutu A, jeŝeli atrybut C jest funkcjonalnie zaleŝny od atrybutu B, a atrybut B jest funkcjonalnie zaleŝy od atrybutu A. Natomiast atrybut A nie jest funkcjonalnie zaleŝny od B, atrybut B nie jest funkcjonalnie zaleŝy od C. JeŜeli: A B B C To nie prawda Ŝe B A lub Ŝe C B więc A wyznacza w sposób przechodni C.

Przykład: Przejść do 3NF, oraz wyznaczyć schematy relacji NF nr_faktury <PK> data nr_kotracheta nazwa_kotracheta adres_kotracheta nr_produktu<pk> cena_produktu opis_produktu liczba_sztuk_produktu wartosc_faktury 2NF nr_faktury <PK><FK> nr_produktu<pk><fk> data nr_faktury <PK> nr_kontracheta nazwa_kontracheta adres_kontracheta wartosc_faktury nr_produktu<pk> cena_produktu opis_produktu liczba_sztuk_produktu 3NF nr_faktury <PK><FK> nr_produktu<pk><fk> data nr_produktu<pk> cena_produktu opis_produktu liczba_sztuk_produktu nr_faktury <PK> nr_kotracheta<fk> wartosc_faktury nr_kontracheta<pk> nazwa_kontracheta adres_kontracheta Schematy relacji : FAKTUY(nr_faktury <PK> INTEGE, nr_kotracheta<fk> INTEGE, wartosc_faktury INTEGE) PODUKTY(nr_produktu<PK> INTEGE, cena_produktu INTEGE, opis_produktu CHAACTE liczba_sztuk_produktu INTEGE [255]) KONTACHECI(nr_kontracheta<PK> INTEGE, nazwa_kontracheta CHAACTE[50] adres_kontracheta CHAACTE [50]) ZLECENIA(nr_faktury <PK><FK> INTEGE, nr_produktu<pk><fk> INTEGE data DATE)

4. Badanie odwracalności Dane : schemat relacji: (A,...,A n ) ; zbiór zaleŝności funkcyjnych F; rozkład ρ(,..., k ) Wynik : stwierdzenie, czy ρ jest rozkładem odwracalnym. Metoda : ) Konstruujemy tablicę o n - kolumnach i k - wierszach; j - ta kolumna odpowiada atrybutowi A j, a i-ty wiersz odpowiada schematowi relacji i. Jeśli A j jest atrybutem i to na przecięciu i-tego wiersza i j-tej kolumny wstawiamy symbol a j. JeŜeli nie wstawiamy tam b ij. KaŜdą z zaleŝności X Y ze zbioru F rozwaŝamy wielokrotnie - dopóki w tablicy nie moŝna dokonać Ŝadnej zmiany. 2 ) Za kaŝdym razem, gdy rozwaŝamy X Y szukamy wierszy zgodnych we wszystkich kolumnach odpowiadającym atrybutom X. Jeśli znajdziemy dwa takie wiersze zrównujemy w nich symbole odpowiadające atrybutom Y (jeśli jednym jest a j to drugi staje się teŝ a j lub jeśli jednym jest b ij, a drugi b Lj to oba stają się arbitralnie równe, bądź b ij, bądź b Lj ). Gdy po zmodyfikowaniu wierszy tablicy odkryjemy, Ŝe jeden wiersz przybrał postać a,...,a n to rozkład jest odwracalny, jeŝeli nie to rozkład jest nieodwracalny. ozkładem schematu relacji ={A,...,A n }nazywamy układ ρ = (,..., k ) złoŝony z podzbiorów, takich Ŝe = 2... k. Jednym z motywów dokonywania rozkładów jest to, Ŝe moŝna wyeliminować : a) redundancję; b) potencjalną niespójność czyli anomalia przy aktualizacji; c) anomalia przy wyszukiwaniu (nie moŝna wstawiać tylko wartości - trzeba wypełnić całe pola); d) anomalia przy usuwaniu. Przykład : elacja = ABCDE; ZaleŜności: A C, C D, B C, DE C, CE A; elacje: = AD, 2 =AB, 3 =BE, 4 =CDE, 5 =AE. ) Budujemy macierz: a b 2 b 3 a 4 b 5 x 2 3 4 5 a a 2 b 23 b 24 b 25 x b 3 b 4 a 2 b 33 b 34 a 5 b 42 a 3 a 4 a 5 a b 52 b 53 b 54 a 5 x 2) Analiza relacji: A C: otrzymujemy: a b 2 b 3 a 4 b 5 2 3 4 a a 2 b 3 b 24 b 25 x b 3 b 4 a 2 b 33 b 34 a 5 x b 42 a 3 a 4 a 5 a b 52 b 3 b 54 a 5 5

3) Analiza relacji: B C: otrzymujemy: a b 2 b 3 a 4 b 5 x 2 a a 2 b 3 b 24 b 25 x 3 b 3 a 2 b 3 b 34 a 5 x 4 b 4 b 42 a 3 a 4 a 5 5 a b 52 b 3 b 54 a 5 x 4) Analiza relacji: C D: otrzymujemy: a b 2 b 3 a 4 b 5 2 a a 2 b 3 a 4 b 25 3 b 3 a 2 b 3 a 4 a 5 x 4 b 4 b 42 a 3 a 4 a 5 x 5 a b 52 b 3 a 4 a 5 x 5) Analiza relacji: DE C: otrzymujemy: a b 2 b 3 a 4 b 5 2 3 4 5 a a 2 b 3 a 4 b 25 b 3 a 2 a 3 a 4 a 5 x b 4 b 42 a 3 a 4 a 5 x a b 52 a 3 a 4 a 5 x 5) Analiza relacji: CE A: otrzymujemy: a b 2 b 3 a 4 b 5 2 3 4 5 a a 2 b 3 a 4 b 25 a a 2 a 3 a 4 a 5 a b 42 a 3 a 4 a 5 a b 52 a 3 a 4 a 5 Wiersz a..an znaleziony, relacja jest Odwracalna!

5. SQL

6. Suplement OLTP - Systemy do przetwarzania na bieŝąco ( systemy rezerwacji miejsc ). Integralność, szybkość i liczba przetwarzanych transmisji. Obiekt kompleksowy - obiekt zawierający co najmniej jeden atrybut, którego wartością jest wskazanie na inny obiekt. JeŜeli wskazany obiekt nie jest powiązany semantycznie z obiektem wskazującym, to wskazanie nazywamy wskazaniem słabym. Obiekt wskazany moŝe być równieŝ obiektem kompleksowym. Obiekty wskazywane przez obiekt kompleksowy mogą być grupowane za pomocą róŝnych konstruktorów np. zbioru, krotki lub listy. Konstruktory są ortagonalne do klas wiązanych obiektów. Jedynie w przypadku zbiorów jest wymagana jednorodność obiektów (grupowane obiekty muszą być wystąpieniami tej samej klasy). Warunek ten nie jest spełniony w klasycznych bazach danych, np. w relacyjnym modelu danych relacja składa się wyłącznie z krotek, a krotki zawierają wyłącznie wartości proste. System MIS - Systemy wspomagające zarządzanie, produkcje i efektywność. System musi dokonywać analizy danych, czas nie jest waŝny. Obiekt złoŝony - jest to szczególny obiekt kompleksowy, jest obiektem zawierającym co najmniej jedno wskazanie o semantyce kompozycji. Wskazanie takie modeluje związek fizycznego zawierania się encji w reprezentowanym fragmencie rzeczywistości. Obiekt wskazywany nazywamy obiektem - komponentem, a wskazanie - wskazaniem kompozycyjnym. Obiekt komponent moŝe być równieŝ obiektem złoŝonym. Obiekty powiązane wskazaniami kompozycyjnymi tworzą hierarchię nazywaną hierarchią kompozycji. W odróŝnieniu od wskazań słabych, wskazania kompozycyjne nie mogą tworzyć cykli, gdyŝ obiekt złoŝony nie moŝe być jednocześnie swoim komponentem.