Mis apuntes
P.D: Esta clase costo tiempo XD
Bienvenida conceptos básicos y contexto histórico de las Bases de Datos
Bienvenida conceptos básicos y contexto histórico de las Bases de Datos
Introducción a las bases de datos relacionales
Historia de las bases de datos relacionales
Entidades y atributos
Entidades de Platzi Blog
Relaciones
Múltiples muchos
Diagrama ER
Diagrama Físico: tipos de datos y constraints
Diagrama Físico: normalización
Formas normales en Bases de Datos relacionales
Diagrama Físico: normalizando Platziblog
RDBMS (MySQL) o cómo hacer lo anterior de manera práctica
¿Qué es RDB y RDBMS?
Instalación local de un RDBMS (Windows)
Instalación local de un RDBMS (Mac)
Instalación local de un RDBMS (Ubuntu)
Clientes gráficos
Servicios administrados
SQL hasta en la sopa
Historia de SQL
DDL create
CREATE VIEW y DDL ALTER
DDL drop
DML
¿Qué tan standard es SQL?
Creando Platziblog: tablas independientes
Creando Platziblog: tablas dependientes
Creando Platziblog: tablas transitivas
Consultas a una base de datos
¿Por qué las consultas son tan importantes?
Estructura básica de un Query
SELECT
FROM
Utilizando la sentencia FROM
WHERE
Utilizando la sentencia WHERE nulo y no nulo
GROUP BY
ORDER BY y HAVING
El interminable agujero de conejo (Nested queries)
¿Cómo convertir una pregunta en un query SQL?
Preguntándole a la base de datos
Consultando PlatziBlog
Introducción a la bases de datos NO relacionales
¿Qué son y cuáles son los tipos de bases de datos no relacionales?
Servicios administrados y jerarquía de datos
Manejo de modelos de datos en bases de datos no relacionales
Top level collection con Firebase
Creando y borrando documentos en Firestore
Colecciones vs subcolecciones
Recreando Platziblog
Construyendo Platziblog en Firestore
Proyecto final: transformando tu proyecto en una db no relacional
Bases de datos en la vida real
Bases de datos en la vida real
Big Data
Data warehouse
Data mining
ETL
Business intelligence
Machine Learning
Data Science
¿Por qué aprender bases de datos hoy?
Bonus
Bases de datos relacionales vs no relacionales
Elegir una base de datos
La normalización como su nombre lo indica nos ayuda a dejar todo de una forma normal. Esto obedece a las 12 reglas de Codd y nos permiten separar componentes en la base de datos:
Aportes 391
Preguntas 96
Mis apuntes
P.D: Esta clase costo tiempo XD
Excelente clase, estos son mis apuntes:
1FN Primera forma normal: Atributos atómicos (Sin campos repetidos). Esto quiere decir que ningún campo puede tener el mismo tipo de valor como varios campos materia (materia1, materia2,…).
2FN Segunda forma normal: Cumplir con 1FN y Cada campo de la tabla debe depender de una clave única. Es decir en las tablas no se puede repetir los campos primarios ya que los mismos son únicos por tanto si existe una relación uno a muchos se debe crear una tabla aparte donde cohabitaran la llave primaria de la primera tabla y la llave primaria de la segunda tabla de esta forma logramos relacionar de manera efectiva dos tablas respetando las llaves primarias.
3FN Tercera forma normal: Cumple 1FN y 2FN y los campos que NO son clave NO deben tener dependencias. Esto nos indica que todos los campos de la tabla deben estar estrechamente relacionados con el campo primario y no serlo de manera transitiva, por ejemplo, en una tabla torneos tenemos el código del torneo el nombre el ganador y la fecha de nacimiento del ganador, como observamos no podemos tener la fecha de nacimiento del ganador en dicha tabla ya que no está relacionada para nada con el torneo y además existe la posibilidad que en varios registros el mismo ganador tenga diferentes fechas de nacimiento por lo cual no mantendría la consistencia de los datos.
4FN Cuarta forma normal: Cumplir 1FN 2FN y 3FN. Los campos multivaluados se identifican por una clave única. Cuando relacionamos dos tablas totalmente independientes cada una de la otra debemos relacionarlas a través de una tabla aparte de las mismas donde solo colocaremos las llaves primarias de cada tabla ya que colocar cualquier otra información relacionada con las tablas implicaría repetir datos, además de hacer la tarea de actualización de registros primarias más compleja, ya que por ejemplo si deseo actualizar el nombre del curso no solo lo tendría que hacer en la tabla cursos sino también en cada tabla donde coloque el nombre lo cual no garantiza la integridad de la información, adiciona información innecesaria en los registros y hace más complejo el trabajo de administrar los datos.
Proceso de normalización El proceso de normalización es un estándar que consiste, básicamente, en un proceso de conversión de las relaciones entre las entidades, evitando:
Como decía el narrador de PES: parece fácil pero hay que ser muy hábil para hacer eso.
En base a lo explicado ¿Por qué la tabla de curso no esta dividida en dos?
Es decir en una tabla llamada niveles, con los campos: id_nivel y nivel, y la tabla cursos tenga los campos: id_curso, nombre_curso y id_nivel. ¿Por qué razón no se divide? Gracias de antemano.
Creo que, antes de empezar a diseñar la base de datos se debe de documentarse, conocer el entorno de la empresa, sus objetivos, etc.
Para analizar si una relación no se encuentra en 3FN buscamos un subconjunto de atributos que no pertenezca a la clave primaria y que al cambiar el valor de un atributo, necesariamente cambia el valor de los demás atributos del subconjunto.
Eje:
Observemos ahora lo que pasa con los atributos Código de cliente y Nombre de Cliente. ¿Qué pasaría si cambiamos el código de cliente? Que necesariamente cambiaría el nombre de cliente. Esto quiere decir que existe una dependencia funcional entre estos dos campos, y eso indica que la relación NO se encuentra en 3FN (Tercera forma normal).
La normalización es útil para separar la información, minimizar la redundancia de los datos, para que la actualización de los datos sea más sencilla y la integridad de los datos se conserve.
Primera forma normal (1FN)
Atributos atómicos (Sin campos repetidos).
Para un atributo sólo debe existir una columna, si surge la necesidad, no se debe crear otra columna (Esto porque si crees que con n columnas es suficiente, tarde que temprano necesitarás n+1) Sencillamente se añade un identificador y posteriormente se divide por filas.
Segunda forma normal (2FN)
Cumple 1FN y cada campo de la tabla debe depender de una clave única.
Esto nos ayuda a tener datos más organizados, y distinguir entre si un atributo hace parte de una entidad, o si son dos entidades separadas relacionadas estrechamente.
Tercera forma normal (3FN)
Cumple 1FN, 2FN y los campos que no son clave no deben tener dependencias.
Sí un dato de un atributo esta directamente relacionado con otro, para que al editar un dato, no deba editar otro campo y haya espacio a errores (porque alguno “se me olvidó”), se separa en una tabla diferente de esta manera la actualización de los datos es más limpia.
Cuarta forma normal (4FN)
Cumple 1FN, 2FN, 3FN y los campos multivaluados se identifican por una clave única.
Esta es usualmente útil cuándo se tiene una cardinalidad N:M, de muchos a muchos, y simplemente se crea una tabla especial para relacionar las claves únicas de las entidades.
Este profe explica excelente pero tiene cara de preocupación constante.
En conclusión: **Normalizar **nos permite estructurar bien la información y almacenarla de forma clara y concreta, para tener una mayor flexibilidad a la hora de almacenar nuevos datos, generar nuevas relaciones y extraer o editar datos.
mi resumen con lo que entendi.
1.Hey no repitas ese atributo
2.Cuidado , ese id debe de ser unico
3.Esa no es tu familia
4.Ese valor no tiene que repetirse , mejor ponlo en otra tabla con su propio id
1 FN : Sus atributos contienen valores atómicos: No podemos tener campos repetidos.
2 FN: | Dede estar aplicada la primera forma normal. || El campo de la tabla debe depender de una unica clave. (primary key)
3 FN: | Debe estar aplicada la primera y segunda forma normal. || Los campos que no sean claves no puede existir dependencia.
4 FN: | Debe estar aplicada la primera, segunda y tercera forma normal || Los campos multivaluados se identifican en una clave única.
Las bases de datos relacionales se normalizan para:
Evitar la redundancia de los datos.
Disminuir problemas de actualización de los datos en las tablas.
Proteger la integridad de los datos.
Facilitar el acceso e interpretación de los datos.
Reducir el tiempo y complejidad de revisión de las bases de datos.
Optimizar el espacio de almacenamiento.
Prevenir borrados indeseados de datos.
Esto de la normalizacion esta Denso jejeje, la verdad ahora entiendo a lo que se refiere al decir que una base de datos normalizada es como alcanzar un estado Zen o llegar al Nirvana,
La normalización es el proces de organizar los datos para minimizar la duplicación. Generalmente implica dividir una base de datos en una o más tablas y definir relaciones entre ellas.
Uff un tema interesante el proceso de normalizacion, cuando me toco verlo por primera vez me costo mucho trabajo, ya que puedes llegar a saturarte con mucha teoria como algebra relacional, dependencias funcionales y esquemas relacionales, un super tema conceptualmente hablando, mi aporte seria mencionar que en mi poca pero grata experiencia en la mayoria de los casos, el proceso de normalizacion se da en modelos de bases de datos que ya estan hechos con una mala arquitectura o que no fueron normalizados correctamente, tambien en negocios que hacen su mejor intento por guardar su informacion de forma masiva pero que como tal estos registros no son una base de datos relacional, tambien me gustaria mencionar que es un proceso ciclico, cada tabla que rompemos para normalizarla, genera tablas nuevas que tambien deben normalizarse y cuando uno adquiere mas experiencia en la creacion de bases de datos mientras se diseña la base ya se aplican de forma intuitiva estos principios, recuerdo que en la escuela nos ponian a normalizar tablas sobre las que ya no habia nada mas que normalizar y era un gran dolor de cabeza tratar de identificar si tenia un buen trabajo o no, pero no tenia buenas bases, me gusto mucho el ejemplo todo muy bien explicado.
que gran profesor todo lo hace fácil de entender es muy profesional
HAY MAS DE 4 FORMAS NORMALES
4.1 Primera Forma Normal (1FN)
4.2 Segunda Forma Normal (2FN)
4.3 Tercera Forma Normal (3FN)
4.4 Forma normal de Boyce-Codd (FNBC)
4.5 Cuarta Forma Normal (4FN)
4.6 Quinta Forma Normal (5FN)
Cosa seria esto de la normalización…😃
😄😄😄😄😄😄😄😄😄😄😄😄😄😄😄
Una clase así, falto en la universidad
espero me entiendan, cualquier aporte o comentario bienvenido
12 reglas de Codd
Cero: El sistema debe calificar como relacional, como base de datos y como sistema de gestión
Uno: Información
Dos: Garantía
Tres: Nulos
Cuatro: Catálogo
Cinco: Sub-lenguaje
Seis: Updating
**Siete: **Alto nivel
Ocho: Independencia física
Nueve: Independencia lógica
Diez: Integridad
Once: Distribución
Doce: No sub-división
Tomado de: https://platzi.com/tutoriales/1566-bd/4120-las-12-1-leyes-de-codd/
Primera forma normal (1FN): Atributos atómicos (Sin campos repetidos)
Segunda forma normal (2FN): Cumple 1FN y cada campo de la tabla debe depender de una clave única.
Tercera forma normal (3FN): Cumple 1FN y 2FN y los campos que NO son clave, NO deben tener dependencias.
Cuarta forma normal (4FN): Cumple 1FN, 2FN, 3FN y los campos multivaluados se identifican por una clave única.
La normalización es poner una tabla de forma normal, sin datos duplicados ni uniones extrañas.
FN=Forma normal.
1FN= Elimina los datos duplicados. Una tabla no puede tener dos campos iguales. Así se elimina la redundancia de los datos.
2FN= Además de cumplir la anterior, se cumple que todos los datos de una tabla que no son clave principal solo dependen de una clave principal. Nunca habrá dos claves principales en una tabla.
3FN= Además de cumplir loas dos anteriores, se cumple que: solo los campos claves tienen dependencias. Una tabla no puede depender de otra por un campo que no sea clave.
4FN= Cumple todos los anteriores y además: los campos multi evaluados tienen una sola clave única.
Todos estos conceptos deben ser manejados no solo en concepto de bases de datos, sino también para los que manejan informes de Excel.
Es normal que en nuestros trabajos tengamos que presentar informes y que los datos que recolectamos lleguen de diferentes fuentes y en diferente orden.
Para ello, tener claro estos conceptos, nos hará mas fácil la vida al realizar informes cruzando información.
No todos en las organizaciones tienen siquiera alguna noción de esto, pero nosotros, los que no paramos de aprender, sabemos que podemos contribuir y minimizar el tiempo que lleva a cabo cruzar informes teniendo claro al menos la normalización de los datos.
Buen video!
Normalización:
Proceso para llegar a donde los datos estén de la mejor manera
1. Atributos atómicos: Sin repetir campos (materia_1, materia_2)
2. Cada campo de la tabla debe depender de una clave unica (id: 1, 1, 2, 2, 2, 3)
3. Los campos que no son clave, no deben tener dependencias (Materia con Data Engineering, Licenciatura con programacion)
4. Los campos multivaluados se identifican por una clave unica
No existen relaciones de dependencias de reunión (join) no triviales que no se generen desde las claves
Profe¡
Buenas tardes cuando hacemos la 2 segunda norma formal, si existen solo dos materias y creamos un campo materia_id, ¿porque la numeración de dicho campo llega a cuatro y no a dos? Si solo hay dos materias debería tener el limite de dos materias no de cuatro…
Un muy buen curso y un excelente maestro.El poder de lo simple.Transformar lo complejo en sencillo es una cualidad de un muy buen maestro.
Para ampliar el comcepto de normalización y la aplicación de las reglas les comparto una explicación del blog de Microsoft https://docs.microsoft.com/es-es/office/troubleshoot/access/database-normalization-description
Un tip muy bueno que me enseño mi profesor de bases de datos en la universidad es que cuando hay una relación en dos tablas de muchos a muchos por obligación se debe crear una tabla intermedia entre los dos (tabla hija), la cual lleva las primary key de las tablas padre, si nos damos cuenta en este ejemplo que nos da el profesor sucede así, entre las tablas estudiantes y materias hay una relación de muchos a muchos y de ahí se genera la tabla materias por alumno que hereda las primary key de su tabla padre. espero les sirva este aporte
Formas normales
1FN - Atributos atómicos
2FN - Cada campo debe depender de una clave única
3FN - Los campos que NO son clave No deben tener dependencias
4FN - Los campos multi valuados se identifican con una clave única
Con esto ya me queda claro que debo trabajar harto en mi proyecto de BD.
Resumen de la clase:
Primera Forma Normal (1FN).- Datos atómicos (sin campos repetidos)
Segundo Forma Normal (2FN).- Cumple con la 1FN y cada campo de la tabla debe depender de una sola clave única.
Tercer Forma Normal (3FN).- Cumple con la 1FN y 2FN y los campos que NO son clave NO deben tener dependencias.
Cuarta Forma Normal (4FN).- Cumple con el 1FN, 2FN y 3FN y los campos multivaluados se identifican por una clave única.
Hace muchos años vi esto en la universidad, hoy hago el curso para refrescar los conocimientos, muy buena explicación. Me hubiese gustado que mi profesor de U hubiese explicado así de conciso. Gracias!
a las 12 reglas de codd también se les conoce como los 12 mandamientos de codd, a futuro les servirá esto.
Buscando dudas, me encontré esta otra explicación por parte de la UNAM:
Normalización UNAM
Tipos de datos:
Todo diagrama tiene detallado cada uno de sus parámetros, y estos son tipos de datos que se dividen en secciones diferentes, las cuales son:
1. Tipos de datos de texto:
Char(n) Permite almacenar caracteres y cadenas de texto.
Este tipo de dato reserva un espacio de memoria del número de caracteres que va a ser ocupado.
Varchar(n) Al igual que char, este reserva espacio en la memoria. Su diferencia radica en que este reserva un mínimo espacio de memoria, y a partir de esta va creciendo o encogiéndose, es eficiente cuando desconocés cual será el tamaño de tu cadena de texto (Su limite es de 255 caracteres).
Text Su función es guardar cadenas de texto que sean muuuuuy grandes.
2. Tipos de datos numéricos:
Integer Número que no tiene punto decimal, se usa para declarar un tipo de dato entero que puede ser usado para hacer operaciones.?Al usar este tipo de dato nuestra base de datos sabrá que estamos hablando de número y no solo de un simple carácter.
Bigint Es un subtipo de integer, nos sirve para declarar números muy grandes.
Smallint Subtipo de integer, nos para declarar números muy pequeños (99 o menos).
Decimal (n, s)?Numeric (n, s) Tiene dos parámetros (n y s, en este ejemplo). La primera entrada es para números enteros, y la segunda entrada es para números decimales.?Nos sirve para hacer operaciones mas precisas.
3. Tipos de datos de fecha y hora:
Esta clase de tipos de datos es muy peculiar ya que nos ayuda internamente a tener una bitácora de nuestra base de datos.
Date Solo contiene la fecha (año, mes y día).
Time Solo contiene la hora.
Datetime Es una mezcla de los dos primeros, contiene fecha y hora.
Timestamp Es el número de segundos que ha transcurrido desde que tu archivo fue creado.?En otras palabras, podría decirse que es un medidor de tiempo.
4. Tipos de datos lógicos:
Boolean Este solo puede tener dos valores, funciona como un tipo de dato binario.?Es usado de manera discriminatoria para hacer validaciones.
Constraints (Restricciones):
Los contraints o restricciones son los tipos de reglas que vas a permitir que tenga tu base de datos.
Para ello usamos las siguientes:
Not null Se asegura que tu columna no tenga valores nulos.
Unique Asegura que cada valor en tu columna no se repita.
Primary Key Es una etiqueta muy importante, es una combinación entre not null y unique.?Nos permite hacer relaciones entre distintas entidades.
Foreign Key Llave foránea, es el otro lado de una primary key, cuando queremos juntar dos tablas y decir que estan relacionadas entre si, lo que va a suceder es la primary key de una de las tablas se añadirá como foreign key de la otra.
Check Algunas bases de datos removieron este tipo de contraints, pero las que lo conservan son muy potentes.?Tiene la función de permitir que añadamos las reglas que queramos a nuestra base de datos.
Index Se crea por columna, su función es hacer búsquedas con mayor rapidez.?Su única desventaja es que suele volverse lenta cada vez que se añaden nuevos registros.
Para mi parecer debería también crearse una nueva tabla “cursos_por_alumnos” para normalizar la tabla “alumnos” y sacarle el atributo “curso_id” lo cual la hace dependiente.
Me gustaría responder con una pregunta para isravazquezmorales 😄.
si separamos el nivel del curso de cursos quedando de la siguiente manera:
niveles_curso
nivel_id
nivel_curso
cursos
curso_id
nivel_curso_id
nombre_curso
para evitar redundancia al momento de agregar otro curso.
piensa en una situación donde agregas 5 o mas cursos :
IOT,
Big Data,
seguridad informatica,
inteligencia artificial,
machine learnig
todos dirían:
maestría IOT
maestría Big Data
maestría seguridad informática
maestría …
maestría …
La palabra maestría tiene 8 bytes.8x5=40bytes,
ahora piensa si esa entidad llega tener unos 200 registros y que esta siga creciendo.
En caso contrario si hacemos una entidad para niveles solo lo haríamos una vez cada cierto tiempo, y al momento de hacer la referencia del nivel solo tomar el id_nivel tomando un valor entero unos 4 bytes, reduciríamos a la mitad el tamaño de la entidad si registramos la misma cantidad de cursos;4x5=20bytes.
concluyendo reduciríamos el tamaño en la base de datos.
Espero alguien le feedback
Quiero hacer una aclaración cuando el prof Israel, hablaba de la segunda clave normal. El campo al cual se refería era un campo clave del cual dependía cada fila de la tabla. Parece una aclaración absurda pero estuve un largo rato, tratando de entender la tercera forma normal por ello. La parte que me confundí era a lo que se refería a dependencia, que era la que era relacionada al campo clave que se hablo en la anterior ocasión. Por ello el curso no es un atributo intrinseco al alumno, ya que incluso, ademas de que este curso puede ser llevados por varios alumnos, tambien hay la posibilidad que este no sea llevado por un alumno y este solo lleve una materia que depende de este curso.
Cuando estaba estudiando la carrera técnica, mi profesor me dio una recomendación al crear base de datos:
Identificar cada tabla con sus valores y solo pertenencientes a éste. Alumos (ID, Nombre, Apellidos, Dirección, Teléfono, etc)
Señalar cada tabla con un identificador (ID)
Al final, identificar qué tabla debe vincularse con cuál y agregar el ID al final.
Sé que no es una práctica muy recomendada y pero puede que ayude a los que tenemos dudas con la normalización. Saludos!
En bases de datos se les llama “campo” a las columnas y “registros” a las filas.
interesante lectura sobre algunos pros y cons de la normalización
https://morpheusdata.com/blog/2015-02-17-pros-cons-db-normalization
Estos son mis apuntes actuales. Super interesante saber como diferenciar las entidades entre sí dándoles un identificador a cada una.
Me dio la idea de que la normalizaion complejiza la base de datos para su lectura o busqueda, pero encontré esta lectura que me ayude a entender mejor el objetivo de la normalización. Se las dejo por si les sirve.
https://blog.saleslayer.com/es/por-que-es-importante-la-normalizacion-de-base-de-datos
Increíbles y Claros ejemplos, muy satisfecho con el profe.
Me parece importante precisar sobre los puntos de normalización:
Diagrama Fisica: Normalización_ (Reglas para separar la informacion)_
Primera forma normal (1FN)
Atributos atomicos (Sin campos repetidos)
Segunda forma normal (2FN)
Cumple 1Fn y cada campo de tabla debe depender de una clave unica.
Tercera formal normal (3FN)
Cumple 1FN y 2FN y los campos que no son claves NO deben tener dependencias.
Cuarta forma normal (4FN)
Cumple 1FN, 2FN Y 3FN los campors multievaluados se identifican por una clave unica.
Permite dar claridad a las entidades, atributos y flexibilidad de la base de datos evitando datos repetidos.
1FN Atributos atómicos
• Sin campos repetidos.
• No pueden haber dos atributos en la tabla similares, si es así mejor tener varios registros del mismo
2FN
• Cada campo debe depender de una clave única
• Ya debe estar en la 1FN
3FN
• Ya debe estar en la 2FN
• Los campos que NO son clave NO deben tener dependencias
4FN
• Ya debe estar en la 3FN
• Los campos multivaluados se identifican por una clave única
La normalización es la transformación de las vistas de usuario complejas y del almacén de datos a un juego de estructuras de datos más pequeñas y estables. Además de ser más simples y estables, las estructuras de datos son más fáciles de mantener que otras estructuras de datos.
Utilizando otras palabras:
1FN: Sin grupos de un mismo atributo.
2FN: 1FN y en cada fila de la tabla, los campos (atributos) deben depender funcionalmente (o contextualmente) de la clave primaria (PK).
Ej: nombre_curso depende solo de la materia (id_materia) y no del alumno_id, luego si éstos están en una misma tabla, ésta no está en 2FN.
3FN: 2FN y Ningún atributo “no determinante” depende transitivamente de la llave primaria
Normalización:
Lo que me gustó de esta clase es que se van descubriendo todo a medida que avanza y el final es genial “Esto hace que no tengas datos repetidos y llegues a Zen de la Base de Datos.”
A mi parecer en el esquema final, en la tabla de cursos nos quedó un campo multi-valuado (nivel_curso) por lo que este lo podríamos convertir en otra tabla llamada niveles que solo contenga id y nivel y el la tabla de cursos cambiar nivel_curso por nivel_curso_id y agregar el constraint de llave foránea.
Una duda que me queda, es cierto que con la normalizacion todo esta mas ordenado, pero tambien es cierto que al principio de la normalizacion teniamos una tabla pero al final teniamos 3. Esto no hace que nuestra bbdd vaya mas lenta? Si no es asi, porque?
Si alguien sabe del tema agradeceria la aclaracion o algun buen aporte para documentarme al respecto.
Una pregunta: supongamos que yo estoy guardando en una BD los resultados de un partido de futbol. En la tabla partidos pondria los siguientes campos:
ID
ID EQUIPO1
ID EQUIPO2
RESULTADO
ID GANADOR
Esto no estaria rompiendo la 1FN por repetir el campo ID Equipo? De ser asi, no encuentro una solucion que quede bien, alguien tiene alguna idea?
¿Porqué no dejar la clave primaria de la relacion materias_por_alumno como los atributos materia_id y alumno_id?
En este caso con la 4FN la entidad materias_por_alumno sería una entidad débil por existencia ya que no puede haber materias por alumno sin que exista la entidad materias.
Cuando empecé a diseñar modelos hace unos años tenía que normalizar bastante. Con la práctica luego empecé a hacer mis modelos ya normalizados sin ni siquiera darme cuenta
súper entendibles las clases
Esto me costó un poco mas de trabajo entenderlo, pero al final logré tenerlo más claro, hay que practicar mucho mas.
Hay que alcanzar el nirvana con bases de datos 😄
el profesor lo hace ver tan facil. no lo se rick parece falso
Estaría bien definir la normalización como el proceso de remover redundancia del diseño?
lo entendí un poco mejor que en la universidad xD
esta ilustrativa la clase, y muy bien explicado
De a poco va tomando forma este gran curso 😃
Siempre me había costado entender la normalización y la importancia de ella, pero ahora todo es mucho más claro. Gracias!
Esta es otra forma normal que es bastante conocida, Forma Normal de Boyce-Codd, os dejo la siguiente información:
https://es.wikipedia.org/wiki/Forma_normal_de_Boyce-Codd
https://guru99.es/database-normalization/#8
La tercera forma normal explicada en clases se adapta mas a la segunda, una campo no clave es aquel que no es la llave primaria, o que no define al dato de forma única, una campo no clave puede tener dependencia, por ejemplo, [valor_producto] : [iva_producto] el segundo campo depende del primero, por ende no se cumple la 3FN, para cumplirla hay que eliminar [iva_producto] para cumplir esta 3FN.
es normal que me pierda con este tema?
por que no separo tambien nivel_curso y nombre_curso? Asi como lo hizo con materias por alumno porque puede que una maestria / licenciatura tenga muchos cursos
La normalización es un proceso que aplicamos en nuestro modelo físico de base de datos para organizar los datos evitando redundancias y haciendo más eficiente nuestro modelo.
Existen las normas formales (FN) que nos ayudan a llevar a cabo este proceso:
• 1FN: La primera forma normal nos habla sobre atributos atómicos, esto quiere decir que no se pueden repetir los campos de una tabla, en este ejemplo podemos ver como esta una tabla sin aplicar la primera forma normal y se puede observar que hay dos campos repetidos (materia1 y materia2).
Al aplicar la primera forma normal eliminamos el campo repetido y los unificamos en un solo campo llamado materia.
• 2FN: La segunda forma normal nos indica que primero debe de cumplirse la primera forma normal y que cada campo de la tabla debe depender de nuestra clave única, en el ejemplo podemos ver que nuestra primary key se repite y eso no se puede permitir en una base de datos ya que no se puede identificar a cada registro, al aplicar la segunda forma normal nuestras tablas quedan de la siguiente manera
• 3FN: La tercera forma normal nos indica que se deben de cumplir 1FN y 2FN y que los campos que no son clave no deben de tener dependencia. Esto quiere decir que se deben de eliminar de una tabla las dependencias transitivas o sea los campos que no dependen de la clave primaria sino de otro atributo de nuestra tabla. Si existen atributos que no tienen relación con la clave primaria debemos de eliminarlos de la tabla y colocarlos en una tabla nueva y haciendo una relación entre estas dos tablas por medio de una llave foránea. En este ejemplo se separo el curso de la entidad alumnos ya que no depende de cada alumno, los cursos son independientes de cada alumno así que se considera una entidad aparte y se relaciona mediante la llave foránea curso_id en la tabla alumnos.
• 4FN: La cuarta forma normal nos indica se deben de cumplir 1FN, 2FN y 3FN y que los campos multivaluados se identifican por una clave única. Esto lo interpreto como que las relaciones de muchos a muchos deben de convertirse en una tabla intermedia entre las dos entidades en la que se almacenen todas las instancias de estos atributos multivaluados. Para que la cuarta forma normal se cumpla se deben de eliminar las relaciones de muchos a muchos (N:M)
La normalización de bases de datos es un proceso que consiste en designar y aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional con objeto de minimizar la redundancia de datos, facilitando su gestión posterior.
La normalizacion en base de datos se realiza con el fin de:
a) Evitar la redundancia de datos
b) Proteger la integridad de los datos
c) Evitar problemas de actualización de los datos en las tablas
La primera Forma Normal (1FN)
La segunda Forma Normal (2FN)
La tercera Forma Normal (3FN)
alumno | nivel_curso | nombre_curso | materia_1 | materia_2 |
---|---|---|---|---|
Juanito | Maestría | Data engineering | MySQL | Python |
Pepito | Licenciatura | Programación | MySQL | Python |
Atributos atómicos (Sin campos repetidos)
alumno_id | alumno | nivel_curso | nombre_curso | materia |
---|---|---|---|---|
1 | Juanito | Maestría | Data engineering | MySQL |
1 | Juanito | Maestría | Data engineering | Python |
2 | Pepito | Licenciatura | Programación | MySQL |
2 | Pepito | Licenciatura | Programación | Python |
Esto permite que la tabla no crezca de forma horizontal, sino que crece de forma vertical y deja un solo campo para materia.
Cumple 1FN y cada campo de la tabla debe depender de una clave única.
alumno_id | alumno | nivel_curso | nombre_curso |
---|---|---|---|
1 | Juanito | Maestría | Data engineering |
2 | Pepito | Licenciatura | Programación |
materia_id | alumno_id | materia |
---|---|---|
1 | 1 | MySQL |
2 | 1 | Python |
3 | 2 | MySQL |
4 | 2 | Python |
Cumple 1FN y 2FN y los campos que NO son clave NO deben tener dependencias.
alumno_id | alumno | curso_id |
---|---|---|
1 | Juanito | 1 |
2 | Pepito | 2 |
curso_id | nivel_curso | nombre_curso |
---|---|---|
1 | Maestría | Data engineering |
2 | Licenciatura | Programación |
materia_id | alumno_id | materia |
---|---|---|
1 | 1 | MySQL |
2 | 1 | Python |
3 | 2 | MySQL |
4 | 2 | Python |
Cumple 1FN, 2FN y 3FN los campos multivaluados se identifican por una clave única.
alumno_id | alumno | curso_id |
---|---|---|
1 | Juanito | 1 |
2 | Pepito | 2 |
curso_id | nivel_curso | nombre_curso |
---|---|---|
1 | Maestría | Data engineering |
2 | Licenciatura | Programación |
materia_id | materia |
---|---|
1 | MySQL |
2 | Python |
mpa_id | materia_id | alumno_id |
---|---|---|
1 | 1 | 1 |
2 | 2 | 1 |
3 | 1 | 2 |
4 | 2 | 2 |
Las bases de datos relacionales se normalizan para:
Evitar la redundancia de los datos.
Disminuir problemas de actualización de los datos en las tablas.
Proteger la integridad de los datos.
Facilitar el acceso e interpretación de los datos.
Reducir el tiempo y complejidad de revisión de las bases de datos.
Optimizar el espacio de almacenamiento.
Prevenir borrados indeseados de datos.
Requisitos de la normalización
Para que las tablas de nuestra BD estén normalizadas deben cumplir las siguientes reglas:
Cada tabla debe tener su nombre único.
No puede haber dos filas iguales.
No se permiten los duplicados.
Todos los datos en una columna deben ser del mismo tipo.
También se puede separar los alumnos de los cursos en una tabla independiente (alumnos_cursos) ya que es una relación de muchos a muchos, y sería mejor unir las materias por cursos que por alumnos.
La normalizacion es un conjunto de reglas que al aplicarlas evitamos que nuestra base de datos sea vulnerable a inconsistencias y anomalías, respetando la integridad de los datos.
like para el que entendió esto.
Presente 😅
Falto en el ejemplo la relación materia-curso que seria algo como n:n ya que una materia puede tener varios cursos y viceversa. Saludos!!
Explicación buenisima sobre la normalizacion y para saber como relacionar las entidades
Increíble, no entiendo como en la univ no pueden explicarlo de esta manera es tan sencillo excelente profesor…
Excelente explicación, cuando lo vì en la universidad lo veia muy complejo
En pocas palabras es organizar bien las entidades con sus atributos y relacionarlas solo con los id.
Me encanto.
Rayos, hasta que normalizo mi base datos me quedo calvo… Fuera de bromas, muy interesante esta clase. La normalización era un tema que había escuchado muchas veces, sin embargo, no tenía muy claro qué mismo era.
Lo que todos debemos aprender y ser exitosos
En resumen:
Acomodar las entidades con sus atributos por separado y establecer una tabla de relación entre estas entidades y sus atributos.
De un buen diseño normalizado de una base de datos, dependerá que tan eficiente sea su comportamiento a la hora de escalarla a grandes cantidades de datos.
Aquí es donde hago un stop y me devuelvo a repasar todo lo visto para continuar. ¡Excelente clase!
excelente explicación.
No entendí ni papa. Pero lo haré.
un tema muy complejo explicado de forma simple, bravo
Me parece excelente esta clase porque me permite afianzar los conocimientos y mejorar en la creación de las tablas de las bases de datos.
Que buen ejemplo para explicar la normalización
Creo que ahora si pude entender eso de la normalizacion de las bases de datos.
¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.