ZASADY TWORZENIA BAZ DANYCH
7 GRZECHÓW GŁÓWNYCH POPOEŁNIANYCH PRZY BAZACH DANYCH
- Grzech obiektowości - brak określienia obiektu odwzorowanego w świetcie rzeczywistym
- Grzech przechowywania w tabel danych innej tabeli - unikać przechowywania redundantnych danych
- Grzech braku rozbijania danych - w każdym polu wiersza musi znajdować się tylko jedna wartość danego typu danych
- Grzech niewłasciwego dobory właściwych kluczy - klucze powinny się kojarzyć z nazwą obiektów oraz posiadać "ID"
- Grzech trudnych zapytań - pomośl o właściwie zadawanych zapytaniach podczas używania bazy danych
- Grzech braku wypełnienia - unikaj pustych pól
- Grzech złożonych tabel - należy tworzyć proste tabele łaczone innymii tabelami
1. OKREŚLANIE OBIEKTÓW
Budujemy zdanie zawierające podstawowe informacje. Np..: "Klient zamówił książkę"
Utworzymy obiekty:
- Klient - mający imię, nazwisko, i adres
- Zamówienie - mające datę, wartość, ilość, książkę
- Książka - mająca identyfikator, tytuł, autora, rodzja okładki, itp..
Przykłady tabel:
|
KSIĄŻKI
| ISBN | Tytuł | Autor | Cena |
|---|
| 0-123-4567-8 | PHP i MYSQL | Welling, Thomson | 99 zł. |
| 0-123-5678-9 | Turbo Pascal 5.5 | Marciniak | 49 zł. |
| 0-987-6543-2 | Java EE 6 | Rychlicki-Kicior | 37 zł. |
|
ZAMÓWIENIA
| ZamowienieID | KlientID | Data | Wartość |
|---|
| 1. | 1 | 2014.02.14 | 198 zł. |
| 2. | 2 | 2014.02.10 | 98 zł. |
| 3. | 1 | 2014.01.14 | 74 zł. |
|
|
KLIENT
| KlientID | Nazwisko | Imię | Adres |
|---|
| 1. | Nowak | Jan | Sosonowiec |
| 2. | Kowalski | Adam | Kraków |
| 3. | Szeregowy | Anna | Sosonowiec |
|
2. REDUNDANTNE DANE
Należy unikać przechwywania danych w jednej tabeli -stwarza to póżniej trudności w zarządaniu nimi
Przykład tabeli z redundantnymi danymi:
ZAMÓWIENIE
| ZamowienieID | KlientID | Nazwisko | Imię | Adres |
|---|
| 1. | 1. | Nowak | Jan | Sosonowiec |
| 2. | 1. | Nowak | Jan | Sosonowiec |
| 3. | 1. | Nowak | Jan | Sosonowiec |
W powyższej tabeli powinien być ujęty tylko numer klienta
3. ROZBIJAJ DANE
|
KlientID - źle
| KlientID | Nazwisko i Imię | Miejscowość |
|---|
| 1. | Nowak Jan | Sosnowiec |
| 2. | Kowalski Adam | Katowice |
| 3. | Nowak Anna | Sosnowiec |
nie dowiemy się ilu Nowaków mieszka w Sosnowcu,
powieważ nie ma takich klientów
|
KlientID - dobrze
| KlientID | Nazwisko | Imię | Miejscowość |
|---|
| 1. | Nowak | Jan | Sosnowiec |
| 2. | Kowalski | Adam | Katowice |
| 3. | Nowak | Anna | Sosnowiec |
W Sosnowcu mieszka 2 Nowaków
|
4. DOBÓR NAZW KLUCZY
Niewłaściwa nazwa klucza będzie nas wprowadzać w błąd lub będzie trudna do użycia (przykłady złych kluczy):
- ID klienta
- dataID
- MiejscowoscID
- AutorID
- itp..
5. ZAPYTANIA
Np.. musimy mieć możliwość zapytania o samo nazwisko. Z tabeli
(patrz 3. zła tabela) nie uzyskamy odpowiedzi gdyż nie ma w niej
pola "Nowak" tylko jest "Nowak Jan".
6. PUSTE POLA
|
Ilość książek - źle
| ISBN | ILOŚĆ |
|---|
| 0-1234-567-8 | 102 |
| 0-2345-678-9 | 99 |
| 0-1234-567-6 | |
Nie każda książka musi być policzona w tej chwili
|
Ilość książek - dobrze
| IloscID | ISBN | Ilosc |
|---|
| 1. | 0-1234-567-8 | 102 |
| 2. | 0-2345-678-9 | 99 |
Mniejsza ilość rekordów
|
7. TABELE PROSTE
Ze wzgl. na zarządzanie danymi powinno się unikać tabel typu wiele do wielu.
Tabele proste (1:1 oraz 1:∞) mogą zawierać klucze innych tabel
ARCHITEKTURA INTERNETOWYCH BAZ DANYCH
Klasyczny układ działania baz danych
⇒ Spis treści ⇐
⇐ PREV NEXT ⇒