# ZASADY TWORZENIA BAZ DANYCH

# 7 GRZECHÓW GŁÓWNYCH POPOEŁNIANYCH PRZY BAZACH DANYCH

1. Grzech obiektowości - brak określienia obiektu odwzorowanego w świetcie rzeczywistym
2. Grzech przechowywania w tabel danych innej tabeli - unikać przechowywania redundantnych danych
3. Grzech braku rozbijania danych - w każdym polu wiersza musi znajdować się tylko jedna wartość danego typu danych
4. Grzech niewłasciwego dobory właściwych kluczy - klucze powinny się kojarzyć z nazwą obiektów oraz posiadać "ID"
5. Grzech trudnych zapytań - pomośl o właściwie zadawanych zapytaniach podczas używania bazy danych
6. Grzech braku wypełnienia - unikaj pustych pól
7. 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

Przeglądarka
| 1 ⇒ 6 ⇐ |
Serwer WWW
| 2 ⇒ 5 ⇐ |
Interpreter PHP
| 3 ⇒ 4 ⇐ |
Serwer MySQL

⇒ Spis treści ⇐

⇐ PREV NEXT ⇒