Przykałdowa baza danych dotycząca forum dyskusyjnego.
Autor: Magister inżynier Ireneusz Łukasz Dzitkowski Wałcz, dnia: 08. 02. 2012r.
© Wszystkie prawa zastrzeżone.
1. Projektowanie bazy danych – przykładowa baza danych Dane Studentów.
Baza danych zaprojektowana jest w celu zmagazynowaniauporządkowania i łatwego wyszukania
oraz zobrazowania danych dotyczących studentów.
Zakłada ona wstępne pojedyńcze informacje dotyczące imienia i nazwiska
oraz określenie podstawowych funkcji rekordów zawartych w bazach danych.
Uwzględnia relacje zachodzące między pakietami danych i podaną informację na temat danego studenta.
2. Definicja celu.
Celem jakiemu ma służyć projektowana baza danych
może być rejestracja obecności i ocen studentów i planowanie wykładów.
3. Założenia wstępne.
Poniżej podano następujące założenia wstępne do systemu
planowania produkcji seryjnej wyrobów prostych:
• baza forum ma wielu klientów stałych i okazyjnych,
• studenci rozmawiają na określony temat
4. Definiowanie funkcji systemu baz danych.
Już na etapie projektowania bazy danych należy określić
podstawowe funkcje systemu baz danych.
W przykładowym systemie planowania produkcji mogą to być następujące funkcje:
• wprowadzanie danych ogólnych (o wyrobach i materiałach z jakich są wytworzone,
czasach technologicznych wykonania wyrobów itp.),
• wprowadzanie danych o studentach
• wprowadzanie danych o tematach
• wspomaganie tworzenia wstępnego planu rozmowy
• wyszukiwanie wszystkich opinii studenta
• wyszukanie wszystkich studentów rozmawiających na określony temat
5. Projektowanie bazy danych - przykład:
6. Budowanie diagramu związków między relacjami.
Metoda przedstawiania związków między relacjami (tabelami) za pomocą diagramu
jest bardzo wygodna i znacznie usprawnia proces tworzenia bazy danych.
Na diagramie (schemacie) widać od razu wszystkie tabele i powiązania między nimi.
Zadanie to najlepiej wykonać w kilku następujących krokach:
• Identyfikacja zbioru obiektów występujących w danym problemie.
• Identyfikacja powiązań bezpośrednich
między obiektami i przekształcenie w pojęciowy model danych (ustalenie typu relacji).
• Określenie atrybutów kluczowych i pozostałych atrybutów dla wszystkich obiektów.
Normalizacja do pierwszej
(rozbicie atrybutów wielowartościowych na jednowartościowe)
i drugiej postaci normalnej (rozbicie tabel na dwie lub więcej w celu uniknięcia redundancji danych w tabeli).
• Normalizacja do trzeciej postaci normalnej, przekształcenie relacji typu m : n na powiązania typu 1 : n.
• Sprawdzenie poprawności struktury bazy danych poprzez porównanie jej struktury z wymaganiami względem systemu bazy danych.
7. Identyfikacja bezpośrednich zależności między obiektami.
Po wyróżnieniu obiektów w systemie należy zidentyfikować wszystkie powiązania występujące między nimi.
8. Pojęciowy model danych.
Na podstawie identyfikacji bezpośrednich zależności między obiektami
możemy utworzyć diagram zależności między obiektami przyszłej bazy danych.
Rodzaj relacji należy ustalić na podstawie założeń wstępnych i funkcji aplikacji.Rozważmy kolejno przykłady relacji:
• relacja między studentami, a tematami jest typu jeden do wielu (1 : n), ponieważ każdy student może podjąć wiele tematów,
natomiast każdy temat należy tylko do jednego formum
• relacja między studentami, a tematami jest typu wiele do wielu (m : n), ponieważ na zamówieniu
9. Budowanie diagramu związków między relacjami
Metoda przedstawiania związków między relacjami (tabelami)
za pomocą diagramu jest bardzo wygodna i znacznie usprawnia proces tworzenia bazy danych.
Na diagramie (schemacie) widać od razu wszystkie tabele i powiązania między nimi.
Zadanie to najlepiej wykonać w kilku następujących krokach:
• Identyfikacja zbioru obiektów występujących w danym problemie.
• Identyfikacja powiązań bezpośrednich między obiektami i przekształcenie w pojęciowy model danych (ustalenie typu relacji).
• Określenie atrybutów kluczowych i pozostałych atrybutów dla wszystkich obiektów.
Normalizacja do pierwszej
(rozbicie atrybutów wielowartościowych na jednowartościowe) i drugiej postaci normalnej
(rozbicie tabel na dwie lub więcej w celu uniknięcia redundancji danych w tabeli).
• Normalizacja do trzeciej postaci normalnej, przekształcenie relacji typu m : n na powiązania typu 1 : n.
• Sprawdzenie poprawności struktury bazy danych poprzez
porównanie jej struktury z wymaganiami względem systemu bazy danych.
10. Identyfikacja bezpośrednich zależności między obiektami.
Po wyróżnieniu obiektów w systemie należy zidentyfikować wszystkie powiązania występujące między nimi.
11. Pojęciowy model danych.
Na podstawie identyfikacji bezpośrednich zależności między obiektami możemy utworzyć
diagram zależności między obiektami przyszłej bazy danych.
Rodzaj relacji należy ustalić na podstawie założeń wstępnych i funkcji aplikacji.
Rozważmy kolejno przykłady relacji:
• relacja między studentami, a tematami jest typu jeden do wielu (1 : n),
ponieważ każdy student może podjąć wiele tematów, natomiast każdy temat należy tylko do jednego formum
• relacja między studentami, a tematami jest typu wiele do wielu (m : n), ponieważ na zamówieniu
12. Przekształcenie powiązań typu wiele do wiele.
Każde z powiązań typu m : n, ze względu na późniejszą implementację,
powinno zostać rozdzielone na dwa powiązania typu jeden do wielu 1 : n.
Operację tę przeprowadza się wg schematu zilustrowanego na diagramie poniżej.
13. Określenie atrybutów
Biorąc pod uwagę założenia wstępne i funkcje jakie ma pełnić przyszły system
baz danych można określić atrybuty dla wszystkich relacji (obiektów) z diagramu docelowego
( poniższe tabele). Oprócz nazw atrybutów zostaną określone ich domeny, czyli praktycznie cała struktura tabel bazy danych.
|
Tabela Nazwa atrybutu |
Rodzaj atrybutu |
Znaczenie |
Domena |
|
Id_Studenta |
Klucz |
Identyfikator materiału |
Integer |
|
Nazwa_Formum |
Nazwa Formum |
Char(32) |
|
Jednostka |
Teksty |
Char(5) |
|
Temat |
Programy |
Integer |
|
Opinia |
Wyniki |
Integer |
