Pagina Iniziale | Preferiti Comunity: Login | Registrati | Newsletter | Forum | Concorsi Newsgroup
Canali: Hardware | Software | Files | Webmaster | Cellulari | Shop
Nel sito: News | Articoli | Files | Manuali | Consigli PC | Schede cellulari | Programmaz. | Hosting | Motori Ricerca | Glossario | Link
Servizi: Shopping | Forum | Crea un BLOG | Cartucce Compatibili | Tool News |   Sponsor: Automazione Industriale
  Articoli

Recensioni
Consigli per PC


  News e files

Software
Telefonia
Internet
Tecnologia
Files e Download


  Manualistica

Guide HW/SW
Scripts ASP
Scripts HTML
Scripts Java
Scripts Delphi
Glossario


  Shopping

Hardware
Software e Giochi
Elettronica
Cinema e Film
Console e Accessori
Prodotti Ufficio
Formazione e Corsi

Tieniti aggiornato sul mondo della tecnologia con la nostra newsletter!
La tecnologia sulla tua
casella e-mail

[Info Newsletter]


Concessionaria Pubblicitaria

<< News Precedente [Fine Pagina] News Successiva >>
Relazioni tra due tabelle: le Join

Un articolo di: Fonte Esterna del 29/05/2003      Letture: 29279

Articolo a cura di Luca Ruggiero - http://www.lukeonweb.net/

La struttura di un'applicazione, di tipo Web o meno, in virtù della teoria dei database relazionali, consiglia di suddividere in più tabelle i dati che saranno oggetto dei risultati delle query. Immaginiamo di avere un'area di accesso privato con username e password, ed una serie di informazioni personali relative agli utenti. Una soluzione intelligente sarebbe quella di inserire in una tabella username e password, ed in una seconda i dati personali.

Creiamo quindi due tabelle: login che conterrà i campi username e password, e la tabella utenti che conterrà i dati degli utenti, ad esempio i campi nome e cognome. Naturalmente le due tabelle saranno munite di un campo id di tipo contatore.

Inseriamo una serie di dati nelle due tabelle, in modo che l'esempio di codice che vedremo tra poco potrà produrre dei risultati.

Ecco il codice del file index.asp che andiamo a creare:

<%@LANGUAGE = JScript%>
<%
var username = new String(Request.QueryString("username"));
var Cn = new ActiveXObject("ADODB.Connection");
Cn.Open("driver={Microsoft Access Driver (*.mdb)};dbq=" + Server.MapPath("database.mdb"));

var joinSql = Cn.Execute(
"SELECT * FROM login INNER JOIN utenti ON login.id = utenti.id WHERE username = '" + username + "'"
);
%>
<html>
<head>
<title>Join - www.lukeonweb.net</title>
<basefont size="2" face="Verdana">
</head>
<body>
<ul>
<li><a href="index.asp?username=lukeonweb">lukeonweb</a></li>
<li><a href="index.asp?username=pippo">pippo</a></li>
</ul>
<%
with (Response)
{
Write("Nome: " + joinSql("nome") + "<br>");
Write("Cognome: " + joinSql("cognome") + "<br>");
}
%>
</body>
</html>
<%Cn.Close()%>

Le operazioni effettuate non sono diverse da una qualsiasi pagina che recupera dei dati da un database in base ad una query, effettuata grazie ad un parametro che passiamo in una QueryString. La differenza sostanziale è sulla stringa Sql che riporto nella sua fase essenziale:

SELECT * FROM login INNER JOIN utenti ON login.id = utenti.id In questo modo abbiamo messo in relazione le due tabelle col campo id. L'unica seccatura, la cui risoluzione è parte della bravura dello sviluppatore, è mantenere sempre i dati corrispondenti nelle due tabelle con lo stesso id progressivo, quindi, in fase di aggiornamento o cancellazione dei dati, è necessario compiere dette operazioni parallelamente sulle due tabelle.



[Indietro]    [Su]      [Home]      [Commenti]      [V. Stampabile]

Commento di Anonimo (ip: 151.81.9.47), scritto il 30/12/2004 alle 11:40:42

L'autore cita immediatamente la "teoria dei database relazionali", tranne poi trasgredirla ampiamente.

Username, Password, informazioni personali, sono tutti ATTRIBUTI (non campi) della stessa ENTITA' (utente) e non vanno suddivisi su tabelle differenti per una "soluzione intelligente" (più tabelle, più intelligenza?).
Un database è una raccolta di FATTI (predicati) realmente verificabili nel mondo reale, suddivisa in ENTITA'. Un singolo fatto è registrato in una RIGA di dati, a sua volta divisa in ATTRIBUTI, e indirizzabile unicamente in maniera LOGICA attraverso la combinazione di TABELLA.CHIAVE.ATTRIBUTO.

L'autore non parla minimamente di CHIAVI (assolutamente fondamentali); invece che cos'è quell'ID? Un datatype fisico, non relazionale, artificiale, che non ha nessun SIGNIFICATO nel mondo reale, e serve solo a distruggere l'INTEGRITA' dei dati; questo design di database infatti non ti impedisce di avere:

1 Rossi Mario
2 Mario Rossi
3 Rossi M.
4 Rossi Dr.Mario
5 Rossi Dr. Mario
6 Rossi Mario
7 Rossi Mario
8 Rossi Mario
9 ...

Ha totalmente mancato il senso di "modello relazionale dei dati", che è il fatto che la struttura e i VINCOLI che si settano nei database permettono ai dati di mantenere DA SOLI la propria integrità, e NON TRAMITE UN PROGRAMMA esterno!!!
Solo una corretta implementazione del giusto modello permetterà di ottenere un database che durerà nel tempo, e potrà servire PIU' APPLICAZIONI differenti, ed eviterà anomalie di AGGIORNAMENTO ai dati. E questo non deve essere "parte della bravura dello sviluppatore"!!!

Il gran finale dell'articolo, su cui veramente non si sa se ridere o piangere, è la conseguenza del design bacato del database; quello che l'autore chiama "seccatura": il database adesso è ampiamente aperto alla corruzione di dati, dati ripetuti, anomalie di aggiornamento, aggiornamenti incoerenti etc... I risultati del pessimo design sono sotto i suoi occhi, ma non si rende conto che sono dovuti all'implementazione bacata dei database!!!

