L'algèbre relationnelle est basée sur la théorie des ensembles et est à la base de la logique de la base de données.
Lorsque je n'étudiais que la structure des bases de données et SQL, une connaissance préliminaire de l'algèbre relationnelle m'a aidé à approfondir mes connaissances pour bien comprendre, et je vais essayer de faire en sorte que cet article ait un effet similaire.

Donc si vous allez commencer vos études dans ce domaine ou que vous venez de vous intéresser, s'il vous plaît, sous cat.

Base de données relationnelle

Pour commencer, nous allons introduire le concept de base de données relationnelle, dans laquelle nous effectuerons toutes les actions.

Une base de données relationnelle est un ensemble de relations qui contiennent toutes les informations qui doivent être stockées dans la base de données. Dans cette définition, nous nous intéressons au terme relation, mais pour l'instant nous le laisserons sans définition stricte.
Imaginons mieux un tableau de produits.

tableau PRODUITS

identifiant	NOM	ENTREPRISE	LE PRIX
123	Biscuits	LLC "Le côté obscur"	190
156	Thé	LLC "Le côté obscur"	60
235	Ananas	JSC "Fruits"	100
623	Tomates	LLC "Légumes"	130

Le tableau se compose de 4 lignes, une ligne dans le tableau est un tuple en théorie relationnelle. L'ensemble des tuples ordonnés est appelé une relation.
Avant de définir une relation, introduisons un autre terme - domaine. Les domaines par rapport à une table sont des colonnes.

Pour plus de clarté, nous introduisons maintenant une définition stricte d'une relation.

Soit N ensembles D1, D2,… donnés. Dn (domaines), la relation R sur ces ensembles est l'ensemble des N-uplets ordonnés de la forme où d1 appartient à D1 et ainsi de suite. Les ensembles D1, D2, .. Dn sont appelés domaines de la relation R.
Chaque élément du tuple représente la valeur de l'un des attributs correspondant à l'un des domaines.

Les clés d'une relation

En ce qui concerne l'exigence est que tous les tuples doivent être différents. Une clé primaire existe pour identifier de manière unique un tuple. Une clé primaire est un attribut, ou un ensemble d'un nombre minimum d'attributs, qui identifie de manière unique un tuple particulier et ne contient pas d'attributs supplémentaires.
L'implication est que tous les attributs de la clé primaire doivent être nécessaires et suffisants pour identifier un tuple particulier, et exclure l'un des attributs de la clé le rendrait insuffisant pour l'identification.
Par exemple, dans une telle table, la clé sera une combinaison d'attributs des première et deuxième colonnes.

tableau des PILOTES

On peut voir qu'une organisation peut avoir plusieurs pilotes, et afin d'identifier de manière unique un pilote, la valeur de la colonne "Nom de l'organisation" et celle du "Nom du pilote" sont requises. Une telle clé est appelée clé composite.

Dans une base de données relationnelle, les tables sont interconnectées et se rapportent les unes aux autres en tant que maître et subordonné. La relation entre les tables maître et subordonnée s'effectue via la clé primaire de la table principale et la clé étrangère de la table subordonnée.
Une clé étrangère est un attribut ou un ensemble d'attributs qui est la clé primaire dans la table principale.

Cette théorie préparatoire sera suffisante pour vous familiariser avec les opérations de base de l'algèbre relationnelle.

Opérations d'algèbre relationnelle

Les huit opérations principales de l'algèbre relationnelle ont été proposées par E. Codd.

• syndicat
• Traversée
• Soustraction
• produit cartésien
• Échantillon
• Projection
• Composé
• Division

La première moitié des opérations est similaire aux mêmes opérations sur les ensembles. Certaines opérations peuvent être exprimées par d'autres opérations. Considérons la plupart des opérations avec des exemples.

Pour la compréhension, il est important de se rappeler que le résultat de toute opération d'algèbre sur des relations est une autre relation, qui peut alors également être utilisée dans d'autres opérations.
Créons une autre table, qui nous sera utile dans les exemples.

tableau VENDEURS

identifiant	VENDEUR
123	OOO "Fléchette"
156	OJSC "Seau"
235	JSC "Baza aux légumes"
623	JSC "Ferme"

Convenons que dans cette table ID se trouve une clé étrangère associée à la clé primaire de la table PRODUCTS.

Commençons par examiner l'opération la plus simple - le nom de la relation. Son résultat sera la même relation, c'est-à-dire qu'en effectuant l'opération PRODUITS, nous obtiendrons une copie de la relation PRODUITS.

Projection

La projection est une opération dans laquelle les attributs de la relation sont sélectionnés uniquement dans les domaines spécifiés, c'est-à-dire que seules les colonnes nécessaires sont sélectionnées dans la table, et si plusieurs tuples identiques sont obtenus, alors une seule instance d'un tel tuple reste dans le relation résultante.
Par exemple, faisons une projection sur la table PRODUITS en y sélectionnant ID et PRIX.

