From 045cd3cd1dccb0a87db5cca390db895b7a4876f4 Mon Sep 17 00:00:00 2001 From: lonkaars Date: Tue, 4 Oct 2022 15:42:54 +0200 Subject: opdracht 1 klaar --- opdracht-1/build | 2 +- opdracht-1/opdracht-1.m4 | 99 ++++++++++++++++++++++++++++++------------------ opdracht-1/q6.sql | 4 +- opdracht-1/t11.sql | 1 + 4 files changed, 67 insertions(+), 39 deletions(-) create mode 100644 opdracht-1/t11.sql (limited to 'opdracht-1') diff --git a/opdracht-1/build b/opdracht-1/build index 17e3379..acbfb3d 100755 --- a/opdracht-1/build +++ b/opdracht-1/build @@ -1,6 +1,6 @@ #!/bin/bash cat reset.sql q*.sql | mysql -u root mysql for file in t*.sql; do - mysql -Hu root mysql < "$file" &> "${file/%.sql}.html" + mysql -Hu root mysql < "$file" &> "${file/%.sql}.md" done m4 opdracht-1.m4 > opdracht-1.md diff --git a/opdracht-1/opdracht-1.m4 b/opdracht-1/opdracht-1.m4 index efe4d96..59b85eb 100644 --- a/opdracht-1/opdracht-1.m4 +++ b/opdracht-1/opdracht-1.m4 @@ -1,44 +1,52 @@ changequote(`{{', `}}') +define({{include_sql}}, {{ +```sql +include({{$1.sql}}) +``` +}}) + define({{q_norm}}, {{ ## Opdracht $1 -```sql -include({{q$1.sql}}) -``` +Query: +include_sql({{q$1}}) }}) define({{q_with_output}}, {{ ## Opdracht $1 -```sql -include({{t$1.sql}}) -``` +Query: +include_sql({{t$1}}) -include({{t$1.html}}) +Output: +include({{t$1.md}}) }}) define({{q_with_test}}, {{ -q_norm({{$1}}) +q_norm($1) -```sql -include({{t$1.sql}}) -``` +Test query: +include_sql({{t$1}}) -include({{t$1.html}}) +Output: +include({{t$1.md}}) }}) # Practicum 1 ## Opdracht 1 -Is geinstalleerd +Is geïnstalleerd q_norm(2) q_with_test(3) q_with_test(4) q_with_test(5) q_with_test(6) + +(Er is geen output want deze query draait zonder foutmelding nu) + q_with_output(7) ## Opdracht 8 @@ -55,56 +63,75 @@ een tabel. Een populatiediagram laat ook de inhoud zien voor elke tabel. ## Opdracht 10 -> Wat is single point of definition, en wat levert dit op? +Single point of definition houdt in dat je geen herhaalde of hard-coded waardes +in je query hebt staan. Door deze waardes op een plaats te definiëren is de +code beter onderhoudbaar. ## Opdracht 11 -> Welke kolommen van de tabel ‘tblKlant’ voldoen aan de ‘verplichte- waarderegel’ +`ID`, `Postcode` en `Huisnummer` moeten ingevuld zijn omdat deze de `not null` +constraint hebben. + +Query: +include_sql({{t11}}) + +Output: +include({{t11.md}}) ## Opdracht 12 -> Op welke tabel of tabellen is de ‘referentiele- integriteitsregel’ van toepassing en waarom? +Alle tabellen behalve `OrderProduct` hebben referentiële integriteit omdat ze +allemaal een primary key hebben, en deze gebruikt wordt om tussen de tabellen +naar elkaar te refereren. OrderProduct heeft wel een primary key, maar binnen +deze database zijn er geen tabellen die de primary key van `OrderProduct` als +foreign key gebruiken. ## Opdracht 13 -> Indien een ‘veel op veel’ relatie ontstaat, hoe wordt dit dan opgelost? +Dit zou je op kunnen lossen door de veel-op-veel relatie op te delen in +meerdere een-op-meer relaties. ## Opdracht 14 -> Wat zijn in het gegeven ERD de ‘eigenschappen’ van tabel ‘tblProduct’ +Een klant kan nul of meer orders plaatsen, die elk één of meer producten +bevatten. ## Opdracht 15 -> Wat zijn de twee belangrijkste transacties en wat betekenen deze? +`commit` en `rollback`. Na het starten van een transactie kun je `commit` +gebruiken om je gemaakte wijzigingen toe te passen, of `rollback` om ze te +annuleren. ## Opdracht 16 -> Wat is het verschil tussen ‘0’ en ‘NULL’? +0 refereert naar het letterlijke getall 0, terwijl NULL refereert naar een +lege/niet ingevulde waarde. ## Opdracht 17 -> Wat betekent ‘normaliseren’ en wat is het doel hiervan? +Normaliseren is een techniek die je kunt gebruiken om een databasestructuur te +maken die informatie niet dubbel opslaat, en tabellen klein en overzichtelijk +houdt. Dit zorgt er voor dat je geen redundante data opslaat, en dat je minder +risico loopt op dataverlies doordat je kleinere tabellen aanpast met de +`insert`, `update` en `delete` commando's. ## Opdracht 18 -> In de tabel ‘tblOrder’ wordt de status bijgehouden per order. Enkele statussen zouden kunnen zijn: -> -> - Geleverd -> - In bestelling -> - Niet meer leverbaar -> -> Hoe zou je de databasestructuur kunnen verbeteren op basis van de tabel -> ‘tblOrder’ met het oog op onderhoud van de statussen? +Je zou de statussen een numerieke waarde kunnen maken, en deze omzetten naar +een string in het programma die de query ontvangt, of door een losse tabel te +maken die voor elk getal een string bevat die de status beschrijft als tekst. ## Opdracht 19 -> In de tabel ‘product’ is iets dergelijks van toepassing als bij vraag 18. -> -> - Wat is hier aan de hand? -> - Hoe kun je dit verbeteren? +In de tabel `Product` worden de eenheden herhaald. Ook deze zou je om kunnen +zetten naar numerieke waardes die de eenheden representeren. ## Opdracht 20 -> Stel dat je de wijzigingen van vraag 18 en 19 bij alle afnemers van je software gelijktijdig wilt doorvoeren. -> -> Hoe zou je dit het beste op afstand kunnen uitvoeren? +Ik zou een transactie maken die deze veranderingen alvast uitrekent van +tevoren, en deze pas committen tijdens een gepland onderhoudsmoment. Omdat dit +gegarandeerde veranderingen aan de gebruikte query's en/of software die de data +uit de database ontvangt vereist, zou het zo fijn mogelijk zijn als alles van +tevoren wordt getest in een ontwikkelomgeving, zodat de klanten van de software +zo min mogelijk uitvaltijd ervaren. + diff --git a/opdracht-1/q6.sql b/opdracht-1/q6.sql index e8d43ff..9125755 100644 --- a/opdracht-1/q6.sql +++ b/opdracht-1/q6.sql @@ -1,2 +1,2 @@ -alter table `Order` drop foreign key KlantID; -alter table `Order` add constraint KlantID foreign key (KlantID) references Klant(ID) on update cascade; +alter table `Order` drop foreign key Order_ibfk_1; +alter table `Order` add constraint Order_ibfk_1 foreign key (KlantID) references Klant(ID) on update cascade; diff --git a/opdracht-1/t11.sql b/opdracht-1/t11.sql new file mode 100644 index 0000000..1f2d4af --- /dev/null +++ b/opdracht-1/t11.sql @@ -0,0 +1 @@ +describe Klant; -- cgit v1.2.3