E questo dovrebbe essere un articolo per i novizi? Bah

qwsa@despammed.com

Commento di Anonimo (ip: 80.182.54.219), scritto il 30/12/2004 alle 18:27:15
In effetti dal punto di vista strettamente teorico ti dovrei dar ragione, in quanto i database relazionali hanno regole rigide per evitare (tra le altre cose) perdità di integrità dei dati, regole che vengono garantite da procedure di validazione del modello quali ad esempio le famore 3 forme normali (o altre ancora).
Durante l'ottimizzazione però, che si fa tra l'altro analizzando le "tavole degli accessi" e altri strumenti di analisi del modello, si adotta ormai universalmente dei "rilassamenti" ai vincoli della pura teoria, consentendo dei casi di ridondanza dei dati ad esempio, o di suddividere in più tabelle (a livello fisico) quello che al livello concettuale era una singola entità, per garantire ove necessario i vincoli sulle prestazioni del sistema. Tutto questo però non va fatto alla buona, ma deve essere parte integrante dell'intera procedura di progettazione e realizzazione di una base di dati, e devono essere garantiti "strumenti" (eventualmente software, tramite controlli dell'applicazione di base di dati) per evitare ridondanze indesiderate e pericolose perdite di integrità dei dati.

Tutto questo non è ovviamente la prima cosa che bisognerebbe insegnare ad un novizio, ma fa comunque parte del programma base di un normale corso di basi di dati di ingegneria informatica ad esempio, per cui è giusto accennarlo.

Per quanto riguarda le tue osservazioni sul uso nel codice ASP (e quindi a livello fisico di realizzazione), il riferimento a campi quali ID che niente hanno a che fare con gli attributi di un'entità (e qui si parla di livello concettuale di progettazione, non di livello fisico! non confondere le cose) è permesso, anzi spesso è indispensabile per certe realizzazioni (non quella dell'esempio comunque), ed è comunque un campo che generalmente è sempre presente nelle realizzazioni fisiche dei database. Il problema di duplicazione cui accenni si risolve comunemente assegnando la flag unique al campo che corrisponde all'entità chiave nel modello concettuale.

Per cui, tirando le somme, ciò che viene detto nell'articolo è corretto (se supportato dai necessari strumenti e accorgimenti che derivano da un'accurata progettazione nei vari livelli precedenti), si può solo obiettare che in un novizio potrebbe generare confusione il fatto che apparentemente si violino delle regole dei database relazionali (in realtà di tratta di eccezioni permesse se adeguatamente progettate e realizzate, senza le quali alcune applicazioni complesse non solo avrebbero performance molto scadenti, ma in alcuni casi non potrebbero nemmeno essere realizzate, come mi è capitato di sperimentare in prima persona).

Commento di Anonimo (ip: 151.81.1.175), scritto il 30/12/2004 alle 23:35:26

Quoto:
"si adotta ormai universalmente dei "rilassamenti" ai vincoli della pura teoria, consentendo dei casi di ridondanza dei dati ad esempio"

La mia risposta:
"A quale velocità preferisce avere il suo dato errato, Signore?" :-)

Il rilassarsi della teoria purtroppo punta inevitabilmente alla corruzione logica dei dati, sotto forma di anomalie di consistenza e letture errate. Quello che bisogna comprendere, è che si sta tollerando la possibilità di avere dati errati in cambio di (una possibile, ma non sempre) maggior velocità. Questa è una bomba a tempo che aspetta solo che l'applicazione (che adesso è diventata la RESPONSABILE dell'integrità dei dati) si "dimentichi" (il programmatore, naturalmente!) di aggiornare in maniera consistente gli attributi di una stessa tabella (dipendenza funzionale, se non gruppi ripetuti), oppure di più tabelle (nel qual caso il presunto aumento di prestazioni si vanifica).
Quello che doveva essere il data layer, l'astrazione dei dati dalle applicazioni e dall'implementazione fisica, è stato reso application-oriented SOLO per QUEL programma; compromessa irrimediabilmente portabilità e accesso da parte di più applicazioni diverse; inoltre: i programmi (tutti!) che modificano il database si dovranno sempre ricordare di "come fare gli update", come "interpretare le letture" etc...

Quoto:
""rilassamenti" ai vincoli della pura teoria, consentendo dei casi di ridondanza dei dati ad esempio, o di suddividere in più tabelle (a livello fisico) quello che al livello concettuale era una singola entità"

No! L'implementazione in più tabelle fisiche di un'entità non è un "rilassamento della teoria"!Questo è un esempio di come i prodotti fallati portino a ragionare in maniera errata. L'errore storico degli RDBMS è quello di miscelare l'implementazione logica con quella fisica, e purtroppo anche l'affermazione del commentatore cade nel tranello: la teoria relazionale dei dati è INTENZIONALMENTE MUTA su OGNI implementazione fisica, di qualunque tipo: file, tabelle, partizioni, indici, record, velocità, etc..., proprio per lasciare posto alle innumerevoli implementazioni fisiche che si possono fare; posso avere QUALUNQUE RIDONDANZA si desideri al livello fisico, proprio perché la teoria relazionale è INTERAMENTE logica: ogni volta che cambierò il valore di un attributo, sarà il motore del database a preoccuparsi di cambiare il valore in ogni occorrenza dell'attributo, e non la tua applicazione. Vedi il vantaggio? Il DBA può cambiare l'implementazione fisica del database quante volte vuole, può fare il "fine tuning" delle prestazioni quante volte vuole, senza cambiare il codice (e la correttezza logica) di nessuna delle applicazioni che vi accedono (nessun bisogno di mettere mano al codice!): un vantaggio ENORME!
"Suddividere in più tabelle fisiche una singola entità" NON è vietato! Ma ormai tutti sono così assuefatti a trasgredire, che "se va bene, è proprio perché abbiamo saltato le regole".
Senza parlare poi che anche l'SQL fa la sua parte, CREATE INDEX: una struttura fisica in linguaggio ad alto livello... puah.

Continuando, sul "campo" ID:
"...ed è comunque un campo che generalmente è sempre presente nelle realizzazioni fisiche dei database."
Si, esattamente come sono comuni i database di qualità bassa/nulla.

