Viene chiamato il numero di entità su ciascun lato della connessione. Il modello di dati entità-relazione. Elenco di controllo delle domande degli attributi

Uno dei mezzi più popolari per una rappresentazione formalizzata dell'area tematica dei sistemi orientati all'elaborazione delle informazioni fattuali è il modello "entità - comunicazione", che sta alla base di un numero significativo di prodotti CASE commerciali che supportano l'intero ciclo di sviluppo dei sistemi di database o le sue singole fasi. Allo stesso tempo, molti di essi non solo supportano la fase di progettazione concettuale dell'area tematica del sistema sviluppato, ma consentono anche di eseguire la fase di progettazione logica sulla base del modello costruito con i loro mezzi generando automaticamente uno schema di database concettuale per il DBMS selezionato, ad esempio uno schema di database per qualsiasi SQL -server o DBMS oggetto.

In questo caso, la modellazione di domini si basa sull'uso di grafici che includono un numero relativamente piccolo di componenti e, soprattutto, - tecnologia di costruzionetali diagrammi.

La base semantica del modello ER sono i seguenti presupposti:

quella parte del mondo reale (un insieme di oggetti interconnessi), le cui informazioni dovrebbero essere collocate nel database, possono essere presentato cometotalità entità;

ogni entità ha proprietà caratteristiche (attributi) che la distinguono dalle altre entità e la consentono per identificare;

le entità possono essere classificate per tipo di entità: ogni istanza di entità (che rappresenta un oggetto) può essere assegnata perclasse - tipo di entitàogni istanza delle quali ha proprietà in comune e le distingue dalle essenze di altre classi;

la sistematizzazione basata su classi di una rappresentazione generalmente presuppone una dipendenza gerarchica di tipi: un'entità di tipo E è un sottotipoentità NEL,se ogni istanza di tipo E è un'istanza di un'entità di tipo NEL;

le relazioni dell'oggetto possono essere rappresentate come comunicazione-entitàche servono a fissare (rappresentare) l'interdipendenza di due o più entità.

Qui dovremmo ancora una volta sottolineare la natura informativa del concetto essenzae il suo rapporto con oggetti materiali o immaginari dell'area tematica. Qualsiasi oggetto nel dominio ha proprietà, alcune delle quali si distinguono come caratteristiche - significative dal punto di vista del problema applicato. In questo caso, ad esempio, nel processo di analisi e sistematizzazione dell'area tematica di solito spiccano classi -un set di oggetti con lo stesso set di proprietà definito nel modulo set di attributi(i valori degli attributi per gli oggetti della stessa classe, ovviamente, possono variare). Di conseguenza, a livello di rappresentazione dell'area tematica (cioè il suo modello infologico), l'oggetto considerato come un concetto (un oggetto nella mente umana) corrisponde al concetto essenza;l'oggetto, come parte del mondo materiale (ed esistente indipendentemente dalla coscienza umana), corrisponde al concetto istanza dell'entità;la classe di oggetti corrisponde al concetto tipo di entità.

In futuro, poiché il modello infologico non considera le singole istanze di oggetti, ma le classi, non distingueremo tra i concetti corrispondenti di questi due livelli, ovvero assumeremo l'identità dei concetti un oggettoe entità, proprietà di un oggettoe proprietà di un'entità.

Modello ERcome descrizione dell'area tematica, deve determinare gli oggetti e le relazioni tra loro, ovvero stabilire le connessioni dei seguenti due tipi.

1. La relazione tra oggetti e insiemi di proprietà caratteristiche, e quindi determina gli oggetti stessi.

2. Relazioni tra oggetti che definiscono la natura e la natura funzionale della loro interdipendenza.

Come notato in precedenza, la modellazione ER del dominio del soggetto si basa sull'uso di diagrammi grafici come un modo semplice (familiare), visivo e allo stesso tempo informativo e multi-aspetto di visualizzare i componenti del progetto. Pertanto, la dichiarazione delle principali disposizioni del modello ER sarà illustrata dal materiale dell'esempio del diagramma ER mostrato in Fig. 5.4.

Essenza.L'entità con cui viene modellata la classe di oggetti dello stesso tipo viene definita come "un oggetto che può essere chiaramente identificato". Proprio come ogni oggetto è caratterizzato in modo univoco da un insieme di valori di proprietà, l'entità deve essere determinatocome un insieme di attributiche consentirebbe di distinguere le singole istanze dell'entità. Ogni istanza di un'entità deve essere distinguibile da qualsiasi altra istanza della stessa entità (questo requisito è simile al requisito che non ci sono tuple duplicate nelle tabelle relazionali). Ad esempio, per identificare in modo univoco ogni istanza dell'entità "Dipendente", viene introdotto l'attributo "Numero del personale", che per sua natura avrà sempre significato unico all'interno dell'impresa. Cioè, un identificatore univoco di un'entità può essere un attributo, una combinazione di attributi, una combinazione di relazioni o una combinazione di relazioni e attributi che distingue in modo univoco qualsiasi istanza di un'entità da altre istanze di un'entità dello stesso tipo.

Essence ha nome,unico nel modello. dove nome dell'entità -questo è digitare il nomenon un'istanza specifica.

Le entità sono divise in fortee debole.Un'entità è debole se la sua esistenza dipende da un'altra entità forte in relazione ai nodi. Ad esempio, l'entità subordinata è debole rispetto a perentità "Dipendente": se un record corrispondente a un dipendente con subordinati viene eliminato, anche le informazioni sulla subordinazione devono essere eliminate.

ProprietàProprietà naturali come natura della comunicazionele proprietà con un'entità (oggetto) possono essere diverse. Considera i principali tipi di proprietà.

La proprietà potrebbe essere pluraleo singolo -vale a dire, un attributo che definisce una proprietà può avere più valori contemporaneamente o, di conseguenza, solo uno. Ad esempio, un dipendente può avere diverse specialità, ma l'unico valore è il numero del personale.

La proprietà potrebbe essere semplice(non soggetto ad ulteriore divisione in termini di compiti applicati) o composito -se il suo valore è composto dai valori di proprietà semplici. Ad esempio, la proprietà "Anno di nascita" è semplice e la proprietà "Indirizzo" è composta, poiché include i valori delle proprietà semplici "Città", "Via", "Casa".

In alcuni casi, è utile distinguere tra di basee derivatiproprietà. Ad esempio, il "Fornitore" può avere la proprietà "Numero totale di parti fornite", che viene calcolato sommando il numero di parti fornite da esso per il progetto.

Se la presenza di alcune proprietà per tutte le istanze dell'entità è facoltativa, viene chiamata tale proprietà condizionale.Ad esempio, non tutti i dipendenti hanno la proprietà "titolo accademico".

I valori delle proprietà possono essere costanti - staticoo dinamicocioè, cambiare nel tempo. Ad esempio, la proprietà Numero personale è statica e Indirizzo dinamico. La proprietà potrebbe essere vagose è dinamico, ma il suo valore attuale non è stato ancora impostato.

Una proprietà può essere considerata come chiavese il suo significato è unico e, possibilmente, in un determinato contesto, identifica in modo univoco l'entità. Ad esempio, un subordinato di un determinato dipendente.

Comunicazione.Oltre alle relazioni tra un oggetto e le sue proprietà, il modello infologico riflette le relazioni tra oggetti di classi diverse. NEL comunicazionedefinita come "associazione di più entità". Questa associazione può sempre esistere tra entità diverse o tra un'entità e se stessa (connessione ricorsiva).

Come l'essenza, la comunicazione è tipicoil concetto, cioè tutte le istanze di entità vincolate obbediscono alle regole di tipo binding. Il principio delle differenze nei tipi di relazioni tra tipi e istanze è illustrato dai diagrammi ER per i tipi e le istanze mostrati in Fig. 5.5.

Vengono chiamate entità unite da una connessione partecipanti. Grado di comunicazionedeterminato dal numero di partecipanti alla comunicazione.

Se ogni istanza di un'entità partecipa ad almeno un'istanza di una relazione, viene chiamata tale partecipazione di questa entità completare(o obbligatoria);altrimenti - incompleto(o opzionale).

È specificata la natura quantitativa della partecipazione delle istanze di entità (una o più) tipo di comunicazione(o potere di comunicazione)Sono possibili i seguenti tipi: "uno a uno"(1:1), Uno a molti(1M), Molti a uno(M: 1) Molti a molti(M: M).

Va notato che lo strumento di comunicazione è un mezzo di presentazione oggetti complessiognuno dei quali può essere considerato un insieme in qualche modo interconnesso oggetti semplici.La divisione in oggetti semplici e complessi, così come la natura della relazione, è condizionata ed è determinata dalle caratteristiche dell'analisi dell'area tematica, che è, alla fine, dalla natura dell'uso di questi oggetti nei problemi applicati risolti. Inoltre, dal punto di vista, ad esempio, del designer, DETAIL è un oggetto complesso e dal punto di vista del fornitore è semplice.

Tra le molte varietà di relazioni, le più comuni sono le relazioni gerarchiche come "parte intera", "genere-specie".

