Discussion :

[Community Management]

Chers membres du club,

J'ai le plaisir de vous présenter ce cours complet pour apprendre les différents types de bases de données et le langage SQL.

Il s'agit d'un cours complet sur les types de bases de données. Vous allez apprendre les différents modèles de conception d'une base de données et l'écriture de requêtes avec SQL.
...
Une base de données (BD) est un ensemble d'informations archivées dans des mémoires accessibles à des ordinateurs en vue de permettre le traitement des diverses applications prévues pour elles.

Bonne lecture et n'hésitez pas à apporter vos commentaires


Retrouvez les meilleurs cours et tutoriels pour apprendre les systèmes de gestion de bases de données et SQL

[Daniel Josue]

Merci pour la publication de ce cours

[Traroth2]

Je suis un peu surpris de l'absence des bases NoSQL (SGBD orientés documents, graphe, en colonne, etc), et aussi de l'absence de la plus grosse évolution depuis longtemps dans ce domaine, la blockchain.

[al1_24]

Ce document n'est pas récent, si l'on en juge cet extrait :

Il (le langage SQL) a depuis fait l'objet de plusieurs normes dont la plus récente est SQL-1992, qui est implantée plus ou moins complètement par tous les SGBD relationnels actuellement disponibles.
Une nouvelle norme SQL:1999 a vu le jour, qui concerne les SGBD objet-relationnels.

D'où l'absence du NoSQL et d'autres nouveautés.

[SQLpro]

Et il propose de faire les jointures.... devinez dans quelle clause... ? Dans le W.... !

A +

[razoredzez]

C'etait mon professeur à la faculté de science à la garde.

[SQLpro]

C'etait mon professeur à la faculté de science à la garde.

il serait temps qu'il se recycle... Quel age as t-il ? Parce que les jointures se font avec lopérateur JOIN / ON qui date de 1992 (norme SQL) et non pas dans le WHERE. Or dans son ouvrage visiblement obsolète, il ne parle que des jointures avec WHERE !

Il ne faut alors pas s'étonner que les étudiants soient nullissimes lorsqu'ils sortent d'un tel cours... Cela dit, cela m'arrange plutôt, comme ça il font de la merde en entreprise, merde qu'il faut ensuite rectifié grâce à de juteuses prestations d'audit !!!

A +

[Luc Orient]

il serait temps qu'il se recycle... Quel age as t-il ? Parce que les jointures se font avec lopérateur JOIN / ON qui date de 1992 (norme SQL) et non pas dans le WHERE. Or dans son ouvrage visiblement obsolète, il ne parle que des jointures avec WHERE ! ...

Déjà, faudrait lire la totalité du document :

VII-G-11 - Opérateurs de jointure dans la clause FROM
Q26. Donner le prénom, le nom et le nom du sommet pour chaque grimpeur ayant réalisé la 1re ascension d'un
sommet de plus de 8000 m de l'Inde ?
1. SELECT prénom_grimpeur, nom_grimpeur, nom_sommet
2. FROM ascension NATURAL INNER JOIN localisation
3. WHERE pays = 'Inde';

En plus, les jointures internes se font aussi bien avec l'operateur WHERE que avec l'opérateur JOIN, c'est comme on veut et le résultat est le même.

Il y a de nombreux fils à ce sujet sur les différents forums concernés.

[SQLpro]

je suis désolé, mais :
1) à l'entrée SQL jointure (§ VII-G-3) ne sont présenté que les jointures dans la clause WHERE, mais pas l'opérateur JOIN, ni même les jointures externes !
2) cette ancienne technique de jointure datant d'avant la norme de 1992 est en fait un produit cartésien suivi d'une restriction du point de vue logique. Cela n'a donc conceptuellement rien à voir avec l'opération de jointure de l'algèbre relationnelle et n'est valable que pour le cas de la jointure interne.

Il y a d'autres choses qui sont fausse, par exemple l'auteur présente l'ordre REPLACE qui n'existe pas dans la norme SQL au lieu de l'ordre UPDATE (voir § VII-C. Panorama des commandes SQL).
Il présente les synonymes qui n'existe pas dans le SQL (c'est une invention d'Oracle pour pallier au défaut de nom trop court).

