1. Projekt przykładowej struktury relacyjnej

Wydział Elektrotechniki, Informatyki i Telekomunikacji
Instytut Informatyki i Elektroniki
Instrukcja do zajęć laboratoryjnych
Praca z bazą danych MySQL
wersja 2.0
Nr ćwiczenia:
10
Temat:
Implementacja przykładowej struktury relacyjnej w bazie MySQL. Język definiowania danych DDL (ang. Data Definition
Language) oraz języki manipulowania danymi DML (ang. Data Manipulation Language)
Cel ćwiczenia:
Celem ćwiczenia jest utworzenie w języku SQL przykładowej struktury relacyjnej. Ćwiczenie rozpoczyna się od opracowania odpowiednich
założeń dla tej struktury. Następnie utworzony model powinien zostać
implementowany w języku SQL. Na koniec powinien powstać skrypt ładujący zestaw przykładowych danych (po kilka–kilkanaście rekordów do
każdej tabeli).
Wymagane przygotowanie
teoretyczne:
Wiadomości podawane na wykładzie. Materiał z poprzednich ćwiczeń.
Sposób zaliczenia:
Pozytywna ocena ćwiczenia przez prowadzącego pod koniec zajęć.
Prowadzący zajęcia:
dr inż. Artur Gramacki, dr inż. Jarosław Gramacki
1. Projekt przykładowej struktury relacyjnej
1.1. Forma prezentacji projektu
Należy zaprojektować relacyjny model danych wg. założeń podanych poniżej. Każde z tych
założeń musi być uwzględnione w projektowanym modelu. Efektem końcowym powinien być
rysunek pokazujący poszczególne tabele (wraz z wyszczególnieniem ich kolumn) oraz powiązania
integralnościowe między nimi.
Forma graficzna jest w zasadzie dowolna. Jako wzór można przyjąć rysunek przykładowej struktury relacyjnej, o której jest mowa w jednym z poprzednich ćwiczeń. Na rysunku należy stosować
następujące skróty:
• pk – primary key,
• ai – auto increment,
• uq – unique (uq1 oraz uq2 oznacza, że ograniczenie unique posiadają obie kolumny jednocześnie a nie każda z osobna!),
• nn – not null,
• fk – foreign key,
• en – enum (pod tabelą wypisać dopuszczalne wartości),
• set – set (pod tabelą wypisać dopuszczalne wartości),
• ck – check (pod tabelą wypisać dopuszczalne wartości).
Przeprowadzić dyskusję podanych niżej założeń. Wskazać ich ew. braki, błędy, niedociągnięcia
itp. Zaproponować ich rozbudowę celem zwiększenia funkcjonalności modelu i dostosowanie do
realnych potrzeb obsługi akademików na Uniwersytecie Zielonogórskim.
Przygotowali: dr inż. Artur Gramacki, dr inż. Jarosław Gramacki
1
1.2. Założenia
Stworzyć strukturę relacyjnej bazy danych do obsługi akademika, która będzie umożliwiała:
1. Gromadzenie danych o studentach wg założeń:
• każdy student należy do jednej ( i tylko jednej) grupy studenckiej a w danej grupie
jest z reguły więcej niż jeden student,
• zakładamy, że każdy student może studiować na wyłącznie jednym wydziale a na
danym wydziale jest zawsze więcej niż jeden student,
• musi istnieć możliwość wpisania paru słów krótko opisujących daną grupę oraz wydział (np.: „grupa bardzo liczna z przewagą osób starszych”, „wydział znajduje się
na 5 piętrze Budynku Dydaktycznego” itp.).
2. Gromadzenie danych o wyposażeniu poszczególnych pokoi w akademiku wg założeń:
• w każdym pokoju może być wiele sprzętów różnego rodzaju (np. 3 krzesła drewniane, 2 tapczany itd.) a dana grupa sprzętów (np. krzesła drewniane) może być na
wyposażeniu wielu pokoi,
• każda sztuka sprzętu ma swój unikalny numer inwentarzowy,
• rejestrujemy również wartość (w zł) konkretnych elementów wyposażenia (przy czym
może się np. zdarzyć, że dwa sprzęty należące do tej samej grupy — np. ”krzesła
drewniane” — mają różną cenę, gdyż jedno z nich jest trwale poplamione).
3. Gromadzenie danych o rozmieszczeniu studentów w pokojach akademika wg założeń:
• każdy student może w danej chwili zajmować tylko jeden pokój,
• pokoje są wieloosobowe i w związku z tym w danym pokoju może (ale nie musi)
mieszkać kilku studentów,
• musi istnieć możliwość wpisywania różnych uwag dotyczących pokoi (np. zapisano, że
w pokoju 506 dnia 20.01.97 zgłoszono usterkę „zamek w drzwiach wejściowych zacina
się”, w tym samym pokoju w dniu 30.02.97 stwierdzono usterkę zlewozmywaka itp.),
• cena za miejsce w pokoju jest uzależniona od konkretnego pokoju (np. cena pokoju
102 wynosi 100zł/miesiąc a pokoju 404 120 zł/miesiąc itd.).
2. Implementacja zaprojektowanej struktury relacyjnej
W poprzednim punkcie projektowałeś strukturę relacyjną do obsługi akademika (w dość ograniczonym zakresie — tylko o wyposażenie pokoi oraz ich lokatorzy). Obecnie przyszedł czas, aby
zaimplementować zaprojektowaną strukturę w bazie MySQL.
Wynik zadania powinien być zapisany w plikach tekstowych jako skrypty języka SQL. Szczegóły
są następujące:
• ustalenie nazw kolumn i tabel,
• ustalenie typów danych dla poszczególnych kolumn,
• ustalenie wymaganych ograniczeń dla kolumn,
• zapisanie poleceń kasujących (DROP) wszystkie tabele w modelu. Dobrym zwyczajem jest
poprzedzenie tworzenia tabel wykasowaniem istniejących. Próba utworzenia tabeli o takiej
samej nazwie jak już istniejąca nie powiedzie się — chyba, że użyjemy konstrukcji CREATE
TABLE IF NOT EXISTS. Szczegóły patrz dokumentacja,
Przygotowali: dr inż. Artur Gramacki, dr inż. Jarosław Gramacki
2
• zapisanie poleceń tworzących (CREATE) wszystkie tabele w modelu. Będzie to najbardziej
czasochłonna część projektu,
• zapisanie poleceń tworzących klucze obce (ALTER TABLE),
• polecenia z trzech poprzednich punktów powinny zostać zapisane w skrypcie o nazwie
model.sql,
• zapisanie poleceń ładujących do poszczególnych tabel zestaw przykładowych danych. Dane
powinny być „sensowne” (przykładowo dla kolumn: imie, nazwisko, data ur sensowne
dane to Marcin Kowalski 12-10-1954 a zupełnie bezsensowne jghfgsas jhfjfdjf 01-01-1400 ).
W każdej tabeli powinno znaleźć się przynajmniej po kilka rekordów. Tam, gdzie wyda się
to celowe, rekordów tych powinno być więcej.
• polecenia z poprzedniego punktu powinny zostać zapisane w skrypcie o nazwie dane.sql.
W czasie pracy zalecamy wzorowanie się na skrypcie tworzącym demonstracyjną strukturą relacyjną omawianą na jednym z poprzednich ćwiczeń.
Przygotowali: dr inż. Artur Gramacki, dr inż. Jarosław Gramacki
3