Introducci贸n

El mundo moderno est谩 completamente centrado en la informaci贸n y los datos.

驴Cu谩l es la diferencia entre informaci贸n y datos?

Los datos son una unidad singular de conocimiento. No tiene valor intr铆nseco por s铆 mismo. No podemos extraerle significado sin saber m谩s al respecto.

La informaci贸n es algo que podemos vincular a los datos, para poder atribuirles un significado.

Por ejemplo: El n煤mero 38 es un dato. Saber que 38 es la edad de Jon es informaci贸n.

Una base de datos es una colecci贸n de informaci贸n cuidadosamente organizada en un sistema.

La tecnolog铆a que permite organizar los datos y representar la informaci贸n esencial para un sistema de informaci贸n se denomina Sistema Gestor de Base de Datos (SGBD) o por sus siglas en ingl茅s (DBMS) Data Base Management System.

Un DBMS es un software que encapsula los datos de una base de datos y nos proporciona una forma de almacenarlos, recuperarlos, editarlos, conservarlos y mucho m谩s.

Le pedimos a un DBMS que sea eficiente, que almacene datos de forma privada y segura, que maneje grandes cantidades de datos.

Aunque una base de datos puede ser tan simple como un archivo de texto separado por comas (CSV), para aplicaciones robustas se recomienda utilizar DBMS como MySQL, PostgreSQL, MongoDB, Oracle, etc.

Algunas ventajas de los DBMS son:

  • Est谩n optimizados para almacenar y manipular grandes cantidades de datos.
  • Ofrecen mayor seguridad y administraci贸n de la informaci贸n.
  • Permiten a varios usuarios acceder y manipular la informaci贸n de forma concurrente.
  • Garantizan la integridad de los datos.

Un DBMS puede contener muchas bases de datos.

Los DBMS se pueden dividir en dos grandes grupos: relacionales (SQL) y no relacionales (NoSQL).

馃敿 Regresar


Tipos de Bases de Datos

Cuando desarrollamos una aplicaci贸n y nos encontramos en el momento de elegir una base de datos, siempre llegamos a un punto en el que nos hacemos la misma pregunta:

驴Qu茅 tipo de base de datos debo elegir?

Independientemente de los distintos gestores de bases de datos que existen en la actualidad, esta pregunta siempre suscita la duda de s铆 debemos elegir una base de datos relacional o no relacional.

Para responder esta pregunta, es muy importante conocer las diferencias entre una y otra y, sobre todo, entender el tipo de aplicaci贸n que estamos realizando, ya que una mala elecci贸n de nuestra base de datos puede dar lugar a una larga lista de problemas durante el desarrollo de la aplicaci贸n.

Bases de Datos Relacionales

Se caracterizan por ser una colecci贸n ordenada de registros que se organizan en un conjunto de tablas. Una tabla es muy parecido a una hoja de c谩lculo, y los registros se organizan en filas y columnas. Estas tablas se relacionan entre s铆. Para acceder a los datos, se usa el Lenguaje de Consultas Estructuradas, mejor conocido por sus siglas en ingl茅s como SQL, Structured Query Language.

Con SQL podemos obtener y alterar datos de una forma organizada siempre y cuando tengamos en cuenta cu谩l es la estructura de la base de datos con la que estamos trabajando. Para ello, utilizaremos los distintos comandos que SQL pone a nuestra disposici贸n.

Las tablas de una bases de datos relacional se organizan a trav茅s de identificadores. De este modo, cada tabla tiene un identificador 煤nico que es el que va a establecer su relaci贸n con el resto de tablas. A su vez, estos identificadores hacen que sea m谩s f谩cil organizar cada una de las tablas por separado.

Los DBMS relacionales se caracterizan por modelar la informaci贸n en tablas que se relacionan entre s铆. Ejemplos son MySQL, MariaDB, PostgreSQL, SQLServer, Oracle, entre otros.

Bases de Datos No Relacionales

Las bases de datos no relacionales est谩n dise帽adas para modelos de datos con estructuras m谩s espec铆ficas y que no necesitan ser relacionados con otros. Cada entidad funciona de forma independiente y son mucho m谩s sencillas que las relacionales.