Syntaxe de l'opération :
(ID, PRIX) PRODUITS

Dans la condition de sélection, nous pouvons utiliser n'importe quelle expression logique. Faisons un autre échantillon avec un prix supérieur à 90 et un ID de produit inférieur à 300 :

σ (PRIX> 90 ^ ID<300) PRODUCTS

Multiplication

La multiplication ou produit cartésien est une opération effectuée sur deux relations, à la suite de laquelle nous obtenons une relation avec tous les domaines à partir de deux relations initiales. Les tuples dans ces domaines représenteront toutes les combinaisons possibles de tuples de la relation initiale. Un exemple le rendra plus clair.

Prenons les produits cartésiens des tables PRODUITS et VENDEURS.
Syntaxe de l'opération :

PRODUITS × VENDEURS
Vous remarquerez que ces deux tables ont le même ID de domaine. Dans cette situation, les domaines portant le même nom sont préfixés par le nom de la relation correspondante, comme indiqué ci-dessous.
Par souci de concision, nous multiplions non pas les relations complètes, mais les échantillons avec l'ID de condition<235

(les mêmes tuples sont surlignés en couleur)

PRODUITS.ID	NOM	ENTREPRISE	LE PRIX	VENDEURS.ID	VENDEUR
123	Biscuits	LLC "Le côté obscur"	190	123	OOO "Fléchette"
156	Thé	LLC "Le côté obscur"	60	156	OJSC "Seau"
123	Biscuits	LLC "Le côté obscur"	190	156	OJSC "Seau"
156	Thé	LLC "Le côté obscur"	60	123	OOO "Fléchette"

Pour un exemple d'utilisation de cette opération, imaginons la nécessité de sélectionner des vendeurs avec des prix inférieurs à 90. Sans produit, il faudrait d'abord récupérer les identifiants des produits du premier tableau, puis utiliser ces identifiants du deuxième tableau pour obtenir les noms de VENDEUR nécessaires, et en utilisant le produit, il y aura la requête suivante :

π (VENDEUR) σ (RODUCTS.ID = SELLERS.ID ^ PRIX<90) PRODUCTS × SELLERS

A la suite de cette opération, on obtient la relation :

VENDEUR

OJSC "Seau"

Collage et collage naturel

L'opération de jointure est à l'opposé de l'opération de projection et crée une nouvelle relation à partir de deux relations existantes. La nouvelle relation est obtenue en concaténant les tuples des première et deuxième relations, et les relations dans lesquelles les valeurs des attributs donnés coïncident sont concaténées. En particulier, si vous joignez les relations PRODUITS et VENDEURS, ces attributs sont les attributs des domaines ID.

Aussi, pour plus de clarté, vous pouvez imaginer la connexion comme le résultat de deux opérations. Tout d'abord, le produit des tables d'origine est pris, puis nous effectuons une sélection à partir de la relation résultante avec la condition d'égalité des attributs des mêmes domaines. Dans ce cas, la condition est l'égalité de PRODUCTS.ID et SELLERS.ID.

Essayons de connecter les relations PRODUITS et VENDEURS et obtenons la relation.

PRODUITS.ID	NOM	ENTREPRISE	LE PRIX	VENDEURS.ID	VENDEUR
123	Biscuits	LLC "Le côté obscur"	190	123	OOO "Fléchette"
156	Thé	LLC "Le côté obscur"	60	156	OJSC "Seau"
235	Ananas	JSC "Fruits"	100	235	JSC "Baza aux légumes"
623	Tomates	LLC "Légumes"	130	623	JSC "Ferme"

Une jointure naturelle reçoit une relation similaire, mais si nous avons un schéma correctement configuré dans la base de données (dans ce cas, la clé primaire de la table ID PRODUITS est liée à la clé étrangère de la table ID SELLERS), alors la relation résultante reste un domaine d'identification.

Syntaxe de l'opération :
PRODUITS VENDEURS;

Vous obtenez cette attitude :

PRODUITS.ID	NOM	ENTREPRISE	LE PRIX	VENDEUR
123	Biscuits	LLC "Le côté obscur"	190	OOO "Fléchette"
156	Thé	LLC "Le côté obscur"	60	OJSC "Seau"
235	Ananas	JSC "Fruits"	100	JSC "Baza aux légumes"
623	Tomates	LLC "Légumes"	130	JSC "Ferme"

Intersection et soustraction.

Le résultat de l'opération d'intersection sera une relation composée de tuples qui sont complètement inclus dans les deux relations.
Le résultat de la soustraction est une relation constituée de tuples qui sont des tuples de la première relation et non des tuples de la seconde relation.
Ces opérations sont similaires aux mêmes opérations sur les ensembles, je pense donc qu'il n'est pas nécessaire de les décrire en détail.

