10 de

junio de BASE DE DATOS

2009

1. Diseño de Bases de Datos

El objetivo principal del diseño de bases de datos es generar tablas que

modelan los registros en los que guardaremos nuestra información.

➢ Análisis.
➢ Diseño del modelo entidad / relación.
➢ Diseño del modelo relacional.
➢ Lenguaje SQL y base de datos final.

1.1.Análisis
Debemos comenzar estudiando a fondo el mundo real que deseamos
representar en la aplicación y base de datos.
A partir de este estudio, debemos crear el UD, que es simplemente la visión
del mundo real bajo unos determinados objetivos.
1.2.Modelo entidad / relación (E/R)
El diseñador debe concebir la base de datos en un nivel superior,
abstrayéndose de cualquier consideración técnica o de implementación en
sistema, plataforma o aplicación.
Para ello puede contar con la ayuda de un modelo de datos como el E/R,
presentado por Peter P. Chen. Con él podrá centrarse en la estructura lógica
y abstracta de la información, siendo capaz de representar toda la
semántica del mundo real por medio de entidades y relaciones.
1.3.Modelo relacional
El diseñador debe transformar el modelo E/R en el modelo relacional,
teniendo muy en cuenta la teoría de la normalización. Esta es una
operación de cierta complejidad.
El modelo relacional, presentado por el Dr. E.F.Codd, fue revolucionario
puesto que consigue la independencia de las aplicaciones respecto a los
datos.
Este modelo de datos está basado en las teorías matemáticas de las
relaciones, haciendo que los datos se estructuren lógicamente en forma de
relaciones -tablas.
Presenta beneficios como:
➢ Sencillez y uniformidad: Al tener como resultado una colección de tablas,
y ser la tabla la estructura básica se da como resultado una gran
uniformidad, junto con la sencillez de los lenguajes de usuario que pueden
operar con ellas.
➢ Flexibilidad: Ofreciendo a los usuarios los datos de la forma más adecuada
a su aplicación.
➢ Independencia del interfaz de usuario: El modo en el que se almacena
los datos no influye en su manipulación lógica.

1.4.Lenguaje SQL y base de datos final

Ahora solamente tendremos que codificar en lenguaje SQL el modelo
relacional expuesto anteriormente.
Para ello necesitaremos de:
➢ LDD: Con el que (por ejemplo) codificar las sentencias para la creación de
las distintas tablas de la base de datos.
➢ LMD: Para codificar las instrucciones (que por ejemplo) se encargarán de
realizar:

1
 10 de
junio de BASE DE DATOS
2009

Consultas, Adiciones, Eliminaciones de Registros.

2. Diseño físico
El diseño físico es el proceso de producir la descripción de la implementación de la
base de datos en memoria secundaria: estructuras de almacenamiento y métodos
de acceso que garanticen un acceso eficiente a los datos.
En general, el propósito del diseño físico es describir cómo se va a implementar
físicamente el esquema lógico obtenido en la fase anterior. Concretamente, en el
modelo relacional, esto consiste en:
➢ Obtener un conjunto de relaciones (tablas) y las restricciones que se deben
cumplir sobre ellas.
➢ Determinar las estructuras de almacenamiento y los métodos de acceso que
se van a utilizar para conseguir unas prestaciones óptimas.
➢ Diseñar el modelo de seguridad del sistema.

3. Diseño conceptual
En esta etapa se debe construir un esquema de la información que se usa en la
empresa, independientemente de cualquier consideración física. A este esquema se
le denomina esquema conceptual. Al construir el esquema, los diseñadores
descubren la semántica (significado) de los datos de la empresa: encuentran
entidades, atributos y relaciones. El objetivo es comprender:
➢ La perspectiva que cada usuario tiene de los datos.
➢ La naturaleza de los datos, independientemente de su representación física.
➢ El uso de los datos a través de las áreas de aplicación.
El esquema conceptual se puede utilizar para que el diseñador transmita a la
empresa lo que ha entendido sobre la información que ésta maneja. Para ello,
ambas partes deben estar familiarizadas con la notación utilizada en el esquema. La
más popular es la notación del modelo entidad-relación, que se describirá en el
capítulo dedicado al diseño conceptual.

