Unidad III: Modelo Lógico de BD

. Universidad Politécnica Territorial Andrés Eloy Blanco
Programa Nacional de Formación en Informática
Ing. Lissette Torrealba
Modelo Relacional, Entidad, Relaciones, atributos, cardinalidad. Tablas, Campos, laves primarias,
claves foráneas, restricciones
Unidad II: El Modelo De Datos Relacional
Objetivo de la Unidad:
Al finalizar esta unidad de aprendizaje los alumnos comprenden e interpreta el modelo relacional de
una base de datos
Desarrollo
Modelos de datos lógicos
Un modelo de datos lógicos describe los datos con el mayor detalle posible, independientemente de
cómo se implementarán físicamente en la base de datos.
Las características de un modelo de datos lógicos incluyen:
 Incluye todas las entidades y relaciones entre ellos.
 Todos los atributos para cada entidad están especificados.
 La clave principal para cada entidad está especificada.
Introducción
Los SGBD se pueden clasificar de acuerdo con el modelo lógico que soportan, el número de usuarios,
el número de puestos, el coste… La clasificación más importante de los SGBD se basa en el modelo
lógico, siendo los principales modelos que se utilizan en el mercado los siguientes: Jerárquico, en Red,
Relacional y Orientado a Objetos.
La mayoría de los SGBD comerciales actuales están basados en el modelo relacional, en el que nos
vamos a centrar, mientras que los sistemas más antiguos estaban basados en el modelo de red o el
modelo jerárquico.
Los motivos del éxito del modelo relacional son fundamentalmente, se basan en el álgebra relacional
que es un modelo matemático con sólidos fundamentos.
Objetivo.
En esta unidad se abordará el Modelo Relacional de Datos, dentro de la fase de análisis del proceso de
desarrollo software. El objetivo que nos planteamos es que, al finalizar el alumno sea capaz de
realizar el Modelo relacional de datos de un sistema de información.
Requerimientos.
Se debe contar con: Un (1) computador teniendo como mínimo el Sistema Operativo Libre
( Canaima/Ubuntu), Aplicación para diseñar modelo conceptual, papel, lápiz.
Componentes.

Universidad Politécnica Territorial Andrés Eloy Blanco
 Se especifican las claves externas (claves que identifican la relación entre diferentes entidades).
 La normalización ocurre en este nivel.
Los pasos para diseñar el modelo de datos lógicos son los siguientes:
 Especifique claves primarias para todas las entidades.
 Encuentra las relaciones entre diferentes entidades.
 Encuentra todos los atributos para cada entidad.
 Resuelva las relaciones de muchos a muchos.
 Normalización.
Modelo Relacional
El modelo relacional se basa en el concepto matemático de relación, que gráficamente se representa
mediante una tabla. Es decir, una relación es una tabla, con columnas y filas. Un SGBD sólo necesita
que el usuario pueda percibir la base de datos como un conjunto de tablas.
Elementos y propiedades del modelo relacional
 Relación (tabla): Representan las entidades de las que se quiere almacenar información en la
BD. Está formada por:
o Filas (Registros o Tuplas): Corresponden a cada ocurrencia de la entidad.
o Columnas (Atributos o campos): Corresponden a las propiedades de la entidad.
Siendo rigurosos una relación está constituida sólo por los atributos, sin las tuplas.
 Las relaciones tienen las siguientes propiedades:
o Cada relación tiene un nombre y éste es distinto del nombre de todas las demás
relaciones de la misma BD.
o No hay dos atributos que se llamen igual en la misma relación.
o El orden de los atributos no importa: los atributos no están ordenados.
o Cada tupla es distinta de las demás: no hay tuplas duplicadas. (Como mínimo se
diferenciarán en la clave principal)
o El orden de las tuplas no importa: las tuplas no están ordenadas.
 Clave candidata: atributo que identifica unívocamente una tupla. Cualquiera de las claves
candidatas se podría elegir como clave principal.
 Clave Principal: Clave candidata que elegimos como identificador de la tuplas.
 Clave Alternativa: Toda clave candidata que no es clave primaria (las que no hayamos elegido
como clave principal)
 Una clave principal no puede asumir el valor nulo (Integridad de la entidad).
 Dominio de un atributo: Conjunto de valores que pueden ser asumidos por dicho atributo.
 Clave Externa o foránea o ajena: el atributo o conjunto de atributos que forman la clave
