E-Handbook: Retos y tendencias de las bases de datos Articulo 2 de 4

CrazyCloud - Fotolia

El poder de una base de datos

¿Qué debemos saber sobre las bases de datos? ¿Cómo funcionan? ¿Cómo se clasifican? ¿Qué reglas deben aplicarse al diseñar e implementar bases de datos? ¿Y por qué es importante saber qué es la normalización y cómo se aplica a una BD? Este artículo ofrece respuestas a 8 preguntas relevantes sobre DBs.

  1. ¿Qué es una base de datos?

Una base de datos es una colección de datos que se almacena para un propósito específico y se organiza de manera que permite acceder, administrar y actualizar fácilmente su contenido. Aunque esta definición incluye colecciones de datos almacenados como bibliotecas, archivadores y libretas de direcciones, cuando hablamos de bases de datos casi invariablemente nos referimos a una colección de datos que se almacena en una computadora.

Hay dos categorías básicas de bases de datos. La categoría más común es la base de datos transaccional, que se utiliza para almacenar datos dinámicos, como el contenido del inventario, que está sujeta a cambios de forma continua. La otra categoría es la base de datos analítica, que se utiliza para almacenar datos estáticos, como resultados de pruebas geográficas o químicas, que rara vez se modifican.

Estrictamente hablando, una base de datos es solo los datos almacenados en sí, aunque el término se usa a menudo, erróneamente, para referirse a una base de datos y su sistema de gestión (DBMS).

Breve historia de la base de datos:

Los primeros intentos de crear bases de datos informáticas surgieron a mediados del siglo XX. Las primeras versiones estaban orientadas a archivos. Un archivo de base de datos se conoció como tabla porque su estructura era la misma que una tabla de datos en papel. Por la misma razón, las columnas dentro de una tabla se llamaron campos y las filas se llamaron registros. Las computadoras evolucionaron durante ese mismo período de tiempo y se estaba reconociendo su potencial para el almacenamiento y la recuperación de datos.

Las primeras bases de datos informáticas se basaban en un modelo de archivo plano, en el que los registros se almacenaban en formato de texto. En este modelo, no se definen relaciones entre registros. Sin definir tales relaciones, solo se puede acceder a los registros de forma secuencial. Por ejemplo, si quisiera encontrar el registro del quincuagésimo cliente, primero tendría que revisar los primeros 49 registros de clientes en secuencia. El modelo de archivo plano funciona bien para situaciones en las que desea procesar todos los registros, pero no para situaciones en las que desea encontrar registros específicos dentro de la base de datos.

El modelo jerárquico, ampliamente utilizado en entornos de mainframe, fue diseñado para permitir relaciones estructuradas que facilitarían la recuperación de datos. Dentro de una estructura de árbol invertida, las relaciones en el modelo jerárquico son padre-hijo y uno a muchos. Cada tabla principal puede estar relacionada con varias tablas secundarias, pero cada tabla secundaria solo puede estar relacionada con una única tabla principal. Debido a que las estructuras de las tablas están vinculadas de forma permanente y explícita en este modelo, la recuperación de datos fue rápida. Sin embargo, la estructura rígida del modelo causa algunos problemas. Por ejemplo, no se puede agregar una tabla secundaria que no esté vinculada a una tabla principal: si la tabla principal era "Doctores" y la tabla secundaria era "Pacientes", no podría agregarse un registro de paciente de forma independiente. Eso significaría que, si un nuevo paciente ingresara al sistema de atención médica de una comunidad, bajo este sistema, su registro no podría agregarse hasta que tuviera un médico. La estructura jerárquica también significa que, si se elimina un registro en una tabla principal, también se eliminarán todos los registros vinculados a él en las tablas secundarias.

