Curso Profesional de Modelamiento de Bases de Datos

¿Qué es una base de datos? ¿Por qué necesita una estructura? Aquí te explico los conceptos básicos relacionados con el modelamiento de bases de datos

¿Cuántos tipos de bases de datos existen? ¿Cuáles son? Te explico cada uno de los tipos de bases de datos. Al menos los mas importantes, los que más se usan en el mercado actual

¿Aún quedan tipos de bases de datos por descubrir? Por supuesto, aquí completamos esa lista

¿Sabías que el modelamiento de bases de datos se rige por siete principios? Aquí te muestro los primeros cuatro.

¿Cuál es el beneficio de conocer los principios del modelamiento de bases de datos? Te explico esto a través de los principios que falta por reconocer

¿Cuáles son los principales elementos del diseño conceptual? ¿Cuál es la importancia del diseño conceptual? Aquí te explico estas interrogantes.

¿Y cómo se dibuja lo aprendido en la clase anterior? Utilizando un software online llamado app.diagrams.net

¿Cuáles son los tipos de atributos en el diseño conceptual? Aquí te explico los tipos de atributos y su importancia para cada entidad en el diseño conceptual

¿Se pueden clasificar las interrelaciones y entidades en el modelo conceptual? Por supuesto. En esta clase te explico cómo y por qué de estas clasificaciones

¿Cómo se usa draw.io para crear un diseño conceptual? En esta clase te muestro como se usa esta aplicación en la nube para desarrollar un diagrama conceptual de una base de datos

¿Completamos la información? Por supuesto, en esta clase continuamos aprendiendo a usar draw.io para modelar un diagrama en el diseño conceptual

¿Cómo podemos aplicar la cardinalidad en un diseño conceptual? Veamos un ejemplo práctico

¿Qué es la especialización y la generalización en el diseño conceptual? En esta clase te explico de qué trata este proceso y cuál es la importancia dentro del diseño de bases de datos

¿Cómo se implementan especializaciones y generalizaciones en el diseño conceptual? En esta oportunidad te muestro a través de un diagrama el proceso de notación para especializaciones y generalizaciones

¿Cómo se clasifican las especializaciones y generalizaciones? Para explicar en el diseño conceptual el proceso de especialización y generalización de entidades, te muestro qué es una especialización/ generalización disjunta y una solapada

¿Más sobre especializaciones y generalizaciones? Por supuesto. Falta aprender acerca de especializaciones/ generalizaciones del tipo total y parcial.

¿Cómo se implementa la notaciones disjunta-solapada y total-parcial en el diseño conceptual? En esta clase te muestro cómo se implementa.

Caso de estudio para implementar el diseño conceptual del proyecto

¿Cuál es la técnica apropiada para identificar entidades en un proyecto? No es sencillo, pero aquí te propongo una técnica que uso habitualmente para el proceso de descubrir entidades de un modelo de datos

Tras la identificación de entidades en el modelo de datos, en esta primera parte procedemos a diagramar las entidades e interrelaciones

Esta es la segunda parte de la creación del diseño conceptual para continuar con el resto de las entidades identificadas del modelo de datos

En esta sección del proyecto definimos la cardinalidad de cada una de las interrelaciones creadas en el diagrama, con el propósito de lograr mayor información en el sistema

Ahora nos toca definir las especializaciones - generalizaciones del modelo, en las entidades que correspondan y que aporten mayor información al sistema o proyecto

Para complementar el proceso de especializaciones y generalizaciones en el modelo, definiremos los tipos de acuerdo a la naturaleza de la información necesaria para el proyecto.

Luego de haber implementado el diagrama del diseño conceptual de nuestro proyecto, es necesario reflexionar acerca de la importancia de comprender lo mejor posible los procesos de negocio para alinear el modelo de bases de datos con las necesidades de la organización

¿Qué es y para qué sirve el modelo lógico? Eso es lo que aprenderás en esta clase, describiendo la etapa dentro del modelamiento de bases de datos, sus procesos y algunas definiciones importantes, tales como, qué es una clave primaria y una foránea.