Sources d'information

• Principes de base de l'utilisation et de la conception de bases de données - V. M. Ilyushechkin
• cours magistral Introduction aux bases de données - Jennifer Widom, Stanford University

Je serais reconnaissant pour des commentaires bien motivés.

La base de données (DB) est un ensemble organisé de données. L'organisation des données est généralement destinée à refléter la relation réelle entre les données stockées de manière à faciliter le traitement de ces informations.

SGBD - les systèmes de gestion de bases de données sont des logiciels spécialisés conçus, comme prévu, pour gérer les bases de données. Ceci est réalisé en interagissant avec l'utilisateur d'une part et avec la base de données elle-même d'autre part.

Un SGBD à usage général doit être capable de définir, créer, modifier, administrer et interroger la base de données.

Des exemples de SGBD incluent des packages bien connus tels que

• MySQL
• PostgreSQL
• Serveur Microsoft SQL
• Oracle
• IBM DB2
• Microsoft Access
• SQLite

Les bases de données ne sont généralement pas portables entre différents SGBD, mais l'interopérabilité entre les SGBD (et avec des logiciels personnalisés) est possible en utilisant différentes normes telles que SQL, ODBC ou JDBC.

Les SGBD sont souvent classés en fonction du modèle de données qu'ils prennent en charge. Depuis les années 1980, pratiquement tous les SGBD populaires ont pris en charge le modèle de données relationnelles représenté par la norme de langage de requête SQL (bien que NoSQL ait gagné en popularité ces dernières années).

Ainsi, les principales tâches effectuées par le SGBD comprennent

Définition d'un schéma de données Création, modification et suppression de structures qui déterminent l'organisation de toutes les autres données de la base de données Modification des données Ajout, modification et suppression des données elles-mêmes Récupération des données Fourniture d'informations sous une forme adaptée à une utilisation directe par d'autres applications. Administration de la base de données Enregistrement et gestion des utilisateurs, sécurité des données, maintenance de l'intégrité, récupération des informations, contrôle des accès simultanés, surveillance des performances, etc.

Les SGBD sont largement utilisés dans les banques, les entreprises de transport, les établissements d'enseignement, les télécommunications, pour la gestion des informations financières et des ressources humaines. N'oubliez pas non plus que la plupart des backends Web utilisent une forme de système de gestion de base de données.

L'une des principales caractéristiques du développement de bases de données est le fait qu'il n'y a pas de solutions et d'algorithmes prêts à l'emploi. Chaque base de données est spécifique à la tâche pour laquelle elle est conçue. Cela distingue le développement d'une base de données du développement d'applications typiques pour lesquelles des algorithmes et des modèles de conception ont été développés depuis longtemps et vous n'avez rien à faire de spécial. Bien que, bien sûr, les techniques de conception de bases de données soient communes à toutes les applications.

modèles de base de données

Comme indiqué précédemment, le modèle de données le plus largement utilisé est le modèle relationnel. Cependant, l'émergence du modèle relationnel a été précédée par d'autres, notamment

• Modèle hiérarchique ou de navigation
• Modèle de réseau

Le modèle hiérarchique a été largement utilisé dans les SGBD fournis par IBM dans les années 1960. L'idée principale est qu'une entrée dans une telle base de données peut avoir plusieurs « enfants » et un « parent ». Dans l'ensemble, cela ressemble étrangement à un système de fichiers hiérarchique. Pour obtenir un enregistrement dans une telle base de données, il est souvent nécessaire de parcourir l'intégralité de l'arbre.

Le modèle de réseau est une version plus flexible de la même approche. Il vous permet d'avoir plusieurs entrées « parents ». Ce modèle, apparu au début des années 1970, ne s'est pas généralisé et a été rapidement supplanté par le modèle relationnel.

