incertezza nello sviluppo di un modello di database

Sto cercando di sviluppare un modello di database per i candidati, i loro esami registrati e il risultato degli esami quando vengono presi. Questo è quello che ho fatto finora. tuttavia non sono sicuro se sono sulla strada giusta, specialmente dalla tabella degli esami alla tabella dei risultati dell’esame. quanto sarà facile scrivere correttamente un codice sql per l’esame della popolazione di esame per un particolare candidato

i tipi di esame sono suddivisi in scienza, arte e scienze sociali. tutti hanno 4 componenti ciascuno

inserisci la descrizione dell'immagine qui

Nota sulla progressione

Dato che la Domanda cambia in modo sostanziale (nel chiarire il requisito, non è lo scopo) in risposta alla mia Risposta e alla mia TRD, questo richiederà un po ‘di avanti e indietro. Identifichiamo i passaggi: i tuoi numeri di Step sono dispari, a partire da 1; il mio, in risposta, è pari. Parti di precedenti passaggi di risposta sono diventati obsoleti, potrebbero non avere più senso.

Suggerirei una taglia, tranne per il fatto che hai pochi punti.

Risposta Passaggio 2 a domanda iniziale e diagramma del passaggio 1

Questo è quello che ho fatto finora.

Hai fatto un buon lavoro, ma è troppo presto per l’assegnazione dei PK. Inoltre, l’assegnazione di un ID su ogni file come punto di partenza paralizzerà il processo di modellazione, il risultato non sarà un database. Devi prima modellare i dati (non il database), quindi assegnare Keys quando le quadro sono chiare e stabili. Quindi rilascia tutti i tuoi ID e PK e modella i dati, come dati. Dimentica ciò che vuoi fare con i dati (ad esempio dimentica l’app).

quanto sarà facile scrivere correttamente un codice sql per l’esame della popolazione di esame per un particolare candidato

In questo momento non puoi. Non hai alcuna relazione tra Candidate ed Examination[Result]. Questo non è un problema perché la modellazione è incompleta in questa fase, quando sarà completo il codice sarà semplice.

Il Course quadro è implicito, ma manca.

tuttavia non sono sicuro se sono sulla strada giusta, specialmente dalla tabella degli esami alla tabella dei risultati dell’esame

Sei sulla strada giusta con alcuni degli altri file, ma il cluster Examination bisogno di lavoro. Questo richiederà un po ‘di andirivieni. Una volta che hai risposto alle domande nei commenti, possiamo procedere.

Il problema principale è questo: come viene identificato l’ Examination .

Un campo ID non identifica nulla e non fornisce univocità nei dati , cosa necessaria se si desidera l’integrità dei dati. Gli ID generano un sistema di archiviazione dei record senza integrità, tuttavia, sembra che si desideri un database con integrità dei dati. È corretto ?

Torna all’utente e spiega come vengono identificati i corsi e i componenti, quali codici usano, ecc. Quelle sono le chiavi naturali che usano per identificare i loro dati, che entreranno nel sistema quando hanno bisogno di cercare qualcosa, o per inserire i risultati degli esami.

  • Per esempio. Non è ragionevole contemplare un Examination che esiste in modo indipendente (come lo hai modellato). Le persone non vanno in una sala e si siedono per qualsiasi esame precedente. L’esame esiste solo nel contesto di un corso, siedono per un esame per un corso .
  • Quindi il corso, e non l’esame, ha componenti, che vengono esaminati. E ogni corso ha un numero diverso di componenti.
  • Per esempio. un Course identificato come ENG101 per la English Literature year 1
  • E poi i componenti all’interno di quello. Per esempio. 2b Short essay on poetry.

Potrebbe essere necessario identificare anche l’anno e il semestre del corso, nel qual caso è necessaria una CourseOffering per semestre.

Considera questo, come punto di discussione. Il corriere è un esempio di dati, il blu è chiave, il verde non è chiave:

  • TRD Step 2