¿Entidades en relaciones? En esta clase te muestro cuál es el proceso para transformar entidades del modelo conceptual a relaciones en el modelo lógico, paso a paso.

¿Sabías que la cardinalidad 1:1 en una interrelación binaria tiene dos opciones de transformación? En esta clase te muestro cómo transformar una interrelación binaria con cardinalidad 1:1 en el diseño conceptual, paso a paso, analizando sus opciones.

¿Dónde ubicamos la clave foránea en la cardinalidad 1:N? En esta ocasión abordamos la transformación de la cardinalidad 1:N en la interrelación binaria, repasando conceptos e ideas de la clase anterior para aplicarlas a este proceso.

¿Cuál es la regla que debemos aplicar para transformar cardinalidades N:M? Continuamos con el proceso de transformación de interrelaciones en el diseño lógico, trabajando ahora con la cardinalidad N:M. Explico en esta clase como creamos esa nueva relación para dar cumplimiento a las reglas de transformación del modelo lógico

¿Cómo se transforma una cardinalidad N:M:P? En esta clase abordamos la transformación de una interrelación ternaria con cardinalidad N:M:P a través de un caso práctico, aplicando reglas ya conocidas de este curso

¿Podemos aplicar las mismas reglas conocidas en la cardinalidad N:M:1? En esta clase transformamos la cardinalidad N:M:1 en una interrelación ternaria, aplicando reglas que ya conocemos en el curso

Continuamos en esta clase aplicando técnicas para transformar interrelaciones ternarias con cardinalidad N:1:1 en el diseño lógico

Y ahora veremos como transformar una interrelación ternaria con cardinalidad 1:1:1, aplicando el conocimiento que hemos adquirido

Avanzamos en nuestra comprensión para aplicar técnicas conocidas de transformación de interrelaciones n-arias no importando la cardinalidad

¿Cómo transformamos entidades débiles en el modelo? En esta oportunidad abordamos esta situación aplicando la técnica que se usa en las cardinalidades 1:N en interrelaciones binarias, paso a paso.

Aquí te muestro cuáles son las técnicas generales para transformar especializaciones generalizaciones en el diseño lógico

Ejemplos prácticos para aplicar las técnicas de transformación de especialización - generalización disjunta y total, explicadas en la clase anterior, con sus ventajas y desventajas

¿Cómo transformar especializaciones - especificaciones solapadas totales? En esta clase te muestro la manera de hacerlo con peras y manzanas

En esta clase te muestro el paso a paso para transformar especializaciones y generalizaciones del tipo disjunta o solapada parcial.

En esta clase te muestro a través de una tabla resumen las diversas opciones de transformación de elementos del diseño conceptual al diseño lógico. Comparto documento de apoyo. El primero es una tabla de resumen de las transformaciones enunciadas en las clases y el otro, es un documento que explica los detalles de implementación de las diferentes opciones de transformación realizadas en las clases.

Caso de estudio que implementa el diseño lógico del proyecto

Partimos este proyecto identificando cada una de las entidades del modelo conceptual para transformarlas en el diseño lógico. De esta manera, podremos continuar con el siguiente proceso.

Continuamos transformando la primera interrelación del modelo, entre la entidad Escuela y Espacio Educativo, identificando la cardinalidad y las claves primarias y foráneas de cada una de las relaciones

Ahora, transformamos la interrelación ternaria entre Escuela, Estudiante y Curso identificando las reglas que nos ayudarán a cumplir con el objetivo.

Procedemos a transformar la interrelación entre Incidente y Estudiante, aplicando las reglas estudiadas durante el diseño lógico

Continuamos con la interrelación entre Estudiante y Apoderado para transformar esta cardinalidad N:M

Otra interrelación ternaria en el modelo, entre Estudiante, Asignatura y Profesor. Aplicamos las reglas que ya conocemos para este tipo de interrelación en el diseño lógico

En esta clase abordamos la última interrelación en el proyecto entre Asignatura y Evaluación