Esta sencillez de acceso y ordenaci贸n hace que en el panorama actual del Big Data est茅n cobrando mucha relevancia, ya que al no tener una estructura definida como en las relacionales, se puedes tener redundancia de datos, es decir, podemos tener datos repetidos.

驴Por qu茅 se permite esto? Porque lo que buscamos es mejorar el rendimiento y se prioriza el acceso r谩pido por sobre la normalizaci贸n e integridad de los datos. En este tipo de modelos se requiere ahorrar poder computo para poder procesar la mayor cantidad de datos en el menor tiempo posible.

Las bases de datos no relacionales pueden tener identificador 煤nico, pero este no se usar谩 para relacionar unos registros con otros. La informaci贸n se organiza normalmente mediante documentos y es muy 煤til cuando no tenemos un esquema exacto de lo que se va a almacenar.

Con respecto a los formatos que se utilizan en las bases de datos no relacionales, podr铆amos decir que el m谩s popular es el de un documento que es un objeto con una clave y un valor para que el acceso a la informaci贸n se pueda realizar de forma sencilla.

A todo este conjunto de bases de datos no relacionales, tambi茅n se les asocia con el concepto de NoSQL que significa: Not Only SQL, para hacer referencia a que no s贸lo la informaci贸n de un sistema debe almacenarse en modelos relacionales.

Los DBMS no relacionales modelan la informaci贸n de diferentes formas: documentos, llave-valor, grafos, entre otras. Ejemplos de DBMS no relacionales son MongoDB, Redis, Apache Cassandra, Firebase entre otras.

驴Cu谩ndo utilizar SQL o NoSQL?

Despu茅s de esta explicaci贸n, podemos decir que ambos tipos de bases de datos son 煤tiles y depender谩 del tipo de aplicaci贸n que queramos realizar la elecci贸n de una u otra base de datos.

As铆, si queremos desarrollar una aplicaci贸n de tipo contable, de inventario o de informaci贸n de clientes, es probable que el modelo relacional se adapte mejor a nuestras necesidades. En este tipo de aplicaciones, normalmente habr谩 m谩s de una tabla que tenga relaci贸n con el resto, por lo que una base de datos relacional ser谩 m谩s 煤til y podr谩 representar mejor nuestra aplicaci贸n.

Si por el contrario nuestra aplicaci贸n necesita de un sistema en el que los datos que se vayan a almacenar no necesitan relacionarse unos con otros, y adem谩s no tenemos certeza de que todos los datos tengan la misma estructura, entonces usaremos una base de datos no relacional. Por ejemplo puede ser una base de datos en la que solo queramos almacenar las estad铆sticas de comportamiento de un usuario al visitar un sitio, o una base para recolectar sus datos biom茅tricos, esta informaci贸n puede cambiar de una persona a otra, dependiendo de sus din谩micas con el sitio o de su estado de salud y condici贸n f铆sica para los biom茅tricos. Otro ejemplo ser铆a la creaci贸n de una galer铆a de fotos en Facebook o Instagram, cada usuario puede subir la cantidad de fotos que guste sin que exista una estructura determinada. Las estad铆sticas de progreso de un videojuego tambi茅n ser铆an un buen ejemplo de modelo no relacional, ya que la informaci贸n de un jugador a otro puede variar.

Todos estos ejemplos almacenan la informaci贸n y no la relacionan entre s铆.

Por todo lo anterior, la elecci贸n del tipo de base de datos es algo muy importante y que no hay que tomarlo a la ligera. La elecci贸n de un DBMS err贸neo puede traer consecuencias fatales en el desarrollo de un proyecto, por lo que es muy importante dedicarle tiempo y ver qu茅 tipo se adapta mejor con el modelo de nuestro proyecto.

La principal diferencia entre las bases de datos SQL y NoSQL es su estructura de almacenamiento de datos.

Las bases de datos SQL utilizan una estructura organizada y relacional, mientras que las bases de datos NoSQL utilizan una estructura m谩s flexible y escalable. Ambas tienen sus propias fortalezas y debilidades, y la elecci贸n de una depende de las necesidades espec铆ficas de la aplicaci贸n y el tipo de datos que deben almacenarse.

