PROGETTAZIONE LOGICA. Prof. Ing. Alfredo GARRO 1/6. Artista. Cantante. DataDiNascita. Codice. Nazionalità

Documenti analoghi
Progettazione di Basi di Dati

Il modello Entità/Relazioni (ER)

Modello Entità-Relazione

La progettazione logica Traduzione dal modello Entità-Associazione al modello relazionale Anno accademico 2008/2009

TRADUZIONE DI SCHEMI

INFORMATICA PER L IMPRESA (Docente Prof. Alfredo Garro)

GESTIONE ABBONAMENTI RIVISTE

GESTIONE MAGAZZINO 1

LA PROGETTAZIONE CONCETTUALE

Generalizzazione. Docente : Alfredo Cuzzocrea Tel. : Informatica

Esame di Basi di Dati, SOLUZIONE APPELLO 09/06/2009

Il modello logico dei dati

GESTIONE VOTI SCOLASTICI

INFORMATICA PER L IMPRESA (Docente Prof. Alfredo Garro) ESERCIZIO 3

Gerarchia di Generalizzazione. Esempio. Rappresentazione grafica. Cap. 4 - Modello E/R avanzato: Gerarchie di Generalizzazione/ specializzazione

Traduzione ER - relazionale

Il sistema informativo deve essere di tipo centralizzato e accessibile mediante un computer server installato nella rete locale dell albergo.

Basi di dati. Progettazione di basi di dati: Metodologie e modelli

Modello Entità-Relazione (E-R)

I database. Introduzione alla teoria delle basi di dati

LE BASI DI DATI. Seconda parte La progettazione di database Relazionali SCHEMA LOGICO - Ristrutturazione dello schema concettuale

Compito Sistemi Informativi LA. Tempo concesso : 90 minuti 22 Giugno 04 Nome: Cognome: Matricola:

Compito Sistemi Informativi LA. Tempo concesso : 90 minuti 28 Giugno 05 Nome: Cognome: Matricola: Esercizio 1

Informatica Industriale Modello funzionale: Informazione Modello Entità-Relazione

Progettazione logica relazionale (1/2) Progettazione logica. Progettazione logica relazionale (2/2) Introduzione. Progettazione logica

Corso di Basi di Dati

Basi di dati: appello 28/02/06

GESTIONE MAGAZZINO 2

IL MODELLO ENTITA - RELAZIONE

Progettazione logica

Strategie top-down. Primitive di trasformazione top-down. Primitive di trasformazione top-down

RELAZIONI E BASI DI DATI

Concettuale. Giuseppe Amato

Esprimere in algebra (ottimizzata), calcolo relazionale la seguente query:

Ciclo di vita di un sistema informativo

Progettazione concettuale

Corso di Basi di Dati A.A. 2014/2015

BASI DI DATI. Titolo Prof. Cognome Nome Indirizzo Numero Telefono

Database per la gestione delle ferrovie dello stato. I treni gestiti sono identificati da un numero. Su ciascun treno sono specificate le classi per

Un esempio di progettazione concettuale

Metodologie e modelli di progetto

a.a. 2012/13 12 Novembre 2012 Preparazione al Test in itinere, Compito A 1. Modellare tramite uno schema entità- relazione la seguente base di dati:

Dichiarazione degli schemi in SQL DDL 1

Basi di Dati e Sistemi Informativi. Raffinamento dello schema e Normalizzazione nei database relazionali

Atzeni, Ceri, Paraboschi, Torlone Basi di dati McGraw -Hill, Progettazione logica. Dati di ingresso e uscita

1. Schema concettuale della base di dati Lo schema concettuale (o statico) è uno dei due schemi del progetto concettuale di un sistema informativo.

Requisiti della base di dati. Schema concettuale

Considerate lo schema ER in figura: lo schema rappresenta varie proprietà di uomini e donne. Copyright The McGraw-Hill Companies, srl

Gestione e Analisi dei Dati. Lezione 4 Relazioni multi tabella Relazioni uno-a-uno, uno-a-molti, molti-a-molti