Continuamos ahora con las transformaciones de las especializaciones/ generalizaciones del modelo conceptual del proyecto. La primera que abordamos es la que está relacionada con la entidad Espacio Educativo.

¿Que hacemos si tenemos doble jerarquía en una especialización? Aquí te muestro cómo la técnica escogida para transformar especializaciones/ generalizaciones influye en el éxito del proceso

Ahora nos corresponde abordar la especialización asociada a la entidad Incidente del proyecto, aplicando las reglas asociadas a las especializaciones/ generalizaciones disjuntas totales.

Utilizando las mismas técnicas que hemos aplicado para transformar especializaciones/ generalizaciones abordamos el caso de la entidad Apoderado en el proyecto

Al finalizar con esta parte, abordamos la especialización de la entidad Evaluación y, de esta manera, concluimos con el proceso de transformación de especializaciones/ generalizaciones en el proyecto.

Antes de pasar a la siguiente sección de este curso, es bueno reflexionar acerca de la importancia de la realización del diseño lógico dentro de un proyecto de bases de datos en general. Aprovecho de compartir un documento con lo realizado en esta sección.

¿Qué es y para qué sirve el diseño físico? En esta clase te explico la importancia de esta etapa para el proceso de modelamiento de una base de datos

¿Es importante saber términos que ayudan a comprender el modelo físico de la base de datos? Por supuesto, siempre es importante saber conceptos técnicos que te ayuden a saber no solo qué debes hacer, sino también el por qué.

¿Qué procesos son importantes para el diseño físico de una base de datos? Esta etapa también es de transformación de elementos que vienen desde el diseño lógico, por ejemplo, la transformación de relaciones a tablas. En esta clase te explico cada uno de estos procesos.

¿Qué es la normalización en el modelo físico? Es un proceso que permite aceptar o descartar campos o atributos de una tabla. En esta clase te explico el detalle.

¿Cómo se clasifican los atributos clave en el diseño físico? De varias maneras. En esta clase veremos los tipos mas representativos para el modelo de datos

¿Qué es la dependencia funcional? ¿Por qué es importante en el diseño físico? Es un mecanismo o técnica que nos permite organizar una tabla en función de sus atributos.

¿La dependencia funcional posee propiedades? Así es, y en esta clase te explico a quién se le ocurrió identificar estas propiedades. Desde ya te menciono que tienen bases matemáticas y lógicas.

¿Reflexiva? Si, pero no es lo que estás pensando. No se trata de pensar. Es una forma de definir una relación estrecha entre dos atributos. En la clase te lo explico.

¿Dependencia funcional aumentativa? Asi es. El señor Armstrong pensó en aquellos atributos que son necesarios en una tabla, pero que cuesta identificar su dependencia funcional con la clave primaria. Mira la explicación que doy en esta clase.

¿Qué es la dependencia funcional transitiva? No es tan difícil de entender. En esta clase te explico qué es y por qué es importante. Todo irá cuadrando al final de todo.

¿Formas normales? Bueno, si. Es que al final debe haber una forma para implementar todo lo que hemos aprendido acerca de la dependencia funcional, ¿verdad? Esta es la introducción al tema.

La primera forma normal nos ayudará a definir con claridad la estructura de una tabla en el modelo de la base de datos. Solo hay que seguir sus reglas. En esta clase revisamos cuáles son esos criterios o reglas.

Y ahora, la segunda forma normal. Es una confirmación de la primera, pero con la aplicación mas estricta de la dependencia funcional de los atributos no clave de la tabla con su clave primaria. Veamos como se aplica.

No hay tercera sin segunda, dicen. Así es, porque no se puede aplicar la tercera forma normal sin haber aplicado la segunda forma. Ahora sí, nos queda mas claro que solo hay dos tipos de dependencia funcional que debemos aplicar en cada tabla de la base de datos.

¿Cuarta forma normal? ¿Y cuántas son? No te preocupes, solo queda una además de esta. Pero es importante porque nos ayuda a trabajar con esos atributos que generan dependencia multivaluada en nuestros modelos. En esta clase te explico cómo se usa y para qué sirve.