principal de otra relación. Que un atributo sea clave ajena en una tabla significa que para
introducir datos en ese atributo, previamente han debido introducirse en la tabla de origen. Es
decir, los valores presentes en la clave externa tienen que corresponder a valores presentes en
la clave principal correspondiente (Integridad Referencial).

Restricciones del Modelo Relacional
El modelo relacional de datos contempla tres tipos de restricciones:
1. Integridad de la clave. Ningún atributo de una clave candidata puede tomar valores nulos.
Lógicamente, los atributos que forman una clave candidata han de tomar siempre valores distintos para
cada posible tupla.
2. Integridad de referencia o referencial. Sea T1.a un atributo de la tabla T1 que forma parte de una
clave ajena para la tabla T2. Es decir, que en T2 existe un atributo definido con el mismo dominio,
aunque no obligatoriamente con igual nombre, y que es parte de su clave primaria. Entonces, T1.a
debe ser siempre igual a algún valor ya contenido en el atributo referenciado en la tabla T2, o bien
tomar un valor nulo.
3. Otras restricciones de acuerdo con la semántica concreta del problema. Pueden ser sencillas, como
la especificación de valores mínimos o máximos que puede tomar un atributo numérico, lista de
valores permitidos de un atributo, o más complejas: condiciones sobre valores de los atributos en
función de valores de otros atributos de esa u otras tablas.
Ejemplo
Se desea almacenar información sobre alumnos universitarios. Para cada alumno hay que almacenar el
estado donde reside.
Restricciones en el ejemplo
1. Integridad de clave
El atributo ALUMNO. Cedula no puede tomar valor nulo.
El atributo ESTADO.cod_estado no puede tomar valor nulo.
El atributo ESTADO.nombre no puede tomar valor nulo.
2. Integridad referencial
El atributo ALUMNO.cod_estado siempre debe tener un valor que se encuentre en
ESTADO.cod_estado,
3. Otras restricciones
El atributo ALUMNO.cedula solo puede tomar valores numéricos enteros de 8 cifras.
Conversión de Diagramas E/R a modelos Relacionales
Al pasar del esquema E/R al esquema Relacional deberemos añadir las claves foráneas necesarias para
establecer las interrelaciones entre las tablas. Dichas claves foráneas no aparecen representadas en el esquema
E/R.
Se deben elaborar los diagramas relacionales de tal forma que, posteriormente al introducir datos, no quede
ninguna clave foránea a valor nulo (NULL). Para ello se siguen las reglas que se muestran a continuación:

Entidades
Cada entidad se transforma en una tabla. El identificador (o identificadores) de la entidad pasa a ser la clave
principal de la relación y aparece subrayada o con la indicación: PK (Primary Key).
Relaciones
Dependiendo de cómo se definan las cardinalidades de las relaciones, éstas pueden generar una tabla o por el
contrario traducirse en columnas dentro de las tablas asociadas a las entidades que participan en dicha relación.
Relaciones 1:N (Una a muchas)
Por lo general no generan tabla. Se dan 2 casos:
 Caso 1: Si la entidad del lado «1» presenta participación (0,1), entonces se crea una nueva tabla
para la relación que incorpora como claves ajenas las claves de ambas entidades. La clave
principal de la relación será sólo la clave de la entidad del lado «N».
 Caso 2: Para el resto de situaciones, la entidad del lado «N» recibe como clave ajena la clave
de la entidad del lado «1». Los atributos propios de la relación pasan a la tabla donde se ha
incorporado la clave ajena.
Ejemplo:1:N un propietario puede tener varios vehículos. Una instancia de entidad propietario se
relaciona con muchas instancias de la entidad vehículo y una instancia vehículo solo puede estar
relacionada con una instancia de propietario.
Tabla: propietario
cedula Nombre Dirección Ciudad telefono
Relaciones N:M: Es el caso más sencillo. Siempre generan tabla. Se crea una tabla que incorpora como claves
ajenas o foráneas FK (Foreign Key) cada una de las claves de las entidades que participan en la relación. La
clave principal de esta nueva tabla está compuesta por dichos campos. Es importante resaltar que no se trata de
2 claves primarias, sino de una clave primaria compuesta por 2 campos.
Nota: la clave primaria podría ser un nuevo campo auto-incrementable.
Tabla: vehiculo
matricula marca modelo color cedula_propietario
Clave
Primaria
Clave
Primaria