Tabla SQL VS Documento NoSQL

Aqu铆 hay algunas consideraciones que puedes tener en cuenta al elegir entre un modelo de base de datos SQL y NoSQL:

SQL

  • Relaciones estructuradas: Si tu aplicaci贸n depende de relaciones estructuradas y complejas entre tus datos, es posible que desees considerar una base de datos SQL. Ya que permiten modelar relaciones complejas entre sus tablas y utilizar lenguajes de consulta estandarizados para realizar consultas complejas.
  • Datos estructurados: Si tus datos tienen una estructura bien definida y poco probable que cambie con frecuencia, una base de datos SQL es una buena opci贸n, ya que permiten definir esquemas rigurosos que garantizan la integridad de los datos y evitan la introducci贸n de datos err贸neos o inconsistentes.

NoSQL

  • Escalabilidad: Si tu aplicaci贸n est谩 destinada a crecer r谩pidamente y manejar una gran cantidad de datos, es posible que desees considerar una base de datos NoSQL. Estas son m谩s escalables que las bases de datos SQL y se adaptan mejor a grandes cantidades de datos no estructurados.
  • Datos no estructurados: Si tus datos no tienen una estructura bien definida o cambian con frecuencia, es posible que desees considerar una base de datos NoSQL. Estas son m谩s flexibles que las bases de datos SQL y te permiten modelar tus datos de manera m谩s natural.
  • Aplicaciones en tiempo real: Si tu aplicaci贸n requiere una respuesta r谩pida y en tiempo real, es posible que desees considerar una base de datos NoSQL. Estas suelen ser m谩s eficientes que las bases de datos SQL en t茅rminos de rendimiento y escalabilidad en aplicaciones en tiempo real.

En 煤ltima instancia, la elecci贸n entre un modelo de base de datos SQL o NoSQL depende de las necesidades espec铆ficas de tu aplicaci贸n y de la naturaleza de tus datos. Es importante evaluar cuidadosamente tus requisitos y considerar las fortalezas y debilidades de cada opci贸n antes de tomar una decisi贸n.

馃敿 Regresar


Entidades y Atributos

Una entidad es un objeto del mundo real que se pretende controlar dentro del sistema, por ejemplo: una persona, un producto, una cuenta, un servicio, una empresa, una compra, etc.

Las entidades al ser objetos, van a tener caracter铆sticas que las describen, a estas propiedades se les llama atributos de la entidad.

Por ejemplo la entidad persona tiene atributos tales como: nombre, apellidos, fecha de nacimiento, domicilio, tel茅fono, correo, etc.

Lo primero que tenemos que hacer al dise帽ar una base de datos es hacer un listado de las entidades que se ver谩n involucradas en el sistema y de sus atributos.

Tipos de Entidades

De Datos

Las entidades de datos son aquellas que alimentan el sistema de informaci贸n. En ellas se almacenan y se interact煤a con los datos.

Pivotes

Las entidades pivotes son las que relacionan la informaci贸n de 2 o m谩s entidades. Nos ayudan a mantener consistencia e integridad en el sistema y evitan la duplicidad de datos. Tambi茅n suelen llamarse entidades de enlace o asociaci贸n.

Por ejemplo en el proceso de una venta, una entidad pivote puede almacenar la relaci贸n de qu茅 y cu谩ntos productos se adquirieron en dicha venta, adem谩s de relacionar dichos productos con la informaci贸n del cliente que los compr贸.

Cat谩logos

Los cat谩logos son entidades que sus registros son una lista o relaci贸n ordenada con alg煤n criterio y por tal motivo su informaci贸n debe estar precargada en el sistema, antes de comenzar a introducir informaci贸n en el.

Una lista de c贸digos postales, colonias, municipios, cuidades o pa铆ses son un buen ejemplo de entidades c谩talogo.

C贸digos Postales
Pa铆ses

馃敿 Regresar


Tipos de Datos