La relazione parte intera viene utilizzata per rappresentare oggetti composti.Ad esempio, LE MACCHINE sono composte da NODI, NODI costituiti da PARTI. Possibile qui come relazione "Uno a molti"come quello "Molti a molti."

La relazione "genere - specie" - da rappresentare oggetti generalizzati. Ad esempio, i DIPENDENTI sono divisi per professione in DESIGNER, PROGRAMMATORI, LAVORATORI; PROGRAMMATORI - su PROGRAMMATORI APPLICATI e PROGRAMMATORI DI SISTEMA. Le relazioni gerarchiche, e in particolare le relazioni "clan-specie", sono generalmente utilizzate come base per classificare gli oggetti in base a serie di caratteristiche. Inoltre, oggetti "specie" ereditareproprietà di "generico".

Un altro tipo di interconnessione ampiamente utilizzato è l'aggregazione: l'unione di oggetti semplici in oggetti complessi per principio di appartenenza aggregatoo la loro partecipazione congiunta in qualche processo. L'aggregazione, qui considerata come un caso più generale di relazioni gerarchiche, combina oggetti di diversa natura con l'unica "partecipazione comune" di proprietà comune. Gli oggetti aggregati sono generalmente chiamati nomi verbali, ad esempio, "Composizione":SUDDIVISIONE consiste diDIPENDENTI; "Fornitura":PROVIDER fornitureDETTAGLI.

Supertipi e sottotipi.Un'entità può essere suddivisa in due o più mutuamente esclusive sottotipiognuno dei quali include attributi e / o relazioni comuni. Questi attributi e / o relazioni comuni vengono definiti esplicitamente una volta a un livello superiore. I sottotipi possono definire i propri attributi e / o relazioni. In linea di principio, l'assegnazione dei sottotipi può continuare a livelli inferiori, ma nella maggior parte dei casi sono sufficienti due o tre livelli.

Viene chiamata l'entità sulla base della quale vengono determinati i sottotipi supertipo.I sottotipi devono formare un set completo, ovvero qualsiasi istanza di un supertipo deve appartenere a un determinato sottotipo. A volte per completezza dell'insieme è necessario definire un sottotipo aggiuntivo, ad esempio ALTRI.

Un sottotipo eredita le proprietà e le relazioni di un supertipo. Ad esempio, un tipo di entità PROGRAMMATOREè un sottotipo di entità DIPENDENTE.I programmatori hanno tutte le proprietà dei dipendenti e partecipano a tutte le relazioni, ma il contrario non è vero.

Il tipo di entità, i suoi sottotipi, sottotipi di questi sottotipi, ecc. Formano gerarchia dei tipi di entitàun esempio di ciò è mostrato in Fig. 5,6.

Nella progettazione reale della struttura del database, viene utilizzato un metodo: il cosiddetto modellazione semantica. La modellazione semantica è una modellazione della struttura dei dati, basata sul significato di questi dati. Varie opzioni sono usate come strumento di modellazione semantica. diagrammi entità-relazione(ER - Entità-relazione).

La prima versione del modello entità-relazione è stata proposta nel 1976 da Peter Pin-Sheng Chen. In futuro, molti autori hanno sviluppato le proprie versioni di tali modelli (notazione Martin, notazione IDEF1X, notazione Barker, ecc.). Anche vari softwareche implementano la stessa notazione possono differire nelle loro capacità. In effetti, tutte le varianti dei diagrammi entità-relazione provengono da un'idea: un'immagine è sempre più visiva di una descrizione testuale. Tutti questi diagrammi utilizzano un'immagine grafica delle entità dell'area tematica, delle loro proprietà (attributi) e delle relazioni tra le entità.

Descriveremo lavorare con diagrammi ER vicini alla notazione di Barker, come abbastanza facile capire le idee principali. Questo capitolo è più un'illustrazione dei metodi di modellazione semantica che un'introduzione completa a quest'area.

Concetti per i grafici ER

Definizione 1: Essenzaè una classe di oggetti dello stesso tipo, le cui informazioni dovrebbero essere prese in considerazione nel modello.
Ogni entità deve avere un nome espresso da un nome singolare. Esempi di entità possono essere classi di oggetti come "Fornitore", "Dipendente", "Fattura". Ogni entità nel modello è rappresentata come un rettangolo con il nome:

Figura. 1

Definizione 2: Istanza dell'entità- Questo è un rappresentante specifico di questa entità.
Ad esempio, il rappresentante dell'entità "Dipendente" può essere "Dipendente Ivanov". Le istanze di entità devono essere distinguibili, ad es. Le entità devono avere alcune proprietà uniche per ciascuna istanza di questa entità.

Definizione 3: Attributo entità- Questa è una caratteristica denominata, che è una proprietà dell'entità.
Il nome dell'attributo dovrebbe essere espresso al singolare (possibilmente con aggettivi caratterizzanti). Esempi di attributi dell'entità "Dipendente" possono essere attributi come "Numero del personale", "Cognome", "Nome", "Secondo nome", "Posizione", "Stipendio", ecc. Gli attributi vengono visualizzati nel rettangolo che definisce l'entità:

Figura. 2

Definizione 4: Chiave dell'entità- Questo è un insieme ridondante di attributi, i cui valori nell'aggregato sono univoci per ogni istanza dell'entità. La ridondanza è che la rimozione di qualsiasi attributo dalla chiave viola la sua unicità. Un'entità può avere più chiavi diverse. Gli attributi chiave sono rappresentati nel diagramma sottolineando:

Figura. 3

Definizione 5: Comunicazione- Questa è un'associazione tra due entità. Un'entità può essere associata a un'altra entità o a se stessa.
Le relazioni consentono a un'entità di trovare altre entità ad essa associate. Ad esempio, le relazioni tra entità possono essere espresse dalle seguenti frasi: "I DIPENDENTI possono avere più BAMBINI", "ogni DIPENDENTE deve essere elencato esattamente in un DIPARTIMENTO". Graficamente, la relazione è rappresentata da una linea che collega due entità:

Figura. 4

Ogni connessione ha due estremità e uno o due nomi. Il nome è di solito espresso in una forma verbale indefinita: "have", "appartengono", ecc. Ciascuno degli articoli si riferisce alla sua fine della comunicazione. A volte i nomi non sono scritti a causa della loro ovvietà.

Ogni collegamento può avere una delle seguenti tipi di comunicazione:

Figura. cinque

Tipo di relazione uno a unosignifica che un'istanza della prima entità (a sinistra) è associata a un'istanza della seconda entità (a destra). La relazione uno a uno indica spesso che in realtà abbiamo una sola entità, erroneamente divisa in due.

Tipo di relazione uno a moltisignifica che un'istanza della prima entità (a sinistra) è associata a diverse istanze della seconda entità (a destra). Questo è il tipo di connessione più comunemente usato. Viene chiamata l'entità sinistra (dal lato "uno") genitore, a destra (dal lato "molti") - filiale. Un tipico esempio di tale connessione è mostrato in Fig. 4.

Tipo di relazione molti-a-moltisignifica che ogni istanza della prima entità può essere associata a diverse istanze della seconda entità e ciascuna istanza della seconda entità può essere associata a diverse istanze della prima entità. Il tipo di relazione molti-a-molti è un tipo temporaneo di connessione accettabile nelle prime fasi di sviluppo del modello. In futuro, questo tipo di connessione dovrebbe essere sostituito da due relazioni uno-a-molti creando un'entità intermedia.

Ogni collegamento può avere uno dei due modalità di comunicazione:

Figura. 6

Modalità " può"significa che un'istanza di un'entità può essere associata a una o più istanze di un'altra entità o non essere associata a nessuna istanza.
Modalità " dovrebbero"significa che un'istanza di un'entità deve essere associata ad almeno un'istanza di un'altra entità.
La comunicazione può avere modalità diverse da estremità diverse (come in Fig. 4). La sintassi grafica descritta consente di leggere in modo inequivocabile i diagrammi utilizzando il seguente schema di costruzione della frase:

<Каждый экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯЗИ> <НАИМЕНОВАНИЕ СВЯЗИ> <ТИП СВЯЗИ> <экземпляр СУЩНОСТИ 2>

Ogni collegamento può essere letto da sinistra a destra e da destra a sinistra. La connessione in Fig. 4 legge così:

Da sinistra a destra: "ogni dipendente può avere più figli".
Da sinistra a destra: "Ogni bambino deve appartenere esattamente a un dipendente".

Un esempio di sviluppo di un semplice modello ER

Durante lo sviluppo di modelli ER, dovremmo ottenere le seguenti informazioni sull'area tematica:

Elenco delle entità dell'area tematica.
Elenco di attributi di entità.
Descrizione della relazione tra entità.

I diagrammi ER sono convenienti in quanto il processo di estrazione di entità, attributi e relazioni è iterativo. Dopo aver sviluppato la prima versione approssimativa dei diagrammi, li perfezioniamo interrogando gli esperti del dominio. In questo caso, la documentazione in cui sono registrati i risultati delle conversazioni sono gli stessi diagrammi ER.

