Sono cose come le tabelle? O includerebbe anche cose come vincoli, stored procedure, pacchetti, ecc.?Che cos'è una "entità database" e quali tipi di elementi DBMS sono considerati entità?
Ho guardato intorno a Internet, ma trovare le risposte alle domande più elementari elementari è a volte un po 'difficile.
Nel mondo di relazione entità un'entità è qualcosa che può esistere indipendentemente e quindi esiste spesso una relazione uno a uno tra entità e tabelle di database. Tuttavia, questa mappatura è una decisione di implementazione: ad esempio, un diagramma ER può contenere tre entità: Triangolo, Quadrato e Cerchio e queste potrebbero essere modellate come una singola tabella: Forma.
Si noti inoltre che alcune tabelle di database possono rappresentare relazioni tra entità.
che tipo di dipende da come si pensa a questo proposito e come si modella il vostro dominio del problema. la maggior parte delle volte in cui si sente parlare di entità, si tratta di tabelle di database (una o più) mappate su classi di oggetti. Quindi non è realmente un'entità finché non è stata richiesta e trasformata in un'istanza di classe.
ma ancora una volta, dipende dalla vostra metodologia di modellazione, e ci sono più :-)
Questa è una questione molto generale!
Fondamentalmente, tutti i tipi che il sistema di database stesso offre, come NUMERIC, VARCHAR ecc., O che il linguaggio di programmazione di scelta offre (int, string ecc.) Sarebbero considerati tipi di dati "base".
Tutto ciò che si - sulla base o le esigenze di business del vostro programma - costruire questo, gli oggetti di business e così via, sono entità.
tabelle, vincoli e così via sono oggetti di database-interno necessarie per memorizzare e recuperare i dati, ma quelli sono generali "entità" non considerati. I dati memorizzati nelle tabelle, quando viene recuperato e trasformato in un oggetto, che allora è un'entità.
Marc
Aggiornamento:
veda questo articolo nel mio blog in cui cerco di coprire l'argomento in modo più dettagliato:
Un'entità è un termine dallo entity-relationship model.
A relational model (lo schema del database) è uno dei modi per implementare il modello ER.
Le tabelle relazionali rappresentano le relazioni tra tra tipi semplici come numeri interi e stringhe, che a loro volta possono rappresentare tutto: entità, attributi, relazioni.
Non si può sapere che cos'è solo dalla struttura relazionale, è necessario vedere il modello ER.
Per tabella persons,
id name surname
1 John Smith
id, name e surname sono entità del mondo reale e può o non può rappresentare entità nel modello ER sottostante.
Il fatto di un record presente nella tabella significa che queste entità sono nella seguente relazione: "person 1ha nome John e ha cognome Smith".
Nell'esempio sopra, l'entità è definita da id (dal punto di vista del modello).
Se una persona cambia il suo nome da John a Jack, la persona rimane la stessa (di nuovo, dal punto di vista del modello), ma viene collegata a un altro name.
Nell'esempio sopra name e surname può essere trattata come attribute (al contrario di entity), ma ancora una volta, è necessario vedere il modello ER che questo schema implementa per dire di cosa si tratta.
In alcune mappature del modello ER-a-relazionale, un'entità deve essere definita in una tabella referenzeable con un FOREIGN KEY da considerarsi un entity (che dovrebbe vincolare il suo dominio).
Tuttavia, questo vincolo può esistere ma non essere rappresentato in un database (a causa di limitazioni tecnologiche o altro).
Come, non è possibile mantenere un elenco di tutti i possibili nomi, ma il nome di @#$^# è molto probabilmente un non-nome, quindi, non appartiene al dominio dei nomi.
Pertanto, uno attribute è un entity che può partecipare a una relazione ma non può essere contenuto in una tabella di definizione del dominio.
Ad esempio, la tabella prices:
good_id price
definisce relazioni tra l'insieme di prodotti (che è definito dalla tabella goods) e l'insieme di numeri reali (che non può essere contenuto in una tabella poiché è nemmeno numerabile).
Ancora ogni prezzo (come $2.00) è anche un'entità del mondo reale.
non sono id, nome e cognome ATTRIBUTI piuttosto che ENTITÀ? –
A mio parere, questa riga che rappresenta uno "Smith, John" come TUTTO sarebbe un'entità –
'@ marc_s': pazienza! – Quassnoi
Avremmo bisogno di conoscere un contesto. Una cosa che le persone talvolta fanno quando analizzano i dati in preparazione per la progettazione di un database è creare un Diagramma Realtàhip di entità, in cui si stanno valutando quali dati sono gestiti e le loro relazioni.
Mi chiedo se questo è il contesto che intendi?
Se sì, forse una lettura di questo article potrebbe iniziare?
Questo thread sta dimostrando una ragione per cui è difficile trovare "risposte elementari a domande elementari". Alcune parole sono state usate da diversi paradigmi di programmazione per indicare cose diverse (prova a chiedere a un gruppo di programmatori OO qual è la differenza tra una classe e un oggetto a volte).
Ecco la mia opinione.
Ho incontrato Entity come termine di modellazione in SSADM (chiedi a tuo padre). In quel contesto un'entità viene utilizzata per modellare un gruppo logico di dati durante la fase di raccolta/analisi dei requisiti. Le relazioni tra entità sono state modellate utilizzando i diagrammi di relazioni di entità e il profilo di un'entità è stato modellato utilizzando le storie di vita di entità. I diagrammi ELH erano molto utili nei sistemi COBOL ma assolutamente orribili nei database relazionali. D'altra parte, gli ERD continuano ad essere utili fino ad oggi.
Durante le fasi di progettazione e implementazione le Entità vengono risolte in tabelle di database, oggetti o record in un file di input COBOL. Nel corso di tale processo un'entità logica può essere suddivisa su più tabelle, o più entità possono essere squittite in una singola tabella, o ci può essere una mappatura uno-a-uno. A volte un'entità viene risolta completamente o si attesta come una vista o una stored procedure.
Questo sembra utile: http://en.wikipedia.org/wiki/Entity-relationship_model
In un database di un'entità è una tabella. La tabella rappresenta qualsiasi concetto del mondo reale che stai cercando di modellare (persona, transazione, evento).
I contrapposti possono rappresentare relazioni tra entità. Queste sarebbero chiavi estranee. Applicano anche regole come first_name non possono essere vuote (null). Una transazione deve avere 1 o più elementi. Un evento deve avere una data.
stored procedure/pacchetti/trigger possono gestire relazioni più complesse e/o possono gestire le regole aziendali, dipende solo da ciò che sta facendo.
spiegazione grande e semplice! - "In un database un'entità è una tabella, la tabella rappresenta qualsiasi concetto del mondo reale che si sta tentando di modellare (persona, transazione, evento)." –
Le entità sono "cose importanti" per il dominio utenti/azienda/impresa/problema.
La mia risposta è, ovviamente, un po 'in ritardo, ma qui è come definito in un libro di testo di certificazione del database:
Entità: Un elemento identificabile in modo univoco su cui i dati vengono memorizzati in un database.
e chiarire entità e tabella di confusione,
entità non è una tabella. Le tabelle possono essere chiamate "tabelle" o "relazioni" e le parole sono sinonimi.
Prima chiarisci la tua risposta – user1972007
Sono d'accordo con te. Una "Entità" è solitamente la rappresentazione di un oggetto del mondo reale. Una tabella PERSON è l'entità che rappresenta una persona del mondo reale. Cose come nome, cognome, ecc. Sono attributi dell'entità. –