Pierwsze dwa wykłady dotyczą podstaw, na których jest zbudowana wiedza o systemach zarządzania bazami danych. Pierwszy wykład jest poświęcony podstawom modelowania relacyjnego i podstawom języka zapytań SQL do baz danych.
W pierwszej części tego wykładu przypomnimy podstawową metodę tworzenia schematu bazy danych za pomocą diagramów związków encji. Jest ona dwustopniowa. W pierwszej fazie projektujemy model danych dla rozważanej dziedziny zastosowań nazywany diagramem związków encji. W drugiej fazie przekształcamy otrzymany model danych w schemat bazy danych.
Użyjemy innej notacji niż na wykładach z Relacyjnych baz danych czy Projektowania systemów informacyjnych, mianowicie tym razem ogólniejszej notacji Chena, za pomocą której można precyzyjniej określać właściwości semantyczne związków. Umożliwia ona w szczególności reprezentację związków więcej niż 2-argumentowych. Ponadto, związki w tej notacji mogą mieć atrybuty, tak jak encje. Argumentem związku może być też inny związek.
Specjalne oprogramowanie, nazywane narzędziami CASE - od ang. Computer Aided System Engineering, dostarcza narzędzi graficznych do projektowania i rysowania diagramów na ekranie komputera. Co więcej, często dostarcza narzędzi do automatycznego generowania schematu bazy danych w konkretnym systemie baz danych takim jak na przykład Oracle lub SQLServer. Rysowanie diagramów jest wspomagane w szczególności przez narzędzie CASE firmy Microsoft - programu Microsoft Visio, który jest dostępny dla studentów w ramach licencji MSDN.
Do realizacji zadań tego wykładu jest potrzebny albo sam program Microsoft Visio albo dowolny inny program umożliwiający rysowanie diagramów, nawet Microsoft Word.
Druga część tego wykładu jest poświęcona podstawom języka zapytań SQL dla relacyjnych i obiektowo-relacyjnych baz danych. Mianowicie, zostaną rozważone alternatywne dla języka SQL, ogólniejsze od niego notacje: algebra relacji, rachunek relacyjny i notacja graficzna QBE (QueryByExample).
Celem procesu projektowania schematu bazy danych jest:
Na ogół, zanim utworzy się bazę danych, należy dokonać analizy wymagań informacyjnych i przedstawia się je w postaci modelu danych nazywanego diagramem związków encji. Na tym diagramie abstrahuje się zarówno od typu systemu baz danych (jak np. sieciowy, hierarchiczny, relacyjny, obiektowo-relacyjny, obiektowy) jak i od szczegółów technicznych związanych z implementacją danych w wybranym, konkretnym systemie baz danych. Diagram związków encji powinien:
Reasumując, projektowanie bazy danych przechodzi przez trzy fazy:
1. Analizę wymagań – nie sformalizowany w pełni proces obejmujący rozmowy z grupami użytkowników, analizę aktualnie używanego środowiska operacyjnego, analizę jakie są oczekiwania jego zmiany, analizę dostępnych dokumentacji, raportów itd.
2. Tworzenie koncepcyjnego schematu bazy danych, inaczej mówiąc modelu danych obszaru aplikacji – opisu wysokiego poziomu danych, które mają być przechowywane w bazie danych łącznie z więzami spójności. Na tym etapie najczęściej używa się diagramów związków encji.
3. Projektowanie logicznego schematu bazy danych tj. projektowanie schematu bazy danych w terminach konkretnego systemu zarządzania bazą danych (ang. database management system, DBMS), w skrócie SZBD.
Omówimy pokrótce składniki diagramu związków encji, mianowicie kolejno: encje (ang. entity), atrybuty (ang. attribute) i związki (ang. relationship).
Encja jest to obiekt, coś co istnieje, co jest odróżnialne od innych, o czym informację trzeba znać lub przechowywać. Reprezentacją graficzną encji jest ramka (prostokąt). Zbiór instancji encji jest to kolekcja podobnych encji w sensie posiadania wspólnych atrybutów (chociaż nie wyklucza się, że mogą istnieć atrybuty, które posiada jedna instancja encja, a druga nie posiada - jak może być w przypadku zbioru encji tworzących hierarchię).
Atrybut jest to właściwość encji danego typu, reprezentowana pewną wartością np. liczbą całkowitą, liczbą rzeczywistą, napisem. Są następujące wskazania:
|
|
Rys. 1.1 Encja Pracownik łącznie z jej atrybutami. Każda instancja encji Pracownik posiada te atrybuty. Ale nie wyklucza się, że pewne instancje mogą mieć więcej atrybutów niż te wspólne. Powstawanie diagramu ilustruje prezentacja Flash.
Dziedzina atrybutu jest to zbiór możliwych wartości atrybutu.
Klucz (jednoznaczny identyfikator) jest to niepusty zbiór (być może jednoelementowy) atrybutów danej encji, których wartości jednoznacznie identyfikują każdą instancję tej encji. Jedna encja może mieć wiele kluczy. Jeden klucz jest wskazywany jako główny, pozostałe jako alternatywne. Klucz główny jest wyróżniany przez zapisanie nazwy atrybutu dużymi literami lub przez podkreślenie.
Związek - uporządkowana lista encji, poszczególne encje mogą występować wielokrotnie.
|
Na przykład:
|
Związek binarny - jest to związek dwuargumentowy.
|
Związek rekurencyjny jest to związek, w którym jedna z jego encji występuje więcej niż jeden raz jako argument związku.
|
Atrybut deskryptywny związku (ang. descriptive attribute) jest to atrybut, który opisuje związek (a nie encję). Związek musi być jednoznacznie identyfikowany przez tworzące go encje bez odwoływania się do jego atrybutów deskryptywnych.
|
Więzy kluczowe związku (ang. key constraints) miedzy listą encji i związkiem oznaczają, że dla każdego układu instancji encji istnieje co najwyżej jedna instancja związku zawierająca te instancje encji. Inaczej mówiąc, między zbiorami instancji encji jest określona funkcja częściowa. W szczególności, więzy kluczowe związku binarnego oznaczają, że jest to związek wiele do jeden czyli związek jednoznaczny. Gdy instancja związku binarnego jest funkcją częściową 1-1 mamy do czynienia ze związkiem jeden do jeden czyli związkiem jedno-jednoznacznym.
|
Więzy kluczowe na rysunku 1.5 można wypowiedzieć w następujący sposób:
|
Więzy kluczowe dotyczą zależności encji ze związkiem i dlatego można je stosować także dla związków więcej niż dwu argumentowych.
Więzy uczestnictwa encji w związku (ang. participation constraints) oznaczają, że dla każdej instancji encji istnieje instancja związku ją zawierająca.
|
Więzy uczestnictwa na rysunku 1.6 można wypowiedzieć w następujący sposób:
|
Więzy uczestnictwa dotyczą zależności encji ze związkiem i dlatego można je stosować także dla związków więcej niż dwu argumentowych.
Encja zależna (ang. weak entity) jest to encja, której atrybuty nie wystarczają do określenia jednoznacznie instancji encji, mianowicie potrzebna jest dodatkowo instancja jednego lub więcej związków pozwalających jednoznacznie zidentyfikować instancję encji. Inaczej mówiąc, encja jest zależna od związku lub związków albo, jeszcze inaczej, związek bądź związki identyfikują encję.
 |
