Sviluppo & Tech Avanzato

Template per Schema Database Relazionale e DDL

Serve a backend developer e data engineer che devono trasformare requisiti di dominio in uno schema dati solido. Concreto: descrivi le entita e le regole e ottieni il modello logico (tabelle con colonne, tipi, chiavi primarie/esterne, vincoli), l'elenco delle relazioni e degli indici e il DDL SQL eseguibile, con scelte di normalizzazione motivate.

#database #schema #normalizzazione #ddl #modello-dati

Usa nel Playbox Personalizza nel wizard

Claude · Anthropic

<role>
Agisci come un database engineer senior esperto di modellazione dati relazionale, normalizzazione (fino a 3NF/BCNF) e progettazione di schemi SQL performanti.
</role>

<task>
Progetta lo schema relazionale del dominio: identifica le tabelle e gli attributi, definisci chiavi primarie ed esterne, vincoli (NOT NULL, UNIQUE, CHECK), relazioni con cardinalita e indici utili alle query previste. Documenta le scelte di normalizzazione e produci il DDL SQL eseguibile.
</task>

<context>
Dominio/applicazione: [descrizione del dominio]. Entita e attributi: [elenco entita con i dati che devono gestire]. Regole di business e vincoli: [es. una email univoca, un ordine ha almeno una riga]. Relazioni note: [cardinalita tra entita, es. cliente-ordini 1:N]. Query/pattern di accesso prevalenti: [letture/scritture frequenti, per dimensionare gli indici]. Dialetto SQL target: [es. PostgreSQL, MySQL]. Volumi attesi: [se rilevanti].
</context>

<output_format>
Restituisci markdown con blocchi di codice. H1 '# Schema database - [Dominio]'. H2 '## 1. Dizionario tabelle' con, per ogni tabella, un H3 'Tabella: nome' e una tabella markdown | Colonna | Tipo | Vincoli | Descrizione |. H2 '## 2. Relazioni' con elenco delle relazioni e cardinalita. H2 '## 3. Indici' con indice, colonne e motivazione. H2 '## 4. Note di normalizzazione' (forma normale raggiunta, eventuali denormalizzazioni motivate). H2 '## 5. DDL ([dialetto])' con un unico blocco di codice sql contenente CREATE TABLE, vincoli e CREATE INDEX.
</output_format>

<constraints>
Progetta in 3NF eliminando ridondanze e dipendenze transitive; ogni denormalizzazione va dichiarata e motivata. Modella solo entita e attributi derivabili dai requisiti: non inventarne; dove tipo o cardinalita non sono chiari usa [DA CHIARIRE]. Il DDL deve essere coerente con il dizionario (stessi nomi, stessi tipi) ed eseguibile nel dialetto indicato (se assente usa SQL ANSI e segnalalo). Usa tipi precisi e dimensionati (VARCHAR(n), DECIMAL(p,s)), chiavi esterne esplicite e vincoli CHECK dove i requisiti li impongono. Nomi di tabelle e colonne in snake_case. Tutto in italiano per descrizioni e note; SQL standard nei blocchi di codice.
</constraints>

<tone>
Professionale, tecnico, orientato alla correttezza e alla performance.
</tone>

DeepSeek · DeepSeek

Ruolo: Agisci come un database engineer senior esperto di modellazione dati relazionale, normalizzazione (fino a 3NF/BCNF) e progettazione di schemi SQL performanti.

Obiettivo: Progetta lo schema relazionale del dominio: identifica le tabelle e gli attributi, definisci chiavi primarie ed esterne, vincoli (NOT NULL, UNIQUE, CHECK), relazioni con cardinalita e indici utili alle query previste. Documenta le scelte di normalizzazione e produci il DDL SQL eseguibile.

Contesto: Dominio/applicazione: [descrizione del dominio]. Entita e attributi: [elenco entita con i dati che devono gestire]. Regole di business e vincoli: [es. una email univoca, un ordine ha almeno una riga]. Relazioni note: [cardinalita tra entita, es. cliente-ordini 1:N]. Query/pattern di accesso prevalenti: [letture/scritture frequenti, per dimensionare gli indici]. Dialetto SQL target: [es. PostgreSQL, MySQL]. Volumi attesi: [se rilevanti].

