1 / 13

Modelowanie logiczne (dla relacyjnych SZBD)

Modelowanie logiczne (dla relacyjnych SZBD). Etapy procesu projektowania BD (przypomnienie). Określenie celów... Sprecyzowanie zakresu ... Modelowanie konceptualne (bez odniesienia do SZBD);

hanzila
Download Presentation

Modelowanie logiczne (dla relacyjnych SZBD)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Modelowanie logiczne(dla relacyjnych SZBD)

  2. Etapy procesu projektowania BD (przypomnienie) • Określenie celów... • Sprecyzowanie zakresu ... • Modelowanie • konceptualne (bez odniesienia do SZBD); • logiczne (dla SZBD konkretnego typu, np. relacyjnego lub obiektowego) – przedstawienie danych w postaci struktur dostępnych w SZBD. • fizyczne (dla konkretnego SZBD) – zdefiniowanie dziedzin, relacji, indeksów, perspektyw, użytkowników z uprawnieniami itp.

  3. Relacyjny SZBD – dostępne struktury • Relacja R=A1A2...Ak lub R(A1,A2,...,Ak) • Atrybuty proste A1,A2,...,Ak • Klucze relacji • Tożsamość atrybutów z różnych relacji (klucze obce) • Wymaganie wartości niepustej

  4. nrRej marka SAMOCHÓD rokPr Encja  relacja • Tworzymy relację dla zbioru encji SAMOCHÓD klucz: nrRej

  5. Atrybuty złożone, wielokrotne, wyliczane • Złożone – rozkładamy na proste lub łączymy w jeden; Adres(kod,miasto,ulica,dom,nr) encji Osoba w relacji Osoba jako: • (...,aKod,aMisto,aUlica,aDom,aNr,...) lub • (...,adres,...) • Wielokrotne – definiujemy kilka „kopii” atrybutu lub oddzielną relację; Tel[1..3] encji Osoba jako: • (...,tel1,tel2,tel3,...) w relacji Osoba lub • Telefon(<klucz relacji Osoba>,tel) • Wyliczane – nie umieszczamy ich w relacji;

  6. Związki • Dla związku Z pomiędzy encjami E(A1,A2,...Ar) i F(B1,B2,...,Bs) o atrybutach C1,C2,...,Ct możemy zdefiniować: • Relację EZF(A1,A2,...Ar, B1,B2,...,Bs, C1,C2,...,Ct) • Relacje EZ(A1,A2,...Ar,C1,C2,...,Ct,<klucz F>) i F(B1,B2,...,Bs) lub analogicznie FZ i E; • Relacje E(A1,A2,...Ar), F(B1,B2,...,Bs) i Z(<klucz E>, <klucz F>, C1,C2,...,Ct)

  7. Związki jednoznaczne EZF • Dla związków jednoznacznych może być odpowiednie każde z czterech rozwiązań w zależności od tego, na ile projekt pomaga unikać: wartości pustych i niepotrzebnych złączeń, np.: Osoba  jestDyrektorem  Dział; przedstawienie Osoba, Dział-jestDyrektorem powoduje powstanie niewielu wartości pustych (mało działów nie ma dyrektora) i pozwala uniknąć jednego złączenia w celu poszukiwania dyrektora działu. Złączenie dalej z relacją Osoba spowoduje powstanie wielu wartości pustych (wiele osób nie jest dyrektorami)

  8. Związki funkcyjne E – ZF • Przedstawienie w postaci relacji EZ i F jest często najbardziej odpowiednie; pozwala uniknąć wartości pustych, dodatkowych złączeń i redundancji, jak w przykładzie: Przedmiot->jestWykładanyPrzez->Pracownik • Przedstawienie w postaci odrębnych relacji E, Z i F, jest odpowiednie, gdy informacje są rzadko wykorzystywane łącznie i wiele encji z E nie pozostaje w związku Z: Student->maPromotora->Pracownik • Przedstawienie w postaci jednej relacji EZF naraża nas na redundancję i rodzi groźbę niespójności danych w przypadku modyfikacji: Samochód -> jestWłasnością->Osoba

  9. Związki wieloznaczne E – Z – F • Wymagają zazwyczaj przedstawienia w postaci trzech relacji: E, Z i F, np. Student – Zaliczył – Przedmiot • Połączenie związku (Z) z jedną lub obiema enacjami (E i/lub F) powoduje często redundancję, jak w przykładzie: Student-ocenaZPrzedmiotu,Przedmiot lub Student, Przedmiot-ocenaStudenta

  10. Związki – wymuszanie • Jeżeli związek E<-Z<-F zapiszemy jako E i FZ=(<atrybuty F>, <atrybuty Z>, <klucz E>), to wymuszenie związku zapisujemy jako zastrzeżenie wartości niepustej atrybutów <klucz E> w relacji FZ. OSOBA SAMOCH. ma

  11. Słabe zbiory encji E – ZF • E musimy przedstawić jako EZ lub EZF. Pierwsze rozwiązanie zazwyczaj pomaga uniknąć redundancji

  12. Związki hierarchiczne ISA • Dla E ISA E1,E2,...,Ek możliwe jest: • Stworzenie odrębnych relacji dla E, E1,E2,...,Ek. W relacjach E1,E2,...,Ek encja E jest reprezentowana przez swój klucz i jej wspólne atrybuty nie są powtarzane w E1,...,Ek. Rozwiązanie to może wymagać wielu złączeń i kontroli integralności danych z różnych relacji (w przypadku warunków Mandatory, Or) • Stworzenie jednej relacji obejmującej wszystkie atrybuty E i E1,...,Ek. Rozwiązanie to może prowadzić do powstawania wartości pustych (Optional,Or)

  13. Użytkownicy i perspektywy • Perspektywa użytkownika może być zbiorem relacji zdefiniowanych na bazie dostępnych relacji bazowych za pomocą operacji algebry relacji, tworzenia atrybutów wyliczanych itp. • Oceny (ImięNazwisko, Indeks, nazwaPrzedmiotu, Ocena) • Średnie (ImięNazwisko, Indeks, nazwaPrzedmiotu, Średnia)

More Related