4. Diseño lógico
El diseño lógico es el proceso de construir un esquema de la información que utiliza
la empresa, basándose en un modelo de base de datos específico, independiente
del SGBD concreto que se vaya a utilizar y de cualquier otra consideración física.
En esta etapa, se transforma el esquema conceptual en un esquema lógico que
utilizará las estructuras de datos del modelo de base de datos en el que se basa el
SGBD que se vaya a utilizar, como puede ser el modelo relacional, el modelo de red,
el modelo jerárquico o el modelo orientado a objetos. Conforme se va desarrollando
el esquema lógico, éste se va probando y validando con los requisitos de usuario.
La normalización es una técnica que se utiliza para comprobar la validez de los
esquemas lógicos basados en el modelo relacional, ya que asegura que las
relaciones (tablas) obtenidas no tienen datos redundantes. Esta técnica se presenta
en el capítulo dedicado al diseño lógico de bases de datos.

5. Características de una base de datos

➢ La velocidad de acceso,
➢ El tamaño de la información,

2
10 de
junio de BASE DE DATOS
2009

➢ El tipo de la información,
➢ Facilidad de acceso a la información,
➢ Facilidad para extraer la información requerida,
➢ El comportamiento del manejador de bases de datos con cada tipo de
información.

6. Objetivos del Diseño de la Base de Datos

Entre las metas más importantes que se persiguen al diseñar un modelo de bases
de datos, se encuentran las siguientes que pueden observarse en esta figura.

7. Almacenar Solo La Información Necesaria

Frecuentemente podemos generar algunos datos sobre la marcha sin tener que
almacenarlos en una tabla de una base de datos. En estos casos también tiene
sentido hacer esto desde el punto de vista del desarrollo de la aplicación.

7.1. Normalizar la Estructura de las Tablas

Uno de los objetivos de una estructura de tabla normalizada es minimizar el
número de celdas vacías.
El concepto relacional, significa que grupos parecidos de información son
almacenados en distintas tablas que luego pueden ser "juntadas"
(relacionadas) basándose en los datos que tengan en común.

Es necesario que al realizar la estructura de una base de datos, esta sea

flexible. La flexibilidad está en el hecho que podemos agregar datos al
sistema posteriormente sin tener que rescribir lo que ya tenemos.
La eficiencia se refiere al hecho de que no tenemos duplicación de datos, y
tampoco tenemos grandes cantidades de "celdas vacías".

3
 10 de
junio de BASE DE DATOS
2009

Podríamos decir que estos son los principales objetivos de la normalización:

➢ Controlar la redundancia de la información.

➢ Evitar pérdidas de información.
➢ Capacidad para representar toda la información.
➢ Mantener la consistencia de los datos.

7.2.Seleccionar el Tipo de Dato Adecuado

Una vez identificadas todas las tablas y columnas que necesita la base de
datos, debemos determinar el tipo de dato de cada campo.

Existen tres categorías principales que pueden aplicarse prácticamente a

cualquier aplicación de bases de datos:

➢ Texto
➢ Números
➢ Fecha y hora

Cada uno de éstos presenta sus propias variantes, por lo que la elección del
tipo de dato correcto no sólo influye en el tipo de información que se puede
almacenar en cada campo, sino que afecta al rendimiento global de la base de
datos.

A continuación se dan algunos consejos que nos ayudarán a elegir un tipo de

dato adecuado para nuestras tablas:

➢ Identificar si una columna debe ser de tipo texto, numérico o de

fecha.
➢ Elegir el subtipo más apropiado para cada columna.
➢ Configurar la longitud máxima para las columnas de texto y
numéricas, así como otros atributos.

7.3.Utilizar Índices Apropiadamente

Los índices son un sistema especial que utilizan las bases de datos para
mejorar su rendimiento global. Dado que los índices hacen que las consultas se
ejecuten más rápido, podemos estar incitados a indexar todas las columnas de
nuestras tablas.

Sin embargo, lo que tenemos que saber es que el usar índices tiene un precio.
Cada vez que hacemos un INSERT, UPDATE, REPLACE, o DELETE sobre una
tabla, SQL tiene que actualizar cualquier índice en la tabla para reflejar los
cambios en los datos.

De manera simple, depende que tipo de consultas ejecutamos y que tan

frecuentemente lo hacemos, aunque realmente depende de muchas otras
cosas.

7.4.Usar Consultas REPLACE

Existen ocasiones en las que deseamos insertar un registro a menos de que

éste ya se encuentre en la tabla. Si el registro ya existe, lo que quisiéramos
hacer es una actualización de los datos.