Hemos llegado hasta la quinta forma normal. Esta nos ayuda a materializar de mejor manera aquellas cardinalidades N:M. Son complejas y pueden tender trampas al diseñador/a sin mucha experiencia. En esta clase te muestro su uso y qué cosas hay tener en cuenta para no cometer muchos errores. Después de esto, solo hay que practicar.

En esta clase comenzamos con la creación del diagrama para el diseño físico de nuestro proyecto de bibliioteca.

¿Cuáles son los criterios generales para aplicar en el diseño físico? Estos criterios no son obligatorios, pero nos ayudan a integrar buenas prácticas en la creación de tablas, tales como, la forma de denominar cada tabla o cómo deben nombrarse los campos de ellas.

¿Cuál es la mejor forma para denominar una clave primaria? Este estándar no es obligatorio, pero nos ayuda a implementar buenas prácticas, aplicando criterios de optimización que nos ayudarán a trabajar de manera mas eficiente y efectiva.

¿Cómo se implementa la cardinalidad N:M en el diseño físico? En esta clase implementamos la asociación entre las tablas libros y autores, considerando su cardinalidad y respetando lo que ya habíamos diseñado en los modelos conceptual y lógico.

En la clase anterior nos faltó implementar la union entre las tablas autores y libros con la tabla intermedia autor_libro para darle vida a la cardinalidad N:M. Aquí te muestro cuál es la simbología apropiada para implementar la cardinalidad entre tablas.

En esta clase te muestro cómo el modelo de la base de datos podría gestionar los préstamos y las devoluciones en la biblioteca, ajustando el diseño a las posibles prestaciones que necesitaría este sistema. En los modelos anteriores teníamos una visión que ahora cambia para ajustarse mejor a los procesos de negocio que abordará la base de datos, teniendo en cuenta criterios de normalización adecuados.

¿Cómo se gestionan los lectores dentro del modelo físico? En esta clase creamos la tabla lectores, tomando en cuenta la formas normales del diseño físico y las posibles relaciones con otras tablas ya creadas o por crear.

¿Qué hacemos si descubrimos una dependencia funcional transitiva en nuestro modelo físico? En esta clase abordamos el caso de registrar en la base de datos la comuna en la que viven nuestros lectores. El atributo comuna no tiene relación directa con la clave primaria de la tabla lectores, ya que este atributo representa a un dominio en sí mismo. En este caso, creamos una nueva tabla para registrar todas las comunas que necesitemos y la conectaremos con la tabla lectores a través de una clave foránea, siguiendo los estándares hasta aquí aplicados en nuestro diagrama.

Complementamos lo realizado en la clase anterior, teniendo en cuenta la relación que existe con las tabla préstamos y devoluciones, implementando las claves foráneas respectivas. Aprovechamos de repasar las formas normales consideradas en el diagrama.

En esta clase comenzamos a abordar las especializaciones/ generalizaciones del modelo. Descartamos por ahora la especialización de la tabla lectores, pero abordamos la especialización de la tabla libros, aplicando uno de los criterios explicados en el diseño lógico ya realizado.

En esta clase descubrimos que el atributo nacionalidad de la tabla autores genera dependencia multivaluada, por lo que necesitamos aplicar la cuarta forma normal estudiada anteriormente. Para ello, creamos una nueva tabla llamada nacionalidades. Con este proceso trataremos de evitar la redundancia y problemas asociados con el registro de este tipo de información en la base de datos.

En esta clase reflexionamos acerca de la aplicación adecuada de estándares, buenas prácticas y criterios de normalización ya estudiados en la sección anterior, con el propósito de garantizar procesos de implementación adecuados.

Para finalizar con esta parte, revisamos posibles prestaciones pendientes en el modelo de datos y que podrían implementarse en el futuro del proyecto.

En esta clase revisamos el contexto del proyecto escuela primaria, sus modelos conceptual y lógico para iniciar el modelo físico de la base de datos