En las bases de datos existen varios tipos de datos que se pueden almacenar y manejar. Algunos de los tipos de datos m谩s comunes incluyen:

  • N煤meros enteros: se utilizan para almacenar n煤meros enteros, como por ejemplo, edad, cantidad de productos, etc.
  • N煤meros de punto flotante: se utilizan para almacenar n煤meros con decimales, como por ejemplo, precios, coordenadas, etc.
  • Cadenas de texto: se utilizan para almacenar caracteres y texto, como por ejemplo, nombres, direcciones, descripciones, etc.
  • Fechas y horas: se utilizan para almacenar fechas y horas, como por ejemplo, fechas de nacimiento, fechas de entrega, etc.
  • Booleanos: se utilizan para almacenar valores verdaderos o falsos, como por ejemplo, si un usuario est谩 activo o no.
  • Blobs y archivos: se utilizan para almacenar archivos grandes como im谩genes, videos, audio, etc.
  • Datos geogr谩ficos: se utilizan para almacenar informaci贸n geogr谩fica, como por ejemplo, ubicaci贸n, direcciones, etc.

Estos son solo algunos ejemplos de los tipos de datos que se pueden almacenar y manejar en una base de datos. El tipo de datos que utilices depende de las necesidades espec铆ficas de la aplicaci贸n y de la naturaleza de los datos.

馃敿 Regresar


CRUD

CRUD es un acr贸nimo que significa Create, Read Update & Delete, es decir: "Crear, Leer, Actualizar y Eliminar".

Se refiere a las 4 operaciones b谩sicas que se pueden realizar en una base de datos, es decir, la capacidad de crear nuevos registros, leer, actualizar y eliminar los registros existentes.

Estas operaciones se consideran la funcionalidad b谩sica que se espera de cualquier sistema de gesti贸n de bases de datos, y suelen estar implementadas de manera nativa en la mayor铆a de los SGBD.

Estas operaciones se utilizan tanto en la administraci贸n de objetos y privilegios de la base de datos como en la gesti贸n de los datos mismos.

CRUD

馃敿 Regresar


L贸gica de Negocio

La l贸gica de negocios es el conjunto de reglas, pol铆ticas y procesos que describen c贸mo se lleva a cabo el negocio.

En el modelado de una base de datos, la l贸gica de negocios se refiere a la representaci贸n de las reglas y procesos de negocios en el modelo de datos.

Estas reglas y procesos incluyen cosas como la validaci贸n de los datos, la validaci贸n de las restricciones de negocios, la definici贸n de las relaciones entre las entidades, y la definici贸n de c贸mo se deben calcular ciertos valores.

La incorporaci贸n de la l贸gica de negocios en el modelo de datos es importante porque permite asegurarse de que los datos est茅n correctamente validados y se respeten las restricciones de negocios antes de ser almacenados en la base de datos.

Tambi茅n permite a los desarrolladores entender mejor c贸mo los datos se relacionan y se utilizan en un sistema, lo que puede ser 煤til a la hora de realizar tareas de mantenimiento o mejora.

Adem谩s, la l贸gica de negocios puede ser reutilizada en diferentes partes de la aplicaci贸n, lo que reduce el esfuerzo y el tiempo necesarios para implementar la misma l贸gica en m煤ltiples lugares.

馃敿 Regresar


Llaves

Una llave en bases de datos es un identificador que permite hacer 煤nico a un registro de informaci贸n tenemos 2 tipos: primarias y for谩neas.

Llave Primaria

Identifica un registro como 煤nico dentro de la entidad a la que pertenece. En nuestro listado de atributos pondremos las siglas PK de Primary Key delante del atributo que sea llave principal.

Llave For谩nea

Relaciona los datos de un registro de una entidad con los de otra, o con un registro distinto de la misma entidad. En nuestro listado de atributos pondremos las siglas FK de Foreign Key delante del atributo que sea llave for谩nea.

Atributos 脷nicos

En algunas ocasiones vamos a necesitar que algunos atributos de la entidad sean 煤nicos, es decir que no existan datos duplicados en el atributo, sin que necesariamente sea una llave primaria o for谩nea.

Esta caracter铆stica se utiliza a menudo para asegurarse de que los datos sean consistentes y no haya duplicados en la entidad. Por ejemplo para que un usuario no pueda crear 2 cuentas diferentes con un mismo correo o n煤mero de tel茅fono.