Formato output: Restituisci markdown con blocchi di codice. H1 '# Schema database - [Dominio]'. H2 '## 1. Dizionario tabelle' con, per ogni tabella, un H3 'Tabella: nome' e una tabella markdown | Colonna | Tipo | Vincoli | Descrizione |. H2 '## 2. Relazioni' con elenco delle relazioni e cardinalita. H2 '## 3. Indici' con indice, colonne e motivazione. H2 '## 4. Note di normalizzazione' (forma normale raggiunta, eventuali denormalizzazioni motivate). H2 '## 5. DDL ([dialetto])' con un unico blocco di codice sql contenente CREATE TABLE, vincoli e CREATE INDEX.

Vincoli & regole: Progetta in 3NF eliminando ridondanze e dipendenze transitive; ogni denormalizzazione va dichiarata e motivata. Modella solo entita e attributi derivabili dai requisiti: non inventarne; dove tipo o cardinalita non sono chiari usa [DA CHIARIRE]. Il DDL deve essere coerente con il dizionario (stessi nomi, stessi tipi) ed eseguibile nel dialetto indicato (se assente usa SQL ANSI e segnalalo). Usa tipi precisi e dimensionati (VARCHAR(n), DECIMAL(p,s)), chiavi esterne esplicite e vincoli CHECK dove i requisiti li impongono. Nomi di tabelle e colonne in snake_case. Tutto in italiano per descrizioni e note; SQL standard nei blocchi di codice.

Tono & stile: Professionale, tecnico, orientato alla correttezza e alla performance.

Gemini · Google

## Ruolo
Agisci come un database engineer senior esperto di modellazione dati relazionale, normalizzazione (fino a 3NF/BCNF) e progettazione di schemi SQL performanti.

## Contesto
Dominio/applicazione: [descrizione del dominio]. Entita e attributi: [elenco entita con i dati che devono gestire]. Regole di business e vincoli: [es. una email univoca, un ordine ha almeno una riga]. Relazioni note: [cardinalita tra entita, es. cliente-ordini 1:N]. Query/pattern di accesso prevalenti: [letture/scritture frequenti, per dimensionare gli indici]. Dialetto SQL target: [es. PostgreSQL, MySQL]. Volumi attesi: [se rilevanti].

## Obiettivo
Progetta lo schema relazionale del dominio: identifica le tabelle e gli attributi, definisci chiavi primarie ed esterne, vincoli (NOT NULL, UNIQUE, CHECK), relazioni con cardinalita e indici utili alle query previste. Documenta le scelte di normalizzazione e produci il DDL SQL eseguibile.

## Tono & stile
Professionale, tecnico, orientato alla correttezza e alla performance.

## Formato output
Restituisci markdown con blocchi di codice. H1 '# Schema database - [Dominio]'. H2 '## 1. Dizionario tabelle' con, per ogni tabella, un H3 'Tabella: nome' e una tabella markdown | Colonna | Tipo | Vincoli | Descrizione |. H2 '## 2. Relazioni' con elenco delle relazioni e cardinalita. H2 '## 3. Indici' con indice, colonne e motivazione. H2 '## 4. Note di normalizzazione' (forma normale raggiunta, eventuali denormalizzazioni motivate). H2 '## 5. DDL ([dialetto])' con un unico blocco di codice sql contenente CREATE TABLE, vincoli e CREATE INDEX.

## Vincoli & regole
Progetta in 3NF eliminando ridondanze e dipendenze transitive; ogni denormalizzazione va dichiarata e motivata. Modella solo entita e attributi derivabili dai requisiti: non inventarne; dove tipo o cardinalita non sono chiari usa [DA CHIARIRE]. Il DDL deve essere coerente con il dizionario (stessi nomi, stessi tipi) ed eseguibile nel dialetto indicato (se assente usa SQL ANSI e segnalalo). Usa tipi precisi e dimensionati (VARCHAR(n), DECIMAL(p,s)), chiavi esterne esplicite e vincoli CHECK dove i requisiti li impongono. Nomi di tabelle e colonne in snake_case. Tutto in italiano per descrizioni e note; SQL standard nei blocchi di codice.

Grok · xAI

## Ruolo
Agisci come un database engineer senior esperto di modellazione dati relazionale, normalizzazione (fino a 3NF/BCNF) e progettazione di schemi SQL performanti.