4
10 de
junio de BASE DE DATOS
2009

7.5.Usar Una Versión Reciente de SQL

La recomendación es simple y concreta, siempre que esté en nuestras manos,

debemos usar la versión más reciente de SQL que se encuentre disponible.
Además de que las nuevas versiones frecuentemente incluyen muchas mejoras,
cada vez son más estables y más rápidas. De esta manera, a la vez que
sacamos provecho de las nuevas características incorporadas en SQL, veremos
significativos incrementos en la eficiencia de nuestro servidor de bases de
datos.

7.6.Usar Tablas Temporales.

Cuando estamos trabajando con tablas muy grandes, suele suceder que
ocasionalmente necesitemos ejecutar algunas consultas sobre un pequeño
subconjunto de una gran cantidad de datos. En vez de ejecutar estas consultas
sobre la tabla completa y hacer que SQL encuentre cada vez los pocos registros
que necesitamos, puede ser mucho más rápido seleccionar dichos registros en
una tabla temporal y entonces ejecutar nuestras consultas sobre esta tabla.

Una tabla temporal existe mientras dure la conexión a SQL. Cuando se

interrumpe la conexión SQL remueve automáticamente la tabla y libera el
espacio que ésta usaba.

5
 10 de
junio de BASE DE DATOS
2009

8. Normalización

Normalizar es reconocer cualidades no deseadas en una tabla y la forma de

corregirla.
Características:
• Cualidades no deseadas
• Evitar redundancia de información pero sin perderla

Existen dos formas para normalizar:

1. Enfoque intuitivo

2. Metodología.- Dependencia funcional

Dependencia Funcional

La dependencia funcional se da cuando hay tablas

El atributo A es funcionalmente dependiente del atributo B, si el valor de A

está determinado por el valor de B.

Para la tabla Ciudades, que tenia 2 campos, hemos creado el DIAGRAMA

DE DEPENDENCIAS FUNCIONALES
Valor de Columna de Valor de Columna de
Tabla CIUDAD Tabla CIUDAD
(DETERMINA PK)
Id_ciudad_edit nombre_ciudad_edit

B A

Para la tabla Editoriales, que tenia 4 campos, hemos creado el DIAGRAMA

DE DEPENDENCIAS FUNCIONALES
Valor de Columna Valor de Valor Valor de
de Tabla EDITORIAL Columna de de Columna
(DETERMINA PK) Tabla EDITORIAL Column de Tabla
a de EDITORIAL

6
10 de
junio de BASE DE DATOS
2009

Tabla
EDITOR
IAL
Id_edit nombre_edit, direc_ed id_ciudad_e
it, dit

B A,B,C

Tabla: Ciudades

id_ciudad_edit ( PK) nombre_ciudad_edit

02 Cuenca
04 Guayaquil
07 Quito

MODELO CORREGIDO Y NORMALIZADO

*debe asignarse

* debe publicar

Debe ser creado debe tener asignada

MODELO NO NORMALIZADO EN UNA UNICA Tabla: LIBROS

id_libr Titul Edicion tipo_lib id_e nombre_ Direc_e id_ciud_ed nomb_ciud_

o o ro dit edit dit it edit
NN
PK NN NN
001 A Primera Ciencia 101 LNS M. Aux 02 Cuenca
F
002 B Segund Terror 102 Don Bosco Xxx 04 Guayaquil
a
003 C Primera Drama 103 Norma Yyy 07 Quito
004 Nach Quinta Enseñan 101 LNS M. Aux 02 Cuenca
o Lee za
1

7
 10 de
junio de BASE DE DATOS
2009

005 Nach Segund Enseñan 101 LNS M. Aux 02 Cuenca

o Lee a za
2
09 Ambato