Datos que suelen definirse como atributos 煤nicos podr铆an ser el DNI, email, tel茅fono m贸vil, nombre de usuario o alias, n煤mero de placas de un autom贸vil, etc.

馃敿 Regresar


Relaciones

Las relaciones son asociaciones entre entidades que se crean para recuperar y vincular datos.

Para crear una relaci贸n sem谩nticamente utiliza un verbo para relacionar las entidades en cuesti贸n.

Tipos de Relaciones

  • 1 a 1: Una persona (e) pose茅 (r) una 煤nica clave de estudiante (e) y viceversa.
  • 1 a M: Una factura (e) se emite (r) a una persona (e) y s贸lo a una, pero una persona (e) puede tener (r) varias facturas (e) emitidas a su nombre.
  • M a M: Un cliente (e) puede comprar (r) varios productos (e) y un producto (e) puede ser comprado (r) por varios clientes (e).

馃敿 Regresar


Modelo Entidad-Relaci贸n

Un diagrama modelo entidad-relaci贸n es una herramienta para el modelo de datos, la cual facilita la representaci贸n de entidades de una base de datos.鈥

Se caracteriza por utilizar una serie de s铆mbolos y reglas para representar los datos y sus relaciones. Con este modelo conseguimos representar de manera gr谩fica la estructura l贸gica de una base de datos.

Ejemplo de Diagrama Modelo Entidad-Relaci贸n

  • Las entidades se representan con rect谩ngulos.
  • Los atributos se representan con 贸valos que se conectan a la entidad a la que pertenecen.
  • Los atributos que son llaves primarias se subrayan.
  • Las relaciones se representan con rombos que conectan a las entidades relacionadas, dentro del rombo se coloca el verbo que hace la relaci贸n entre las entidades.

Hay una variante a este diagrama, que se llama Modelo Relacional de la Base de Datos que tambi茅n ejemplifica gr谩ficamente la relaci贸n de las entidades y la descripci贸n de los atributos de estas.

Ejemplo de Diagrama Modelo Relacional de Base de Datos

Personalmente prefiero este tipo de diagrama por sobre el modelo entidad-relaci贸n, ya que nos permite describir el tipo de dato de cada atributo y se vuelve m谩s f谩cil de manejar al tener cada entidad en una tabla con sus respectivos atributos.

Este tipo de diagramas lo puedes hacer con cualquier aplicaci贸n o software de dise帽o o diagramaci贸n, yo uso Diagrams que es gratuita.

馃敿 Regresar


Normalizaci贸n

La normalizaci贸n de bases de datos es un proceso que se utiliza para organizar y optimizar la estructura de una base de datos para asegurar su integridad, evitar la redundancia y mejorar el rendimiento. La normalizaci贸n consiste en la divisi贸n de las entidades en varias entidades m谩s peque帽as y relacionarlas mediante llaves for谩neas.

La normalizaci贸n se realiza a trav茅s de varios niveles o formas, cada uno de los cuales representa un grado de descomposici贸n de la entidad original. Los tres niveles m谩s comunes de normalizaci贸n son la Primera Forma Normal (1FN), la Segunda Forma Normal (2FN) y la Tercera Forma Normal (3FN), aunque existen otros 2 niveles.

El objetivo de la normalizaci贸n es reducir la redundancia y garantizar la integridad de los datos al asegurar que cada dato solo se almacene en un solo lugar y que los datos sean consistentes y coherentes. La normalizaci贸n tambi茅n ayuda a mejorar el rendimiento de la base de datos, ya que reduce el tama帽o y la complejidad de las entidades, lo que facilita la indexaci贸n y la b煤squeda de informaci贸n.

Es importante tener en cuenta que la normalizaci贸n puede tener un impacto en el rendimiento de la aplicaci贸n, ya que puede requerir una mayor cantidad de consultas y una complejidad adicional para recuperar y manipular datos. Por lo tanto, es importante encontrar un equilibrio entre la normalizaci贸n y la eficiencia en el dise帽o de la base de datos.

Formas Normales