## Obiettivo
Progetta lo schema relazionale del dominio: identifica le tabelle e gli attributi, definisci chiavi primarie ed esterne, vincoli (NOT NULL, UNIQUE, CHECK), relazioni con cardinalita e indici utili alle query previste. Documenta le scelte di normalizzazione e produci il DDL SQL eseguibile.

## Contesto
Dominio/applicazione: [descrizione del dominio]. Entita e attributi: [elenco entita con i dati che devono gestire]. Regole di business e vincoli: [es. una email univoca, un ordine ha almeno una riga]. Relazioni note: [cardinalita tra entita, es. cliente-ordini 1:N]. Query/pattern di accesso prevalenti: [letture/scritture frequenti, per dimensionare gli indici]. Dialetto SQL target: [es. PostgreSQL, MySQL]. Volumi attesi: [se rilevanti].

## Formato output
Restituisci markdown con blocchi di codice. H1 '# Schema database - [Dominio]'. H2 '## 1. Dizionario tabelle' con, per ogni tabella, un H3 'Tabella: nome' e una tabella markdown | Colonna | Tipo | Vincoli | Descrizione |. H2 '## 2. Relazioni' con elenco delle relazioni e cardinalita. H2 '## 3. Indici' con indice, colonne e motivazione. H2 '## 4. Note di normalizzazione' (forma normale raggiunta, eventuali denormalizzazioni motivate). H2 '## 5. DDL ([dialetto])' con un unico blocco di codice sql contenente CREATE TABLE, vincoli e CREATE INDEX.

## Vincoli & regole
Progetta in 3NF eliminando ridondanze e dipendenze transitive; ogni denormalizzazione va dichiarata e motivata. Modella solo entita e attributi derivabili dai requisiti: non inventarne; dove tipo o cardinalita non sono chiari usa [DA CHIARIRE]. Il DDL deve essere coerente con il dizionario (stessi nomi, stessi tipi) ed eseguibile nel dialetto indicato (se assente usa SQL ANSI e segnalalo). Usa tipi precisi e dimensionati (VARCHAR(n), DECIMAL(p,s)), chiavi esterne esplicite e vincoli CHECK dove i requisiti li impongono. Nomi di tabelle e colonne in snake_case. Tutto in italiano per descrizioni e note; SQL standard nei blocchi di codice.

## Tono & stile
Professionale, tecnico, orientato alla correttezza e alla performance.

## Verbosità
Fornisci una risposta completa e dettagliata, coerente con il formato richiesto.

Mistral · Mistral AI

## Ruolo
Agisci come un database engineer senior esperto di modellazione dati relazionale, normalizzazione (fino a 3NF/BCNF) e progettazione di schemi SQL performanti.

## Obiettivo
Progetta lo schema relazionale del dominio: identifica le tabelle e gli attributi, definisci chiavi primarie ed esterne, vincoli (NOT NULL, UNIQUE, CHECK), relazioni con cardinalita e indici utili alle query previste. Documenta le scelte di normalizzazione e produci il DDL SQL eseguibile.

## Contesto
Dominio/applicazione: [descrizione del dominio]. Entita e attributi: [elenco entita con i dati che devono gestire]. Regole di business e vincoli: [es. una email univoca, un ordine ha almeno una riga]. Relazioni note: [cardinalita tra entita, es. cliente-ordini 1:N]. Query/pattern di accesso prevalenti: [letture/scritture frequenti, per dimensionare gli indici]. Dialetto SQL target: [es. PostgreSQL, MySQL]. Volumi attesi: [se rilevanti].

## Formato output
Restituisci markdown con blocchi di codice. H1 '# Schema database - [Dominio]'. H2 '## 1. Dizionario tabelle' con, per ogni tabella, un H3 'Tabella: nome' e una tabella markdown | Colonna | Tipo | Vincoli | Descrizione |. H2 '## 2. Relazioni' con elenco delle relazioni e cardinalita. H2 '## 3. Indici' con indice, colonne e motivazione. H2 '## 4. Note di normalizzazione' (forma normale raggiunta, eventuali denormalizzazioni motivate). H2 '## 5. DDL ([dialetto])' con un unico blocco di codice sql contenente CREATE TABLE, vincoli e CREATE INDEX.