Atzeni, Ceri, Paraboschi, Torlone Basi di dati McGraw-Hill, Progettazione concettuale

Atzeni, Ceri, Paraboschi, Torlone Basi di dati McGraw-Hill, Progettazione logica. Dati di ingresso e uscita

Basi di Dati. Laboratorio Ing. G. Laboccetta Dott.ssa. V. Policicchio. Corso di Laurea in Informatica. a.a

Il linguaggio SQL: DDL di base

Database. Cos è un database? Intro Tipi di entità Mapping ER/EER à Relazionale

Basi di Dati Relazionali

Progettazione del Software

Traduzione dello schema E-R in modello logico relazionale

Compito Sistemi Informativi LA. Tempo concesso : 90 minuti 26 Giugno 07 Nome: Cognome: Matricola: Esercizio 1

Basi di Dati Corso di Laura in Informatica Umanistica

Esame di Stato Istituto Tecnico Industriale Soluzione della Seconda Prova Indirizzo: INFORMATICA Tema: INFORMATICA Anno Scolastico:

GESTIONE TRASPORTI PROVINCIALI

Informatica. Dipartimento di Economia. Ing. Cristiano Gregnanin. 20 ottobre Corso di laurea in Economia

Compito Sistemi Informativi LA. Tempo concesso : 90 minuti 27 Marzo 07 Nome: Cognome: Matricola:

REGIONE BASILICATA UFFICIO S. I. R. S.

Esercitazione 2: Progettazione Concettuale

Atzeni, Ceri, Paraboschi, Torlone Basi di dati

Progettazione di Database

SISTEMI INFORMATIVI E DATABASE

SOLUZIONE ESAME DI STATO 2015/2016 Indirizzo: ITSI - AMMINISTRAZIONE, FINANZA E MARKETING ARTICOLAZIONE SISTEMI INFORMATIVI AZIENDALI

BASE DI DATI. Esercizio: Agenzia pubblicitaria Progettazione concettuale Progettazione logica. Informatica Umanistica Università di Pisa

Fase di Analisi Class Diagram. Esercizi

Progettazione di basi di dati

Progettazione logica

Si considerino le seguenti specifiche relative alla realizzazione di un sistema informativo per un concessionario di automobili.

SCHEMA ER. Tutti i dati del carrello acquisti sono memorizzati nel database e quindi può essere costruito con più query.

Numero di Componenti

Si considerino le seguenti specifiche relative alla realizzazione di un sistema informativo per la comunità scientifica di ricerca paleontologica.

CORSO di INFORMATICA e ARCHIVIAZIONE

Cap. 3 - Il modello ER

Esercitazione seconda prova Esame di Stato Prova di Informatica Gestionale ITC Programmatori e Mercurio. Note introduttive

11 - Progettazione Logica

Esempi sul modello Entità-Associazione

Compito Basi di Dati. Tempo concesso : 90 minuti 28 aprile 2005 Nome: Cognome: Matricola:

Corso di Informatica (Basi di Dati)

Esercitazione 4: Trigger in DB2

Informatica Industriale

Esercitazione: Dalle Specifiche alla Modellazione ER. Roberto Basili a.a. 2011/2012

Basi di dati: appello 21/09/12

Semplici esercizi relativi agli schemi E/R e prog. logica. Esempio A : Orario delle lezioni dei corsi

B a s i d i D a t i ( M o d u l o T e o r i a ) P r o v a s c r i t t a

CAPITOLO V. DATABASE: Il modello relazionale

Laboratorio di Basi di Dati Per Bioinformatica

Fase di Analisi Class Diagram. Esercizi

MySQL progettazione di un database per un mobilificio

BASI DATI INFORMATICA

Prova del 14/09/09. Considerare la seguente descrizione di un campeggio:

Le basi di dati. Definizione 1. Lezione 2. Bisogna garantire. Definizione 2 DBMS. Differenza