Ejemplo: N:M: Una instancia AUTOR, está relacionada con muchas instancias de la entidad LIBRO y
viceversa
Tabla autor
codigo nombre
A1 Gabriel García Márquez
A2 Ferran Virgós Bel
A3 Joan Segura Casanovas
Normalización
El diseño de una BD relacional se puede realizar aplicando al mundo real, en una primera fase, un
modelo como el modelo E/R, a fin de obtener un esquema conceptual; en una segunda fase, se
transforma dicho esquema al modelo relacional mediante las correspondientes reglas de
transformación. También es posible, aunque quizás menos recomendable, obtener el esquema
relacional sin realizar ese paso intermedio que es el esquema conceptual. En ambos casos, es
conveniente (obligatorio en el modelo relacional directo) aplicar un conjunto de reglas, conocidas
como Teoría de normalización, que nos permiten asegurar que un esquema relacional cumple unas
ciertas propiedades, evitando:
 La redundancia de los datos: repetición de datos en un sistema.
Tabla: libro
codigo titulo isbn editorial paginas
L01 Fundamentos De
Informática
9788448167479 McGraw-Hill 450
L02 Cien Años de Soledad 9788497592208 Planeta 500
Tabla libroxautor
codigo codigo_autor codigo_libro
A2L01 A2 L01
A3L01 A3 L01
A1L02 A1 L02
Clave
Primaria
Clave
Primaria
Tabla Relación
Clave
Primaria
Clave
Foránea
Clave Foránea

 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.
En la práctica, si la BD se ha diseñado haciendo uso de modelos semánticos como el modelo E/R no
suele ser necesaria la normalización. Por otro lado si nos proporcionan una base de datos creada sin
realizar un diseño previo, es muy probable que necesitemos normalizar.
En la teoría de bases de datos relacionales, las formas normales (FN) proporcionan los criterios para
determinar el grado de vulnerabilidad de una tabla a inconsistencias y anomalías lógicas. Cuanta más
alta sea la forma normal aplicable a una tabla, menos vulnerable será a inconsistencias y anomalías.
Edgar F. Codd originalmente definió las tres primeras formas normales (1FN, 2FN, y 3FN) en 1970.
Estas formas normales se han resumido como requiriendo que todos los atributos sean atómicos,
dependan de la clave completa y en forma directa (no transitiva). La forma normal de Boyce-Codd
(FNBC) fue introducida en 1974 por los dos autores que aparecen en su denominación. Las cuarta y
quinta formas normales (4FN y 5FN) se ocupan específicamente de la representación de las relaciones
muchos a muchos y uno a muchos entre los atributos y fueron introducidas por Fagin en 1977 y 1979
respectivamente. Cada forma normal incluye a las anteriores.
Beneficios de la Normalización:
 Nos permite representar un conjunto de datos complejos en estructuras más simples y estables.
 Asegura de que los atributos se ubiquen apropiadamente a la entidad a la que pertenecen y que
estén en un solo lugar, con un solo nombre y con un solo valor a la vez.
 Simplifica la lógica de la base de datos.
 Facilita la estandarización, lectura y entendimiento de las bases de datos.
 Reduce el consumo de espacio.
 Optimiza la ejecución de las consultas.
 Reduce la redundancia de datos.
 Facilita el mantenimiento de la base de datos y de las aplicaciones.
 Protege la integridad de los datos.
 Facilita el diseño de consultas.
 Aumenta el número de usuarios concurrentes que la base de datos puede soportar.
Objetivos generales de la normalización.
-A Nivel Base:
 Elimina la repetición de grupos.
 Minimizar redundancia.
 Facilitar el mantenimiento de la base de datos.
 Optimizar el rendimiento de la base.
-A Nivel Tabla:
 Cada tabla debe representar sólo un tipo de entidad (como una persona, un lugar, un pedido de
cliente o un producto).
 Eliminar repetición de columnas.
 Definir una clave primaria por tabla.
 Eliminar el uso de claves compuestas.

 Separar los campos que no sean de esa tabla y/o clave primaria y ubicarlos en la tabla/entidad
correcta.
 Crear una nueva tabla para mover la repetición de grupos de la tabla original. (generación de
catálogos)
 Cada registro debe de tener una clave primaria única e irrepetible.
-A Nivel Campo:
 Todos los campos deben depender de la clave primaria, ya sea directamente o indirectamente.
 Cada campo debe de representar un hecho de la clave primaria y nada más.
 Eliminar dependencias de los campos a claves no primarias.
 Todos los campos deben contener un único valor.
 Todos los valores de cada campo debe tener el mismo tipo de dato.
1FN:
 Solo debe de existir un solo valor atómico (indivisible) por columna, el cual hay que evitar que
