Promp

Diseñando la BD
Para diseñar una base de datos se parte de la recolección de atributos o campos que va a tener, y de la definición de sus tipos de dato. La manera más profesional es realizando el análisis de requisitos con todas las personas que van a hacer uso de los datos. Pero por experiencia ya sabéis que esto se hace muy a ojo: os piden realizar una aplicación y según los requisitos de laaplicación hacéis el diseño de la BD.
El primer método está más estandarizado, y suele ser más lento pero a cambio es improbable que el diseño salga mal. El segundo es más rápido porque directamente se piensa en las tablas y sus datos sobre la marcha. Se utiliza principalmente en la metodología de programación conocida como “programación extrema” y en las demás de la familia “desarrollo ágil desoftware”; y es más propenso a fallos de diseño, proporcionalmente inversos al tiempo que se dedique a su definición y valoración (más tiempo, menos probabilidad de fallos).
Normalizando la BD
La normalización es un método de análisis de BD para conseguir una BD relacional, que respete la integridad referencial, y que no tenga redundancia de datos. Se divide en formas normales, y aunque hay unmontón y es toda una ciencia, explicaré por encima las 3 primeras ya que el nivel 3 es suficiente para la mayoría de casos.
Hay que destacar que la normalización se puede hacer a nivel completo de la BD, o a nivel de tablas o esquemas. La técnica es la misma: analizar el conjunto de campos y en base a eso designar una clave inicial que identifique a un grupo de datos. Por ejemplo si estamosnormalizando todo un esquema de facturación podemos partir de los datos del cliente añadiendo la clave del cliente, y según vayamos normalizando nos saldrán todas las tablas y les iremos dando claves primarias nuevas. Si lo que normalizamos es una tabla, el procedimiento es el mismo y ya irán saliendo otras tablas subordinadas si acaso.








Las reglas de Codd
Además de la normalización hayunas reglas, las reglas de Codd, que ayudan a diseñar una BD relacional perfecta (desde el punto de vista de Codd, claro) que merece la pena estudiarlas pues son casi de lógica común y nos harán la vida más fácil en todos los sentidos. La idea de estas reglas surgió porque la normalización no era suficiente para que una BD fuera relacional, consistente e independiente.
Hay ocasiones en las quelos diseñadores de las BD confeccionan la BD para satisfacer necesidades lógicas y funcionales de una aplicación, por ejemplo almacenando los datos en un formato que luego la aplicación se encarga de transformar. Esto es bastante típico cuando el diseñador es el programador de la aplicación, y lo hace por comodidad o falta de conocimiento.
La moraleja es que una BD debe ser independiente de laaplicación, y si lo pensáis bien es mejor así. Según las reglas de Codd la BD tiene que ser completamente operativa desde su lenguaje de consultas (típicamente SQL), y las restricciones en los datos deben ser propiedad de la BD (no vale controlar la entrada desde la aplicación). Con esto conseguiremos que mediante el SQL no se puedan realizar operaciones que hagan que la aplicación no funcione(introduciendo datos en un formato inesperado para la aplicación, por ejemplo), y entre otras cosas, que si tenemos que realizar informes puntuales o sacar listados los podremos hacer desde un simple cliente y sin tener que parsear nada ni realizar consultas sobre consultas.











Normalizando la BD: primera forma normal (1FN)
Se podría decir que al aplicarla hay que asegurarse de que:No se permiten vectores de campos en una columnaUn ejemplo de esto es cuando en un campo de texto metemos varios valores del mismo dominio,
como por ejemplo tres números de teléfono, o dos direcciones e-mail. Lo típico en estos casos
es separar los datos por comas, espacios u otro carácter y depués procesarlo mediante la aplicación.
Para evitar esto hay que definir una nueva tabla que tendrá...