También basado en una estructura de árbol invertida, el siguiente enfoque para el diseño de la base de datos fue el modelo de red. El modelo de red permitía conexiones más complejas que el modelo jerárquico: varios árboles invertidos podrían compartir ramas, por ejemplo. El modelo conectó tablas en conjuntos, en los que un registro de una tabla de propietario podría vincularse a varios registros de una tabla de miembros. Al igual que el modelo jerárquico, el modelo de red permitió una recuperación de datos muy rápida. Sin embargo, también tuvo varios problemas. Por ejemplo, un usuario necesitaría una comprensión clara de la estructura de la base de datos para poder obtener información de los datos. Además, si se cambiaba una estructura de conjunto, también se tendría que cambiar cualquier referencia a ella desde un programa externo.

En la década de 1970, la base de datos relacional se desarrolló para tratar datos de formas más complejas. El modelo relacional finalmente dominó la industria y ha continuado haciéndolo hasta el día de hoy. Exploraremos la base de datos relacional con cierto detalle en el siguiente segmento.

  1. ¿Qué es una base de datos relacional?

En el modelo de base de datos relacional, los datos se almacenan en relaciones, más comúnmente conocidas como tablas. Las tablas, los registros (a veces conocidos como tuplas) y los campos (a veces conocidos como atributos) son los componentes básicos. Cada dato individual, como un apellido o un número de teléfono, se almacena en un campo de tabla y cada registro comprende un conjunto completo de datos de campo para una tabla en particular.

En el siguiente ejemplo, la tabla mantiene la información de la dirección de envío del cliente. Apellido y otros encabezados de columna son los campos. Un registro, o fila, en la tabla comprende el conjunto completo de datos de campo en ese contexto: toda la información de dirección que se requiere para enviar un pedido a un cliente específico. Cada registro se puede identificar y acceder a través de un identificador único llamado clave primaria. En la tabla Envío al cliente, por ejemplo, el campo ID del cliente podría servir como clave principal porque cada registro tiene un valor único para los datos de ese campo.

Envío al cliente

ID

Nombre

Apellido

Apto.

Domicilio

Ciudad

Estado

CP

101

John

Smith

147

123 1st Street

Chicago

IL

60635

102

Jane

Doe

13 C

234 2nd Street

Chicago

IL

60647

103

June

Doe

14 A

243 2nd Street

Chicago

IL

60647

104

George

Smith

N/A

345 3rd Street

Chicago

IL

60625

 

El término relacional proviene de la teoría de conjuntos, en lugar del concepto de que las relaciones entre los datos impulsan la base de datos. Sin embargo, el modelo, de hecho, funciona definiendo y explotando las relaciones entre los datos de la tabla. Las relaciones de tabla se definen como uno a uno (1:1), uno a varios (1:N) o, con poca frecuencia, muchos a varios (N:M):

  • Si un par de tablas tiene una relación de uno a uno, cada registro de la Tabla A se relaciona con un solo registro de la Tabla B. Por ejemplo, en un emparejamiento de tablas que consta de una tabla de direcciones de envío de clientes y una tabla de cuentas de clientes saldos, cada número de identificación de cliente individual estaría relacionado con un identificador único para el registro de saldo de la cuenta de ese cliente. La relación uno a uno refleja el hecho de que cada cliente individual tiene un saldo de cuenta único.
  • Si un par de tablas tiene una relación de uno a muchos, cada registro individual en la Tabla A se relaciona con uno o más registros en la Tabla B. Por ejemplo, en una combinación de tablas que consta de una tabla de cursos universitarios (Tabla A) y una tabla de información de contacto de los estudiantes (Tabla B), cada número de curso individual estaría relacionado con varios registros de información de contacto de los estudiantes. La relación de uno a muchos refleja el hecho de que cada curso individual tiene varios estudiantes inscritos en él.
  • Si un par de tablas tiene una relación de varios a varios, cada registro individual en la Tabla A se relaciona con uno o más registros en la Tabla B, y cada registro individual en la Tabla B se relaciona con uno o más registros en la Tabla A. Por ejemplo, en una combinación de tablas que consta de una tabla de información de empleados y una tabla de información de proyectos, cada registro de empleado podría estar relacionado con múltiples registros de proyecto y cada registro de proyecto podría estar relacionado con múltiples registros de empleado. La relación de muchos a muchos refleja el hecho de que cada empleado puede estar involucrado en múltiples proyectos y que cada proyecto involucra a múltiples empleados.
  1. ¿De dónde vino el modelo relacional?