S.I.T. PER LA VALUTAZIONE E GESTIONE DEL TERRITORIO Corso di Laurea Magistrale in Scienze Ambientali. Alessandra Raffaetà

SQL SQL. Definizione dei dati. Domini. Esistono 6 domini elementari:

Basi di Dati e Sistemi Informativi. Progettazione Concettuale: Il modello Entità-Relazioni

Transcript:

PROGETTAZIONE LOGICA L obiettivo della fase di progettazione Logica è progettare lo Schema Logico della Base di Dati partendo da quanto prodotto nella fase di progettazione Concettuale. Si ricorda che, se come modello Concettuale dei Dati si è utilizzato il modello Entità-Relazione (E-R), i prodotti della fase di progettazione Concettuale sono lo Schema o Diagramma E-R della Base di Dati e le Regole Aziendali. Se adottiamo come modello Logico dei Dati il modello Logico Relazionale il risultato della fase di progettazione Logica sarà lo Schema Logico Relazionale della Base di Dati. Di conseguenza, la fase di progettazione Logica dovrà tradurre opportunamente il Diagramma E-R e le Regole Aziendali prodotte durante la fase di progettazione Concettuale nello Schema Logico Relazionale della Base di Dati. Un algoritmo semplificato per effettuare tale traduzione, applicabile ai costrutti del modello E-R visti a lezione, si compone di 4 passi: 1. Rappresentazione delle Entità. Ad ogni Entità presente nel Diagramma E-R corrisponderà una Relazione (d ora in avanti Tabella per evitare confusione con il termine relazione del modello E-R) nello Schema Logico Relazionale. Ogni attributo dell Entità sarà un attributo della Tabella, l attributo o l insieme di attributi identificatori dell Entità costituiranno la chiave primaria della Tabella. Il dominio di ciascun attributo sarà opportunamente scelto in base alle Regole Aziendali ed ai requisiti della Base di Dati. In tale fase si ignorano le Entità figlie delle Generalizzazioni che verranno appositamente trattate al passo 1-bis. 1-bis. Rappresentazione delle Generalizzazioni. Premesso che non è possibile dare delle regole generali per la rappresentazione delle Generalizzazioni e che ogni caso andrebbe valutato dal progettista e trattato in modo specifico si possono, tuttavia, dare delle linee guida applicabili in alcuni casi particolari e molto semplici: a. Le Entità figlie non possiedono attributi propri. In questo caso si aggiungono all Entità padre tanti attributi di tipo bit per quante sono le Entità figlie. Tali attributi assumeranno valore 1 se l Entità padre è anche del tipo dell Entità figlia corrispondente. Cognome DataDiNascita Artista Nazionalità Cantante Compositore Musicista Autore Applicando la regola sopra definita avremo: TABLE Artista ( longint, Cognome varchar(20), varchar(20), DataDiNascita date, Nazionalità varchar(20), Cantante bit, Compositore bit, Musicista bit, Autore bit, primary key() ); Ad esempio, un Artista potrebbe avere il valore 1 per gli attributi Cantante ed Autore ed il valore 0 per gli attributi Musicista e Compositore. Se invece si vuole impedire che più attributi abbiano il valore 1 (generalizzazione esclusiva) si possono: (i) inserire uno o più Prof. Ing. Alfredo GARRO 1/6

vincoli di tupla; (ii) sostituire gli attributi di tipo bit con un solo attributo di tipo smallint ed associare ad ogni Entità figlia un particolare valore intero, ad esempio: TABLE Artista ( longint, Cognome varchar(20), varchar(20), DataDiNascita date, Nazionalità varchar(20), TipoArtista smallint, primary key() ); con la convenzione che TipoArtista avrà valore1 se l Artista è un Cantante, valore 2 se è un Compositore, valore 3 se è un Musicista e valore 4 se è Autore. Ovviamente sarà necessario un vincolo sui dati che impedisca all attributo di assumere un valore più piccolo di 1 e più grande di 4 ( check (TipoArtista>=1 and TipoArtista<=4) ) se la generalizzazione è totale 1 (non esistono altre tipologie di artisti). Se, invece, la generalizzazione è parziale, cioè esistono altre tipologie di artisti oltre a quelle specificate dalle Entità figlie (ad esempio Attore), è ammissibile per TipoArtista il valore 0, che indica appunto che all artista non è assegnabile nessuno dei tipi rappresentati dalle Entità figlie, in tal caso il vincolo diventa: check (TipoArtista>=0 and TipoArtista<=4). Un caso particolare si ha quando le Entità figlie sono due e la generalizzazione è esclusiva e totale, in questo caso basta aggiungere un solo attributo di tipo bit il cui nome può essere quello di una delle due Entità figlie. Il suo valore sarà pari a 1 se l Entità padre è del tipo dell Entità figlia corrispondente al nome dell attributo, 0 se l Entità padre è del tipo dell altra Entità figlia. b. Le Entità figlie possiedono attributi propri. In questo caso a ciascuna Entità figlia corrisponderà una Tabella nella quale saranno riportati tutti gli attributi propri dell Entità figlia più un attributo che si riferisce alla chiave primaria dell Entità padre. Cognome CF Persona DataDiNascita Nazionalità Stipendio Studente Lavoratore Matricola ClasseDiReddito DataIscrizione Applicando la regola sopra definita avremo: DataAssunzione Qualifica TABLE Persona ( CF char(16), Cognome varchar(20), varchar(20), DataDiNascita date, Nazionalità varchar(20), primary key(cf) ); TABLE Studente ( Matricola longint, DataIscrizione date, ClasseDiReddito smallint, Fiscale char(16), primary key(matricola), foreign key(fiscale) references Persona(CF) ); TABLE Lavoratore ( longint, DataAssunzione date, Qualifica varchar(20), Stipendio currency, Fiscale char(16), primary key(), foreign key(fiscale) references Persona(CF) ); c. Alcune Entità figlie possiedono attributi propri ed altre non possiedono attributi propri. In questo caso si combinano i due approcci precedentemente discussi. 1 Una generalizzazione totale è rappresentata disegnando la freccia con tratto pieno Prof. Ing. Alfredo GARRO 2/6

2. Rappresentazione delle Associazioni uno a molti. Le Associazione uno a molti presenti nel Diagramma E-R si rappresentano aggiungendo alla Tabella rappresentante l Entità raffigurata al lato uno dell associazione uno o più attributi che si riferiscono alla chiave primaria della Tabella rappresentante l Entità raffigurata al lato enne dell associazione. Si aggiungono inoltre, sempre alla Tabella rappresentante l Entità raffigurata al lato uno dell associazione, eventuali attributi propri dell Associazione. Targa Modello Marca CF DataDiNascita Nazionalità Automobile (1,1) possesso (0,N) Persona Cilindrata Cavalli L Associazione uno a molti possesso lega le automobili alle persone specificando che una persona può possedere al minimo nessun automobile ed al massimo N automobili e che una automobile ha uno ed un solo proprietario. Applicando la regola sopra definita avremo: TABLE Automobile ( Targa char(7), Modello varchar (20), Marca varchar (20), Cilindrata int, Cavalli int, Proprietario char(16), DataImmatricolazione date, primary key(targa), foreign key(proprietario) references Persona(CF) ); TABLE Persona ( CF char(16), Cognome varchar(20), varchar(20), DataDiNascita date, Nazionalità varchar(20), primary key(cf) ); 3. Rappresentazione delle Associazioni molti a molti. Le Associazioni molti a molti presenti nel Diagramma E-R si rappresentano mediante una Tabella avente come nome quello dell Associazione e come attributi un insieme di attributi che si riferiscono alle chiavi primarie delle Tabelle rappresentanti le Entità correlate dall Associazione più gli (eventuali) attributi propri dell Associazione. La chiave primaria della nuova Tabella sarà costituita dall insieme di attributi che si riferiscono alle chiavi primarie delle Tabelle rappresentanti le Entità correlate dall Associazione. DataImmatricolazione Matricola Cognome DataAssunzione Progetto (1,N) coinvolgimento (0,N) Dipendente Durata Budget MesiUomo Qualifica Stipendio L Associazione molti a molti coinvolgimento lega i dipendenti ai progetti specificando che un dipendente può essere coinvolto al minimo in nessun progetto ed al massimo in N progetti e che un progetto può vedere coinvolti al minimo un dipendente ed al massimo N dipendenti. Applicando la regola sopra definita avremo: Prof. Ing. Alfredo GARRO 3/6

TABLE Dipendente ( Matricola longint, Qualifica varchar(20), DataAssunzione date, Stipendio currency, primary key(matricola) ); TABLE Progetto ( char(4), varchar(50), durata smallint, budget currency, primary key() ); TABLE Coinvolgimento ( Dipendente longint, Progetto char(4), MesiUomo smallint, primary key(dipendente, Progetto), foreign key(dipendente) references Dipendente(Matricola), foreign key(progetto) references Progetto() ); 4. Rappresentazione dei Vincoli sui Dati. Si arricchiscono le Tabelle sinora definite dei vincoli sui valori degli attributi e dei vincoli di tupla ricavati in base alle Regole Aziendali ed ai requisiti della Base di Dati. Al fine di chiarire ulteriormente i passi sopra elencati progettiamo lo Schema Logico Relazione corrispondente al seguente Diagramma E-R: Città Indirizzo DataApertura Matricola Cognome Qualifica PuntoVendita (1,N) dipendenza (1,1) Dipendente Stipendio (0,N) DataAssunzione tesseramento NumeroTessera (1,N) Responsabile Impiegato Cliente NCartaCredito CF Cognome Telefono PASSO 1: Rappresentazione delle Entità. Nel Diagramma E-R, ignorando le Generalizzazioni, sono presenti 3 Entità: Dipendente, Punto Vendita e Cliente. In base agli attributi E-R indicati nel Diagramma si ottengono le seguenti Tabelle: TABLE Dipendente ( Matricola longint, varchar (20), Cognome varchar (20), Qualifica varchar(20), DataAssunzione date, Stipendio currency, primary key(matricola) ); TABLE PuntoVendita ( char(5), varchar(50), Città varchar (50), Indirizzo varchar(70), DataApertura date, primary key() ); Prof. Ing. Alfredo GARRO 4/6

PASSO 1-bis: Rappresentazione delle Generalizzazioni. Abbiamo una sola generalizzazione che coinvolge l Entità Dipendente. Le Entità figlie (Impiegato e Responsabile) non hanno attributi propri, quindi, ricadiamo nel caso a. del passo 1-bis; inoltre, la generalizzazione è totale (non esistono altre tipologie di dipendenti) ed esclusiva poiché un dipendente o è un semplice impiegato oppure è un responsabile. Possiamo quindi aggiungere, come indicato al termine del caso a., un unico attributo di tipo bit che chiameremo Responsabile, se tale attributo avrà valore 1 allora ci troveremo di fronte ad un dipendente con incarico di responsabile del punto vendita, se, invece, tale attributo avrà valore 0 allora ci troveremo di fronte ad un dipendente con mansioni di semplice impiegato. TABLE Dipendente ( Matricola longint, varchar (20), Cognome varchar (20), Qualifica varchar(20), DataAssunzione date, Stipendio currency, Responsabile bit, primary key(matricola) ); TABLE PuntoVendita ( char(5), varchar(50), Città varchar (50), Indirizzo varchar(70), DataApertura date, primary key() ); PASSO 2: Rappresentazione delle Associazioni uno a molti. Abbiamo una sola associazione una a molti, l associazione dipendenza che lega i dipendenti ai punti vendita specificando che un punto vendita può avere al minimo un dipendente ed al massimo N dipendenti e che un dipendente lavora in uno ed un solo punto vendita. Seguendo le regole relative al passo 2 e tenendo presente che l Entità lato uno è il Dipendente mentre L Entità lato enne è il Punto Vendita si ottiene: TABLE Dipendente ( Matricola longint, varchar (20), Cognome varchar (20), Qualifica varchar(20), DataAssunzione date, Stipendio currency, Responsabile bit, PuntoVendita char (5), primary key(matricola), foreign key(puntovendita) references PuntoVendita() ); TABLE PuntoVendita ( char(5), varchar(50), Città varchar (50), Indirizzo varchar(70), DataApertura date, primary key() ); PASSO3: Rappresentazione delle Associazioni moli a molti. Abbiamo una sola associazione molti a molti, l associazione tesseramento che lega i punti vendita ed i clienti specificando che un punto vendita può tesserare al minimo nessun cliente ed al massimo N clienti e che un cliente può essere tesserato al minimo con un punto vendita ed al massimo con N punti vendita. L associazione tesseramento possiede, inoltre, un attributo proprio indicante il numero della tessera del cliente. Seguendo le regole relative al passo 3 si ottiene: TABLE Dipendente ( Matricola longint, varchar (20), Cognome varchar (20), Qualifica varchar(20), DataAssunzione date, Stipendio currency, Responsabile bit, PuntoVendita char (5), primary key(matricola), foreign key(puntovendita) references PuntoVendita() ); TABLE PuntoVendita ( char(5), varchar(50), Città varchar (50), Indirizzo varchar(70), DataApertura date, primary key() ); TABLE Tesseramento ( Cliente char(16), PuntoVendita char(5), NumeroTessera longint, Prof. Ing. Alfredo GARRO 5/6

primary key(cliente, PuntoVendita), foreign key(cliente) references Cliente(CF), foreign key(puntovendita) references PuntiVendita() ); PASSO 4: Rappresentazione dei Vincoli sui Dati. Pur non avendo a disposizione le Regole Aziendali a corredo del Diagramma E-R possiamo sulla base di ovvie considerazioni inserire i seguenti vincoli sui dati: TABLE Dipendente ( Matricola longint, varchar (20), Cognome varchar (20) not null, Qualifica varchar(20), DataAssunzione date not null, Stipendio currency not null, Responsabile bit default 0, PuntoVendita char (5), primary key(matricola), foreign key(puntovendita) references PuntoVendita(), check(dataassunzione>10/06/2002) ); TABLE PuntoVendita ( char(5), varchar(50), Città varchar (50) not null, Indirizzo varchar(70) not null, DataApertura date, primary key(), check(dataapertura>20/06/2002) ); varchar(15) not null, NCartaCredito char(16), primary key(cf) ); TABLE Tesseramento ( Cliente char(16), PuntoVendita char(5), NumeroTessera longint not null, primary key(cliente, PuntoVendita), foreign key(cliente) references Cliente(CF), foreign key(puntovendita) references PuntiVendita(), unique(numerotessera), check(numerotessera>0) ); Lo Schema Logico Relazionale della Base di Dati risultato dalla fase di progettazione Logica sarà quindi: DATABASE PuntiVendita { } TABLE Dipendente ( Matricola longint, varchar (20), Cognome varchar (20) not null, Qualifica varchar(20), DataAssunzione date not null, Stipendio currency not null, Responsabile bit default 0, PuntoVendita char (5), primary key(matricola), foreign key(puntovendita) references PuntoVendita(), check(dataassunzione>10/06/2002) ); TABLE PuntoVendita ( char(5), varchar(50), Città varchar (50) not null, Indirizzo varchar(70) not null, DataApertura date, primary key(), check(dataapertura>20/06/2002) ); varchar(15) not null, NCartaCredito char(16), primary key(cf) ); TABLE Tesseramento ( Cliente char(16), PuntoVendita char(5), NumeroTessera longint not null, primary key(cliente, PuntoVendita), foreign key(cliente) references Cliente(CF), foreign key(puntovendita) references PuntiVendita(), unique(numerotessera), check(numerotessera>0) ); Prof. Ing. Alfredo GARRO 6/6