Response Step 4

Risposta a domande e descrizioni

Questo è quello che ho fatto finora.

La mia precedente risposta si applica ancora:

Hai fatto un buon lavoro, ma è troppo presto per l’assegnazione dei PK. Inoltre, l’assegnazione di un ID su ogni file come punto di partenza paralizzerà il processo di modellazione, il risultato non sarà un database. Devi prima modellare i dati (non il database), quindi assegnare Keys quando le quadro sono chiare e stabili. Quindi rilascia tutti i tuoi ID e PK e modella i dati, come dati. Dimentica ciò che vuoi fare con i dati (ad esempio dimentica l’app).

Non hai affrontato il problema, che ho identificato nel tuo diagramma del passaggio 1 , nel tuo diagramma del passaggio 3 . Dalle prove, sembra che tu possa essere felice con ID come “Chiavi Primarie” (non ce ne sono), nonostante l’ostacolo ti sia stato identificato. Ciò significa che la comprensione dei dati è compromise e il progresso dei diagrammi sarà lento.

La mia precedente risposta si applica ancora:

Un campo ID non identifica nulla e non fornisce univocità nei dati , cosa necessaria se si desidera l’integrità dei dati. Gli ID generano un sistema di archiviazione dei record senza integrità, tuttavia, sembra che si desideri un database con integrità dei dati. È corretto ?

Devi rispondere a queste domande, altrimenti il ​​tuo progetto non può procedere. Questi sono errori gravi che devono essere corretti. Non si può build, o progredire, una fondazione che contiene errori gravi.

  1. Potresti confermare, vuoi un database relazionale, con l’integrità e le prestazioni di cui sono capaci i database relazionali, che è facile da codificare, al contrario di un sistema di archiviazione dei record, senza integrità o velocità, che sarà difficile codice contro. Corretta ?

  2. Se [1] è corretto. Poiché i campi ID come “Chiavi primarie” non forniscono l’unicità della riga , richiesta per un database relazionale, con quale precisione, si intende fornire l’unicità della riga richiesta? In alternativa, sei felice di avere una RFS piena di righe duplicate (ognuna con un ID record univoco)?

quanto sarà facile scrivere correttamente un codice sql per l’esame della popolazione di esame per un particolare candidato

La mia precedente risposta si applica ancora:

In questo momento non puoi. Non hai alcuna relazione tra Candidato ed Esame [Risultato]. Questo non è un problema perché la modellazione è incompleta in questa fase, quando sarà completo il codice sarà semplice.

Ok, nel Diagramma Step 3 , hai tracciato una linea tra il file Candidate e il file ExaminationResult (invece di inserire una relazione in un database).

  • In un sistema di archiviazione dei record, certo, puoi semplicemente tracciare una linea tra due file qualsiasi, inserire il campo ID pertinente, e presto, hai “collegato” o “connesso” o “mappato” i due file.

  • Ma la progettazione del database (al contrario del disegno del file) non progredisce in questo modo, non si può semplicemente tracciare una linea tra due oggetti qualsiasi, inserire il campo ID pertinente, e presto, creare una relazione tra database . No. Non c’è alcuna base, nessuna integrità , nella linea tratteggiata che hai disegnato. Per esempio. nel diagramma del punto 3 , qualsiasi candidato può essere correlato a qualsiasi esame [risultato].

  • Questo è “normale” o “ordinario” nei sistemi di archiviazione dei record, ma in un database, è qualcosa che deve essere riconosciuto e compreso come un errore e quindi prevenuto. Perché ci aspettiamo integrità in un database e perché può essere prevenuto, facilmente.

tuttavia non sono sicuro se sono sulla strada giusta, specialmente dalla tabella degli esami alla tabella dei risultati dell’esame

La mia precedente risposta si applica ancora:

Sei sulla strada giusta con alcuni degli altri file, ma il cluster Examination ha bisogno di lavoro. Questo richiederà un po ‘di andirivieni. Una volta che hai risposto alle domande nei commenti, possiamo procedere.

