· Andrea Pollini · basi dati · 4 min read

7 Esercizi sui diagrammi concettuali

Esercizi sui diagrammi concettuali

Esercizi sui diagrammi concettuali

La progettazione concettuale dei database è una fase importante nello sviluppo di un database. In questa fase, si identificano i dati necessari per rappresentare la realtà di interesse e si modellano in modo da soddisfare i requisiti degli utenti.

Un modo efficace per rappresentare i dati è utilizzare i diagrammi ER. I diagrammi ER sono diagrammi grafici che rappresentano le entità, le relazioni tra le entità e gli attributi delle entità.

Per comprendere i concetti fondamentali della progettazione concettuale dei database, è utile esercitarsi nella costruzione di diagrammi ER.

In questo post, presentiamo 5 esercizi sui diagrammi ER, adatti a chi si sta avvicinando a questa disciplina.

Ogni esercizio presenta una descrizione di una situazione reale e richiede di modellare i dati necessari per rappresentare tale situazione utilizzando un diagramma ER.

Gli esercizi sono progettati per essere progressivi, in modo che gli studenti possano esercitarsi gradualmente nelle diverse tecniche di progettazione concettuale dei database.

Suggerimenti per la risoluzione degli esercizi

Ecco alcuni suggerimenti per la risoluzione degli esercizi:

  • Inizia identificando gli enti coinvolti nella situazione.
  • Per ogni ente, identifica gli attributi che sono necessari per rappresentarlo.
  • Identifica le relazioni tra gli enti.
  • Assicurati che le relazioni siano appropriate per il contesto.

Esercizio 1

Un’università ha diversi corsi, ognuno dei quali ha un nome, un codice, una descrizione e un numero massimo di crediti. Ogni corso è tenuto da un docente, che ha un nome, un cognome, un codice fiscale e un indirizzo e-mail.

Soluzione

erDiagram
DOCENTE one -- one or more CORSO : tiene
DOCENTE {
string nome
string cognome
string cod_fiscale
string email
}
CORSO {
string nome
string descrizione
string codice
int crediti
}

Esercizio 2

Un negozio di alimentari vende diversi prodotti, ognuno dei quali ha un nome, un codice, un prezzo e una categoria. Un prodotto può essere fornito da uno o più fornitori, che hanno un nome, un indirizzo e un numero di telefono.

Analisi preliminare

In questo caso, abbiamo una relazione molti-a-molti tra i prodotti e i fornitori. Questa relazione è necessaria per rappresentare il fatto che un prodotto può essere fornito da più fornitori e che un fornitore può fornire più prodotti.

Esercizio 3

Un libro ha un titolo, un autore, un editore e una data di pubblicazione. Un autore può aver scritto più libri e un editore può aver pubblicato più libri.

Esercizio 4

Un’università ha diversi corsi, ognuno dei quali ha un nome, un codice, un numero di crediti, un professore responsabile e una data di inizio e fine. Un professore può insegnare uno o più corsi.

Esercizio 5

Un’azienda ha diversi dipendenti, ognuno dei quali ha un nome, un cognome, un codice fiscale e un indirizzo e-mail. Ogni dipendente può ricoprire uno o più ruoli, ognuno dei quali ha un nome e una descrizione.

Esercizio 6

Una biblioteca ha diversi libri, ognuno dei quali ha un titolo, un autore, un editore, una data di pubblicazione, un genere e un numero di pagine. Un libro può essere prestato a uno o più utenti, che hanno un nome, un cognome, un codice fiscale e un indirizzo e-mail.

Analisi preliminare

In questo caso, abbiamo una relazione molti-a-molti tra i libri e gli utenti. Questa relazione è necessaria per rappresentare il fatto che un libro può essere prestato a più utenti e che un utente può prendere in prestito più libri.

Per rendere la relazione più efficiente, possiamo aggiungere una tabella intermedia chiamata Prestiti. Questa tabella conterrà le informazioni relative a ogni prestito, come la data di inizio e di fine del prestito.

Esercizio 7

Un’azienda ha diversi dipendenti, ognuno dei quali ha un nome, un cognome, un codice fiscale, un indirizzo e-mail, una posizione, un salario e una data di assunzione. I dipendenti possono essere assegnati a uno o più progetti, che hanno un nome, una descrizione e una data di inizio.

Analisi preliminare

In questo caso, abbiamo una relazione molti-a-molti tra i dipendenti e i progetti. Questa relazione è necessaria per rappresentare il fatto che un dipendente può essere assegnato a più progetti e che un progetto può avere più dipendenti assegnati.

Per rendere la relazione più efficiente, possiamo aggiungere una tabella intermedia chiamata Assunzioni. Questa tabella conterrà le informazioni relative a ogni assegnazione, come la data di inizio e di fine dell’assegnazione.

    Back to Blog

    Related Posts

    View All Posts »
    Definzione di DBMS

    Definzione di DBMS

    Esistono diversi tipi di basi di dati, a seconda della loro struttura, della tecnologia utilizzata e del modello di dati utilizzato.

    Installare Mosquitto su Raspberry Pi

    Installare Mosquitto su Raspberry Pi

    Impara a installare e configurare il broker MQTT Mosquitto sul tuo Raspberry Pi. Segui la nostra guida passo-passo per creare un sistema di messaggistica IoT flessibile e scalabile.

    Unit testing in Java

    Unit testing in Java

    Gli unit test sono una pratica di test software che consiste nel verificare il corretto funzionamento di singole unità di codice, come metodi o funzioni. In Java, il framework più popolare per l'unit testing è JUnit.

    Esercizi sulle matrici in C++

    Esercizi sulle matrici in C++

    Una raccolta di esercizi sulle matrici in C++ per aiutarti a consolidare le tue conoscenze e a prepararti per gli esami di informatica.

    Quali sono le differenze tra "INNER JOIN" e "OUTER JOIN"

    Quali sono le differenze tra "INNER JOIN" e "OUTER JOIN"

    La differenza tra INNER JOIN e OUTER JOIN è uno dei concetti fondamentali della progettazione di database relazionali. In questo articolo, esaminiamo le differenze tra INNER JOIN e OUTER JOIN e quando è opportuno utilizzare ciascuno di essi.

    Cosa é un algoritmo?

    Cosa é un algoritmo?

    Un algoritmo è la descrizione dei passi necessari per risolvere un problema. Affinchè un qualsiasi procedimento risolutivo possa essere considerato e definito come algoritmo abbiamo bisogno di alcune proprietà fondamentali.vediamole assieme