Rys. 1.7 Zadanie jest tutaj encją zależną, ponieważ sama Nazwa zadania nie wystarcza do jego pełnej identyfikacji - potrzebny jest jeszcze co najmniej Pracownik, któremu zadanie zostaje zlecone. Mogą być dwa zadania o tej samej nazwie zlecone różnym pracownikom. Konieczne są zarówno więzy kluczowe jak i uczestnictwa. Kreska na linii związku oznacza fakt zależności encji od związku. Powstawanie diagramu ilustruje prezentacja Flash.
Hierarchia encji (klas) jest to zbiór encji i związków jedno-jednoznacznych tworzący hierarchię (przy odczytywaniu: w dół hierarchii są to związki specjalizacji; przy odczytywaniu w górę hierarchii są to związki generalizacji). Hierarchia encji jest tworzona przez wielokrotne użycie związku jedno-jednoznacznego jest będącego odpowiednio szczególnym przypadkiem lub uogólnieniem, w zależności od kolejności ustawienia encji.
|
Rys. 1.8 Związek w postaci hierarchii encji. Encja Pracownik stały jest szczególnym przypadkiem encji Pracownik, a encja Pracownik jest uogólnieniem encji Pracownik stały. Encja Pracownik jest nadencją, a encja Pracownik stały podencją. Powstawanie diagramu ilustruje prezentacja Flash.
W przypadku hierarchii mamy możliwość nałożenia dodatkowych więzów spójności:
Podencje mogą mieć swoje charakterystyczne atrybuty oraz związki nie dotyczące wszystkich instancji nadencji.
Do tej pory argumentami związków były albo encje albo atrybuty deskryptywne. Argumentem związku może też być inny związek.
Agregacja (ang. aggregation) oznacza sytuację, w której jeden związek jest argumentem innego związku.
|
Rys. 1.9 Agregacja: związek Zlecone jest argumentem związku Jest kontrolowane. Związek, który jest argumentem innego związku jest obejmowany prostokątem wraz ze swoimi argumentami. Powstawanie diagramu ilustruje prezentacja Flash.
Moglibyśmy zapytać, czy rzeczywiście związki więcej niż dwu-argumentowe są konieczne. Przykładem związku trzy-argumentowego, którego nie można zamienić na związki binarne powiązanych encji jest znany przykład reprezentowania relacji:
|
(*) "Dostawca D dostarcza części C dla projektu P" Relacja (*) nie wynika z trzech binarnych relacji:
|
Przy przejściu do związków binarnych zachodzi konieczność reprezentowania związku więcej niż dwu-argumentowego przez osobną encję i zbiór związków binarnych odpowiadających poszczególnym argumentom związku wielo-argumentowego.
Reasumując, notacja Chena dostarcza większych możliwości precyzyjniejszego modelowania pojęć semantycznych przy konstruowaniu modelu danych obszaru zastosowań niż notacje wykorzystujące tylko związki binarne między encjami. Natomiast notacje oparte na związkach binarnych (i często też jednoznacznych) są bliższe schematom rzeczywistych baz danych, w szczególności umożliwiają automatyczne generowanie schematu bazy danych. Stanowią więc krok pośredni między precyzyjniejszymi modelami semantycznymi dziedzin zastosowań a schematami baz danych.
Przy modelowaniu staramy się zawrzeć jak najwięcej więzów spójności danych
dziedziny aplikacyjnej w samych diagramach związków encji. Do dyspozycji mamy tu
w szczególności hierarchie (w tym więzy pokrycia i rozłączności) i agregacje.
Rozważymy po kolei wszystkie składowe diagramów związków encji i pokażemy jak je reprezentować w relacyjnej bazie danych.
1. Encja jest reprezentowana przez tabelę. Klucz główny encji staje się kluczem głównym tabeli. Na przykład, encja Pracownik jest reprezentowana przez tabelę Pracownicy:
|
CREATE TABLE Pracownicy( Pesel CHAR(11), Nazwisko CHAR(60), Stanowisko CHAR(20), PRIMARY KEY (Pesel)) |
a encja Departament przez tabelę Departamenty:
|
CREATE TABLE Departamenty( Id NUMBER(3), Nazwa CHAR(20), Budżet NUMBER(15,2), PRIMARY KEY (Id)) |
2. Jako ogólna zasada, każdy związek może być reprezentowany przez tabelę. Klucze główne encji wchodzących w skład związku stają się kluczami obcymi w tabeli reprezentującej związek a łącznie stają się kluczem głównym tworzonej tabeli. Na przykład, związek Pracuje w można reprezentować za pomocą tabeli Pracuje_w:
|
CREATE TABLE Pracuje_w( Pesel CHAR(11), Id NUMBER(3), PRIMARY KEY (Pesel, Id), FOREIGN KEY (Pesel) REFERENCES Pracownicy(Pesel), FOREIGN KEY (Id) REFERENCES Departamenty(Id) ) |
3. Związek posiadający więzy kluczowe z pewną, jedną encją może być reprezentowany w tabeli reprezentującej tę encję (po stronie wiele związku binarnego) przez klucze obce do tabel reprezentujących pozostałe encje (w związku binarnym przez klucz obcy tabeli reprezentującej encję po stronie jeden). Na przykład, związek jest kierownikiem można reprezentować, albo za pomocą osobnej tabeli, albo za pomocą klucza obcego w tabeli Departamenty reprezentującej encję Departament:
|
CREATE TABLE Departamenty( Id NUMBER(3), Nazwa CHAR(20), Budżet NUMBER(15,2), Kierownik CHAR(11), PRIMARY KEY (Id), FOREIGN KEY (Kierownik) REFERENCES Pracownicy(Pesel)) |
Przy założeniu, że związek Pracuje w jest związkiem kluczowym, w podobny sposób moglibyśmy reprezentować go w tabeli Pracownicy za pomocą klucza obcego do tabeli Departamenty, zamiast tworzyć dla niego osobną tabelę Pracuje_w.
4. Więzy uczestnictwa są reprezentowane przez więzy NOT NULL z opcją klucza obcego ON DELETE NO ACTION - przy czym w Oracle nie używa się żadnego słowa kluczowego. Na przykład, w tabeli Departamenty:
|
CREATE TABLE Departamenty( Id NUMBER(3), Nazwa CHAR(20), Budżet NUMBER(15,2), Kierownik CHAR(11) NOT NULL, PRIMARY KEY (Id), FOREIGN KEY (Kierownik) REFERENCES Pracownicy(Pesel)) |
5. Encja zależna i identyfikujące je związki są reprezentowane przez jedną tabelę, której klucz główny jest złożony i zawiera klucze obce do tabel reprezentujących encje wchodzące w skład identyfikujących związków oraz te klucze obce są zdefiniowane z opcją ON DELETE CASCADE. Na przykład w tabeli Zadania.
|
CREATE TABLE Zadania( Nazwa CHAR(50), Opis CHAR(2000), Budżet NUMBER(15,2), Pesel CHAR(11), Termin DATE, PRIMARY KEY (Nazwa, Pesel), FOREIGN KEY (Pesel) REFERENCES Pracownicy(Pesel) ON DELETE CASCADE) |
6. Najprościej hierarchia encji jest reprezentowana za pomocą osobnych tabel dla nadencji i podencji.
Ale wtedy w aplikacji bazodanowej możemy mieć do czynienia z dużą liczbą złączeń tych tabel. Aby uniknąć
złączeń możemy zastosować jedną z dwóch poniższych metod:
|
7. Agregacja. Ponieważ każdy związek jest reprezentowany przez pewną tabelę (posiadającą klucz główny), więc związek, którego argumentami są inne związki, reprezentujemy też przez tabelę na tych samych zasadach co poprzednio.
.
Oto przykład diagramu zawierającego zarówno atrybut wielowartościowy jak i złożony (i to atrybut wchodzący w skład klucza).
.
Językom zapytań do bazy danych stawia się cele, które nie dają się zrealizować
przez jeden system notacyjny - dlatego często używane są notacje
dedykowane do konkretnych celów. Wymagane jest więc, aby:
|
Język zapytań jest to język służący do formułowania zapytań do bazy danych. Językiem zapytań, który jest standardem w relacyjnej bazie danych (jak i w obiektowo-relacyjnej bazie danych), jest język SQL.
Podstaw teoretycznych dla relacyjnych języków zapytań dostarczają algebra relacji i rachunek relacyjny. Ich zrozumienie jest kluczem do zrozumienia konstrukcji języka SQL, twórczego rozwiązywania problemów konstrukcji zapytań i przetwarzania zapytań czyli ich optymalizacji.
W algebrze relacji zapytanie ma charakter operacyjny tj. wyrażenie algebry relacji specyfikuje ciąg operacji na relacjach wejściowych prowadzący do pożądanego wyniku będącego relacją wynikową. Sprowadzenie zapytania do postaci wyrażenia algebry relacji pomaga w przekształceniach prowadzących do optymalizacji zapytania.
W rachunku relacyjnym zapytanie ma charakter deklaratywny tj. wyrażenie rachunku relacyjnego specyfikuje co ma być otrzymane bez podawania w jaki sposób to osiągnąć. Sprowadzenie zapytania do wyrażenia rachunku relacyjnego określa jego formalną semantykę. W przypadku skomplikowanych problemów łatwiej jest sformułować zapytanie w rachunku relacyjnym niż od razu w języku SQL - dotyczy to w szczególności problemów, w których występują sformułowania typu: "istnieje ...." lub "dla każdego ...".
W notacji QBE zapytanie ma postać graficzną. Użycie QBE ułatwia użytkownikom formułowanie zapytań do bazy danych.
Alternatywne sposoby reprezentacji zapytań dają możliwość obejrzenia ich z innej strony niż tylko postać SQL i w ten sposób głębiej je zrozumieć.
Dziedziną algebry jest zbiór możliwych relacji nad przyjętymi skończonymi dziedzinami. Tabela 1.1 pokazuje podstawowe operatory algebry relacji.
| Operator | Symbol |
| Selekcja |  |
| Projekcja |  |
| Złączenie |  |
| Suma |  |
Tab. 1.1 Oznaczenia symboliczne głównych operatorów relacyjnych.
Operatory relacyjne mając na wejściu argumenty będące relacjami przekształcają je w relację wynikową.
Oto ich semantyka razem z przykładami.
1. Selekcja - wybór wierszy spełniających określony warunek. Na przykład, wyrażenie algebry relacji:
|
oznacza zastosowanie operatora selekcji z warunkiem "Sal > 1000" do relacji Emp. Wyrażenie to jest równoważne następującej instrukcji SQL:
| SELECT * FROM Emp WHERE Emp.Sal>1000 |
2. Projekcja (rzut) - wybór określonych kolumn w relacji. Na przykład, wyrażenie algebry relacji:
|
oznacza zastosowanie operatora projekcji do kolumn Ename i Sal
w relacji
Emp. Wyrażenie to jest równoważne instrukcji SQL:
| SELECT Ename, Sal FROM Emp |
3. Złączenie - złączenie wierszy dwóch relacji względem wspólnych kolumn. Na przykład, wyrażenie algebry relacji:
|
oznacza zastosowanie operatora złączenia do relacji Emp i Dept. Wyrażenie to
jest równoważne instrukcji SQL:
| SELECT * FROM Emp, Dept WHERE Emp.Deptno=Dept.Deptno |
co jest także równoważne:
| SELECT * FROM Emp NATURAL JOIN Dept |
4. Suma - suma teoriomnogościowa dwóch relacji o tym samym schemacie. Na przykład, wyrażenie algebry relacji:
|
oznacza zastosowanie operatora sumy teoriomnogościowej do relacji R1 i
R2.
Odpowiednio dobierając R1 i R2 otrzymujemy instrukcję SQL:
| (SELECT Emp.Deptno FROM Emp) UNION (SELECT Dept.Deptno FROM Dept) |
Najważniejszą zaletą wyrażeń algebry relacji jest ich elastyczność składania, co w przypadku instrukcji SQL nie zawsze jest oczywiste i nie zawsze możliwe. Na przykład, wyrażenie algebry relacji:
 |
