REL. Molti-A-Molti(Forse non ho capito bene)

di il
7 risposte

REL. Molti-A-Molti(Forse non ho capito bene)

Salve. Sono nuovo nell'ambiente Access (a parte i rudimenti per superare il modulo base ECDL ).

Mi è venuto in mente di fare un database personale (anche per capire meglio Access)...
Veniamo al dunque...
In pratica ho queste tabelle:
Libri / Fumetti / Carte / Autori
Come ogni Manuale/Libro/guida su Access indica, tra libri ed autori, c'è una Relazione Molti a molti), ma è vero (per me), che lo stesso potrebbe dirsi per un Fumetto o un mazzo di carte illustrato.
Da questo pensiero, per prima cosa ho provato a creare la prima relazione Molti a Molti, tra Libri ed Autori.
La mia tabella di giunzione aveva solo il suo ID e gli ID dell'autore e del libro. Fin qua era tutto a posto... la relazione funzionava e se aprivo le due tabelle, i fogli secondario collegati, mi spuntava senza errori.
Utilizzavo Campi Ricerca Guidata per creare le relazioni della tabella di giunzione, ossia nei campi ID_aut ed ID_book e poi la finestra relazioni per rafforzare l'integrità.

Il dubbio/problema mi viene preparando la seconda Relazione Molti a molti, tra Autori e le altre tabelle...
Creando con le stesse modalità, una seconda realzione tra autori e Fumetti, nella finestra delle relazioni, le linee sembravano essere corrette...
Aprendo le varie tabelle, alcune funzionavano bene, facendo vedere i record appropriati, mentre nelle altre (nelle varie prove che ho fatto), o mi si chiedeva di inserire il foglio secondario, oppure in altri casi, mi spuntavano ad esempio, negli autori, tutti i record (pochi per l'esatezza) dei libri, anche quelli di altri autori, in una sorta di struttura ad albero...
Ho pensato, che vedendo un immagine di un libro che stavo leggendo su access che usava 4 Tabelle, che la tabella centrale (quella di giunzione) non aveva l'integrità riferenziale per fare spuntare il sibolo 1 ed infinito, specchiati rispetto a quella della prima tabella (non so se rendo l'idea)....
cmq ho provato anche così, ma con 4 tabelle mie (Autori, giunzione, libri e Fumetti collegato agli autori) non andava bene lo stesso... gli stessi errori di selezione foglio dati secondario e tutti i record visibili...

Le relazioni Molti a Molti, devono stare da sole?
Se una tabella Autore è in relazione con una Libri, non può avere un altra tabella correlata in Molti a molti? Mi pare assurda come convinzione....