Las formas normales son est谩ndares para la organizaci贸n y modelamiento de datos en una base de datos relacional. En total existen 5 formas normales.

  1. Primera Forma Normal (1FN): Cada atributo de una entidad debe contener solo valores at贸micos, es decir, valores indivisibles que no pueden ser divididos en atributos m谩s peque帽os.
  2. Segunda Forma Normal (2FN): Adem谩s de cumplir con la 1FN, cada atributo no dependiente funcionalmente de la llave principal debe estar en una entidad separada.
  3. Tercera Forma Normal (3FN): Adem谩s de cumplir con la 2FN, todas las dependencias funcionales deben ser eliminadas, es decir, no deben existir dependencias funcionales transitorias.
  4. Cuarta Forma Normal (4FN): Tambi茅n llamada de Forma Normal de Boyce-Codd (FNBC), es una forma m谩s restrictiva que la 3FN, donde se garantiza que no existan dependencias funcionales parciales o transitivas en la entidad.
  5. Quinta Forma Normal (5FN): Tambi茅n conocida como Forma Normal de Domino-Clave (FNDC), en ella se debe garantizar que no haya dependencias m煤ltiples de conjuntos en las entidades.

Al aplicar las formas normales a un modelo de base de datos, se puede asegurar que los datos sean consistentes, que no haya redundancia y que sea f谩cil de mantener y escalar.

Sin embargo, tambi茅n es importante tener en cuenta que la aplicaci贸n de formas normales m谩s rigurosas puede resultar en una estructura de base de datos m谩s compleja y menos eficiente en t茅rminos de rendimiento. Por lo tanto, es importante encontrar un equilibrio entre la integridad de los datos y la eficiencia en el dise帽o de un modelo de base de datos.


  • Primera Forma Normal: En la 1FN, cada columna de una tabla debe contener 煤nicamente valores at贸micos, es decir, valores simples que no pueden ser divididos en partes m谩s peque帽as.
  • Segunda Forma Normal: La 2FN requiere que cada columna no dependiente funcionalmente de la clave primaria de una tabla sea movida a una tabla separada. Esto significa que cada tabla debe representar un solo hecho o concepto.
  • Tercera Forma Normal: La 3FN requiere que todas las dependencias funcionales sean removidas de la tabla, es decir, que no haya redundancia de informaci贸n.
  • Forma Normal de Boyce-Codd: La FNBC es una forma normal m谩s rigurosa que la anteriores y requiere que cada dependencia funcional sea una clave candidata 煤nica.
  • Forma Normal de Dominio-Clave: Esta forma normal (FNDC) es una extensiones de la FNBC y se utiliza para asegurar la integridad de los datos en modelos de datos m谩s complejos. No debe haber dependencias funcionales m煤ltiples, es decir, una dependencia funcional en la que varios atributos dependen de una clave externa.

Normalizando una base de datos

Veamos un ejemplo de normalizaci贸n de base de datos.

Tenemos una entidad desnormalizada de "Ventas" de una tienda con la siguiente informaci贸n:

Puedes normalizarme el siguiente modelo de datos

Venta Fecha Cliente Correo Tel茅fono Direcci贸n Ciudad Pa铆s Producto Precio Cantidad
1 01/01 Juan Perez juan.perez@gmail.com 5512345678 Calle 1 No. 58-1 CP 03100 CDMX M茅xico Laptop 25,000.00 2
2 02/01 Pedro Gomez pedro.gomez@gmail.com 3387654321 Calle 2 No. 85-6 CP 44100 Guadalajara M茅xico Celular 12,000.00 3
3 03/01 Ana Silva ana.silva@gmail.com 8109128734 Calle 3 No. 33-3 CP 64000 Monterrey M茅xico Micr贸fono 2,500.00 1
4 04/01 Ana Silva ana.silva@gmail.com 8109128734 Calle 3 No. 33-3 CP 64000 Monterrey M茅xico Laptop 25,000.00 1
5 05/01 Juan Perez juan.perez@gmail.com 5512345678 Calle 4 45-3 03920 CDMX M茅xico Micr贸fono 2,500.00 3

