Aanmaken van tabellen en het leggen van relaties
De tabellen “klant” en “klantzakelijk” zijn inmiddels aangemaakt, nu dienen de hotels, medewerkers en reserveringen nog te worden aangemaakt. Bij het aanmaken van de tabellen zal ik regelmatig verwijzen naar het klassendiagram, de functie hiervan zal je dan (hopelijk) duidelijk worden.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
2
3
4
5
6
7
8
9
10
11
12
13
CREATE TABLE medewerker
(
medewerker_id serial NOT NULL,
hotel_id int8,
manager_id int8,
naam varchar(150) NOT NULL,
adres varchar(100) NOT NULL,
postcode varchar(7) NOT NULL,
woonplaats varchar(100) NOT NULL,
CONSTRAINT pk_medewerker PRIMARY KEY (medewerker_id),
CONSTRAINT fk_manager FOREIGN KEY (manager_id) REFERENCES medewerker (medewerker_id) ON UPDATE RESTRICT ON DELETE RESTRICT
)
WITH OIDS;
(
medewerker_id serial NOT NULL,
hotel_id int8,
manager_id int8,
naam varchar(150) NOT NULL,
adres varchar(100) NOT NULL,
postcode varchar(7) NOT NULL,
woonplaats varchar(100) NOT NULL,
CONSTRAINT pk_medewerker PRIMARY KEY (medewerker_id),
CONSTRAINT fk_manager FOREIGN KEY (manager_id) REFERENCES medewerker (medewerker_id) ON UPDATE RESTRICT ON DELETE RESTRICT
)
WITH OIDS;
Bij het aanmaken van de tabel “medewerker” is er een relatie gelegd op de kolom “manager_id” naar het veld “medewerker_id” in dezelfde tabel. Een medewerker kon volgens het klassendiagram een manager hebben. Met deze relatie wordt afgedwongen dat het manager_id moet voorkomen als medewerker_id in medewerker, het verwijderen van een medewerker kan niet zolang hij nog manager is van andere medewerkers.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
CREATE TABLE hotel
(
hotel_id serial NOT NULL,
manager_id int8 NOT NULL,
naam varchar(100) NOT NULL,
adres varchar(150) NOT NULL,
postcode varchar(7) NOT NULL,
plaats varchar(100) NOT NULL,
CONSTRAINT pk_hotel PRIMARY KEY (hotel_id),
CONSTRAINT fk_manager FOREIGN KEY (manager_id) REFERENCES medewerker (medewerker_id) ON UPDATE RESTRICT ON DELETE RESTRICT
)
WITH OIDS;
(
hotel_id serial NOT NULL,
manager_id int8 NOT NULL,
naam varchar(100) NOT NULL,
adres varchar(150) NOT NULL,
postcode varchar(7) NOT NULL,
plaats varchar(100) NOT NULL,
CONSTRAINT pk_hotel PRIMARY KEY (hotel_id),
CONSTRAINT fk_manager FOREIGN KEY (manager_id) REFERENCES medewerker (medewerker_id) ON UPDATE RESTRICT ON DELETE RESTRICT
)
WITH OIDS;
Een hotel heeft altijd één manager, daarom is het veld aangemaakt met de eigenschap NOT NULL, het veld mag niet leeg zijn. Er is een relatie gelegd op de kolom manager_id welke verwijst naar medewerker_id in de tabel medewerker, ook hier wordt op database-niveau afgedwongen dat de manager moet bestaan en nooit kan worden verwijderd zolang er nog hotels zijn welke hij ‘managed’.
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
2
3
4
5
6
7
8
9
10
11
12
13
14
15
CREATE TABLE reservering
(
reservering_id serial NOT NULL,
hotel_id int8 NOT NULL,
klant_id int8 NOT NULL,
medewerker_id int8 NOT NULL,
datum_aankomst date,
datum_vertrek date,
CONSTRAINT pk_reservering PRIMARY KEY (reservering_id),
CONSTRAINT fk_hotel FOREIGN KEY (hotel_id) REFERENCES hotel (hotel_id) ON UPDATE CASCADE ON DELETE CASCADE,
CONSTRAINT fk_klant FOREIGN KEY (klant_id) REFERENCES klant (klant_id) ON UPDATE CASCADE ON DELETE CASCADE,
CONSTRAINT fk_medewerker FOREIGN KEY (medewerker_id) REFERENCES medewerker (medewerker_id) ON UPDATE CASCADE ON DELETE CASCADE
)
WITH OIDS;
Een reservering bevat ALTIJD de volgende gegevens: hotel_id, klant_id en medewerker_id, daarom zijn ook deze velden NOT NULL en verwijzen ze met relaties naar de betreffende tabellen. In deze opzet is het zo gemaakt dat als een klant wordt weggegooid ook meteen zijn reserveringen worden verwijderd (ON DELETE CASCADE), idem bij het verwijderen van een hotel en medewerker. Of dit wenselijk is is afhankelijk van het systeem dat je bouwt.
« vorige pagina | volgende pagina »
Inhoudsopgave
- Inleiding
- Voorbeeld-case
- Overerving in PostgreSQL
- Aanmaken van tabellen en het leggen van relaties
- Views
- PL/pgSQL functies en procedures
- Triggers
- Check constraints en domains
- Conclusie