Small corrections.

This commit is contained in:
Davte 2020-05-30 18:37:58 +02:00
parent 4c4ffa048f
commit 51f220e5d2
Signed by: Davte
GPG Key ID: D848081D6F892DA9
7 changed files with 32 additions and 15 deletions

View File

@ -33,7 +33,8 @@ top=30mm,
basicstyle=\small\ttfamily,
keywordstyle=\bfseries,
moredelim=[is][\underbar]{_}{_},
keepspaces=true
keepspaces=true,
morekeywords={AFTER,BEFORE,RAISE,ABORT}
}
\selectlanguage{italian}
@ -49,7 +50,6 @@ top=30mm,
\begin{document}
\maketitle % Insert the title, author and date
\input{\folder/source_code.tex}
\section{Descrizione di massima del dominio (testo)}\label{sec:testo}
\input{\folder/testo.tex}
\clearpage

View File

@ -6,7 +6,7 @@ metodo all-grain.
Ogni utente dell'app (birraio o birraia) può lavorare per uno o più birrifici, e può
visualizzare le ricette dei birrifici per cui lavora.
Del birraio o birraia sono rilevanti il nome, il cognome, il soprannome,
Del* birrai* sono rilevanti il nome, il cognome, il soprannome,
l'indirizzo email, il codice fiscale.
Ogni birrificio ha un nome, un anno di fondazione, un motto e uno stemma.
Il birrificio ha inoltre una capacità produttiva, cioè il numero massimo di
@ -45,9 +45,9 @@ nel database invece le quantità verranno memorizzate in termini relativi come
descritto sopra.
Una produzione è caratterizzata da una data di produzione, un numero di lotto
che la identifica univocamente, il numero di bottiglie da 500 mL prodotte
(questo è l'unico possibile formato di produzione) e uno stato di preparazione
(in corso, completa, annullata).
che la identifica univocamente all'interno del birrificio, il numero di
bottiglie da 500 mL prodotte (questo è l'unico possibile formato di produzione)
e uno stato di preparazione (in corso, completa, annullata).
È prodotta seguendo una ricetta di un birrificio.
A ogni produzione si possono accompagnare alcune note.

View File

@ -87,7 +87,7 @@ WHERE EXISTS (SELECT *
(r2.IdBirrificio @$\neq$@ r1.IdBirrificio)}
\end{lstlisting}
\textbf{Scrivo quindi la query}, inserendo l'IdPersona e la parola chiave
\textbf{Scrivo quindi la query}, inserendo l'\texttt{IdPersona} e la parola chiave
\texttt{DISTINCT} per rimuovere i duplicati (ma non le persone omonime).
\begin{lstlisting}[style=SQLu,escapechar=@]
SELECT DISTINCT p1.IdPersona, p1.Nome, p1.Cognome

View File

@ -43,9 +43,9 @@ AS SELECT iat.IdIngrediente IdIngrediente,
- COALESCE(iiu.InUso, 0)) QuantitàDisponibile
FROM IngredientiAcquistatiTotali iat
LEFT JOIN IngredientiUsati iu
ON iu.idIngrediente = iat.IdIngrediente
ON iu.IdIngrediente = iat.IdIngrediente
LEFT JOIN IngredientiInUso iiu
ON iiu.idIngrediente = iat.IdIngrediente
ON iiu.IdIngrediente = iat.IdIngrediente
WHERE iat.Totale - COALESCE(iu.Usati, 0) > 0;
\end{lstlisting}
@ -89,6 +89,8 @@ birrificio per cui lavora.
\item Ogni nota deve fare riferimento a una produzione.
\item Ogni prenotazione deve fare riferimento a una produzione.
\item Ogni prenotazione deve fare riferimento ad un* cliente.
\item La quantità di bottiglie di un produzione prenotate non deve
superare il numero di bottiglie prodotte.
\item Ogni produzione deve seguire una ricetta.
\item Due produzioni di uno stesso birrificio non devono avere lo stesso lotto.
\item Ogni ricetta deve avere un* creat*r* e un birrificio di riferimento.

View File

@ -41,7 +41,7 @@ NoteDegustazione(@\underline{IdNota*}@, Giudizio)
anche che ci possono essere errori umani nell'inserimento di un CF e voglio
riservarmi la possibilità di correggere un CF senza minare l'affidabiltà
della base di dati.
\item Stesso discorso per la RagioneSociale e la PartitaIva nella tabella
\item Stesso discorso per la \texttt{RagioneSociale} e la \texttt{PartitaIva} nella tabella
\texttt{Fornitori}: ciascuno è chiave separatamente.
\item Nella tabella \texttt{Fatture}, la coppia di attributi \texttt{\{IdFornitore, NumeroFattura\}}
è chiave.
@ -50,7 +50,7 @@ NoteDegustazione(@\underline{IdNota*}@, Giudizio)
birrificio che il lotto identifica univocamente la produzione.
\end{itemize}
Uno schema R, avente insieme di attributi T e insieme di dipendenze funzionali F, (\lstinline{R<T, F>}) è
Uno schema R, avente insieme di attributi T e insieme di dipendenze funzionali F, \lstinline{R<T, F>}, è
in forma normale di Boyce-Codd (BCNF) se ogni dipendenza funzionale della chiusura di F o è
banale o ha come determinante una superchiave di T.
Esiste un teorema che semplifica il calcolo, asserendo che se la condizione di cui sopra vale per
@ -61,3 +61,18 @@ solo attributo come determinato, nessuna dipendenza è ridondante e non sono pre
attributi estranei, in quanto ogni determinante è chiave), ogni dipendenza funzionale ha
come determinante o la chiave primaria o una chiave naturale che non è stata scelta come
primaria, in ogni caso una superchiave. \underline{La BCNF è pertanto rispettata}.
Alcuni vincoli intra-relazionali possono essere tradotti in trigger in modo da
mantenere la coerenza del database con l'inserimento di record.
Per esempio:
\begin{lstlisting}[style=SQLu,escapechar=@]
CREATE TRIGGER IntegritàReferenzialeNote
BEFORE INSERT ON Note
BEGIN
SELECT
CASE WHEN NEW.IdProduzione NOT IN (
SELECT IdProduzione FROM Produzioni)
THEN RAISE (ABORT,'Produzione non valida!')
END;
END;
\end{lstlisting}

View File

@ -221,8 +221,8 @@ AS SELECT iat.IdIngrediente IdIngrediente,
- COALESCE(iiu.InUso, 0)) QuantitàDisponibile
FROM IngredientiAcquistatiTotali iat
LEFT JOIN IngredientiUsati iu
ON iu.idIngrediente = iat.IdIngrediente
ON iu.IdIngrediente = iat.IdIngrediente
LEFT JOIN IngredientiInUso iiu
ON iiu.idIngrediente = iat.IdIngrediente
ON iiu.IdIngrediente = iat.IdIngrediente
WHERE iat.Totale - COALESCE(iu.Usati, 0) > 0;
COMMIT;

View File

@ -185,8 +185,8 @@ AS SELECT iat.IdIngrediente IdIngrediente,
- COALESCE(iiu.InUso, 0)) QuantitàDisponibile
FROM IngredientiAcquistatiTotali iat
LEFT JOIN IngredientiUsati iu
ON iu.idIngrediente = iat.IdIngrediente
ON iu.IdIngrediente = iat.IdIngrediente
LEFT JOIN IngredientiInUso iiu
ON iiu.idIngrediente = iat.IdIngrediente
ON iiu.IdIngrediente = iat.IdIngrediente
WHERE iat.Totale - COALESCE(iu.Usati, 0) > 0;
COMMIT;