A +

[cleray.fr]

il serait temps qu'il se recycle... Quel age as t-il ? Parce que les jointures se font avec lopérateur JOIN / ON qui date de 1992 (norme SQL) et non pas dans le WHERE. Or dans son ouvrage visiblement obsolète, il ne parle que des jointures avec WHERE !

Il ne faut alors pas s'étonner que les étudiants soient nullissimes lorsqu'ils sortent d'un tel cours... Cela dit, cela m'arrange plutôt, comme ça il font de la merde en entreprise, merde qu'il faut ensuite rectifié grâce à de juteuses prestations d'audit !!!

A +

JOIN ou WHERE, une jointure reste une jointure, pas de grosses révolutions de ce coté là.

Je suis allé voir, votre cours, il n'a rien à envier à celui que vous critiquez, en particulier pour tout ce qui concerne les transactions concurrentes,
vous ne parlez pas du modèle multiversion (MVCC).

[SQLpro]

Déjà, faudrait lire la totalité du document ...

Luc, tu cites le NATURAL JOIN qui est considéré comme obsolète depuis des lustres par la norme SQL et qui a causé des ravages en implémentation !!!!

A +

[StringBuilder]

Tiens, je savais pas que NATURAL JOIN était deprecated.
C'est une très bonne chose ! Car en effet, c'est le meilleur moyen pour que le même code ne donne pas le même résultat dans le temps... aussi dangereux qu'un "select *"

Le plus marrant, c'est que des profs aujourd'hui encore n'apprennent à leurs élève QUE cet opérateur !

Et après moi je découpe mes stagiaires à la hache...

[CinePhil]

Le plus marrant, c'est que des profs aujourd'hui encore n'apprennent à leurs élève QUE cet opérateur !

Il encore un ou deux ans, on voyait quasi-systématiquement la jointure à l'ancienne FROM liste, de, tables WHERE conditions de jointures dans les message des forums de DVP. Je constate que depuis quelques temps que je suis redevenu plus présent sur DVP, c'est beaucoup moins fréquent. Il semble que les profs se soient enfin mis à la norme de 1992 et enseignent l'opérateur JOIN. Ouf !

[fsmrel]

Bonjour,

Je viens seulement de découvrir ce cours. Quelques remarques de ma part concernant quelques paragraphes :

III-C - Une entité est identifiée par sa clé

Non. Une entité-type du MCD a un identifiant. Le concept de clé n’apparaît qu’à partir du MLD.

III-E - on considérera que ces valeurs sont atomiques (comme dans le modèle relationnel)

Concernant le MRD (modèle relationnel de données), vous avez tort. Pour Codd, père du MRD, l'atomicité se définit par rapport au SGBD.
Par la suite, le concept d'atomicité a été carrément évacué du MRD, puisque source de confusion et inessentiel.

III-F - Il n'existe pas d'autre association de A associant les entités e1, …, en.

Que signifie cette phrase ?
Quoi qu’il en soit deux entités-types E1 et E2 peuvent très bien être mises en relation par plus d’une association. Exemple :

IV-B-2-a - Schéma d'une relation

Il faudrait parler d’en-tête aussi bien pour une variable relationnelle que pour une relation (valeur). Dans les années 1970-1980, le terme relation était malheureusement utilisé pour désigner aussi bien une variable qu’une valeur. Depuis au moins 30 ans, le distinguo variable/valeur existe !  

A cet effet, je cite l’ouvrage de C. J. Date, héraut incontesté et iinlasable du modèle relationnel de données, Relational Database Writings 1991-1994, page 314 :

« A relation variable―relvar for short―of type H is a variable whose permitted values are relations with a specified relation heading H, the declared heading for that relvar. »

IV-B-2-e - Valeurs nulles.

NULL n'est pas une valeur ! mais une marque indiquant l’absence d’information (donc de valeur).

IV-B-2-f – Constituant

Dans le modèle relationnel de données, on parle plutôt de projection.

