|
<noinclude>
{{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}}
{{Bar7/barradisc|2019_07_25}}
[[Categoria:Bar di Wikipedia]]
[[Categoria:Wikipedia_Bar_-_25_luglio_2019]]
[[Categoria:Wikipedia_Bar - Archivio_2019-30]]
[[Categoria:Wikipedia_Bar - luglio 2019]]
</noinclude>
<!----------------------------------
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à.
NON CANCELLARE NESSUNA PARTE DELLA PAGINA, GRAZIE
SCRIVERE SOTTO QUESTA LINEA
== 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>Gehani, N. (2006). The Database Book: Principles and practice using MySQL. 1st ed., Summit, NJ.: Silicon Press</ref>
Visti numerosi casi in cui l'applicazione dei criteri generali di enciclopedicità delle voci riguardanti alcuni personaggi del web come gestori di blog e di canali YouTube è risultata poco efficace, credo che sia necessario fare chiarezza creando una pagina di aiuto che raccolga dei criteri di enciclopedicità specifici per i personaggi del web. Rispondete scrivendo se siete d'accordo o meno e avanzate eventuali proposte :-) --'''''[[Utente:Tsu.name|Tsu]].<small>[[Discussioni utente:Tsu.name|name]]</small>''''' 20:40, 25 lug 2019 (CEST)
:{{Fav}}, anche se sarà difficilissimo stabilire ''quali'' saranno i criteri.--<span style=";font-size:100%;font-family:segoe ui;">[[Utente:Jtorquy|<span style="color:#AE262B;">'''tor'''</span>]][[Discussioni utente:Jtorquy|<span style="color:#FFD700;">'''qua'''</span>]]</span> 20:46, 25 lug 2019 (CEST)
Lo sviluppo del database generalmente consiste in un numero di passi effettuati dal progettista del database. Solitamente, esso deve:
::{{fav}} Dei criteri minimi (anche molto stringenti) sono necessari, non è possibile che, come succede in gran parte ora, una personalità legata al web debba necessariamente partecipare a progetti ''al di fuori'' di esso per essere ritenuto enciclopedico.--[[Utente:Janik98|Janik98]] ([[Discussioni utente:Janik98|msg]]) 21:10, 25 lug 2019 (CEST)
::: A parte il criterio un po' strano (il web ormai è parte preponderante della nostra vita, uno scrittore ha meno seguito di un personaggio del web), i criteri sono SUFFICIENTI, ma MAI NECESSARI. --[[Utente:Emanuele676|Emanuele676]] ([[Discussioni utente:Emanuele676|msg]]) 23:09, 25 lug 2019 (CEST)
* Definire i dati da memorizzare nel database
::::Sì, ma quali criteri? <small>lol</small>--<span style=";font-size:100%;font-family:segoe ui;">[[Utente:Jtorquy|<span style="color:#AE262B;">'''tor'''</span>]][[Discussioni utente:Jtorquy|<span style="color:#FFD700;">'''qua'''</span>]]</span> 00:11, 26 lug 2019 (CEST)
* Definire le relazioni tra i diversi elementi presenti tra i dati
{{contrario}}: abbiamo già voci su pornostar e giocatori di poker di dubbia enciclopedicità; se poi volete i lemmi per Andrea Diprè e Giuseppe Simone, la strada è quella giusta--[[Utente:Agapito Malteni|Agapito Malteni]]<sup>[[Discussioni_utente:Agapito Malteni| (lettere in viaggio)]]</sup> 17:26, 28 lug 2019 (CEST)
* 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>
:Dimenticavo, {{favorevole}} --[[Utente:Emanuele676|Emanuele676]] ([[Discussioni utente:Emanuele676|msg]]) 17:44, 28 lug 2019 (CEST)
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. 2009" />
=== 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.
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>
=== Definizione relazioni tra i dati ===
Una volta che il progettista è consapevole di quali dati memorizzare all'interno della base di dati, deve definire dove la dipendenza è all'interno dei dati. A volte quando i dati vengono cambiati tu puoi modificare altri dati che non sono visibili. Per esempio, in una lista di nomi e indirizzi, assumendo una situazione dove più persone possono avere lo stesso indirizzo, ma una persona non può avere molto più di un indirizzo, l'indirizzo è dipendente sul nome. Quando fornito un nome a la lista, l'indirizzo può essere unicamente definito; tuttavia, l'inverso no vale - quando dato un indirizzo e la lista,
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}}
Una volta che le relazioni e le dipendenze tra i diversi pezzi 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.
Ogni tabella può rappresentare un'implementazione di un oggetto logico o una relazione di accoppiamento di una o più istanze di uno o più oggetti logici. Le relazioni tra le tabelle possono allora essere memorizzate come collegamenti tra le tabelle figlie e padre. Dato che le complesse relazioni logiche sono a loro volta delle tabelle, avranno probabilmente collegamenti a più di una tabella padre.
=== Diagramma ER (modello entità-relazione) ===
{{vedi anche|Modello E-R}}
[[File:ER Diagram MMORPG.png|thumb|upright=1.5|Un esempio di diagramma ER]]
La progettazione di basi di dati include anche i diagrammi del [[Modello E-R]]. Un tale diagramma aiuta nella progettazione in modo efficiente.
Gli attributi in un diagramma ER sono di solito modellati come un ovale specificandone il nome, e collegati all'entità o relazione che contiene l'attributo.
=== Esempio: una proposta di progettazione per Microsoft Access<ref>Database design basics. (n.d.). Database design basics. Retrieved May 1, 2010, from https://support.office.com/en-US/article/Database-design-basics-EB2159CF-1E30-401A-8084-BD4F9C9CA1F5</ref> ===
# ''Definire l'obiettivo del database'' - Questo aiuta a prepararsi per i passi successivi.
# ''Trovare e organizzare le informazioni necessarie'' - Raccogliere tutti questi tipi di informazioni da registrare nel database, ad esempio il nome di un prodotto o il numero d'ordine.
# ''Dividere le informazioni nelle tabelle'' - Dividere gli elementi informativi in entità principali oppure oggetti, ad esempio Prodotti o Ordini. Ogni oggetto allora diventa una tabella.
# ''Trasformare gli elementi informativi nelle colonne della tabella'' - Decidere quale informazione è necessaria per essere memorizzata in ogni tabella. Per esempio, una tabella 'Impiegati' potrebbe includere campi come Cognome e Data di Assunzione.
# ''Specificare le chiavi primarie'' - Scegliere la chiave primaria di ogni tabella. La chiave primaria è una colonna, o un loro insieme, che viene usata per identificare univocamente ogni riga. Un esempio potrebbe essere il codice prodotto o il codice dell'ordine.
# ''Impostare le relazioni tra le tabelle'' - Guardare ogni tabella e decidere come i dati in essa sono correlati ai dati di un'altra tabella. Aggiungere campi alle tabelle o crearne di nuove per chiarire le relazioni, se ritenuto opportuno.
# ''Affinare la progettazione'' - Analizzare la progettazione per eventuali errori. Creare le tabelle e aggiungerci un paio di record come esempio campione. Controllare se i risultati vengono dalle tabelle come previsto. Effettuare adattamenti alla progettazione, se necessario.
# ''Applicare le [[Normalizzazione (informatica)|regole di normalizzazione]]'' - Applicare tali regole ai dati per vedere se le tabelle sono strutturate il modo corretto. Effettuare adattamenti alle tabelle, se necessario.
== Normalizzazione ==
{{Vedi anche|Normalizzazione (informatica)}}
Nel progettazione di un [[Relational database management system|database relazionale]], la ''normalizzazione'' è un via sistematica di garantire che la struttura di un database sia adatta per scopi
generici di interrogazione e sia libera da certe caratteristiche indesiderate — le anomalie da inserimento, aggiornamento, e cancellazione che potrebbero condurre alla perdita
dell'[[Integrità dei dati]].
Una regola standard della progettazione prevede che il progettista dovrebbe creare un progetto di base di dati pienamente normalizzato; in maniera selettiva la [[denormalizzazione]] può essere successivamente eseguita, ma solo per ragioni di [[computer performance|performance]]. Tuttavia, molte discipline di modellazione, ad esempio il [[dimensional modeling]] usato nella progettazione di [[data warehouse]], raccomanda esplicitamente di progettare in maniera non normalizzata, cioè progettazioni che in larga parte non sono conformi al 3NF.
La Normalizzazione consiste in forme normali che sono 1NF, 2NF, 3NF, BOYCE-CODD NF (3.5NF), 4NF e 5NF.
=== Schema Concettuale ===
{{Vedi anche|Modello concettuale (informatica)}}
=== Raffinamento dello Schema ===
Il raffinamento dello schema di un database specifica che i dati vengano normalizzati per ridurne l'insufficienza e i conflitti.
=== 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.
== Note ==
<references />
== 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}}
* 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 ==
* [[Normalizzazione (informatica)]]
* [[Relational database management system|Database relazionale]]
* [[Modello relazionale]]
* [[POOD]] ([[Principle of orthogonal design]])
* [[The Third Manifesto]]
* [[Mappa concettuale]]
* [[Modellazione dei dati]]
* [[Modello E-R]]
* [[Entity-attribute-value model]]
* [[Object-relationship modeling]]
* [[Object Role Modeling]]
* [[Rappresentazione della conoscenza]]
* [[Logical data model]]
* [[Mappa mentale]]
* [[Physical data model]]
* [[Web semantico]]
* [[Three schema approach]]
== Altri progetti ==
{{Interprogetto}}
== Collegamenti esterni ==
* [http://www.sqlteam.com/article/database-design-and-modeling-fundamentals]
* [https://support.office.com/en-US/article/Database-design-basics-EB2159CF-1E30-401A-8084-BD4F9C9CA1F5]
* [http://databases.about.com/od/specificproducts/a/normalization.htm Database Normalization Basics] by Mike Chapple (About.com)
* [http://www.databasejournal.com/sqletc/article.php/1428511 Database Normalization Intro], [http://www.databasejournal.com/sqletc/article.php/26861_1474411_1 Part 2]
* {{Cita web|url=http://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=http://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 }}
* [http://tinycc.me/DybeLE Efficient Database Design]
* [http://en.tekstenuitleg.net/articles/software/database-design-tutorial/intro.html Relational database design tutorial]
{{DEFAULTSORT:Progettazione di Basi di Dati}}
[[Categoria:Basi di dati]]
| 