Database Systems Labs
Del enunciado ambiguo al esquema defendible: entidades, claves, dependencias funcionales y la decisión consciente de desnormalizar.
5 clases · 16 horas · 20 conceptos · 12 fuentes
Esta parte se apoya en lo trabajado antes. Si vienes de fuera del programa, revisa al menos el vocabulario de:
Aquí empieza el trabajo de diseño. El material de entrada es lo que suele haber en la realidad: un enunciado ambiguo escrito por alguien que no piensa en tablas. El material de salida es un esquema que se puede defender frente a preguntas, no solo dibujar.
Las cinco clases forman una secuencia que va de lo blando a lo formal y vuelve. Primero se extraen entidades, reglas de negocio y un alcance escrito de lo que el modelo decide no representar. Después el modelo entidad-relación fija cardinalidad y participación, que son las dos decisiones que determinan dónde va cada clave foránea y si admite nulos. La tercera clase resuelve el debate de las claves con un criterio y no con preferencias. La cuarta introduce el aparato formal —dependencias funcionales, formas normales, descomposición sin pérdida— que convierte «esto está mal modelado» en una demostración. Y la quinta cierra el círculo dando permiso para desnormalizar, pero solo con un patrón de lectura medido y el costo de escritura aceptado por escrito.
La tensión entre las clases 018 y 019 es intencionada y no se resuelve a favor de ninguna: normalizar es la posición por defecto, desnormalizar es una decisión que hay que ganarse con datos.
| # | Clase | Nivel | Horas | Fuentes |
|---|---|---|---|---|
| 015 | De requisitos ambiguos a entidades defendibles | Fundamentos | 3 | 3 |
| 016 | Entidad-relación, cardinalidad y participación | Fundamentos | 3 | 3 |
| 017 | Claves, identidad y el debate natural frente a sustituta | Fundamentos | 3 | 3 |
| 018 | Normalización de 1FN a BCFN con dependencias funcionales | Intermedio | 4 | 4 |
| 019 | Desnormalización deliberada y patrones de acceso | Intermedio | 3 | 3 |
El paso del enunciado ambiguo a un conjunto de entidades que se puede defender. Trabaja tres herramientas: las reglas de negocio que acabarán siendo restricciones, el diccionario de datos que impide que dos equipos llamen igual a cosas distintas, y el alcance escrito de lo que el modelo decide no representar.
regla de negocio diccionario de datos alcance patrón de acceso
El modelo entidad-relación de Chen con las dos decisiones que más consecuencias tienen: la cardinalidad, que determina dónde va la clave foránea, y la participación, que determina si esa columna admite nulos. Introduce la entidad débil y el atributo que pertenece a la relación y no a ninguna de las dos entidades.
entidad débil cardinalidad participación total atributo de relación
El debate entre clave natural y clave sustituta resuelto por un criterio y no por preferencia: cuál de las dos mantiene la identidad estable cuando el mundo cambia. La conclusión práctica —usar sustituta y proteger además la natural con `UNIQUE`— se aplica al resto del programa.
clave candidata clave primaria clave sustituta identidad estable
La normalización explicada como lo que es: una demostración a partir de dependencias funcionales, no una intuición sobre qué pertenece a qué. Recorre de la primera forma normal a la de Boyce-Codd y exige que cada descomposición sea sin pérdida, es decir, que reunir las tablas devuelva exactamente la original.
dependencia funcional anomalía de actualización BCFN descomposición sin pérdida
El contrapeso de la clase anterior: cuándo duplicar a propósito. Exige tres cosas antes de desnormalizar —un patrón de lectura medido, un mecanismo declarado que mantenga las copias al día y el costo de escritura aceptado por escrito—, y así separa la redundancia controlada de la accidental.
redundancia controlada costo de escritura agregado patrón de lectura
Cada uno de estos es una creencia habitual y su corrección.
Los 20 términos que esta parte introduce. Todos están también en el glosario del programa con sus términos relacionados.
| Término | Qué significa | Se trabaja en |
|---|---|---|
| agregado | Conjunto de datos que se trata como una unidad para leer, escribir y garantizar consistencia: un pedido con sus líneas. Sadalage y Fowler lo toman del diseño dirigido por el dominio y lo convierten en el criterio que separa a los motores NoSQL del relacional. (En la clase 027 la palabra se usa en su otro sentido: el resultado de una función de agregación como `SUM` o `COUNT`.) | 019 |
| alcance | Lo que el modelo decide representar y lo que decide ignorar. Kent lo formula sin rodeos: ningún modelo captura el mundo, siempre hay un recorte, y ese recorte es una decisión humana que conviene escribir en lugar de sufrir después. | 015 |
| anomalía de actualización | Consecuencia de guardar un hecho en varias filas: corregirlo exige tocarlas todas, y la que se olvida deja la base contradiciéndose a sí misma. Junto con las anomalías de inserción y borrado, es lo que la normalización elimina. | 018 |
| atributo de relación | Dato que no pertenece a ninguna de las dos entidades sino al hecho de que estén relacionadas: la fecha de inscripción no es del estudiante ni del curso, es de la inscripción. Es la señal de que la tabla intermedia es una entidad de pleno derecho. | 016 |
| BCFN | Forma normal de Boyce-Codd: toda dependencia funcional no trivial tiene como determinante una clave candidata. Es más estricta que la tercera forma normal y es el listón práctico de este programa para un esquema transaccional. | 018 |
| cardinalidad | Cuántas instancias de una entidad pueden relacionarse con cuántas de la otra: uno a uno, uno a muchos, muchos a muchos. Determina directamente dónde va la clave foránea y si hace falta una tabla intermedia. | 016 |
| clave candidata | Cualquier conjunto mínimo de atributos que identifica unívocamente una fila. Una tabla puede tener varias; elegir una como primaria no anula a las demás, que deben seguir protegidas con `UNIQUE`. | 017 |
| clave primaria | La clave candidata elegida para identificar cada fila: única, no nula y estable en el tiempo. Es la dirección por la que el resto del esquema se referirá a esa fila. | 017 |
| clave sustituta | Identificador inventado por el sistema y sin significado externo: entero autoincremental, UUID. No cambia nunca porque no depende del mundo, a costa de necesitar además una restricción `UNIQUE` sobre la clave natural real. | 017 |
| costo de escritura | Lo que se paga en cada `INSERT` o `UPDATE` por las copias, los índices y los agregados que hay que mantener coherentes. Toda aceleración de lectura por duplicación se cobra aquí; el diseño consiste en decidir de qué lado se quiere el dolor. | 019 |
| dependencia funcional | Relación `X → Y`: conocido el valor de X queda determinado el de Y. Es la herramienta formal con la que se demuestra que una tabla está mal descompuesta, y no una intuición sobre qué «pertenece» a qué. | 018 |
| descomposición sin pérdida | Partir una tabla en dos de modo que reunirlas devuelva exactamente la original, ni una fila más ni una menos. Se garantiza cuando el atributo común es clave en al menos una de las dos; sin esa condición la normalización inventa datos. | 018 |
| diccionario de datos | La lista de cada atributo con su significado exacto, su tipo, su unidad y su origen. Es lo que impide que «fecha» signifique alta para un equipo y último acceso para otro. | 015 |
| entidad débil | Entidad que no puede identificarse sin la entidad de la que depende: una línea de pedido existe solo dentro de su pedido. Su clave incluye la del padre, y su ciclo de vida termina cuando termina el del padre. | 016 |
| identidad estable | La propiedad de que el identificador de una fila no cambie mientras la fila represente la misma cosa. Es el criterio real del debate entre clave natural y sustituta: no cuál es más elegante, sino cuál sobrevive a los cambios del mundo. | 017 |
| participación total | Cuando toda instancia de una entidad debe participar obligatoriamente en la relación —todo pedido tiene un cliente—. Se traduce en `NOT NULL` sobre la clave foránea; la participación parcial admite el nulo. | 016 |
| patrón de acceso | La lista concreta de consultas y escrituras que el sistema tendrá que servir, con su frecuencia y su latencia aceptable. Es el dato de entrada del diseño: sin él, elegir modelo o índice es adivinar. | 015 |
| patrón de lectura | Qué se consulta, con qué filtros y con qué frecuencia. Es el argumento que justifica desnormalizar: sin una lectura dominante medida, duplicar datos es solo asumir el costo sin cobrar el beneficio. | 019 |
| redundancia controlada | Duplicar un dato a propósito, sabiendo dónde está la copia y quién la mantiene al día. Se distingue de la redundancia accidental en que existe un mecanismo declarado de sincronización y un costo de escritura aceptado. | 019 |
| regla de negocio | Una afirmación del dominio que el sistema debe respetar: «un estudiante no puede inscribirse dos veces en el mismo curso». Cada regla acaba en una restricción, en un índice único o en una prueba; la que no acaba en ninguna de las tres es solo una frase en un documento. | 015 |
12 obras distintas sostienen lo que se afirma en estas 5 clases.