IV-B-2-g - Les entités sont identifiées au travers des clés primaires

C’est du SQL ! En relationnel on parle de clés candidates.

IV-B-2-g-ii – Un constituant Y d'une relation R1 est une clé étrangère de R1 s'il existe une relation R2 possédant une clé primaire X et que Y a pour domaine l'ensemble des valeurs de X.

En relationnel, Une clé étrangère de R1 peut référencer une clé primaire ou une clé alternative de R2 (même SQL permet cela).

IV-B-3 - soit existe comme valeur de la clé primaire d'un n-uplet de la relation que Y réfère,
soit est nulle.

Même remarque qu’en IV-B-2-g-ii. Par ailleurs, en relationnel une clé étrangère ne peut pas être marquée NULL.

VII-A - Le langage SQL est la version commercialisée du langage SEQUEL du prototype System R développé à IBM San José à partir de 1975.

En fait, il faut remonter à 1974, année de la publication de l’article de Chamberlin et Boyce : SEQUEL: A structured English query language

VII-E – Création de domaine

L’instruction Create Domain existait déjà dans la norme SQL/92, mais elle est absente dans les SGBD qui lui préfèrent Create Type.

Exemples

PostgreSQL :

CREATE TYPE Jour
AS ENUM ('lundi', 'mardi', 'mercredi', 'jeudi', 'vendredi', 'samedi', 'dimanche');

SQL Server :

CREATE RULE Jours_de_la_semaine_rule
AS
@list IN ('lundi', 'mardi', 'mercredi', 'jeudi', 'vendredi', 'samedi', 'dimanche');
go
CREATE TYPE Jour FROM VARCHAR(10) ;
go
sp_bindrule 'Jours_de_la_semaine_rule', 'Jour' ;
go

DB2 :

CREATE TYPE Jour AS VARCHAR(10) ARRAY[7] ;
SET Jour = ARRAY['lundi', 'mardi', 'mercredi', 'jeudi', 'vendredi', 'samedi', 'dimanche'];

Etc.

VIII-D-4 - Relativement aux dépendances fonctionnelles, on distingue quatre formes normales

• la 1re forme normale ;
• la 2e forme normale ;
• la 3e forme normale ;
• la forme normale de Boyce-Codd qui est la plus aboutie.

LA 1NF n'a rien à voir avec les DF ! seulement avec le type des attributs. A nouveau je fais référence à C. J. Date :

Let relation r have attributes A1, ..., An, of types T1, ..., Tn, respectively. Then r is in first normal form (1NF) if and only if, for all tuples t appearing in r, the value of attribute Ai in t is of type Ti (i = 1, ..., n).

Attention, une relation est bien ici une valeur de relvar.

VIII-D-4-b - Une relation est en 1re forme normale si tous ses attributs ont une valeur atomique.

Je rappelle une fois de plus que depuis des lustres, l'atomicité a été évacuée du modèle relationnel de données.

VIII-D-4-C – 2e forme normale

La 2NF n’implique pas uniquement la clé primaire, mais chaque clé candidate.


Paragraphes IX, X et XI – Aspects physiques

Paragraphes intéressants du point de vue de la culture générale, mais au-delà il est indispensable de se reporter à la documentation de son SGBD.

[SQLpro]

JOIN ou WHERE, une jointure reste une jointure, pas de grosses révolutions de ce coté là.

Je suis allé voir, votre cours, il n'a rien à envier à celui que vous critiquez, en particulier pour tout ce qui concerne les transactions concurrentes,
vous ne parlez pas du modèle multiversion (MVCC).

Cela est parfaitement normal. Mon cours est basé sur la norme du langage SQL qui n'exprime que le niveau logique, pas le niveau physique, donc pas le verrouillage ! Le MVCC c'est du verrouillage et en plus c'est totalement hors norme, car la norme stipule que les données doivent être "live" ce que le verrouillage optimiste ne permet pas...

A +

[SQLpro]

...

L’instruction Create Domain existait déjà dans la norme SQL/92, mais elle est absente dans les SGBD qui lui préfèrent Create Type.