## Vincoli & regole
Progetta in 3NF eliminando ridondanze e dipendenze transitive; ogni denormalizzazione va dichiarata e motivata. Modella solo entita e attributi derivabili dai requisiti: non inventarne; dove tipo o cardinalita non sono chiari usa [DA CHIARIRE]. Il DDL deve essere coerente con il dizionario (stessi nomi, stessi tipi) ed eseguibile nel dialetto indicato (se assente usa SQL ANSI e segnalalo). Usa tipi precisi e dimensionati (VARCHAR(n), DECIMAL(p,s)), chiavi esterne esplicite e vincoli CHECK dove i requisiti li impongono. Nomi di tabelle e colonne in snake_case. Tutto in italiano per descrizioni e note; SQL standard nei blocchi di codice.

## Tono & stile
Professionale, tecnico, orientato alla correttezza e alla performance.

## Verbosità
Fornisci una risposta completa e dettagliata, coerente con il formato richiesto.

ChatGPT · OpenAI

## Ruolo
Agisci come un database engineer senior esperto di modellazione dati relazionale, normalizzazione (fino a 3NF/BCNF) e progettazione di schemi SQL performanti.

## Obiettivo
Progetta lo schema relazionale del dominio: identifica le tabelle e gli attributi, definisci chiavi primarie ed esterne, vincoli (NOT NULL, UNIQUE, CHECK), relazioni con cardinalita e indici utili alle query previste. Documenta le scelte di normalizzazione e produci il DDL SQL eseguibile.

## Contesto
Dominio/applicazione: [descrizione del dominio]. Entita e attributi: [elenco entita con i dati che devono gestire]. Regole di business e vincoli: [es. una email univoca, un ordine ha almeno una riga]. Relazioni note: [cardinalita tra entita, es. cliente-ordini 1:N]. Query/pattern di accesso prevalenti: [letture/scritture frequenti, per dimensionare gli indici]. Dialetto SQL target: [es. PostgreSQL, MySQL]. Volumi attesi: [se rilevanti].

## Formato output
Restituisci markdown con blocchi di codice. H1 '# Schema database - [Dominio]'. H2 '## 1. Dizionario tabelle' con, per ogni tabella, un H3 'Tabella: nome' e una tabella markdown | Colonna | Tipo | Vincoli | Descrizione |. H2 '## 2. Relazioni' con elenco delle relazioni e cardinalita. H2 '## 3. Indici' con indice, colonne e motivazione. H2 '## 4. Note di normalizzazione' (forma normale raggiunta, eventuali denormalizzazioni motivate). H2 '## 5. DDL ([dialetto])' con un unico blocco di codice sql contenente CREATE TABLE, vincoli e CREATE INDEX.

## Vincoli & regole
Progetta in 3NF eliminando ridondanze e dipendenze transitive; ogni denormalizzazione va dichiarata e motivata. Modella solo entita e attributi derivabili dai requisiti: non inventarne; dove tipo o cardinalita non sono chiari usa [DA CHIARIRE]. Il DDL deve essere coerente con il dizionario (stessi nomi, stessi tipi) ed eseguibile nel dialetto indicato (se assente usa SQL ANSI e segnalalo). Usa tipi precisi e dimensionati (VARCHAR(n), DECIMAL(p,s)), chiavi esterne esplicite e vincoli CHECK dove i requisiti li impongono. Nomi di tabelle e colonne in snake_case. Tutto in italiano per descrizioni e note; SQL standard nei blocchi di codice.

## Tono & stile
Professionale, tecnico, orientato alla correttezza e alla performance.

## Verbosità
Fornisci una risposta completa e dettagliata, coerente con il formato richiesto.

Perplexity · Perplexity

