Newsgroup: it.comp.appl.access
Titolo: Consiglio su relazioni

Vorrei costruire un database ma visto che le relazioni non sono il mio forte
volevo chiedere se qualcuno poteva darmi indicazioni su come creare le
tabelle con le relative relazioni di un database che ha le seguenti tabelle
per descrizione:
(0)Clienti
(1) Impianto cliente (Condizionamento, Riscaldamento ecc)
(2) Dettagli impianto(Convettori, compressore ecc)
(3) Fogli di intervento (In caso di guasto o altro il cliente chiama per
un'intervento)
(4) Dettagli foglio di intervento (Parti sostituite, data esecuzione ecc)
(5) Parti
(5) Tecnico che esegue il lavoro
Grazie, Alberto

 wrote in message
OOgS5.25757$DG3.4...@news2.giganews.com...


Ti posso mandare uno snapshop delle relazioni che ho costruito per vedere se
ci siamo quasi ?

 wrote in message
8kjS5.26463$DG3.4...@news2.giganews.com...


 sai già cosa sono le opzioni CASCADE nelle relazioni ?
______
Ma le relazioni sono importanti, oppure se ne puo' fare anche a meno?
La loro utilità , quale è?
ciao Riccardo

 ha scritto nel messaggio
news:8vftqu$ih0$1...@news.panservice.it...

C'è chi sostiene che se ne possa fare a meno, secondo me chi lo sostiene è
un pò masochista.
Esplicitare ad Access le relazioni, ma innanzitutto aggiungere le integrità
referenziali quando necessario, ti permette degli automatismi (specie sui
controllo di integrità del database) che altrimenti dovresti programmarti da
solo, ma soprattutto ti evita brutte sorprese durante la gestione
dell'applicazione.
Insomma è come inventare l'ombrello quando piove, quando l'ombrello è già
stato inventato e basta aprirlo.
Naturalmente questo vale se hai deciso di creare un database relazionale; in
caso contrario vale la pena adoperare Access?
--
Roberto
---------------------------------------------
il sito comune di it.comp.appl.access:
http://members.xoom.it/it_db_access/
---------------------------------------------

io lavoro su mainframe, ed una volta c'erano database soltanto dl/1
la loro caratteristica era la relazionazalità, cioè insieme di record legati
gerarchicamente come in un albero genealogico.
si era sempre certi che che a fronte di un figlio ci fosse un padre
(es.cliente/fatture, non ha senso il record fattura se il record cliente è
stato segato)
in un grande ambiente (milioni di records) non possono mancare queste
certezze
poi è arrivato il db2 (programmato in sql), molto comodo, succhia cpu
(troppo facile scrivere programmi di poche righe sql, poi vedi quanti mips
ti succhia quando gira) portandosi con se i concetti di entità, relazioni,
attributi ecc.
la scopertta dell'acqua calda.
tutto molto accademico e molto relativo, ma veramente relativo, nel senso
che se apri un cursose (ovvero fai una select) e non metti order by nessuno
di assicura che hai un elenco ordinato per la chiave della tabella.
e allora a che serve la chiave ? ....bè questo è un'altro discorso...il
"motore" dietro l'sql cerca di ottimizzare gli accessi cercando di
utilizzare le chiavi che sono state create; poi si dovettero inventare delle
utility che ti consigliavano qualu chiavi mettere monitorando un certo
numero di I/O.
.......
sto andando fuori tema...............
insomma SQL applica i concentti di entità relazioni attributi ecc. puramente
accademici, slegandosi cioè il più possibile dall'organizzazione della base
dati.
siccome però dalla teoria poi occurre scendere in pratica, bisogna fare
anche qualche compromesso, quindi:
-prestare attenzione alle chiavi che si definiscono sia per avere maggiori
prestazioni nelle ricerche, che per garantire univocità nei records
-creare delle relazioni fisiche (es 1 a molti) con integrità referenziale
per evitare che nel nostro database vadano a "spasso" delle fatture senza
che esistano più gli articoli o i clienti.
in più access di tà la possibilità che cancellando un padre (cascade) ti
cancella tutti i fligli
inoltre, con la update cascade (porca troia con "alter table" non piglia il
parametro occorre farlo per forza con il pannellino del menù relazioni)
cambiando il valore del campo definito in relazione, ti aggiorna
automativamente tutto il database.
.....scusa se mi sono dilungato, ma sono a casa malato e non ho nulla da
fare (forse però è meglio che stacci il modem se no mi costa troppo, meglio
la tv)
in altre parore: LE RELAZIONI SERVONO eccome
Ciao Luc

 stato segato)
_____
ma se sego una fattura , non corro il rischio di segare anche il Cliente?
O questo accede solo se creo una relazione uno a uno?
bye Riccardo

no, il cascade scedde soltanto, nel senso che agisce sempre sui figli e non
viceversa.
è comodo impostarla nei casi di cliente -> fatture; mentre non va impostata
per le relazioni di integrità referenziale con campi di tipo "tipologie";
se per esempio c'è un campo "natura giuridica" del cliente con cui datta
tabella clienti si fa rifemimento alla tabella delle forme giuridiche (da
cui ricavare soltanto descrizione ecc..) non è corretto impostare il cascade
in cancellazione, anzi, non essendo impostato, access ti dirà che non puoi
cancellare quella natura giuridica perchè in uso su altri record.
in queste relazione è comodo impostare il cascade in modifica, così se cambi
il codice della natura giuridica te lo cambia in tutti i clienti (è il caso
di relazioni su campi testo invece del solito id-... che non serve a nulla).
Luc