Supponiamo che ci troviamo di fronte al compito di sviluppare un sistema informativo per un ordine di alcune società di commercio all'ingrosso. Prima di tutto, dobbiamo studiare l'area tematica e i processi che si verificano in essa. Per fare ciò, intervistiamo i dipendenti dell'azienda, leggiamo la documentazione, studiamo le forme di ordini, fatture, ecc.

Ad esempio, durante una conversazione con un responsabile delle vendite, si è scoperto che lui (il responsabile) ritiene che il sistema progettato debba eseguire le seguenti azioni:

Conservare le informazioni sui clienti.
Stampa fatture per merci rilasciate.
Monitorare la disponibilità delle merci in magazzino.

Selezioniamo tutti i nomi in queste frasi - questi saranno potenziali candidati per entità e attributi e li analizzeremo (metteremo in evidenza termini oscuri con un punto interrogativo):

L'acquirente è un chiaro candidato per l'essenza.
La fattura è un chiaro candidato per l'entità.
Prodotto: un chiaro candidato per l'essenza
(?) Magazzino - in generale, quanti magazzini ha l'azienda? Se diversi, allora questo sarà un candidato per una nuova entità.
(?) La presenza di un prodotto è molto probabilmente un attributo, ma quale attributo di un'entità?

Immediatamente esiste un'ovvia connessione tra le entità: "gli acquirenti possono acquistare molti beni" e "i beni possono essere venduti a molti acquirenti". La prima versione del diagramma è simile alla seguente:

Figura. 7

Ponendo ulteriori domande al gestore, abbiamo scoperto che la società ha diversi magazzini. Inoltre, ogni prodotto può essere immagazzinato in diversi magazzini ed essere venduto da qualsiasi magazzino.

Dove mettere le entità "Invoice" e "Warehouse" e con cosa collegarle? Ci chiediamo come queste entità siano correlate tra loro e alle entità "Acquirente" e "Prodotto"? Gli acquirenti acquistano beni, mentre ricevono fatture in cui vengono inseriti i dati sulla quantità e sul prezzo dei beni acquistati. Ogni acquirente può ricevere diverse fatture. Ogni fattura deve essere emessa per cliente. Ogni fattura deve contenere più prodotti (non ci sono fatture vuote). Ogni prodotto, a sua volta, può essere venduto a più clienti attraverso diverse fatture. Inoltre, ogni fattura deve essere emessa da un magazzino specifico e molte fatture possono essere emesse da qualsiasi magazzino. Pertanto, dopo il chiarimento, il diagramma apparirà come segue:

Figura. 8

È tempo di pensare agli attributi dell'entità. Parlando con i dipendenti dell'azienda, abbiamo scoperto quanto segue:

Ogni acquirente lo è entità legale e ha un nome, indirizzo, coordinate bancarie.
Ogni prodotto ha un nome, un prezzo ed è anche caratterizzato da unità.
Ogni fattura ha un numero univoco, la data dell'estratto conto, un elenco di prodotti con quantità e prezzi, nonché l'importo totale della fattura. La fattura viene emessa da un magazzino specifico e ad un acquirente specifico.
Ogni magazzino ha il suo nome.
Ancora una volta, scriviamo tutti i nomi che saranno potenziali attributi e li analizzeremo:
Persona giuridica è un termine retorico, non lavoriamo con le persone. Non prestiamo attenzione.
Il nome dell'acquirente è una chiara descrizione dell'acquirente.
L'indirizzo è una chiara indicazione dell'acquirente.
Dati bancari: una chiara descrizione dell'acquirente.
Il nome della merce è una caratteristica esplicita della merce.
(?) Prezzo del prodotto - sembra che questa sia una caratteristica del prodotto. Questa funzionalità differisce dal prezzo in fattura?
Unità di misura - una caratteristica esplicita della merce.
Il numero di fattura è una caratteristica univoca chiara della fattura.
La data della fattura è una caratteristica esplicita della fattura.
(?) Elenco di prodotti in fattura - l'elenco non può essere un attributo. Probabilmente, devi selezionare questo elenco come entità separata.
(?) La quantità di merci in fattura è una caratteristica ovvia, ma la caratteristica di cosa? Questa caratteristica non è solo "merce", ma "merce in fattura".
(?) Il prezzo delle merci sulla fattura - ancora una volta, questa non dovrebbe essere solo una descrizione delle merci, ma le caratteristiche delle merci sulla fattura. Ma il prezzo della merce ha già raggiunto livelli più alti - è la stessa cosa?
L'importo della fattura è una chiara caratteristica della fattura. Questa caratteristica non è indipendente. L'importo della fattura è pari alla somma dei costi di tutte le merci incluse nella fattura.
Il nome del magazzino è una caratteristica esplicita del magazzino.

In una conversazione aggiuntiva con il gestore, è stato possibile chiarire vari concetti di prezzi. Si è scoperto che ogni prodotto ha un certo prezzo corrente. Questo è il prezzo al quale il prodotto viene attualmente venduto. Naturalmente, questo prezzo può cambiare nel tempo. Il prezzo dello stesso prodotto in fatture diverse emesse in momenti diversi può essere diverso. Pertanto, ci sono due prezzi: il prezzo della merce sulla fattura e il prezzo corrente della merce.

Con il concetto emergente di "Elenco delle merci sulla fattura", tutto è abbastanza chiaro. Le entità "Fattura" e "Prodotto" sono correlate tra loro da una relazione molti-a-molti. Tale connessione, come abbiamo notato prima, dovrebbe essere suddivisa in due relazioni uno-a-molti. Ciò richiede un'entità aggiuntiva. Questa entità sarà l'entità "Elenco delle merci nella fattura". Il suo collegamento con le entità "Fattura" e "Prodotto" è caratterizzato dalle seguenti frasi: "ogni fattura deve contenere più voci dall'elenco dei prodotti nella fattura", "ogni voce dall'elenco dei prodotti nella fattura deve essere inclusa in un'unica fattura", "ogni articolo può essere incluso in più voci dall'elenco delle merci nella fattura "," ciascuna voce dell'elenco delle merci nella fattura deve essere associata esattamente a un prodotto ". Gli attributi "Quantità di merci in fattura" e "Prezzo di merci in fattura" sono attributi dell'entità "Elenco di merci in fattura".

Faremo lo stesso con la connessione che collega le entità "Magazzino" e "Prodotto". Introduciamo l'entità aggiuntiva "Prodotto disponibile". L'attributo di questa entità sarà "Quantità di merci in magazzino". Pertanto, la merce verrà elencata in qualsiasi magazzino e la sua quantità in ciascun magazzino sarà diversa.

Ora puoi aggiungere tutto questo al diagramma:

Figura. nove

Modelli ER concettuali e fisici

L'esempio sopra di un diagramma ER è un esempio. diagramma concettuale. Ciò significa che il diagramma non tiene conto delle caratteristiche di un determinato DBMS. Usando questo diagramma concettuale, puoi costruire diagramma fisico, che saranno già presi in considerazione come DBMS come tipi e nomi validi di campi e tabelle, vincoli di integrità, ecc. La versione fisica del diagramma mostrato in Fig. 9 può apparire, ad esempio, come segue:

Figura. dieci

In questo diagramma, ogni entità è una tabella del database, ogni attributo diventa una colonna della tabella corrispondente. Richiamiamo l'attenzione sul fatto che in molte tabelle, ad esempio "CUST_DETAIL" e "PROD_IN_SKLAD" corrispondenti alle entità "Record dell'elenco delle fatture" e "Prodotto in magazzino", sono comparsi nuovi attributi che non erano nel modello concettuale: questi sono gli attributi chiave delle tabelle principali , migrataalle tabelle figlio al fine di fornire una relazione tra le tabelle tramite chiavi esterne.

È facile vedere che le tabelle risultanti sono immediatamente in 3NF.

conclusioni

Il vero strumento per modellare i dati non è un metodo formale per normalizzare le relazioni, ma il cosiddetto modellazione semantica.

Varie opzioni sono usate come strumento di modellazione semantica. diagrammi entità-relazione(ER - Entità-relazione).

I diagrammi entità-relazione consentono di utilizzare la notazione grafica visiva per modellare le entità e le loro relazioni.

Distinguere concettualee fisicoGrafici ER. I diagrammi concettuali non tengono conto delle caratteristiche di DBMS specifici. I diagrammi fisici sono costruiti su base concettuale e rappresentano un prototipo di un database specifico. Le entità definite nel diagramma concettuale diventano tabelle, gli attributi diventano colonne di tabelle (ciò tiene conto dei tipi di dati e dei nomi di colonna validi per un dato DBMS), le relazioni sono implementate da migrazioneattributi chiave delle entità principali e creazione di chiavi esterne.

Con la corretta definizione di entità, le tabelle risultanti saranno immediatamente in 3NF. Il vantaggio principale del metodo è che il modello è costruito dal metodo di perfezionamento sequenziale dei diagrammi originali.

Questo capitolo, che illustra i metodi di modellazione ER, non tratta gli aspetti più complessi della creazione di diagrammi, come sottotipi, ruoli, relazioni escluse, relazioni intollerabili, relazioni identificative, ecc.