¿Por qué ya no va la entidad Escuela en este modelo? Aquí te explico el por qué. En realidad, hay casos en los que una entidad puede servir para representar una realidad tanto en el diseño conceptual como lógico, pero cuando lo pasamos al diseño físico debemos evaluar su real aporte al modelo.

En esta clase comenzamos a representar la tabla espacios, para considerar los espacios educativos de la escuela con su clasificación.

Ahora, abordamos el proceso de incorporar la tabla estudiantes y la comuna a la que pertenece su dirección de residencia. De esta manera, vamos aplicando formas normales para evitar redundancia

En esta clase continuamos con la tabla estudiantes, pero relacionándola con la tabla cursos. Como la interrelación cambió debido al ajuste realizado al inicio del modelo, entonces un estudiante es matriculado en un curso y, el curso podrá matricular a muchos estudiantes

El proyecto incluye el registro de incidentes asociado a estudiantes, entonces, implementamos la tabla incidentes con su tabla tipos para clasificarlos debidamente

En esta oportunidad abordamos la implementación de la tabla apoderados y su relación con una tabla teléfonos. Esta nos permitirá registrar todos los números de teléfonos que tenga disponible un apoderado

La tabla profesores es modelada en el sistema, relacionándola con la tabla comunas para registrar completamente su residencia particular.

Los profesores tendrán la oportunidad de registrar sus especializaciones, las que ayudarán a mejorar la información necesaria para asignarles una o varias asignaturas. La tabla asignaturas se modela con los atributos necesarios para relacionarla con profesores a través de una cardinalidad N:M

¿Complicando el modelo? Sí. A veces es necesario para documentar información de mejor manera, debemos crear nuevas tablas. En este caso, descubrí que las asignaturas tienen niveles. Por ejemplo, la asignatura matemáticas está asignada a un grado; así, puede haber matemáticas para primer grado, segundo grado, etc. Por ello, la tabla niveles podrá clasificar mejor las asignaturas.

¿Como relacionaremos la tabla espacios con el resto del modelo? Si has llegado hasta aquí, habrás notado que la tabla espacios está sola, anclada a sus tipos, sin el resto del modelo. Para ello, crearemos la tabla clases, la cual nos permitirá asociarla con un espacio educativo, con un curso y una asignación.

En esta clase implementaremos la tabla asistencias para registrar la presencia de un estudiante en una clase.

En esta clase asociamos la tabla asistencias con la tabla estudiantes y, a su vez, creamos una tabla que registre el estatus de un estudiante en el sistema para clasificarlo. De esta forma, para diversos propósitos administrativos y académicos un estudiante puede estar en estado regular, retirado u otro que ayude a clasificar la situación de los estudiantes de la escuela

En esta clase creamos la tabla evaluaciones para que pueda registrar las pruebas que pudieran generarse en la escuela como parte del proceso educativo.

En esta clase implementamos la asociación preliminar de la tabla evaluaciones con profesores, asignaturas y estudiantes para darle un sentido en el modelo.

Ahora, trabajamos con la asociación entre las tablas cursos y profesores con el propósito de asociar a un curso el profesor o profesora jefe. Incorporamos el campo respectivo dentro de la tabla profesores para darle consistencia

En esta clase reflexionamos acerca de los elementos que debemos tener presentes para que el modelo de datos quede lo mejor posible: las formas normales, evitar campos derivados y otras cuestiones necesarias.

A partir de esta clase comienzo a revisar algunas inconsistencias presentes en el modelo para corregir aquello que sea evidente. La primera tabla que ajustamos es asistencias, agregando un campo que nos permita saber si un estudiante estuvo presente en una clase o no, corrigiendo la cardinalidad en el modelo.

En esta ocasión agregamos una tabla llamada calificaciones, debido a que necesitamos representar de mejor manera las notas que cada estudiante obtendrá a partir de una evaluación. Es decir, ajustaremos la tabla evaluaciones para que se refleje mejor la información relacionada con pruebas y calificaciones en el modelo.

