Progettazione di database per uno strumento di manutenzione giornaliero

Question

Progettazione di database per uno strumento di manutenzione giornaliero

#1 da (0 voti)

1

Sto pensando alla corretta progettazione del database per questo requisito.

È un controllo di manutenzione manuale. Una società può avere un contratto di manutenzione comprendente controlli HW, controlli Sys, entrambi o nessuno. La parte con CommandParameters mi preoccupa particolarmente. La quantità / nome dei comandi può essere cambiato dopo un po ', inoltre dipendono da ciascuna società. Stavo pensando di esternalizzare CommandParameters alla sua tabella, collegandola con MaintenanceContract . I comandi sarebbero tutti in una colonna, separati da un delimitatore. La casella di controllo e la riga di commento (testo libero) non sono direttamente collegate a loro (vedi sotto). Il problema qui è che devo essere sicuro che la quantità di delimitatori di testo libero, la casella di controllo, i comandi sono sempre gli stessi. Immagino che non sia possibile nella struttura, che ho progettato qui sotto. Sarebbe bello, quando hai altre idee / migliori.

Quilabozzadeldatabase:

database database-design

posta Matej 25.08.2016 - 09:08

fonte

1 risposta

Leggi altre domande sui tag database database-design

Coprendo una griglia con un numero minimo di rettangoli Scambia tra concorrenza e stagnazione in un problema analogo di Dining Philosophers?

score 0 · Accepted Answer

Varietà:

La relazione tra COMPANY e MACHINE dovrebbe essere 1: M e non 1: 1
MAINTENANCE_HW e MAINTENANCE_SW sono fondamentalmente gli stessi
La colonna COMMANDS viola NF1 avendo più valori separati da una virgola
La relazione tra MAINTENANCE_TYPE e MAINTENANCE deve essere M: M e non 1: 1 per un contratto che includa sia harwd che soft come si afferma:

Suggerimento:

MAINTENANCE_HW e MAINTENANCE_SW devono essere uniti e quindi rinominati MAINTENANCE_LOG
Come fai a sapere quale riga è l'hardware e cos'è il software: attraverso l'FK con MAINTENANCE_CONTRACT - > MAINTENANCE_TYPE
COMMAND_PARAMETER dovrebbe essere una tabella separata
Ogni elemento in MAINTENANCE_LOG è correlato a un parametro di comando

UPDATE:

Dato che stiamo normalizzando COMMAND_PARAMETER (ricorda che NF1 proibisce i valori multipli in una colonna. Quindi creiamo la costruzione principale / dettaglio dove COMMAND è la tabella principale e COMMAND_PARAMETER ha tutti i parametri di quel comando. descrizione del comando. COMMAND_PARAMETER ha un ID e la descrizione del parametro.
Ho anche corretto e errore nel mio design. Ora MAINTENANCE_LOG punta alla tabella di join CONTRACT_MAINTENANCE_TYPE . In questo modo sai cosa succede se è HW o SW e transitivelly a quale contratto appartiene.
Non ho aggiunto tutti i nomi di colonna perché è un modello concettuale, non un modello fisico. In quella fase puoi ancora correggere molti errori concettuali prima di creare effettivamente delle tabelle. In questa fase non sono ancora tavoli, ma entità. Le tabelle con una relazione che punta a un'entità padre avranno un FK e qualsiasi altra colonna che si desidera.

Unmodellofisico,pratico: