Progettazione di basi di dati: differenze tra le versioni

Versione delle 08:29, 24 ott 2018

Versione attuale delle 23:39, 22 giu 2025

(20 versioni intermedie di 14 utenti non mostrate)

Riga 1:

{{torna a|Base di dati}}

{{C|Questa definizione della progettazione di basi di dati confonde il concetto di relazione con quello di associazione fra relazioni, ci sono molti refusi e non consente la comprensione del concetto di progettazione di database né delle modalità con cui tale processo si esplica. Deve essere riscritta completamente!|informatica|febbraio 2018}}

{{U|verso=da|Schema di database|multi1=Progettazione logica|multi2=Modello concettuale (informatica)|informatica|maggio 2024}}

In [[informatica]] la '''progettazione di basi di dati''' è il processo di formulazione di un [[Modello dei dati|modello]] dettagliato del [[Base di dati|database]]. Questo modello contiene tutte le scelte progettuali a livello logico e fisico e i parametri fisici di memorizzazione necessari per la generazione del [[Data Definition Language|data definition language (DDL)]], che può essere usato per l'implementazione del database. Un modello dei dati completamente specificato contiene i dettagli specifici per ogni singola entità.

== Descrizione ==

Il termine progettazione di basi di dati può essere usato per descrivere diverse parti della progettazione in un generico [[Database management system|database management system (DBMS)]]. Principalmente, e più correttamente, può essere pensato come la progettazione logica della struttura dati di base usata per memorizzare i dati. Nel [[modello relazionale]] queste strutture sono le [[Tabella (database)|tabelle]] e le [[Vista (basi di dati)|viste]]. In una [[base di dati ad oggetti]] le entità e le relazioni sono mappate direttamente alle classi di oggetti e ai nomi delle relazioni. Tuttavia, il termine database potrebbe anche essere utilizzato per applicare il generico processo di progettazione, non solo le singole strutture dati di base, ma anche le schermate e interrogazioni usate come parte di una generica applicazione per database presente all'interno del DBMS.<ref name="Gehani">{{cita|Gehani, N|}}. (2006). The Database Book: Principles and practice using MySQL. 1st ed., Summit, NJ.: Silicon Press</ref>

Lo sviluppo del database generalmente consiste in un numero di passi effettuati dal progettista del database. Solitamente, esso deve:

Riga 12 ⟶ 14:

* Sovrapporre una struttura logica sopra i dati sulla base delle relazioni precedentemente definite.<ref name="Teorey, T.J. 2009">Teorey, T.J., Lightstone, S.S., et al., (2009). Database Design: Know it all.1st ed. Burlington, MA.: Morgan Kaufmann Publishers</ref>

All'interno del modello relazionale l'ultimo passo di sopra può generalmente essere spezzato in due parti ulteriori, quella di definire il raggruppamento delle informazioni all'interno del sistema, generalmente definendo quali sono gli oggetti base su cui le informazioni sono memorizzate, e poi definire le relazioni tra questi gruppi di informazioni, o oggetti. Questo step non è necessario con un base di dati ad oggetti.<ref name="Teorey, T.J. 2009Gehani" />

=== Definizione dati da memorizzare ===

Nella maggioranza dei casi, chi progetta il database è una persona che possiede competenze in tale campo, piuttosto che competenze nel dominio applicativo dei dati da memorizzare. Ad esempio financial information, biological information ecc. Pertanto, i dati da memorizzare devono essere definiti in cooperazione con un esperto di dominio, che è consapevole di quali dati devono essere memorizzati nel nuovo sistema.

da memorizzare. ad esempio financial information, biological information ecc. Pertanto, i dati da memorizzare devono essere definiti in cooperazione con un esperto di dominio,

che è consapevole di quali dati devono essere memorizzati nel nuovo sistema.

Questo processo è uno di quelli comunemente considerati parte dell'[[analisi dei requisiti]], e richiede che il progettista abbia le competenze necessarie per sfruttare al meglio le conoscenze di dominio applicativo. Questo avviene perché spesso chi progetta il database non riesce esprimere con chiarezza quali sono i requisiti del sistema siccome non è abituato a pensare in termini dei dati che devono essere memorizzati. Tali dati possono essere rilevati tramite un'apposita specifica dei requisiti.<ref>Teorey, T.; Lightstone, S. and Nadeau, T.(2005) ''Database Modeling & Design: Logical Design'', 4th edition, Morgan Kaufmann Press. ISBN 0-12-685352-5</ref>

al meglio le conoscenze di dominio applicativo. Questo avviene perché spesso chi progetta il database non riesce esprimere con chiarezza quali sono i requisiti del sistema siccome non è abituato a pensare in termini dei dati che devono essere memorizzati. Tali dati possono essere rilevati tramite un'apposita specifica dei requisiti.<ref>Teorey, T.; Lightstone, S. and Nadeau, T.(2005) ''Database Modeling & Design: Logical Design'', 4th edition, Morgan Kaufmann Press. ISBN 0-12-685352-5</ref>

=== Definizione relazioni tra i dati ===

Una volta che il progettista è consapevole di quali dati memorizzare all'interno della base di dati, deve definire dovecome lai dipendenzadati èdipendono all'internodagli dei datialtri. A volte quando i dati vengono cambiati tupossono puoiessere modificaremodificati altri dati che non sono visibili. Per esempio, in una lista di nomi e indirizzi (in realtà al posto del nome è necessario usare un attributo univoco come ad esempio il codice fiscale), assumendo una situazione dove più persone possono avere lo stesso indirizzo, ma una persona non può avere molto più di un indirizzo. Quindi dato un nome, l'indirizzo è dipendenteunivocamente suldefinito; nome.tuttavia Quandol'inverso fornitonon vale, dato un indirizzo non possiamo univocamente definire un nome aperché lapiù lista,persone possono risiedere allo stesso indirizzo. Poiché l'attributo indirizzo puòè esseredefinito unicamenteunivocamente definito;dall'attributo tuttavianome, labbiamo la dipendenza dall'inversoattributo noindirizzo valedall'attributo -nome. quando(NOTA: datoIl unmodello indirizzorelazionale eè lachiamato lista,così perché è basato sulla struttura matematica conosciuta come [[Relazione binaria|relazione]]).

un nome non può essere unicamente definito perché più persone possono risiedere allo stesso indirizzo. Perché un indirizzo è definito da un nome, un indirizzo è considerato dipendente dal nome

(NOTA: un'idea sbagliata comune è che il modello relazionale sia anche chiamato a causa dell'avvio di relazioni tra elementi dati ivi. Questo non è vero. Il modello relazionale è quindi nominato perché è basato sulla struttura matematica conosciuta come [[Relazione binaria|relazione]]).

=== Strutturazione Logica dei dati ===

{{Vedi anche|Schema di database|Tablespace}}

Una volta che le relazionientità e le dipendenzerelazioni tra ile diversidiverse pezzientità sono state definite, Èè possibile organizzare i dati in una struttura logica la quale può allora essere mappata negli oggetti memorizzati e supportati dal DBMS. Nel caso di un [[Relational database management system|database relazionale]] gli oggetti memorizzati sono tabelle che immagazzinano i dati in righe e colonne. In un database ad oggetti, invece, gli oggetti memorizzati corrispondono direttamente agli oggetti usati dalla [[programmazione orientata agli oggetti]] per scrivere le applicazioni che vogliono gestire e accedere ai dati. Le relazioni possono essere definite come attributi delle classi ad oggetti coinvolte o come metodi che operano su tali classi.

Il modo in cui questa mappatura è generalmente fatta è tale che ogni insieme di dati correlati che dipende da un singolo oggetto, se reale o astratto, è collocato in una tabella. Le relazioni tra questi oggetti dipendenti è allora memorizzato come collegamento tra i vari oggetti.

Riga 70 ⟶ 67:

=== Progettazione Fisica ===

{{Vedi anche|Schema Fisico del Database}}

Il design fisico di un database precisa la configurazione fisica di un database sui supporti di memorizzazione. Questo include dettagliate specifiche dei [[data element]], [[tipo di dato]], [[Indice (basi di dati)|indicizzazione]] e altri parametri risiedenti nel [[data dictionary]] del DMBS. È la progettazione dettagliata di un sistema che include moduli e le specifiche hardware e software del sistema.

Riga 78 ⟶ 74:

== Bibliografia ==

* {{cita libro|titolo="[http://www.ateneonline.it/catlibro.asp?item_id=2986 Basi di dati 4/ed]" |autore= Paolo Atzeni, Stefano Ceri, Stefano Paraboschi, Riccardo Torlone|anno=2014 |ISBN=978-88-386-6587-5}}

* {{cita libro|autore=Narain Gehani|titolo=The Database Book: Principles & Practice using MySQL|ed=1|anno=2006|editore=Silicon Press|isbn=0-929306-35-X|lingua=en|cid=Gehani}}

* S. Lightstone, T. Teorey, T. Nadeau, “Physical Database Design: the database professional's guide to exploiting indexes, views, storage, and more”, Morgan Kaufmann Press, 2007. ISBN 0-12-369389-6

* M. Hernandez, "[http://www.informit.com/store/database-design-for-mere-mortals-a-hands-on-guide-to-9780321884497 Database Design for Mere Mortals]: A Hands-On Guide to Relational Database Design", 3rd Edition, Addison-Wesley Professional, 2013. ISBN 0-321-88449-3

== Voci correlate ==

{{Div col}}

* [[Normalizzazione (informatica)]]

* [[Relational database management system|Database relazionale]]

Riga 99 ⟶ 97:

* [[Web semantico]]

* [[Three schema approach]]

{{Div col end}}

== Altri progetti ==

{{Interprogetto}}

== Collegamenti esterni ==

* [http://www.sqlteam.com/article/database-design-and-modeling-fundamentals Database Design and Modeling Fundamentals]

* [https://support.office.com/en-US/article/Database-design-basics-EB2159CF-1E30-401A-8084-BD4F9C9CA1F5 Database design basics]

* [http://databases.about.com/od/specificproducts/a/normalization.htm Database Normalization Basics] {{Webarchive|url=https://web.archive.org/web/20070205184226/http://databases.about.com/od/specificproducts/a/normalization.htm |date=5 febbraio 2007 }} by Mike Chapple (About.com)

* [https://web.archive.org/web/20110928000244/http://www.databasejournal.com/sqletc/article.php/1428511 Database Normalization Intro], [https://web.archive.org/web/20110708233620/http://www.databasejournal.com/sqletc/article.php/26861_1474411_1 Part 2]

* {{Cita web|url=httphttps://dev.mysql.com/tech-resources/articles/intro-to-normalization.html |urlarchivio=https://web.archive.org/web/20110606025027/http://dev.mysql.com/tech-resources/articles/intro-to-normalization.html |dataarchivio=6 giugno 2011 |titolo=An Introduction to Database Normalization |accesso=25 febbraio 2012 }}

* {{Cita web|url=httphttps://www.utexas.edu/its/windows/database/datamodeling/rm/rm7.html |urlarchivio=https://web.archive.org/web/20100106115112/http://www.utexas.edu/its/archive/windows/database/datamodeling/rm/rm7.html |dataarchivio=6 gennaio 2010 |titolo=Normalization |accesso=25 febbraio 2012 }}

* {{Collegamento interrotto|1=[http://tinycc.me/DybeLE Efficient Database Design] |data=dicembre 2019 |bot=InternetArchiveBot }}

* [https://web.archive.org/web/20190505222423/http://en.tekstenuitleg.net/articles/software/database-design-tutorial/intro.html Relational database design tutorial]

{{Portale|informatica}}

{{DEFAULTSORT:Progettazione di Basi di Dati}}