La primera forma normal busca tener valores at贸micos, es decir datos simples que no puedan ser divididos en parte m谩s peque帽as, por lo que en el modelo anterior podr铆amos atomizar el nombre del cliente y su direcci贸n quedando de la siguiente forma:

Venta Fecha Nombre Apellido Correo Tel茅fono Calle N煤mero CP Ciudad Pa铆s Producto Precio Cantidad
1 01/01 Juan Perez juan.perez@gmail.com 5512345678 Calle 1 58-1 03100 CDMX M茅xico Laptop 25,000.00 2
2 02/01 Pedro Gomez pedro.gomez@gmail.com 3387654321 Calle 2 85-6 44100 Guadalajara M茅xico Celular 12,000.00 3
3 03/01 Ana Silva ana.silva@gmail.com 8109128734 Calle 3 33-3 64000 Monterrey M茅xico Micr贸fono 2,500.00 1
4 04/01 Ana Silva ana.silva@gmail.com 8109128734 Calle 3 33-3 64000 Monterrey M茅xico Laptop 25,000.00 1
5 05/01 Juan Perez juan.perez@gmail.com 5512345678 Calle 4 45-3 03920 CDMX M茅xico Micr贸fono 2,500.00 3

La segunda forma normal se refiere a la eliminaci贸n de las dependencias funcionales parciales. En este caso, podemos identificar que los datos del cliente se duplican en las ventas.

Por lo tanto, podemos crear una entidad separada llamada "Clientes" que almacene estos datos y en la entidad principal "Ventas" agregamos la llave for谩nea que haga referencia al cliente.

Venta Fecha Cliente Producto Precio Cantidad
1 01/01 1 Laptop 25,000.00 2
2 02/01 2 Celular 12,000.00 3
3 03/01 3 Micr贸fono 2,500.00 1
4 04/01 3 Laptop 25,000.00 1
5 05/01 1 Micr贸fono 2,500.00 3
Cliente Nombre Apellido Correo Tel茅fono Calle N煤mero CP Ciudad Pa铆s
1 Juan Perez juan.perez@gmail.com 5512345678 Calle 1 58-1 03100 CDMX M茅xico
2 Pedro Gomez pedro.gomez@gmail.com 3387654321 Calle 2 85-6 44100 Guadalajara M茅xico
3 Ana Silva ana.silva@gmail.com 8109128734 Calle 3 33-3 64000 Monterrey M茅xico
1 Juan Perez juan.perez@gmail.com 5512345678 Calle 4 45-3 03920 CDMX M茅xico

Sin embargo al extraer los datos del cliente se genera duplicidad de informaci贸n, ya que se detecta que un cliente puede tener m谩s de una direcci贸n, por lo que es necesario crear una entidad separada llamada "Direcciones" que almacene estos datos y en la entidad principal "Ventas" agregamos la llave for谩nea que haga referencia a dicha direcci贸n y finalmente la entidad "Clientes" s贸lo quedar铆a con la informaci贸n personal de la persona.

Por lo que el modelo quedar铆a de la siguiente forma:

Venta Fecha Cliente Direcci贸n Producto Precio Cantidad
1 01/01 1 1 Laptop 25,000.00 2
2 02/01 2 2 Celular 12,000.00 3
3 03/01 3 3 Micr贸fono 2,500.00 1
4 04/01 3 3 Laptop 25,000.00 1
5 05/01 1 4 Micr贸fono 2,500.00 3
Cliente Nombre Apellido Correo Tel茅fono
1 Juan Perez juan.perez@gmail.com 5512345678
2 Pedro Gomez pedro.gomez@gmail.com 3387654321
3 Ana Silva ana.silva@gmail.com 8109128734
Direcci贸n Cliente Calle N煤mero CP Ciudad Pa铆s
1 1 Calle 1 58-1 03100 CDMX M茅xico
2 2 Calle 2 85-6 44100 Guadalajara M茅xico
3 3 Calle 3 33-3 64000 Monterrey M茅xico
4 1 Calle 4 45-3 03920 CDMX M茅xico

La tercer forma normal exige que no haya transparencias funcionales. Esto se logra removiendo todas las dependencias transitivas, es decir, aquellas dependencias en las que un atributo depende indirectamente de otro a trav茅s de un tercer atributo.