El modelo de base de datos relacional se desarrolló a partir de las propuestas de "Un modelo relacional de datos para grandes bancos de datos compartidos", un artículo presentado por el Dr. E.F. Codd en 1970. Codd, un científico investigador de IBM, estaba explorando mejores formas de administrar grandes cantidades de datos delas que estaban disponibles. Los modelos jerárquicos y de red de la época tendían a sufrir problemas con la redundancia de datos y la mala integridad de los datos. Al aplicar el cálculo relacional, el álgebra y la lógica al almacenamiento y recuperación de datos, Codd permitió el desarrollo de un modelo más complejo y completamente articulado que el que existía anteriormente.

Uno de los objetivos de Codd era crear un idioma similar al inglés que permitiera a los usuarios no técnicos interactuar con una base de datos. Basado en el artículo de Codd, IBM inició su grupo de investigación System R para desarrollar un sistema de base de datos relacional. El grupo desarrolló SQL/DS, que finalmente se convirtió en DB2. El lenguaje del sistema, SQL, se convirtió en el estándar de facto de la industria. En 1985, el Dr. Codd publicó una lista de doce reglas para una base de datos relacional ideal. Aunque es posible que las reglas nunca se hayan implementado por completo, han proporcionado una guía para los desarrolladores de bases de datos durante las últimas décadas.

Las 12 reglas de Codd:

  1. La regla de la información: los datos deben presentarse al usuario en formato de tabla.
  2. Regla de acceso garantizado: los datos deben ser accesibles de manera confiable mediante una referencia al nombre de la tabla, la clave principal y el nombre del campo.
  3. Tratamiento sistemático de valores nulos: los campos que no son claves primarias deben poder permanecer vacíos (contener un valor nulo).
  4. Catálogo dinámico en línea basado en el modelo relacional: La estructura de la base de datos debe ser accesible a través de las mismas herramientas que brindan acceso a los datos.
  5. Regla completa de sublenguaje de datos: la base de datos debe admitir un idioma que pueda usarse para todas las interacciones (SQL se desarrolló a partir de las reglas de Codd).
  6. Ver regla de actualización: los datos deben estar disponibles en diferentes combinaciones (vistas) que también se pueden actualizar y eliminar.
  7. Insertar, actualizar y eliminar de alto nivel: debería ser posible realizar todas estas tareas en cualquier conjunto de datos que se pueda recuperar.
  8. Independencia física de los datos: los cambios realizados en la arquitectura subyacente a la base de datos no deberían afectar la interfaz de usuario.
  9. Independencia lógica de los datos: si la estructura lógica de una base de datos cambia, eso no debería reflejarse en la forma en que el usuario la ve.
  10. Independencia de integridad: El lenguaje utilizado para interactuar con la base de datos debe soportar las limitaciones del usuario que mantendrán la integridad de los datos.
  11. Independencia de distribución: si la base de datos está distribuida (ubicada físicamente en varias computadoras), ese hecho no debería ser evidente para el usuario.
  12. Regla de no subversión: No debería ser posible alterar la estructura de la base de datos por ningún otro medio que no sea el idioma de la base de datos.

4. ¿Qué otros tipos de bases de datos existen?

