Forum libero

- Scritto da: The Lich
> (+ teorica che pratica)
> in pratica è facile da risolvere, il mio dubbio è
> piuttosto di natura
> teorica.
>
> Comunque, supponiamo di avere un insieme di dati
> ordinati
> gerarchicamente:
>
> Stato
> Regione
> Provincia
> Località
>
> si crea un insieme di tabelle in cui la relazione
> gerarchica o di ereditarietà viene espressa
> esportando nella tabella inferiore l' id del
> campo superiore, ad
> esempio:
>
> tabella provincia:
> id_provincia   
> id_regione
> nome_provincia
>
> supponiamo poi di avere un dato definito in
> maniera tale che un suo campo è la località. Fin
> qui nulla di strano, la tabella del dato avrà un
> id_localita e con una serie di join sarà
> possibile ricostruire tutte le relazioni dalla
> località allo
> stato.
>
> Supponiamo ora di avere invece un dato poco
> definito, nel senso che non è in relazione con
> una località ma con una provincia o addirittura
> uno
> stato.
> In pratica si potrebbero importare nella tabella
> di questo dato tutti gli id: id_stato,
> id_regione, id_provincia etc come campi non
> obbligatori e pertanto lasciare vuoti quelli non
> definiti.
>
> Il mio dubbio è il seguente: questo modo di
> procedere in un databse relazionale come mYSQL
> non viola le regole per la riduzione alla terza
> forma normale?
>
> E' un approccio teoricamente legittimo o è
> applicabile solo nella pratica
> comune?
>
> The Lich™
>
> [img]http://www.gamewyrd.com/previews/bottledimp/i

Ma utilizzare un database serio come Access, invece che quella ciofeca di MySQL?

- Scritto da: The Lich
> (+ teorica che pratica)
> in pratica è facile da risolvere, il mio dubbio è
> piuttosto di natura
> teorica.
>
> Comunque, supponiamo di avere un insieme di dati
> ordinati
> gerarchicamente:
>
> Stato
> Regione
> Provincia
> Località
>
> si crea un insieme di tabelle in cui la relazione
> gerarchica o di ereditarietà viene espressa
> esportando nella tabella inferiore l' id del
> campo superiore, ad
> esempio:
>
> tabella provincia:
> id_provincia   
> id_regione
> nome_provincia
>
> supponiamo poi di avere un dato definito in
> maniera tale che un suo campo è la località. Fin
> qui nulla di strano, la tabella del dato avrà un
> id_localita e con una serie di join sarà
> possibile ricostruire tutte le relazioni dalla
> località allo
> stato.
>
> Supponiamo ora di avere invece un dato poco
> definito, nel senso che non è in relazione con
> una località ma con una provincia o addirittura
> uno
> stato.
> In pratica si potrebbero importare nella tabella
> di questo dato tutti gli id: id_stato,
> id_regione, id_provincia etc come campi non
> obbligatori e pertanto lasciare vuoti quelli non
> definiti.
>
> Il mio dubbio è il seguente: questo modo di
> procedere in un databse relazionale come mYSQL
> non viola le regole per la riduzione alla terza
> forma normale?
>

Dipende dalle relazioni tra gli attributi non chiave... in poche parole BUH, potrebbe.

> E' un approccio teoricamente legittimo o è
> applicabile solo nella pratica
> comune?
>

Per esperienza la normalizzazione non è il sacro graal, ci possono essere buoni motivi per avere una base di dati non completamente normalizzata. Anzi, a volte dopo averla normalizzata fai uno step indietro per motivi di performance o perchè in teoria certi dati dovrebbero essere definiti in un certo modo ma questo va a scontrarsi con l'uso che ne fanno gli utenti.

- Scritto da: The Lich
> (+ teorica che pratica)
> in pratica è facile da risolvere, il mio dubbio è
> piuttosto di natura
> teorica.
>
> Comunque, supponiamo di avere un insieme di dati
> ordinati
> gerarchicamente:
>
> Stato
> Regione
> Provincia
> Località
>
> si crea un insieme di tabelle in cui la relazione
> gerarchica o di ereditarietà viene espressa
> esportando nella tabella inferiore l' id del
> campo superiore, ad
> esempio:
>
> tabella provincia:
> id_provincia   
> id_regione
> nome_provincia
>
> supponiamo poi di avere un dato definito in
> maniera tale che un suo campo è la località. Fin
> qui nulla di strano, la tabella del dato avrà un
> id_localita e con una serie di join sarà
> possibile ricostruire tutte le relazioni dalla
> località allo
> stato.
>
> Supponiamo ora di avere invece un dato poco
> definito, nel senso che non è in relazione con
> una località ma con una provincia o addirittura
> uno
> stato.
> In pratica si potrebbero importare nella tabella
> di questo dato tutti gli id: id_stato,
> id_regione, id_provincia etc come campi non
> obbligatori e pertanto lasciare vuoti quelli non
> definiti.
>
> Il mio dubbio è il seguente: questo modo di
> procedere in un databse relazionale come mYSQL
> non viola le regole per la riduzione alla terza
> forma normale?
>
> E' un approccio teoricamente legittimo o è
> applicabile solo nella pratica
> comune?
>
> The Lich™
>
> [img]http://www.gamewyrd.com/previews/bottledimp/i

se pensiamo a stato provincia località come alle specializzazioni di uno stesso concetto, chiamato ad esempio zona, potresti produrre una relazione tra zona e dato poco_definito

tradotto poi dallo schema concettuale allo schema logico diverrebbero comunque tre tabelle e se la relazione è 1-n tre campi nella tabella che rappresenta il dato poco_definito

IMHO

- Scritto da: The Lich

>
> Supponiamo ora di avere invece un dato poco
> definito, nel senso che non è in relazione con
> una località ma con una provincia o addirittura
> uno
> stato.

c'è qualcosa che non funge nell'analisi dei requisiti

- Scritto da: The Lich
> (+ teorica che pratica)
> in pratica è facile da risolvere, il mio dubbio è
> piuttosto di natura
> teorica.
>
> Comunque, supponiamo di avere un insieme di dati
> ordinati
> gerarchicamente:
>
> Stato
> Regione
> Provincia
> Località
>
> si crea un insieme di tabelle in cui la relazione
> gerarchica o di ereditarietà viene espressa
> esportando nella tabella inferiore l' id del
> campo superiore, ad
> esempio:
>
> tabella provincia:
> id_provincia   
> id_regione
> nome_provincia
>
> supponiamo poi di avere un dato definito in
> maniera tale che un suo campo è la località. Fin
> qui nulla di strano, la tabella del dato avrà un
> id_localita e con una serie di join sarà
> possibile ricostruire tutte le relazioni dalla
> località allo
> stato.
>
> Supponiamo ora di avere invece un dato poco
> definito, nel senso che non è in relazione con
> una località ma con una provincia o addirittura
> uno
> stato.
> In pratica si potrebbero importare nella tabella
> di questo dato tutti gli id: id_stato,
> id_regione, id_provincia etc come campi non
> obbligatori e pertanto lasciare vuoti quelli non
> definiti.
>
> Il mio dubbio è il seguente: questo modo di
> procedere in un databse relazionale come mYSQL
> non viola le regole per la riduzione alla terza
> forma normale?
>
> E' un approccio teoricamente legittimo o è
> applicabile solo nella pratica
> comune?
>
> The Lich™
>
> [img]http://www.gamewyrd.com/previews/bottledimp/i

vedi qual'è un'utilità delle relazioni sociali? questa: chiedere un parere- consiglio- aiuto o quant'altro.


Se non ci fosse il forum con chi parleresti/chiederesti pareri? Agli alberi?

In ogni tabella (località, provincia, regione, paese, pianeta...) aggiungi ai record esistenti un record indefinito.

Immagino un'interfaccia dove assegni al record di un minerale i valori dei vari campi da caselle a discesa, partendo dalle proprietà gerarchicamente superiori - per un minerale di cui sai tutto sceglieresti:

Stato: Italia

(la casella delle regioni si popola con le regioni d'Italia)

Regione: Piemonte

(la casella delle province si popola con le province piemontesi)

Provincia: Torino

(la casella dei comuni si popola con i comuni della provincia di Torino)

Supponi ora di introdurre i campi indefiniti negli elenchi, e di classificare un minerale di cui sai solo che proviene dal Piemonte.

Stato: Italia

(la casella delle regioni si popola con le regioni d'Italia, più "regione indefinita")

Regione: Piemonte

(la casella delle province si popola con le province piemontesi, più "provincia indefinita")

Provincia: Indefinita

(la casella dei comuni si popola con la sola voce "indefinito")

Mi resta qualche dubbio sull'appartenenza degli indefiniti o meno ai record gerarchicamente superiori: se ad esempio la provincia "indefinita" che scegli dall'elenco delle province del Piemonte sia, a livello teorico, una "provincia indefinita della regione Piemonte" distinta dalla "provincia indefinita della regione Liguria" ma non so se questo dubbio abbia qualche effetto pratico.

Guarda domani ti spiego come fare.
Se spiegavi subito a cosa ti serviva non mi sorbivo 89 post di cazzate e te lo spiegavo stasera.

Ciao

Non so se ho capito bene cosa vuoi fare, ma ci provo.
La gerachia territoriale va bene come hai detto, con le relazioni:

Stato {nome_stato}
Regione {nome_regione, nome_stato}
Provincia {nome_provincia, nome_regione}
Località {nome_località, nome_provincia}

e le ovvie relazioni (intese come relationship in questo caso) tra gli attributi con stesso nome.

Ho eliminato gli "id" perché a livello concettuale non hanno alcun senso, poi in un'implementazione reale puoi introdurli per ragioni di prestazioni ben sapendo che lo fai perché gli RDBMS sono implementati coi piedi (potrebbero sostituire a livello fisico i riferimenti automaticamente senza esporre numeri con poco senso agli utenti).

Per inciso nella vita reale alcune di quelle "entità" hanno un identificativo univoco diverso dal nome, ben definito e di uso comune da parte degli utenti. Per cui potresti comunque volerlo introdurre (es. codice ISO dello stato, codice della provincia).

Per il resto a livello teorico devi modellare secondo i fatti, anche se sarebbe bello un mondo ideale dove sai sempre la Località dove hai raccolto il campione e ti riporti agli altri livelli tramite la gerarchia.

Quali sono le proposizioni?

Il giorno 1/1/2008 ho raccolto un campione di quarzo in località Luino.

Il giorno 1/2/2008 ho raccolto un campione di pirite in località Legnano.

Il giorno 1/3/2008 ho raccolto un campione di azzurrite nella provincia di Milano.

Il giorno 1/4/2008 ho raccolto un campione di quarzo nella regione Lombardia.

Il giorno 1/5/2008 ho raccolto un campione di pirite nella stato italia.

Quali predicati puoi estrarre dalle precedenti proposizioni?

Il giorno d ho raccolto un campione di m in località c.
Il giorno d ho raccolto un campione di m nella provincia di p.
Il giorno d ho raccolto un campione di m nella regione r.
Il giorno d ho raccolto un campione di m nello stato r.

Le relazioni che si derivano sono:

Campione_Località
{data_raccolta, nome_minerale, nome_località}
Campione_Provincia
{data_raccolta, nome_minerale, nome_provincia}
Campione_Regione
{data_raccolta, nome_minerale, nome_regione}
Campione_Stato
{data_raccolta, nome_minerale, nome_stato}

Con le ovvie relazioni (relationship) con la gerarchia territoriale per attributi con lo stesso nome.

Questo è il modello più ovvio e con le dovute operazioni di unione e join puoi fare tutte le richeste che vuoi.

Ad esempio se vuoi sapere tutte le regioni dove hai trovato campioni di quarzo (in pseudo sql, ti risparmio il Tutorial-D e ometto gli attributi per la join assumendo che il sistema sia in grado di fare una join naturale):

SELECT    nome_regione
FROM    (
    SELECT    nome_regione
    FROM    Campione_Regione
    WHERE    nome_minerale = 'Quarzo'
    UNION
    SELECT    nome_regione
    FROM    Campione_Provincia
    JOIN    Provincia
    WHERE    nome_minerale = 'Quarzo'
    UNION
    SELECT    nome_regione
    FROM    Campione_Località
    JOIN    Località
    JOIN    Provincia
    WHERE    nome_minerale = 'Quarzo'
    )
GROUP BY
    nome_regione

A questo punto se vuoi, ma a livello concettuale sarebbe sufficiente quanto detto, puoi a livello logico usare la tecnica di "generalizzazione":

Campione
{data_raccolta, nome_minerale}
Campione_Località
{data_raccolta, nome_minerale, nome_Località}
Campione_Provincia
{data_raccolta, nome_minerale, nome_provincia}
Campione_Regione
{data_raccolta, nome_minerale, nome_regione}
Campione_Stato
{data_raccolta, nome_minerale, nome_stato}

Così a occhio sembra avere poco senso, ma è solo un preconcetto perché la relazione Campione ha solo gli attributi chiave, ma pensa di avere molti altri attributi comuni tra i 4 predicati:

Campione {data_raccolta, nome_minerale, attributo1, attributo2, .., attributoN}

Nella realtà probabilmente avrai anche un identificativo numerico univoco per il campione raccolto (cosa succede se raccogli due minerali lo stesso giorno nello stesso posto?) e puoi usare quello come chiave. Ho preferito non metterlo per semplicità e perché non è necessario dal punto di vista del modello concettuale.

Verrebbe qualcosa tipo:

Campione
{id_campione, data_raccolta, nome_minerale}
Campione_Località
{id_campione, nome_località}
Campione_Provincia
{id_campione, nome_provincia}
Campione_Regione
{id_campione, nome_regione}
Campione_Stato
{id_campione, nome_stato}

Questo è quanto dice la teoria relazionale secondo Date. Tieni conto che Codd (il padre della teoria), in una fase successiva ha provato ad introdurre alcuni concetti per le informazioni mancanti: i famosi I-mark (valore inapplicabile) e A-mark (valore applicabile ma mancante) che hanno dato origine ai NULL. Date è contro i NULL perché introducono nel modello una logica a più di 2 valori (TRUE, FALSE) complicando il linguaggio di interrogazione (in sql è a 3 valori: TRUE, FALSE e UNKNOWN).

Tieni conto che facendo un modello tipo:

Campione {data_raccolta, nome_minerale, nome_Località, nome_provincia, nome_regione, nome_stato}

non è che i valori che ti mancano sono A-mark (applicabili ma mancanti), sono proprio inapplicabili. Per questo il modello corretto è quello sopra. D'altra parte quale sarebbe il predicato della precedente relazione? E che proposizioni salterebbero fuori istanziando il predicato con i vari valori?

Detto questo, a livello fisico fai un po' quello che vuoi tanto se ne vedono di tutti i colori L'importante è farlo con cognizione, sapendo bene che ogni trade-off che fai per le prestazioni potrebbe originare problemi di integrità (logica ovviamente).

Ti sconsiglio vivamente di cercare di ragionare in questo modo (semplice e lineare) con i tecnici che leggono come fare le basi dati sui "libri seri" perché sono di un'approssimazione sconsolante.

Se decidi di intramprendere la tortuosa strada degli oggetti e dei dbms ad oggetti sappi che regna il caos e la confusione, a cominciare dalla terminologia di base. Se ti può servire per il lavoro studialo, va di moda. Se ti interessa invece l'argomento a livello personale teorico ci le estensioni al modello relazionale di Date. Tieni presente che, al contrario dei luoghi comuni degli smanettoni, nella teoria nulla vieta che un attributo di una relazione sia a sua volta una relazione. E nulla vieta che un tipo dato abbia una struttura interna complessa.