"Il problema di duplicazione cui accenni si risolve comunemente assegnando la flag unique al campo che corrisponde all'entità chiave nel modello concettuale."
No! Il problema è che non si applica correttamente la teoria!
La colonna ID, aggiunta sempre da tutti i novizi perché quella maledetta "autocomposizione tabella", "wizard" (o come-vuolesi-chiamare il dispositivo che illude di saper disegnare un database) propone in automatico un datatype proprietario, non relazionale, non portabile, non verificabile nella realtà, viene assunta immancabilmente come CHIAVE PRIMARIA (ecco l'errore!!!).
E cos'è il "flag unique"? Stai progettando un database pensando ai bottoni della tua interfaccia, e non alla teoria relazionale dei DATI (non dei database!). VINCOLO, vincolo unique, e non devi metterlo DOPO aver disegnato la tabella (infatti è errato: una persona PUO' avere omonimi, vedi come errore genera errore?). Se prima non si identificano le chiavi corrette, non si ha alcuna possibilità di avere dati corretti (intesi come PREDICATI, fatti che nel mondo reale sono veri). All'atto della definizione della chiave primaria (pensata prima di accendere il computer), un almeno decente RDBMS applica sempre alcune caratteristiche proprie delle chiavi: UNIVOCO, NON NULL, a differenza del vincolo unique che, risibilmente, permette UN null (risata), ma non un secondo null (doppia risata). Con quel design avresti il "Signor NULL".
Con in mente questo, torniamo all'articolo: che design è quello, con nessuna chiave primaria REALE, solo un ID? E' chiaro adesso l'incredibile nonsenso del design? Questo è l'errore che fanno i novizi, ed è quello che si INSEGNA, purtroppo!!!

E adesso, gran finale:

"Per cui, tirando le somme, ciò che viene detto nell'articolo è corretto"
NO NO! E' fondalmentalmente sbagliato, e non avrà alcuna possibilità di creare database corretti! Non vedi quanti errori su solo due tabelle?

"se supportato dai necessari strumenti e accorgimenti"
Una buona conoscenza dei FONDAMENTI della teoria e un RDBMS è tutto quello che ti serve per il data layer, unito ad un application server per le business rules, ed alla tecnologia di presentazione che preferisci. Vedrai che non servono "accorgimenti". L'informatica non si fa con gli accorgimenti!!! Il settore è piagato dalla bassa qualità, non si può tollerare, men che meno INSEGNARE.

"si può solo obiettare che in un novizio potrebbe generare confusione il fatto che apparentemente si violino delle regole dei database relazionali"
No no no! E' una sonora violazione delle regole fondanti della teoria! E che cos'è quell'"apparentemente"? Svengo...

qwsa@despammed.com

Commento di Anonimo (ip: 151.81.3.232), scritto il 31/12/2004 alle 11:27:43

Gourmet: l'Università e il "corso"

Quoto:
"si adotta ormai universalmente dei "rilassamenti" ai vincoli della pura teoria [...] Tutto questo non è ovviamente la prima cosa che bisognerebbe insegnare ad un novizio, ma fa comunque parte del programma base di un normale corso di basi di dati di ingegneria informatica ad esempio, per cui è giusto accennarlo."

Mi auguro caldamente che tu non sia un laureato, non posso accettare la tua linea di pensiero.

Non posso accettare che anche l'università abbia abdicato al suo ruolo di eccellenza (scuola di pensiero), per "rilassarsi", ovvero accettare COMPROMESSI.
Non posso accettare che un laureato faccia passare quietamente e sottilmente l'idea che la TEORIA E' UN INTRALCIO nel design di un database!

Come credono i laureati di far valere sul mercato la loro laurea, quando in questo modo loro stessi svalutano l'importanza della conoscenza teorica?
Una delle cose che dovrebbe dare l'università (ed uno dei motivi che distinguono il laureato) è la "forma mentis", che sa riconoscere e astrarre gli elementi del problema indipendentemente dalla forma in cui si presentano. Inoltre, il fatto di ricevere conoscenza teorica pura (benché sia materia per i detrattori), deve essere un motivo di VANTO per il laureato. L'educazione ricevuta (forma mentis + teoria pura) resterà per sempre, perché è scienza; un corso invece durerà fino alla prossima versione del prodotto!

I laureati siano ORGOGLIOSI della loro conoscenza, e non si facciano mettere nel sacco da uno smanettone che aggiunge chiavi ID perché "rilassa" i vincoli sui dati, permettendo un "miglior controllo" e denormalizza per "migliori prestazioni".

Dove sono i laureati che spingono per un corretto design? Dov'è la sonora stroncatura di quel scandaloso design, e soprattutto del fatto che lo si insegni ai novizi (molto, molto più grave)?
Dov'è il pensiero critico (verso i RDBMS bacati, verso le università stesse che rinunciano al loro ruolo)?
Perché non si spinge il ragionamento nella direzione giusta (miglior design, migliori prodotti in commercio) e invece si accetta quietamente una caduta verso il basso nella teoria e nella pratica?
L'Università sta diventando serva del mercato, e la tendenza sta peggiorando!


qwsa@despammed.com


Commento di Anonimo (ip: 80.182.54.219), scritto il 03/01/2005 alle 13:25:42
Condivido quello che hai scritto, tant'è che è anche il mio pensiero (soprattutto per quanto riguarda il tuo ultimo commento sull'università, anche per esperienza), il fatto è che hai travisato un po' il senso delle cose.