jest równoważne instrukcji SQL:
| SELECT Emp.Ename, Dept.Dname FROM Emp, Dept WHERE Emp.Deptno=Dept.Deptno AND Emp.Sal>1000 |
co jest także równoważne:
| SELECT Emp.Ename, Dept.Dname FROM Emp NATURAL JOIN Dept WHERE Emp.Sal>1000 |
W przypadku gdy zależy nam na przekształcaniu wyrażeń w celu optymalizacji wykonania zapytania, znacznie wygodniej jest to robić na poziomie wyrażeń algebry relacji a nie dokonując przekształceń samej instrukcji SQL.
Rozważane są także inne operacje w algebrze relacji jak:
przecięcie,
różnica,
iloczyn kartezjański (iloczyn krzyżowy),
zmiana nazwy pola.
Reasumując, samo zapytanie SQL ma charakter deklaratywny. Jest ono przez optymalizator przekształcane do wyrażenia algebry relacji, które łatwo jest następnie przekształcać na gruncie algebry relacji i które ma charakter operacyjny - to jest, z którego już łatwo otrzymać zoptymalizowany plan wykonania zapytania. Wyrażenia algebry relacji, tak jak każde inne wyrażenia np. wyrażenia arytmetyczne, wyrażenia XML, są często przedstawiane w postaci drzewa.
W rachunku relacyjnym zapytanie jest formułą logiki matematycznej. Kwantyfikatory, odpowiednio egzystencjalny i ogólny, zapisujemy za pomocą słów kluczowych Exists i All. Są dwie wersje rachunku relacyjnego:
Przykład
Instrukcję SQL:
| SELECT Emp.Ename, Dept.Dname FROM Emp, Dept WHERE Emp.Deptno=Dept.Deptno AND Emp.Sal>1000 |
zapisujemy w rachunku dziedzinowym jako:
P(Ename, Dname) iff (Exists Empno, Sal, Job, Deptno (Exists Loc ((Deptno, Dname, Loc) in Dept and (Empno, Ename, Sal, Job, Deptno) in Emp and Sal > 1000)))
a w rachunku krotkowym jako:
p in P(Ename, Dname) iff (Exists e in Emp (Exists d in Dept (((p.Ename=e.Ename and p.Dname=d.Dname) and e.Deptno=d.Deptno ) and e.Sal > 1000)))
W ten sposób każdej instrukcji SQL można podać jej definicję formalną w postaci formuły logicznej, czyli zdefiniować formalną semantykę.
Jest pewien problem związany z formułami logicznymi. Wyrażenia algebry relacji nie wyprowadzają poza zakres skończonych relacji (o ile nie wprowadzimy operatora dopełnienia relacji). Natomiast, formuły rachunku relacyjnego mogą wyprowadzić poza zakres skończonych relacji, z powodu negacji – uzupełnienia zbioru, jak to jest w przypadku relacji:
p in NotEmp iff not (p in Emp)
Konieczne jest ograniczenie rozważanych formuł do tzw. formuł bezpiecznych – określających zawsze skończone relacje. Wówczas rachunki relacyjne i algebra relacyjna są wzajemnie równoważne a także równoważne, jeśli chodzi o ekspresywność, językowi SQL.
QBE jest to graficzny, formularzowy język tworzenia instrukcji SQL. Wersja tego języka jest używana w MS Access.
Na przykład, w MS Access zapytanie:
| Wyznacz nazwisko klienta, nazwę kupionego przez niego produktu oraz cenę tego produktu przy czym weź pod uwagę tylko produkty których cena jest większa niż 1000. |
można sformułować w postaci graficznej przedstawionej na rysunku 1.10.
|
Rys. 1.10 Zapytanie w postaci graficznej QBE.
Użytkownik wybiera tabele, a następnie przeciąga interesujące go pola do kolumny siatki zapytania, jednocześnie określając ograniczenia na wartości poszczególnych pól. Złączenia tabel są realizowane automatycznie przez system na podstawie związków zdefiniowanych przy tworzeniu schematu bazy danych.
| Inne rodzaje baz danych różne od relacyjnych, nie mają takich podstaw teoretycznych jak algebra relacji czy rachunek relacyjny. Na gruncie teorii postuluje się aby każdy rodzaj baz danych posiadał zarówno model zapytań umożliwiający elastyczne przekształcanie zapytań w celu ich optymalizacji a także model umożliwiający formalne zdefiniowanie ich semantyki. Te modele niekoniecznie muszą być oparte na języku matematyki. Ponadto, powinien istnieć równoważny model graficzny formułowania zapytania przez użytkownika. |
Przypomnieliśmy modelowanie relacyjne na przykładzie bardzo ogólnej notacji graficznej Chena, która wnika głębiej niż powszechnie używane notacje definiowania modeli danych oparte na związkach binarnych.
W drugiej części przedstawiliśmy alternatywne sposoby formułowania zapytań SQL, które uwypuklają pewne podstawowe aspekty zapytań, mianowicie związki z algebrą, rachunkiem kwantyfikatorów i reprezentacjami graficznymi.
diagram związków encji- model danych dziedziny aplikacyjnej używający notacji encji, atrybutów i związków.
więzy kluczowe - miedzy encją i związkiem oznaczają, że dla każdej instancji encji istnieje co najwyżej jedna instancja związku zawierająca tę instancję encji.
więzy uczestnictwa - oznaczają, że dla każdej instancji encji istnieje instancja związku ją zawierająca.
hierarchia encji - jest to zbiór encji i związków jedno-jednoznacznych tworzący hierarchię.
agregacja - związek, którego jednym z argumentów jest inny związek.
logiczny schemat bazy danych - model danych dziedziny aplikacyjnej wyrażony w języku konkretnej bazy danych.
algebra relacji - notacja zapisu zapytań do relacyjnej bazy danych, która ma charakter operacyjny i która jest używana przy optymalizacji zapytań.
rachunek relacyjny - notacja zapisu zapytań do relacyjnej bazy danych, która ma charakter deklaratywny i która jest używana do określania formalnej semantyki zapytań.
QBE - notacja graficznego zapisu zapytań ułatwiająca układanie zapytań.
|
1. Zastanów się nad reprezentacją diagramów na tym wykładzie w Twoich ulubionych notacjach np. w notacjach wprowadzonych na wykładach Relacyjne bazy danych i Projektowanie systemów informacyjnych (UML).
2. Zapisz reprezantację encji Pracownik i Departament oraz związków Pracuje w, jest kierownikiem departamentu, jest kierownikiem pracownika za pomocą dwóch tabel Pracownicy i Departamenty. Przyjmij założenie, że zachodzą więzy kluczowe dla wszystkich trzy związków, a więzy uczestnictwa dla pierwszych dwóch z nich.
3. Czy potrafisz wskazać przykład diagramu zawierającą agregację dwóch związków i połączenie związkiem tych agregacji.
4. Jak reprezentować w relacyjnej bazie danych atrybuty wielowartościowe i złożone?
5. Zapisz następujące zapytania SQL w postaci wyrażeń algebry relacji:
a) SELECT Dept.Dname FROM Dept WHERE Dept.Loc='Warszawa'
b) (SELECT Emp.Ename FROM Emp WHERE Emo.Job='Konsultant') UNION (SELECT
Emp.Ename FROM
Emp NATURAL JOIN Dept WHERE Dept.Dname='Konsultanci')
c) SELECT Emp.Ename FROM
Emp NATURAL JOIN Dept WHERE (Emp.Job='Konsultant' OR Dept.Dname='Konsultanci')
6. To zadanie dotyczy rozwiązywania problemów bazodanowych za pomocą zapytań SQL. W przypadku niektórych z nich wygodnie jest zapisać je najpierw jako formuły logiczne z kwantyfikatorami. Mianowicie, baza danych ma następujący schemat:
|
Bywa(Piwosz, Bar) Podają(Bar, Piwo, Cena) Lubi(Piwosz, Piwo) |
Zakładamy, że każdy piwosz odwiedza co najmniej jeden bar i lubi co najmniej
jeden gatunek piwa. Rozwiąż następujące problemy najpierw za pomocą formuły
logicznej z kwantyfikatorami a następnie w postaci zapytania SQL:
1. Wypisz bary, w których jest podawane piwo lubiane przez Kowalskiego.
2. Sprawdź, ile gatunków piwa jest podawanych w barze 'Źródełko'.
3. Znajdź bar, w którym wybór piw jest największy.
4. Sprawdź, czy jest piwosz, który lubi tylko jeden gatunek piwa i chodzi tylko
do jednego baru.
5. Wypisz gatunki piwa, których nikt nie lubi.
6. Wypisz piwoszy, którzy chodzą do baru, gdzie podaje się lubiane przez nich
piwo.
7. Wypisz piwoszy, którzy odwiedzają wyłącznie bary, w których jest podawane
lubiane przez nich piwo.
8. Wypisz piwoszy nie chodzących w ogóle do barów, gdzie podaje się lubiane
przez nich piwo.
9. Sprawdź, czy Kowalski chodzi wyłącznie do barów, gdzie jest podawane tylko
lubiane przez niego piwo.
10. Każdemu piwoszowi wskaż bar, w którym może się napić najtańszego lubianego
przez niego piwa.
11. Wypisz 10 najtańszych gatunków piwa.
12. Wypisz 10 najpopularniejszych gatunków piwa.
13. Wypisz wszystkich piwoszy oznaczając gwiazdką * tych, którzy chodzą do
największej liczby barów.
Strona przygotowana przez Lecha Banachowskiego, PJWSTK, 01/07/08 .