Domanda

I modelli di progettazione sono generalmente correlati al design orientato agli oggetti Esistono modelli di progettazione per creare e programmare database relazionali ?
Molti problemi devono sicuramente avere soluzioni riutilizzabili.

Esempi potrebbero includere schemi per la progettazione di tabelle, procedure memorizzate, trigger, ecc ...

Esiste un repository online di tali modelli, simile a martinfowler.com ?


Esempi di problemi che i pattern potrebbero risolvere:

  • Archiviazione di dati gerarchici (ad es. tabella singola con tipo vs più tabelle con chiave 1: 1 e differenze ...)
  • Memorizzazione dei dati con struttura variabile (ad es. colonne generiche vs xml vs colonna delimitata ...)
  • Denormalizza i dati (come farlo con un impatto minimo, ecc ...)
È stato utile?

Soluzione

C'è un libro nella serie Signature di Martin Fowler chiamato Database di refactoring . Ciò fornisce un elenco di tecniche per il refactoring dei database. Non posso dire di aver sentito così tanto un elenco di modelli di database.

Consiglio vivamente anche Data Model Patterns di David C. Hay e il seguito Una mappa dei metadati che si basa sul primo ed è molto più ambizioso e intrigante. La prefazione da sola è illuminante.

Un altro ottimo posto in cui cercare alcuni modelli di database predefiniti è la serie di libri sulle risorse del modello dati di Len Silverston Volume 1 contiene modelli di dati universalmente applicabili (dipendenti, account, spedizioni, acquisti, ecc.), Volume 2 contiene modelli di dati specifici del settore (contabilità, assistenza sanitaria, ecc.), Volume 3 fornisce modelli di modelli di dati.

Infine, mentre questo libro parla apparentemente di UML e Object Modeling, Modellazione a colori con UML fornisce un "archetipo" processo guidato di modellazione di entità a partire dal presupposto che ci sono 4 archetipi principali di qualsiasi modello di oggetti / dati

Altri suggerimenti

Ecco un link a un gentiluomo che ha sviluppato diverse centinaia di schemi di database gratuiti.

http://www.databaseanswers.org/data_models/

Forse se devi creare un db rapidamente questo ti darà un punto di partenza in termini di tabelle e relazioni in un dato schema. Tieni presente che probabilmente dovrai modificare questo punto di partenza. Ho trovato molto utile.

In secondo luogo, SQL Server Magazine ha una colonna occasionale chiamata " The Data Modeler " che è molto educativo e spesso contiene schemi completi per un determinato sistema.

I modelli di progettazione non sono soluzioni banalmente riutilizzabili.

I motivi di progettazione sono riutilizzabili, per definizione. Sono schemi che tu rilevano in altre buone soluzioni.

Un modello non è banalmente riutilizzabile. Tuttavia, puoi implementare il tuo design down seguendo lo schema.

Gli schemi di progettazione relazionale includono cose come:

  1. Relazioni uno-a-molti (dettaglio principale, padre-figlio) relazioni usando una chiave esterna.

  2. Relazioni Many-to-Many con una tabella bridge.

  3. Relazioni one-to-one opzionali gestite con NULL nella colonna FK.

  4. Schema stellare: dimensione e realtà, design OLAP.

  5. Design OLTP completamente normalizzato.

  6. Più colonne di ricerca indicizzate in una dimensione.

  7. " Tabella di ricerca " che contiene PK, descrizione e valori di codice utilizzati da una o più applicazioni. Perché avere il codice? Non lo so, ma quando devono essere utilizzati, questo è un modo per gestire i codici.

  8. Uni-tavolo. [Alcuni lo definiscono un anti-schema; è uno schema, a volte è cattivo, a volte è buono.] Questo è un tavolo con molte cose pre-unite che violano la seconda e la terza forma normale.

  9. Tabella di array. Questa è una tabella che viola la prima forma normale avendo una matrice o una sequenza di valori nelle colonne.

  10. Database ad uso misto. Questo è un database normalizzato per l'elaborazione delle transazioni ma con molti indici extra per i report e le analisi. È un anti-pattern - non farlo. Le persone lo fanno comunque, quindi è ancora uno schema.