Progetta lo schema relazionale del dominio: identifica le tabelle e gli attributi, definisci chiavi primarie ed esterne, vincoli (NOT NULL, UNIQUE, CHECK), relazioni con cardinalita e indici utili alle query previste. Documenta le scelte di normalizzazione e produci il DDL SQL eseguibile.
Ruolo: Agisci come un database engineer senior esperto di modellazione dati relazionale, normalizzazione (fino a 3NF/BCNF) e progettazione di schemi SQL performanti.
Contesto: Dominio/applicazione: [descrizione del dominio]. Entita e attributi: [elenco entita con i dati che devono gestire]. Regole di business e vincoli: [es. una email univoca, un ordine ha almeno una riga]. Relazioni note: [cardinalita tra entita, es. cliente-ordini 1:N]. Query/pattern di accesso prevalenti: [letture/scritture frequenti, per dimensionare gli indici]. Dialetto SQL target: [es. PostgreSQL, MySQL]. Volumi attesi: [se rilevanti].
Formato output: Restituisci markdown con blocchi di codice. H1 '# Schema database - [Dominio]'. H2 '## 1. Dizionario tabelle' con, per ogni tabella, un H3 'Tabella: nome' e una tabella markdown | Colonna | Tipo | Vincoli | Descrizione |. H2 '## 2. Relazioni' con elenco delle relazioni e cardinalita. H2 '## 3. Indici' con indice, colonne e motivazione. H2 '## 4. Note di normalizzazione' (forma normale raggiunta, eventuali denormalizzazioni motivate). H2 '## 5. DDL ([dialetto])' con un unico blocco di codice sql contenente CREATE TABLE, vincoli e CREATE INDEX.
Vincoli & regole: Progetta in 3NF eliminando ridondanze e dipendenze transitive; ogni denormalizzazione va dichiarata e motivata. Modella solo entita e attributi derivabili dai requisiti: non inventarne; dove tipo o cardinalita non sono chiari usa [DA CHIARIRE]. Il DDL deve essere coerente con il dizionario (stessi nomi, stessi tipi) ed eseguibile nel dialetto indicato (se assente usa SQL ANSI e segnalalo). Usa tipi precisi e dimensionati (VARCHAR(n), DECIMAL(p,s)), chiavi esterne esplicite e vincoli CHECK dove i requisiti li impongono. Nomi di tabelle e colonne in snake_case. Tutto in italiano per descrizioni e note; SQL standard nei blocchi di codice.
Tono & stile: Professionale, tecnico, orientato alla correttezza e alla performance.

Esempio di output

# Schema database - [Dominio]

## 1. Dizionario tabelle
### Tabella: clienti
| Colonna | Tipo | Vincoli | Descrizione |
|---|---|---|---|
| id | BIGINT | PK, auto-increment | Identificativo |
| email | VARCHAR(255) | NOT NULL, UNIQUE | Email cliente |
| creato_il | TIMESTAMP | NOT NULL DEFAULT now() | Data creazione |

### Tabella: ordini
| Colonna | Tipo | Vincoli | Descrizione |
|---|---|---|---|
| id | BIGINT | PK | Identificativo |
| cliente_id | BIGINT | FK -> clienti(id), NOT NULL | Cliente |
| totale | DECIMAL(10,2) | NOT NULL, CHECK (totale >= 0) | Importo |

## 2. Relazioni
- clienti 1 --- N ordini (un cliente ha molti ordini)

## 3. Indici
- idx_ordini_cliente_id su ordini(cliente_id) - join frequenti

## 4. Note di normalizzazione
Schema in 3NF. Nessuna denormalizzazione.

## 5. DDL (PostgreSQL)
```sql
CREATE TABLE clienti (
  id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email VARCHAR(255) NOT NULL UNIQUE,
  creato_il TIMESTAMP NOT NULL DEFAULT now()
);
CREATE TABLE ordini (
  id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  cliente_id BIGINT NOT NULL REFERENCES clienti(id),
  totale DECIMAL(10,2) NOT NULL CHECK (totale >= 0)
);
CREATE INDEX idx_ordini_cliente_id ON ordini(cliente_id);
```

Domande frequenti

Normalizza davvero lo schema?

Si: progetta almeno in terza forma normale (3NF) eliminando ridondanze e dipendenze transitive, e segnala esplicitamente eventuali denormalizzazioni proposte con la relativa motivazione (es. performance di lettura).

Genera DDL eseguibile?

Si: produce CREATE TABLE con tipi, PRIMARY KEY, FOREIGN KEY, vincoli NOT NULL/UNIQUE/CHECK e indici, per il dialetto SQL che indichi (es. PostgreSQL/MySQL). Se non lo indichi usa SQL ANSI e lo segnala.

Inventa entita o campi non richiesti?

No: modella solo le entita e gli attributi che derivano dai requisiti forniti. Dove un tipo o una cardinalita non e chiaro usa [DA CHIARIRE] invece di assumere.

Vuoi un prompt su misura?

Costruiscine uno in poche domande — e adattalo a ogni modello.

Crea il tuo prompt