Primo, questo articolo non parla di progettazione, ma di una soluzione a livello di codice ASP e implementazione fisica delle tabelle, quindi non puoi attaccarne presunti errori di progettazione, qui l'unica cosa che si afferma è il dividere in due tabelle a livello di implementazione fisica la tabella che deriva nei passi successivi dalla rappresentazione di un'entità. Tutto questo è lecito anche per la teoria, in quanto non riguarda la teoria relazionale dei dati, che come giustamente affermi anche tu non tratta il livello fisico dal quale astrae.
E ripeto, è una pratica a livello di implementazione fisica contemplata dalla teoria (non quella relazionale che non c'entra qui), e della teoria stessa fanno parte i vincoli sulla progettazione dell'applicazione che devono garantire l'integrità dei dati. Da questo non prescinde (e non deve prescindere) la correttezza di un data-base fisico, altrimenti allora si potrebbe dire che uno stesso DBMS non garantisce necessariamente la correttezza e l'integrità perchè è un'implementazione fisica "a righe di codice" di una teoria (che sia quella relazionale o altre poco importa), in quanto errori di programmazione ci potrebbero essere anche in quelle procedure che sono pur sempre scritte da esseri umani non infallibili...

Per tutte le tue osservazioni, non le commento ad una ad una perchè non è questo il luogo (se ti interessa comunque la mia mail è pubblicata nel sito). Dico solo che quello che affermi è condivisibile, ma le critiche che muovi vengono dal fatto che non distingui quando parlo di livello fisico o di livello di analisi e progettazione. A livello di progettazione ovviamente sono d'accordo con quello che dici, ma quello di cui si parla in questa news, e quello cui mi riferivo, non c'entra niente con ciò.

Detto questo, la progettazione di una base di dati deve assolutamente prescindere dall'implementazione fisica della base stessa o dell'applicazione, e va progettata correttamente secondo la teoria scelta (ad es. quella relazionale), seguendo strettamente tutte le imposizioni della stessa, e dopo va verificata la correttezza e l'ottimizzazione con verifiche quali le forme normali ad esempio. Fin qui siamo d'accordo. E qui finisce la teoria relazionale e il livello logico (vado a memoria per i nomi dei livelli che potrei sbagliare ma il risultato non cambia).
Poi vanno analizzate le operazioni e si creano strumenti quali tavole degli accessi ecc.
Da questi si fanno analisi e progettazioni ulteriori e si valutano eventuali implementazioni di tabelle, ma ovviamente non devono andare in contrasto con la progettazione fatta in precedenza, pena la perdita di validità dell'intera base di dati.
A questo punto (più o meno) si procede alla realizzazione fisica di base di dati e applicazione/i, e qui, grazie anche alle analisi precedenti, ad esempio si può decidere di dividere la tabella "utente del forum" che deriva dalla realtiva entità "utente del forum" in due tabelle (ognuna con tutti i vincoli individuati in precedenza da rispettare) in cui in una ci sarà la chiave primaria (che sia un ID, il nick, o altro, non è importante cosa sia, ma che verifichi i requisiti individuati in sede di progettazione), il login e la password; nell'altra ci sarà sempre la chiave primaria, la foto, la firma, e tutti gli altri dati (magari alcune centinaia di KB o più) dell'utente. Questo serve per non impallare il server se l'operazione più frequente è il solo login (decine al secondo o anche molto più), mentre l'accesso agli altri dati è raro. Spesso questo accorgimento fa la differenza tra un sistema fisicamente non realizzabile (causa richieste eccessive per qualsiasi HW) e uno realizzabile. Sta poi all'applicazione fare in modo che le due tabelle rispondano a tutti i vincoli individuati dalla teoria relazionale per la tabella originale, oltre ai vincoli aggiuntivi dovuti alla "divisione" in due. E' un esempio un po' tanto per dire, ma il concetto è quello.
E tutto questo non c'entra con la correttezza della teoria relazionale che si ferma ai livelli superiori, e non comporta necessariamente un data base fallato o non manutenibile, in quanto anche la manutenzione passa per una fase di analisi e progettazione, lavorando su quanto fatto in precedenza. Spesso poi direttamente i DBMS consentono di gestire realizzazioni di questo tipo.

All'università poi, grazie a dio, si insegna ancora proprio la forma mentis, e nessun DBMS o realizzazione in particolare. Ma della forma mentis fanno parte tutte le fasi di realizzazione della progettazione concettuale a quella fisica, ovviamente astraendo da implementazioni particolari.

Personalmente poi ho apprezzato PostgreSQL proprio per la sua correttezza formale e per l'aderenza a tutte le regole della teoria relazionale. MySQL ad esempio prima delle ultimissime versioni era molto lacunoso in tal senso...

Commento di Anonimo (ip: 151.81.1.228), scritto il 06/01/2005 alle 12:14:14
"Primo, questo articolo non parla di progettazione, ma di una soluzione a livello di codice ASP e implementazione fisica delle tabelle, quindi non puoi attaccarne presunti errori di progettazione, qui l'unica cosa che si afferma è il dividere in due tabelle a livello di implementazione fisica la tabella"

Mi ero reso perfettamente conto che l'articolo non ha il suo focus sui DB relazionali. Inoltre non ho alcun interesse ad attaccare un singolo articolo o singola persona (sarebbe futile, la posta in gioco è MOLTO più alta). Credo inoltre che tu sia una cara persona, ma no, non ha senso scriversi in email: della conoscenza devono beneficiare tutti.

Comunque, non è solo questione di implementazione (benché tu e l'autore forse lo pensiate); inoltre il fatto che si parli di codice ASP non lo rende 'zona franca' dalla teoria; l'autore stesso lo riconosce: "La struttura di un'applicazione, *di tipo Web o meno*, in virtù della teoria dei database relazionali, " etc...

Il design del db dell'articolo IMPLICA vari errori di progettazione (la dimostrazione seguirà, assieme ad una soluzione), e tristemente è lo standard del settore. Gli errori sono lì, sotto il naso, ma nessuno sembra rendersene conto (chiara mancanza dei fondamenti di teoria).
Inoltre, non ci si accorge che si sta modificando il livello logico dei dati, credendo di lavorare solo sul livello fisico (se sei obbligato a cambiare la query, ti rendi conto che è cambiata la logica o no?).

Non si realizza che si sta usando un RDBMS come fosse un tool al servizio di una singola applicazione; inoltre quasi nessuno si rende conto che sta 'sporcando' il design logico con una discutibile implementazione fisica. Le 'vie di mezzo' non soddisfano né una causa né l'altra.

L'autore dei post precedenti, prima espone correttamente il senso della divisione nei layer, per poi fare marcia indietro, in un balletto del tipo qui-lo-dico-e-qui-lo-nego che dura per tutto il messaggio.
Prima ancora che di teoria relazionale dei dati, parliamo del paradigma di programmazione a strati:
1° Presentation tier: L'interfaccia che mostra e raccoglie i dati all'utente.
2° Middle tier (o business logic o conceptual tier): La logica dell'applicazione che elabora i processi e prende decisioni di tipo 'business', specifiche dell'attività considerata.
3° Data tier: Strato dei dati; conosce le regole formali che governano i dati; nel nostro caso, il RDBMS
"4°" Storage fisico (assolutamente non uno strato logico, in realtà compreso nel terzo, ma esposto qui solo per il nostro ragionamento)

Ad.esempio, su internet:
1° Browser -> 2° ASP -> 3° RDBMS -> 4° Filesystem
Oppure su lan:
1° Terminale client -> 2° Application Server -> 3° RDBMS -> 4° Filesystem
Naturalmente la divisione logica prescinde dalla locazione fisica dei componenti.
Invece la visione dell'articolo, dei post, è:
1° Browser -> 2° ASP + Data Logic -> 3° Assente -> 4° Database come fosse lo strato fisico
Da cosa lo deduco? Lo dice l'autore stesso:
"si può decidere di dividere la tabella "utente del forum" che deriva dalla relativa entità "utente del forum" in due tabelle [...] Sta poi **all'applicazione** fare in modo che le due tabelle rispondano a tutti i vincoli individuati dalla teoria relazionale per la tabella originale, oltre ai vincoli aggiuntivi dovuti alla "divisione" in due."
Visto? Guarda a che livello sta l'applicazione e a quale stanno i dati: hai fuso il data layer (3) con l'application logic (2). La divisione in layer prescrive proprio che l'applicazione NON è e non deve essere interessata ai dettagli dell'implementazione. E guarda che fine hai fatto fare al database! L'hai fatto diventare un disk-writer !! Mi dispiace, è un grave errore fondamentale, che non potrà che aggravarsi con l'aumentare della complessità del database.
La frase deve essere così corretta: "Non si può decidere di dividere la tabella utente in due tabelle, sarebbe una violazione del modo in cui si presentano i dati. Sta invece al MOTORE DI DATABASE fare in modo che il database presenti SEMPRE la medesima visione logica dei dati; sta inoltre al motore di database mantenere i vincoli aggiuntivi dovuti l'implementazione fisica modificata per l'aumento delle prestazioni".

Perché insisto tanto sulla correttezza formale? Primo perché il nostro settore è piagato dalla bassa qualità delle produzioni. Inoltre, il settore dei database è uno dei pochi in cui una teoria provata e ampiamente condivisa, specifica nei dettagli la sua realizzazione (logica).
Incredibilmente, è forse il settore maggiormente incompreso dell'intero settore informatico, e mi dispiace vedere che l'uso prevalente detti legge.

Quello che molti continuano a non capire, è che stanno sacrificando per sempre portabilità, mantenibilità, e purtroppo integrità dei dati, per salvare anche l'ultimo ciclo di clock del processore (e spesso lo riperdono in seguito!); questa non può essere un'opzione. Inoltre, in un contesto dove il costo degli errori è in continuo aumento, i MHZ si sprecano e lo spazio disco sta costando come l'aria, privilegiare le prestazioni a discapito del design è semplicemente 'puntare sul cavallo sbagliato'.

Continuando a portare esempi errati, uno alla fine crede davvero che si faccia così. E' meglio non aspettare un danno per cominciare ad apprezzare la correttezza formale della teoria relazionale.

qwsa@despammed.com


Commento di Anonimo (ip: 151.81.1.228), scritto il 06/01/2005 alle 12:15:01

Quello che segue è il tentativo di esporre come l'applicazione ragionata della teoria porti a risultati drammaticamente differenti dal design del database dell'articolo di apertura; i rudimenti di teoria qui esposti devono intendersi come ulteriore stimolo all'approfondimento.


La Teoria Relazionale dei Dati è l'applicazione della teoria degli insiemi e della logica dei predicati alla gestione dei database. Essa regola sia l'implementazione LOGICA dei CONCETTI che regolano un'attività ('modellazione'), sia le caratteristiche che un prodotto software (RDBMS) deve avere per potersi correttamente definire 'relazionale' ; lo scopo del database è di catturare la porzione di realtà che interessa descrivere attraverso FATTI (proposizioni) che sono veri (e verificabili) nel mondo reale; come conseguenza, i risultati che fornisce devono a loro volta essere veri (in quanto sottoinsiemi del segmento di realtà catturato dal database).
Il fine è quello di astrarre il livello dei dati dalle applicazioni da una parte, e dall'implementazione fisica dall'altra.

La struttura fondamentale della teoria è la RELAZIONE: gli ATTRIBUTI di un'entità sono in relazione e formano un TUPLE (una singola riga di dati), identificato univocamente attraverso l'uso di CHIAVI.
Una delle regole fondamentali è: "Ogni entità deve avere un singolo soggetto".

Esaminiamo le affermazioni dell'articolo:
"La struttura di un'applicazione, di tipo Web o meno, in virtù della teoria dei database relazionali, consiglia di suddividere in più tabelle i dati che saranno oggetto dei risultati delle query."

Un database ben disegnato deve poter fornire risultati coerenti a qualunque applicazione lo richieda, indipendentemente dalla struttura del programma che lo interroga. Pertanto l'affermazione "La struttura di un'applicazione [si, UNA] consiglia di suddividere in più tabelle i dati" è un esempio tipico della confusione tra il livello fisico e quello logico, oggigiorno prevalente. Invece, il database deve poter servire OGNI applicazione con dati corretti.
Purtroppo qui si va anche più in basso: l'autore ha in mente di disegnare il database in base alle singole query (l'esempio della procedura di login). Pertanto il design non durerà solo fino al cambio dell'applicazione, ma fino al cambio di una query!

Esempio di una query in un database modellato correttamente:

SELECT nick FROM utenti

La soprastante rappresenta la forma logicamente corretta di interrogare una base dati: "Restituiscimi le password relative agli utenti". L'applicazione descrive solo IL RISULTATO che vuole ottenere, non COME ottenerlo. Questo è il vero succo della "data indipendence".

La stessa query nel database dell'articolo:

SELECT nick FROM login INNER JOIN utenti ON login.id = utenti.id

Vedete? Siccome è stata aggiunta la colonna ID, che non ha un significato logico, è necessario un ulteriore join per ottenere dati che abbiano un qualche significato logicamente interpretabile.
L'applicazione (in questo caso lo script ASP) ha perso l'indipendenza dai dati, perché sta specificando COME recuperare i dati, e non il semplicemente risultato che vuole ottenere.
Contemporaneamente (e più grave ancora), il database non potrà rispondere alla semplice domanda logica "SELECT nick FROM utenti" ("Dimmi il nick degli utenti"), perché l'attributo è stato spostato nella tabella login. IL DESIGN E` STATO SPORCATO DALL'IMPLEMENTAZIONE FISICA, ed è rotto per sempre. Si è fusa l'applicazione con il livello dei dati!! E NESSUNO SEMBRA RENDERSENE CONTO! I mezzi per l'implementazione fisica ci sono, pochi, ma ci sono, e non son questi.


Ora, invece, esaminiamo per sommi capi il percorso che doveva essere seguito.

*Identificare l'entità da modellare*
L'entità UTENTI è concettualmente rilevante, ed è distinta da altre entità. Si decide di implementarla nel modello logico.

*Identificare le chiavi dell'entità*
Una chiave identifica univocamente un utente (e una singola riga) all'interno di una tabella, deve essere verificabile nel mondo reale. Si riconoscono 'nickname' e 'codice fiscale' come identificatore logico di un utente

*Si sceglie la chiave primaria*
Per motivi di privacy e di praticità, il designer scarta il codice fiscale e decide di usare il nick come identificatore di un utente. (La chiave primaria diventerà foreign key nelle altre tabelle).

*Identificare gli attributi dell'entità*
Un attributo descrive un'entità, ed è in dipendenza funzionale della chiave (al variare del valore della chiave, l'attributo deve poter variare, altrimenti è un chiaro segno di errore di modellazione). Per cui si includerà nome, cognome, età etc... Non è possibile mettere questi attributi anche sotto altra entità, perché sarebbero in dipendenza di un'altra chiave primaria (e quindi aggiornabili in maniera incoerente), oppure ridondanti.