La maggior parte delle persone che progettano database possono facilmente scuotere una mezza dozzina di "È un'altra di quelle"; questi sono modelli di progettazione che usano su base regolare.

E questo non include modelli amministrativi e operativi di utilizzo e gestione.

Dai un'occhiata a questo blog - Il programmatore di database .

Descrive alcuni modelli di database .

I libri di Joe Celko sono eccellenti per questo genere di cose, in particolare "SQL for Smarties". Ha alcune soluzioni innovative a problemi comuni, molti dei quali sono modelli di design riutilizzabili.

http://www.celko.com/books.htm

AskTom è probabilmente la singola risorsa più utile sulle migliori pratiche sui Oracle DB. (Di solito digito " asktom " come prima parola di una query google su un argomento particolare)

Non penso sia davvero appropriato parlare di schemi di progettazione con database relazionali. I database relazionali sono già l'applicazione di un "modello di progettazione" a un problema (il problema è "come rappresentare, archiviare e lavorare con i dati mantenendo la sua integrità" e la progettazione è il modello relazionale). Altri approcci (generalmente considerati obsoleti) sono i modelli di Navigazione e Gerarchici (e sono sicuro che ne esistono molti altri).

Detto questo, potresti considerare " Data Warehousing " come un "modello" alquanto separato o approccio nella progettazione di database. In particolare, potresti essere interessato a leggere le Schema a stella .

Dopo molti anni di sviluppo del database posso dire che non ci sono problemi e alcune domande alle quali dovresti rispondere prima di iniziare:

domande:

  • Vuoi utilizzare in futuro un altro DBMS? In caso affermativo, allora non utilizza oggetti speciali SQL del DBMS corrente. Rimuovi la logica dalla tua applicazione.

Non utilizza:

  • spazi bianchi nei nomi delle tabelle e dei nomi delle colonne
  • Caratteri non Ascii nei nomi di tabelle e colonne
  • vincolante per una specifica minuscola o maiuscola. E non usare mai 2 tabelle o colonne che differiscono solo per le lettere minuscole e maiuscole.
  • non utilizza parole chiave SQL per nomi di tabelle o colonne come " FROM " ;, " TRA " ;, " DELETE " ;, etc

recomendations:

  • Utilizza NVARCHAR o equivalenti per il supporto Unicode quindi non avrai problemi con le tabelle codici.
  • Assegna a ogni colonna un nome univoco. Ciò semplifica il join per selezionare la colonna. È molto difficile se ogni tabella ha una colonna "ID" o " Nome " o " Descrizione " ;. Usa XyzID e AbcID.
  • Utilizza un pacchetto di risorse o uguale a espressioni SQL complesse. Rende più semplice il passaggio a un altro DBMS.
  • Non esegue il cast rigido su nessun tipo di dati. Un altro DBMS non può avere questo tipo di dati. Per esempio, Oracle daes non ha un PICCOLO solo un numero.

Spero che questo sia un buon punto di partenza.

La tua domanda è un po 'vaga, ma suppongo che UPSERT potrebbe essere considerato un modello di progettazione. Per le lingue che non implementano MERGE , un certo numero di alternative per risolvere il problema (se esiste una riga adatta, AGGIORNAMENTO ; in caso contrario INSERT )

Dipende da cosa intendi per modello. Se stai pensando a Persona / Azienda / Transazione / Prodotto e simili, allora sì - ci sono già molti schemi di database generici disponibili.

Se stai pensando a Factory, Singleton ... allora no - non hai bisogno di nessuno di questi in quanto sono di livello troppo basso per la programmazione DB.

Se stai pensando alla denominazione degli oggetti del database, rientra nella categoria delle convenzioni, non nella progettazione in sé.

BTW, S.Lott, relazioni uno-a-molti e molti-a-molti non sono "schemi". Sono i mattoni di base del modello relazionale.

Questo libro sembra interessante

Title: Data Patterns
By: Microsoft Corporation
Publisher: Microsoft Press
Pub. Date: December 21, 2004
Print ISBN-13: 978-0-7356-2200-5
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top