Exemples

PostgreSQL :

CREATE TYPE Jour
AS ENUM ('lundi', 'mardi', 'mercredi', 'jeudi', 'vendredi', 'samedi', 'dimanche');

...

PostGreSQL possède bien le CREATE DOMAIN...

https://www.postgresql.org/docs/curr...atedomain.html

(pour une fois que je défends PG !!!)

A +

[fsmrel]

pour une fois que je défends PG !!!

Dont acte


Pour revenir sur le code :

CREATE RULE Jours_de_la_semaine_rule
AS
@list IN ('lundi', 'mardi', 'mercredi', 'jeudi', 'vendredi', 'samedi', 'dimanche');
go
CREATE TYPE Jour FROM VARCHAR(10) ;
go
sp_bindrule 'Jours_de_la_semaine_rule', 'Jour' ;
go

Je viens de voir dans ton ouvrage SQL Server 2014 (Editions Eyrolles) que l’instruction CREATE RULE, en association avec sp_bindrule devenait obsolète. Soit. Quelle est l’alternative si je dois m’en passer ? Si ma base de données comporte de nombreuses tables faisant référence au type Jour, comment faire pour ne pas régresser, éviter d’avoir à recopier la contrainte dans chaque CREATE TABLE (donc maintenir une redondance toujours source d’erreurs ?)

Je note que l’instruction CREATE TYPE ne comporte pas de contrainte CHECK. Est-ce par allégeance à la norme SQL ? En tout cas, en l’absence de sp_bindrule, cette instruction devient d’un intérêt epsilonesque, d’autant que le type qu’on crée (qualifié de sous-type) doit faire uniquement référence à un type de base SQL (INTEGER, etc.) ce qui est pour le moins réducteur et trivial (bref, sans intérêt). On est bien loin de ce que propose Tutorial D, cf. Databases, Types, and The Relational Model: The Third Manifesto, voyez page 181 et suivantes, RM Prescription 23: Integrity Constraints. L’exemple du type POINT est caractéristique...

[SQLpro]

...
Je viens de voir dans ton ouvrage SQL Server 2014 (Editions Eyrolles) que l’instruction CREATE RULE, en association avec sp_bindrule devenait obsolète. Soit. Quelle est l’alternative si je dois m’en passer ?

Aucune et j'en suis fort marrie !

Si ma base de données comporte de nombreuses tables faisant référence au type Jour, comment faire pour ne pas régresser, éviter d’avoir à recopier la contrainte dans chaque CREATE TABLE (donc maintenir une redondance toujours source d’erreurs ?)

Utiliser un outil de conception qui le fait à ta place comme AMC Designor / Power Designer...

Je note que l’instruction CREATE TYPE ne comporte pas de contrainte CHECK. Est-ce par allégeance à la norme SQL ?

Normal car elle a été créée il y a fort longtemps du temps de Sybase (années 80/90) et c'est bien la procédure sp_bindrule qui permettait de faire l'équivalent d'une contraintes CHECK... Or le CREATE TYPE de la norme ce n'est pas tout à fait le CREATE DOMAIN... MS a donc abandonné le CREATE DOMAINE pour se consacrer à une réelle création de NOUVEAUX types, types objets d'ailleurs, mais implémenté en .net (C# ou autre...).
Le CREATE TYPE sert donc depuis à :

• créer des pseudos domaines dépourvues de contraintes et de valeur par défaut
• créer des types exotiques (tableaux, matrices, collections...) en langage objet
• créer des types table (en Transact SQL)

En tout cas, en l’absence de sp_bindrule, cette instruction devient d’un intérêt epsilonesque, d’autant que le type qu’on crée (qualifié de sous-type) doit faire uniquement référence à un type de base SQL (INTEGER, etc.) ce qui est pour le moins réducteur et trivial (bref, sans intérêt).

Et bien non justement... Il est réellement adapté au CREATE TYPE et le CREATE DOMAIN a été plus ou moins abandonné (il n'existe d'ailleurs pas dans Oracle...).