Se debe realizar un diagrama de Dependencias Funcionales (LO PRIMERO ES

QUE DEBO HACER ES VERIFICAR QUE “CAMPOS SERIAN DETERMINANTES,
SERIA PK”

LUEGO INICIO EL Proceso de Normalización:

1FN 2FN 3FN 4FN

Problemas o Anomalías Dependencia Multi valorada (DMV)

– Inserción

– Actualización

– Eliminación

Solución para el Proceso de Normalización:

Atributos Clave (PK)

Atributos NO Clave (normales y los FK)

Crear nuevas tablas y que sus columnas no clave dependan total y funcionalmente
únicamente de su clave primaria.

(1FN) Primera Forma Normal

Está en primera forma normal cuando los valores para los campos o
columnas, en un registro o fila de una tabla, TIENEN UN SOLO VALOR.

Ej.:

Tabla: LIBROS se encuentra en 1FN

8
 10 de
junio de BASE DE DATOS
2009

id_libr titul edición tipo_lib id_e nombre_ Direc_e id_ciud_edi nomb_ciud_

o o ro dit edit dit t edit
001 A Primera Ciencia 101 LNS zzz 02 Quito
F
002 B Segund Terror 102 Don Bosco xxx 04 Guayaquil
a
003 C Primera Drama 103 Norma yyy 07 Cuenca

Anomalías de inserción en 1FN.

Algunas anomalías de inserción se deben a la dependencia funcional de algunos
campos no clave en un subconjunto de atributos de la clave principal en lugar de
toda la clave primaria.

Anomalías en la eliminación en 1FN.

Esto sucede cuando se desea borrar el valor de un campo, y al hacer esto no se
puede borrar sólo ese valor sino que se debe borrar todo el registro, y es donde
aparece esta anomalía debido a que se puede borrar información importante de una
relación.

Anomalías de actualización en 1FN.

Cuando una relación sin normalizar se convierte en una relación 1FN, algunos datos
se duplican. Tal duplicidad de datos almacenados causará problemas en las
operaciones de actualización Y ADEMAS GENERARÁ INCONSISTENCIAS O ERRORES
EN LOS DATOS.

(2FN)Segunda Forma Normal

Si esta en primera forma normal y cada atributo no clave depende

totalmente de su clave principal.

Ej.:

Anomalías de relaciones en 2FN

Puede presentar anomalías de almacenamiento si cualquiera de sus atributos no

clave depende transitivamente de la clave primaria, es decir depende
indirectamente de la clave primaria.

Ej.:

9
 10 de
junio de BASE DE DATOS
2009

Tabla: LIBROS, está en 1FN, está en 2 FN

id_libr titul edición tipo_lib id_e

o o ro dit
001 A Primera Ciencia 101
F
002 B Segund Terror 102
a
003 C Primera Drama 103

Tabla: EDITORIALES, está en 1FN, está en 2FN

id_e nombre_ Direc_e id_ciud_ed nomb_ciud_

dit edit dit it edit

PK
101 LNS zzz 02 Quito
102 Don Bosco xxx 04 Guayaquil
103 Norma yyy 07 Cuenca

Id_edit ----> nombre_edit, Direc_edit, id_ciud_edit, nomb_ciud_edit

(3FN) Tercera Forma Normal

Una relación es tercera forma normal si es 2FN y un atributo no clave YA

NO ES funcionalmente dependiente de algún otro atributo no clave.

Ej.:

Tabla: LIBROS, está en 1FN, 2FN y 3FN

id_li t Id_edicion ID_tipo_ id_e

bro itul _libro libro dit
o
`PK FK FK FK
001 A 001 001 101
002 B 002 002 102
003 C 003 003 103

Tabla: TIPO_LIBROS, está en 1FN, 2FN y 3FN

id_TIPO tipo_l
_libro ibro

PK
001 Cienci
aF
002 Terror
003 Dram
a
10
 10 de
junio de BASE DE DATOS
2009

Tabla: EDICION_LIBROS, está en 1FN, 2FN y 3FN

id_edicio edic
n_libro ión

PK
001 Prim
era
002 Segu
nda
003 Prim
era

Tabla: EDITORIALES, está en 1FN, 2FN y 3FN

id_e nombre_ Direc_e id_ciud_ed

dit edit dit it

PK FK
101 LNS zzz 02
102 Don Bosco xxx 04
103 Norma yyy 07

Tabla: CIUDADES, está en 1FN, 2FN y 3FN

id_ciud_ed nomb_ciud_
it edit

PK
02 Quito
04 Guayaquil
07 Cuenca
Anomalías debidas a dependencia de valores múltiples.

Generalmente un proceso de normalización termina cuando todas las

relaciones pertenecen a tercera forma normal. Sin embargo, si una relación
contiene dependencias de valores múltiples, es necesaria una normalización
posterior. Dada una relación, el atributo A de esta relación se dice ser dependiente
de multi valuados (DMV) del atributo B si un rango específico de valores del atributo
A está determinado por un valor particular de B.

(4FN) Cuarta Forma Normal

Una relación es 4FN si es 3FN y no contiene dependencias multi valoradas.

La dependencia multi valuada se denota X Y, y se lee X multi determina a Y.

11
10 de
junio de BASE DE DATOS
2009

9. Proceso de Análisis y Diseño de la Base de Datos

9.1. Identificación de Entidades: En el proceso de identificación de entidades
se tiene que obtener las entidades principales que intervienen en los
procesos que lleve a cabo la empresa, para esto se tiene que realizar un
análisis previo del trabajo que lleva a cabo la empresa y cada una de sus
áreas.

Realizado un análisis previo de la empresa IMPORCOMPU S.A. se ha

identificado las siguientes entidades principales:

➢ Clientes
➢ Productos
➢ Proveedores
➢ Empleados
➢ Factura

9.2. Modelo Entidad – Relación: En esta parte se realizara el esquema previo

de las relaciones que lleva cada una de las entidades tomando en cuenta su
función dentro de la empresa.
Realizando un seguimiento previo del funcionamiento de la empresa se ha
llegado a la conclusión de las siguientes relaciones que tiene cada una de
las entidades identificadas previamente.

9.3. Proceso de Normalización: En el proceso de normalización analizaremos

cada una de las entidades principales elaborando sus tablas y los campos
correspondientes para luego primeramente identificar la dependencia
funcional de cada uno de sus campos y comenzar el proceso de normalizado
ya descrito en la parte anterior del documento.

Clientes
Cod_Cliente

12
10 de
junio de BASE DE DATOS
2009

Cod_Descuento
Cedula_RUC
Nombres
Apellidos
Direccion
e-mail
Telefono_Conven
sional
Telefono_Celular

Empleados
Cedula_Empleado
Nombres
Apellidos
Direccion
e-mail
Fecha_Nacimiento
Genero
Fecha_Ingreso
Sueldo_Mensual

Productos
Cod_Producto
Tipo
Marca
Modelo
Descripcion
Cantidad
Precio_Compra
Precio_Venta

Proveedores
Prov_RUC
Empresa
Encargad
o
Ciudad
Direccion

13
10 de
junio de BASE DE DATOS
2009

Factura
Factura_Num
Cod_Cliente
Subtotal
Cod_Impuesto
Descuento
Impuesto
Total
Cedula_Emplead
o

En las tablas anteriores se identificado los datos principales que deben

llevar las tablas expuestas, estas tablas han sido analizadas y se les a dado
un campo el cual va identificar a varios de los datos expuestos en los
registros, aplicando así el proceso de dependencia funcional.
Siguiendo el proceso de normalización se ha llevado a cabo la extracción de
campos los cuales almacenaran información adicional y necesaria para la
base de datos.
Cargos
Cod_Cargo
Cargo

Empleados_Cargos
Cod_Cargo
Cedula_Emplead
o

Empleados_Telefonos
Cedula_Emplead
o
Telefono

Personal
Cod_Personal
Tipo_Personal

Cliente_Descuentos
Cod_Descuento
Descuento_Ocacio
nal
Descuento_Frecue
nte

Facturas_Descripcion

14
10 de
junio de BASE DE DATOS
2009

Factura_Nu
m
Cod_Product
o
Cantidad
Decripcion
Valor_Unitari
o
Valor_Total

Facturas_Impuestos
Cod_Impuest
o
Impuesto

Productos_Proveedo
res
Cod_Product
o
Prov_RUC

Proveedores_Fax
Prov_RUC
Fax

Proveedores_Telefon
os
Prov_RUC
Telefono

Tipo_Personal
Cod_Personal
Cedula_Emplead
o

9.4. Descripción de Tablas: En este paso se mostrara todas las tablas

identificadas y normalizadas con sus respectivos campos definidos con
CONSTRAINT – NOMBRE – TIPO DE DATO – LONGITUD.

15
10 de
junio de BASE DE DATOS
2009

FACTURA
CONSTRAIN TIPO DE LONGITU
T NOMBRE DATO D
NN-FK Factura_Num Numeric [5,0]
NN-FK Cod_Cliente Numeric [3,0]
NN Subtotal Money
NN-FK Cod_Impuesto Char [5]
NN Descuento Money
NN Impuesto Money
NN Total Money
NN-FK Cedula_Empleado Nchar [10]

FACTURA DESCRIPCION
CONSTRAINT NOMBRE TIPO DE DATO LONGITUD
NN-PK-UK Factura_Num Numeric [5,0]
NN-FK Cod_Producto Numeric [4,0]
NN Cantidad Numeric [3,0]
Descripcion Char [50]
NN Valor_Unitario Money
NN Valor_Total Money

FACTURA IMPUESTOS
CONSTRAINT NOMBRE TIPO DE DATO LONGITUD
NN-PK-UK Cod_Impuesto Char [5,0]
NN Impuesto Money

EMPLEADOS
CONSTRAIN TIPO DE LONGITU
T NOMBRE DATO D
NN-PK-UK Cedula_Empleado Nchar [10]
NN Nombre Char [25]
NN Apellido Char [25]
NN Direccion Char [40]
NN-UN e-mail Char [20]
NN Fecha de Nacimiento Date/Time
NN Genero Char [1]
NN Fecha_Ingreso Date/Time
NN Sueldo_Mensual Money

EMPLEADOS_TELEFONOS
CONSTRAIN TIPO DE LONGITU
T NOMBRE DATO D
NN-FK Cedula_Empleado Nchar [10]
NN Telefono Nchar [9]
16
10 de
junio de BASE DE DATOS
2009

TIPO_PERSONAL
CONSTRAIN TIPO DE LONGITU
T NOMBRE DATO D
NN-FK Cod_Personal Nchar [2]
NN-FK Cedula_Empleado Nchar [10]

TIPO_PERSONAL
CONSTRAINT NOMBRE TIPO DE DATO LONGITUD
NN-PK-UK Cod_Personal Nchar [2]
NN-UK Tipo_Personal Nchar [15]

EMPLEADOS_CARGO
CONSTRAIN TIPO DE LONGITU
T NOMBRE DATO D
NN-FK Cod_Cargo Char [20]
NN-FK Cedula_Empleado Nchar [10]

EMPLEADOS_CARGO
CONSTRAINT NOMBRE TIPO DE DATO LONGITUD
NN-PK-UK Cod_Cargo Char [20]
NN-UK Cargo Nchar [20]

CLIENTES
CONSTRAIN TIPO DE LONGITU
T NOMBRE DATO D
NN-PK-UK Cod_Cliente Numeric [3,0]
NN-FK Cod_Descuento Nchar [2]
NN-UK Cedula/RUC Nchar [13]
NN Nombre Char [25]
NN Apellido Char [25]
NN Direccion Char [40]
e-mail Char [30]
Telefono_Convencional Numeric [9,0]
Telefono_Celular Numeric [9,0]

CLIENTES_DESCUENTOS
CONSTRAINT NOMBRE TIPO DE DATO LONGITUD
NN-PK-UK Cod_Descuento Nchar [2]
NN Descuento Money

17
10 de
junio de BASE DE DATOS
2009

PRODUCTOS
CONSTRAINT NOMBRE TIPO DE DATO LONGITUD
NN-PK-UK Cod_Producto Numeric [4,0]
NN Tipo Char [20]
NN Marca Char [15]
NN Modelo Char [20]
NN Descripcion Char [50]
NN Cantidad Numeric [3,0]
NN Precio_Compra Money
NN Precio_Venta Money

PRODUCTOS_PROVEEDORES
CONSTRAINT NOMBRE TIPO DE DATO LONGITUD
NN-FK Cod_Producto Numeric [4,0]
NN-FK Prov_RUC Nchar [13]

PROVEEDORES
CONSTRAINT NOMBRE TIPO DE DATO LONGITUD
NN-PK-UK Prov_RUC Nchar [4,0]
NN Empresa Char [13]
NN Encargado Char [15]
NN Ciudad Char [20]
NN Direccion Char [50]

PROVEEDORES
CONSTRAINT NOMBRE TIPO DE DATO LONGITUD
NN-FK Prov_RUC Nchar [13]
NN Fax Nchar [9]

PROVEEDORES
CONSTRAINT NOMBRE TIPO DE DATO LONGITUD
NN-FK Prov_RUC Nchar [13]
NN Telefono Nchar [13]
9.5. Modelo Relacional: El modelo relacional trata del esquema o diagrama
realizado en un programa diseñador o modelador de base de datos el cual
nos mostrara las tablas con sus principales campos y relaciones,
mostrándonos como la base de datos quedara finalmente al momento de
trasladarlo a un sistema gestor de base de datos.

18
10 de
junio de BASE DE DATOS
2009

19