¿Se siente abrumado por la cantidad de tiempo que le llevará aprender a ser diseñador de bases de datos? Lea acerca de las habilidades y talentos esenciales que necesitará, ¡no es tan terrible!
Cuando caminas por los pasillos del supermercado, con el carrito de la compra en una mano y la lista de la compra en la otra, ¿en qué estás pensando? Si eres como yo, te estás imaginando cómo mejorar la organización de las estanterías para que tus compras semanales te lleven menos tiempo. O tal vez sientas el mismo deseo de organizar y estructurar la información cuando un amigo te muestra su gran colección de revistas. O tal vez te llame la atención cuando estés administrando tus listas de reproducción para que se adapten mejor a tus preferencias. Si te pasas la vida pensando en cómo representar la realidad en términos de entidades, atributos y relaciones, entonces tu vocación es ser modelador de bases de datos.
Tal vez no seas tan extremo, pero aún te atrae la idea de dedicarte al diseño de bases de datos como carrera. De cualquier manera, necesitarás dominar algunas habilidades nuevas. Algunos de ellos son puramente técnicos; puedes aprender estas habilidades estudiando o leyendo y profundizarlas a través de la experiencia laboral. Otras habilidades involucran conocimientos no técnicos que puede aprender a través de cursos, artículos de blog u observando a otros.
Aquí hay un resumen de los conocimientos y habilidades esenciales que todo diseñador de bases de datos debe tener.
Habilidades duras que necesitan los diseñadores de bases de datos
Las habilidades duras son aquellas que se adquieren a través del estudio y se perfeccionan a través de la práctica. Si puede demostrar con evidencia concreta que ha dominado una habilidad difícil, significa que es capaz de realizar cualquier tarea que la involucre.
En términos de conocimiento de bases de datos, las habilidades duras incluyen los fundamentos de la teoría de bases de datos y las diversas técnicas utilizadas para aplicar conceptos teóricos para resolver problemas concretos. Veamos cada una de las habilidades duras que necesitan los diseñadores de bases de datos.
Teoría de bases de datos
La teoría de bases de datos está llena de conceptos abstractos que pueden ser difíciles de entender si no están asociados con hechos de la vida real. El modelo relacional, los dominios, los atributos, las relaciones y las relaciones, las claves primarias y externas, la integridad de la entidad, la integridad referencial y las restricciones de dominio son solo algunos ejemplos. Si agrega materias aún más complejas (como álgebra relacional o cálculo relacional), puede preguntarse si no sería mejor elegir una carrera que se ocupe de cosas concretas como la jardinería o la cocina gourmet.
No entrar en pánico. El conocimiento profundo de la teoría de bases de datos es importante si planeas dar clases en la universidad o inventar una nueva forma de organizar la información. Pero para diseñar bases de datos, solo necesita dominar los conceptos teóricos que se aplican para resolver problemas de la vida real. El más importante, el ABC del diseño de bases de datos, es el modelo relacional.
El modelo relacional
Los profesores universitarios le dirán que el modelo relacional es un mecanismo de organización de datos basado en la teoría de conjuntos y la lógica de predicados. Pero eso no le servirá de mucho en su trabajo diario como modelador de bases de datos. En la práctica, debe saber que el modelo relacional es una forma intuitiva y sencilla de organizar datos en forma de tablas – llamadas relaciones – que se componen de filas (que también se llaman tuplas). Cada tabla (o relación) está definida por sus atributos (o columnas).
Conceptos fundamentales del modelo relacional.
Todas las relaciones deben tener uno o más atributos sobresalientes que representen un identificador único para cada tupla. En la jerga de la base de datos, esa es la clave de la tabla. Los atributos no clave dependen de la clave en el sentido de que cada valor clave determina un único valor posible para cada atributo.
Imagina una tabla de información de vehículos en la que la clave es la matrícula. La matrícula determina los atributos de cada vehículo (como el fabricante, modelo, propietario, etc.), ya que las reglas del dominio impiden que dos vehículos diferentes compartan la misma matrícula.
Bases de datos relacionales
Los sistemas de gestión de bases de datos relacionales (RDBMS) implementan el modelo relacional, respetando sus principios. Ofrecen formas de recuperar información a través de consultas y actualizar información a través de transacciones. Para que la información de una base de datos relacional refleje hechos y situaciones de la vida real, puede definir condiciones o restricciones específicas del dominio al que se aplica la base de datos. Por ejemplo, en una tabla que almacena información sobre escolares, se puede imponer una restricción para que las fechas de nacimiento no permitan fechas futuras o demasiado lejanas en el pasado.
La organización de las tablas en una base de datos se conoce comúnmente como el esquema de la base de datos. Además de las tablas, el esquema detalla las restricciones que implican pares de tablas denominadas relaciones. Una relación conecta dos tablas al imponer la restricción de que los valores en el campo de una de las tablas corresponden a los valores en la clave principal de la otra tabla.
Los esquemas de bases de datos suelen estar representados por el diagrama entidad-relación (ERD), una herramienta común para cualquier diseñador de bases de datos.
Un ERD que representa un modelo de datos del cliente.
Anomalías y Normalización
Todos los conceptos que hemos discutido hasta ahora son bastante claros, ¿verdad? Ahora podemos hablar de las anomalías que ocurren en las bases de datos debido a un diseño defectuoso o inadecuado (es decir, la base de datos no refleja adecuadamente la realidad que intenta representar).
Las anomalías ocurren cuando una operación de inserción, actualización o eliminación genera inconsistencias en los datos. Por ejemplo, suponga que tiene una tabla para almacenar datos de ventas. Para cada venta (es decir, en cada registro de la tabla), se registra el nombre y la dirección de los clientes. La anomalía es la siguiente:
- Si se modifica la dirección del cliente en una de las ventas, y
- El mismo cliente tiene otras ventas,
- Las otras ventas tendrán una dirección obsoleta.
Para evitar anomalías, puede aplicar una técnica de diseño llamada normalización de base de datos. Esto implica descomponer tablas y columnas (es decir, dividirlas en partes más pequeñas) para evitar fallas de diseño como:
- Columnas que contienen más de una pieza de información (p. ej., el número de identificación de un elemento, así como su nombre).
- Almacenar la misma información más de una vez en la misma tabla.
- Campos que dependen de otros campos no clave.
Tabla no normalizada (izquierda) versus esquema normalizado (derecha).
Almacenes de datos y desnormalización
Algunas bases de datos se utilizan para consultar grandes volúmenes de información en lugar del procesamiento de transacciones en línea (OLTP). Estas bases de datos se denominan almacenes de datos.
La información en un almacén de datos no proviene de las interfaces de usuario (por ejemplo, ingresada directamente desde un sistema de pedidos de comercio electrónico). Proviene de procesos por lotes que recopilan información de diferentes fuentes, la procesan, la limpian y la almacenan en tablas. Por este motivo, podemos suponer que los almacenes de datos no están expuestos a las mismas anomalías que las bases de datos convencionales.
Por eso, los almacenes de datos no necesitan mantener las mismas condiciones de normalización que una base de datos OLTP. Por otro lado, es más importante optimizar la eficiencia de las consultas en los almacenes de datos. Esta es la razón por la que se aplica la desnormalización en un almacén de datos; esta técnica utiliza una cierta cantidad de redundancia para simplificar las consultas y evitar sobrecargar los esquemas con un número excesivo de tablas.
Un esquema de almacén de datos típico.
Grandes datos
Al igual que el almacenamiento de datos, el concepto de Big Data se refiere a los repositorios que albergan grandes cantidades de datos. Sin embargo, hay una diferencia importante entre los dos conceptos. Un almacén de datos está diseñado para un propósito específico y tiene como objetivo generar informes cuyo comportamiento y formato se conocen de antemano.
Big Data, por otro lado, tiene como objetivo recopilar grandes volúmenes de datos que se generan a alta velocidad desde diferentes fuentes, p. información de redes sociales, microtransacciones o sensores inteligentes. Esta enorme cantidad de información se puede utilizar para exploración y análisis o para entrenar modelos de aprendizaje automático.
En el diseño de bases de datos de Big Data, la economía del espacio de almacenamiento y la partición de datos (entre otras cosas) se priorizan para permitir el paralelismo y la captura de datos en tiempo real. Además, se utilizan sistemas de bases de datos no relacionales o NoSQL, que ofrecen mejores alternativas para el manejo de información no estructurada.
Tecnologías como NoSQL y el propio concepto de Big Data son relativamente nuevas en comparación con las bases de datos relacionales, que ya tienen más de 40 años. Por eso, como diseñador de bases de datos, debe estar atento a los nuevos desarrollos en esta área. Tenga en cuenta que Big Data también es un gran negocio. Muchas empresas quieren tomar una posición de liderazgo y están desarrollando nuevas herramientas y tecnologías para hacerlo.
Administración de bases de datos
Una vez que una base de datos está en funcionamiento, alguien debe encargarse de su gestión diaria. Esto significa realizar tareas rutinarias para que la base de datos nunca se convierta en un cuello de botella para las aplicaciones que la utilizan. Las tareas de administración incluyen el mantenimiento de copias de seguridad, la supervisión del consumo de espacio de almacenamiento, la detección de bloqueos entre procesos y la solución de problemas de datos que impiden el funcionamiento normal de las aplicaciones.
La persona que tiene las habilidades de la base de datos para encargarse de estas tareas es el administrador de la base de datos o DBA, cuando lo hay. En organizaciones muy pequeñas, o en entornos de desarrollo donde la operación de las bases de datos no es crítica para el negocio, la responsabilidad del mantenimiento de la base de datos puede recaer en el modelador de la base de datos. Por lo tanto, debe tener algunos conocimientos que le permitan tomar el relevo del DBA en ciertas situaciones. Sin embargo, bajo ninguna circunstancia debe aceptar la responsabilidad de administrar una base de datos en un entorno de producción que admita aplicaciones comerciales o de misión crítica .
Las tareas de administración varían mucho según el sistema de base de datos y la infraestructura en la que se monta. Por ejemplo, las tareas de administrar bases de datos de Microsoft SQL Server son muy diferentes de las de administrar bases de datos MySQL u Oracle. Y administrar un servidor que se ejecuta localmente en su computadora portátil es muy diferente de administrar uno que se ejecuta en la nube.
No recomiendo dedicar mucho esfuerzo a aprender a administrar un servidor de base de datos en particular, ya que tratará con bases de datos y entornos muy diferentes a lo largo de su carrera. No te servirá de mucho especializarte en uno solo.
Gestión de simultaneidad y transacciones
El acceso simultáneo a una base de datos puede causar problemas en las aplicaciones cuando varios usuarios intentan acceder al mismo recurso al mismo tiempo. Podríamos pensar que, como diseñadores, esto no es asunto nuestro y que es responsabilidad del DBA lidiar con estos problemas. También podemos pensar que es culpa de los programadores por crear aplicaciones que lo permitan.
Sin embargo, los diseñadores pueden hacer su parte para minimizar los posibles problemas de concurrencia mediante el diseño de esquemas que los eviten.
Muchos problemas de concurrencia ocurren cuando se ejecutan transacciones largas y complejas en una base de datos; mientras se procesa la transacción, las tablas involucradas quedan bloqueadas para otros procesos que las necesiten para leer o escribir información. Para evitar este tipo de problemas, lo mejor que puede hacer es asegurarse de que sus diseños cumplan al menos hasta la tercera forma normal. Entonces será responsabilidad del programador pensar en las transacciones correctamente para evitar puntos muertos.
Pero también puedes utilizar estrategias que eviten la concurrencia, como particionar esquemas o agrupar tablas según la función que cumpla cada una.
Imaginemos una base de datos para un sitio de comercio electrónico. Puede colocar las tablas de datos maestros para productos, existencias y precios en un esquema y pedidos y ventas en otro, junto con vistas o réplicas de solo lectura de las tablas del primer esquema. Esto ayuda a evitar errores al ejecutar transacciones que actualizan los datos maestros.
Herramientas de diseño de bases de datos
Si comprende el modelo relacional, los diagramas de entidad-relación y las técnicas de normalización, puede diseñar bases de datos con solo lápiz y papel. Sin embargo, su rendimiento mejorará considerablemente si utiliza una herramienta inteligente, especialmente una que pueda automatizar ciertas tareas de diseño, como la reubicación o modificación de objetos en un diagrama, la detección de errores de diseño, la generación de secuencias de comandos SQL para crear o actualizar una base de datos y revertir- diseñar un diseño de base de datos existente.
Dominar una herramienta especializada como la plataforma Vertabelo te permitirá trabajar mucho más rápido. Y te permitirá destacarte de otros diseñadores que no cuentan con esta ayuda.
SQL y Programación
A todos nos gustaría poder entregar un diseño de base de datos, decir con orgullo “Mi trabajo aquí está hecho” e irnos a unas merecidas vacaciones. Pero por lo general, esa situación ideal nunca sucede. Una vez que haya terminado su diseño, los programadores de aplicaciones necesitarán usarlo y necesitarán que usted esté cerca para ayudarlos.
Una forma de continuar ayudando en un proyecto de desarrollo es escribir vistas, disparadores, procedimientos almacenados y otras cosas en SQL (lenguaje de consulta estructurado) para resolver las necesidades particulares de la aplicación. Otra forma es supervisar las tareas de programación que se llevan a cabo con algo llamado Mapeo Objeto-Relacional (ORM).
Los ORM están destinados a abstraer el acceso a los datos de un RDBMS en particular. El lado bueno de esto es que los programadores no tienen que preocuparse por los detalles de la base de datos que usarán; en otras palabras, no necesitan preocuparse si el RDBMS es MySQL, Oracle, IBM DB2, MS SQL Server. , o algo más.
La desventaja de los ORM es que los objetos de diseño de la base de datos (tablas, atributos y relaciones) se definen en el código de un lenguaje de programación de alto nivel como Java, Python, R o C#. En otras palabras, están donde los diseñadores de bases de datos no podemos verlos.
La solución a este problema pasa por las metodologías de desarrollo Agile y su filosofía colaborativa. Estos promueven que los diseñadores y programadores trabajen juntos en el transcurso de un proyecto, por lo que querrá mantener una buena relación con los programadores. Debería estar dispuesto a sentarse junto a ellos, mirar el código de programación y escribir juntos las definiciones de los objetos de datos.
Los diseñadores de bases de datos de habilidades blandas deberían tener
Además de los conocimientos teóricos y técnicos específicos del diseño de bases de datos, lo ideal es que un diseñador tenga otras habilidades conocidas como "habilidades interpersonales". Estas habilidades, como ser un buen comunicador y comprender la visión de la empresa para el producto final, impactan indirectamente en el éxito de su trabajo. Las que menciono a continuación son solo algunos ejemplos, pero hay muchas más habilidades blandas que los empleadores potenciales valoran mucho.
Visión empresarial
Cuando diseña una base de datos, está representando la realidad de un negocio en términos de objetos de datos interrelacionados. Hemos visto que el diseño debe cumplir con las condiciones de estandarización y que debe evitar inconsistencias, anomalías y problemas de concurrencia. Pero igual de importante, o quizás más, es que el diseño esté alineado con la visión comercial de quien paga tu salario.
Comprender la visión del negocio le permitirá comprender mejor la importancia de cada requisito y orientar sus decisiones para que sus diseños estén mejor alineados con los objetivos de la organización.
Aquí hay un ejemplo simple de cómo la comprensión de la visión empresarial dará forma a su trabajo. Puede pensar que usar una clave sustituta en una tabla desordena su diseño, agregando un elemento innecesario y molesto. Pero al omitir la clave sustituta, puede ralentizar las consultas en esa tabla porque una clave de tipo INTEGER podría brindar un rendimiento superior. Si la visión comercial es proporcionar consultas rápidas, entonces la clave sustituta es el camino a seguir.
Habilidades de comunicación
No es suficiente hacer grandes diseños. También debe poder explicar por qué su diseño funciona. La forma de hacerlo es saber presentarlo, tanto discursivamente (hablado o escrito) como visualmente.
Haz una lista de las fortalezas de tu diseño para que se destaquen. Piensa en las decisiones que tomaste para crearlo y escribe las razones de esas decisiones. Esté preparado para defender sus decisiones y su diseño ante aquellos que no lo entienden o que quieren cambiarlo, haciéndolo imperfecto o defectuoso.
Pero también debe estar dispuesto a aceptar críticas constructivas y considerar puntos de vista diferentes a los suyos. A veces, un programador puede detectar un problema que no viste y darte un buen consejo. No descarte a sus compañeros de trabajo pensando que no tienen conocimientos de bases de datos.
Habilidades interpersonales
He comentado anteriormente sobre las ventajas de tener una buena relación con los programadores. No importa cuán avanzado esté en su área de especialización, es importante que mantenga una actitud de compañerismo con todos los miembros del equipo, ya sea un probador que detectó un defecto que lo obliga a replantearse parte de su diseño o un gerente de proyecto que necesita para realizar una tarea en una fecha determinada. En resumen, debes ser un jugador de equipo . Nadie quiere tener prima donnas en su equipo que se sientan insustituibles y quieran imponer sus reglas.
Puede suceder que usted no sea el único diseñador de bases de datos en un equipo de desarrollo. Quizás debas liderar un subgrupo de tus colegas. Para hacerlo, debe demostrar habilidades de liderazgo y actuar como gerente de proyecto, asegurándose de que el equipo de diseñadores de bases de datos cumpla con sus objetivos y se mantenga motivado.
Cómo aprender habilidades de diseño de bases de datos
Puedes adquirir las habilidades que necesitas para ser un diseñador de base de datos de títulos universitarios, cursos, libros y artículos especializados. La ventaja de los cursos universitarios es que te dan todos los conocimientos que necesitas y avalan esos conocimientos con un título reconocido. La desventaja es que requieren una gran inversión de tiempo y dinero.
Si prefiere aprender por su cuenta leyendo libros y artículos, ahorrará tiempo y dinero, pero necesitará una guía que lo guíe a través de los temas esenciales y evalúe su conocimiento. Y tendrás que demostrar tus conocimientos de forma práctica, ya que no tendrás una titulación que los avale.
En cualquier caso, ya sea que aprendas tomando cursos o leyendo, ese conocimiento solo te servirá como base. Aprenderá más creando modelos, enfrentando problemas reales y observando las acciones de sus colegas y compañeros de trabajo.
