Qual è la differenza tra un modello di relazione di un’ quadro e un modello relazionale?

Sono stato solo in grado di trovare le seguenti due differenze:

  1. Le relazioni in un modello ER sono definite esplicitamente, mentre sono implicite in un modello relazionale.
  2. I modelli relazionali richiedono una tabella intermedia (spesso chiamata “tabella di giunzione”) per contenere due chiavi esterne che implementano la relazione molti-a-molti.

E perché usiamo il modello relazionale, quando abbiamo un diagramma ER?

Hai indietro.

  1. Le relazioni in un modello ER sono definite esplicitamente, mentre sono implicite in un modello relazionale.

No. Ogni tabella di base del database del modello relazionale (RM) e il risultato della query rappresentano una relazione di applicazione. Gli schemi E-RM (Entity-Relationship Modeling) sono solo un modo di organizzare (ma sottoutilizzando e sotto-specificando) (ma con l’incomprensione) tabelle e vincoli relazionali.

  1. I modelli relazionali richiedono una tabella intermedia (spesso chiamata “tabella di giunzione”) per contenere due chiavi esterne che implementano la relazione molti-a-molti.

No. Si tratta di approcci Object-Relational Mapping (ORM) che oscurano le loro relazioni, tabelle e vincoli relazionali diretti e diretti. La nozione di “tabella di giunzione” è nata da incomprensioni di ORM di presentazioni confuse dell’E-RM che di per sé non comprende l’RM.

Come CJ Data ha messo un Introduzione ai sistemi di database, 8 ° ed:

una lettura caritatevole della [carta originale di Chen] suggerirebbe che il modello E / R è in effetti un modello di dati, ma che è essenzialmente solo un sottile strato sopra il modello relazionale di base [p 426]

È un triste commento sullo stato del settore IT che le soluzioni semplici sono popolari anche quando sono troppo semplici. [p 427]

Il modello relazionale

Ogni tabella relazionale rappresenta una relazione di applicazione.

-- employee EID has name NAME and ... E(EID,NAME,...) 

Il termine matematico per una cosa del genere, e anche per una serie di tuple ordinate matematiche che rappresentano una, è una “relazione”. Da qui il “Modello Relazionale ” (e “Modellizzazione Entità- Relazione “). Nelle relazioni matematiche sono spesso descritte da modelli di istruzioni parametrizzati per i quali un termine matematico è “predicato caratteristico”. I parametri del predicato sono colonne della tabella. Nell’RM un DBA fornisce un predicato per ogni tabella di base e gli utenti inseriscono le righe che realizzano un’istruzione vera dai valori delle colonne e il predicato nella tabella e lasciano le righe che emettono un’istruzione errata.

 /* now also employee 717 has name 'Smith' and ... AND employee 202 has name 'Doodle' and ... */ INSERT INTO E VALUES (EID,NAME,...) (717,'Smith',...),(202,'Doodle',...) 

