Relazioni: grado ed esistenza

di il
8 risposte

Relazioni: grado ed esistenza

Salve a tutti
Nei miei ritagli di tempo provo a studiare un po' le basi della progettazione di un database, ma inevitabilmente trovo delle difficoltà che non riesco a superare. Nello specifico mi riferisco ai seguenti aspetti per me poco chiari:
Cosa sono le esistenze obbligatorie e opzionali?
Come si rappresentano nel diagramma ER ?
Il grado rappresenta il nr di relazioni di una tabella: esistono limiti a questo numero?
Spero di essere stato chiaro

8 Risposte

  • Re: Relazioni: grado ed esistenza

    Silvio_Decio ha scritto:


    Salve a tutti
    Nei miei ritagli di tempo provo a studiare un po' le basi della progettazione di un database, ma inevitabilmente trovo delle difficoltà che non riesco a superare. Nello specifico mi riferisco ai seguenti aspetti per me poco chiari:
    Cosa sono le esistenze obbligatorie e opzionali?
    Come si rappresentano nel diagramma ER ?
    Francamente ci vuole un po' di "fantasia", per questa notazione un pochino fuori standard.
    Suppongo che per "esistenze obbligatorie e opzionali" intenda la necessità o meno che esista una seconda entità correlata (mediante la relazione) alla prima.
    In sostanza la cardinalità degli attributi.

    Esempio entità thread del forum, potrà avere un attributo "utenti-che-hanno-risposto", di cardinalità 0,n.
    Se mettessi 1,n intenderesti che ALMENO un utente deve sempre rispondere al thread.
    Il grado rappresenta il nr di relazioni di una tabella: esistono limiti a questo numero?
    Spero di essere stato chiaro
    Stai mischiando due elementi, ma d'altronde è normale, almeno all'inizio.
    Le "tabelle" non esistono, nei diagrammi ER, "saltano fuori" successivamente.

    Ci sono solo
    - entità (rettangoli)
    - relazioni (lineette)
    - associazioni (rombetti)
    - ruoli scritti sulle lineette (delle associazioni, non indispensabili, sono note, tipicamente per i cicli)
    - attributi (lineette con pallini e nome campo)
    - cardinalità (vincoli scritti sulle lineete delle relazioni tra parentesi, come (0,1), (0,n), (1,1) )
    - identificatori (pallini neri, lineette con pallini neri), sono le chiavi, semplici, composte, interne, esterne

    Sulla rappresentazione tieni presente che ce ne sono una trentina, a partire dalle primissime degli anni '70, in particolare ogni autore si è inventata la sua (frecce, freccette, doppie freccette, pallini, rombetti, linee tratteggiate) e così via.
    La differenza principale è del tipo "a diagramma di flusso" (cioè coi pittogrammi, i rombetti per capirci) con quella più "informatizzata", cioè con rettangoli che vengono collegati tra di loro.
    I secondi sono, tipicamente, di derivazione di programmi di disegno di ER, poi "imbastarditi" con alcuni elementi UML e così via (lineette con pallini e "lineette uscenti", rombetti vuoti e pieni e così via).

    Ti suggerisco di non passare troppo tempo su questi dettagli (cioè come fare meravigliosi diagrammi ER), perchè non servono praticamente a nulla nel "mondo reale".
    Un po' come i diagrammi di flusso: si utilizzano (anche questi sono nati negli anni 60-70) per mostrare alcune informazioni banali, a scopo didattico, per gli studenti nella fascia elementare.

    A nessuno sano di mente verrebbe in mente di disegnare il flowchart che so di Word.
    O il diagramma ER di un ERP di fascia media, con un 2.000 o 3.000 tabelle.

    ---
    Quindi DEVI conoscere gli schemi ER, DEVI avere una vaga idea di come si utilizzano in fase di progettazione banale, MA devi renderti conto che sono strumenti inventati una quarantina di anni fa, per i problemi informatici di quaranta anni fa.
    Che non sono quelli di oggi.
  • Re: Relazioni: grado ed esistenza

    Dove leggi questi concetti molto "teorici"? Io ho provato a dare un'occhiata qui
    http://newstarstaras.wikidot.com/progetto-di-un-database
    per esempio, ma ci credi che non ci capisco nulla?

    Silvio_Decio ha scritto:


    Il grado rappresenta il nr di relazioni di una tabella: esistono limiti a questo numero?
    Da una tabella possono partire molte linee di join. Dipende pure che senso vuoi dargli.

    Per quello che ci ho capito io di "progettazione database", il miglior modo è affrontare una analisi nel caso specifico secondo le proprie esigenze. Database che trattano lo stesso argomento (ad esempio una banale Rubrica) possono essere pensati in molti modi diversi.
  • Re: Relazioni: grado ed esistenza

    OsvaldoLaviosa ha scritto:


    ma ci credi che non ci capisco nulla?

    secondo le proprie esigenze
    Esistono regole teoriche e procedimenti ben precisi, poi ci vuole l'esperienza.
  • Re: Relazioni: grado ed esistenza

    Se la domanda è : dove trovo del materiale su er la risposta è ovunque.
    per motivi abbastanza intuibili consiglio di partire da qualche slide introduttiva di un qualche corso elementare universitario.
    Esempio cercare diagrammi er deis

    Se la domanda è :come si progettano database relazionali la risposta è NON così
  • Re: Relazioni: grado ed esistenza

    Solo per chiarire, l'esistenza è obbligatoria quando un'istanza deve necessariamente essere utilizzata nell'entità a cui la relazione si riferisce; diversamente è opzionale. Una città (prima entità) deve appartenere a una nazione (seconda entità) perché non può esistere una città senza nazione (obbligatorietà). Ogni individuo può avere un recapito telefonico, ma può anche esserci un individuo che non lo possiede (Opzionalità). La precisazione dovrebbe creare relazioni con caratteristiche diverse (MySQLWorkbench). Tutto qui. Magari praticamente non serve a nulla, ma questo è quello che ho capito.
    Grazie comunque per il vostro tempo
    Farò tesoro dei vostri consigli
  • Re: Relazioni: grado ed esistenza

    Silvio_Decio ha scritto:


    Solo per chiarire, l'esistenza è obbligatoria quando un'istanza deve necessariamente essere utilizzata nell'entità a cui la relazione si riferisce; diversamente è opzionale. Una città (prima entità) deve appartenere a una nazione (seconda entità) perché non può esistere una città senza nazione (obbligatorietà). Ogni individuo può avere un recapito telefonico, ma può anche esserci un individuo che non lo possiede (Opzionalità). La precisazione dovrebbe creare relazioni con caratteristiche diverse (MySQLWorkbench). Tutto qui. Magari praticamente non serve a nulla, ma questo è quello che ho capito.
    Grazie comunque per il vostro tempo
    Farò tesoro dei vostri consigli
    Non ci sono i check di questo tipo in mysql (o meglio, dipende dalla versione).
    Non puoi (potevi) imporre questo vincolo.
    Che, tra l'altro, non ha nulla a che vedere con le tabelle.

    Di nuovo sono due mondi diversi: ER è una cosa, tabelle (mysql eccetera) un altro.

    Tipicamente si passa dal mondo ER a quello delle tabelle, ma si richiedono ulteriori passaggi intermedi (collassi e così via)
  • Re: Relazioni: grado ed esistenza

    +m2+ ha scritto:


    Tipicamente si passa dal mondo ER a quello delle tabelle, ma si richiedono ulteriori passaggi intermedi (collassi e così via)
    Questo non lo sapevo. Nel mio piccolo pensavo che una volta chiarite le mie esigenze, create le tabelle e stabilite le relazioni (ER) fosse stato sufficiente attivare la funzione propria di MySQLWorkbench (forward engineer) per avere lo script SQL per la creazione del database con tutte le sue relazioni.
    Visto che sono partito con il piede sbagliato e addirittura riferendomi a concetti ormai superati da anni, come vi regolate, voi professionisti del settore, furante la creazione di un nuovo database di piccole dimensioni (anagrafica clientela, ordini, listini e quant'altro)? Quali gli step e a cosa porre la maggiore attenzione ?
  • Re: Relazioni: grado ed esistenza

    Comincerei con lo studiare un pochino. Diciamo che un tre o sei mesi dovrebbero essere sufficienti per quello che vuoi fare.
Devi accedere o registrarti per scrivere nel forum
8 risposte