Sachant juste assez bases de données relationnelles

Construire un système d'Oracle ou d'un autre produit de base de données relationnelle ne fait pas automatiquement une base de données relationnelle. De même, vous pouvez concevoir une très bonne base de données relationnelle et mettre en œuvre dans autre chose qu'un produit de base de données relationnelle. Nous discutons deux domaines importants:

• Qu'est-ce que les gens entendent par base de données relationnelle?

• Quel est le produit de base de données relationnelle Oracle?

Ce qui rend une base de données «relationnel»?

Lorsqu'une base de données est décrit comme relationnelle, il a été conçu pour se conformer (au moins la plupart du temps) à un ensemble de pratiques appelé règles de normalisation. Une base de données normalisée est celui qui suit les règles de normalisation.

Par exemple, dans une organisation, vous avez des employés qui travaillent dans des départements spécifiques. Chaque employé et chaque département a un numéro et un nom. Vous pouvez organiser cette information comme indiqué dans le tableau 1.

Tableau 1: Exemple Renseignements sur l'employé

Si vous structurez vos données de cette façon et de faire certaines modifications, vous aurez des problèmes. Par exemple, la suppression de tous les employés de la Direction des Achats éliminera le ministère lui-même. Si vous modifiez le nom du département de marketing de «publicité», vous auriez besoin de changer le dossier de chaque employé dans ce département.

En utilisant les principes de bases de données relationnelles, les données Employé et Service peuvent être restructurés en deux tableaux distincts (dept et EMP), comme indiqué dans les tableaux 2 et 3.

Tableau 2: une table relationnelle DEPT échantillon

Tableau 3: Une table relationnelle EMP échantillon

En utilisant cette structure, vous pouvez examiner la table EMP de découvrir que Doug travaille dans le département 20. Ensuite, vous pouvez consulter le tableau de DEPT pour savoir ce département 20 est d'achat. Vous pourriez penser que le tableau 1 semble plus efficace. Toutefois, la récupération de l'information dont vous avez besoin dans un certain nombre de façons différentes est beaucoup plus facile avec la structure de deux tables. Rejoindre l'information dans les deux tableaux pour la récupération plus efficace est exactement le problème que bases de données relationnelles ont été conçus pour résoudre.

Lorsque les tables sont mises en oeuvre dans la base de données, les informations dans les deux tableaux est lié en utilisant des colonnes spéciales appelées clés étrangères. Dans l'exemple, la colonne DeptNo est la clé étrangère reliant les tables département et l'employé.

Tableaux 4 et 5 montrent une autre structure de base de données commune, à savoir un ordre d'achat (table de PURCH_ORDER) pour un article et les détails d'information liés à l'achat afin (table de PURCH_ORDER_DTL).

Tableau 4: Une table relationnelle de PURCH_ORDER échantillon

Tableau 5: Une table relationnelle de PURCH_ORDER_DTL échantillon

Un bon de commande peut inclure de nombreux éléments. Tableau 5 montre que bon de commande 451 comprend trois éléments distincts. Le lien (de clé étrangère) entre les tables est le numéro de commande.

La terminologie de base de données de base compréhension

Une base de données est constituée de tables et des colonnes, comme décrit dans la section précédente. Il ya quelques autres termes que vous devez connaître pour comprendre comment fonctionnent les bases de données. Une base de données est construite en deux étapes. D'abord, vous créez un modèle de données logique d'exposer la conception de la base de données et comment les données seront organisées. Ensuite, vous mettez en œuvre la base de données en fonction de la modèle physique de données, qui met en place les tables et colonnes réels. Terminologie différente applique aux éléments des conceptions logiques et physiques. En outre, les concepteurs de bases de données relationnelles utilisent des mots différents de designers orientés objets base de données (OO) pour décrire les éléments de base de données. Le tableau 6 montre les mots utilisés dans chacun de ces cas.

Tableau 6: Database Design Terminologie

Les définitions des termes figurant dans le tableau 6 sont les suivantes:

• Entité: Une entité correspond à quelque chose dans le monde réel qui est de l'intérêt et que vous souhaitez stocker des informations sur. Exemples d'entités comprennent des éléments tels que les départements au sein d'une organisation, les employés, ou des ventes. Chaque département ou employé en particulier est considéré comme un exemple de cette entité. Par exemple, dans le tableau 3, Doug est une instance de l'entité Salarié. (Dans le monde de OO, Doug serait un objet dans la classe des employés.)

• Attribut: Ce mot est utilisé dans les deux bases de données relationnelles et OO pour représenter des informations sur une instance d'entité ou d'un objet qui sera suivi. Un exemple d'un attribut pourrait être la date de naissance ou numéro de sécurité sociale d'un salarié.

• Entités (classes), leurs attributs et instances (objets): Celles-ci sont mises en œuvre dans la base de données sous forme de tableaux, les colonnes et rangées respectivement.

Un concept important supplémentaire pour comprendre lorsqu'ils traitent avec des bases de données relationnelles est la clé primaire. UN clé primaire identifie de manière unique une instance spécifique d'une entité. Pas de deux instances d'une entité peuvent avoir la même clé primaire. Les valeurs de toutes les parties de la clé primaire ne doivent jamais être nulle. Les types les plus communs de clés primaires dans les bases de données relationnelles sont des numéros d'identification. Par exemple, dans le tableau 3, la EmpID peut être la clé primaire. Parfois, plus d'un attribut (ou ensembles d'attributs) peuvent être utilisés en tant que clé primaire. Ces attributs sont appelés clés candidates, un ensemble qui doit être désignée comme la clé primaire.