Il problema principale è questo: come viene identificato l’ esame.

Un campo ID non identifica una riga (identifica un record, che non ha alcuna rilevanza in un database).

Gli stessi due problemi (a) mancanza di un identificatore valido e (b) mancanza di unicità della riga , esiste con i file Candidato, Componente ed EsaminazioneRisultato.

Risposta al diagramma come diagramma (a differenza del contenuto)

Lo hai migliorato rispetto al tuo diagramma Step 1 e in risposta al mio Response Step 2, ottimo. Ma le relazioni (la maggior parte di esse) sono ancora errate. E la base di Candidate :: Esame non è ancora stata risolta.

  • Mi sembra che tu non sia chiaro riguardo alla notazione (tacche, cerchi, zampe di gallina) e precisamente cosa significano alla fine del genitore e del bambino). Quindi devi prima apprenderlo e poi disegnare il diagramma, piuttosto che il contrario.

  • È bello che tu stia usando una notazione che è significativa, e molti dettagli sono mostrati (molte persone no, disegnano diagrammi dall’aspetto gradevole che mancano dei dettagli necessari per una piena comprensione del modello. cerchio, zampe di gallina, ha un significato specifico e deve essere disegnato correttamente, al fine di trasmettere quel significato al lettore.

  • Le entity framework non esistono in modo isolato, deve sempre esserci un genitore prima, in modo che il bambino sia figlio del genitore. Non esiste una cosa come “uguale”. La dipendenza è sempre in una direzione.

  • Le relazioni che sono 1-and-only-1 su un lato e 1-and-only-1 sull’altro lato, non sono corrette, indicano un errore di normalizzazione. Il campo nel record subordinato può essere normalizzato nel record delle ordinate.

    • Per esempio. AdmissionLetter non è un file separato, una forma di identificatore AdmissionLetter (non un campo ID) deve trovarsi in Candidato.

    • Per esempio. Title :: Candidate è un errore di disegno, dovrebbe essere 1 alla fine del titolo e 0-a-molti alla fine del candidato.

  • In un modello di dati, in grassetto (per convenzione) si intende una chiave esterna migrata. La chiave primaria migrata non è in grassetto.

Risposta al contenuto del diagramma

  1. Dalle tue risposte, il termine Oggetto supera il termine Componente; La categoria trionfa su vari elementi liberamente identificati in un’unica quadro chiara.

  2. Non è ragionevole contemplare un Esame che esiste in modo indipendente (come lo hai modellato).

    • Le persone non vanno in una sala e si siedono per qualsiasi esame precedente, qualsiasi vecchio Sobject. L’esame esiste solo nel contesto di un sobject, siedono per un esame per un sobject .

    • Accetto che l’Esame sia una sola seduta, per quattro Soggetti

    • Accetto che i quattro soggetti siano definiti da una categoria.

    • Accetto che il Candidato sia registrato per una Categoria.

    • Quindi l’esame esiste solo nel contesto di un Sobject, che esiste solo nel contesto di una Categoria, e il Candidato si siede per un esame che è una Categoria, che contiene quattro (il numero non importa) Soggetti.

  3. Avendo risolto ciò, rimangono due domande:

    • Devi registrare un esame come evento, indipendentemente dai candidati che siedono in quell’evento. Per esempio. Esame (posizione, data e ora)?

    • L’evento d’esame esamina i candidati in uno o più di una categoria?

  4. La nozione di quattro argomenti implementati come quattro campi ripetuti in un record interrompe il secondo modulo normale, che richiede che i campi ripetuti siano normalizzati in record separati in un file secondario.

    • Pertanto, per entrambi i file Component ed ExaminationResult, è necessario risolvere il problema.

    • Si noti che il fatto che quel problema si ripete in due file separati è un secondo allarme che si tratta di un errore.

    Ho chiarito i problemi relativi a Categoria / Oggetto per te e ho risolto l’errore di Normalizzazione.

    • Ho fornito identificativi semplici per Categorie e Soggetti.

    • Se non lo applichi, non avrai integrità tra il Candidato e il Sobject per cui sono esaminati. Inoltre, soffrirai di vari problemi quando arrivi alla fase di codifica.

  5. Non ho idea di cosa stai provando a fare con exComp, quindi non ho alcuna risposta. Forse puoi dire alcune parole a riguardo.

  6. Finora, non esiste ancora un modo ragionevole per mettere in relazione i candidati con esami o esami. Cioè, non ha basi , nulla è stato definito come la base per la relazione, e quindi la relazione non ha integrità.

    • Sulla base di ciò che ho potuto accertare fino ad ora, ci deve essere una sorta di registrazione per un esame. Altrimenti non sapresti che un Candidato è seduto per un esame.

    • Quando i candidati si registrano, si registrano per un esame e quell’esame è definito (e quindi vincolato) da una categoria. Altrimenti ogni Candidato può sostenere qualsiasi esame, che credo, vorresti evitare.

    • Inoltre, i [quattro] argomenti di esame per i quali siedono, dovrebbero essere vincolati dalla categoria per cui sono stati registrati.

      • Vuoi assicurarti di non registrare un risultato di un esame di Economia per un Candidato registrato per la scienza, corretto?

    Ho determinato che la base di un esame è la registrazione. Questo è l’evento, il fatto, la registrazione di ciò, stabilisce che un candidato siederà per un esame.

    • L’ identificatore ti salta praticamente addosso, è CategoryCode più CandidateID. Ecco! abbiamo unicità di fila. Magnifique! abbiamo integrità.

    • Ora l’integrità di ExaminationResult può essere implementata: è vincasting alla CandidateRegistration :: Category e alla Category :: Subject.

  7. Per essere risolto: È necessario identificare il fatto che un candidato si iscriva ad un esame (RegistrationDate, AdmissionLetter di qualsiasi cosa) rispetto al fatto che il Candidato si sia seduto per l’esame (ad esempio, ExaminationDate)? Una specie di appello.

    In questo momento, l’ho modellato come un singolo fatto senza differenziazione, e il tavolo si chiama Esame perché sembra che tu sia concentrato su quello.

Predicato

Oggigiorno sembra che le persone si stiano lanciando a disegnare un diagramma, senza capire né le basi di un Database relazionale, né l’esercizio di dati di modellazione. Prevedibilmente, ciò si traduce in un diagramma mal definito (molti dettagli rilevanti sono omessi) [con gratitudine, il diagramma ha qualche definizione ] e produce un sistema di archiviazione dei record senza integrità, senza potere relazionale, senza velocità, invece di un Database relazionale con integrità, potenza e velocità.

Un concetto che spesso manca è Predicati. Un lettore competente può leggere un buon modello di dati, e accertare i predicati, perché sono disegnati nel modello, sotto forma di notazione, ma un novizio non capisce la notazione, o la rilevanza dei vari elementi, e quindi perdere i predicati. In breve, i Predicati sono tutti i vincoli che vengono posti sui dati:

  • Identificazione della fila:

    • La base della sua esistenza e come è identificata: indipendente (angoli quadrati); o dipendente (angoli arrotondati)
  • Unicità della riga: chiavi primarie e alternative (nota, gli IDs non sono chiavi)

  • Relazioni tra le righe:

    • Identificazione (linee continue); o Non identificante (linee tratteggiate)

    • Significato, rilevanza, scopo: l’importantissima frase verbale

Inoltre, un novizio non può determinare i Predicati quando non c’è un diagramma, o quando il diagramma è scarso, o quando stanno progettando il sistema di archiviazione e disegnando il diagramma da soli. Quindi non identificano i predicati rilevanti nel loro diagramma.

I predicati sono molto importanti durante l’esercizio di modellazione, in quanto oltre al modello che esprime i Predicati, i Predicati confermano l’accuratezza del modello, è un ciclo di feedback. È una parte essenziale dell’esercizio di modellazione. Dal momento che sto eseguendo l’attività di modellazione per te, sto elaborando i Predicati mentre svolgo questo compito, sono ovvi per me. Ma potrebbero non essere ovvi per te.

Quando il modello dati è pubblicato e pronto per la discussione con gli utenti, questi Predicati sono incorporati in esso. Sono sotto il titolo di Business Rules , ne fanno parte, perché questo è il modo in cui l’utente li percepisce. Di conseguenza, durante le procedure dettagliate e le discussioni, i Predicati (così come le altre Regole aziendali dichiarate) vengono confermati o negati dall’utente. Devono essere dichiarati esplicitamente, perché a differenza dello sviluppatore tecnicamente istruito, non ci si può aspettare che l’utente legga tutti i Predicati pertinenti dalla notazione in un buon modello di dati.

In questa situazione, io sono il modellatore e tu sei l ‘”utente”. Quindi ho deciso di fornire i Predicati per te, esplicitamente. In modo che tu possa confermarli o negarli, e così possiamo progredire nell’esercizio di modellazione. Una volta che ti sei abituato a leggere i Predicati da un buon modello di dati, non avrai bisogno di averli dichiarati esplicitamente per te. Ancora una volta, i predicati sono molto importanti perché verificano (o meno) l’accuratezza del modello. Quindi, per favore, leggi attentamente e commenta qualsiasi Predicato con cui non sei completamente d’accordo o che non capisci.

Naturalmente, non è necessario dichiarare esplicitamente tutti i Predicati, ce ne sono troppi, dichiariamo solo quelli più rilevanti, che riguardano:

  • (a) righe (tabelle), la base per la loro esistenza

  • (b) la loro identificazione

  • (c) tutte le dipendenze

  • (d) relazioni, entrambi i lati (un lato è la frase verbale).

Step 4 TRD

Ho implementato tutto quanto sopra, come dettagliato. Per favore considera questo TRD come una piattaforma di discussione per la successiva iterazione e commenta. Il corriere indica i dati di esempio, il blu indica i valori chiave, il verde indica i valori non chiave:

  • Step 4 TRD

Risposta Passaggio 6 alla chat Passaggio 5

Tutti i problemi discussi sono stati risolti e implementati nel modello. Siamo spiacenti, non ho il tempo per postare dettagli, questo è semplicemente identifica i modelli aggiornati.

  • Relazione quadro e predicati completi a pagina 1

    Tutti i problemi risolti sono stati implementati.

    predicati
    Ora che è stabile, ti sto dando il secondo lato dei Predicati di relazione (da bambino a genitore). E ora che li capisci, ho cancellato il ripetuto, fastidioso “Ognuno” che è richiesto per i novizi.

  • Chiave quadro-relazione a pagina 2

    Ora che il TRD è stabile, siamo pronti per procedere alla Determinazione delle Chiavi

    (Secondo solo alla Normalizzazione, la Determinazione Chiave è una parte fondamentale dell’esercizio di modellazione: i due compiti sono normalmente eseguiti fianco a fianco, sono inseparabili, ho già determinato le chiavi, in questo caso, date le limitazioni della comunicazione media, lo presento come un passaggio sequenziale).

    Qui, io uso un’estensione alla notazione IDEF1X che mi consente di concentrarmi sui componenti rilevanti per il compito, mi aspetto che sia auto-esplicativo. Vengono fornite solo le colonne Chiave. Le chiavi esterne non sono grassetto (come sono nel DM). Tutto ciò, è destinato a renderlo facile per gli occhi.

    La maggior parte delle tabelle ha una chiave (primaria). Dove ci sono due chiavi (primaria e alternativa), l’ AK è sotto la linea.

    Questa è la mia raccomandazione per le Chiavi, come richiesto, per la tua recensione.

Step 6 TRD e TRK 6