*Disegnare il database*
Si otterrà una sola tabella Utenti con chiave primaria nickname e con gli altri attributi tutti nella stessa tabella.


Torniamo per un momento all'articolo.L'autore dice: "In questo modo abbiamo messo in relazione le due tabelle col campo id.".
Tristemente, in questa maniera ha ROTTO la relazione degli attributi con l'entità Utente, spezzettandoli su due tabelle. Gli attributi non sono più in relazione con la loro entità logica.

Quali sono i risultati della mancata applicazione della corretta procedura di cui sopra?
L'autore ne è al corrente, e mi risparmia la fatica di dimostrarlo: "L'unica seccatura, la cui risoluzione è parte della bravura dello sviluppatore, è mantenere sempre i dati corrispondenti nelle due tabelle con lo stesso id progressivo, quindi, in fase di aggiornamento o cancellazione dei dati, è necessario compiere dette operazioni parallelamente sulle due tabelle"
Il database adesso è aperto alla corruzione logica dei dati, perché non si è costruita l'integrità relazionale DEI DATI ma quella delle strutture FISICHE!
Il motivo di usare un RDBMS è quello che la struttura e i VINCOLI che si settano nei database permettono al livello dei dati di mantenere DA SOLI la propria integrità, e NON TRAMITE UN PROGRAMMA esterno!!! Il database fornirà sempre risposte corrette a TUTTE le applicazioni, non solo quelle al corrente dell'implementazione fisica del database. Questo è tutto il senso di implementare la teoria relazionale dei dati!