Aunque el modelo relacional es, con mucho, el más frecuente, hay otros modelos que se adaptan mejor a tipos particulares de datos. Las alternativas al modelo relacional incluyen:

  • Bases de datos de archivos planos: los datos se almacenan en archivos que constan de uno o más archivos legibles, generalmente en formato de texto.
  • Bases de datos jerárquicas: los datos se almacenan en tablas con relaciones padre/hijo con una estructura estrictamente jerárquica.
  • Bases de datos de red: similar al modelo jerárquico, pero permite una mayor flexibilidad; por ejemplo, una tabla secundaria puede estar relacionada con más de una tabla principal.
  • Bases de datos orientadas a objetos: el modelo de base de datos orientada a objetos se desarrolló a fines de la década de 1980 y principios de la de 1990 para tratar tipos de datos para los que el modelo relacional no era adecuado. Los datos médicos y multimedia, por ejemplo, requerían un sistema más flexible para la representación y manipulación de datos.
  • Bases de datos relacionales de objetos: un modelo híbrido que combina características de los modelos relacionales y orientados a objetos.
  1. ¿Qué lenguajes se utilizan para interactuar con las bases de datos?

SQL (lenguaje de consulta estructurado) es, con mucho, el lenguaje más común utilizado para interactuar con bases de datos relacionales. Desarrollado originalmente para su uso con DB2 de IBM, el estándar es promovido en varios formatos tanto por el Instituto Nacional Estadounidense de Normas (ANSI) como por la Organización Internacional de Normas (ISO).