Damos una revisión a todo lo desarrollado hasta aquí en el modelo físico para ver qué detalles quedan pendientes.

En esta clase, implementamos la relación entre las tablas estudiantes y apoderados a través de la cardinalidad N:M. Se nos había olvidado, pero lo arreglamos aquí

¿Quién fue Edgar Codd? En esta clase te explico el aporte de este científico a las bases de datos relacionales y por qué es importante estudiar el trabajo que él realizó al describir las 12 reglas del modelo relacional.

En esta clase aprendemos acerca de la relación que existe entre el modelo físico de la base de datos y la implementación real en un servidor utilizando SQL (Lenguaje Estructurado de Consultas, por sus siglas en inglés).

En esta clase aprendemos como el uso de tablas es crucial para guardar y organizar los datos dentro de una base de datos.

En esta regla se establece que la información que está almacenada en las tablas debe ser accedida a través del uso de tablas, columnas y clave primaria. Al menos debe considerarse el nombre de la tabla y de columnas para acceder a datos.

En esta regla, se establece el manejo de valores nulos. Los valores declarados como NULL corresponden a una especificación explícita de que en una tabla puede haber columnas cuyos valores pueden ser nulos o no existentes.

Esta regla establece que la información de la base de datos con sus tablas y otros objetos debe ser accedida a través de sus metadatos. En otras palabras, los metadatos pueden otorgar información que permita a los usuarios administrar las bases de datos creadas en el motor respectivo (o sistema de gestión de bases de datos correspondiente).

En esta regla se establece que SQL es un lenguaje que otorga soporte para crear la estructura de la base de datos y la manipulación de los datos propiamente tal. De esta manera, podremos establecer criterios de acceso y administración de la base de datos que estemos utilizando.

En esta clase aprendemos que la forma de acceder a los datos guardados en tablas no se restringe solamente a las tablas reales de la base de datos, sino que también podemos crear vistas a partir de tablas que pueden ser consultadas y modificadas según necesidades específicas. Las vistas son como tablas virtuales que nos permiten manipular información sin tener que usar tablas reales y se utilizan principalmente en consultas complejas.

En esta regla se especifica que los procesos de actualización, inserción y eliminación de datos no deben aplicarse solo a tablas individuales, sino también a conjuntos de filas. Esto permite que si necesitamos modificar datos, por ejemplo, de varias filas, el lenguaje SQL nos permita hacerlo sin complicaciones o limitaciones.

Esta regla establece que sin importar la organización de la estructura de las tablas de la base de datos, la forma de acceder a los datos no cambia, ya que SQL dará soporte a esos ajustes.

En esta regla el acceso a los datos es independiente a la organización lógica de la base de datos. Esto permite hacer ajustes en la estructura de la base de datos sin comprometer el soporte que da el lenguaje SQL.

En esta regla se establece que la integridad de los datos puede ser implementada dentro de la base de datos sin tener que acudir a herramientas adicionales. Si queremos validar información a través de mecanismos de chequeo u otras restricciones, se puede hacer utilizando SQL. Sin embargo, en esta clase también te explico que se puede hacer un enfoque mas distribuido, ya que en las aplicaciones modernas existen herramientas que permiten la ejecución de reglas de integridad de manera inclusive mas eficientes que en la base de datos. Este enfoque solo se puede usar si trabajamos con framework que estén a la vanguardia en materia de desarrollo de software.

En esta regla se entiende que no importando donde se alojen físicamente los datos, la información podrá accederse utilizando un solo lenguaje, en este caso SQL, ya que esta herramienta tiene soporte para el caso descrito en esta clase

A través de esta regla entendemos que no se puede acceder a la información que tiene una base datos de ninguna forma que no sea a través de SQL. Esta regla busca evitar la manipulación riesgosa de datos que comprometan su calidad e integridad.

Hemos llegado prácticamente al final del curso de Modelamiento Profesional de Bases de Datos. En la sección posterior se agregarán algunos desafíos que te ayuden a poner en práctica lo aprendido con la debida supervisión docente. Así que, continúa aprendiendo sin temor.