Modello logico I dati (essenziali) sono una rappresentazione logica indipendente dei dati.

Modello fisico I dati (tabulari) contengono le definizioni di tutti gli oggetti implementati in un database specifico per un DBMS specifico.

I modelli sono la pietra angolare del design. Gli ingegneri devono costruire un modello di auto, elaborare tutti i dettagli prima di metterlo in produzione. Allo stesso modo, gli ingegneri di sistema sviluppano innanzitutto modelli per studiare la logica aziendale e approfondire la comprensione della struttura del database.

Nell'ultima lezione, abbiamo conosciuto le metodologie IDEF0 e DFD che ci consentono di descrivere i processi aziendali che si svolgono nel sistema informativo. Nel modello DFD, abbiamo esaminato un elemento, un data warehouse, che mostra i tipi di informazioni con cui il sistema opera. Tuttavia, questa metodologia non intende descrivere la struttura delle informazioni memorizzate. Per questo sono più adatti vari Entity Relationships (diagrammi di entità), il cui scopo è descrivere la struttura dei dati memorizzati e le relazioni tra di essi. Sono state sviluppate tecniche che consentono di convertire tali dati in una serie di comandi che creeranno gli archivi (tabelle) necessari all'interno del database del sistema informativo.

Modellazione ER

NEL sistemi di informazioneah, i dati sono divisi in categorie o entità separate. Dopotutto, ricordiamo che un database è un insieme di dati strutturati. I dati di vari tipi vengono memorizzati separatamente. Il compito del modello ER è mostrare quali tipi di informazioni sono archiviate nel sistema, quale sia la loro struttura e come sono interconnesse. Il modello ER è costruito sulla base di un'analisi aziendale (diagramma DF costruito). In questo caso, inizialmente, ogni negozio nel diagramma DF diventa un'entità nel diagramma ER. Nel corso di ulteriori analisi, possono essere frantumati in parti componenti. Vale la pena notare che i modelli ER sono più resistenti ai cambiamenti nella struttura aziendale rispetto ai diagrammi DF. I processi aziendali possono cambiare, ma le informazioni necessarie per implementarli rimangono spesso invariate.

I principali vantaggi dei modelli ER:

Formato accurato e comprensibile per la documentazione della struttura delle informazioni.
Consente di specificare i requisiti dei dati e le relazioni tra di essi.
Consente di mostrare visivamente la struttura del repository per facilitare la progettazione del database.
Esistono metodi per mappare i modelli ER da e verso le tabelle del database.
Poni le basi per l'integrazione con altre applicazioni.

I principali tipi di oggetti in un diagramma ER:

Entità: tipo di oggetti, informazioni sui quali verranno archiviati nel database. Ad esempio: dipartimenti, impiegati, merci, fatture.
Attributo: elementi di cui è costituita l'entità. Ad esempio, per l'entità "merci", gli attributi possono essere "nome", "descrizione", "quantità", "prezzo" e altri, a seconda delle esigenze del sistema informativo. A seconda della notazione del diagramma ER, accanto all'attributo, oltre al nome, indicare il tipo e il riempimento obbligatorio. La diapositiva mostra il diagramma ER nella notazione “Ingegneria dell'informazione”, in base al quale viene indicato il nome dell'attributo, il tipo ed è un pianto esterno e / o primario.
Le relazioni mostrano le relazioni tra entità. Ad esempio, un dipendente lavora in un dipartimento, in cui "dipartimento" e "dipartimento" sono entità.

Un'entità è un insieme di oggetti del mondo reale, ognuno dei quali ha le seguenti caratteristiche:

Unico (può essere separato da tutti gli altri in alcun modo)
Gioca un ruolo nel sistema simulato
Può essere descritto da uno o più elementi informativi (Attributo)

Esempio: persone, personale, eventi, ordini, vendite, clienti, fornitori

L'attributo descrive alcune proprietà di un'entità. Un'entità può avere molti attributi, ma vengono selezionati solo quelli importanti per il sistema. Gli attributi sono divisi in Chiavi entità e Descrittori entità. Gli attributi chiave devono identificare in modo univoco le istanze di un'entità. Per ogni attributo, è necessario specificare un dominio (tipo, area tematica).

La diapositiva mostra come entità e attributi sono registrati in varie notazioni di modelli ER. In tutte le notazioni, un'entità è un oggetto di forma rettangolare, nella parte superiore della quale è indicato il nome dell'entità. Gli attributi sono elencati sotto il nome dell'entità.

Diamo un'occhiata più da vicino a quali sono gli attributi chiave. Questo è importante per comprendere i tipi di relazioni tra entità.

Termini di base

Il modello relazionale, se necessario, può essere descritto in un linguaggio matematico, cioè il più preciso di quello inventato dall'uomo. Quelle che seguono sono definizioni non rigorose di alcuni concetti di un modello relazionale.

"Tipo di dati" (tipo, domean - dominio) - un insieme di valori consentiti ("ambito") e operazioni. Per tutti i tipi, ci sono operazioni di confronto e assegnazione. Ai valori non è proibito avere una struttura, come un oggetto.
"Relazione" - molti attributi: nomi univoci con specifica del tipo di dati; più molte "serie di quantità" ("serie") corrispondenti agli attributi. I valori negli insiemi possono essere rappresentati solo da valori unitari corrispondenti ai tipi di attributo, ovvero essere scalari ("1a forma normale").
Una "chiave" è un gruppo di attributi i cui valori in tutti gli insiemi sono relativamente diversi in relazione, ma non un singolo sottogruppo di questi attributi possiede già una tale proprietà (la proprietà "minimalità" di una chiave). In particolare, un gruppo può essere costituito da un singolo attributo. La chiave con rispetto deve essere sempre presente e, se ce ne sono diverse, una deve essere designata come "primaria" (primaria).
Una "chiave esterna" è un gruppo di attributi i cui valori in ciascuna serie di valori di una relazione devono coincidere con i valori di una chiave di forse un'altra relazione. Le chiavi esterne sono opzionali rispetto e vengono proclamate in base alle esigenze di simulazione.
"Operazioni" (operazione) - molte azioni comuni sulle relazioni, risultanti nuovamente nella relazione ("operazioni chiuse"). Utilizzato per ottenere nuove relazioni nelle esigenze della successiva modellazione o durante il recupero dei dati necessari dal database. L'elenco delle operazioni può essere definito in diversi modi; nelle prime frasi del modello sono state fornite otto operazioni (proiezione, connessione, selezione, ecc.), non più un set minimo, come un compromesso tra la mancanza di ridondanza e facilità d'uso.
" Database relazionale" (database relazionale) - un insieme di relazioni.

Il "tipo di dati" è talvolta chiamato "dominio" (dominio), ma a volte solo "dominio" delle quantità è inteso dal "dominio". Un "insieme di quantità" (tupla) in russo è altrimenti chiamato "tupla" o "n-koi".

Per comodità, le relazioni sono spesso rappresentate sotto forma di tabelle, sebbene tale rappresentazione sia illegale (né l'ordine delle caratteristiche né l'ordine delle serie di quantità sono definiti in relazione, a differenza della tabella). In SQL, sulla base del quale Oracle DBMS è costruito, il concetto di "relazione" come strumento di modellazione è sostituito da una semplice "tabella". Un'altra rappresentazione dei dati di relazione può essere un ipercubo, ed è talvolta conveniente ricorrere ad esso nelle discussioni su un database esistente.