sea nulo(null).
 No se deben almacenar campos calculados (como el promedio).
2FN:
 La base de datos debe de estar normalizada a la forma 1FN.
 Cada registro debe depender de la clave primaria de la tabla a la que pertenece.
 Cada clave primaria debe determinar una solo ocurrencia para cada registro. Normalmente un
entero autoincremental hace el trabajo aquí.
3FN:
 Generar catálogos (relaciones uno a muchos). Cada columna se debe de separar y colocar en su
respectiva tabla.
 Cada campo debe de representar un hecho acerca de la llave primaria y nada más.
 Los atributos que no sean clave única y que dependan de otra tabla deberán ser llaves foráneas
que hagan referencia a las llaves primarias de la tabla a la que pertenecen.
 No almacenar valores calculados como por ejemplo un promedio.
4FN:
 Generación de tablas muchos a muchos. Esto para resolver las dependencias multivaluadas.
5FN:
 Generación de tablas muchos a muchos, pero usando únicamente llaves foráneas.
Un ejemplo completo
A través del siguiente ejercicio se intenta afirmar los conocimientos de normalización con un ejemplo
simplificado de una base de datos para una pequeña biblioteca.
CodLibro Titulo Autor Editorial NombreLector FechaDev
1001 Variable compleja Murray Spiegel McGraw Hill Pérez Gómez,
Juan
15/04/2005
1004 Visual Basic 5 E. Petroustsos Anaya Ríos Terán, Ana 17/04/2005
1005 Estadística Murray Spiegel McGraw Hill Roca, René 16/04/2005
1006 Oracle University Nancy Greenberg
y Priya Nathan
Oracle Corp. García Roque,
Luis
20/04/2005
1007 Clipper 5.01 Ramalho McGraw Hill Pérez Gómez,
Juan
18/04/2005

Esta tabla no cumple el requisito de la Primera Forma Normal (1NF) de sólo tener campos atómicos,
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 Titulo Autor Editorial Paterno Materno Nombres FechaDev
1001 Variable compleja Murray Spiegel McGrawHill Pérez Gómez Juan 15/04/2005
1004 Visual Basic 5 E. Petroustsos Anaya Ríos Terán Ana 17/04/2005
1005 Estadística Murray Spiegel McGrawHill Roca René 16/04/2005
1006 OracleUniversity Nancy Greenberg OracleCorp. García Roque Luis 20/04/2005
1006 OracleUniversity Priya Nathan OracleCorp. García Roque Luis 20/04/2005
1007 Clipper 5.01 Ramalho McGrawHill Pérez Gómez Juan 18/04/2005
Como se puede ver, hay cierta redundancia característica 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. Actualmente en nuestra
tabla tenemos varias dependencias parciales si consideramos como atributo clave el código del libro.
Por ejemplo, el título es completamente identificado por el código del libro, pero el nombre del lector
en realidad no tiene dependencia de este código, por tanto estos datos deben ser trasladados a otra
tabla.
2NF
CodLibro Titulo Autor Editorial
1001 Variable
compleja
Murray Spiegel McGraw Hill
1004 Visual Basic 5 E. Petroustsos Anaya
1005 Estadística Murray Spiegel McGraw Hill
1006 Oracle University Nancy Greenberg Oracle Corp.
1006 Oracle University Priya Nathan Oracle Corp.
1007 Clipper 5.01 Ramalho McGraw Hill
La nueva tabla sólo contendrá datos del lector.
CodLector Paterno Materno Nombres
501 Pérez Gómez Juan
502 Ríos Terán Ana

503 Roca René
504 García Roque Luis
Hemos creado una tabla para contener los datos del lector y también tuvimos que crear la
columna CodLector para identificar unívocamente a cada uno. Sin embargo, esta nueva disposición de
la base de datos necesita que exista otra tabla para mantener la información de qué libros están
prestados a qué lectores. Esta tabla se muestra a continuación:
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
Para la Tercera Forma Normal (3NF) la relación debe estar en 2NF y además los atributos no clave
deben ser mutuamente independientes y dependientes por completo de la clave primaria. También
recordemos que dijimos que esto significa que las columnas en la tabla deben contener solamente
información 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 nuestro ejemplo en 2NF, la primera tabla conserva información acerca del libro, los autores y
editoriales, por lo que debemos crear nuevas tablas para satisfacer los requisitos de 3NF.
3NF
CodLibro Titulo
1001 Variable compleja
1004 Visual Basic 5
1005 Estadística
1006 Oracle University
1007 Clipper 5.01
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 hemos creado nuevas tablas para que cada una tenga sólo información acerca de una entidad,
también hemos perdido la información acerca de qué autor ha escrito qué libro y las editoriales
correspondientes, por lo que debemos crear otras tablas que relacionen cada libro con sus autores y
editoriales.
Y el resto de las tablas no necesitan modificación.
Otro Ejemplo de tabla con normalización cero:
Vamos a darle solución a esta tabla llamada “CURSOS” para entender mucho mejor todo el proceso
de normalización.
CodLibro codAutor
1001 801
1004 802
1005 801
1006 803
1006 804
1007 806
CodLibro codEditorial
1001 901
1004 902
1005 901
1006 903
1007 901
501 Pérez Gómez Juan
502 Ríos Terán Ana
503 Roca René
504 García 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