7 Risposte

  • Re: REL. Molti-A-Molti(Forse non ho capito bene)

    Scusa ma che differenza passa tra [Libri / Fumetti]...?

    Entrambi gli elementi hanno in comune la questione Autori...!

    Sei certo che non basti aggiunegre alla tabella Libri un Campo Proprietà che ne definisca il Tipo...?

    Per il resto direi che devi aver commesso qualche errore, l'oggetto della Relazione MOLTI-MOLTI è la tabella di Dettaglio, ma le Tabelle lato (1) possono formare N relazioni MOLTI-MOLTI.

    Sicuro di non aver fatto dei COPY/PASTE per semplificare... senza andare poi a modificare correttamente i dati...?
  • Re: REL. Molti-A-Molti(Forse non ho capito bene)

    Ciao appoggio la riflessione di @Alex, stai cercando una soluzione che va contro i principi basilari della progettazione di un database relazionale.

    Le tabelle libri, fumetti, carte, guide se ci rifletti dal punto di vista strutturale delle informazioni sono simili.

    Puoi fare un'unica tabella dove oltre a specificare la tipologia di pubblicazione (per capire se il record riguarda un libro, un fumetto, ecc) come giustamente suggerito da Alex, puoi inserire dei campi "di specializzazione" che ti permettono di gestire eventuali informazioni che hai in "guide" e non in "fumetti".

    A questo punto devi relazionare l'entità "libro o come vuoi chiamarla" e la tabella degli autori.
  • Re: REL. Molti-A-Molti(Forse non ho capito bene)

    @Alex ha scritto:


    Scusa ma che differenza passa tra [Libri / Fumetti]...?

    Entrambi gli elementi hanno in comune la questione Autori...!
    Lo avevo pensato alla prima stesura di metterle insieme...
    Ma poi ci sarebbero dei campi che sono solo della attinenti ai Fumetti e non ai libri, che resterebbero vuoti...
    dovrei dividerli con una relazione uno-A-Uno...
    del resto anche la tabella fumetti possiede un campo per differenziare la pubblicazione...
    se sono giapponesi, americani, ecc...
    avevo pensato di non immishiare troppa carne al fuoco...
    mi sa che dovrei separare Autori di Fumetti ed autori di Libri...
    nel mondo reale ci ha fumetti, non fa libri, ma pensando con mente analitica, mi sono detto
    e se ci sono anche chi fa l'uno e l'altro?
  • Re: REL. Molti-A-Molti(Forse non ho capito bene)

    Concordo anch'io sul fatto che una tabella Titoli (dove si inseriscono i titoli sia di fumetti, libri, carte ecc...) dovrà poi contenere un campo di discriminazione "Tipo". Ho un database simile anch'io che prevede questa discriminante apposita.

    Robywekky ha scritto:


    Ma poi ci sarebbero dei campi che sono solo della attinenti ai Fumetti e non ai libri, che resterebbero vuoti...
    È del tutto normale che accada questo, non temere di avere alcuni campi vuoti in certi casi.

    Robywekky ha scritto:


    pensando con mente analitica, mi sono detto
    e se ci sono anche chi fa l'uno e l'altro?
    Esattamente: devi poter dare al database questa possibilità, che in fondo è reale.
    Alberto Sordi può essere tanto un Attore, quanto un Regista (Autore di film), quanto un Autore di canzoni, altrettanto Interprete di canzoni, Autore di libri........attento, magari Attore e Interprete potrebbero fuorviare il discorso, ma gli altri 3 significati sono molto pertinenti, anche per il tuo database.
  • Re: REL. Molti-A-Molti(Forse non ho capito bene)

    Robywekky ha scritto:


    Lo avevo pensato alla prima stesura di metterle insieme...
    Ma poi ci sarebbero dei campi che sono solo della attinenti ai Fumetti e non ai libri, che resterebbero vuoti...
    dovrei dividerli con una relazione uno-A-Uno...
    del resto anche la tabella fumetti possiede un campo per differenziare la pubblicazione...
    se sono giapponesi, americani, ecc...
    avevo pensato di non immishiare troppa carne al fuoco...
    mi sa che dovrei separare Autori di Fumetti ed autori di Libri...
    nel mondo reale ci ha fumetti, non fa libri, ma pensando con mente analitica, mi sono detto
    e se ci sono anche chi fa l'uno e l'altro?
    La questione non è esattamente come la descrivi... chi sviluppa Database non vorrai che si fermi davanti a queste cose...?
    Le Relazioni 1-1 lasciale perdere... non si usano, diciamo che non sono semplici da gestire come troppi pensano, e la loro utilità è discutibile nella maggior parte dei casi.

    La soluzione al tuo problema ha 2 strade, una semplice ed una complessa.
    La soluzione semplice ma rigida è che rendi VISIBILI solo i controlli/Campi specifici per l'oggetto...
    Puoi ottenerlo inserendo dei Codici prima o dopo i Campi...
    
    LIB_NomeCampo
    quindi nelle maschere se visualizzi Fumetti... nascondi tutto quello che Inizia con "LIB_"

    Oppure generi un Codice Binario 0010_NomeCampo...

    E' un sistema rigido, ma semplice da implementare.

    La soluzione complessa richiede una denormalizzazione, che prevede una gestione delle proprietà(quelle che volevi distinguere in 1_1) le devi vedere come Attributi dell'oggetto.

    Per fare questo devi definire dei Template, ad esempio il Template dei Libri prevede N_Attributi
    Serve una Relazione Molti-Molti, TIPI-Dettaglio-Attributi.
    Hai definito SOLO i TEMPLATE.
    Quando vai ad inserire un LIBRO vai a recuperare dal TEMPLATE gli attributi e li Accodi in una Tabella M-M tra Oggetti ed Attributi...

    Se hai capito sei già in gamba... questa struttura è molto complessa sia da capire che da Gestire e Strutturare... ha solo 1 VANTAGGIO... non ha LIMITI.
  • Re: REL. Molti-A-Molti(Forse non ho capito bene)

    @Alex ha scritto:


    Robywekky ha scritto:


    Per fare questo devi definire dei Template, ad esempio il Template dei Libri prevede N_Attributi
    Serve una Relazione Molti-Molti, TIPI-Dettaglio-Attributi.
    Quando vai ad inserire un LIBRO vai a recuperare dal TEMPLATE gli attributi e li Accodi in una Tabella M-M tra Oggetti ed Attributi...
    Vediamo se ho capito...
    Tipi-Dettaglio-Attributi...

    i tipi dovrebbero essere le difinizioni, se si tratta di un libro, un fumetto, ecc...
    il dettaglio dovrebbe contenere gli ID_Autore e ID della tabella che contiene tutte le pubblicazioni..
    gli attributi, sono i campi che sarebbero vuoti appartenenti ai vari record...

    tabella tipi
    Manuale - Narrativa - Manga, ecc...

    attributi
    Piattaforma a cui si rivolge il manuale.... che non a nulla a che vedere con un racconto o un fumetto....
    Numero volumi, che sta ai manga ed ai fumetti (ma può stare anche ai libri, se è una enciclopedia)
    Personaggio (chi mi ha detto di fare il database, usa anche storie separate e che vorrebbe indicare il personaggio della storia, ma starebbe meglio nel campo autore/personaggio a questo punto...)
    Lingua (molto forzato è una ipotesi)che sta al manuale che uno possiede, ma un libro di narrativa lo comprerebbe nella sua lingua nativa, ma farebbe parte della tabella delle risorse, visto che entrerebbe a pieno titolo anche nella narrativa...

    Era questo che intendevi?
  • Re: REL. Molti-A-Molti(Forse non ho capito bene)

    Ho la sensazione che il tuo database somigli molto a una porzione del mio. Non so se può tornarti utile dare un'occhiata a questo post

    ignora la problematica sulla strutturazione, piuttosto osserva le tabelle
    TITOLI
    AUTORI-TITOLI
    ARTISTI

    La tabella TITOLI, nel tuo caso potrebbe includere campi più o meno così
    IDTitolo
    Titolo
    Genere (molto facoltativo)
    Tipo

    il campo Tipo nel mio database l'ho chiamato Qualifica e lì ci vai a mettere valori ad es.
    Libro
    Fumetto
    Carte
    ...

    Robywekky ha scritto:


    attributi
    Piattaforma a cui si rivolge il manuale.... che non a nulla a che vedere con un racconto o un fumetto....
    Numero volumi, che sta ai manga ed ai fumetti (ma può stare anche ai libri, se è una enciclopedia)
    Personaggio (chi mi ha detto di fare il database, usa anche storie separate e che vorrebbe indicare il personaggio della storia, ma starebbe meglio nel campo autore/personaggio a questo punto...)
    Lingua (molto forzato è una ipotesi)che sta al manuale che uno possiede, ma un libro di narrativa lo comprerebbe nella sua lingua nativa, ma farebbe parte della tabella delle risorse, visto che entrerebbe a pieno titolo anche nella narrativa...
    Attento, tutte queste considerazioni, rendono molto più complesso tutto il discorso.
    Autore/Personaggio...mi tocchi una corda a me dolente. Nel mio caso ho preferito avere una tabella di partenza ARTISTI, poi a seconda di cosa fanno realmente, diventano ora Autori, ora Interpreti. Io li ho smistati su tabelle differenti (continua a vedere tutta la mia struttura). Ricordo che Alex, in un altro caso relativamente simile, proponeva una tabella di congiunzione dove, accanto a ogni Titolo, puoi associare molti Artisti e aggiungere un campo Ruolo (Autore, Interprete...)(mi si corregga se sbaglio).
    Ecc...ecc...ecc...spero di non confondere le acque e riuscire a dare un contributo utile lo stesso.
Devi accedere o registrarti per scrivere nel forum
7 risposte