Dans les années 1970, Edgar Codd (employé d'IBM) a proposé un modèle relationnel qui a grandement facilité la tâche de trouver des informations dans une base de données. Le modèle relationnel peut être considéré comme des « tables » dans lesquelles les « lignes » sont des enregistrements dans la base de données. Les enregistrements d'une base de données relationnelle sont également appelés tuples et les groupes d'enregistrements (« tables ») sont appelés relations. Le modèle relationnel est capable d'exprimer les relations entre les modèles hiérarchique et de réseau, et a ajouté ses propres relations correspondant au modèle tabulaire.

Sur la base des suggestions de Codd, System R a été développé au milieu des années 1970 et, à la fin, il prenait en charge le langage de requête SQL standardisé.

Dans les années 1980, avec l'avènement de la programmation orientée objet, il est devenu de plus en plus difficile de traduire les objets en modèle relationnel. Au final, cela a conduit à l'émergence des approches NoSQL et NewSQL, qui ne sont actuellement qu'en développement. Des exemples de mise en œuvre de l'approche NoSQL peuvent être ce qu'on appelle. bases de données orientées document construites sur la base de XML. Le principal avantage de NoSQL est une évolutivité horizontale élevée, c'est-à-dire la possibilité d'augmenter les performances en ajoutant des serveurs. Avec l'avènement des technologies cloud, NoSQL est devenu particulièrement demandé.

Néanmoins, le modèle relationnel reste le plus répandu, nous y reviendrons donc plus en détail.

Modèle relationnel

Le modèle relationnel fonctionne en termes d'enregistrements, d'attributs et de relations. Une relation peut être imaginée comme une table à deux dimensions, alors les attributs sont les colonnes de la table (plus précisément, les noms des colonnes), et les enregistrements sont les lignes de la table.

Le modèle relationnel nécessite une définition stricte de la structure des données stockées dans la base de données, c'est-à-dire que les relations et les attributs d'une base de données donnée sont fixes.

Introduisons quelques définitions.

Domaine Un ensemble contenant l'ensemble complet de toutes les valeurs possibles pour une variable. Les domaines sont souvent appelés Type de données... Attribut de paire ordonnée noms d'attributs et domaine \ (D_j \). Tuple Ensemble fini ordonné \ ((d_1, d_2, \ ldots, d_n) \) Titre (schéma) de la relation Tuple \ ((A_1, A_2, \ ldots, A_n) \), où \ (A_j \) sont des attributs. Valeur d'attribut Une valeur spécifique qui appartient au domaine de l'attribut. Corps de relation Un ensemble de tuples, où \ (d ^ i_j \ dans D_j \), \ (D_j \) sont des domaines. Enregistrer un tuple \ ((d ^ i_1, d ^ i_2, \ ldots, d ^ i_n) \) avec fixe \ (i \). Relation Collection de l'en-tête et du corps de la relation. Schéma de la base de données L'ensemble des schémas de toutes les relations incluses dans la base de données.

Vous pouvez représenter la relation sous la forme d'un tableau. Ensuite, le corps de la relation est le corps du tableau, l'en-tête de la relation est l'en-tête du tableau, les attributs sont les noms des colonnes, les enregistrements sont les lignes et les valeurs des attributs sont dans les cellules :

\ (A_1 \)	\ (A_2 \)	\ (\ ldots \)	\ (Un \)	Titre
\ (d ^ 1_1 \)	\ (d ^ 1_2 \)	\ (\ ldots \)	\ (d ^ 1_n \)	Enregistrement
\ (d ^ 2_1 \)	\ (d ^ 2_2 \)	\ (\ ldots \)	\ (d ^ 2_n \)	Enregistrement
\ (\ ldots \)	\ (\ ldots \)	\ (\ ldots \)	\ (\ ldots \)	Enregistrement
\ (d ^ m_1 \)	\ (d ^ m_2 \)	\ (\ ldots \)	\ (d ^ m_n \)	Enregistrement

Le modèle relationnel impose les exigences supplémentaires suivantes aux relations :

Il est clair que les attributs (plus précisément, leurs valeurs) dépendent en quelque sorte les uns des autres - sinon la relation s'avère n'être qu'un ensemble de données non structuré. Pour définir les dépendances entre les attributs, le concept est utilisé dépendance fonctionnelle.

La dépendance fonctionnelle de l'ensemble d'attributs \ (B \) dépend fonctionnellement de l'ensemble d'attributs \ (A \) (écrit \ (A \ rightarrow B \)), si pour deux enregistrements qui ont les mêmes valeurs \ ( A \), leurs valeurs \ ( B \) correspondent. Sinon, chaque valeur \ (A \) correspond à une seule valeur \ (B \) (pas forcément unique, c'est la seule).

En d'autres termes, si un ensemble d'attributs \ (A \) détermine de manière unique (dans le cadre de cette relation) les valeurs des attributs \ (B \), alors \ (B \) dépend fonctionnellement de \ (A \ ).

Comme exemple plus courant de dépendance fonctionnelle, nous pouvons citer la définition mathématique d'une fonction. Pour une fonction, chaque valeur d'argument a une valeur de fonction unique. L'inverse n'est généralement pas vrai, par exemple, pour la fonction \ (y = sin (x) \) toute valeur \ (y \) du domaine \ (1 \ geq y \ geq -1 \) correspond à un ensemble infini de valeurs \ (x \ ), mais pour chaque valeur \ (x \) il y a exactement une valeur \ (y \), donc \ (x \ à y \). Notez que le concept de dépendance fonctionnelle est également applicable aux fonctions de nombreuses variables. Pour eux, la valeur de la fonction dépend fonctionnellement de tous les arguments en même temps... Par exemple, pour la fonction \ (z = f (x, y) \), le FZ \ ((x, y) \ à z \) est rempli, ou en bref, \ (xy \ à z \).

Les relations dans ce contexte peuvent être considérées comme une sorte de tabulaire ou fonctions discrètes.

Travailler avec la loi fédérale

Il existe certaines règles formelles pour travailler avec les relations FZ.

Les règles formelles sont étroitement liées aux concepts fermetures et FZ irréductible.

Les axiomes d'Armstrong

Il existe des règles pour retirer de nouvelles ZF des ZF existantes, appelées par les axiomes d'Armstrong.

Les axiomes d'Armstrong

1. Règle de réflexivité : si \ (B \ sous-ensemble A \), alors \ (A \ rightarrow B \)
2. Règle du complément : si \ (A \ rightarrow B \), alors \ (AC \ rightarrow BC \)
3. Règle de transitivité : si \ (A \ rightarrow B \) et \ (B \ rightarrow C \), alors \ (A \ rightarrow C \)

Les règles supplémentaires suivantes peuvent également être déduites de ces axiomes :

1. Règle d'autodétermination : \ (A \ rightarrow A \)
2. Règle de décomposition : Si \ (A \ rightarrow BC \), alors \ (A \ rightarrow B \) et \ (A \ rightarrow C \)
3. Règle d'union : Si \ (A \ rightarrow B \) et \ (A \ rightarrow C \), alors \ (A \ rightarrow BC \)
4. Règle de composition : Si \ (A \ rightarrow B \) et \ (C \ rightarrow D \), alors \ (AC \ rightarrow BD \)

On peut noter que, du fait de la règle de réflexivité, tout ensemble d'attributs \ (A \) implique une FD de la forme \ (A \ à A \). De telles FZ, ainsi que les suivantes, n'ont pas d'intérêt et sont dites triviales.

Dépendance fonctionnelle triviale ФЗ \ (A \ à B \), telle que \ (B \ sous-ensemble A \).

En principe, ces règles sont suffisantes pour trouver toutes les FD qui découlent des données. À cet égard, le concept de fermeture d'un ensemble de ZF est introduit.

Fermeture d'un ensemble de FD La fermeture d'un ensemble de FD est un ensemble de FD qui comprend tous les FD de l'ensemble d'origine, ainsi que tous ceux qu'ils impliquent. Autrement dit, pour une relation \(R\) à dépendances fonctionnelles\(S\), la clôture \(S^+\) est l'ensemble de toutes les FZ possibles pour \(R\), à partir de \(S\ ).

En règle générale, il est nécessaire d'établir si un certain ФЗ \ (X \ rightarrow Y \) découlera d'un ensemble donné de ФЗ \ (S \). Il s'avère que cela est possible si et seulement si l'ensemble d'attributs \(Y\) est un sous-ensemble de la clôture d'attributs\(X^+\) dans \(S\).

Fermeture d'attributs Fermeture de \(X ^ + \) attributs \ (X \) par l'ensemble ФЗ \ (S \) est l'ensemble de tous les attributs qu'ils dépendent fonctionnellement de quelque subset \ (X \).

Pour calculer la fermeture de l'ensemble des attributs \(X ^ + \) par l'ensemble ФЗ \ (S \), il existe la règle suivante : pour chaque ФЗ \ (A \ rightarrow B \) dans \ (S \), si \ (A \ sous-ensemble X ^ + \), alors \ (B \ sous-ensemble X ^ + \), et il suffit de partir de l'hypothèse que \ (X ^ + = X \).

Il est à noter que pour toute fermeture \ (X ^ + \), il existe des FD de la forme \ (X \ à B \), où \ (B \ sous-ensemble X ^ + \), donc, les fermetures de tous les attributs de la relation selon sa FZ décrivent la fermeture de la FZ de cette relation.

Cette règle permet de calculer un ensemble irréductible de DF équivalent à une donnée (au sens de l'équivalence de leurs clôtures). Réduire le nombre de FD tout en maintenant la fermeture (et, par conséquent, la logique interne décrite par le FD) est une étape importante dans la conception de la base de données.

Un ensemble de FZ est dit irréductible si :

1. Le côté droit de chaque FZ ne contient qu'un élément
2. Aucun des attributs d'un côté gauche de l'ensemble FZ ne peut être supprimé sans changer la fermeture
3. Aucun FZ de l'ensemble ne peut être retiré sans changer la fermeture.

Pour tout ensemble de FZ, il existe au moins un ensemble irréductible équivalent. Un tel ensemble est appelé couverture minimale.

Annotation: Ce cours et les deux suivants sont consacrés à la théorie des bases de données relationnelles. Puisque toute la direction de l'approche relationnelle de l'organisation des bases de données est purement pratique, cette théorie est principalement pragmatique. Le principal problème que la théorie des bases de données relationnelles cherche à résoudre est de découvrir les propriétés utiles de certains schémas de bases de données et de trouver des moyens de construire de tels schémas. Il est d'usage d'appeler brièvement ce problème un problème de conception de base de données relationnelle.

introduction

Malgré son orientation pratique, théorie des bases de données relationnelles est un domaine scientifique indépendant dans lequel de nombreux chercheurs célèbres ont travaillé (et continuent de travailler), dont les noms se retrouveront dans nos conférences. Nous n'avions pas prévu dans ce cours de décrire en détail les principaux résultats sur le terrain. Notre objectif est de fournir uniquement les définitions et les déclarations nécessaires à une compréhension générale du processus conception de base de données relationnelle basé sur la normalisation.

Étant donné que les propriétés les plus importantes des bases de données relationnelles d'un point de vue pratique sont basées sur le concept dépendance fonctionnelle, nous avons choisi une brève discussion des questions théoriques pertinentes dans une conférence séparée. Parmi ces questions, les plus intéressantes sont les fermetures et couverture d'ensembles de dépendances fonctionnelles, Les axiomes d'Armstrong et le théorème des conditions suffisantes de Heath décomposition de la relation sans perte... Les concepts et les énoncés de cette conférence sont vraiment nécessaires pour assimiler le matériel de la conférence 7, mais nous avons également essayé de démontrer aux lecteurs avec des exemples simples ce qui constitue théorie des bases de données relationnelles, quel est son niveau de complexité et à quel point il est intuitif.

Notez que nous n'avons pas distingué de matériel théorique concernant dépendances à plusieurs valeurs et dépendances de connexion... Cela a été fait pour deux raisons. Premièrement, ces types de dépendances sont moins courants dans la modélisation Domaine au moyen de bases de données. Par conséquent, nous avons estimé qu'il suffisait de présenter dans la leçon 8 uniquement les fondements du matériel théorique correspondant. Deuxièmement, bien que la théorie dépendances à plusieurs valeurs et dépendances de connexion, en fait, pas beaucoup plus compliqué que la théorie dépendances fonctionnelles, ses définitions et énoncés sont trop lourds pour ce cours.

Dépendances fonctionnelles

Le plus important d'un point de vue pratique relations normales reposent sur des principes fondamentaux théorie des bases de données relationnelles notions dépendance fonctionnelle... Pour une présentation plus approfondie, nous avons besoin de plusieurs définitions et déclarations (au cours de la présentation, nous les expliquerons et les illustrerons).

Définitions générales

Qu'il soit donné variable de relation r, et X et Y sont des sous-ensembles arbitraires de l'en-tête r (attributs "composites").

Dans le sens rapport variable r l'attribut Y dépend fonctionnellement de l'attribut X si et seulement si chaque valeur de X correspond à exactement une valeur de Y. Dans ce cas, on dit aussi que l'attribut X définit fonctionnellement attribut Y (X est un déterminant ( déterminant) pour Y et Y est dépendant de X). Nous le noterons r.X-> r.Y.

Par exemple, on utilisera la relation EMPLOYÉS_PROJETS (SLU_NOM, SLU_NAME, SLU_ZARP, PRO_NOM, PROJECT_HANDS)(fig. 6.1). Évidemment, si SLU_NOM est la clé primaire de la relation EMPLOYÉS, alors pour cette relation est juste dépendance fonctionnelle (FD) SLU_NOM-> SLU_NAME.

En fait, pour le corps de la relation EMPLOYÉS_PROJETS sous la forme sous laquelle il est représenté sur la fig. 6.1, les FD suivantes sont également remplies (1) :

Riz. 6.1.

SLU_NOM-> SLU_NAME SLU_NOM-> SLU_ZARP SLU_NOM-> ABOUT_SLU_NOM-> PROJECT_HANDS (SLU_NOM, SLU_NAME) -> SLU_ZARP (SLU_NOOL, SLU_NAME) -> ABOUT_YE_SUFF_SUFF_SUFFY, ... etc.

Étant donné que les noms de tous les employés sont différents, les FD suivantes (2) sont également exécutées :

SLU_NAME-> SLU_NOMY_NAME-> SLU_ZARP SLU_NAME-> PRO_NOM, etc.

De plus, par exemple, sur la Fig. 6.1 prises et FD (3) :

SLU_ZARP-> PRO_NOM

Notez, cependant, que la nature du groupe FD (1) diffère de la nature des groupes FD (2) et (3). Il est logique de supposer que les numéros d'identification des employés doivent toujours être différents et que chaque projet n'a qu'un seul responsable. Par conséquent, les groupes FD (1) doivent être vrais pour toute valeur valide rapport variable EMPLOYÉS_PROJETS et peut être considéré comme invariants, ou contraintes d'intégrité cette rapport variable.

Les groupes FD (2) reposent sur l'hypothèse moins naturelle que les noms de tous les employés sont différents. Ceci est vrai pour l'exemple de la Fig. 6.1, mais il est possible qu'au fil du temps les groupes FD (2) ne soient pas remplis pour aucune valeur rapport variable EMPLOYÉS_PROJETS.

Enfin, la DF du groupe (3) est basée sur l'hypothèse totalement contre nature qu'il n'y a pas deux employés participant à des projets différents qui reçoivent le même salaire. Encore une fois, cette hypothèse est vraie pour l'exemple de la Fig. 6.1, mais il s'agit probablement d'une coïncidence.

À l'avenir, nous ne nous intéresserons qu'à ceux dépendances fonctionnellesà effectuer pour toutes les valeurs possibles variables de relation.

Notez que si l'attribut A d'une relation r est une clé possible, alors pour tout attribut B de cette relation, il est toujours valable

Cycle de vie des systèmes d'information

L'analyse de la situation (la complexité du développement du SI, l'utilisation inefficace du SI), réalisée par les scientifiques, a montré que cette situation était causée par le fait que des exigences très importantes n'étaient pas respectées dans le développement de logiciels. :

· Absence de spécification complète de toutes les exigences ;

· Absence d'une méthodologie acceptable (système de méthodes) pour le développement des SI ;

· Absence de division du projet global général en composantes distinctes qui peuvent être efficacement surveillées et gérées.

Le cycle de vie (LC) des systèmes d'information est une approche structurée du développement logiciel.

(certain schéma) pour le 26/09/12

1. Planifier le développement du SI. Des actions préparatoires qui vous permettent de mettre en œuvre les étapes du cycle de vie du SI avec une efficacité maximale. Trois composantes principales : une estimation de la portée des travaux; évaluation des ressources nécessaires; estimer le coût total du projet.

2. Détermination des exigences du système. Détermination de la portée et des limites de l'application de base de données, des fonctions, de ses utilisateurs et des portées.

3. Recueil et analyse des besoins des utilisateurs. Collecte et analyse d'informations sur cette partie de l'organisation, dont le travail sera pris en charge à l'aide du SI créé, détermination des besoins des utilisateurs pour le système. Sources : enquête et questionnaire ; observation; étude de documents; Experience precedente.

4. Conception de la base de données. Création de projet de base de données. Il existe deux approches principales pour concevoir des systèmes de bases de données : descendant" et " Ascendant».

5. Sélection du SGBD cible. Sélection du bon type de SGBD pour prendre en charge l'application de base de données que vous créez.

6. Développement d'applications. Concevoir l'interface utilisateur et les applications pour travailler avec la base de données.

7. Création d'un prototype. Créez un modèle de travail pour votre application de base de données.

8. Mise en œuvre. La mise en œuvre physique de la base de données et des applications développées.

9. Conversion et chargement des données. Transfert de données existantes vers une nouvelle base de données, chargement et modification d'applications existantes afin d'organiser le travail en commun avec une nouvelle base de données.

10. Tests. Le processus d'exécution des programmes d'application afin de trouver des erreurs. Stratégies de test : test descendant ; tests ascendants ; tester les flux ; tests intensifs.

11. Exploitation et entretien. Surveillance du système et soutien de son fonctionnement normal : contrôle des performances ; maintenance et modernisation des applications.

Théorie des bases de données relationnelles

Terminologie

En 1970, le modèle relationnel a été proposé pour la première fois par E.F. Codom.

Dans un SGBD relationnel, on suppose que l'utilisateur perçoit la base de données comme un ensemble de tables (et pas autrement).

Relations mathématiques.

La théorie des bases de données relationnelles est basée sur la théorie mathématique des relations.

Soit D1, D2,… Dn des ensembles.

Produit cartésien D1 D2… Dn = ((X1, X2,…, Xn) | X1 D1, X2 D2,… Xn Dn)

Ratio est un sous-ensemble de R D1 * D2 *… * Dn

Par exemple, n = 2, D1 = (2,4) et D2 = (1,3,5), D1 * D2 = ((2,1), (2,3), (2,5), (4 , 1), (4,3), (4,5)), R = ((2,1), (4,1))

Sous-ensemble m. B. donnée par une condition, par exemple :

R = ((x1, x2) | x1 D1, x2 D2, X2 = 1), A1, A2,… An sont les noms d'attributs de domaines D1, D2,… Wb alors on écrira la relation sous la forme :

R (A1 : D1, A2 : D2,… An : Dn)

Propriétés de la relation :

· La relation a un nom unique ;

· Chaque attribut a un nom unique (par rapport à);

· Chaque cellule de la relation ne contient qu'une valeur atomique et il n'y a pas de groupes répétitifs (la relation est normalisée);

D1 - étudiants
D2 - disciplines : Mathématiques, Informatique

· L'ordre des attributs n'a pas d'importance ;

· L'ordre des tuples est arbitraire ;

· Chaque tuple est unique.

Clés relationnelles

Les clés relationnelles sont utilisées pour identifier de manière unique un tuple décrivant les relations entre les relations.

Intégrité relationnelle.

Algèbre relationnelle

Le résultat d'une opération peut être utilisé comme opérande pour une autre opération, ce qui permet de créer des expressions imbriquées (fermeture PA).

L'algèbre relationnelle est un langage dans lequel tous les tuples sont traités par une seule instruction.

Cinq opérations de base :

Échantillonnage,

Projection,

Produit cartésien,

· Syndicat,

· Différence.

Sur la base de ces opérations, d'autres peuvent être obtenus :

Connexions,

Carrefours,

· Divisions.

Les symboles des opérations logiques ^ (Et), v (Ou), ~ (non) peuvent être utilisés dans le prédicat.

Exemple. Obtenez une liste de tous les employés avec un salaire supérieur à 300.

Projection.

Définit une relation dont les attributs sont attr1, ..., attrn et ne contient que des tuples uniques.

produit cartésien

Le produit cartésien est rarement utilisé, la sélection est appliquée au résultat.

syndicat

Différence

Opérations de connexion.

Connexion thêta

Connexion naturelle

Connexion externe

Ensuite, avec la jointure externe gauche, toutes les informations d'origine de la relation R sont conservées. De même, vous pouvez également définir la jointure externe droite.

Semi-jointure

Une opération de semi-jointure peut être définie à l'aide des opérateurs de projection et de jointure.

Traversée

Représentation

Objectif des vues :

· Fournit un mécanisme flexible pour protéger la base de données en cachant certaines de ses parties à certains utilisateurs ;

· Vous permet d'organiser l'accès des utilisateurs aux données de la manière la plus pratique pour eux ;

· Vous permet de simplifier des opérations complexes avec des relations de base.

Des règles à satisfaire
SGBD relationnel

Pour déterminer si SUBO est relationnel, Codd (1985) a proposé 13 règles auxquelles ils doivent satisfaire.

№		La règle
		Une règle fondamentale. Un SGBD relationnel doit pouvoir gérer des bases de données en utilisant uniquement ses fonctions relationnelles.
		Présentation des informations. Toutes les informations d'une base de données relationnelle sont représentées explicitement au niveau logique d'une seule manière - sous la forme de valeurs dans des tableaux. Y compris les métadonnées.
		Accès garanti. Pour chaque élément de données dans une base de données relationnelle, l'accès logique doit être garanti en fonction d'une combinaison de nom de table, de valeur de clé primaire et de nom de colonne.
		Prise en charge des valeurs non définies. Le SGBD prend en charge les valeurs nulles.
		Catalogue du système relationnel. La description de la base de données doit être présentée au niveau logique de la même manière que les données normales, ce qui permet aux utilisateurs d'utiliser le même langage relationnel pour s'y référer.
		Sous-langage de données complet. un SGBD relationnel peut prendre en charge plusieurs langues. Cependant, il doit exister au moins un langage dont les opérateurs permettraient d'effectuer les fonctions suivantes : 1. Définition des données ; 2. Définition des vues ; 3. Commandes de manipulation de données ; 4. Contraintes d'intégrité ; 5. Autorisation de l'utilisateur ; 6. Organisation des transactions
		Opérations de haut niveau d'extraction, d'insertion, de suppression, de mise à jour. La capacité d'un SGBD à effectuer des opérations de récupération de données des commandes d'insertion, de suppression et de mise à jour en une seule opération.
		Indépendance physique des données. De la méthode de stockage
		Indépendance logique des données. Indépendance de l'application vis-à-vis des modifications apportées aux tables de base.
		L'intégrité limite l'indépendance. Les contraintes d'intégrité doivent être définies dans le sous-langage des données relationnelles et stockées dans le catalogue système, et non dans les programmes d'application.
		Indépendance de la distribution des données.
		Règle d'interdiction des détours. Si le SGBD dispose d'un langage de bas niveau (avec traitement séquentiel ligne par ligne), il ne doit pas permettre de contourner les règles et contraintes d'intégrité décrites dans le langage relationnel de haut niveau.

Modélisation des données basée sur le processus de normalisation

L'objectif de la normalisation.

Le processus de normalisation a été proposé en 1972 par E. F. Codd - trois formes normales (NF) : la première (1NF), la deuxième (2NF) et la troisième (3NF).

Une définition plus rigoureuse de la troisième NF (R. Boyes et E. F. Codd, 1974) est la forme normale Boyes-Codd (NFBK).

Redondance et anomalies de traitement.

Le manque de normalisation entraîne :

Redondance des données

Anomalies d'insertion (impossible d'ajouter des enregistrements)

Anomalies de suppression (lors de la suppression d'informations, d'autres informations sont perdues)

Anomalies de mise à jour (de nombreux enregistrements doivent être mis à jour)

· Propriétés de préservation sans perte et de préservation des dépendances.

Dépendances fonctionnelles