Un’espressione di query ha anche un predicato costruito dagli operatori di relazione e dagli operatori logici (in condizioni) in esso. Il suo valore contiene anche le righe che rendono vero il suo predicato e lascia fuori quelle che lo rendono falso.

 /* rows where FOR SOME E.*, M.*, EID = E.EID AND ... AND MID = M.MID AND employee E.EID has name E.NAME and ... AND manager M.MID has AND E.DEPT = M.DEPT AND E.NAME = 'Smith' /* SELECT E.*, M.MID FROM E JOIN M ON E.DEPT = M.DEPT WHERE E.NAME = 'Smith' 

Le file di tabelle presenti che rendono le dichiarazioni vere e le righe assenti che fanno dichiarazioni false sono il modo in cui registriamo la situazione dell’applicazione nel database e come interpretiamo ciò che il database dice sulla situazione dell’applicazione. Non è ansible utilizzare o interpretare il database senza avere e comprendere i predicati, ovvero le relazioni delle applicazioni.

Modellazione entity framework-relazione

E-RM (che in realtà non capisce l’RM) è essenzialmente una (n inutile, ristretta e restrittiva) notazione diagrammatica per la descrizione (alcune parti di) (limitate forms di) database relazionali. Inizialmente esistevano icone / relazioni ” quadro (class)” in cui i valori della chiave candidata (CK) erano 1: 1 con le entity framework dell’applicazione più altre colonne (“proprietà” dell’entity framework) e c’erano le icone “relazione (class)” / tabelle che avevano chiavi esterne (FK) per le tabelle di entity framework che rappresentano relazioni di applicazione su più entity framework più altre cose (“proprietà” della “associazione”). Una relazione applicativa era rappresentata da un’icona con le linee alle varie icone di quadro che vi partecipavano. (Cioè le linee rappresentano gli FK, che non sono relazioni ma affermazioni sui vincoli sulle tabelle).

E-RM non capisce il modello relazionale. Fa una distinzione inutile e fuorviante tra quadro applicative e relazioni. Dopotutto, ogni superkey (set di colonne unico) di ogni tabella di base o risultato di una query è in corrispondenza 1: 1 con alcune entity framework applicative, non solo con quelle che hanno tabelle di quadro. Ad esempio, le persone possono essere associate per il fatto di essere sposate; ma ciascuna di queste associazioni è 1: 1 con un’ quadro chiamata matrimonio. Ciò porta a normalizzazione e vincoli inadeguati, quindi ridondanza e perdita di integrità. Oppure, quando tali passaggi vengono eseguiti in modo adeguato, il diagramma ER non descrive in realtà l’applicazione, che è in realtà descritta dai predicati, dalle tabelle e dai vincoli del database relazionale. Quindi il diagramma ER è sia vago, ridondante e sbagliato.

Stenografia E-RM e ORM

Un sacco di presentazioni e prodotti che dichiarano di essere E-RM deformano l’E-RM, per non parlare della RM. Usano la parola “relazione” per indicare un vincolo FK. Questo si presenta come segue. Quando una relazione E-RM è binaria, è un simbolo con due linee ai suoi FK. Quindi queste tre cose possono essere sostituite da una linea tra FK. Questo tipo di linea rappresenta quella particolare relazione binaria e le sue FK, ma ora la relazione ER non è esplicita nel diagramma sebbene la relazione ER sia esplicita nella versione longhand e viene riflessa da una tabella in quali sono le immagini dei diagrammi , vale a dire la database relazionale che stanno descrivendo . Questo viene chiamato una “tabella di congiunzione”. E la gente parla di quella linea / tabella che è / che rappresenta “una relazione X: Y” tra quadro e / o associazioni senza in realtà mai notare che si tratta di una particolare relazione di applicazione . E possono esserci molti rapporti di applicazione tra le stesse due entity framework e / o associazioni.

Gli ORM fanno anche questo, ma sostituiscono anche le associazioni n-ary solo con i loro FK in modo che la relazione e la tabella associate siano ulteriormente oscurate. Active Records va anche oltre definendo diverse relazioni di stenografia e le loro tabelle contemporaneamente, equivalenti a una catena di linee FK e icone di associazione nel diagramma E-RM di lunga durata. Ciò è esacerbato da molte tecniche di modellazione, incluse le versioni di E-RM e ORM, anche pensando che le relazioni delle applicazioni possano essere solo binarie. Di nuovo, questo è sorto storicamente da mancanza di comprensione del RM.

Sono due cose diverse di per sé. Un modello relazionale rappresenta le informazioni come tuple, direttamente mappate a uno schema relazionale. Le linee guida derivano dall’algebra relazionale.

Nel frattempo, un diagramma ER modella le relazioni tra gli utenti e i relativi dati sottostanti in un sistema che utilizza entity framework. Un diagramma ER può essere associato a un modello relazionale e infine a uno schema funzionante.