La corretta implementazione della teoria porta anche alla corretta soluzione dei problemi:

*Ottimizzazione prestazioni e implementazione fisica*
Dopo aver correttamente il nostro database, si proceda alle considerazioni sulle performance:
"si valutano eventuali implementazioni di tabelle, ma ovviamente non devono andare in contrasto con la progettazione fatta in precedenza, pena la perdita di validità dell'intera base di dati."
Ben lungi dal modificare lo schema del database o l'applicazione (per non parlare di applicazioni fornite da terze parti, delle quali proprio non si dispone del codice), il dba, ripeto, il DBA (non il programmatore dell'applicazione né il progettista del database, e qui si vede il beneficio di mantenere separati i livelli dell'architettura), ottiene la seguente analisi:
"L'aumento dell'attività ha creato un collo di bottiglia nel database, a causa dell'accesso ai dati di login nella tabella Utenti".

Soluzione dell'articolo:
Si suddivida la tabella in due parti, attribuendo ad entrambe una colonna ID, in modo che il motore del database scansioni solo gli attributi interessati. I dati originari dovranno essere *sempre* ricostruiti da un join. [tralascio la sonora violazione della teoria, già esposta]
Essendo le colonne ID coinvolte in join, è necessario indicizzarle; inoltre è necessario indicizzare la colonna 'nick'.
Risultato: 3 indici in più e un join ogni qualvolta sia necessario avere una visione logica della tabella.

Soluzione corretta:
Il DBA decide di usare un indice cluster sulla chiave primaria 'nickname'. Adesso i dati sui login sono adesso recuperabili SENZA NEPPURE TOCCARE LA TABELLA FISICA traversando semplicemente l'albero binario dell'indice; gli ulteriori dati della riga sono a portata di mano SENZA ULTERIORE join.
Risultato: 1 indice e una velocizzazione nel recupero dei dati collegati, conseguendo un drammatico aumento delle prestazioni !


Prepararsi per il gran finale...