En este caso, la entidad "Ventas" ya est谩 en la segunda forma normal, as铆 que podemos continuar con la eliminaci贸n de dependencias transitivas.

La entidad "Ventas" depende transitoriamente del "Producto" a trav茅s de "Precio". Por lo tanto, debemos crear una entidad adicional para los "Productos" que incluya la informaci贸n de estos.

Por lo cual nuestro modelo quedar铆a de la siguiente forma:

Venta Fecha Cliente Direcci贸n Producto Cantidad
1 01/01 1 1 1 2
2 02/01 2 2 2 3
3 03/01 3 3 3 1
4 04/01 3 3 1 1
5 05/01 1 4 3 3
Producto Nombre Precio
1 Laptop 25,000.00
2 Celular 12,000.00
3 Micr贸fono 2,500.00
Cliente Nombre Apellido Correo Tel茅fono
1 Juan Perez juan.perez@gmail.com 5512345678
2 Pedro Gomez pedro.gomez@gmail.com 3387654321
3 Ana Silva ana.silva@gmail.com 8109128734
Direcci贸n Cliente Calle N煤mero CP Ciudad Pa铆s
1 1 Calle 1 58-1 03100 CDMX M茅xico
2 2 Calle 2 85-6 44100 Guadalajara M茅xico
3 3 Calle 3 33-3 64000 Monterrey M茅xico
4 1 Calle 4 45-3 03920 CDMX M茅xico

La cuarta forma normal (Boyce-Codd), es m谩s restrictiva con las dependencias transitivas, por lo que analizando la informaci贸n del modelo detectamos que la entidad "Direcciones" sigue dependiendo del "Pa铆s", por lo que debemos crear una entidad adicional que contenga la informaci贸n de dicho atributo.

Finalmente la quinta forma normal (Dominio-Clave) exige eliminar cualquier dependencia funcional m煤ltiple, pero en este modelo no existen por lo que tambi茅n cumple con esta 煤ltima forma normal.

Al final de la normalizaci贸n el modelo quedo de la siguiente manera:

Venta Fecha Cliente Direcci贸n Producto Cantidad
1 01/01 1 1 1 2
2 02/01 2 2 2 3
3 03/01 3 3 3 1
4 04/01 3 3 1 1
5 05/01 1 4 3 3
Producto Nombre Precio
1 Laptop 25,000.00
2 Celular 12,000.00
3 Micr贸fono 2,500.00
Cliente Nombre Apellido Correo Tel茅fono
1 Juan Perez juan.perez@gmail.com 5512345678
2 Pedro Gomez pedro.gomez@gmail.com 3387654321
3 Ana Silva ana.silva@gmail.com 8109128734
Direcci贸n Cliente Calle N煤mero CP Ciudad Pa铆s
1 1 Calle 1 58-1 03100 CDMX 1
2 2 Calle 2 85-6 44100 Guadalajara 1
3 3 Calle 3 33-3 64000 Monterrey 1
4 1 Calle 4 45-3 03920 CDMX 1
Pa铆s Nombre Dominio
1 M茅xico mx

馃敿 Regresar


Modelado de Datos

  1. Identificar las entidades del sistema.
  2. Identificar los atributos de las entidades.
  3. Identificar las llaves primarias y for谩neas.
  4. Asignar una nomenclatura adeacuada a las entidades y sus atributos.
  5. Identificar las entidades pivote del sistema.
  6. Identificar los cat谩logos del sistema.
  7. Identificar los tipos de relaciones del sistema.
  8. Crear el Modelo Entidad-Relaci贸n del sistema.
  9. Crear el Modelo Relacional de la base de datos del sistema.
  10. Identificar los tipos de dato de los atributos de las entidades del sistema.
  11. Identificar los atributos que puedan ser 煤nicos en el sistema.
  12. Identificar las reglas de negocio (Operaciones CRUD) del sistema.

馃敿 Regresar


Aprende m谩s

Si est谩s interesado en aprender m谩s sobre bases de datos, no te pierdas mis cursos totalmente gratuitos en mi canal de YouTube.

隆隆隆Accede ya!!!

Ver Cursos

馃敿 Regresar