Conception des bases de données SOLID

Introduction

Chris Travers

Traducteur

GaÃ«l YIMEN YIMGA

Cet article est le premier d'une série d'articles rédigés par Chris Travers. Il présente le modèle de conception SOLID de bases de données. L'auteur essaye de par ces articles de comparer l'application des principes SOLID aux applications orientées objet et l'application de ces mêmes principes aux bases de données relationnelles. Chris Travers est un blogueur très actif et nous avons souhaité partager avec la communauté francophone ses contributions afin que chacun en tire profit.

Commentez . ♪

- Titre : Conception des bases de données SOLID

- Auteur : Chris Travers

- Traducteur : GaÃ«l YIMEN YIMGA

- Parution : 2 septembre 2014

- Mise à jour : 11 septembre 2014

- Licence : Copyright ® 2013 Chris Travers - Developpez. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Introduction

- II. Remerciements

- III. Conception des bases de données SOLID

I - Introduction

L'approche de conception SOLID est constituée d'un ensemble de principes développés en programmation orientée objet. Cette série d'articles qui commence par celui-ci explorera en profondeur l'applicabilité des principes SOLID aux bases de données relationnel-objet et comparera la façon de mettre en œuvre ces principes dans les bases de données et la façon avec laquelle ces principes se manifestent dans les couches applicatives.

Vous ne pouvez pas concevoir une base de données de la même façon que vous concevez une application. Une base de données fournit principalement deux fonctionnalités : un métaespace de persistance et un modèle d'information dérivé de cet espace. Le modèle de consistance ACID limite le type de programmation que vous pouvez raisonnablement effectuer sur une base de données. En effet, c'est une mauvaise idée de combiner les effets transactionnels et non transactionnels.

Pour un modèle d'information, l'approche utilisée pour appliquer ces principes est différente. Une façon de penser est que si nous pouvons voir la conception orientée objet comme un triangle, l'application de ces principes à une base de données requiert de tourner le triangle en présentant sa base vers le haut pour que l'application à développer repose dessus.

Cette série d'articles traitera de l'application des principes SOLID à la conception des bases de données relationnel-objet, en comparant la façon dont ces principes sont utilisés pour le développement logiciel. De nombreux aspects du modèle relationnel interviennent dans ces sujets, un aspect propose une mixture différente (du modèle relationnel) tandis qu'un autre aspect met en avant une conception purement orientée objet.

En général, cette série considérera les relations comme des ensembles d'objets plutôt que comme des ensembles de tuples (enregistrement dans une base de données relationnelle). La question à se poser est comment définir les structures de données et les interfaces telles que nous puissions créer un pont entre le monde relationnel et le monde objet. Les principes SOLID constituent un bon point de départ.

Bienvenue dans cette série d'articles. J'espère que vous l'apprécierez.

II - Remerciements

Nous remercions, Chris Travers, de nous avoir aimablement autorisés à publier son article. Nous remercions particulièrement Alassane Diakité et Deepin qui ont bien voulu que cette série d'articles soit publiée sur www.developpez.com. Nous tenons à remercier également f-leb qui malgré ses multiples occupations a sacrifié de son temps pour relire cet article. Et enfin Lana Bauer pour sa disponibilité constante dans le suivi pour la publication de ce chef d'œuvre.

III - Conception des bases de données SOLID

Retrouvez toute la série « Conception des bases de données SOLID » :

1- Introduction

2- Responsabilité unique et normalisation

3- Le principe d'Ouverture/Fermeture (à suivre)

4- La substitution de Liskov (à suivre)

5- La ségrégation des interfaces ou garder les procédures stockées simples (à suivre)

6- Inversion de dépendances et interfaces robustes de bases de données (à suivre)