IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Cours complet pour apprendre les différents types de bases de données et le langage SQL
Par Jacques Le Maitre

Le , par Community Management

48PARTAGES

15  2 
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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 28/11/2017 à 9:03
Citation Envoyé par Luc Orient Voir le message
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 +
6  0 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 03/04/2017 à 12:43
Citation Envoyé par razoredzez Voir le message
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 +
6  1 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 31/03/2017 à 14:22
Et il propose de faire les jointures.... devinez dans quelle clause... ? Dans le W.... !

A +
4  1 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 05/04/2017 à 11:24
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 +
5  2 
Avatar de al1_24
Modérateur https://www.developpez.com
Le 30/03/2017 à 23:49
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.
2  0 
Avatar de StringBuilder
Expert éminent https://www.developpez.com
Le 28/11/2017 à 20:33
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...
2  0 
Avatar de fsmrel
Expert éminent sénior https://www.developpez.com
Le 27/03/2023 à 17:05
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.
3  1 
Avatar de CinePhil
Modérateur https://www.developpez.com
Le 28/11/2017 à 21:53
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 !
1  0 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 29/03/2023 à 12:38
Citation Envoyé par fsmrel Voir le message
...

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 +
1  0 
Avatar de SQLpro
Rédacteur https://www.developpez.com
Le 03/05/2023 à 17:28
Citation Envoyé par fsmrel Voir le message
...
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 !

Citation Envoyé par fsmrel
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...

Citation Envoyé par fsmrel
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)


Citation Envoyé par fsmrel
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...).

Citation Envoyé par fsmrel
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
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 +
1  0