Bienvenida conceptos básicos y contexto histórico de las Bases de Datos

1

Bienvenida conceptos básicos y contexto histórico de las Bases de Datos

Introducción a las bases de datos relacionales

2

Historia de las bases de datos relacionales

3

Entidades y atributos

4

Entidades de Platzi Blog

5

Relaciones

6

Múltiples muchos

7

Diagrama ER

8

Diagrama Físico: tipos de datos y constraints

9

Diagrama Físico: normalización

10

Formas normales en Bases de Datos relacionales

11

Diagrama Físico: normalizando Platziblog

RDBMS (MySQL) o cómo hacer lo anterior de manera práctica

12

¿Qué es RDB y RDBMS?

13

Instalación local de un RDBMS (Windows)

14

Instalación local de un RDBMS (Mac)

15

Instalación local de un RDBMS (Ubuntu)

16

Clientes gráficos

17

Servicios administrados

SQL hasta en la sopa

18

Historia de SQL

19

DDL create

20

CREATE VIEW y DDL ALTER

21

DDL drop

22

DML

23

¿Qué tan standard es SQL?

24

Creando Platziblog: tablas independientes

25

Creando Platziblog: tablas dependientes

26

Creando Platziblog: tablas transitivas

Consultas a una base de datos

27

¿Por qué las consultas son tan importantes?

28

Estructura básica de un Query

29

SELECT

30

FROM

31

Utilizando la sentencia FROM

32

WHERE

33

Utilizando la sentencia WHERE nulo y no nulo

34

GROUP BY

35

ORDER BY y HAVING

36

El interminable agujero de conejo (Nested queries)

37

¿Cómo convertir una pregunta en un query SQL?

38

Preguntándole a la base de datos

39

Consultando PlatziBlog

Introducción a la bases de datos NO relacionales

40

¿Qué son y cuáles son los tipos de bases de datos no relacionales?

41

Servicios administrados y jerarquía de datos

Manejo de modelos de datos en bases de datos no relacionales

42

Top level collection con Firebase

43

Creando y borrando documentos en Firestore

44

Colecciones vs subcolecciones

45

Recreando Platziblog

46

Construyendo Platziblog en Firestore

47

Proyecto final: transformando tu proyecto en una db no relacional

Bases de datos en la vida real

48

Bases de datos en la vida real

49

Big Data

50

Data warehouse

51

Data mining

52

ETL

53

Business intelligence

54

Machine Learning

55

Data Science

56

¿Por qué aprender bases de datos hoy?

Bonus

57

Bases de datos relacionales vs no relacionales

58

Elegir una base de datos

Diagrama Físico: normalización

9/58
Recursos

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:

  • 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.

Aportes 391

Preguntas 96

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.

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:

  • La redundancia de los datos: repetición de datos en un sistema.
  • Anomalías de actualización: Inconsistencias de los datos como resultado de datos redundantes y actualizaciones parciales.
  • Anomalías de borrado: Pérdidas no intencionadas de datos debido a que se han borrado otros datos.
  • Anomalías de inserción: Imposibilidad de adicionar datos en la base de datos debido a la ausencia de otros datos.

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).

Normalización


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,

  • Pregunta: Es posible saber si una base de datos esta normalizada o es algo que solo sabe el que la creo

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:

  1. No podemos tener columnas que tengan datos repetidos. Para este caso la primera tabla tenía las columnas materia 1 y materia 2, que contienen el mismo tipo de datos, esto se puede consolidar en una sola columna.
  2. Podemos entender que la tabla resultante del punto anterior se entiende como una unión de tablas independientes. Esta tabla se puede generar de la intersección de dos tablas, “Alumnos” y “Materias” debido a que uno no es dependiente de la otra.
  3. Se separan los cursos de los alumnos, ya que los cursos no tienen una dependencia de los alumnos, los cursos pueden tener más de un alumno, así que un curso no es un atributo del alumno
  4. El atributo materia es un campo multivariado, así que esta debe tener una clave específica, esto ayuda a separar la información y a partir de esta generar nueva, en caso de que, por ejemplo, se requiriera saber las materias por cursos.

Descripción grafica de como quedé al ver como se debe normalizar

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:

  • 1ra Forma Normal : Sin campos duplicados
  • 2da Forma Normal : 1FN + Registros Únicos
  • 3ra Forma Normal : 1FN + 2FN + Entidades no relacionadas deben separarse si conceptualmente son diferentes.
  • 4ta Forma Normal : 1FN + 2FN + 3FN + Campos con múltiples valores deben separarse en una nueva tabla con clave.

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.”

Aporte

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

por qué los ID de los cursos que se llaman igual tienen diferente ID? no debieran ser los mismos?

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)

  • Eliminar los grupos repetitivos de la tablas individuales
  • Crear una tabla separada por cada grupo de datos relacionados
  • Identificar cada grupo de datos relacionados con una clave primaria

La segunda Forma Normal (2FN)

  • Crear tablas separadas para aquellos grupos de datos que se aplican a varios registros
  • Relacionar estas tablas mediante una clave externa

La tercera Forma Normal (3FN)

  • Eliminar aquellos campos que no dependan de la clave
  • Ninguna columna puede depender de una columna que no tenga una clave
  • No puede haber datos derivados

Diagrama Físico: normalización

¿Qué es normalizar?

alumno nivel_curso nombre_curso materia_1 materia_2
Juanito Maestría Data engineering MySQL Python
Pepito Licenciatura Programación MySQL Python

Primera forma normal (1FN)

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.

Segunda forma normal (2FN)

Cumple 1FN y cada campo de la tabla debe depender de una clave única.

Alumnos

alumno_id alumno nivel_curso nombre_curso
1 Juanito Maestría Data engineering
2 Pepito Licenciatura Programación

Materias

materia_id alumno_id materia
1 1 MySQL
2 1 Python
3 2 MySQL
4 2 Python

Tercera forma normal (3FN)

Cumple 1FN y 2FN y los campos que NO son clave NO deben tener dependencias.

Alumnos

alumno_id alumno curso_id
1 Juanito 1
2 Pepito 2

Cursos

curso_id nivel_curso nombre_curso
1 Maestría Data engineering
2 Licenciatura Programación

Materias

materia_id alumno_id materia
1 1 MySQL
2 1 Python
3 2 MySQL
4 2 Python

Cuarta forma normal (4FN)

Cumple 1FN, 2FN y 3FN los campos multivaluados se identifican por una clave única.

Alumnos

alumno_id alumno curso_id
1 Juanito 1
2 Pepito 2

Cursos

curso_id nivel_curso nombre_curso
1 Maestría Data engineering
2 Licenciatura Programación

Materias

materia_id materia
1 MySQL
2 Python

Materias por alumno

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.