Progetto Basi dati

di il
24 risposte

Progetto Basi dati

"Si sviluppi un database che permetta la descrizione e memorizzazione di diagrammi della tipologia Entitˆ-Relazioni, con supporto ad attributi (anche compositi e/o multivalore), chiavi, cardinalitˆ ecc. "

Ho rinominato il vecchio post da "Progetto basi dati" a "Connettere Java ad Oracle" perché il discorso era deviato su quell'altro argomento. Quindi ho aperto un nuovo post qui col nome del vecchio.
No, una entità chiamata Diagramma. Quali attributi ha un diagramma? Beh, sicuramente un nome, poi eventualmente altro di "contesto" che non saprei se possa servire nella tua esercitazione (es. autore).

Poi quale altra entità sta concettualmente "sotto" Diagramma?
Dicevamo che per un database che memorizzi un modello ER deve avere degli attributi come "Nome_entità". Inserirei "Nome_relazione", "tipo_relazione" (potrebbe essere uno a molti, molti a molti, ecc.). Vado bene?

24 Risposte

  • Re: Progetto Basi dati

    giulio0 ha scritto:


    Dicevamo che per un database che memorizzi un modello ER deve avere degli attributi come "Nome_entità". Inserirei "Nome_relazione", "tipo_relazione" (potrebbe essere uno a molti, molti a molti, ecc.). Vado bene?
    No, allora, mettiamola così: una base dati adatta per descrivere/memorizzare diagrammi, dovrebbe "ragionevolmente" poterne memorizzare più di uno di diagramma.

    Quindi la base dati concettualmente avrebbe: N diagrammi, di cui ciascuno ha M entità, di cui ciascuna ha P attributi.
    Poi c'è la questione delle "relazioni" tra le entità (nonché le chiavi primarie), qui c'è invece da valutare meglio la cosa su come poterli descrivere.

    Pertanto quali entità dovrebbe avere il tuo diagramma ER per una base dati che descrive altri diagrammi ER?
  • Re: Progetto Basi dati

    Quindi la base dati concettualmente avrebbe: N diagrammi, di cui ciascuno ha M entità, di cui ciascuna ha P attributi.
    In qualche messaggio precedente ho proprio detto che come attributi dovrebbe avere i numeri entità, relazioni ed attributi da inserire, e visto che lo sto scrivendo in java potrei fare un while che cicla l'istruzione "CREATE TABLE nome_entità", dove "nome_entità" è una stringa scelta dall'utente. La stessa cosa potrei fare con le chiavi chiedendo all'utente quale vorrebbe fosse la chiave tra gli attributi da lui inseriti (il metodo utilizzato per inserire gli attributi è del tutto analogo a quello usato per creare un entità)... così via per il resto. In sintesi mi verrebbe una cosa così:

    NOME_ENTITA' (nome scelto dall'utente)
    Attributo_1 (nome scelto dall'utente)
    Attributo_2
    .
    .
    .
    Attriubuto_n
    (chiedo all'utente quale debba essere la chiave primaria tra quelle inserite)
    (chiedo all'utente quale debba essere la chiave esterna se questa non è la prima tabella)
  • Re: Progetto Basi dati

    giulio0 ha scritto:


    Quindi la base dati concettualmente avrebbe: N diagrammi, di cui ciascuno ha M entità, di cui ciascuna ha P attributi.
    In qualche messaggio precedente ho proprio detto che come attributi dovrebbe avere i numeri entità, relazioni ed attributi da inserire, e visto che lo sto scrivendo in java potrei fare un while che cicla l'istruzione "CREATE TABLE nome_entità", dove "nome_entità" è una stringa scelta dall'utente.
    No, allora ascolta, lo ripeto meglio. Ho detto prima che la base dati concreta (quella su cui poi fai effettivamente select, insert, ecc... da Java) dovrebbe gestire: N diagrammi, di cui ciascuno ha M entità, di cui ciascuna ha P attributi

    Quindi, come minimo (dimentichiamo solo un attimo le relazioni/vincoli sulle entità), quali entità/tabelle dovrebbe avere questa base dati?
  • Re: Progetto Basi dati

    Un' entità che gestisce tutte le altre?
  • Re: Progetto Basi dati

    giulio0 ha scritto:


    Un' entità che gestisce tutte le altre?


    Se ti dico: N diagrammi, di cui ciascuno ha M entità, di cui ciascuna ha P attributi
    Quante tabelle (ripeto, come minimo) dovresti fare per realizzare concretamente l'espressione che ho appena ridetto?
  • Re: Progetto Basi dati

    Tre entità di cui una si occupa dei diagrammi, una delle entità e l'altra degli attributi?
  • Re: Progetto Basi dati

    giulio0 ha scritto:


    Tre entità di cui una si occupa dei diagrammi, una delle entità e l'altra degli attributi?
    Esatto! E poi per le relazioni .... beh, anche una relazione ha un nome e altri dati che descrivono la relazione. Quindi direi un'ulteriore tabella Relazioni.
  • Re: Progetto Basi dati

    Però non mi è ben chiaro la funzione di queste tre tabelle? Chiedo all'utente il numero di diagrammi/entità/attriubti? Forse ho omesso che il programma dev'esere interattivo infatti dovrò sviluppare una GUI
  • Re: Progetto Basi dati

    giulio0 ha scritto:


    Però non mi è ben chiaro la funzione di queste tre tabelle? Chiedo all'utente il numero di diagrammi/entità/attriubti? Forse ho omesso che il programma dev'esere interattivo infatti dovrò sviluppare una GUI
    La interazione con l'utente c'entra relativamente poco (anzi, quasi niente, direi) con il modello della base dati. Chiaramente più la interazione con l'utente è "sofisticata", più sarà complessa da sviluppare. Un conto ad esempio è richiedere i nomi e altri dati con dei textfield, checkbox, combobox ecc... Un altro conto ben diverso sarebbe se l'utente deve proprio "disegnare" i blocchetti e tracciare le connessioni tra i blocchetti. Ma per ciò che sta "sotto" (la base dati) non cambierebbe nulla.

    Comunque forse non ti è ancora chiaro: 3 tabelle (ripeto, come minimo), Diagrammi, Entita, Attributi

    Se l'utente vuole inserire (ripeto, con qualunque interazione, non importa) quel modello di esempio che avevo fatto, Aule e Studenti (relazione uno-a-molti), allora nelle varie tabelle andranno man mano inseriti:

    in Diagrammi 1 record che descrive il diagramma in generale es. "Diagramma ER Aule - Studenti", ecc...
    In Entita 2 record, uno per descrivere l'entità Studente, uno per Aula (chiaramente dovranno essere associati al record in Diagrammi !).
    In Attributi, tanti record per descrivere gli attributi di ciascuna delle due entità.

    Ora è assolutamente chiaro, oppure no?
  • Re: Progetto Basi dati

    Non mi è chiarissimo cosa intendi per Diagramma. Inoltre, ammettiamo che Entità sia una tabella nominata "Studente", ed i suoi Attributi siano "sesso, eta", allora nel database in SQL non corrisponde a questo: CREATE TABLE Sudente(Sesso VARCHAR2, eta NUMBER);?
    Quindi ad una ed una sola tabella con attributi dentro?

    Perché, come dici tu, dovrei fare una tabella per Entità quindi" CREATE TABLE Entita(Nome VARCHAR2);" ed una per attributi, quindi CREATE TABLE Attributi(Sesso VARCHAR2, eta NUMBER, nome_entita VARCHAR2)?

    Non posso sintetizzare in una tabella il tutto?
  • Re: Progetto Basi dati

    giulio0 ha scritto:


    Non mi è chiarissimo cosa intendi per Diagramma. Inoltre, ammettiamo che Entità sia una tabella nominata "Studente", ed i suoi Attributi siano "sesso, eta", allora nel database in SQL non corrisponde a questo: CREATE TABLE Sudente(Sesso VARCHAR2, eta NUMBER);?
    giulio0, sinceramente, se non è chiaro a te, non saprei come aiutarti più di tanto oltre ...

    A me la descrizione iniziale "Si sviluppi un database che permetta la descrizione e memorizzazione di diagrammi [...]" è ragionevolmente molto chiara, almeno come obiettivo generale.

    Se l'utente con l'applicazione vuole inserire e quindi descrivere il diagramma Studenti-Aule, NON vuol dire che devi fare una CREATE TABLE studenti. Se fai così non "descrivi" un bel nulla ...
  • Re: Progetto Basi dati

    Okok adesso mi è tutto chiaro come l'acqua cristallina! Adesso torna tutto! Però solo un dubbio, nei messaggi precedenti mi hai detto che serve una tabella Diagrammi, quella servirebbe solo a salvare il nome del diagramma perché comunque si parla di diagrammi ER no?

    Adesso che ho tutto chiaro ho capito che è un'impresa ardua
  • Re: Progetto Basi dati

    giulio0 ha scritto:


    mi hai detto che serve una tabella Diagrammi, quella servirebbe solo a salvare il nome del diagramma perché comunque si parla di diagrammi ER no?
    Beh, ma scusa, vuoi poter gestire solo 1 diagramma e basta? Se generalizzi, mi sembra comunque una buona cosa (non è quella la parte più difficile, essendo Diagrammi concettualmente "a monte" di tutto).

    giulio0 ha scritto:


    Adesso che ho tutto chiaro ho capito che è un'impresa ardua
    Non è complicatissimo ma c'è da ragionare un pochino. Soprattutto su una cosa: come descrivere le relazioni. Se ti documenti un pochino (o se l'hai già fatto) vedi che in realtà i diagrammi ER si possono disegnare in diversi modi a seconda che il diagramma sia concettuale/logico/fisico.

    Un conto è descrivere solo che Aula ha una relazione uno-a-molti con Studente. Un altro conto è descrivere che la tabella STUDENTI ha un campo ID_AULA che è una foreign-key verso il ID di AULE (la foreign key sta sempre dalla parte del "molti" in una relazione uno-molti).

    E a me non è chiaro cosa ti è stato richiesto su questo aspetto. Il testo iniziale parla di "attributi (anche compositi e/o multivalore), chiavi, cardinalità ecc. " ma non parla di tabelle fisiche, quindi mi viene da pensare che il diagramma sia a livello concettuale e non fisico.
  • Re: Progetto Basi dati

    Il grafico l'ho fatto in UML, che ne pensi? Una tabella per Entità collegata 1 ...* con tabella Attributi ed *...1 con la tabella Relazioni. Attributi è collegata con la tabella Tipo (non sono sicuro di questo collegamento) e Tipo è superclasse di Enum
Devi accedere o registrarti per scrivere nel forum
24 risposte