A simple vista podemos apreciar que esta tabla no cumple con el requisito mínimo de normalización
que dice que toda la información deben de ser atómicos, es decir que debemos de descomponerlo en su
mínima expresión de datos.
La solución: Formalizar la Tabla Cursos
La primera fase es crear tablas separadas para Cursos, para docentes, para manuales y cada una de
estas tendría su clave primaria y estarían relacionadas por una clave foránea (Foreign Key).
Tabla de Cursos:
Esta tabla posee el nombre del curso y está relacionada a manualId y docenteId
Tabla de Docente:
Recudiendo en su mínima expresión, separando en apellidos paternos, apellidos maternos, nombres y
fecha de registro.
Tabla de Manual:
Esta tabla está relacionada con la “tabla cursos” de uno a muchos mediante clave primaria.

La segunda fase de Normalización
Es relacionar las tablas mediante una clave primaria y clave foránea.
Otro Ejemplo partiendo que se tiene una base de datos en una tabla de Excel.
La Tabla 3.5 almacena los siguientes detalles:
 Cada orden que se realiza, es identificada por un IdOrden.
 La fecha de la orden (FechaOrden).
 Los detalles del cliente que ha pedido los artículos (Cliente, EmailCliente).
 A cada cliente, dependiendo de su historia de crédito, se le asigna PuntosCredito.
De acuerdo con PuntosCredito, se califica a un cliente. Por ejemplo, los clientes con los
PuntosCredito de 1, 2 y 3 están en el Grado A.
Los clientes con PuntosCredito de 4, 5 y 6 están en el Grado B. La tabla almacena
PuntosCredito y Grado del cliente.
 Los artículos pedidos (NombreItem).

 La cantidad pedida por cada artículo (CantReque).
 El precio unitario del artículo (PrecioUnitario).
Según la definición de 1NF, los campos de variables repetidas y los grupos de variables
repetidas deben ser eliminados.
¿Qué es un grupo de variables repetidas?
En la Tabla 3.5 Orden, los detalles del cliente se repiten por cada artículo que fue pedido.
Por ejemplo, el cliente Joe Smith ha pedido martillo, clavo y sierra. Los detalles de este
cliente se han repetido en la tabla tres veces, ya que ha pedido tres artículos.
Esta clase de repetición en grupos de valores se llama grupo de variables repetidas. La
tabla anterior no está en 1NF, pues viola la condición de repetición de grupo.
Observe las desventajas de una tabla no normalizada. En la tabla anterior, si se cambia la
dirección de correo electrónico (e-mail) del cliente Joe Smith, se debe cambiar en tres
lugares. Así pues, si el cliente ha hecho tres órdenes y en cada orden ha pedido cinco
artículos, entonces se debe cambiar su dirección de correo electrónico (e-mail) en 15 filas.
El precio unitario de los artículos también se repite para cada orden, si el artículo se incluye
en varias órdenes.
Se aplica la 1NF en la tabla anterior sobre órdenes. Cuando se aplica la normalización, dará
lugar a dos tablas, la Tabla 3.6 con clave primaria IdOrden y la Tabla 3.7 con clave primaria
IdOrden y NombreItem (Clave Compuesta).
2NF
Un diseño relacional se dice que está en segunda forma normal (2NF) si, y sólo si, está en
1NF y cada columna que no está en la clave primaria es dependiente totalmente de la clave
primaria.
La 2NF sólo se aplica a las Tablas que tienen claves primarias compuestas (por dos o más
columnas). Si una Tabla está en 1NF y su clave primaria es simple (tiene una sola columna),