Los comandos SQL son bastante sencillos y fáciles de entender. Por ejemplo, si desea una lista de todos sus clientes dentro de un área de código postal específico, el siguiente comando (basado en la tabla del punto #2) devolverá esa información, que en este caso sería ser "George Smith".

seleccionar Nombre, Apellido de Envío_a_clientes donde Zip = '60625';

La mayoría de las bases de datos usan SQL, aunque muchas usan extensiones propietarias específicas para sus propios productos.

  1. ¿Cómo puedo asegurar un buen diseño de base de datos?

Sin duda, lo más importante que puede hacer para garantizar un diseño de base de datos exitoso es poner suficientes recursos en la etapa de planificación. La proliferación de bases de datos y aplicaciones de bases de datos comerciales ha llevado a muchas personas a una serie de conclusiones erróneas, tales como:

  • Las bases de datos disponibles en el mercado se pueden personalizar fácilmente.

De hecho, aunque existen bases de datos listas para usar, disponibles para cualquier número de aplicaciones, su diseño generalmente difiere significativamente del modelo ideal para sus necesidades específicas. Y adaptarlas para que encajen es a menudo más complicado que empezar desde cero.

  • Cualquiera puede crear una base de datos perfectamente funcional.

De hecho, casi cualquier persona podría crear una base de datos perfectamente funcional, si se tomara el tiempo para aprender lo que necesitaba saber antes de comenzar a desarrollar.

  • Puede saltar directamente al proceso de desarrollo, haciendo ajustes a medida que avanza.

De hecho, podría crear una base de datos sin un plan cuidadosamente elaborado. También puede construir una casa de esa manera, pero no es recomendable. Las bases de datos son construcciones complicadas. Ya sea que aparezcan o no problemas importantes en la fase de desarrollo, es probable que surjan en la implementación. Arreglar esos problemas puede ser difícil, lento y costoso. Además, debido a las intrincadas formas en que los datos se conectan en una base de datos, un problema en un área puede afectar los datos en otras áreas de manera sorprendente.

Las bases de datos surgieron gracias a la computadora, y las dos han disfrutado de una relación simbiótica mutuamente beneficiosa desde entonces, cada una ayudando a la otra a crecer a pasos agigantados. Sin embargo, irónicamente, la mejor manera de comenzar un plan para el desarrollo de una base de datos es sacar papel, un lápiz y una gran goma de borrar.

El desarrollo de la base de datos es un proceso de tres fases. En la primera fase, debe crear el diseño lógico para la base de datos, basándose únicamente en los datos que desea almacenar, en lugar de pensar en el software específico que se utilizará para crearlo, o los tipos de informes que se crearán a partir de eso. En esta fase, se definen tablas y campos, y se establecen claves primarias y externas y restricciones de integridad. En la segunda fase, se implementa el plan dentro del programa de software de la base de datos, y en la tercera fase, se desarrolla la aplicación para el usuario final que permitirá que sus usuarios interactúen con la base de datos.

  1. ¿Cuáles son las cosas más importantes a tener en cuenta durante la fase de diseño?

  • Primero cree su diseño en papel, lo más completo posible.
  • Elimine tanta redundancia de datos como sea posible.
  • Empiece desde cero: no intente utilizar partes de una base de datos con problemas estructurales.
  • Asegúrese de que cada tabla represente un solo tema.
  • Asigne una clave primaria cuyo valor identifique claramente cada registro y solo un registro.
  • Asegúrese de que cada campo represente un valor único.
  • Tómese el tiempo para estar seguro de la integridad de los datos.
  1. ¿Qué es la normalización y por qué necesito saberlo?

En breve:

Los datos bien normalizados facilitan la programación (relativamente) y funcionan muy bien en entornos empresariales multiplataforma. Los datos no normalizados conducen a la angustia. - Steve Litt

La normalización es un proceso de guía para el diseño de tablas de bases de datos que asegura, en cuatro niveles de rigurosidad, una mayor confianza en que los resultados del uso de la base de datos son inequívocos y según lo previsto. Básicamente, un proceso de refinamiento, la normalización prueba el diseño de una tabla por la forma en que almacena los datos, de modo que no dé lugar a la eliminación involuntaria de registros, por ejemplo, y que devuelva de manera confiable los datos solicitados.

Grados de normalización de tablas de bases de datos relacionales:

Primera forma normal (1NF). Este es el nivel "básico" de normalización y generalmente corresponde a la definición de cualquier base de datos, a saber:

  • Contiene tablas bidimensionales con filas y columnas correspondientes, respectivamente, a registros y campos.
  • Cada campo corresponde al concepto representado por la tabla completa: por ejemplo, cada campo en la tabla Envío_al_cliente identifica algún componente de la dirección de envío del cliente.
  • No son posibles los registros duplicados.
  • Todos los datos de campo deben ser del mismo tipo. Por ejemplo, en el campo "Código Postal (CP)" de la tabla Envío_al_cliente, solo se aceptarán cinco dígitos.

Segunda forma normal (2NF). Además de las reglas 1NF, cada campo de una tabla que no determina el contenido de otro campo debe ser en sí mismo una función de los otros campos de la tabla. Por ejemplo, en una tabla con tres campos para ID de cliente, producto vendido y precio del producto cuando se vende, el precio sería una función del ID de cliente (con derecho a un descuento) y del producto específico.

Tercera forma normal (3NF). Además de las reglas 2NF, cada campo de una tabla debe depender de la clave principal. Por ejemplo, utilizando la tabla de clientes que se acaba de citar, eliminar un registro que describe la compra de un cliente (quizás debido a una devolución) también eliminará el hecho de que el producto tiene un precio determinado. En la tercera forma normal, estas tablas se dividirían en dos tablas para que los precios de los productos se rastrearan por separado. La información del cliente dependería de la clave principal de esa tabla, ID del cliente, y la información de precios dependería de la clave principal de esa tabla, que podría ser Número de factura.

Forma normal de dominio/clave (DKNF). Además de las reglas 3NF, una clave, que es un campo utilizado para ordenar, identifica de forma única cada registro en una tabla. Un dominio es el conjunto de valores permitidos para un campo. Al hacer cumplir las restricciones de dominio y clave, se asegura que la base de datos se librará de anomalías de modificación. DKNF es el nivel de normalización que la mayoría de los diseñadores pretenden alcanzar.

Investigue más sobre Bases de datos

ComputerWeekly.com.br
Close