=====================================================
LA SOLUZIONE RELAZIONALE E` PIU` VELOCE E PIU` EFFICIENTE !!
=====================================================


GOSH !!! Sia nella teoria che nella pratica, l'articolo fallisce miseramente ogni obiettivo !


QUALCUNO COMINCI A RIFLETTERE *SERIAMENTE*


qwsa@despammed.com


Commento di Anonimo (ip: 80.182.54.219), scritto il 06/01/2005 alle 20:57:40
Ciao, rieccomi qui.

Ho il sospetto che tendi a confondere l'autore dell'articolo con me che ho scritto i due commenti con IP 80.182... e che tale autore non conosco. Per cui rispondo ovviamente solo alla parte dei commenti, che riguarda la mia risposta.

Per quanto riguarda il consentire ridondanza (come dividere tabelle o altre soluzioni), ti cito quanto scritto nel primo capitolo di "Sistemi di Basi di Dati - Elmasri, Navathe" ovvero uno dei libri maggiormente formali nella teoria relazionale delle basi di dati:
"Questa ridondanza nel memorizzare più volte gli stessi dati porta a numerosi problemi. ... i files che rappresentano gli stessi dati possono diventare inconsistenti.", e qui siamo d'accordo entrambi, proprio per questo esistono strumenti di controllo come le forme normali. Poi prosegue con:
"Peraltro in alcuni casi una ridondanza controllata può essere utile per migliorare le prestazioni delle interrogazioni. Ad esempio...", ed è esattamente quello che dicevo io, ovvero in 'alcuni' casi critici (da individuare in fase di progettazione con le tavole degli accessi e delle operazioni) è consentito purchè progettato e realizzato correttamente (che non significa alla buona o chiudendo un occhio...). Poi continua:
"Questo obiettivo può essere raggiunto automaticamente verificando che i valori ... si accordino" e ancora "queste verifiche possono essere specificate al DBMS durante la progettazione della base di dati e automaticamente imposte dal DBMS ogni volta che il file ... è aggiornato.", ovvero esattamente quello che affermavo, cioè che quando è necessario percorrere questa strada (e per questo ti dicevo che casi di divisione di tabelle potessero essere consentiti in alcuni casi) si può demandare al software DBMS i controlli aggiuntivi necessari, oppure realizzarli tramite applicazione, magari a livello inferiore rispetto all'applicazione principale, in maniera da realizzare un layer aggiuntivo "trasparente" all'applicazione principale, che gestisca la ridondanza controllata.
Tutto ciò per dire che quando ammettevo la possibilità di dividere una tabella come nel caso del login non facevo "qui lo dico e qui lo nego"...
E' comunque una soluzione, lo ripeto, da evitare se non strettamente necessaria, ma non per questo scorretta o bacata.

La soluzione che porponi tu all'esempio del login invece è semplicemente quella di partenza (a parte l'ID che va eliminato anche secondo me), dalla quale poi può discendere la necessità della divisione, arrivando quindi alla soluzione che "rifiuti" ma che esiste e che può e deve essere corretta e priva di problemi, anche in fase di modifica o manutenzione dell'applicazione.

Poi per quanto riguarda l'uso del campo ID, mi trovi d'accordo che non sia adeguata la sua introduzione "artificiosa" nel caso trattato dall'articolo, ma come ho già detto ci sono casi in cui può essere usato (ad esempio in entità "lavorazione" in cui la chiave primaria deve essere per forza un progressivo quando non sia possibile o convieniente usare chiavi primarie composte da data, ora, macchinario, ecc oppure il prograssivo stesso deve essere assegnato ad un'etichetta con codice a barre identificativo per un magazzino automatico).
Mi sovviene un esempio, se non ricordo male gli articoli di AZPoint hanno come chiave primaria proprio l'ID ! D'altronde non vi era altra chiave (data, ora e autore non sono univoci nemmeno come chiave composita, e usare il testo dell'articolo o del titolo come chiave la vedo dura, soprattutto da richiamare in un URL!).

Per il resto della trattazione che fai mi trovi sostanzialmente d'accordo, aggiungendo inoltre che nei casi non critici quando viene la "tentazione" di usare soluzioni con ridondanza spesso il problema può essere evitato con l'uso delle viste.

E visto che in realtà su AzPoint mi pare non ci sia mai stato un articolo sulla progettazione di data base relazionali, se hai voglia di scrivere una mini-guida teorica da pubblicare fammi sapere. Ciao.

Commento di Anonimo (ip: 151.81.8.48), scritto il 07/01/2005 alle 02:21:01
Ciao Egregio, ormai siamo ad una discussione a due...
Mi scuso se sto usano l'area commenti come se fosse una chat, faccio un ultimo post solo per completare il pensiero (oggi ho l'ultimo giorno di ferie, poi avrò veramente poco tempo).

"Ho il sospetto che tendi a confondere l'autore dell'articolo con me"
Tranquillo, non vi confondo... ma purtroppo proponete idee simili, e nel post ho quotato da entrambi.

Quoto:
"Per quanto riguarda il consentire ridondanza (come dividere tabelle o altre soluzioni)"
*Attenzione*, hai fuso due concetti diversi... una cosa è la ridondanza (la ripetizione di attributi), un'altra è la normalizzazione (processo di creazione delle appropriate tabelle con i relativi attributi); sono due cose differenti e solo in parte collegate (perdona la pignoleria, ma vedrai che sarà fondamentale fra poco). L'errore (grosso) dell'articolo è di *normalizzazione*.

Inoltre, la corretta modellazione della business logic punta 'naturalmente' ad un database completamete normalizzato, senza anomalie di letture e aggiornamenti. Cioé, il livello di normalizzazione non si decide in anticipo, ma è (auto)determinato dalla complessità delle entità in gioco; il database deve essere normalizzato correttamente, non c'é scampo. Con la ridondanza, invece, si può agire in alcuni modi a scelta.

"ti cito quanto scritto nel primo capitolo di "Sistemi di Basi di Dati - Elmasri, Navathe" ovvero uno dei libri maggiormente formali nella teoria relazionale delle basi di dati:"
Questo testo è usatissimo nelle università americane. Suppongo tu abbia un'edizione italiana.

"Questa ridondanza nel memorizzare più volte gli stessi dati porta a numerosi problemi. ... i files che rappresentano gli stessi dati possono diventare inconsistenti." [Ben detto!]
"Poi prosegue con: "Peraltro in alcuni casi una ridondanza controllata può essere utile per migliorare le prestazioni delle interrogazioni. Ad esempio...", ed è esattamente quello che dicevo io"
*Attenzione*, RIDONDANZA o NORMALIZZAZIONE ? L'errore dell'articolo, e il mio argomento principale, era la normalizzazione, ma tu mi stai parlando di ridondanza (vedi che la pignoleria serve? L'uso preciso dei termini porta alla luce gli errori concettuali).

Elmasri, Navathe "Fundamentals of Database Systems": "Normalization of data can hence be looked as a process of analyzing the relation schemas based on their functional dependences and primary keys..." e questo era il mio argomento sul perché è errato suddividere in due tabelle: gli attributi sono in dipendenza funzionale della stessa chiave primaria, e *devono* trovarsi nella stessa tabella. ..."to achieve the desirable properties of minimizing redundancy and minimizing the insertion, deletion, and update anomalies..."; l'eliminazione delle ridondanze, è UNA delle *conseguenze* (alquanto desiderabili) della normalizzazione; un'altra è la correttezza logica delle operazioni sui dati.

La ridondanza si ottiene agendo sul livello fisico dei dati, non su quello logico. Gli strumenti per fare questo non sono molti purtroppo (ed è qui che bisogna premere sui produttori di RDBMS) ma ci sono, e quelli bisogna usare. Ad esempio, comunemente troviamo:

Per le prestazioni:
- INDICI (praticamente di ogni tipo possibile)
- MAPPATURA di singole tabelle su specificati file (da distribuirsi su più dischi, magari RAID)
- SEGMENTATION/PARTITIONING

Per la ridondanza:
- MATERIALIZED VIEW (strumento potentissimo e ampiamente sottovalutato)
- MATERIALIZED COMPUTED COLUMN
- AGGREGAZIONI (computed hierarchies, cubi multidimensionali)

E qui dipende come cadi col prodotto che ti trovi... qualcuno ha solo pochi tipi di indice, qualcuno non ha viste materializzate, le aggregazioni bisogna ricalcolarle 'a comando' etc... Ed è purtroppo la limitatezza di alcuni prodotti che spinge gli utenti a "ingegnarsi" nel modo errato.

Perché è fondamentale usare il motore del database per mantenere queste integrità? Lo dici tu stesso citando dal libro: "queste verifiche possono essere specificate al DBMS durante la progettazione della base di dati e automaticamente imposte dal DBMS ogni volta che il file ... è aggiornato."
Vedi ? E' il database che deve farlo.

"ovvero esattamente quello che affermavo, "
No! Tu dicevi che lo deve fare l'applicazione.

"si può demandare al software DBMS i controlli aggiuntivi necessari [io direi proprio che si DEVE], oppure realizzarli tramite applicazione [NOO ancora!], magari a livello inferiore rispetto all'applicazione principale, in maniera da realizzare un layer aggiuntivo "trasparente" all'applicazione principale, che gestisca la ridondanza controllata."

GRANDE! Hai introdotto il piano 'ammezzato', come gli ascensori di una volta !
Non esiste un layer di mezzo; PERCHE' vuoi reinventare il database ?!? Credi davvero di fare un lavoro migliore di Oracle, IBM etc... ? C'è *già*tutto*quello*che*ti*serve* !! Evitati lavoro (ed errori) inutili.

"Tutto ciò per dire che quando ammettevo la possibilità di dividere una tabella come nel caso del login non facevo "qui lo dico e qui lo nego"... E' comunque una soluzione, lo ripeto, da evitare se non strettamente necessaria, ma non per questo scorretta o bacata. "
sig..sob... NO!, è da evitare sempre, è sempre errata, è un errore fondamententale, è una violaz......buzz... fuzz.... basta; guarda che ora mi hai fatto fare (2:15)! Invece di applicare correttamente la teoria ti inventi un layer aggiuntivo...

"adeguata la sua introduzione "artificiosa" nel caso trattato dall'articolo, ma come ho già detto ci sono casi in cui può essere usato (ad esempio in entità "lavorazione" in cui la chiave primaria deve essere per forza un progressivo quando non sia possibile o convieniente usare chiavi primarie composte da data, ora, macchinario, ecc oppure il prograssivo stesso deve essere assegnato ad un'etichetta con codice a barre identificativo per un magazzino automatico)."
groan... stai confondendo ID, chiavi artificiali e chiavi surrogate.... STOP qui abbiamo accumulato GIORNI di teoria da spiegare... io cedo qui.

Non ti arrabbi se ti dico una cosa? Si vede che hai un'infarinatura di teoria, ma non approfondita a sufficienza (o dimenticata). Ma sei dialogante, questo è molto positivo.

"E visto che in realtà su AzPoint mi pare non ci sia mai stato un articolo sulla progettazione di data base relazionali, se hai voglia di scrivere una mini-guida teorica da pubblicare fammi sapere."

Ho finito le ferie, e manca tempo... ma soprattutto, ci sono una infinità di tutorial sull'argomento sul Web... non vorrei creare... RIDONDANZA :-))

Ciao simpaticone

qwsa@despammed.com

Commento di Anonimo (ip: 31.184.238.21), scritto il 02/01/2012 alle 14:17:22
Лучшая аренда микроавтобусов только тут

Commenta questa notizia:
Non hai ancora fatto il
Login, puoi inserire commenti solo come anonimo.
ATTENZIONE: il tuo IP verrà memorizzato e mostrato a fianco del commento; con la pressione del tasto invia commento si esprime il consenso alla pubblicazione di tale informazione personale.
A discrezione dello staff, i commenti ritenuti non adatti od offensivi potranno essere rimossi. Nel caso di utilizzo di espressioni volgari od offensive il comportamento verrà segnalato al provider interessato.
Se non ti sei ancora registrato, cosa aspetti? Registrati subito.

Da ora puoi discutere dei problemi informatici anche sul nostro FORUM

Testo del commento:


  News correlate
 Grafico a barre con ASP e CSS
 Registrare data e ora sul Database
 Un contaclick basato su file di testo
 Relazioni tra due tabelle: le Join
 Gestione spazi nelle stringhe
 Creazione di dizionari
 Scrittura di un file Ms Word
 Spedire un file via email
  Ultime dal Forum

aricept side effects elderly
sample college admissions essay prompts
thesis presented for the degree
sample essay benefits computer
baylor graduate school dissertation
free economics homework help
interest and career goals essay
in the heat of the night movie essay
buy discount casadei online Manolo Blahnik Green Snake Driver Flats

Comunicazioni / Note Legali / Staff / Collabora / Pubblicità / Privacy / Contatti


Triboo Media s.r.l. (società socio unico) - Viale Sarca 336 - Edificio 16, 20126 Milano (MI) Cap. Soc. 1.250.000,00 euro i.v. - P.IVA, C.F. e CCIAA di Milano IT06933670967 - REA MI-1924178 tel. +39 02 64741470 - fax +39 02 64741494 Società sottoposta alla direzione e coordinamento di TRIBOO SPA - all rights reserved CAP. SOC. EURO 28.740.210 I.V. - P.IVA 02387250307 - COD. FISC. e numero iscrizione al registro delle imprese CCIAA MI : 02387250307 tel.+39 02 64741401 - fax + 39 02 64741491. Utenti Connessi: 256


Pagina creata in 0,09sec. Powered by JuiceADV S.r.l.

Stats v0.1 (0,000sec.)