Se abbandoniamo la parola definitiva "tracciamento", il termine "database relazionale" può essere tradotto come "database delle relazioni" (più precisamente, "database costruito" attraverso relazioni "; relazioni come strumento, non oggetto di modellistica: altrimenti il \u200b\u200btermine originale sarebbe database delle relazioni). Allo stesso modo, il termine" modello relazionale "può essere tradotto come un" modello di relazioni ", cioè un" sistema di concetti per costruire un modello di dominio sotto forma di un insieme relazioni ". Per una serie di ragioni, comprese quelle storiche e linguistiche, ciò non è stato fatto al momento.

Sono descritte tutte le relazioni di dati. ovviamente e solo valori negli insiemi (in altri approcci alla modellazione, potrebbe essere diverso). Non ci sono dipendenze "implicite" (anche a livello di logica del programma), ad eccezione di quelle formulate dalle variabili di relazione. L'approccio relazionale distingue tra la descrizione dei dati e la logica del software che accompagna l'applicazione (al contrario, ad esempio, dell'approccio oggetto).

La vista sopra di un database relazionale (un insieme di relazioni e operazioni) è tipica per algebra relazionale. Questo non è l'unico punto di vista. Ogni serie di quantità in una variabile di relazione può essere intesa come un'affermazione vera ("predicato"): esiste un tale dipendente con tali e tali proprietà; tale dipartimento e così via. Pertanto, il database relazionale in ogni momento è un insieme di affermazioni vere sull'area tematica, formulate attraverso le relazioni. In effetti, un insieme di istruzioni in relazioni variabili forma un modello di dominio rappresentato da un database. Questa vista di un database relazionale è caratteristica di calcolo relazionale. Entrambe le opinioni sul modello relazionale sono ben studiate e la loro equivalenza espressiva è dimostrata.

Per i termini elencati nella diapositiva precedente, esistono equivalenti informali per facilitare la comprensione e il ricordo del loro significato:

Relazione → Tabella
Tupla → Stringa, registra
Cardinalità → Numero di righe
Attributo → Campo colonna
Grado → Numero di colonne
Chiave primaria → Identificatore
Dominio → Intervallo valido

Campi chiave

Alcuni degli attributi di una relazione sono chiave o chiavi. Esistono diversi tipi di chiavi:

Chiave semplice - è composta da un attributo, composito - di diversi.
Chiave potenziale - Un attributo o un insieme di attributi che possono identificare ciascuna delle tuple di una relazione. Ad esempio, per quanto riguarda l'ufficio passaporti ("Numero passaporto") e ("Nome" e "Data di nascita") - potenziali chiavi che consentono a ciascuna persona di essere identificata in modo univoco.
In ogni relazione può esserci solo una chiave primaria: un attributo o un insieme di valori di attributo di cui identificano in modo univoco ciascun record. Se diversi insiemi di attributi possiedono tali proprietà, uno di questi viene selezionato come primario e tutti gli altri vengono scelti in alternativa.
Chiave esterna - negozi valore chiave primaria di un'altra relazione. Le chiavi esterne vengono utilizzate per comunicare tra le relazioni.

Chiave primaria

Ogni relazione relazionale ha solo 1 chiave primaria, tutte le altre sono alternative.
Il valore di tutti gli attributi della chiave primaria non può essere non definito. Ad esempio, una relazione memorizza informazioni sui residenti in città. La chiave primaria è una chiave composta (NAME, SURNAME, data di nascita). Il sistema informativo è stato installato in Islanda, dove i cognomi non sono utilizzati, il che significa che l'attributo "cognome" per la maggior parte delle tuple sarà vuoto. Nonostante ciò, la chiave primaria composita continuerà a identificare in modo univoco ciascuna delle tuple. Tuttavia, è inaccettabile che i valori di tutti gli attributi della chiave primaria siano vuoti contemporaneamente.
Il valore della chiave primaria non influisce sulla posizione delle tuple nella vista tabella della relazione. Anche se il valore della chiave primaria è un numero (ad esempio, 1,2,3 ...) in generale, ciò non garantisce che le tuple all'interno del database siano memorizzate nello stesso ordine e verranno visualizzate nello stesso ordine. Nel "caso generale", significa che a volte, a causa delle specifiche di un particolare DBMS, le righe possono essere archiviate ordinate per chiave primaria, ma questa è piuttosto un'eccezione. Nel caso di risultati di query in uscita, dobbiamo indicare esplicitamente l'ordine in cui produrre le linee, se questo ordine è importante. I risultati della query "dammi le prime 5 persone" sono imprevedibili a meno che non indichiamo con quali criteri dovrebbero essere "primi".
La chiave primaria non influisce sull'accesso agli attributi tupla. Ad esempio, in relazione all '"ufficio passaporti", insieme al nome e alla data di nascita, viene memorizzato l'indirizzo di registrazione della persona. Possiamo chiedere al database di estrarre tutti gli indirizzi senza conoscere il nome e la data di nascita.

Chiave esterna

Una chiave esterna viene utilizzata per stabilire relazioni tra relazioni. Ad esempio, prendi le due relazioni "Proprietari" (chiave primaria "numero passaporto") e "Immobiliare". Per stabilire chi possiede ciascuno degli oggetti immobiliari, assoceremo queste relazioni al valore dell'attributo "numero passaporto". A differenza della chiave primaria, il valore della chiave esterna può essere indefinito (riga 4 sulla diapositiva) - se non conosciamo il proprietario della proprietà, non lo indichiamo. A differenza della chiave primaria, il valore della chiave esterna può essere ripetuto (lavelli 1.3 sulla diapositiva) - un proprietario può avere diversi oggetti immobiliari. Tuttavia, il fatto che l'attributo "numero passaporto" in relazione a "Immobiliare" sia una chiave esterna alla chiave primaria della relazione "Proprietario" garantisce che il valore dell'attributo "numero pastore" può essere solo valori dalla chiave primaria. Non possiamo indicare il numero di attributo del parroco di una persona che non è ancora in relazione al "Proprietario" (riga 5).

Impostando una chiave esterna, è possibile impostare esplicitamente il comportamento del DBMS se si modifica il valore della chiave primaria o si elimina la tupla. Tuttavia, la regola "solo i valori che si trovano nella chiave primaria o il valore indefinito (NULL)" sono memorizzati nella chiave esterna.

Una chiave esterna tra le relazioni viene in genere impostata durante la progettazione del database. Tuttavia, può essere rimosso in qualsiasi momento o reinstallato se l'aggiunta di questa restrizione non contraddice le proprietà della chiave esterna. La rimozione / installazione di chiavi esterne viene di solito eseguita quando si inseriscono grandi quantità di dati, per accelerare questo processo - il DBMS non può memorizzare dati incoerenti (errati, errati), quindi controlla ogni restrizione quando si inserisce ogni riga.

Modelli ER: comunicazioni

Sui modelli ER, le chiavi esterne vengono visualizzate come collegamenti.

Ogni connessione è caratterizzata da 4 proprietà: forza, potenza, grado e partecipazione dell'entità alla connessione.

Analizzeremo queste caratteristiche.

Coinvolgimento dell'entità nella comunicazione

È designato su comunicazione da una linea trasversale o un cerchio.

La linea trasversale significa obbligatorio (obbligatorio) la partecipazione dell'entità alla comunicazione e il cerchio - opzionale (opzionale).

Nel caso della partecipazione obbligatoria dell'entità a una connessione, il verbo " dovrebbero". Con la partecipazione facoltativa delle entità alla comunicazione, usa il verbo" può".

Nel dipartimento può lavorare diversi dipendenti. Dipendente dovrebbero lavorare in alcuni dipartimenti.

Il grado di comunicazione ( relazione grado) indica il numero di entità associate. Comunicazione binaria ( binario relazione) descrive le associazioni di due entità. Comunicazione ternaria (ternario relazione) ha luogo quando sono collegate tre entità. Collegamento unario (unario relazione) descrive le associazioni all'interno di una singola entità.

Le connessioni binarie più comuni: collegano due entità diverse (“Dipartimento” - “Dipendente”, “Ordine” - “Merci”, “Corso” - “Lezioni frontali”, “Gruppo” - “Studenti”). Meno comuni, ma ancora spesso utilizzati sono i legami unari. Con il loro aiuto, di solito impostano il rapporto di nidificazione su oggetti dello stesso tipo (la relazione "Dettagli" - possiamo indicare quale parte è il componente dato, la relazione "Dipendenti" - possiamo indicare quale dei dipendenti è il capo per questo).

La potenza di comunicazione indica quante istanze di un'entità sono associate a istanze di un'altra entità.

Il potere può essere:

uno a uno (1: 1) - nel gruppo di studenti c'è un anziano;
uno a molti (1: N) - molti dipendenti lavorano in un reparto;
molti-a-molti (M: N) - un acquirente ha acquistato molti beni, molti acquirenti hanno acquistato beni.

Forza della comunicazione: relazione forte (relazione di identificazione)

Un'entità figlio non può esistere senza un'entità padre. (Non c'è risposta senza una domanda; non c'è prodotto nel carrello dell'utente se il carrello stesso non esiste)

In questo caso, la chiave primaria migra dal genitore al figlio, dove diventa parte della chiave primaria.

In un diagramma, una forte connessione è mostrata da una linea inestricabile tra entità.

Forza di comunicazione: relazione non identificativa

Le entità padre e figlio sono correlate, ma un'entità figlio può essere creata in precedenza. (La merce appartiene all'ordine, ma la merce può essere disponibile prima della creazione dell'ordine).

La chiave primaria migra dal genitore al figlio e non fa parte della chiave primaria (diventa solo una chiave esterna).

Nel diagramma, una forte connessione è mostrata da una linea tratteggiata tra le entità.

Comunicazione ricorsiva (comunicazione unaria)

Più spesso usato per costruire gerarchie.

Il fornitore può collaborare con ZERO o PIÙ clienti (id_Customer).

Il cliente DEVE lavorare con un fornitore (id_Sup).

Ma il fornitore e il cliente, indipendentemente dal fatto che l'organizzazione sia una società, sono dello stesso tipo e pertanto vengono archiviati sotto un aspetto.

Rapporto molti-a-molti.

Esempio: i fornitori possono fornire molti tipi di merci. Fornitori diversi possono fornire gli stessi tipi di merci.

La relazione molti-a-molti è accettabile dal punto di vista del modello ER, ma non può essere riflessa direttamente in termini di algebra relazionale.

L'ambiguità della comunicazione è risolta dall'introduzione di entità di transizione, come mostrato nella diapositiva.

Modelli ER e realtà

Uno sguardo ravvicinato alle relazioni one-to-one rivela quasi sempre che A e B sono in realtà diversi sottoinsiemi dello stesso oggetto o diversi punti di vista su di esso, con solo nomi diversi e relazioni e attributi descritti in modo diverso.

Immagina che A sia il fornitore, B sia il prodotto.

Obbligatoria obbligatorio.Per l'esempio mostrato nella diapositiva, questa relazione indica che ciascun fornitore dovrebbero fornire solo uno unico insieme di merci (fattura). Dal punto di vista della teoria, qui va tutto bene. In pratica, ciò non è consentito: nessuno cercherà un nuovo fornitore se il fornitore che hai verificato può fornire diverse gamme di prodotti. E ora per quanto riguarda le emozioni, il gatto sperimenterà l'operatore quando tenta di inserire dati su un nuovo fornitore. Non sarà in grado di inserire dati in nessuna delle tabelle. Quindi ti verranno inviati tutti i bagagli del vocabolario indecente.

Opzionale obbligatorio. Un esempio di comunicazione è mostrato sulla diapositiva. Come vediamo, l'operatore sta facendo bene: può inserire i dati. L'azienda ha ancora un problema: deve cercare un nuovo fornitore, anche se il fornitore che hai verificato può fornire diverse gamme di prodotti. Le imprese hanno bisogno di problemi? Non. Deve funzionare. Come soddisfare un'azienda? La risposta è semplice Quando si progetta un database, è necessario pensare alla normalizzazione. Se il fornitore è un'entità, utilizzare relazioni come opzionale-obbligatorio (obbligatorio-opzionale) o opzionale-opzionale. Anche se il più delle volte le comunicazioni one-to-one sono un errore.

Opzionale-optional. Come vediamo, l'operatore sta di nuovo bene, ma l'azienda sta riscontrando nuovamente un problema. Riassumendo una relazione uno a uno. Se le entità partecipano alla comunicazione come: - obbligatorio-obbligatorio, tale comunicazione non ha diritto alla vita; - opzionale-obbligatorio (obbligatorio-opzionale) o opzionale-opzionale, quindi il supporto aziendale è problematico.

La relazione uno-a-molti obbligatorio-obbligatorio è un costrutto abbastanza forte, suggerendo che una voce dell'entità B non può essere creata senza creare contemporaneamente almeno una voce dell'entità A. Molto spesso, si tratta di una relazione errata.

Il vincolo uno-a-molti obbligatorio-opzionale è la forma di comunicazione più comune. Presuppone che ogni singola occorrenza dell'entità A possa esistere solo nel contesto di una (e unica) occorrenza dell'entità B. A sua volta, le occorrenze di B possono esistere sia in connessione con le occorrenze di A e senza di essa.

Relazione uno-a-molti opzionale-opzionale - Sia A che B possono esistere senza una relazione tra loro.

In termini di diapositiva precedente, questi diagrammi possono essere illustrati dai seguenti esempi.

Rapporti uno-a-molti. Queste relazioni suggeriscono che un record in una tabella può essere logicamente collegato a più record in un'altra tabella.

Obbligatoria obbligatorio.Per l'esempio mostrato nella diapositiva, questa relazione significa che ogni fornitore (A) deve fornire uno o più gruppi di prodotti (B). Dal punto di vista della teoria, qui va tutto bene. Tuttavia, in pratica, l'operatore non sarà in grado di inserire dati in nessuna delle tabelle, poiché i record sono necessari allo stesso tempo entra in entrambe le tabelle.

Opzionale obbligatorio.In questo caso, l'operatore ora sta bene: può inserire i dati, ma l'azienda potrebbe avere problemi. Il fatto è che la relazione facoltativa-obbligatoria presuppone che il fornitore (A) dovrebbero consegnare una o più serie di merci (B), mentre B può appartengono al fornitore. In altre parole, le merci possono esistere senza un fornitore, mentre il fornitore ha merci. Coloro. affari probabilmente incontrollati: chi ha consegnato la merce? A chi chiedere? Le imprese hanno bisogno di problemi? Non. Deve realizzare un profitto. In questo caso, è preferibile utilizzare un obbligo facoltativo: il fornitore può fornire uno o più gruppi di merci, mentre i beni devono appartenere al fornitore. In altre parole, i beni hanno un fornitore e i dati sui fornitori che una volta consegnati i beni verranno salvati. E le pecore sono al sicuro ei lupi sono pieni: l'operatore può inserire i dati e l'uomo d'affari è al centro delle cose.

Opzionale-optional.Come vediamo, l'operatore sta di nuovo bene, ma l'azienda ha un problema di mancanza di controllo: un prodotto può esistere senza un fornitore e un fornitore senza un prodotto.
Riassumendo una relazione uno-a-molti. Se le entità partecipano a una relazione come: - obbligatorio-obbligatorio, tale relazione non ha il diritto alla vita, poiché è impossibile inserire record simultaneamente in entrambe le tabelle; - opzionale-opzionale, quindi il supporto aziendale è problematico.

Le relazioni molti-a-molti sono accettabili nei diagrammi ER, ma quando convertite in una vista tabella, tale relazione viene sostituita da un'entità intermedia.

Molti-molti-obbligatori-obbligatori - una simile costruzione spesso ha luogo all'inizio della fase di analisi e significa comunicazione - o non è completamente compresa e richiede un'autorizzazione aggiuntiva, o riflette una semplice relazione collettiva - un elenco bidirezionale.

Molti-a-obbligatori-facoltativi - usati raramente. Tali relazioni sono sempre soggette a ulteriori elaborazioni.

Comunicazione ricorsiva. Queste relazioni suggeriscono che le voci della tabella possono essere logicamente correlate.

Uno-a-uno opzionale-opzionale. Per l'esempio mostrato nella diapositiva, questa relazione significa che qualsiasi uomo (donna) può essere sposato con una donna (uomo). Questa connessione è comoda per tracciare la storia della coppia: per la prima volta, ripetutamente, ... In altre parole, un tipo alternativo di connessione.

Uno-a-molti opzionale-opzionale. Un esempio di comunicazione è mostrato sulla diapositiva. Questa è una gerarchia classica (struttura ad albero). La relazione mostrata nella diapositiva può essere interpretata, ad esempio, come segue: qualsiasi dipendente può essere subordinato a un solo manager, mentre un manager può guidare uno o più dipendenti.

Opzionale-opzionale M: \u200b\u200bM Un esempio di comunicazione è mostrato nella diapositiva 3. Questa è una struttura di rete.

Elenco di controllo della domanda dell'entità

Il nome dell'entità riflette l'essenza dell'oggetto dato?
Ci sono incroci con altre entità?
Ci sono almeno due attributi?
Attributi totali non più di otto?
Ci sono sinonimi / omonimi per questa entità?
L'entità è completamente definita?
Esiste un identificatore univoco?
C'è almeno una connessione?
Esiste almeno una funzione per creare, cercare, aggiornare, eliminare, archiviare e utilizzare un valore di entità?
Viene mantenuta una cronologia delle modifiche?
Esiste il rispetto dei principi di normalizzazione dei dati?
Esiste la stessa entità in un altro sistema applicativo, possibilmente con un nome diverso?
L'entità ha un significato troppo generale?
Il livello di generalizzazione incorporato in esso è sufficiente?

Elenco di controllo delle domande degli attributi:

Il nome dell'attributo è singolare e riflette l'essenza della proprietà indicata dall'attributo?
Il nome dell'attributo include il nome dell'entità (questo non dovrebbe essere)?
Un attributo ha un solo valore alla volta?
Mancano valori (o gruppi) duplicati?
Sono descritti il \u200b\u200bformato, la lunghezza, i valori accettabili, l'algoritmo di recupero, ecc.?
Questo attributo potrebbe essere un'entità mancante che sarebbe utile per un altro sistema applicativo (esistente o implicito)?
Potrebbe essere un collegamento perso?
Esiste da qualche parte un riferimento all'attributo come "caratteristica del progetto", che dovrebbe scomparire al passaggio al livello dell'applicazione?
È necessaria una cronologia delle modifiche?
Il suo valore dipende solo da questa entità?
Se è richiesto un valore di attributo, è sempre noto?
È necessario creare un dominio per questo e attributi simili?
Il suo valore dipende solo da una parte dell'identificatore univoco?
Il suo valore dipende dai valori di alcuni attributi non inclusi nell'identificatore univoco?

Il modello entità - attributo - relazione è stato proposto da Peter Pin-Shen Chenov nel 1976. La maggior parte degli approcci moderni alla progettazione di basi di dati (principalmente relazionali) si basano sull'uso di varietà del modello ER. La modellizzazione del dominio si basa sull'uso di grafici che includono un numero limitato di componenti eterogenei. A causa della chiara presentazione di schemi concettuali di database, i modelli ER sono ampiamente utilizzati nei sistemi CASE che supportano la progettazione automatizzata di database relazionali.

I concetti di base del modello ER sono l'essenza, l'attributo e la relazione.

Essenza - questo è un oggetto reale o immaginario, informazioni su quali sono di interesse. Nei diagrammi del modello ER, un'entità è rappresentata come un rettangolo contenente il nome dell'entità. In questo caso, il nome dell'entità è il nome del tipo e non un oggetto specifico, un'istanza di questo tipo. Ogni istanza di un'entità deve essere distinguibile da qualsiasi altra istanza della stessa entità.

Una relazione è un'associazione rappresentata graficamente stabilita tra due entità. Questa associazione è sempre binaria e può esistere tra due entità diverse o tra un'entità e se stessa (una relazione ricorsiva). In ogni connessione, si distinguono due estremità (in accordo con una coppia di entità connesse), ognuna delle quali indica il nome della fine della connessione, il grado della fine della connessione (quante istanze dell'entità data sono collegate), il legame della connessione (ovvero, se una qualsiasi istanza di questa entità dovesse essere coinvolta in questa connessione).

La connessione viene presentata sotto forma di una linea che collega due entità o conduce da un'entità a essa stessa. Allo stesso tempo, nel punto in cui la connessione con l'entità è "ancorata", viene utilizzata una voce a tre punti nel rettangolo dell'entità se è possibile utilizzare molte istanze dell'entità nella relazione e una voce a punto singolo se solo un'istanza dell'entità può partecipare alla relazione. L'estremità richiesta della connessione è indicata da una linea continua e quella opzionale da una linea tratteggiata.

Come un'entità, una relazione è un concetto tipico, tutte le istanze di entrambe le coppie di entità collegate obbediscono alle regole di associazione. In fig. 1. Viene fornito un esempio dell'immagine delle entità e della loro relazione. Questo diagramma può essere interpretato come segue:

Ogni STUDENTE studia in un solo GRUPPO;

Ogni GRUPPO è composto da uno o più STUDENTI.

Figura. 1. La relazione tra entità

In fig. 2 raffigura l'essenza di MAN con una connessione ricorsiva che la collega a se stessa. Un'interpretazione orale concisa del diagramma è la seguente:

Ogni UOMO è il figlio di un solo UOMO;

Ogni MAN può essere il padre di una o più PERSONE ("MANS").

Figura. 2. Comunicazione ricorsiva

Un attributo di un'entità è qualsiasi dettaglio che serve a chiarire, identificare, classificare, caratterizzare numericamente o esprimere lo stato di un'entità. I nomi degli attributi sono inseriti in un rettangolo raffigurante l'entità, sotto il nome dell'entità e sono rappresentati in lettere minuscole:

Un identificatore univoco per un'entità è un attributo, una combinazione di attributi, una combinazione di relazioni o una combinazione di relazioni e attributi che distingue in modo univoco qualsiasi istanza di un'entità da altre istanze di un'entità dello stesso tipo. Questi sono i concetti più importanti di un modello di dati ER. Gli elementi più complessi del modello includono quanto segue.

Rapporti molti-a-molti. A volte è necessario vincolare le entità in modo tale che diverse istanze dell'entità possano essere presenti ad entrambe le estremità della connessione (ad esempio, tutti i membri di una cooperativa possiedono congiuntamente la proprietà della cooperativa). Per fare questo, viene introdotta una sorta di relazione molti-con-molti.

Gradi di comunicazione specificati. A volte è utile determinare il numero possibile di istanze di entità coinvolte in una determinata relazione (ad esempio, un dipendente è autorizzato a partecipare a non più di tre progetti alla volta). Per esprimere questa restrizione semantica, è consentito indicare alla fine della connessione il suo grado massimo o obbligatorio.

Cancellazione a cascata di istanze di entità. Alcune relazioni sono così forti (ovviamente, nel caso di una relazione uno-a-molti) che quando si elimina un'istanza di riferimento di un'entità (corrispondente alla fine di una connessione), è necessario eliminare tutte le istanze di un'entità che corrispondono alla fine di una relazione molte. Il requisito corrispondente di "eliminazione a cascata" può essere formulato quando si definisce un'entità.

domini Come per il modello di dati relazionali, può essere utile definire un insieme potenzialmente valido di valori di attributo di entità (dominio).

Questi e altri elementi più complessi del modello di dati entità - relazione lo rendono più potente, ma allo stesso tempo ne complicano l'uso. Naturalmente, con il reale utilizzo di diagrammi ER per la progettazione di database, è necessario acquisire familiarità con tutte le funzionalità.

Molto spesso, in pratica, la modellazione ER viene utilizzata nella prima fase della progettazione del database. Il suo risultato, di regola, è un modello concettuale dell'area tematica, espresso in termini di modello ER.

Passando alla fase successiva - la modellazione dello schema del database - lo sviluppatore affronta il problema di esprimere il modello concettuale del dominio soggetto in termini di modello di dati applicato (ad esempio, relazionale). Esistono tre approcci per risolvere questo problema.

Primo approccio consiste nel convertire manualmente un modello concettuale di un dominio soggetto in uno schema di database, eseguito secondo tecniche in cui tutte le fasi di tale trasformazione sono chiaramente indicate.

Nel secondo approccio viene implementata una compilazione automatizzata del modello concettuale dell'area tematica in uno schema di database (il più delle volte relazionale). Sono noti due tipi di approccio:

un approccio basato sulla rappresentazione esplicita del modello concettuale dell'area tematica come informazioni di fonte per la compilazione;

approccio focalizzato sulla costruzione di sistemi di progettazione integrata con la creazione automatizzata di un modello concettuale dell'area tematica sulla base di interviste con esperti dell'area tematica.

In entrambi i casi, il risultato è uno schema di database relazionale nella terza forma normale.

Finalmente, terzo approccio -questo è un lavoro diretto con il database nel modello semantico, ad es. applicazione di DBMS basati su modelli di dati semantici. In questo caso, vengono nuovamente considerate due opzioni.

La prima opzione è fornire interfaccia utente basato su un modello di dati semantici con mappatura automatica delle strutture in un modello di dati relazionali (questo è un compito di circa lo stesso livello di complessità della compilazione automatica di un modello concettuale di un dominio soggetto in uno schema di database).

La seconda opzione è un'implementazione DBMS diretta basata su una sorta di modello di dati semantici.

Più vicini alla seconda opzione sono i moderni DBMS orientati agli oggetti i cui modelli di dati sono simili per molti aspetti simili ai modelli semantici (anche se in alcuni aspetti sono più potenti e in alcuni sono più deboli). Sebbene in generale si possa dire che questo approccio non è ancora andato oltre la ricerca e i progetti sperimentali.

Attualmente sul mercato software Sono comparsi molti pacchetti universali (non legati a particolari DBMS) di progettazione assistita da computer del database, che consentono la modellazione concettuale dell'area tematica. Quasi tutti i sistemi di questo tipo si basano su una o un'altra interpretazione del modello ER. Tali sistemi sono l'implementazione del secondo degli approcci di cui sopra. Uno dei prodotti software più popolari in questo settore è ERwin Platinum.

Modelli di dati

Il modo in cui entità, attributi e relazioni si associano alle strutture di dati è determinato dal modello di dati. Esistono 4 modelli di dati principali: elenchi, database relazionali, strutture gerarchiche e di rete. Consideriamoli in modo più dettagliato.

Il tipo più semplice è un elenco: una struttura di dati in una sequenza lineare.

Le strutture gerarchiche degli alberi sono ampiamente utilizzate nell'attività umana quotidiana. I modelli di dati gerarchici si basano sull'uso di forme grafiche e tabulari di rappresentazione dei dati. Nel diagramma grafico dello schema del database, il vertice del grafico viene utilizzato per interpretare i tipi di entità e gli archi per interpretare i tipi di relazioni tra i tipi di entità. Quando implementati, i vertici sono rappresentati da tabelle che descrivono istanze di entità del tipo corrispondente. In fig. La Figura 3 mostra un esempio di una struttura ad albero gerarchica di un database.

Figura. 3. La struttura ad albero gerarchica del database

Le principali limitazioni interne di un modello di dati gerarchico sono le seguenti:

- tutti i tipi di connessioni devono essere funzionali, ad es. 1: 1, 1: M, M: 1;

- la struttura delle relazioni dovrebbe essere simile ad un albero.

Il risultato di queste restrizioni è una serie di caratteristiche del processo di strutturazione dei dati in un modello gerarchico.

Struttura ad albero, o legna, - è un grafico non indirizzato connesso che non contiene cicli. Di solito, quando si lavora con un albero, viene selezionato un vertice specifico, che viene definito come radice albero ed è considerato soprattutto - non un bordo arriva in questo picco. In questo caso, l'albero si orienta. L'orientamento è solitamente determinato dalla radice.

L'albero della radice come grafico diretto può essere definito come segue:

- esiste un singolo vertice speciale chiamato radice, in cui non entra un singolo bordo;

- in tutti gli altri vertici entra solo un bordo ed emana un numero arbitrario di bordi;

- nessun ciclo.

La struttura gerarchica ad albero, orientata dalla radice, soddisfa le seguenti condizioni:

- la gerarchia inizia sempre dal nodo principale;

- al primo livello della gerarchia, è possibile individuare solo il nodo principale;

- ai livelli inferiori sono generato da nodi (dipendenti);

- ogni nodo generato situato al livello L , associato solo a uno direttamente fonte un nodo (direttamente il nodo genitore) situato al livello più alto (L - 1) della gerarchia dell'albero;

- ogni nodo di origine può avere uno o più nodi generati direttamente, chiamati piace;

- l'accesso a ciascun nodo generato viene eseguito attraverso il suo nodo sorgente direttamente;

- esiste un singolo percorso di accesso gerarchico al nodo a partire dalla radice dell'albero (Fig. 4).

Figura. 4. Percorso di accesso al nodo gerarchico

In altre parole, un modello gerarchico di rappresentazione della conoscenza (o albero) è una struttura di dati in cui ciascun nodo ha un solo "genitore", ovvero il nodo dominante (ad eccezione del nodo più in alto) e un numero illimitato di "discendenti", ad es. nodi su cui domina questo nodo.

I modelli di dati di rete si basano anche sull'uso di una rappresentazione grafica dei dati. I vertici del grafico vengono utilizzati per interpretare i tipi di entità e gli archi, i tipi di relazioni. Modello di rete rappresentazioni della conoscenza - una struttura di dati in cui ogni oggetto, contrariamente alla rappresentazione gerarchica, può avere più di un nodo dominante (Fig. 5).

Figura. cinque. Struttura della rete

Negli anni '70, iniziarono a condurre attivamente studi teorici. modello di dati relazionali. Con l'avvento dei personal computer, i modelli relazionali hanno iniziato a dominare il mercato dei sistemi di informazione. Rappresentazione della conoscenza relazionale- Presentazione della conoscenza sotto forma di relazioni.

Secondo il modello di dati relazionali, i dati sono presentati come un insieme di tabelle su cui è possibile eseguire operazioni formulate in termini algebra relazionale o calcolo relazionale.

Progettazione logica

Nella metodologia di progettazione del database proposta, l'intero processo di sviluppo è suddiviso in tre fasi principali: progettazione concettuale, logica e fisica. Progettazione di database logici - Questo è il processo di costruzione di un modello di informazione generale di un'azienda sulla base di singoli modelli di dati utente, che è indipendente dalle caratteristiche del DBMS effettivo e da altre condizioni fisiche.

Nella fase precedente, abbiamo ottenuto una serie di modelli di dati concettuali locali che riflettono la visione dell'utente sull'ambiente tematico. Tuttavia, questi modelli possono contenere alcune strutture di dati la cui implementazione in tipi convenzionali di DBMS sarà difficile. In questa fase, tali strutture di dati vengono convertite in un modulo che non causerà difficoltà quando vengono implementate nell'ambiente di DBMS esistenti. Potrebbe seguire un'osservazione che queste azioni non fanno parte della progettazione logica dei database. Tuttavia, la procedura proposta obbliga lo sviluppatore a considerare più attentamente il significato di ciascun elemento di dati, il che influenza positivamente l'accuratezza della visualizzazione delle caratteristiche di una particolare impresa nel modello. In questa fase, vengono eseguite le seguenti azioni:

1. Rimozione delle relazioni di tipo M:N.

2. Rimozione di relazioni complesse.

3. Rimozione delle relazioni ricorsive.

4. Rimozione delle relazioni con gli attributi.

5. Rimozione di più attributi.

6. Ricontrollo delle relazioni di tipo 1: 1.

7. Rimozione dei collegamenti in eccesso.

1. Rimozione di obbligazioni di tipo M: N.Se il modello concettuale contiene relazioni simili M:N ("Many-to-many"), quindi dovrebbero essere eliminati definendo qualche entità intermedia. Tipo di relazione M:N sostituito da due legami di tipo 1: Mstabilito con l'entità appena creata.

Ad esempio, considerare quanto segue M:N comunicazione: il giornale stampa annunci per oggetti in affitto (Fig. 6)

Figura. 6. M: N comunicazione

Per eliminare questa relazione, definiamo l'entità intermedia AD e creiamo due nuove relazioni di tipo 1: M. Di conseguenza, il tipo M:N sarà sostituito da due legami (Fig. 7).

Figura. 7. Relazioni di tipo 1: M

2. Rimozione di relazioni complesse.Complesso è la connessione esistente tra tre o più tipi di entità. Se nel modello concettuale è presente una relazione complessa, dovrebbe essere eliminata con un'entità intermedia. Un legame complesso è sostituito dal numero richiesto di legami binari di tipo 1: Mimpostato con un'entità appena creata. Ad esempio, la tripla connessione "In affitto" (rappresentata da un rombo) riflette la relazione esistente tra il dipendente dell'azienda che effettua il contratto di locazione, il terreno e l'inquilino (Fig. 8).

Figura. 8. Connessione complessa

Questa relazione complessa può essere semplificata introducendo una nuova entità e definendo relazioni binarie tra essa e ciascuna delle entità originali della connessione complessa.

Nel nostro esempio, la relazione "In affitto" può essere eliminata introducendo una nuova entità debole denominata Accordo. L'entità appena creata verrà associata alle entità originali con tre nuovi legami binari (Fig. 9).

Figura. 9. Semplifica comunicazioni complesse

3. Rimozione delle relazioni ricorsive.Ricorsive sono quelle relazioni in cui un'entità di un certo tipo interagisce con se stessa. Se il modello concettuale contiene relazioni ricorsive, dovrebbero essere eliminate definendo un'entità intermedia. Ad esempio, per visualizzare una situazione in cui uno dei dipendenti guida un gruppo di altri dipendenti, è possibile stabilire una relazione ricorsiva uno-a-molti (1: M).

4. Rimozione delle relazioni con gli attributi.Se nel modello concettuale ci sono relazioni che hanno i loro attributi, devono essere trasformate creando una nuova entità. Ad esempio, prendere in considerazione una situazione in cui si desidera registrare il numero di ore lavorative lavorate dal personale temporaneo di ciascuno dei dipartimenti dell'azienda. Il link "Lavori in" ha un attributo chiamato "Ore lavorate". Trasformiamo la relazione "Lavori in" in un'entità con il nome "Distribuzione per dipartimento", a cui assegniamo l'attributo "Ore lavorate", quindi creiamo due nuove relazioni di tipo 1: M.

5. Rimozione di più attributi.Gli attributi multipli sono attributi che possono avere più valori contemporaneamente per la stessa istanza dell'entità. Se nel modello concettuale è presente un attributo multiplo, dovrebbe essere trasformato definendo una nuova entità. Ad esempio, per riflettere la situazione in cui lo stesso ramo dell'azienda ha diversi numeri di telefono, nel modello concettuale è stato definito un attributo multiplo " Numero di telefono", Relativo all'essenza di" Filiale dell'azienda ". Questo attributo multiplo dovrebbe essere rimosso definendo una nuova entità "Telefono" che ha un singolo attributo semplice "Numero di telefono" e creando una nuova relazione di tipo 1.

6. Ricontrollo delle relazioni di tipo1:1. Nel processo di definizione delle entità, è possibile creare due entità diverse che rappresentano effettivamente lo stesso oggetto nel dominio dell'applicazione. Ad esempio, è possibile creare due entità "Dipartimento" e "Dipartimento", che rappresentano effettivamente lo stesso tipo di oggetto. In altre parole, il nome "Dipartimento" è sinonimo del nome "Dipartimento". In questo caso, dovresti combinare queste due entità in una. Se le chiavi primarie delle entità da unire sono diverse, selezionarne una come principale e specificare l'altra come chiave alternativa.

7. Rimozione dei collegamenti in eccesso.Una connessione è ridondante se le stesse informazioni possono essere ottenute non solo attraverso di essa, ma anche tramite un'altra connessione. Bisogna sempre cercare di creare modelli di dati minimi e, quindi, se la comunicazione ridondante non è ovviamente necessaria, dovrebbe essere rimossa. Stabilire che esiste più di una connessione tra due entità è abbastanza semplice. Tuttavia, non ne consegue ancora che una delle due relazioni sia necessariamente ridondante, poiché entrambe possono rappresentare associazioni diverse che esistono effettivamente nell'organizzazione.

Nell'eliminazione della ridondanza di accesso, il tempismo è importante. Ad esempio, si consideri una situazione in cui è necessario modellare le relazioni tra le entità "Uomo", "Donna" e "Bambino". Ovviamente, tra le entità "Uomo" e "Bambino" ci sono due modi di accesso: uno attraverso la comunicazione diretta “ È un padre ”e l'altro attraverso le connessioni “ Sposato con "e" È una madre ". A prima vista, sembra che la connessione “ Is the father ”è ridondante. Tuttavia, questa affermazione può rivelarsi errata per due motivi. In primo luogo, un padre può avere figli da un precedente matrimonio e modelliamo solo il matrimonio attuale di un padre (attraverso una relazione 1: 1). In secondo luogo, il padre e la madre potrebbero non essere affatto sposati, oppure il padre potrebbe essere sposato con una donna che non è la madre del bambino (o la madre potrebbe essere sposata con un uomo che non è il padre del bambino). Pertanto, tutte le relazioni esistenti non possono essere modellate senza utilizzare una relazione come "È un padre" (Fig. 10).

Figura. 10. Il rapporto tra le entità "Uomo", "Donna", "Bambino"

Informazioni simili