entonces también está en 2NF.
Para pasar una Tabla en 1NF a 2NF hay que eliminar las dependencias parciales de la clave
primaria. Para ello, se eliminan las columnas que no dependen completamente de la clave
compuesta y se colocan en una nueva tabla con una copia de su determinante (las
columnas de la clave primaria de las que dependen).
La Tabla 3.6 está en 2NF, ya que la tabla tiene clave primaria simple, en este caso la tabla
permanece igual, el siguiente paso es verificar la 3NF.
Considere la Tabla 3.7 que enumera los artículos pedidos en cada orden. La columna clave
en esta tabla es una clave compuesta por IdOrden y NombreItem. IdOrden y NombreItem,
en combinación, identifican cada fila en la Tabla 3.7. Las otras columnas
(CantReque y PrecioUnitario) son columnas no-clave.
La columna cantidad requerida (CantReque) es totalmente dependiente de la clave
compuesta por IdOrder y NombreItem. Sin embargo, la columna del precio (PrecioUnitario)
no es totalmente dependiente de la clave compuesta, es dependiente de la columna
NombreItem, aunque se mantiene en la tabla DetalleOrden una columna
PrecioUnitarioVenta de Item, para asegurar tener el precio de venta del producto en ese
momento, en el caso de que en un futuro aumenten los precios del ítem. Para hacer que la
Tabla 3.7 cumpla con 2NF, se divide en dos tablas, las tablas DetalleOrden e Item.
Vea las Tablas 3.8 y 3.9.
Se agrega la columna IdItem la cual será el identificador de cada Item en la Tabla 3.9.
La columna de PrecioUnitario es una característica de un artículo, y por lo tanto, se incluye
en la tabla Item, se mantiene una columna PrecioUnitarioVenta en la Tabla 3.8 para
garantizar información histórica de venta de un Item. La Tabla 3.8 tiene como clave primaria
IdOrden e IdItem (Clave Compuesta) y la Tabla 3.9 tiene como clave primaria IdItem.
3NF

Para que un diseño relacional esté en 3NF, tiene que estar en 2NF y cada columna oclave
tiene que ser mutuamente excluyente e independiente. No debe tener ninguna dependencia
transitiva.
Dependencia Transitiva:
Tome un ejemplo para entender la dependencia transitiva. Asuma que se tienen tres
columnas A, B y C en una tabla, donde A es la columna clave. La dependencia se puede
especificar como A---> B, C. En esta relación, si B depende de A y C depende de B,
entonces C también depende de A. Esta clase de dependencia se denomina dependencia
transitiva. Si hay una dependencia transitiva, entonces se elimina separando la tabla, en la
Tabla 1 que contiene las columnas A y B, y la Tabla 2 que contiene las columnas B y C.
La Tabla 3.6 está en 2NF, pero no en 3NF. La columna clave de la tabla Orden (Tabla 3.6)
es IdOrden. Según 3NF, todas las columnas no-clave tienen que ser mutuamente
independientes. Las columnas no-clave PuntosCredito y Grado no son mutuamente
independientes, así como las columnas cliente y emailCliente no son mutuamente
independientes.
Cada Grado se basa en PuntosCredito. A los clientes que tienen PuntosCredito 1, 2 y 3 se
les asigna el Grado A. Los clientes que tienen PuntosCredito 4, 5 y 6 se les asignan el
Grado B. Cuando se aplica 3NF en la Tabla 3.6, da lugar a tres tablas más: la tabla Cliente
Tabla 3.10, la tabla PuntosCredito Tabla 3.11 y la Tabla 3.12 Orden.

La tabla 3.10 Cliente contiene la información del cliente. A cada cliente se le asigna un
IdCliente, que es la columna clave en la tabla. Este IdCliente se utiliza en la tabla
Orden para cada orden. Vea la Tabla 3.12.
La Tabla 3.11 PuntosCredito la columna clave en esta tabla es PuntosCredito para
cada uno de los puntos se asigna un grado de descuento.
Las Tablas 3.10, 3.11 y 3.12 ahora están en 3NF. Las Tablas 3.8 y 3.9 están en 3NF.
Segunda fase de Normalización
Modelar las tablas y sus relaciones en día, utilizando los tipos de datos del SGBD Mysql.
En dia, elegir la opción Base de Datos

Referencias Bibliográficas
IBM Capacitación (2008) Base de Datos I

Unidad III: Modelo Lógico de BD

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Unidad III: Modelo Lógico de BD

Similar a Unidad III: Modelo Lógico de BD (20)

Más de lissette_torrealba

Más de lissette_torrealba (20)

Último

Último (20)

Unidad III: Modelo Lógico de BD