One place for hosting & domains

      Información sobre las bases de datos relacionales


      Introducción

      Los sistemas de administración de bases de datos (DBMS) son programas que permiten a los usuarios interactuar con una base de datos. Les permiten controlar el acceso a una base de datos, escribir datos, ejecutar consultas y realizar otras tareas relacionadas con la administración de bases de datos.

      Sin embargo, para realizar cualquiera de estas tareas, los DBMS deben tener algún tipo de modelo subyacente que defina la organización de los datos. El modelo relacional es un enfoque para la organización de datos que se ha utilizado ampliamente en programas de software de bases de datos desde su concepción a fines de la década de 1960; a tal grado que, a la fecha de redacción de este artículo, cuatro de los cinco DBMS más populares son relacionales.

      Este artículo conceptual describe la historia del modelo relacional, la manera en que se organizan los datos en las bases de datos relacionales y cómo se utilizan hoy en día.

      Historia del modelo relacional

      Las bases de datos son conjuntos de información, o datos, modelados de forma lógica. Cualquier recopilación de datos es una base de datos, independientemente de cómo o dónde se almacene. Incluso un gabinete de archivos con información sobre nómina es una base de datos, al igual que una pila de formularios de pacientes hospitalizados o la recopilación de información sobre clientes de una empresa repartida en varias ubicaciones. Antes de que almacenar y administrar datos con computadoras se convirtiera en una práctica común, las bases de datos físicas como estas eran lo único con lo que contaban las organizaciones gubernamentales y empresariales que necesitaban almacenar información.

      A mediados del siglo XX, los desarrollos en las ciencias de la computación dieron lugar a máquinas con mayor capacidad de procesamiento y almacenamiento, tanto local como externo. Estos avances hicieron que los especialistas en ciencias de la computación comenzaran a reconocer el potencial que tenían estas máquinas para almacenar y administrar cantidades de datos cada vez más grandes.

      Sin embargo, no había teorías sobre cómo las computadoras podían organizar datos de manera significativa y lógica. Una cosa es almacenar datos no ordenados en una máquina, pero es mucho más complicado diseñar sistemas que permitan agregar, recuperar, clasificar y administrar esos datos de forma sistemática y práctica. La necesidad de contar con un marco de trabajo lógico para almacenar y organizar datos dio lugar a varias propuestas sobre cómo utilizar las computadoras para administrar datos.

      Uno de los primeros modelos de bases de datos fue el modelo jerárquico, en el que los datos se organizan con una estructura de árbol similar a la de los sistemas de archivos modernos. El siguiente ejemplo muestra el aspecto que podría tener el diseño de una parte de una base de datos jerárquica utilizada para categorizar animales:

      Ejemplo de base de datos jerárquica: categorización de animales

      El modelo jerárquico se implementó ampliamente en los primeros sistemas de administración de bases de datos, pero resultaba poco flexible. En este modelo, a pesar de que los registros individuales pueden tener varios “elementos secundarios”, cada uno puede tener un solo “elemento primario” en la jerarquía. Es por eso que estas primeras bases de datos jerárquicas se limitaban a representar relaciones “uno a uno” y “uno a varios”. Esta carencia de relaciones “varios a varios” podía provocar problemas al trabajar con puntos de datos que se deseaba asociar a más de un elemento primario.

      A fines de los años 60, Edgar F. Codd, un especialista en ciencias de la computación que trabajaba en IBM, diseñó el modelo relacional de administración de bases de datos. El modelo relacional de Codd permitía que los registros individuales se relacionaran con más de una tabla y, de esta manera, posibilitaba las relaciones “varios a varios” entre los puntos de datos además de las relaciones “uno a varios”. Esto proporcionó más flexibilidad que los demás modelos existentes a la hora de diseñar estructuras de base de datos y permitió que los sistemas de gestión de bases de datos relacionales (RDBMS) pudieran satisfacer una gama mucho más amplia de necesidades empresariales.

      Codd propuso un lenguaje para la administración de datos relacionales, conocido como Alfa, que influyó en el desarrollo de los lenguajes de bases de datos posteriores. Dos colegas de Codd en IBM, Donald Chamberlin y Raymond Boyce, crearon un lenguaje similar inspirado en Alpha. Lo llamaron SEQUEL, abreviatura de Structured English Query Language (Lenguaje de consulta estructurado en inglés), pero debido a una marca comercial existente, lo abreviaron a SQL (conocido formalmente como* Lenguaje de consulta estructurado*).

      Debido a las limitaciones de hardware, las primeras bases de datos relacionales eran prohibitivamente lentas y el uso de la tecnología tardó un tiempo en generalizarse. Pero a mediados de los años ochenta, el modelo relacional de Codd se había implementado en varios productos comerciales de administración de bases de datos, tanto de IBM como de sus competidores. Estos proveedores también siguieron el liderazgo de IBM al desarrollar e implementar sus propios dialectos de SQL. Para 1987, tanto el Instituto Nacional Estadounidense de Estándares (American National Standards Institute) como la Organización Internacional de Normalización (International Organization for Standardization) habían ratificado y publicado normas para SQL, lo que consolidó su estado como el lenguaje aceptado para la administración de RDBMS.

      Gracias al uso extendido del modelo relacional en varias industrias, se lo comenzó a reconocer como el modelo estándar para la administración de datos. Incluso con el surgimiento de varias bases de datos NoSQL en los últimos años, las bases de datos relacionales siguen siendo las herramientas predominantes para almacenar y organizar datos.

      Cómo organizan los datos las bases de datos relacionales

      Ahora que tiene una idea general de la historia del modelo relacional, vamos a analizar en detalle cómo organiza los datos.

      Los elementos más fundamentales del modelo relacional son las relaciones, que los usuarios y los RDBMS modernos reconocen como tablas. Una relación es un conjunto de tuplas, o filas de una tabla, en el que cada una de ellas comparte un conjunto de atributos o columnas:

      Diagrama de ejemplo de la asociación entre las relaciones, las tuplas y los atributos

      Una columna es la estructura de organización más pequeña de una base de datos relacional y representa las distintas facetas que definen los registros en la tabla. De ahí proviene su nombre más formal: atributos. Se puede pensar que cada tupla es como una instancia única de cualquier tipo de personas, objetos, eventos o asociaciones que contenga la tabla.  Estas instancias pueden ser desde empleados de una empresa y ventas de un negocio en línea hasta resultados de pruebas de laboratorio. Por ejemplo, en una tabla que contiene registros de los maestros de una escuela, las tuplas pueden tener atributos como name, subjects, start_date, etc.

      Al crear una columna, especificamos un* tipo de datos *que determina el tipo de entradas que se permiten en esa columna. Los sistemas de administración de bases de datos relacionales (RDBMS) suelen implementar sus propios tipos de datos únicos, que pueden no ser directamente intercambiables con tipos de datos similares de otros sistemas. Algunos tipos de datos frecuentes son fechas, cadenas, enteros y booleanos.

      En el modelo relacional, cada tabla contiene, por lo menos, una columna que puede utilizarse para identificar de forma única cada fila, lo que se denomina clave primaria. Esto es importante, dado que significa que los usuarios no necesitan saber dónde se almacenan físicamente los datos en una máquina; en su lugar, sus DBMS pueden realizar un seguimiento de cada registro y devolverlo según corresponda. A su vez, significa que los registros no tienen un orden lógico definido y que los usuarios tienen la capacidad de devolver sus datos en cualquier orden y a través de los filtros que deseen.

      Si tiene dos tablas que desea asociar, una manera de hacerlo es con una clave externa. Una clave externa es, básicamente, una copia de la clave primaria de una tabla (la tabla “primaria”) insertada en una columna de otra tabla (la “secundaria”). El siguiente ejemplo destaca la relación entre dos tablas: una se utiliza para registrar información sobre los empleados de una empresa y la otra, para realizar un seguimiento de las ventas de la empresa. En este ejemplo, la clave primaria de la tabla EMPLOYEES se utiliza como clave externa de la tabla SALES:

      Diagrama de ejemplo de cómo la clave primaria de la tabla EMPLOYEE actúa como la clave externa de la tabla SALES

      Si intenta agregar un registro a la tabla secundaria y el valor ingresado en la columna de la clave externa no existe en la clave primaria de la tabla primaria, la instrucción de inserción no será válida. Esto ayuda a mantener la integridad del nivel de las relaciones, dado que las filas de ambas tablas siempre se relacionarán correctamente.

      Los elementos estructurales del modelo relacional ayudan a mantener los datos almacenados de forma organizada, pero el almacenamiento de datos solo es útil si se pueden recuperar. Para obtener información de un RDBMS, puede emitir una consulta o una solicitud estructurada de un conjunto de información. Como se mencionó anteriormente, la mayoría de las bases de datos relacionales utilizan SQL para administrar y consultar datos. SQL permite filtrar y manipular los resultados de las consultas con una variedad de cláusulas, predicados y expresiones, lo que, a su vez, permite controlar correctamente qué datos se mostrarán en el conjunto de resultados.

      Ventajas y limitaciones de las bases de datos relacionales

      Teniendo en cuenta la estructura organizativa subyacente de las bases de datos relacionales, consideremos algunas de sus ventajas y desventajas.

      Hoy en día, tanto SQL como las bases de datos que lo implementan se desvían del modelo relacional de Codd de diversas maneras. Por ejemplo, el modelo de Codd determina que cada fila de una tabla debe ser única, mientras que, por cuestiones de practicidad, la mayoría de las bases de datos relacionales modernas permiten la duplicación de filas. Algunas personas no consideran que las bases de datos SQL sean verdaderas bases de datos relacionales a menos que cumplan con las especificaciones de Codd del modelo relacional. Sin embargo, en términos prácticos, es probable que cualquier DBMS que utilice SQL y, por lo menos, se adhiera en cierta medida al modelo relacional se denomine “sistema de administración de bases de datos relacionales”.

      A pesar de que las bases de datos relacionales ganaron popularidad rápidamente, algunas de las deficiencias del modelo relacional comenzaron a hacerse evidentes a medida que los datos se volvieron más valiosos y las empresas comenzaron a almacenar más de ellos. Entre otras cosas, puede ser difícil escalar una base de datos relacional de forma horizontal.  Los términos escalado horizontal o escala horizontal se refieren a la práctica de agregar más máquinas a una pila existente para extender la carga y permitir un mayor tráfico y un procesamiento más rápido. Se suele contrastar con el escalado vertical, que implica la actualización del hardware de un servidor existente, generalmente, añadiendo más RAM o CPU.

      El motivo por el cual es difícil escalar una base de datos relacional de forma horizontal está relacionado con el hecho de que el modelo relacional se diseñó para garantizar coherencia, lo que significa que los clientes que realizan consultas en la misma base de datos siempre obtendrán los mismos datos. Al querer escalar una base de datos relacional de forma horizontal en varias máquinas, resulta difícil asegurar la coherencia, dado que los clientes pueden escribir datos en un nodo pero no en otros.  Es probable que haya un retraso entre la escritura inicial y el momento en que se actualicen los demás nodos para reflejar los cambios, lo que daría lugar a inconsistencias entre ellos.

      Otra limitación que presentan los RDBMS es que el modelo relacional se diseñó para administrar datos estructurados o alineados con un tipo de datos predeterminado o, por lo menos, organizado de una manera predeterminada para que se puedan ordenar o buscar de forma más sencilla. Sin embargo, con la difusión de los equipos informáticos personales y el auge de Internet a principios de la década de 1990, los datos no estructurados, como los mensajes de correo electrónico, las fotos, los videos, etc., se volvieron más comunes.

      Nada de esto significa que las bases de datos relacionales no sean útiles. Al contrario, después de más de 40 años, el modelo relacional sigue siendo el marco dominante para la administración de datos. Su prevalencia y longevidad indican que las bases de datos relacionales son una tecnología madura, lo que constituye una de sus principales ventajas. Hay muchas aplicaciones diseñadas para trabajar con el modelo relacional, así como muchos administradores de bases de datos profesionales expertos en bases de datos relacionales. También hay una amplia variedad de recursos disponibles en formato impreso y digital para quienes desean comenzar a utilizar bases de datos relacionales.

      Otra ventaja de las bases de datos relacionales es que casi todos los RDBMS admiten transacciones. Las transacciones constan de una o más instrucciones SQL individuales que se ejecutan en secuencia como una unidad de trabajo única. Las transacciones tienen un enfoque de todo o nada, lo que significa que todas las instrucciones SQL de una transacción deben ser válidas; de lo contrario, falla en su totalidad. Esto es muy útil para garantizar la integridad de los datos al realizar cambios en varias filas o tablas.

      Por último, las bases de datos relacionales son sumamente flexibles. Se han utilizado para crear una amplia variedad de aplicaciones distintas y siguen funcionando de forma eficiente incluso con grandes cantidades de datos. SQL también es sumamente potente y permite agregar y cambiar datos sobre la marcha, así como alterar la estructura de los esquemas y las tablas de las bases de datos sin afectar a los datos existentes.

      Conclusión

      Gracias a su flexibilidad y diseño para la integridad de los datos, más de cincuenta años después de su concepción inicial, las bases de datos relacionales siguen siendo la principal forma de administrar y almacenar datos.  A pesar del surgimiento de diversas bases de datos NoSQL en los últimos años, la comprensión del modelo relacional y la manera de trabajar con RDBMS es fundamental para cualquier persona que desee crear aplicaciones que aprovechen el poder de los datos.

      Para obtener más información sobre RDBMS populares de código abierto, le recomendamos consultar nuestra comparación de diversas bases de datos relacionales SQL de código abierto. Si desea obtener más información sobre las bases de datos en general, le recomendamos consultar nuestra biblioteca completa de contenidos relacionados con bases de datos.



      Source link

      Comprendre les bases de données relationnelles


      Introduction

      Les systèmes de gestion des bases de données (SGDB ou DBMS en anglais) sont des programmes informatiques qui permettent aux utilisateurs d’interagir avec une base de données. Un SGDB permet aux utilisateurs de contrôler l’accès à une base de données, d’écrire des données, d’exécuter des requêtes et d’effectuer toute autre tâche liée à la gestion de base de données.

      Pour effectuer l’une de ces tâches, cependant, le SGDB doit avoir une sorte de modèle sous-jacent qui définit la manière dont les données sont organisées. Le modèle relationnel est une approche d’organisation des données qui ont trouvé un large usage dans le logiciel de base de données depuis sa conception initiale à la fin des années 1960, à tel point que, à partir de ce texte, quatre des cinq SGDB les plus populaires sont relationnels.

      Cet article conceptuel décrit l’historique du modèle relationnel, la manière dont les bases de données relationnelles organisent les données, et leur utilisation aujourd’hui.

      Histoire du modèle relationnel

      Les bases de données sont des groupes d’informations ou de données modélisés de manière logique**. Toute collecte de données est une base de données, quel que soit la manière dont elle est stockée ou l’endroit où elle est stockée. Même un classeur de fichiers contenant des informations sur les salaires est une base de données, tout comme une pile de formulaires de patients d’un hôpital ou la collecte d’informations sur les clients d’une entreprise répartis dans plusieurs endroits. Avant que le stockage et la gestion des données à l’aide d’ordinateurs ne soit une pratique courante, les bases de données physiques comme celles-ci étaient les seules dont disposaient les organisations gouvernementales et commerciales qui avaient besoin de stocker des informations.

      Vers le milieu du XXe siècle, les développements en informatique ont conduit à la mise au point de machines plus puissantes, ainsi qu’à une plus grande capacité de stockage local et externe. Ces progrès ont conduit les informaticiens à commencer à reconnaître le potentiel de ces machines pour stocker et gérer des quantités de données toujours plus importantes.

      Cependant, il n’existait pas de théories sur la manière dont les ordinateurs pouvaient organiser les données de manière logique et significative. C’est une chose de stocker des données non triées sur une machine, mais il est beaucoup plus compliqué de concevoir des systèmes qui vous permettent d’ajouter, récupérer, trier et gérer ces données d’une manière cohérente et pratique. La nécessité d’un cadre logique pour stocker et organiser les données a conduit à un certain nombre de propositions d’utilisation des ordinateurs pour la gestion des données.

      L’un des premiers modèles de base de données était le modèle hiérarchique, dans lequel les données sont organisées dans une structure arborescente ressemblant semblables aux systèmes de fichiers modernes. L’exemple suivant montre à quoi pourrait ressembler la disposition d’une partie d’une base de données hiérarchique utilisée pour classer les animaux : :

      Exemple Base de données hiérarchiques : catégorisation des animaux

      Le modèle hiérarchique a été largement appliqué dans les systèmes de gestion de base de données, mais il s’est également avéré peu flexible. Dans ce modèle, même si les enregistrements individuels peuvent avoir plusieurs enregistrements “enfant”, chaque enregistrement ne peut avoir qu’un seul “parent” dans la hiérarchie. Pour cette raison, ces bases de données hiérarchiques antérieures se limitaient à représenter uniquement des relations “”un à un” et “un à plusieurs” Cette absence de relations “de plusieurs à plusieurs”  pourrait entraîner des problèmes lorsque vous travaillez avec des points de données que vous souhaitez associer à plus d’un parent.

      À la fin des années 1960, Edgar F. Codd, un informaticien chez IBM, a mis au point le modèle relationnel de gestion de base de données. Le modèle relationnel de Codd a permis à des enregistrements individuels d’être associés à plus d’une table, permettant ainsi des relations “de plusieurs à plusieurs” entre les points de données en plus des relations “d’un à plusieurs”.  Cela a permis une plus grande flexibilité que d’autres modèles existants en ce qui concerne la conception des structures de base de données, ce qui signifie que les systèmes de gestion de bases de données relationnelles (SGBDR) pouvaient répondre à un éventail beaucoup plus large de besoins commerciaux.

      Codd a proposé un langage pour gérer les données relationnelles, connu sous le nom d’Alpha, qui a influencé le développement de langages de base de données ultérieurs. Deux des collègues de Codd chez IBM, Donald Chamberlin et Raymond Boyce, ont créé un tel langage inspirée d’Alpha. Ils ont appelé leur langue SEQUEL, anagramme de   S tructured  E nglish  Que ry  L anguage, mais en raison d’une marque existante ils ont raccourci le nom de leur langage à SQL (appelé de manière plus formelle Structured Query Language).

      En raison de contraintes matérielles, les premières bases de données relationnelles étaient excessivement lentes, et il a fallu un certain temps avant que la technologie ne se généralise. Mais au milieu des années 1980, le modèle relationnel de Codd a été mis en œuvre dans un certain nombre de produits de gestion de base de données commerciales d’IBM et de ses concurrents. Ces entreprises ont également suivi l’initiative d’IBM en développant et en mettant en œuvre leurs propres dialectes de SQL. En 1987, l’American National Standards Institute et l’International Organization for Standardization avaient tous deux ratifié et publié des normes pour SQL, consolidant ainsi son statut de langage accepté pour la gestion des SGBDR.

      L’utilisation du modèle relationnel dans plusieurs industries a conduit à sa reconnaissance en tant que modèle standard de gestion des données. Même avec l’essor de différentes bases de données NoSQL ces dernières années, les bases de données relationnelles restent les outils dominants pour le stockage et l’organisation des données.

      Maintenant que vous avez une compréhension générale de l’histoire du modèle relationnel, examinons de plus près la manière dont le modèle organise les données.

      Les éléments les plus fondamentaux du modèle relationnel sont les relations que les utilisateurs et les SGBDR modernes reconnaissent comme tableaux. Une relation est un ensemble de tuples, ou de lignes dans une table, avec chaque tuple partageant un ensemble d’attributs, ou colonnes :

      Exemple de diagramme indiquant comment les relations, les tuples et les attributs sont liés les uns aux autres

      Une colonne est la plus petite structure organisationnelle d’une base de données relationnelle, et représente les différentes facettes qui définissent les enregistrements de la table. D’où leur nom plus formel, les attributs. Vous pouvez penser à chaque tuple comme une instance unique de n’importe quel type de personnes, objets, événements ou associations que la table contient. Ces instances peuvent être des éléments comme les employés d’une entreprise, les ventes d’une entreprise en ligne ou les résultats de test en laboratoire. Par exemple, dans une table contenant les enregistrements des enseignants d’une école, les tuples peuvent avoir des attributs comme name, subjects, start_date, etc.

      Lorsque vous créez des colonnes, vous spécifiez un type de données qui dicte le type d’entrées autorisées dans cette colonne. Les SGBDR mettent souvent en œuvre leurs propres types de données uniques, qui peuvent ne pas être directement interchangeables avec des types de données similaires dans d’autres systèmes. Les types de données les plus courants comprennent les dates, les chaînes de caractères, les entiers et les Booléens.

      Dans le modèle relationnel, chaque table contient au moins une colonne qui peut être utilisée pour identifier de manière unique chaque ligne, appelée clé primaire. C’est important, car cela signifie que les utilisateurs n’ont pas à savoir où leurs données sont physiquement stockées sur une machine, au lieu de cela, leur SGBD peut suivre chaque enregistrement et les renvoyer sur une base ad hoc. Cela signifie que les enregistrements n’ont pas d’ordre logique défini, et que les utilisateurs ont la possibilité de renvoyer leurs données dans n’importe quel ordre ou par les filtres qu’ils souhaitent.

      Si vous souhaitez associer deux tables l’une à l’autre, vous pouvez le faire avec une clé étrangère. Une clé étrangère est essentiellement une copie de la clé primaire d’une table (la table “parent”) insérée dans une colonne d’une autre table (l’“enfant”). L’exemple suivant met en évidence la relation entre deux tableaux, l’un utilisé pour enregistrer les informations relatives aux employés d’une entreprise et l’autre utilisée pour suivre les ventes de l’entreprise. Dans cet exemple, la clé principale du tableau EMPLOYEES est utilisée comme clé étrangère du tableau SALES :

      Diagramme illustrant comment la clé principale du tableau de EMPLOYEE agit en tant que clé étrangère du tableau SALES

      Si vous essayez d’ajouter un enregistrement au tableau enfant et que la valeur saisie dans la colonne de clé étrangère n’existe pas dans la clé primaire du tableau parent, l’instruction d’insertion sera invalide. Cela aide à maintenir l’intégrité au niveau des relations, car les lignes des deux tableaux seront toujours correctement reliées.

      Les éléments structurels du modèle relationnel aident à conserver les données stockées de manière organisée, mais la conservation des données n’est utile que si vous pouvez les récupérer. Pour récupérer des informations d’un SGBDR, vous pouvez émettre une query ou une requête structurée d’un ensemble d’informations. Comme mentionné précédemment, la plupart des bases de données relationnelles utilisent SQL pour gérer et interroger les données. SQL vous permet de filtrer et de manipuler les résultats de requête avec une variété de clauses, de prédicats et d’expressions, vous donnant un contrôle précis sur les données qui apparaîtront dans l’ensemble de résultats.

      Avantages et limitations des bases de données relationnelles

      En tenant compte de la structure organisationnelle sous-jacente des bases de données relationnelles, examinons quelques-uns de leurs avantages et de leurs inconvénients.

      Aujourd’hui, tant SQL que les bases de données qui l’implémentent s’écartent du modèle relationnel de Codd de plusieurs façons. Par exemple, le modèle de Codd dicte que chaque ligne d’une table doit être unique tandis que, pour des raisons pratiques, la plupart des bases de données relationnelles modernes permettent de dupliquer les lignes. Certaines personnes ne considèrent pas les bases de données SQL comme de véritables bases de données relationnelles si elles ne respectent pas chacune des spécifications du modèle relationnel de Codd. En termes pratiques, cependant, tout SGBD qui utilise SQL et qui adhère au moins en partie au modèle relationnel est susceptible d’être appelé un système de gestion de base de données relationnelles.

      Bien que les bases de données relationnelles aient rapidement gagné en popularité, certaines des lacunes du modèle relationnel ont commencé à apparaître lorsque les données prenaient de la valeur et que les entreprises ont commencé à en stocker davantage. La scalabilité horizontale, ou scaling out, est la pratique qui consiste à ajouter plus de machines à une pile existante afin de répartir la charge et de permettre un traffic plus important et un traitement plus rapide. Cette opération est souvent opposée à la mise à la scalabilité verticale qui implique la mise à niveau du matériel d’un serveur existant, généralement en ajoutant plus de RAM ou de CPU.

      La raison pour laquelle il est difficile de faire évoluer une base de données relationnelle horizontalement est liée au fait que le modèle relationnel est conçu pour assurer la cohérence, ce qui signifie que les clients qui interrogent la même base de données récupèrent toujours les mêmes données. Si vous devez faire évoluer une base de données relationnelle horizontalement sur plusieurs machines, il devient difficile d’en garantir la cohérence car les clients peuvent parfois écrire des données sur un nœud, sans le faire sur les autres. Il y aurait probablement un délai entre l’écriture initiale et le moment où les autres nœuds sont mis à jour pour refléter les changements, ce qui entraînerait des incohérences entre eux.

      Une autre limitation présentée par les SGDBR est que le modèle relationnel a été conçu pour gérer des données structurées, ou des données qui s’alignent avec un type de données prédéfini ou qui sont au moins organisées d’une manière prédéterminée, ce qui les rend facilement triables et consultables. Toutefois, avec le développement de l’informatique personnelle et l’essor d’Internet au début des années 1990, les données non structurées — telles que les messages électroniques, les photos, les vidéos, etc. — sont devenues plus fréquentes.

      Rien de cela ne veut dire que les bases de données relationnelles ne sont pas utiles. Au contraire, le modèle relationnel est toujours le cadre dominant de la gestion des données après plus de 40 ans. Leur prévalence et leur longévité signifient que les bases de données relationnelles sont une technologie mature, qui est en soi l’un de leurs avantages majeurs. Il existe de nombreuses applications conçues pour fonctionner avec le modèle relationnel, ainsi que de nombreux administrateurs de base de données de carrière qui sont des experts en matière de bases de données relationnelles. Il existe également un large éventail de ressources disponibles sur papier et en ligne pour ceux qui souhaitent se lancer dans les bases de données relationnelles.

      Un autre avantage des bases de données relationnelles est que presque tous les SGBDR prennent en charge les transactions. Une transaction consiste en une ou plusieurs des instructions SQL individuelles exécutées en séquence comme une seule unité de travail. Les transactions présentent une approche de type tout-ou rien, ce qui signifie que chaque instruction SQL de la transaction doit être valide ; sinon, la transaction entière échouera. Ceci est très utile pour garantir l’intégrité des données lors de modifications de plusieurs lignes ou tableaux.

      Enfin, les bases de données relationnelles sont extrêmement flexibles. Elles ont été utilisées pour construire une grande variété d’applications différentes, et continuent de fonctionner efficacement même avec de très grandes quantités de données. SQL est également extrêmement puissant, vous permettant d’ajouter et de modifier des données au vol, ainsi que de modifier la structure des schémas et des tableaux de base de données sans incidence sur les données existantes.

      Conclusion

      Grâce à leur flexibilité et à leur conception pour l’intégrité des données, les bases de données relationnelles sont toujours le principal moyen de gérer et de stocker les données plus de cinquante ans après leur conception. Même avec l’essor de diverses bases de données NoSQL ces dernières années, la compréhension du modèle relationnel et de la manière de travailler avec les SGBDR sont la clé pour tous ceux qui veulent construire des applications qui exploitent la puissance des données.

      Pour en savoir plus sur quelques SGBDR open source populaires, nous vous encourageons à consulter notre comparaison de différentes bases de données SQL relationnelles open-source. Si vous souhaitez en savoir plus sur les bases de données en général, nous vous encourageons à consulter notre bibliothèque complète de contenus liés aux bases de données.



      Source link

      Cómo administrar y usar activadores de bases de datos de MySQL en Ubuntu 18.04


      El autor seleccionó la Apache Software Foundation para recibir una donación como parte del programa Write for DOnations.

      Introducción

      En MySQL, un activador es un comando SQL definido por el usuario que se invoca automáticamente durante una operación INSERT, DELETE o UPDATE. El código de activación se asocia con una tabla y se destruye una vez que se elimina una tabla. Puede especificar un tiempo de acción de activación y establecer si esta se producirá antes o después del evento de base de datos definido.

      Los activadores tienen varias ventajas. Por ejemplo, puede usarlos para generar el valor de una columna derivada durante una instrucción INSERT. Otro caso de uso tiene que ver con la aplicación de la integridad referencial, en el que puede usar un activador para guardar un registro en varias tablas relacionadas. Entre otras ventajas, se incluyen el registro de las acciones del usuario para realizar una auditoría de las tablas, así como la copia en vivo de datos en diferentes esquemas de bases de datos por motivos de redundancia para evitar un único punto de fallo.

      También puede usar activadores para mantener las reglas de validación en el nivel de base de datos. Esto le permite compartir la fuente de datos en varias aplicaciones sin infringir la lógica de negocios. Con esto, se reducen en gran medida los recorridos de ida y vuelta al servidor de base de datos, lo cual a su vez mejora el tiempo de respuesta de sus aplicaciones. Debido a que en el servidor de base de datos se ejecutan activadores, se pueden aprovechar recursos mejorados de este, como la memoria RAM y el CPU.

      En este tutorial, creará, usará y eliminará diferentes tipos de activadores en su base de datos de MySQL.

      Requisitos previos

      Antes de comenzar, asegúrese de contar con lo siguiente:

      Paso 1: Crear una base de datos de ejemplo

      En este paso, creará una base de datos de clientes de ejemplo con varias tablas para demostrar el funcionamiento de los activadores de MySQL.

      Para obtener más información sobre consultas de MySQL, lea nuestra Introducción a las consultas de MySQL.

      Primero, inicie sesión en su servidor MySQL como root:

      Introduzca su contraseña root de MySQL cuando se le solicite y presione INTRO para continuar. Cuando visualice el intérprete de comandos de mysql>, ejecute el siguiente comando para crear una base de datos test_db:

      Output

      Query OK, 1 row affected (0.00 sec)

      A continuación, realice un cambio a test_db con lo siguiente:

      Output

      Database changed

      Comience creando una tabla customers. En esta tabla se almacenarán los registros de los clientes, incluidos customer_id, customer_name y level. Habrá dos niveles de cliente: BASIC y VIP.

      • Create table customers(customer_id BIGINT PRIMARY KEY, customer_name VARCHAR(50), level VARCHAR(50) ) ENGINE=INNODB;

      Output

      Query OK, 0 rows affected (0.01 sec)

      Ahora, añada algunos registros a la tabla customers. Para hacer esto, ejecute los siguientes comandos uno por uno:

      • Insert into customers (customer_id, customer_name, level )values('1','JOHN DOE','BASIC');
      • Insert into customers (customer_id, customer_name, level )values('2','MARY ROE','BASIC');
      • Insert into customers (customer_id, customer_name, level )values('3','JOHN DOE','VIP');

      Verá el siguiente resultado después de ejecutar cada uno de los comandos INSERT:

      Output

      Query OK, 1 row affected (0.01 sec)

      Para asegurarse de que los registros de ejemplo se hayan insertado correctamente, ejecute el comando SELECT:

      Output

      +-------------+---------------+-------+ | customer_id | customer_name | level | +-------------+---------------+-------+ | 1 | JOHN DOE | BASIC | | 2 | MARY ROE | BASIC | | 3 | JOHN DOE | VIP | +-------------+---------------+-------+ 3 rows in set (0.00 sec)

      También creará otra tabla para contener información relacionada con la cuenta customers. Esta tabla contendrá un campo customer_id y un campo status_notes.

      Ejecute el siguiente comando:

      • Create table customer_status(customer_id BIGINT PRIMARY KEY, status_notes VARCHAR(50)) ENGINE=INNODB;

      A continuación, creará una tabla sales. En esta tabla, se almacenarán datos de ventas relacionados con los diferentes clientes a través de la columna customer_id:

      • Create table sales(sales_id BIGINT PRIMARY KEY, customer_id BIGINT, sales_amount DOUBLE ) ENGINE=INNODB;

      Output

      Query OK, 0 rows affected (0.01 sec)

      En los próximos pasos, añadirá datos de ejemplo a los de sales mientras prueba los activadores. A continuación, cree una tabla audit_log para registrar las actualizaciones realizadas en la tabla sales cuando implemente el activador AFTER UPDATE en el paso 5:

      • Create table audit_log(log_id BIGINT PRIMARY KEY AUTO_INCREMENT, sales_id BIGINT, previous_amount DOUBLE, new_amount DOUBLE, updated_by VARCHAR(50), updated_on DATETIME ) ENGINE=INNODB;

      Output

      Query OK, 0 rows affected (0.02 sec)

      Una vez establecidas la base de datos test_db y las cuatro tablas, procederá a trabajar con los diferentes activadores de MySQL en su base de datos.

      Paso 2: Crear un activador “Before Insert”

      En este paso, examinará la sintaxis de un activador de MySQL antes de aplicar esta lógica para crear un activador BEFORE INSERT que valide el campo sales_amount cuando se inserten datos en la tabla sales.

      La sintaxis general para crear un activador de MySQL se muestra en el siguiente ejemplo:

      DELIMITER //
      CREATE TRIGGER [TRIGGER_NAME]
      [TRIGGER TIME] [TRIGGER EVENT]
      ON [TABLE]
      FOR EACH ROW
      [TRIGGER BODY]//
      DELIMITER ;
      

      En la estructura del activador se incluye lo siguiente:

      DELIMITER //: el delimitador predeterminado de MySQL es ;, es necesario cambiarlo por algo diferente para que MySQL trate las siguientes líneas como un comando hasta que alcance su delimitador personalizado. En este ejemplo, el delimitador se cambió a // y luego al final se redefinió el delimitador ;.

      [TRIGGER_NAME]: un activador debe contar con un nombre y aquí es donde debe incluir el valor.

      [TRIGGER TIME]: un activador se puede invocar en diferentes intervalos. En MySQL se le permite definir si el activador se iniciará antes o después de una operación de base de datos.

      [TRIGGER EVENT]: los activadores solo se pueden invocar con operaciones INSERT, UPDATE y DELETE. Aquí puede usar cualquier valor dependiendo de lo que quiera lograr.

      [TABLE]: cualquier activador que cree en su base de datos de MySQL debe estar asociado a una tabla.

      FOR EACH ROW: con esta instrucción se ordena a MySQL ejecutar el código de activación para cada fila afectada por el activador.

      [TRIGGER BODY]: el código que se ejecuta cuando se invoca el activador se conoce como cuerpo del activador. Puede constar de una sola instrucción SQL o de varios comandos. Tenga en cuenta que si ejecuta varias instrucciones SQL en el cuerpo del activador, debe ajustarlas entre un bloque BEGIN... END.

      Nota: Cuando cree el cuerpo del activador, puede usar las palabras claves OLD y NEW para acceder a los valores antiguos y nuevos de la columna introducidos durante una operación INSERT, UPDATE, y DELETE. En un activador DELETE, solo se puede emplear la palabra clave OLD (que usará en el paso 4).

      Ahora, creará su primer activador BEFORE INSERT. Este activador estará asociado con la tabla sales y se invocará antes de que se inserte un registro para validar sales_amount. La función del activador es verificar si el campo sales_amount que se inserta en la tabla “sales” es mayor que 10000 y mostrar un error si esto se evalúa a “true”.

      Asegúrese de haber iniciado sesión en el servidor de MySQL. Luego, introduzca los siguientes comandos MySQL uno por uno:

      • DELIMITER //
      • CREATE TRIGGER validate_sales_amount
      • BEFORE INSERT
      • ON sales
      • FOR EACH ROW
      • IF NEW.sales_amount>10000 THEN
      • SIGNAL SQLSTATE '45000'
      • SET MESSAGE_TEXT = 'Sale has exceeded the allowed amount of 10000.';
      • END IF//
      • DELIMITER ;

      Usará la instrucción IF...THEN...END IF para evaluar si la cantidad que se proporciona durante la instrucción INSERT se encuentra dentro de su rango. Con el activador se puede extraer el nuevo valor sales_amount proporcionado con la palabra clave NEW.

      Para mostrar un mensaje de error genérico, utilice las siguientes líneas a fin de informar al usuario sobre el error:

      SIGNAL SQLSTATE '45000'
      SET MESSAGE_TEXT = 'Sale has exceeded the allowed amount of 10000.';
      

      A continuación, inserte un registro con un sales_amount de 11000 en la tabla sales para verificar si con el activador se detendrá la operación:

      • Insert into sales(sales_id, customer_id, sales_amount) values('1','1','11000');

      Output

      ERROR 1644 (45000): Sale has exceeded the allowed amount of 10000.

      Este error muestra que el código de activación funciona según lo previsto.

      Ahora, pruebe un nuevo registro con un valor de 7500 para verificar si el comando tendrá éxito:

      • Insert into sales(sales_id, customer_id, sales_amount) values('1','1','7500');

      Debido a que el valor se encuentra dentro del rango recomendado, verá el siguiente resultado:

      Output

      Query OK, 1 row affected (0.01 sec)

      Para confirmar que se insertaron los datos, ejecute el siguiente comando:

      En el resultado, se confirma que los datos se encuentran en la tabla:

      Output

      +----------+-------------+--------------+ | sales_id | customer_id | sales_amount | +----------+-------------+--------------+ | 1 | 1 | 7500 | +----------+-------------+--------------+ 1 row in set (0.00 sec)

      En este paso, probó activadores para validar datos antes de su inserción en una base de datos.

      A continuación, trabajará con el activador AFTER INSERT para guardar información relacionada en diferentes tablas.

      Paso 3: Crear un activador “After Insert”

      Los activadores AFTER INSERT se ejecutan cuando se insertan registros correctamente en una tabla. Esta funcionalidad puede utilizarse para ejecutar automáticamente otras lógicas relacionadas con los negocios. Por ejemplo, en una aplicación bancaria, con un activador AFTER INSERT se puede cerrar una cuenta de préstamo cuando un cliente termina de pagarlo. El activador puede controlar todos los pagos introducidos en una tabla de transacciones y cerrar el préstamo automáticamente una vez que el saldo llegue a cero.

      En este paso, trabajará con su tabla customer_status usando un activador AFTER INSERT para ingresar registros de clientes relacionados.

      Para crear el activador AFTER INSERT, introduzca los siguientes comandos:

      • DELIMITER //
      • CREATE TRIGGER customer_status_records
      • AFTER INSERT
      • ON customers
      • FOR EACH ROW
      • Insert into customer_status(customer_id, status_notes) VALUES(NEW.customer_id, 'ACCOUNT OPENED SUCCESSFULLY')//
      • DELIMITER ;

      Output

      Query OK, 0 rows affected (0.00 sec)

      Aquí, indica que MySQL guarde otro registro en la tabla customer_status una vez que se inserte un nuevo registro de cliente en la tabla customers.

      Ahora, inserte un nuevo registro en la tabla customers para confirmar que se invocará su código de activación.

      • Insert into customers (customer_id, customer_name, level )values('4','DAVID DOE','VIP');

      Output

      Query OK, 1 row affected (0.01 sec)

      Debido a que el registro se insertó correctamente, compruebe que se haya introducido un nuevo registro de estado en la tabla customer_status:

      • Select * from customer_status;

      Output

      +-------------+-----------------------------+ | customer_id | status_notes | +-------------+-----------------------------+ | 4 | ACCOUNT OPENED SUCCESSFULLY | +-------------+-----------------------------+ 1 row in set (0.00 sec)

      En el resultado se confirma que el activador se ejecutó correctamente.

      El activador AFTER INSERT es útil para controlar el ciclo de vida de un cliente. En un entorno de producción, las cuentas de los clientes pueden atravesar diferentes etapas, como la apertura, la suspensión y el cierre.

      En los siguientes pasos, trabajará con activadores UPDATE.

      Paso 4: Crear un activador “Before Update”

      Los activadores BEFORE UPDATE son similares a los BEFORE INSERT; la diferencia radica en el momento en que se invocan. Puede usar el activador BEFORE UPDATE para verificar una lógica de negocios antes de que se actualice un registro. Para probar esto, usará la tabla customers en la que ya insertó datos.

      Dispone de dos niveles para sus clientes en la base de datos. En este ejemplo, una vez que la cuenta de un cliente asciende al nivel VIP, ya no es posible que descienda al nivel BASIC. Para aplicar tal regla, creará un activador BEFORE UPDATE que se ejecutará antes de la instrucción UPDATE, como se muestra a continuación. Si un usuario de la base de datos intenta hacer que un cliente descienda al nivel BASIC desde el nivel VIP, se activará una excepción definida por el usuario.

      Introduzca los siguientes comandos SQL uno por uno para crear el activador BEFORE UPDATE:

      • DELIMITER //
      • CREATE TRIGGER validate_customer_level
      • BEFORE UPDATE
      • ON customers
      • FOR EACH ROW
      • IF OLD.level='VIP' THEN
      • SIGNAL SQLSTATE '45000'
      • SET MESSAGE_TEXT = 'A VIP customer can not be downgraded.';
      • END IF //
      • DELIMITER ;

      Utilice la palabra clave OLD para capturar el nivel que el usuario proporciona cuando ejecuta el comando UPDATE. Una vez más, utilice la instrucción IF...THEN…END IF“ para indicar una instrucción de error genérico al usuario.

      Luego, ejecute el siguiente comando SQL con el que se intenta bajar el nivel de la cuenta de un usuario asociado con el customer_id de 3:

      • Update customers set level='BASIC' where customer_id='3';

      Verá el siguiente resultado, en el que se muestra SET MESSAGE_TEXT:

      Output

      ERROR 1644 (45000): A VIP customer can not be downgraded.

      Si ejecuta el mismo comando en un cliente de nivel BASIC e intenta que la cuenta ascienda al nivel VIP, el comando se ejecutará correctamente:

      • Update customers set level='VIP' where customer_id='1';

      Output

      Rows matched: 1 Changed: 1 Warnings: 0

      Usó el activador BEFORE UPDATE para implementar una regla comercial. Ahora, usará un activador AFTER UPDATE para registros de auditoría.

      Paso 5: Crear un activador “After Update”

      Un activador AFTER UPDATE se invoca una vez que se actualiza correctamente el registro de una base de datos. Este comportamiento hace que el activador sea adecuado para los registros de auditoría. En un entorno multiusuario, es posible que el administrador quiera ver el historial de los usuarios que actualizan registros en una tabla en particular para auditorías.

      Creará un activador que registre la actividad de actualización de la tabla sales. Nuestra tabla audit_log contendrá información sobre los usuarios de MySQL que actualicen la tabla sales, la date de la actualización y los valores sales_amount de new y old.

      Para crear el activador, ejecute los siguientes comandos SQL:

      • DELIMITER //
      • CREATE TRIGGER log_sales_updates
      • AFTER UPDATE
      • ON sales
      • FOR EACH ROW
      • Insert into audit_log(sales_id, previous_amount, new_amount, updated_by, updated_on) VALUES (NEW.sales_id,OLD.sales_amount, NEW.sales_amount,(SELECT USER()), NOW() )//
      • DELIMITER ;

      Se ingresa un nuevo registro en la tabla audit_log. Utilice la palabra clave NEW para obtener el valor de sales_id y el nuevo sales_amount. Además, utilice la palabra clave OLD para obtener el sales_amount anterior, ya que desea registrar ambos montos para auditoría.

      Con el comando SELECT USER() se obtiene el usuario actual que realiza la operación y con la instrucción NOW() se obtiene el valor de la fecha y hora actuales del servidor de MySQL.

      Si ahora un usuario intenta actualizar el valor de cualquier registro en la tabla sales, el activador log_sales_updates insertará un nuevo registro en la tabla audit_log.

      Crearemos un nuevo registro de ventas con un sales_id aleatorio de 5 e intentaremos actualizarlo. Primero, inserte el registro de ventas con lo siguiente:

      • Insert into sales(sales_id, customer_id, sales_amount) values('5', '2','8000');

      Output

      Query OK, 1 row affected (0.00 sec)

      A continuación, actualice el registro:

      • Update sales set sales_amount='9000' where sales_id='5';

      Verá el siguiente resultado:

      Output

      Rows matched: 1 Changed: 1 Warnings: 0

      Ahora ejecute el siguiente comando para verificar si con el activador AFTER UPDATE se pudo introducir un nuevo registro en la tabla audit_log:

      En el activador se registró la actualización. En el resultado se muestran el sales_amount y el new amount anteriores registrados con el usuario que actualizó los registros:

      Output

      +--------+----------+-----------------+------------+----------------+---------------------+ | log_id | sales_id | previous_amount | new_amount | updated_by | updated_on | +--------+----------+-----------------+------------+----------------+---------------------+ | 1 | 5 | 8000 | 9000 | root@localhost | 2019-11-07 09:28:36 | +--------+----------+-----------------+------------+----------------+---------------------+ 1 row in set (0.00 sec)

      También dispone de la fecha y hora en las que se realizó la actualización, que son valiosas para auditorías.

      A continuación, usará el activador DELETE para aplicar la integridad referencial a nivel de base de datos.

      Paso 6: Crear un activador “Before Delete”

      Los activadores BEFORE DELETE se invocan antes de que se ejecute una instrucción DELETE en una tabla. Estos tipos de activadores normalmente se utilizan para implementar la integridad referencial en diferentes tablas relacionadas. Por ejemplo, cada registro de la tabla sales se relaciona a un customer_id de la tabla customers. Si un usuario de la base de datos eliminara un registro de la tabla customers que tiene un registro relacionado en la tabla sales, usted no tendría manera de conocer al cliente asociado a ese registro.

      A fin de evitar esto, puede crear un activador BEFORE DELETE para aplicar su lógica. Ejecute los siguientes comandos SQL uno por uno:

      • DELIMITER //
      • CREATE TRIGGER validate_related_records
      • BEFORE DELETE
      • ON customers
      • FOR EACH ROW
      • IF OLD.customer_id in (select customer_id from sales) THEN
      • SIGNAL SQLSTATE '45000'
      • SET MESSAGE_TEXT = 'The customer has a related sales record.';
      • END IF//
      • DELIMITER ;

      Ahora, intente eliminar un cliente que tenga un registro de ventas relacionado:

      • Delete from customers where customer_id='2';

      Como resultado, obtendrá lo siguiente:

      Output

      ERROR 1644 (45000): The customer has a related sales record.

      Con el activador BEFORE DELETE se puede evitar la eliminación accidental de información relacionada en una base de datos.

      Sin embargo, en algunas situaciones, es posible que quiera eliminar todos los registros asociados con un registro específico de las diferentes tablas relacionadas. En este caso, usaría el activador AFTER DELETE, que probará en el siguiente paso.

      Paso 7: Crear un activador “After Delete”

      Los activadores AFTER DELETE funcionan una vez que se elimina correctamente un registro. Un ejemplo de cómo puede usar un activador AFTER DELETE es una situación en la cual el nivel de descuento que recibe un cliente en particular se determina mediante el número de ventas realizadas durante un período definido. Si alguno de los registros del cliente se eliminan de la tabla sales, el nivel de descuento de este deberá reducirse.

      Otro uso del activador AFTER DELETE consiste en eliminar información relacionada de otra tabla una vez que se elimina un registro de una tabla básica. Por ejemplo, establecerá un activador con el que se elimine el registro del cliente si los registros de ventas con los customer_id relacionados se eliminan de la tabla sales. Ejecute el siguiente comando para crear su activador:

      • DELIMITER //
      • CREATE TRIGGER delete_related_info
      • AFTER DELETE
      • ON sales
      • FOR EACH ROW
      • Delete from customers where customer_id=OLD.customer_id;//
      • DELIMITER ;

      A continuación, ejecute lo siguiente para eliminar todos los registros de ventas asociados con un customer_id de 2:

      • Delete from sales where customer_id='2';

      Output

      Query OK, 1 row affected (0.00 sec)

      Ahora compruebe si hay registros para el cliente en la tabla sales:

      • Select * from customers where customer_id='2';

      Obtendrá un resultado Empty Set, ya que el activador eliminó el registro del cliente asociado con el customer_id de 2:

      Output

      Empty set (0.00 sec)

      Con esto, habrá usado cada una de las diferentes formas de activadores para realizar funciones específicas. A continuación, verá la manera de eliminar un activador de la base de datos si ya no lo necesita.

      Paso 8: Eliminar activadores

      Con un método similar al que se emplea para cualquier otro objeto de base de datos, puede eliminar los activadores usando el comando DROP. A continuación, se muestra la sintaxis para eliminar un activador:

      Drop trigger [TRIGGER NAME];
      

      Por ejemplo, para eliminar el último activador AFTER DELETE que creó, ejecute el siguiente comando:

      • Drop trigger delete_related_info;

      Output

      Query OK, 0 rows affected (0.00 sec)

      La necesidad de eliminar los activadores surge cuando desea recrear su estructura. En tal caso, puede eliminar el activador y redefinir uno nuevo con los diferentes comandos de activación.

      Conclusión

      A través de este tutorial, creó, utilizó y eliminó los diferentes tipos de activadores de una base de datos de MySQL. Usando un ejemplo de base de datos relacionada con los clientes, implementó activadores para diferentes casos de uso, como la validación de datos, la aplicación de lógica de negocios, el registro de auditorías y la aplicación de integridad referencial.

      Para obtener más información sobre el uso de su base de datos de MySQL, consulte lo siguiente:



      Source link