Analizar y reconocer las estrategias de la migracin del modelo lgico al fsico. Aplicar las formas normales como medios de refinamiento del modelo. Establecer un criterio para discernir cundo normalizar o desnormalizar, de acuerdo con la evaluacin de tiempo de acceso y recursos computacionales empleados.
Temas:
1. El Modelo Fsico Relacional. 2. Generando el Modelo Fsico. 3. Normalizacin de Datos.
Del Modelo Fsico Relacional de Base de Datos 54
1. El Modelo Fsico Relacional
1.1 Definicin
El enfoque relacional es uno de los modelos matemticos ms importantes y actuales para la representacin de las bases de datos. Se basa en la teora matemtica de las relaciones, suministrndose por ello, una fundamentacin terica que permite aplicar todos los resultados de dicha teora a problemas, tales como, el diseo de sub lenguajes de datos y otros.
El trmino relacin se puede definir matemticamente, como sigue:
Relacin: Dados los conjuntos D1, D2, ..., Dn (no necesariamente distintos), R es una relacin sobre esos n conjuntos, si est constituida por un conjunto de n-tuplos ordenados d1,d2,...dn tales que, d1 D1, d2 D2, ..., dn Dn.
Los conjuntos D1, D2, ..., Dn se llaman dominios de R y n constituye el grado de la relacin. La cantidad de tuplas constituye la cardinalidad.
Es conveniente representar una relacin como una tabla bidimensional donde cada fila representa un n-tuplo.
. . . COLUMNAS (atributos) FILAS (ocurrencias) . . . . . . Del Modelo Fsico Relacional de Base de Datos 55
Cada relacin est compuesta de filas (las ocurrencias de los objetos) y se les denomina, como tuplos, tuplas, uplos o uplas (en realidad, n-tuplos, pero en muchos casos se suprime la n cuando no existe posibilidad de confusin).
Tambin la relacin est compuesta por columnas (los atributos o campos que toman valores en sus respectivos dominios).
No obstante, es importante considerar lo siguiente.
1. No hay dos filas (tuplas) iguales. 2. El orden de las filas no es significativo (1 y 2 se deben a que la relacin es un conjunto). El orden de las columnas s es significativo, pues representa el orden de los dominios implicados; siempre se hace referencia a una columna por su nombre y nunca por su posicin relativa. 3. El orden de las columnas no es significativo. 4. Cada valor dentro de la relacin (cada valor de un atributo) es un dato atmico (o elemental), es decir, no descomponible; por ejemplo: un nmero, una cadena de caracteres. En otras palabras, en cada posicin fila o columna existe un solo valor, nunca un conjunto de valores.
Una relacin que satisface este ltimo punto se denomina normalizada. La teora de la normalizacin se basa en la necesidad de encontrar una representacin del conjunto de relaciones, que en el proceso de actualizacin sea ms adecuada. Existen diferentes niveles de normalizacin, llamadas formas normales.
Ejemplo:
El ejemplo de suministrador y producto puede ser representado fcil y claramente, mediante el modelo relacional.
Los atributos de estas dos entidades son:
Suministrador: nmero que lo identifica, nombre, tipo y distrito donde radica. Producto: nmero que lo identifica, nombre, precio unitario y peso.
Adems, un suministrador puede suministrar muchos productos, mientras que un producto puede ser suministrado por varios suministradores. Adems, se conoce la cantidad de un determinado producto que suministra un suministrador dado.
Aclaracin del autor: En el modelo relacional, tanto los objetos o entidades como las relaciones que se establecen entre ellos, se representan a travs de tablas, que en la terminologa relacional se denominan relaciones.
Del Modelo Fsico Relacional de Base de Datos 56
La representacin en el modelo relacional es ms simple que con el modelo jerrquico y el modelo reticular, ya que con 3 tablas se tiene todo el modelo representado.
En el modelo relacional el resultado de una demanda es tambin una relacin y las demandas simtricas (en el sentido de ser una la inversa de la otra; por ejemplo, recuperar los nmeros de los suministradores que suministran el producto P4 y recuperar los nmeros de los productos que suministra el suministrador S2) requieren operaciones simtricas.
Asimismo, las diversas formas de expresar las recuperaciones, dan lugar a los lenguajes relacionales cuyas formas ms representativas son:
lgebra relacional (basado en las operaciones del lgebra de relaciones) Clculo relacional (basado en el clculo de predicados)
1.2 Ventajas del modelo relacional
Simplicidad, pues el usuario formula sus demandas en trminos del contenido informativo de la BD, sin tener que atender a las complejidades de la realizacin del sistema, lo que implica gran independencia de los datos.
La informacin se maneja en forma de tablas, lo que constituye una manera familiar de representarla.
Al igual que en el modelo reticular, si se tienen relaciones normalizadas no surgen grandes dificultades en la actualizacin.
0.10 0.15 3.50 0.20 2.00 4.00 12 17 80 10 50 90 PRODUCTO SNUM SNOM TIPO DIST S1 S2 S3 S4 S5 PREZ RAMOS ARENAS VALLE LPEZ 30 10 20 20 15 SAN ISIDRO SURCO SAN ISIDRO LINCE LINCE SUMINISTRADOR Del Modelo Fsico Relacional de Base de Datos 57
En el modelo del Suministrador-Producto, presentado anteriormente, un ejemplo de cada tipo de operacin de actualizacin, sera de la siguiente manera.
Creacin: aadir un producto P7. Se agrega la nueva ocurrencia en la tabla Producto. Es posible hacerlo aunque ningn suministrador lo suministre.
Supresin: se puede eliminar el suministrador S1 sin perder el producto P6, a pesar de que es el nico que lo suministra.
Modificacin: se puede cambiar el precio del producto P2 sin necesidad de bsquedas adicionales ni posibilidad de inconsistencias.
No obstante, el proceso de normalizacin no es suficiente.
1.3 Aspectos del modelo relacional
El Modelo Relacional est orientado hacia 3 aspectos sustanciales de los datos:
1.3.1. Estructura de datos relacional
Bajo el enfoque de la estructura, el Modelo Relacional permite analizar las relaciones, as como, determinar los componentes que conforman cada una de ellas. Estos componentes son:
Relaciones: Generalmente se denomina Tabla (aunque existe una diferencia para el modelo relacional entre Tabla y Relacin). Cada tabla es una entidad diferente. Las tablas almacenadas en la base de datos se denominan Tablas Bases. Las que se crean a partir de ellas, se denominan Tablas Virtuales (Memoria). Cada relacin posee un nombre que est asociado con los datos que almacena. Cada relacin est formada a su vez, por Atributos y Tuplas.
Atributos: Es un elemento de datos que describe a la entidad representada por medio de la tabla, que en su implementacin, conforma lo que sera una columna (campo) de dicha tabla. Cada atributo posee un nombre que, normalmente, sugiere el tipo de datos que se almacenar en dicho atributo.
Tuplas: Se denomina as a cada fila de la relacin (tabla). Cada tupla refleja una ocurrencia de la relacin. Aclaracin del autor: Se dice que una de las desventajas del modelo relacional consiste en la dificultad de lograr productividad adecuada de los sistemas, ya que no se emplean los medios tcnicos idneos, (tales como las memorias asociativas), siendo necesario simular este proceso, pero en realidad, la eficiencia y productividad de los sistemas actuales resultan realmente muy satisfactorias.
Ejemplos de SGBD relacionales: Query By Example (QBE)(IBM) MS Access, Informix, Oracle, SQL Server, My SQL
Del Modelo Fsico Relacional de Base de Datos 58
Dominio: Es el conjunto de valores permitidos para un Atributo, validado por reglas convencionales o del negocio. Su implementacin en una base de datos, libera a la misma de los famosos errores de los usuarios.
Existen los dominios simples, como por ejemplo:
- Sexo, cuyos valores pueden ser Masculino o Femenino. - Estado Civil, cuyos valores pueden ser Soltero, Casado, Divorciado o Viudo. - Tipo de Empleado, cuyos valores pueden ser Estable o Contratado. - Notas (evaluaciones) cuyos valores van desde 0 hasta 20.
De igual manera, existen los dominios compuestos, como por ejemplo:
- Fecha De Ingreso, compuesto por los dominios: Da, cuyos valores van desde 1 hasta 31. Mes, cuyos valores van desde 1 hasta 12. Ao, cuyos valores van desde 0 hasta 9999 (dependiendo del negocio).
Propiedades de las Relaciones: No existen tuplas repetidas. Las tuplas y los atributos no estn ordenados, todos los atributos tienen valores atmicos.
1.3.2. Integridad de los datos
Permite indicar ciertas restricciones propias del mundo real a la base de datos. Por ejemplo, no permitir dentro de una Tabla de Artculos, tuplas cuyo atributo Cdigo sea Nulo.
El modelo Relacional incluye 2 reglas generales, aplicables para todas las bases de datos bajo este modelo. Estas 2 reglas estn asociadas a los conceptos de Llaves Primarias y Llaves Forneas.
Llave primaria (primary key - PK)
Es una columna o grupo de columnas que identifican de manera nica a cada rengln (fila) de la Tabla. Como es un identificador nico, no se aceptan duplicados en la llave primaria. El valor de la llave primaria, generalmente, no se puede cambiar. Las llaves primarias que constan de ms de una columna se llaman Llaves Compuestas.
Llaves alternas o Candidatas
Una tabla puede tener ms de una columna o combinacin de columnas que pueden servir como la llave primaria de la tabla. Por ejemplo, en una tabla de clientes se pueden establecer como llaves candidatas al cdigo del cliente y al RUC. Tambin, dentro de una tabla de empleados, se podra elegir la llave primaria entre el cdigo del Empleado o su DNI. Del Modelo Fsico Relacional de Base de Datos 59
En resumen, las llaves candidatas deben cumplir 2 caractersticas:
Unicidad: garantiza que en cualquier momento no existirn 2 tuplas con la misma Llave Primaria. Minimalidad: garantiza que si la llave es compuesta, no se eliminar ninguno de sus componentes sin romper la propiedad de Unicidad.
Las Llaves Primarias son importantes, ya que el nico modo que garantiza el Modelo Relacional para acceder a una tupla especfica es por medio del valor de su llave primaria. Adems, permitirn el manejo de las Llaves Forneas.
Llaves forneas (foreign key)
Es una columna o combinacin de columnas, dentro de una tabla que se refieren a una Llave Primaria de otra tabla. La relacin (tabla) que contiene la llave fornea se le conoce como Relacin Referencial y a la que contiene la llave primaria, como Relacin Objetivo.
La llave fornea no necesariamente puede formar parte de la llave primaria de una relacin. En la relacin Empleados la llave fornea Cargo no es parte de la llave primaria. Sin embargo, en las relaciones producto de entidades asociativas, la llave primaria est compuesta por las llaves forneas provenientes de las Llaves Primarias de las Entidades que se asocian. Las llaves forneas sirven para hacer "JOIN" (UNION) de tablas y pueden ser repetidas o nulas.
Las megarreglas o constraints de integridad de datos
Las dos MEGARREGLAS ms importantes son:
Los Constraints de Integridad de Entidades. Los Constraints de Integridad Referencial.
Por medio del constraint de integridad de entidades se asegura que la llave primaria no puede ser NULA ni REPETIDA. Esto es lgico, ya que las tablas almacenan informacin proveniente del mundo real, del cual siempre existirn objetos distinguibles. Por medio del constraint de integridad referencial, una llave fornea debe coincidir con un valor de la llave primaria, es decir, el valor de la llave fornea debe ser concordante con algn valor de la llave primaria relacionada.
Existen 3 formas de asegurar la Integridad Referencial, en caso de sufrir alguna variacin el valor de la llave primaria de donde proviene la respectiva llave fornea:
- Restringida. - De cascada. - Anulacin.
1.2.3. Operaciones con datos
Adicionar registros. Actualizar registros. Eliminar registros. - Lgicamente. - Fsicamente. Consultar registros. Del Modelo Fsico Relacional de Base de Datos 60
2. Generando el Modelo Fsico
A continuacin, se indicar como construir los modelos fsicos, a partir de un modelo lgico elaborado con ERwin.
PASO A: Definiendo el Modelo Fsico
1. En el control Toggle Logical-Physical de la Barra de herramientas, seleccionar Physical. En el Men Format, seleccionar Table Display y luego, Column Datatype.
Modelo Fsico Del Modelo Fsico Relacional de Base de Datos 61
2. El modelo fsico, por defecto, utiliza el nombre de la entidad como nombre de la tabla y adems, las columnas han sido definidas con tipos predeterminados.
PASO B: Seleccin del Software de Bases de Datos en que se generar la nueva Base de Datos
1. En el men Database, ejecutar la opcin Choose Database.
2. En el dilogo Target Server seleccionar el software de bases de datos a emplear. De ser necesario, seleccionar tambin la versin. Para este ejemplo, seleccionar SQL Server.
3. En el control Default Non-Key Null Option especificar si los atributos no claves permitirn o no, valores nulos como valores predeterminados.
4. Hacer clic en el botn OK.
PSO C: Redefinicin de los Tipos de Datos para el Modelo Fsico
1. Dar clic sobre la entidad con el botn secundario del ratn.
2. Seguidamente, en el men contextual seleccionar Columns.
3. En el dilogo Columns debe aparecer una pestaa SQL Server al costado de la pestaa General. Seleccionar la pestaa SQL Server.
Del Modelo Fsico Relacional de Base de Datos 62
4. Utilizando la pestaa SQL Server redefinir los tipos de datos de cada atributo de la entidad, especificando el tamao del mismo.
5. Al finalizar, hacer clic en OK.
PASO D: Generacin de los Objetos de la Base de Datos
En este punto, con la ayuda del SQL Server Managment Studio, crear una base de datos llamada VENTA, para el ejemplo.
Del Modelo Fsico Relacional de Base de Datos 63
PASO E: Conexin de ERwin con SQL Server
1. Regresar al modelo fsico en ERwin; luego del men Database, ejecutar la opcin Database Connection.
2. En Authenticacion, elegir Database Authentication.
3. En User Name y Password proporcionar la identificacin y la contrasea de una cuenta SQL Server vlida. Para este caso, digitar sa en User Name y sa como Password. (Asegurarse que el servidor de base de datos tenga autenticacin Sql Server and Windows Authentication, habilitado el login sa y el password del login sea sa)
4. En Server Name digitar el nombre del servidor SQL.
5. Asimismo, en Database escribir el nombre de la base de datos a la que se desea conectar (VENTA).
6. Hacer clic en el botn Connect. Si no se recibe ningn mensaje, la conexin se ha establecido.
PASO E: Creacin de los Objetos de la Base de Datos
Para crear los objetos de la base de datos, ERwin crea un procedimiento que contiene todas las sentencias SQL que deben ejecutarse para crear los objetos definidos en el modelo Fsico. Por ello, se puede:
Utilizar la conexin establecida para crear en este momento los objetos de la base de datos. Generar un archivo script (programa) que guarde el procedimiento que crea los objetos de la base de datos y ejecutar posteriormente, el procedimiento desde el cliente SQL Server.
Conectar Del Modelo Fsico Relacional de Base de Datos 64
Para revisar el procedimiento que crea los objetos de la base de datos
1. En el men Tools, ejecutar Forward Engineer / Schema Generation.
2. En el dilogo SQL Server 2008/2012 Schema Generation, hacer clic en el botn Preview. Se podrn ver todas las instrucciones que se ejecutarn para crear los objetos definidos en el modelo fsico.
3. Hacer clic en el botn Close, al finalizar la revisin.
Hacer clic aqu. Del Modelo Fsico Relacional de Base de Datos 65
Para crear un script SQL que puede ser editado y ejecutado, posteriormente
1. En el dilogo SQL Server 2008/2012 Schema Generation, dar clic en el botn Report.
2. En el dilogo Generate SQL Server/SQL Schema Report, especificar la ubicacin y el nombre del archivo que almacenar el script (guardarlo con extensin sql). Por ejemplo, ObjetosVentas.sql.
3. Dar clic en el botn Guardar y luego, en OK.
Para generar los objetos de la base de datos desde ERwin
Antes de proceder a generar los objetos de la base de datos, revisar el esquema de generacin para seleccionar las sentencias SQL a ejecutar.
1. En la lista SQL Server Schema Generation de la ficha Options, seleccionar Schema. Luego, en la lista Schema Options a la derecha quitar la marca check a todas las opciones que las tengan.
2. Ahora de la lista de la izquierda, seleccionar View y quitar la marca a las opciones seleccionadas y continuar as, con las dems opciones.
3. Las nicas opciones que debern seleccionarse sern las siguientes:
Del Modelo Fsico Relacional de Base de Datos 66
4. Hacer clic en el botn Preview. Se podr notar que algunas sentencias SQL han sido eliminadas del procedimiento original.
5. Para generar los objetos de la base de datos utilizando la conexin establecida, hacer clic en el botn Generate.
6. La ventana siguiente mostrar un reporte con el resultado de la generacin. En este caso, todas las sentencias se ejecutaron sin problemas. Luego, dar clic en OK.
Del Modelo Fsico Relacional de Base de Datos 67
Revisin del servidor SQL para comprobar la creacin de los objetos
1. Ingresar al SQL Management Studio; en Authentication, utilizar SQL Server Authentication, Luego, utilizar sa para Login y Password.
2. Hacer clic sobre la base de datos Venta utilizando el botn secundario del ratn.
3. Del men contextual, ejecutar la opcin Refresh.
4. Expandir Venta y hacer doble clic sobre Tables.
Del Modelo Fsico Relacional de Base de Datos 68
3. Normalizacin de datos
3.1. Definicin
La normalizacin es la expresin formal del modo de realizar un buen diseo, pues provee los medios necesarios para describir la estructura lgica de los datos en un sistema de informacin. La teora de la normalizacin se ha desarrollado para obtener estructuras de datos eficientes que eviten las anomalas de actualizacin.
El concepto de normalizacin fue introducido por E.D. Codd y fue pensado para aplicarse a sistemas relacionales; sin embargo, tiene aplicaciones ms amplias.
3.2. Ventajas de la normalizacin
Evita anomalas en la actualizacin. Mejora la independencia de los datos permitiendo realizar extensiones de la BD, afectando muy poco o nada, a los programas de aplicacin existentes que acceden la base de datos.
3.3. Las Formas Normales
La normalizacin involucra varias fases que se realizan en orden. La realizacin de la 2da. fase supone que se ha concluido la 1ra. y as sucesivamente. Del Modelo Fsico Relacional de Base de Datos 69
Tras completar cada fase, se dice que la relacin est en:
Primera Forma Normal (1FN) Segunda Forma Normal (2FN) Tercera Forma Normal (3FN) Forma Normal de Boyce-Codd (FNBC)
Existen, adems, la Cuarta (4FN) y la Quinta (5FN) Formas Normales.
Primera Forma Normal (1FN): establece que las columnas repetidas deben eliminarse y colocarse en tablas separadas. Las celdas de la tabla deben poseer valores simples y no se permiten grupos ni arreglos repetidos como valores. Todos los ingresos en cualquier columna (atributo) deben ser del mismo tipo. Asimismo, cada columna debe tener un nombre nico, el orden de las columnas en la tabla no es importante. Dos hileras en una tabla no deben ser idnticas, aunque el orden de las hileras no es importante.
Segunda Forma Normal (2FN): para que una tabla est en 2NF tiene que cumplir con lo siguiente:
Estar en 1FN. Todas las dependencias parciales se deben eliminar y separar dentro de sus propias tablas. (Una dependencia parcial es un trmino que describe a aquellos datos que no dependen de la llave primaria de la tabla para identificarlos). La 2FN slo se aplica para llaves compuestas.
La Tercera Forma Normal (3FN): seala que hay que eliminar y separar cualquier dato que no sea clave. El valor de esta columna debe depender de la llave. Todos los valores deben identificarse nicamente por la llave. Del mismo modo, elimina cualquier dependencia transitiva (aquella en la cual, las columnas que no son llave son dependientes de otras columnas que tampoco lo son).
Ejemplo de Aplicacin:
A travs de este ejercicio se intenta afirmar los conocimientos de normalizacin, con un ejemplo simplificado de una base de datos para una pequea biblioteca.
CodLibro Titulo Autor Editorial NombreLector FechaDev 1001 Variable compleja Murray Spiegel McGraw Hill Prez Gmez, Juan 15/04/2005 1004 Visual Basic 2005 E. Petroustsos Anaya Ros Tern, Ana 17/04/2005 1005 Estadstica Murray Spiegel McGraw Hill Roca, Ren 16/04/2005 1006 Oracle University Autor1: Nancy Greenberg Autor 2: Priya Nathan Oracle Corp. Garca Roque, Luis 20/04/2005 1007 Power Builder 10.0 Ramalho McGraw Hill Prez Gmez, Juan 18/04/2005 Del Modelo Fsico Relacional de Base de Datos 70
Esta tabla no cumple el requisito de la Primera Forma Normal (1NF) de slo tener campos atmicos, pues el nombre del lector es un campo que puede (y conviene) descomponerse en apellido paterno, apellido materno y nombres. Tal como se muestra en la siguiente tabla.
1NF
CodLibro Ttulo Autor Editorial Paterno Materno Nombres FechaDev 1001 Variable compleja Murray Spiegel McGraw Hill Prez Gmez Juan 15/04/2005 1004 Visual Basic 2005 E. Petroustsos Anaya Ros Tern Ana 17/04/2005 1005 Estadstica Murray Spiegel McGraw Hill Roca Ren 16/04/2005 1006 Oracle University Nancy Greenberg Oracle Corp. Garca Roque Luis 20/04/2005 1006 Oracle University Priya Nathan Oracle Corp. Garca Roque Luis 20/04/2005 1007 Power Buider 10.0 Ramalho McGraw Hill Prez Gmez Juan 18/04/2005
Como se puede ver, hay cierta redundancia caracterstica de 1NF. La Segunda Forma Normal (2NF) pide que no existan dependencias parciales o dicho de otra manera, todos los atributos no clave, deben depender por completo de la clave primaria.
Por ejemplo, el ttulo es completamente identificado por el cdigo del libro, pero el nombre del lector en realidad no tiene dependencia de este cdigo, por tanto, estos datos deben ser trasladados a otra tabla.
Del Modelo Fsico Relacional de Base de Datos 71
2NF
CodLibro Ttulo Autor Editorial 1001 Variable compleja Murray Spiegel McGraw Hill 1004 Visual Basic 2005 E. Petroustsos Anaya 1005 Estadstica Murray Spiegel McGraw Hill 1006 Oracle University Nancy Greenberg Oracle Corp. 1006 Oracle University Priya Nathan Oracle Corp. 1007 Power Buider 10.0 Ramalho McGraw Hill
La nueva tabla slo contendr datos del lector.
CodLector Paterno Materno Nombres 501 Prez Gmez Juan 502 Ros Tern Ana 503 Roca Ren 504 Garca Roque Luis
Se ha creado una tabla para contener los datos del lector y tambin se cre la columna CodLector para identificar unvocamente a cada uno. Sin embargo, esta nueva disposicin de la base de datos necesita que exista otra tabla para mantener la informacin de qu libros estn prestados y a qu lectores.
Para la Tercera Forma Normal (3NF) la relacin debe estar en 2NF y adems, los atributos no clave, deben ser mutuamente independientes y dependientes por completo, de la clave primaria. Esto significa que las columnas en la tabla deben contener solamente informacin sobre la entidad definida por la clave primaria y, por tanto, las columnas en la tabla deben contener datos acerca de una sola cosa. En el ejemplo en 2NF, la primera tabla conserva informacin acerca del libro, los autores y editoriales, por lo cual, se debern crear nuevas tablas para satisfacer los requisitos de 3NF. Del Modelo Fsico Relacional de Base de Datos 72
3NF
CodLibro Titulo 1001 Variable compleja 1004 Visual Basic 2005 1005 Estadstica 1006 Oracle University 1007 Power Builder 10.0
CodAutor Autor 801 Murray Spiegel 802 E. Petroustsos 803 Nancy Greenberg 804 Priya Nathan 806 Ramalho
CodEditorial Editorial 901 McGraw Hill 902 Anaya 903 Oracle Corp.
Aunque se han creado nuevas tablas para que cada una tenga informacin acerca de una entidad, tambin se ha perdido la informacin acerca de qu autor ha escrito qu libro y las editoriales correspondientes, por ende, se debern crear otras tablas que relacionen cada libro con sus autores y editoriales.
CodLibro codEditorial 1001 901 1004 902 1005 901 1006 903 1007 901 CodLect or Patern o Matern o Nombre s 501 Prez Gmez Juan 502 Ros Tern Ana 503 Roca Ren 504 Garca Roque Luis CodLibro CodLector FechaDev 1001 501 15/04/2005 1004 502 17/04/2005 1005 503 16/04/2005 1006 504 20/04/2005 1007 501 18/04/2005
Normalizacin vs. Desnormalizacin: Cmo sera si en vez de normalizar las tablas de las bases de datos, se desnormalizarn; suena incoherente para alguien que ha seguido el dogma de diseo de bases de datos. Sin entrar en grandes detalles, uno de los resultados casi directos de la normalizacin tiende a ser la obtencin de varias tablas relacionadas unas con otras de una manera fsica.
El normalizar una base de datos, depende de la aplicacin que se desarrolle. Si el diseo slo tiene una clase persistente, generalmente, se debera tener una tabla representndola.
Uno de los principales mitos respecto a las consecuencias de normalizar una BBDD es pensar que en un motor relacional es costoso procesar un join. Esto incide en el hecho de tener tres tablas (resultado de una normalizacin) y luego, realizar una consulta sobre las tres tablas, entonces se tendrn que hacer 2 joins.
El tiempo de respuesta es menor si slo se consulta una tabla. En una aplicacin pequea esto pasa desapercibido, pero en una aplicacin que maneja grandes volmenes de acceso a datos, de seguro que si se toma en cuenta. Sin embargo, las consultas a una BBDD son solo una pequea parte de lo que una aplicacin hace con ellas.
Por otro lado, si se quiere eliminar un registro en una tabla, y esa tabla est relacionada con otras, se tendr que eliminar tambin el registro de esas tablas.