On est bien loin de ce que propose Tutorial D, cf. Databases, Types, and The Relational Model: The Third Manifesto, voyez page 181 et suivantes, RM Prescription 23: Integrity Constraints. L’exemple du type POINT est caractéristique...

Comme Oracle, SQL Server ne l'a pas fait en SQL, mais dans un langage objet hote plus propice au codage des objets complexes... un exemple :
https://www.mssqltips.com/sqlservert...defined-types/

Sache que divers types intégrés à SQL Server travaillent directement en C# (.net) sans le dire :

• XML
• GEOMETRY
• GEOGRAPHY
• hierarchid

Un petit exemple qui fait rire... Tentative de créer un point à la volée (et partant en erreur, car un point c'est juste 2 coordonnées, 3 avec z) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT CAST('POINT(1 3 5 7 9)' AS GEOMETRY)

Msg*6522, Niveau*16, État*1, Ligne*1
Une erreur .NET Framework s'est produite au cours de l'exécution de la routine ou de la fonction d'agrégation définie par l'utilisateur "geometry"*:
System.FormatException: 24142*: «*)*» était attendu à la position 14. L'entrée contient «*9*».
System.FormatException:
à Microsoft.SqlServer.Types.WellKnownTextReader.RecognizeToken(Char token)
à Microsoft.SqlServer.Types.WellKnownTextReader.ParsePointText(Boolean parseParentheses)
à Microsoft.SqlServer.Types.WellKnownTextReader.ParseTaggedText(OpenGisType type)
à Microsoft.SqlServer.Types.WellKnownTextReader.Read(OpenGisType type, Int32 srid)
à Microsoft.SqlServer.Types.SqlGeometry.GeometryFromText(OpenGisType type, SqlChars text, Int32 srid)
à Microsoft.SqlServer.Types.SqlGeometry.Parse(SqlString s)

A +

[fsmrel]

Ave,

Utiliser un outil de conception qui le fait à ta place comme AMC Designor / Power Designer.

Je n’ai que la version 15 de power AMC, mais on va faire avec.

Je reprends l’exemple traditionnel de Codd et Date et l’adapte POUR AMC :


L’attribut City des tables S et P va faire référence au domaine Ville, doté de contrôles supplémentaires :



Bien entendu, AMC génère le code avec sp_bindrule :

if exists(select 1 from systypes where name='VILLE')
   execute sp_unbindrule VILLE

if exists(select 1 from systypes where name='VILLE')
   drop type VILLE

if exists (select 1 from sysobjects where id=object_id('R_VILLE') and type='R')
   drop rule  R_VILLE

create rule R_VILLE as
      "Paris", "Albi", "Caen"

/*==============================================================*/
/* Domaine : VILLE                                              */
/*==============================================================*/
create type VILLE
   from varchar(24)

execute sp_bindrule R_VILLE, VILLE

Je suis refait puisque, pour ne plus utiliser sp_bindrule, il va falloir que je déclare la même contrainte CHECK pour chaque table faisant référence au type VILLE. C’est comme si en programmation, on me disait : les sous-programmes c’est fini...

MS a donc abandonné le CREATE DOMAINE pour se consacrer à une réelle création de NOUVEAUX types, types objets d'ailleurs, mais implémenté en .net (C# ou autre...).
Le CREATE TYPE sert donc depuis à :
créer des pseudos domaines dépourvues de contraintes et de valeur par défaut
créer des types exotiques (tableaux, matrices, collections...) en langage objet
créer des types table (en Transact SQL)

Ça me fait une belle jambe... Pour assurer les contrôles anciennement effectués par sp_bindrule, à part déclarer la même contrainte CHECK pour chaque table faisant référence au type VILLE, je devrais donc devoir maintenant utiliser un langage autre que SQL, et ça c’est une régression à laquelle je ne peux souscrire.

[SQLpro]

Ave,

Je n’ai que la version 15 de power AMC, mais on va faire avec.

Ben oui, mais la version 15 s'est arrêté avec SQL Server 2008 , dans lequel les sp_bindrule etc on été considéré comme obsolète.... Utilise la dernière version ou bien modifie le driver...

A +