En informática , una base de datos es una colección organizada de datos o un tipo de almacenamiento de datos basado en el uso de un sistema de gestión de bases de datos ( DBMS ), el software que interactúa con los usuarios finales , las aplicaciones y la propia base de datos para capturar y analizar los datos. El DBMS también abarca las instalaciones básicas proporcionadas para administrar la base de datos. La suma total de la base de datos, el DBMS y las aplicaciones asociadas se puede denominar un sistema de base de datos . A menudo, el término "base de datos" también se usa de manera vaga para referirse a cualquiera de los DBMS, el sistema de base de datos o una aplicación asociada con la base de datos.
Las bases de datos pequeñas se pueden almacenar en un sistema de archivos , mientras que las bases de datos grandes se alojan en clústeres de computadoras o en almacenamiento en la nube . El diseño de bases de datos abarca técnicas formales y consideraciones prácticas, que incluyen modelado de datos , representación y almacenamiento eficientes de datos, lenguajes de consulta , seguridad y privacidad de datos confidenciales y cuestiones de computación distribuida , incluido el soporte de acceso concurrente y tolerancia a fallas .
Los informáticos pueden clasificar los sistemas de gestión de bases de datos según los modelos de base de datos que admiten. Las bases de datos relacionales se volvieron dominantes en la década de 1980. Estas modelan los datos como filas y columnas en una serie de tablas , y la gran mayoría utiliza SQL para escribir y consultar datos. En la década de 2000, las bases de datos no relacionales se hicieron populares, denominadas colectivamente NoSQL , porque utilizan diferentes lenguajes de consulta .
Formalmente, una "base de datos" se refiere a un conjunto de datos relacionados a los que se accede mediante el uso de un "sistema de gestión de bases de datos" (DBMS), que es un conjunto integrado de software informático que permite a los usuarios interactuar con una o más bases de datos y proporciona acceso a todos los datos contenidos en la base de datos (aunque pueden existir restricciones que limiten el acceso a datos particulares). El DBMS proporciona varias funciones que permiten la entrada, el almacenamiento y la recuperación de grandes cantidades de información y proporciona formas de gestionar cómo se organiza esa información.
Debido a la estrecha relación que existe entre ellos, el término "base de datos" se utiliza a menudo de manera informal para referirse tanto a una base de datos como al DBMS utilizado para manipularla.
Fuera del mundo de la tecnología de la información profesional , el término base de datos se utiliza a menudo para referirse a cualquier recopilación de datos relacionados (como una hoja de cálculo o un índice de tarjetas), ya que los requisitos de tamaño y uso normalmente requieren el uso de un sistema de gestión de bases de datos. [1]
Los DBMS existentes proporcionan diversas funciones que permiten la gestión de una base de datos y sus datos que pueden clasificarse en cuatro grupos funcionales principales:
Tanto una base de datos como su DBMS se ajustan a los principios de un modelo de base de datos particular . [5] "Sistema de base de datos" se refiere colectivamente al modelo de base de datos, al sistema de gestión de base de datos y a la base de datos. [6]
Físicamente, los servidores de bases de datos son computadoras dedicadas que contienen las bases de datos reales y ejecutan solo el DBMS y el software relacionado. Los servidores de bases de datos suelen ser computadoras multiprocesador , con memoria generosa y matrices de discos RAID que se utilizan para un almacenamiento estable. Los aceleradores de bases de datos de hardware, conectados a uno o más servidores a través de un canal de alta velocidad, también se utilizan en entornos de procesamiento de transacciones de gran volumen . Los DBMS se encuentran en el corazón de la mayoría de las aplicaciones de bases de datos . Los DBMS pueden construirse alrededor de un núcleo multitarea personalizado con soporte de red integrado , pero los DBMS modernos generalmente dependen de un sistema operativo estándar para proporcionar estas funciones. [ cita requerida ]
Dado que los DBMS constituyen un mercado importante , los proveedores de computadoras y almacenamiento a menudo tienen en cuenta los requisitos de DBMS en sus propios planes de desarrollo. [7]
Las bases de datos y los DBMS se pueden clasificar según los modelos de base de datos que admiten (como relacional o XML ), los tipos de computadora en los que se ejecutan (desde un clúster de servidores hasta un teléfono móvil ), los lenguajes de consulta utilizados para acceder a la base de datos (como SQL o XQuery ) y su ingeniería interna, que afecta el rendimiento, la escalabilidad , la resiliencia y la seguridad.
Los tamaños, capacidades y rendimiento de las bases de datos y sus respectivos DBMS han crecido en órdenes de magnitud. Estos aumentos de rendimiento fueron posibles gracias al progreso tecnológico en las áreas de procesadores , memoria de computadora , almacenamiento de computadora y redes de computadoras . El concepto de una base de datos fue posible gracias a la aparición de medios de almacenamiento de acceso directo, como discos magnéticos , que se volvieron ampliamente disponibles a mediados de la década de 1960; los sistemas anteriores dependían del almacenamiento secuencial de datos en cinta magnética . El desarrollo posterior de la tecnología de bases de datos se puede dividir en tres eras basadas en el modelo o estructura de datos: navegacional , [8] SQL/ relacional y posrelacional.
Los dos primeros modelos de datos de navegación principales fueron el modelo jerárquico y el modelo CODASYL ( modelo de red ). Estos se caracterizaban por el uso de punteros (a menudo direcciones de discos físicos) para seguir las relaciones de un registro a otro.
El modelo relacional , propuesto por primera vez en 1970 por Edgar F. Codd , se apartó de esta tradición al insistir en que las aplicaciones deberían buscar datos por contenido, en lugar de seguir enlaces. El modelo relacional emplea conjuntos de tablas de estilo libro mayor, cada una utilizada para un tipo diferente de entidad . Solo a mediados de la década de 1980, el hardware informático se volvió lo suficientemente potente como para permitir la amplia implementación de sistemas relacionales (DBMS más aplicaciones). Sin embargo, a principios de la década de 1990, los sistemas relacionales dominaban en todas las aplicaciones de procesamiento de datos a gran escala y, a partir de 2018 , [actualizar]siguen siendo dominantes: IBM Db2 , Oracle , MySQL y Microsoft SQL Server son los DBMS más buscados . [9] El lenguaje de base de datos dominante, SQL estandarizado para el modelo relacional, ha influido en los lenguajes de base de datos para otros modelos de datos. [ cita requerida ]
Las bases de datos de objetos se desarrollaron en la década de 1980 para superar el inconveniente del desajuste de impedancia objeto-relacional , lo que llevó a la acuñación del término "post-relacional" y también al desarrollo de bases de datos híbridas objeto-relacionales .
La siguiente generación de bases de datos posrelacionales de finales de los años 2000 se conoció como bases de datos NoSQL , que introdujeron almacenes rápidos de clave-valor y bases de datos orientadas a documentos . Una "próxima generación" competidora, conocida como bases de datos NewSQL , intentó nuevas implementaciones que conservaban el modelo relacional/SQL, pero que al mismo tiempo apuntaban a igualar el alto rendimiento de NoSQL en comparación con los DBMS relacionales disponibles comercialmente.
La introducción del término base de datos coincidió con la disponibilidad de almacenamiento de acceso directo (discos y tambores) a partir de mediados de la década de 1960. El término representaba un contraste con los sistemas basados en cinta del pasado, permitiendo un uso interactivo compartido en lugar del procesamiento por lotes diario . El Oxford English Dictionary cita un informe de 1962 de la System Development Corporation de California como el primero en utilizar el término "base de datos" en un sentido técnico específico. [10]
A medida que las computadoras crecieron en velocidad y capacidad, surgieron varios sistemas de bases de datos de propósito general; a mediados de la década de 1960, varios de estos sistemas habían comenzado a usarse comercialmente. El interés en un estándar comenzó a crecer y Charles Bachman , autor de uno de esos productos, el Integrated Data Store (IDS), fundó el Database Task Group dentro de CODASYL , el grupo responsable de la creación y estandarización de COBOL . En 1971, el Database Task Group presentó su estándar, que generalmente se conoció como el enfoque CODASYL , y pronto ingresaron al mercado varios productos comerciales basados en este enfoque.
El método CODASYL ofrecía a las aplicaciones la posibilidad de navegar por un conjunto de datos vinculados que se formaban en una gran red. Las aplicaciones podían encontrar registros mediante uno de tres métodos:
Los sistemas posteriores añadieron árboles B para proporcionar rutas de acceso alternativas. Muchas bases de datos CODASYL también añadieron un lenguaje de consulta declarativo para los usuarios finales (a diferencia de la API de navegación ). Sin embargo, las bases de datos CODASYL eran complejas y requerían de una formación y un esfuerzo importantes para producir aplicaciones útiles.
IBM también tenía su propio DBMS en 1966, conocido como Information Management System (IMS). IMS fue un desarrollo de software escrito para el programa Apollo en el System/360 . IMS era generalmente similar en concepto a CODASYL, pero utilizaba una jerarquía estricta para su modelo de navegación de datos en lugar del modelo de red de CODASYL. Ambos conceptos luego se conocieron como bases de datos de navegación debido a la forma en que se accedía a los datos: el término se popularizó con la presentación del Premio Turing de Bachman en 1973, The Programmer as Navigator . IMS está clasificado por IBM como una base de datos jerárquica . Las bases de datos IDMS y TOTAL de Cincom Systems están clasificadas como bases de datos de red. IMS sigue en uso a partir de 2014. [ 11][actualizar]
Edgar F. Codd trabajó en IBM en San José, California , en una de sus sucursales que se dedicaban principalmente al desarrollo de sistemas de disco duro . No estaba satisfecho con el modelo de navegación del enfoque CODASYL, en particular con la falta de una función de "búsqueda". En 1970, escribió una serie de artículos que describían un nuevo enfoque para la construcción de bases de datos que finalmente culminó en el innovador A Relational Model of Data for Large Shared Data Banks . [12]
En este artículo, describió un nuevo sistema para almacenar y trabajar con grandes bases de datos. En lugar de almacenar los registros en una especie de lista enlazada de registros de formato libre como en CODASYL, la idea de Codd era organizar los datos como una serie de " tablas ", cada tabla se utilizaba para un tipo diferente de entidad. Cada tabla contendría un número fijo de columnas que contenían los atributos de la entidad. Una o más columnas de cada tabla se designaban como una clave principal mediante la cual las filas de la tabla podían identificarse de forma única; las referencias cruzadas entre tablas siempre utilizaban estas claves principales, en lugar de direcciones de disco, y las consultas unirían las tablas en función de estas relaciones clave, utilizando un conjunto de operaciones basadas en el sistema matemático de cálculo relacional (del que el modelo toma su nombre). La división de los datos en un conjunto de tablas normalizadas (o relaciones ) tenía como objetivo garantizar que cada "hecho" solo se almacenara una vez, simplificando así las operaciones de actualización. Las tablas virtuales llamadas vistas podían presentar los datos de diferentes maneras para diferentes usuarios, pero las vistas no podían actualizarse directamente.
Codd utilizó términos matemáticos para definir el modelo: relaciones, tuplas y dominios en lugar de tablas, filas y columnas. La terminología que hoy nos resulta familiar proviene de las primeras implementaciones. Codd criticaría más tarde la tendencia de las implementaciones prácticas a alejarse de los fundamentos matemáticos en los que se basaba el modelo.
El uso de claves primarias (identificadores orientados al usuario) para representar relaciones entre tablas, en lugar de direcciones de disco, tenía dos motivaciones principales. Desde una perspectiva de ingeniería, permitía reubicar y redimensionar las tablas sin una costosa reorganización de la base de datos. Pero Codd estaba más interesado en la diferencia en la semántica: el uso de identificadores explícitos facilitaba la definición de operaciones de actualización con definiciones matemáticas claras, y también permitía definir operaciones de consulta en términos de la disciplina establecida del cálculo de predicados de primer orden ; debido a que estas operaciones tienen propiedades matemáticas claras, se hace posible reescribir consultas de formas demostrablemente correctas, que es la base de la optimización de consultas. No hay pérdida de expresividad en comparación con los modelos jerárquicos o de red, aunque las conexiones entre tablas ya no son tan explícitas.
En los modelos jerárquicos y de red, se permitía que los registros tuvieran una estructura interna compleja. Por ejemplo, el historial salarial de un empleado podía representarse como un "grupo repetitivo" dentro del registro del empleado. En el modelo relacional, el proceso de normalización llevó a que dichas estructuras internas fueran reemplazadas por datos almacenados en múltiples tablas, conectadas solo por claves lógicas.
Por ejemplo, un uso común de un sistema de base de datos es el de rastrear información sobre los usuarios, su nombre, información de inicio de sesión, diversas direcciones y números de teléfono. En el enfoque de navegación, todos estos datos se colocarían en un único registro de longitud variable. En el enfoque relacional, los datos se normalizarían en una tabla de usuarios, una tabla de direcciones y una tabla de números de teléfono (por ejemplo). Los registros se crearían en estas tablas opcionales solo si se proporcionaran realmente la dirección o los números de teléfono.
Además de identificar filas y registros mediante identificadores lógicos en lugar de direcciones de disco, Codd cambió la forma en que las aplicaciones ensamblaban datos de múltiples registros. En lugar de requerir que las aplicaciones recopilaran datos de un registro a la vez navegando por los vínculos, utilizarían un lenguaje de consulta declarativo que expresara qué datos se necesitaban, en lugar de la ruta de acceso mediante la cual se debían encontrar. Encontrar una ruta de acceso eficiente a los datos pasó a ser responsabilidad del sistema de administración de bases de datos, en lugar del programador de aplicaciones. Este proceso, llamado optimización de consultas, dependía del hecho de que las consultas se expresaban en términos de lógica matemática.
El artículo de Codd fue retomado por dos personas de Berkeley, Eugene Wong y Michael Stonebraker . Comenzaron un proyecto conocido como INGRES utilizando fondos que ya se habían asignado para un proyecto de base de datos geográfica y programadores estudiantes para producir código. A principios de 1973, INGRES entregó sus primeros productos de prueba que, en general, estaban listos para su uso generalizado en 1979. INGRES era similar a System R en varios aspectos, incluido el uso de un "lenguaje" para el acceso a los datos , conocido como QUEL . Con el tiempo, INGRES se trasladó al estándar SQL emergente.
IBM realizó una implementación de prueba del modelo relacional, PRTV , y una de producción, Business System 12 , ambas actualmente descontinuadas. Honeywell escribió MRDS para Multics , y ahora hay dos nuevas implementaciones: Alphora Dataphor y Rel. La mayoría de las otras implementaciones de DBMS que normalmente se denominan relacionales son en realidad DBMS SQL.
En 1970, la Universidad de Michigan comenzó a desarrollar el Sistema de Gestión de Información MICRO [13] basado en el modelo de datos de teoría de conjuntos de DL Childs . [14] [15] [16] MICRO fue utilizado para gestionar conjuntos de datos muy grandes por el Departamento de Trabajo de los EE. UU. , la Agencia de Protección Ambiental de los EE. UU. e investigadores de la Universidad de Alberta , la Universidad de Michigan y la Universidad Estatal de Wayne . Se ejecutaba en computadoras mainframe de IBM utilizando el Sistema de Terminal de Michigan . [17] El sistema permaneció en producción hasta 1998.
En los años 1970 y 1980, se intentó construir sistemas de bases de datos con hardware y software integrados. La filosofía subyacente era que dicha integración proporcionaría un mayor rendimiento a un menor costo. Algunos ejemplos fueron IBM System/38 , la primera oferta de Teradata y la máquina de base de datos de Britton Lee, Inc.
Otro enfoque para el soporte de hardware para la gestión de bases de datos fue el acelerador CAFS de ICL , un controlador de disco de hardware con capacidades de búsqueda programables. A largo plazo, estos esfuerzos generalmente no tuvieron éxito porque las máquinas de bases de datos especializadas no podían seguir el ritmo del rápido desarrollo y progreso de las computadoras de propósito general. Por lo tanto, la mayoría de los sistemas de bases de datos actuales son sistemas de software que se ejecutan en hardware de propósito general, utilizando almacenamiento de datos de computadora de propósito general. Sin embargo, esta idea todavía se persigue en ciertas aplicaciones por parte de algunas empresas como Netezza y Oracle ( Exadata ).
IBM comenzó a trabajar en un sistema prototipo basado libremente en los conceptos de Codd, el System R, a principios de los años 70. La primera versión estuvo lista en 1974/5, y luego se empezó a trabajar en sistemas multitabla en los que los datos se podían dividir de modo que todos los datos de un registro (algunos de los cuales son opcionales) no tuvieran que almacenarse en un único "fragmento" grande. Los clientes probaron versiones multiusuario posteriores en 1978 y 1979, momento en el que se había añadido un lenguaje de consulta estandarizado , SQL [ cita requerida ] . Las ideas de Codd se estaban consolidando como viables y superiores a CODASYL, lo que empujó a IBM a desarrollar una verdadera versión de producción de System R, conocida como SQL/DS y, más tarde, Database 2 ( IBM Db2 ).
La base de datos Oracle de Larry Ellison (o más simplemente, Oracle ) comenzó a partir de una cadena diferente, basada en los documentos de IBM sobre System R. Aunque las implementaciones de Oracle V1 se completaron en 1978, no fue hasta Oracle Versión 2 cuando Ellison superó a IBM en el mercado en 1979. [18]
Stonebraker aplicó las lecciones de INGRES para desarrollar una nueva base de datos, Postgres, que ahora se conoce como PostgreSQL . PostgreSQL se utiliza a menudo para aplicaciones globales de misión crítica (los registros de nombres de dominio .org y .info lo utilizan como su principal almacén de datos , al igual que muchas grandes empresas e instituciones financieras).
En Suecia, el artículo de Codd también se leyó y Mimer SQL se desarrolló a mediados de los años 70 en la Universidad de Uppsala . En 1984, este proyecto se consolidó como una empresa independiente.
En 1976 surgió otro modelo de datos, el modelo entidad-relación , que ganó popularidad para el diseño de bases de datos , ya que enfatizaba una descripción más familiar que el modelo relacional anterior. Más tarde, las construcciones entidad-relación se adaptaron como una construcción de modelado de datos para el modelo relacional, y la diferencia entre los dos se volvió irrelevante. [ cita requerida ]
La década de 1980 marcó el comienzo de la era de la informática de escritorio . Las nuevas computadoras permitieron a sus usuarios contar con hojas de cálculo como Lotus 1-2-3 y software de bases de datos como dBASE . El producto dBASE era liviano y fácil de entender para cualquier usuario de computadora desde el primer momento. C. Wayne Ratliff , el creador de dBASE, afirmó: "dBASE se diferenciaba de programas como BASIC, C, FORTRAN y COBOL en que gran parte del trabajo sucio ya se había hecho. La manipulación de datos la realiza dBASE en lugar de hacerlo el usuario, por lo que el usuario puede concentrarse en lo que está haciendo, en lugar de tener que lidiar con los detalles sucios de abrir, leer y cerrar archivos y administrar la asignación de espacio". [19] dBASE fue uno de los títulos de software más vendidos en la década de 1980 y principios de la de 1990.
En la década de 1990, junto con el auge de la programación orientada a objetos , se produjo un crecimiento en la forma en que se manejaban los datos en varias bases de datos. Los programadores y diseñadores comenzaron a tratar los datos de sus bases de datos como objetos . Es decir, si los datos de una persona estaban en una base de datos, los atributos de esa persona, como su dirección, número de teléfono y edad, ahora se consideraban que pertenecían a esa persona en lugar de ser datos extraños. Esto permite que las relaciones entre los datos se relacionen con los objetos y sus atributos y no con campos individuales. [20] El término " desajuste de impedancia objeto-relacional " describió el inconveniente de traducir entre objetos programados y tablas de bases de datos. Las bases de datos de objetos y las bases de datos objeto-relacionales intentan resolver este problema proporcionando un lenguaje orientado a objetos (a veces como extensiones de SQL) que los programadores pueden usar como alternativa al SQL puramente relacional. En el lado de la programación, las bibliotecas conocidas como mapeos objeto-relacionales (ORM) intentan resolver el mismo problema.
Las bases de datos XML son un tipo de base de datos orientada a documentos estructurados que permite realizar consultas basadas en atributos de documentos XML . Las bases de datos XML se utilizan principalmente en aplicaciones en las que los datos se visualizan cómodamente como una colección de documentos, con una estructura que puede variar desde muy flexible hasta muy rígida: algunos ejemplos incluyen artículos científicos, patentes, declaraciones de impuestos y registros de personal.
Las bases de datos NoSQL suelen ser muy rápidas, no requieren esquemas de tablas fijos, evitan operaciones de unión al almacenar datos desnormalizados y están diseñadas para escalar horizontalmente .
En los últimos años, ha habido una fuerte demanda de bases de datos distribuidas masivamente con alta tolerancia a la partición, pero según el teorema CAP , es imposible que un sistema distribuido proporcione simultáneamente garantías de consistencia , disponibilidad y tolerancia a la partición. Un sistema distribuido puede satisfacer dos de estas garantías al mismo tiempo, pero no las tres. Por esa razón, muchas bases de datos NoSQL están utilizando lo que se denomina consistencia eventual para proporcionar garantías tanto de disponibilidad como de tolerancia a la partición con un nivel reducido de consistencia de datos.
NewSQL es una clase de bases de datos relacionales modernas que tiene como objetivo proporcionar el mismo rendimiento escalable de los sistemas NoSQL para cargas de trabajo de procesamiento de transacciones en línea (lectura-escritura) mientras sigue utilizando SQL y mantiene las garantías ACID de un sistema de base de datos tradicional.
Las bases de datos se utilizan para respaldar las operaciones internas de las organizaciones y respaldar las interacciones en línea con clientes y proveedores (consulte Software empresarial ).
Las bases de datos se utilizan para almacenar información administrativa y datos más especializados, como datos de ingeniería o modelos económicos. Algunos ejemplos son los sistemas informáticos de bibliotecas , los sistemas de reserva de vuelos , los sistemas informáticos de inventario de piezas y muchos sistemas de gestión de contenido que almacenan sitios web como colecciones de páginas web en una base de datos.
Una forma de clasificar las bases de datos es según el tipo de contenido, por ejemplo: bibliográficas , de texto documental, estadísticas o de objetos multimedia. Otra forma es según su área de aplicación, por ejemplo: contabilidad, composiciones musicales, películas, banca, fabricación o seguros. Una tercera forma es según algún aspecto técnico, como la estructura de la base de datos o el tipo de interfaz. En esta sección se enumeran algunos de los adjetivos que se utilizan para caracterizar los diferentes tipos de bases de datos.
Connolly y Begg definen el sistema de gestión de bases de datos (DBMS) como un "sistema de software que permite a los usuarios definir, crear, mantener y controlar el acceso a la base de datos". [24] Algunos ejemplos de DBMS son MySQL , MariaDB , PostgreSQL , Microsoft SQL Server , Oracle Database y Microsoft Access .
El acrónimo DBMS se extiende a veces para indicar el modelo de base de datos subyacente , con RDBMS para el relacional , OODBMS para el orientado a objetos y ORDBMS para el modelo objeto-relacional . Otras extensiones pueden indicar otras características, como DDBMS para sistemas de gestión de bases de datos distribuidos.
La funcionalidad que ofrece un DBMS puede variar enormemente. La funcionalidad principal es el almacenamiento, la recuperación y la actualización de datos. Codd propuso las siguientes funciones y servicios que debería proporcionar un DBMS de propósito general completo: [25]
También se espera generalmente que el DBMS proporcione un conjunto de utilidades para los fines que puedan ser necesarios para administrar la base de datos de manera efectiva, incluidas utilidades de importación, exportación, monitoreo, desfragmentación y análisis. [26] La parte central del DBMS que interactúa entre la base de datos y la interfaz de la aplicación a veces se denomina motor de base de datos .
A menudo, los DBMS tienen parámetros de configuración que se pueden ajustar de forma estática y dinámica, por ejemplo, la cantidad máxima de memoria principal de un servidor que puede utilizar la base de datos. La tendencia es minimizar la cantidad de configuración manual y, en casos como el de las bases de datos integradas, la necesidad de apuntar a la administración cero es primordial.
Los grandes DBMS empresariales han tendido a aumentar en tamaño y funcionalidad y han requerido hasta miles de años humanos de esfuerzo de desarrollo a lo largo de su existencia. [a]
Los primeros DBMS multiusuario normalmente solo permitían que la aplicación residiera en la misma computadora con acceso a través de terminales o software de emulación de terminal. La arquitectura cliente-servidor fue un desarrollo en el que la aplicación residía en un escritorio cliente y la base de datos en un servidor, lo que permitía distribuir el procesamiento. Esto evolucionó hacia una arquitectura de múltiples niveles que incorpora servidores de aplicaciones y servidores web con la interfaz de usuario final a través de un navegador web con la base de datos conectada directamente solo al nivel adyacente. [28]
Un DBMS de propósito general proporcionará interfaces de programación de aplicaciones (API) públicas y, opcionalmente, un procesador para lenguajes de bases de datos como SQL, para permitir que se escriban aplicaciones que interactúen con la base de datos y la manipulen. Un DBMS de propósito especial puede utilizar una API privada y personalizarse y vincularse específicamente a una sola aplicación. Por ejemplo, un sistema de correo electrónico realiza muchas de las funciones de un DBMS de propósito general, como la inserción de mensajes, la eliminación de mensajes, el manejo de archivos adjuntos, la búsqueda en listas de bloqueo, la asociación de mensajes a una dirección de correo electrónico, etc.; sin embargo, estas funciones se limitan a lo que se requiere para manejar el correo electrónico.
La interacción externa con la base de datos se realizará a través de un programa de aplicación que interactúe con el DBMS. [29] Esto puede variar desde una herramienta de base de datos que permite a los usuarios ejecutar consultas SQL de forma textual o gráfica, hasta un sitio web que utiliza una base de datos para almacenar y buscar información.
Un programador codificará las interacciones con la base de datos (a veces denominada fuente de datos ) a través de una interfaz de programación de aplicaciones ( API) o mediante un lenguaje de base de datos. La API o el lenguaje en particular elegidos deberán ser compatibles con el DBMS, posiblemente de forma indirecta a través de un preprocesador o una API de enlace. Algunas API tienen como objetivo ser independientes de la base de datos, siendo ODBC un ejemplo conocido. Otras API comunes incluyen JDBC y ADO.NET .
Los lenguajes de bases de datos son lenguajes de propósito especial, que permiten una o más de las siguientes tareas, a veces distinguidas como sublenguajes :
Los lenguajes de bases de datos son específicos de un modelo de datos en particular. Algunos ejemplos destacados son:
Un lenguaje de base de datos también puede incorporar características como:
El almacenamiento de la base de datos es el contenedor de la materialización física de una base de datos. Comprende el nivel interno (físico) en la arquitectura de la base de datos. También contiene toda la información necesaria (por ejemplo, metadatos , "datos sobre los datos" y estructuras de datos internas ) para reconstruir el nivel conceptual y el nivel externo a partir del nivel interno cuando sea necesario. Las bases de datos como objetos digitales contienen tres capas de información que deben almacenarse: los datos, la estructura y la semántica. El almacenamiento adecuado de las tres capas es necesario para la preservación futura y la longevidad de la base de datos. [33] Colocar los datos en un almacenamiento permanente es generalmente responsabilidad del motor de la base de datos, también conocido como "motor de almacenamiento". Aunque un DBMS normalmente accede a ellos a través del sistema operativo subyacente (y a menudo utilizando los sistemas de archivos de los sistemas operativos como intermediarios para el diseño del almacenamiento), las propiedades de almacenamiento y las configuraciones son extremadamente importantes para el funcionamiento eficiente del DBMS y, por lo tanto, son mantenidas de cerca por los administradores de la base de datos. Un DBMS, mientras está en funcionamiento, siempre tiene su base de datos residiendo en varios tipos de almacenamiento (por ejemplo, memoria y almacenamiento externo). Los datos de la base de datos y la información adicional necesaria, posiblemente en cantidades muy grandes, se codifican en bits. Los datos suelen residir en el almacenamiento en estructuras que tienen un aspecto completamente diferente al de los datos en los niveles conceptual y externo, pero de forma que se intenta optimizar (lo mejor posible) la reconstrucción de estos niveles cuando lo necesitan los usuarios y los programas, así como para calcular tipos adicionales de información necesaria a partir de los datos (por ejemplo, al consultar la base de datos).
Algunos DBMS permiten especificar qué codificación de caracteres se utilizó para almacenar datos, de modo que se pueden utilizar múltiples codificaciones en la misma base de datos.
El motor de almacenamiento utiliza varias estructuras de almacenamiento de base de datos de bajo nivel para serializar el modelo de datos de modo que pueda escribirse en el medio elegido. Se pueden utilizar técnicas como la indexación para mejorar el rendimiento. El almacenamiento convencional está orientado a filas, pero también existen bases de datos orientadas a columnas y correlacionadas.
A menudo se emplea redundancia de almacenamiento para aumentar el rendimiento. Un ejemplo común es el almacenamiento de vistas materializadas , que consisten en vistas externas o resultados de consultas que se necesitan con frecuencia. El almacenamiento de dichas vistas ahorra el costoso cálculo de las mismas cada vez que se necesitan. Las desventajas de las vistas materializadas son la sobrecarga que se genera al actualizarlas para mantenerlas sincronizadas con los datos de la base de datos original actualizada y el costo de la redundancia de almacenamiento.
Ocasionalmente, una base de datos emplea redundancia de almacenamiento mediante la replicación de objetos de base de datos (con una o más copias) para aumentar la disponibilidad de los datos (tanto para mejorar el rendimiento de los accesos simultáneos de múltiples usuarios finales al mismo objeto de base de datos como para proporcionar resiliencia en caso de falla parcial de una base de datos distribuida). Las actualizaciones de un objeto replicado deben sincronizarse entre las copias de objetos. En muchos casos, se replica toda la base de datos.
Con la virtualización de datos , los datos utilizados permanecen en sus ubicaciones originales y se establece un acceso en tiempo real para permitir el análisis de múltiples fuentes. Esto puede ayudar a resolver algunas dificultades técnicas, como problemas de compatibilidad al combinar datos de varias plataformas, reducir el riesgo de error causado por datos defectuosos y garantizar que se utilicen los datos más recientes. Además, evitar la creación de una nueva base de datos que contenga información personal puede facilitar el cumplimiento de las regulaciones de privacidad. Sin embargo, con la virtualización de datos, la conexión a todas las fuentes de datos necesarias debe estar operativa ya que no hay una copia local de los datos, lo que es uno de los principales inconvenientes de este enfoque. [34]
La seguridad de las bases de datos se ocupa de todos los aspectos relacionados con la protección del contenido de las bases de datos, sus propietarios y sus usuarios. Abarca desde la protección contra usos intencionales no autorizados de las bases de datos hasta accesos no intencionales a las bases de datos por parte de entidades no autorizadas (por ejemplo, una persona o un programa informático).
El control de acceso a bases de datos se ocupa de controlar quién (una persona o un programa informático determinado) tiene permiso para acceder a qué información de la base de datos. La información puede incluir objetos específicos de la base de datos (por ejemplo, tipos de registros, registros específicos, estructuras de datos), determinados cálculos sobre determinados objetos (por ejemplo, tipos de consultas o consultas específicas) o el uso de rutas de acceso específicas a los primeros (por ejemplo, el uso de índices específicos u otras estructuras de datos para acceder a la información). Los controles de acceso a bases de datos son establecidos por personal autorizado especial (por el propietario de la base de datos) que utiliza interfaces DBMS de seguridad protegidas y dedicadas.
Esto se puede gestionar directamente de forma individual, o mediante la asignación de individuos y privilegios a grupos, o (en los modelos más elaborados) mediante la asignación de individuos y grupos a roles a los que luego se les otorgan derechos. La seguridad de los datos impide que usuarios no autorizados vean o actualicen la base de datos. Mediante el uso de contraseñas, los usuarios pueden acceder a toda la base de datos o a subconjuntos de ella denominados "subesquemas". Por ejemplo, una base de datos de empleados puede contener todos los datos sobre un empleado individual, pero un grupo de usuarios puede estar autorizado a ver solo los datos de nómina, mientras que a otros se les permite acceder solo al historial laboral y los datos médicos. Si el DBMS proporciona una forma de ingresar y actualizar la base de datos de forma interactiva, así como de interrogarla, esta capacidad permite administrar bases de datos personales.
La seguridad de datos en general se ocupa de la protección de fragmentos específicos de datos, tanto físicamente (es decir, de la corrupción, la destrucción o la eliminación; por ejemplo, consulte seguridad física ) o la interpretación de ellos, o partes de ellos, para obtener información significativa (por ejemplo, al observar las cadenas de bits que los componen, concluyendo números de tarjetas de crédito válidos específicos; por ejemplo, consulte cifrado de datos ).
Los registros de cambios y accesos registran quién accedió a qué atributos, qué se modificó y cuándo se modificó. Los servicios de registro permiten realizar una auditoría forense de la base de datos más adelante al mantener un registro de las incidencias y los cambios de acceso. A veces, se utiliza código a nivel de aplicación para registrar los cambios en lugar de dejarlos en la base de datos. Se puede configurar un sistema de monitoreo para intentar detectar brechas de seguridad. Por lo tanto, las organizaciones deben tomar en serio la seguridad de las bases de datos debido a los muchos beneficios que brinda. Las organizaciones estarán protegidas de las brechas de seguridad y las actividades de piratería, como la intrusión en el firewall, la propagación de virus y el ransomware. Esto ayuda a proteger la información esencial de la empresa, que no se puede compartir con terceros bajo ningún concepto. [35]
Las transacciones de bases de datos se pueden utilizar para introducir cierto nivel de tolerancia a fallos e integridad de los datos tras la recuperación de un fallo . Una transacción de base de datos es una unidad de trabajo que, por lo general, encapsula una serie de operaciones sobre una base de datos (por ejemplo, leer un objeto de base de datos, escribir, adquirir o liberar un bloqueo , etc.), una abstracción admitida en bases de datos y también en otros sistemas. Cada transacción tiene límites bien definidos en términos de qué ejecuciones de programa/código se incluyen en esa transacción (determinadas por el programador de la transacción a través de comandos de transacción especiales).
El acrónimo ACID describe algunas propiedades ideales de una transacción de base de datos: atomicidad , consistencia , aislamiento y durabilidad .
Una base de datos creada con un DBMS no es portable a otro DBMS (es decir, el otro DBMS no puede ejecutarla). Sin embargo, en algunas situaciones, es deseable migrar una base de datos de un DBMS a otro. Las razones son principalmente económicas (diferentes DBMS pueden tener diferentes costos totales de propiedad o TCO), funcionales y operativas (diferentes DBMS pueden tener diferentes capacidades). La migración implica la transformación de la base de datos de un tipo de DBMS a otro. La transformación debe mantener (si es posible) la aplicación relacionada con la base de datos (es decir, todos los programas de aplicación relacionados) intacta. Por lo tanto, los niveles de arquitectura conceptual y externa de la base de datos deben mantenerse en la transformación. Puede ser deseable que también se mantengan algunos aspectos del nivel interno de la arquitectura. Una migración de base de datos compleja o grande puede ser un proyecto complicado y costoso (de una sola vez) en sí mismo, lo que debe tenerse en cuenta en la decisión de migrar. Esto es a pesar del hecho de que pueden existir herramientas para ayudar a la migración entre DBMS específicos. Por lo general, un proveedor de DBMS proporciona herramientas para ayudar a importar bases de datos de otros DBMS populares.
Después de diseñar una base de datos para una aplicación, la siguiente etapa es la construcción de la base de datos. Normalmente, se puede seleccionar un DBMS de propósito general adecuado para utilizarlo con este fin. Un DBMS proporciona las interfaces de usuario necesarias para que las utilicen los administradores de bases de datos para definir las estructuras de datos de la aplicación necesaria dentro del modelo de datos correspondiente del DBMS. Se utilizan otras interfaces de usuario para seleccionar los parámetros necesarios del DBMS (como los relacionados con la seguridad, los parámetros de asignación de almacenamiento, etc.).
Cuando la base de datos está lista (se han definido todas sus estructuras de datos y otros componentes necesarios), normalmente se llena con los datos iniciales de la aplicación (inicialización de la base de datos, que suele ser un proyecto independiente; en muchos casos, se utilizan interfaces DBMS especializadas que admiten la inserción masiva) antes de ponerla en funcionamiento. En algunos casos, la base de datos se vuelve operativa mientras está vacía de datos de la aplicación, y los datos se acumulan durante su funcionamiento.
Una vez creada, inicializada y completada la base de datos, es necesario realizar un mantenimiento. Es posible que sea necesario cambiar varios parámetros de la base de datos y ajustarla ( ajuste ) para obtener un mejor rendimiento; se pueden cambiar o agregar estructuras de datos de la aplicación, se pueden escribir nuevos programas de aplicación relacionados para agregar funcionalidad a la aplicación, etc.
A veces se desea devolver una base de datos a un estado anterior (por muchas razones, por ejemplo, casos en los que la base de datos se encuentra dañada debido a un error de software o si se ha actualizado con datos erróneos). Para lograr esto, se realiza una operación de copia de seguridad ocasional o continuamente, donde cada estado deseado de la base de datos (es decir, los valores de sus datos y su incrustación en las estructuras de datos de la base de datos) se guarda dentro de archivos de copia de seguridad dedicados (existen muchas técnicas para hacer esto de manera efectiva). Cuando un administrador de base de datos decide devolver la base de datos a este estado (por ejemplo, especificando este estado en un punto deseado en el tiempo cuando la base de datos estaba en este estado), estos archivos se utilizan para restaurar ese estado.
Las técnicas de análisis estático para la verificación de software también se pueden aplicar en el escenario de los lenguajes de consulta. En particular, el marco de interpretación abstracta se ha extendido al campo de los lenguajes de consulta para bases de datos relacionales como una forma de apoyar técnicas de aproximación sólidas. [36] La semántica de los lenguajes de consulta se puede ajustar de acuerdo con abstracciones adecuadas del dominio concreto de los datos. La abstracción de los sistemas de bases de datos relacionales tiene muchas aplicaciones interesantes, en particular, para fines de seguridad, como control de acceso de grano fino, marcas de agua, etc.
Otras características del DBMS pueden incluir:
Cada vez más, se pide un sistema único que incorpore todas estas funcionalidades básicas en el mismo marco de creación, prueba e implementación para la gestión de bases de datos y el control de fuentes. Tomando como ejemplo otros desarrollos en la industria del software, algunos comercializan este tipo de ofertas como " DevOps para bases de datos". [37]
La primera tarea de un diseñador de bases de datos es producir un modelo de datos conceptual que refleje la estructura de la información que se almacenará en la base de datos. Un enfoque común para esto es desarrollar un modelo de entidad-relación , a menudo con la ayuda de herramientas de dibujo. Otro enfoque popular es el Lenguaje de Modelado Unificado . Un modelo de datos exitoso reflejará con precisión el posible estado del mundo externo que se está modelando: por ejemplo, si las personas pueden tener más de un número de teléfono, permitirá capturar esta información. Diseñar un buen modelo de datos conceptual requiere una buena comprensión del dominio de la aplicación; por lo general, implica hacer preguntas profundas sobre las cosas que interesan a una organización, como "¿un cliente también puede ser un proveedor?", o "si un producto se vende con dos formas diferentes de empaquetado, ¿son el mismo producto o productos diferentes?", o "si un avión vuela de Nueva York a Dubai vía Frankfurt, ¿se trata de un vuelo o dos (o tal vez incluso tres)?". Las respuestas a estas preguntas establecen definiciones de la terminología utilizada para las entidades (clientes, productos, vuelos, segmentos de vuelo) y sus relaciones y atributos.
La producción del modelo de datos conceptual a veces implica la aportación de datos de los procesos empresariales o el análisis del flujo de trabajo de la organización. Esto puede ayudar a establecer qué información se necesita en la base de datos y qué se puede omitir. Por ejemplo, puede ayudar a decidir si la base de datos necesita contener datos históricos además de datos actuales.
Una vez que se ha producido un modelo de datos conceptual con el que los usuarios están satisfechos, la siguiente etapa es traducirlo en un esquema que implemente las estructuras de datos relevantes dentro de la base de datos. Este proceso se suele denominar diseño lógico de la base de datos y el resultado es un modelo lógico de datos expresado en forma de esquema. Mientras que el modelo de datos conceptual es (al menos en teoría) independiente de la elección de la tecnología de la base de datos, el modelo lógico de datos se expresará en términos de un modelo de base de datos particular compatible con el DBMS elegido. (Los términos modelo de datos y modelo de base de datos se suelen utilizar indistintamente, pero en este artículo utilizamos modelo de datos para el diseño de una base de datos específica y modelo de base de datos para la notación de modelado utilizada para expresar ese diseño).
El modelo de base de datos más popular para bases de datos de propósito general es el modelo relacional, o más precisamente, el modelo relacional representado por el lenguaje SQL. El proceso de creación de un diseño de base de datos lógico utilizando este modelo utiliza un enfoque metódico conocido como normalización . El objetivo de la normalización es garantizar que cada "hecho" elemental se registre solo en un lugar, de modo que las inserciones, actualizaciones y eliminaciones mantengan automáticamente la coherencia.
La etapa final del diseño de una base de datos es tomar las decisiones que afectan el rendimiento, la escalabilidad, la recuperación, la seguridad y demás, que dependen del DBMS en particular. Esto suele denominarse diseño físico de la base de datos y el resultado es el modelo físico de datos . Un objetivo clave durante esta etapa es la independencia de los datos , lo que significa que las decisiones tomadas con fines de optimización del rendimiento deben ser invisibles para los usuarios finales y las aplicaciones. Hay dos tipos de independencia de los datos: independencia física de los datos e independencia lógica de los datos. El diseño físico está impulsado principalmente por los requisitos de rendimiento y requiere un buen conocimiento de la carga de trabajo y los patrones de acceso esperados, y una comprensión profunda de las características que ofrece el DBMS elegido.
Otro aspecto del diseño de bases de datos físicas es la seguridad, que implica tanto definir el control de acceso a los objetos de la base de datos como definir los niveles y métodos de seguridad para los datos en sí.
Un modelo de base de datos es un tipo de modelo de datos que determina la estructura lógica de una base de datos y, fundamentalmente, determina de qué manera se pueden almacenar, organizar y manipular los datos . El ejemplo más popular de un modelo de base de datos es el modelo relacional (o la aproximación SQL de relacional), que utiliza un formato basado en tablas.
Los modelos de datos lógicos comunes para bases de datos incluyen:
Una base de datos relacional de objetos combina las dos estructuras relacionadas.
Los modelos de datos físicos incluyen:
Otros modelos incluyen:
Los modelos especializados están optimizados para tipos particulares de datos:
Un sistema de gestión de bases de datos proporciona tres vistas de los datos de la base de datos:
Si bien normalmente solo existe una única visión conceptual e interna de los datos, puede haber cualquier cantidad de vistas externas diferentes. Esto permite a los usuarios ver la información de la base de datos de una manera más relacionada con el negocio en lugar de desde un punto de vista técnico y de procesamiento. Por ejemplo, un departamento financiero de una empresa necesita los detalles de pago de todos los empleados como parte de los gastos de la empresa, pero no necesita detalles sobre los empleados que son de interés para el departamento de recursos humanos . Por lo tanto, los diferentes departamentos necesitan diferentes vistas de la base de datos de la empresa.
La arquitectura de base de datos de tres niveles se relaciona con el concepto de independencia de los datos , que fue una de las principales fuerzas impulsoras iniciales del modelo relacional. [39] La idea es que los cambios realizados en un determinado nivel no afecten la vista en un nivel superior. Por ejemplo, los cambios en el nivel interno no afectan a los programas de aplicación escritos utilizando interfaces de nivel conceptual, lo que reduce el impacto de realizar cambios físicos para mejorar el rendimiento.
La vista conceptual proporciona un nivel de indirección entre lo interno y lo externo. Por un lado, proporciona una vista común de la base de datos, independiente de las diferentes estructuras de vista externas, y por otro lado, abstrae los detalles de cómo se almacenan o gestionan los datos (nivel interno). En principio, cada nivel, e incluso cada vista externa, se puede presentar mediante un modelo de datos diferente. En la práctica, por lo general, un determinado DBMS utiliza el mismo modelo de datos tanto para el nivel externo como para el conceptual (por ejemplo, el modelo relacional). El nivel interno, que está oculto dentro del DBMS y depende de su implementación, requiere un nivel de detalle diferente y utiliza sus propios tipos de estructuras de datos.
La tecnología de bases de datos ha sido un tema de investigación activo desde la década de 1960, tanto en el ámbito académico como en los grupos de investigación y desarrollo de empresas (por ejemplo, IBM Research ). La actividad de investigación incluye la teoría y el desarrollo de prototipos . Entre los temas de investigación destacados se incluyen los modelos , el concepto de transacción atómica, las técnicas de control de concurrencia relacionadas , los lenguajes de consulta y los métodos de optimización de consultas , RAID y más.
El área de investigación de bases de datos cuenta con varias revistas académicas dedicadas (por ejemplo, ACM Transactions on Database Systems -TODS, Data and Knowledge Engineering -DKE) y conferencias anuales (por ejemplo, ACM SIGMOD , ACM PODS , VLDB , IEEE ICDE).
Definiciones de Wikcionario
Medios de comunicación de Commons
Noticias de Wikinoticias
Citas de Wikiquote
Textos de Wikisource
Libros de texto de Wikilibros
Recursos de Wikiversidad