Tecnológico Sudamericano
Base de Datos
Diseño de base de datos
Realizador por: Jhonny Peñaloza Andrés Pesantez Alex Sanmartín Jorge Enderica
1
2009 INDICE
Pág.
Portada…………..……………………………………………………………………………………………………….………. .I Índice………..………………………..…………….……………………………………………………………................ II Introducción…………………………………….…………………………………………………………………………….....IV
CAPITULO I
Marco Teórico
1. Base de Datos ……………….…………............................................................................5 1.1 ventajas………………………………… ventajas……………………………………………………………….……… …………………………….………5 5 1.2 tipos Base Datos…………………………………………… Datos………………………………………………………….…..5 …………….…..5 2. Los DBMS………………………………….....................................................................6 2.1 Esquema DBMS………………………… DBMS……………………………………………………….… …………………………….…..…7 ..…7 3. Diseño Base Datos …………….……….……………………….……….….….……………..8 3.1 identificación de entidades……………………………………………….9 3.2 Relación Entidades……………………………………………………….9 3.3 Identificación de tablas…………………………………………………..9 3.4 Identificación claves……………………………………………………...9
4. Tipos Dato, Longitud ……..………………………………..…………………….………………………..…10
2
5. Dependencia Funcional… …………………………………………………………….………..…..….10 6. Normalización ………………………………………………...…..………………..……11 6.1 Primera Forma Normal …………..………………………..…….……………….11 6.2 Segunda Forma Normal….. ………………………………………………….…………11 6.3 Tercera Forma Normal…… ……..…………………………………….……………………11 6.4 Cuarta Forma Normal …………………………………………….………….……………… 12 7. Relación de Tablas Modelo Relacional ………...……………………………..................12 CAPITULO II Desarrollo 1. Identificación Entidades ………………...……….…………………………………….…13 2. Relación Entidades …………………...………….………………………………….……13 3. Normalización …………………..………………………………………………………....15
4.1 Primera Forma Normal …………..………………………..…….……………….16 4.2 Segunda Forma Normal …………..………………………..…….……………….17 4.3 Tercera Forma Normal …………...………………………..…….……………….19 4.3 Cuarta Forma Normal …………….………………………..…….……………….20 4. Identificación de Tablas… …………...…….…………………………………………..….21 5. Modelo Relacional …………………………………………………………….…………..22
CAPITULO III 1. Conclusiones .……………………………………………………………………………23 2. Recomendaciones …………………………….……………………………………….….24 3. Glosario……………………………………………………………………………….….25 4. Bibliografía ………………..……………………………………………………………..26
3
5. Anexos……………………..…………………………………………………………….27
Introducción
En la actualidad la empresa maneja una gran cantidad de datos, al ser estos datos pieza clave en el funcionamiento de la empresa debe tenerlos almacenados en una base de datos y manejados de una forma automática para poder tratarlos y manejarlos en su totalidad de una forma correcta en los aspectos que lleva a cabo la empresa y con esto evitar perdida un tiempo y un dinero muy valiosos. Uno de los pasos cruciales en la construcción de una aplicación que maneje una base de datos es el diseño de la base de datos. Si las tablas no son definidas apropiadamente, podemos tener muchos inconvenientes al momento de ejecutar consultas a la base de datos datos para tratar de obtener alguna información. La funcionalidad de la base de datos no debe variar en forma considerable si por ejemplo nuestra base de datos tiene sólo 20 registros, o 1000 registros, es importante asegurarnos que nuestra base de datos está correctamente diseñada para que tenga eficiencia y que se pueda seguir utilizando por largo del tiempo. Este trabajo, dará los parámetros básicos para diseñar una base de datos. La complejidad en el diseño de la base de datos, dependerá de cuanta y que información será almacenada en la misma y es única para cada caso, pero todos se basaran en los mismos principios que notaremos en el presente documento.
4
Marco Teórico
CONCETOS Y DEFINICIONES. Base de datos. Un conjunto de información relacionada entre sí, almacenada almacenada en memoria auxiliar que permite permite acceso directo y un conjunto de programas que manipulan esos datos que están estructurados y organizados independientemente de su utilización, y que es utilizada para que el usuario con necesidad de información la consulte en tiempo real. Ventajas de Base de Datos. 1.
Independencia de datos y tratamiento. Cambio en datos no implica cambio en programas y viceversa (Menor coste de mantenimiento).
2.
Coherencia de resultados. Reduce redundancia.
3.
Mejora en la disponibilidad disponibilidad de datos No hay dueño de datos (Pero no son públicos), públicos), guardamos descripción.
Cumplimiento de ciertas normas. Restricciones de seguridad, accesos (Usuarios a datos), operaciones (Operaciones sobre datos). almacenamiento. 5. Otras ventajas: Más eficiente gestión de almacenamiento. 4.
Tipos de Base de Datos.
Por variabilidad de los datos almacenados • •
Estáticos. Solo lectura, son históricos Dinámicos. Se modifican con el tiempo.
Por Contenido. • •
Bibliográficos. Información sobre la fuente principal Texto completo. Contenidos
Modelo de Administración de Datos. •
Jerárquicas. Forma de árbol invertido, puede representar dos tipos de relaciones entre los
•
datos: relaciones de uno a uno y relaciones de uno a muchos, existe redundancia. Red. Este modelo permite la representación de muchos a muchos, de tal forma que cualquier registro dentro de la base de datos puede tener varias ocurrencias superiores a
5
•
• • • • •
él. El modelo de red evita redundancia en la información, a través de la incorporación de un tipo de registro denominado el conector. Relacional. Este modelo se está empleando con más frecuencia en la práctica, debido a las ventajas que ofrece sobre los dos modelos anteriores, entre ellas, el rápido entendimiento por parte de usuarios que no tienen conocimientos profundos sobre Sistemas de Bases de Datos. Multidimensional. Similar a la relacional, esta almacena estructuras de base de datos Orientada a objetos. Relaciona el estado y comportamiento de datos Documentales. Indexación a texto completo Distribuidas. Almacenadas en varias computadoras Deductivas. A través de inferencias (aplicadas al entorno científico)
Nos enfocaremos en la forma relacional que es la más utilizada.
Los DBMS (Sistemas Administradores de Bases de Datos) El DBMS: es un conjunto de programas que se encargan de manejar la creación y todos los accesos a las bases de datos, son un tipo de software muy específico, dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan, está compuesto por: •
•
•
DDL (Data Definition language): Lenguaje de Definición de Datos. Por medio de este el DBMS identifica las descripciones de los elementos de los esquemas y almacena la descripción del esquema en el catálogo del DBMS. Por medio de este el DBMS especifica el esquema conceptual e interno (Base de datos Almacenada). DML (Data Manipulation language): Lenguaje de Manipulación de Datos. Permite la manipulación de las operaciones de Inserción, Eliminación y Modificación. SQL: Lenguaje de Consulta.
Ejemplos: Oracle, Access, Informix, SQL Server. La capacidad de los DBMS se define por su motor, es decir la cantidad de datos que puede ser capaz de manejar. Objetivos. •
•
Independencia física y lógica de los datos. La independencia de los datos consiste en la capacidad de modificar el esquema (físico o lógico) de una base de datos sin tener que realizar cambios en las aplicaciones que se sirven de ella. Redundancia mínima. En aquellos casos en los que no se ha logrado eliminar la redundancia, será necesario vigilar que aquella información que aparece repetida
6
•
•
•
•
•
•
Integridad de los datos. Se trata de adoptar las medidas necesarias para garantizar la validez de los datos almacenados. Acceso concurrente por parte de múltiples usuarios. debe controlar este acceso concurrente a la información, que podría derivar en inconsistencias. Consultas completas optimizadas. Es deseable minimizar el tiempo que el SGBD tarda en darnos la información solicitada y en almacenar los cambios realizados. Seguridad de acceso y auditoria. Deben garantizar que esta información se encuentra segura frente a usuarios malintencionados, malintencionados, que intenten leer información privilegiada. Respaldo y recuperación. Deben proporcionar una forma eficiente de realizar copias de respaldo de la información almacenada en ellos, y de restaurar a partir de estas copias los datos que se hayan podido perder Acceso a través de lenguaje estándar. Pueda ser accesible con lenguaje común.
Propósito
El propósito general de los sistemas de gestión de base de datos es el de manejar de manera clara, sencilla y ordenada un conjunto de datos que posteriormente se convertirán en información relevante, para un buen manejo de los datos. Esquema de un DBMS
7
Usuarios de un Sistema Manejador de Base de Datos • • • •
Personal del DBA Usuarios Esporádicos Programadores de Aplicaciones Usuarios paramétricos
DISEÑO DE BASE DE DATOS Es la base de todo el proceso ya que si el diseño es sólido, al implantarlo no nos nos presentara mayor problema. Consta esencialmente de los siguientes procesos: 1. 2. 3. 4. 5. 6. 7.
Identificación de Entidades Relación de Entidades Identificación de tablas Identificación de claves o keys Tipos de datos y longitud Normalización Modelo relacional
Terminología relacional equivalente
Regla = tabla o archivo Tupla = registro, fila o renglón 8
Atributo = columna o campo Clave = llave o código de identificación Clave Candidata =superclave mínima Clave Primaria = clave candidata elegida Clave Ajena = clave externa o clave cl ave foránea Clave Alternativa = clave secundaria Dependencia Multivaluada = dependencia multivalor RDBMS = Del inglés Relational Data Base Manager System que significa, Sistema Gestor de Bases de Datos Relacionales. 1FN = Significa, Primera Forma Normal o 1NF del inglés First Normal Form.
Identificación de Entidades.
Alguna cosa acerca de la l a cual almacenamos datos. Una persona, lugar, cosa o concepto que empresa.
tiene características de interés para la
Relación de Entidades.
Identificar que entidades se involucran en los procesos, y para la práctica se entrelazan con una palabra que identifica el proceso y flechas de dirección. Ejemplo: Cliente
Recibe
Factura
Identificación de tablas.
Es generar la tabla para cada entidad definiendo los l os campos o registros que sean necesarios para cada uno de ellos. Identificación de claves o Keys.
Una clave primaria es aquella columna (pueden ser también dos columnas o más) que identifica únicamente a esa fila. La clave primaria es un identificador que va a ser único para cada fila. En una tabla puede que tengamos más de una clave, en tal caso se puede
9
escoger una para ser la clave primaria, las demás claves son las claves candidatas. Además es la posible clave primaria. Una clave foránea es aquella columna que existiendo como dependiente en una tabla, es a su vez clave primaria en otra tabla. Una clave alternativa es aquella clave candidata que no ha sido seleccionada como clave primaria, pero que también puede identificar de forma f orma única a una fila dentro de una tabla. Ejemplo: Si en una tabla clientes definimos el número de documento (id cliente) como clave primaria, el número de seguro social de ese cliente podría ser una clave alternativa. En este caso no se usó como clave primaria porque es posible que no se conozca ese dato en todos los clientes. Una clave compuesta es una clave que está compuesta c ompuesta por más de una columna. Pk = clave principal Fk = clave foránea Nn = no nulo Uk = única Ck = clave de chequeo
Tipo de datos, y longitud.
Esto define la clase de información que va a ser almacenada en cada campo. Puede definirse de varios tipos como texto, numérico, monetario, fecha, etc. También debemos definir la longitud del campo es decir que carga soportaría, por ejemplo definimos el campo nombre de tipo texto de longitud 30, esto nos quiere decir que el campo nombre almacenara datos de texto hasta 50 caracteres. c aracteres.
Dependencia funcional
Una dependencia funcional es una conexión entre uno o más atributos. Por ejemplo si conocemos el valor de FechaDeNacimiento podemos conocer el valor de Edad . Se escribe utilizando una flecha: FechaDeNacimiento
Edad
Propiedades : Axiomas de Armstrong
10
Reflexiva. Nos sirve para obtener registros que están relacionados directamente con la clave principal. Por ejemplo: Nro. Cuenta
Nombre Aumentativa. Para poder obtener registros adicionales a los relacionados directamente a la clave principal. Por ejemplo: Nro. Cuenta
Tipo cuenta Estado cuenta Saldo cuenta Transitiva. Es la interpretación de que un atributo depende de otro y de este depende de pende otro. Por ejemplo:
Fecha_Nacim Edad Puede Conducir
Normalización.
El proceso de normalización de bases de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional. Las bases de datos relacionales se normalizan para: • Evitar la redundancia re dundancia de los datos. • Evitar problemas de actualización de los datos en las tablas. • Proteger la integridad de los datos.
11
En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea considerada como una relación tiene que cumplir con algunas restricciones: • Cada columna debe tener su nombre único. • No puede haber dos filas iguales. No se permiten los duplicados. • Todos los datos en una columna deben ser del mismo tipo. Seguiremos 4 Formas Normales: 1. Primera Forma Normal.
Busca campos multivaluados es decir que en un mismo campo guarda dos datos distintos, y los separa en campos distintos. Por ejemplo: El campo teléfono se puede dividir dividir en Telefono1 y Teléfono2 2. Según Forma Normal. Crear tablas separadas para aquellos grupos de datos que se aplican a varios registros. Relacionar estas tablas mediante una clave externa. 3. Tercera Forma Normal.
Análisis de tabla para distinguir los campos que no están asociados directamente con la clave principal. 4. Forma Normal de Boyce- Codd (FNBC)
Se divide la tabla en dos: y CompVent_Detalle Donde el criterio para separar la tabla es elegir los campos que se relacionen entre si y a su vez sean multivaluados, esto se da mayormente en documentos tales como comprobantes de venta/factura/recibo, etc.
CompVenta_maestro
Relación de tablas.
Relacionamos los datos de tres formas diferentes: 1a1 1 a varios Varios a varios 1a1
Al introducir un registro en un campo introducimos simultáneamente uno en otro campo (pero solo uno por vez) 1 a varios
12
Permiten a un campo tener relacionado, y puede introducir en un campo varios registros. Varios a varios
Establece que varios campos con varios registros, pueden tener asociados varios campos también con varios registros.
13
Desarrollo Los Datos para el desarrollo de los siguientes puntos se hicieron en base a la información previamente recolectada en análisis de la empresa. IDENTIFICACION DE ENTIDADES
Luego de realizar el análisis previo se determinan las siguientes entidades: •
•
•
•
•
•
Factura Productos Vendedor Bodeguero Repartidor Clientes
RELACION DE ENTIDADES
Identificamos como se relacionan las entidades. Factura
Emite
Describe
Recibe
Clientes
Vendedor
Solicita
Producto
Entrega
Prepara
Bodeguero
Repartidor
14
. Empresa
Contrata
Adquiere
Producto
Empleados Provee Recibe
Proveedor
Rol Pago
Luego de haber llevado a cabo la relación entre entidades esto nos dará la pauta para definir las tablas que usaremos así como de qué campos serán los que esa tabla contenga. Por ejemplo: Identificamos la tabla cliente, y sus campos nombre, apellido, tipo, dirección, teléfono, cedula, Ruc, etc.…. Luego procedemos a realizar la normalización, respectiva que sea necesaria para cada tabla.
15
NORMALIZACION Primera Formal Normal
Buscamos los campos multivaluados, y hacemos un campo para c/uno. Factura Numero Fecha Cliente RUC/CI Codigo Direccion Telefono Vendedor producto1 producto2 Cantidad1 V.Unitario V. Total2 Subtotal Iva Descuent Total a Pagar
1 12/12/2020 juan 0104900881 c001 Bolivar 809090 pedro prod1 prod2 1 5 10 13 1,56 0 14,56
Emplados
Cedula Nombre Apellido Direccion Telefono1 Telefono2 genero Fecha_nacim estado civil Fecha_ingres Cargo1 Cargo2 Sueldo Horario1 Horario2
0104900881 Luis perez Luis Cordero 2809090 096398610 masculino 15/05/1980 soltero 12/11/2009 vendedor cajero 250 7:00- 11:30 15:00-23:00
Productos
Codigo Nombre Descripcion Existencia fech_ingreso fech_elaborado fech_expedicion Presentacion1 Presentacion2 Precio Compra Precio Venta Proveedor
p001 fideo fideo Vittorio 400 03-may-09 24-abr-09 05-jul-09 500grs. 200grs. 0, 5 0,75 Azuero Aso.
Clientes
Codigo Cedul edula/ a/Ru Rucc Nombre Apellido Diereccion Telefono1 Telefono2 Genero Tipo
C001 0104 010490 9008 0881 81 juan Lopez G. Colombi mbia 808070 096398610 masculino minorista
16
Proveedpr
RUC Nombre Contacto Direccion Telefono1 Telefono2 Fax1 Fax2 E-mail1 E-mail2 Producto_distr marca_product
1658974035698 Azuero Aso Rafael Cuesta Octavio Chacon 808070 096398610
[email protected] [email protected] Fideo Vittorio
Segunda Formal Normal Los campos multivaluados deben separarse en tablas y relacionarse con la clave principal Factura 1 Numero_fact 12/12/2020 Fecha juan Cliente 0104900881 RUC/CI c001 Codigo Bolivar Direccion 809090 Telefono pedro Vendedor 1 Cantidad1 5 V.Unitario 10 V. Total2 13 Subtotal 1,56 Iva 0 Descuent 14,56 Total a Pagar
Producto_Factura numero_Fact nom_product fideo
1
17
Empleados
Cedula Nombre Apellido Direccion Telefono Celular genero Fecha echa_n _nac aciim estado civil Fech Fecha_ a_in ingr gres es Sueldo
0104900881 Luis perez Luis Co Cordero 2809090 096398610 masculino 15/ 15/05/1 05/198 980 0 soltero 12/1 12/11/ 1/20 2009 09 250
Cargos_Empleados Cedula Cargo
010265814 vendedor
010265814 cajero
Horarios_Empleados Cedula horario
010265814 010265814 7:00 7:00 - 11:3 11:30 0 15:0 15:00 0 - 23:0 23:00 0
Productos
Cod Codigo igo_pro _prod d p001 p001 Nombre fideo Desc Descri ripc pciion fid fideo Vitt Vittor orio io Existencia 400 fech_ingreso 03-may-09 fech_elaborad 24-abr-09 fech_expedici 05-jul-09 Precio Compr 0, 5 Precio Venta 0,75 Proveedor Azuero Aso.
Presentacion_Productos codigo_prod p001 presentacion 200grs.
Cliente
Codigo Ced Cedula/ la/Ruc Ruc Nombre Apellido Die Diereccion Telefono Celular Genero Tipo
C001 0104 010490 9008 0881 81 juan Lopez G. Colombia 808070 096398610 masculino minorista
Proveedor RUC 1658974035698 Nombre Azuero Aso Cont Contac acto to Rafa Rafael el Cues Cuesta ta Dire Direcc ccio ion n Octa Octavio vio Chac Chacon on Telefono 808070 Celular 096398610 Producto_dist Fideo marca_produ Vittorio
RUC Fax
RUC e-mail
FAX_Proveedor 1658974035698
E-MAIL_Proveedor 1658974035698
[email protected]
18
No fue necesario separar los teléfonos en una tabla, solo se separo en dos campos y los renombremos teléfono (fijo) y celular (móvil)
Tercera Forma Normal Eliminar los datos no dependientes de la clave Factura Numero_fact Cliente RUC/CI Codigo Direccion Telefono Vendedor Cantidad1 V.Unitario V. Total2 Subtotal Total a Pagar
1
juan 0104900881 c001 Bolivar 809090 pedro 1 5 10 13 14,56
Empleados Cedula 0104900881 Nombre Luis Apellido perez Dire Direcc ccio ion n Luis Luis Cord Corder ero o Telefono
nom_product
1
fideo
Fecha_Factura codigo_fecha I001 fecha
12-may-09
Impuestos_Factura codigo_impuesto Im001 valor
1,56
Descuentos_Factura codigo_descuento dsc001 0 0,00
Cargos_empleados Carg001 Carg002 Codigo_cargos vend vended edor or caje cajero ro Cargo
2809090
Celular
096398610
genero
masculino
Fecha_ Fecha_nac nacim im
Producto_Factura numero_Fact
15/05/ 15/05/198 1980 0
estad estado o civi civill solter soltero o Fecha_ Fecha_ing ingres res 12/11/ 12/11/200 2009 9 Cod_Cargos
250
Cod_Horarios
250
Cod_sueldo
250
Horarios_Empleados hor001 hor002 Codigo_horario 7:00 - 11:30 15:00 - 23:00 horario Sueldo_Empleados hor001 hor002 Codigo_horario 250 300 Monto bode bodegu guer ero o vand vanded edor or Descrip
19
Productos Codigo_prod p001 Nombre fideo Desc Descri ripc pcio ion n fideo ideo Vitto ittori rio o Existencia 400 fech_ingreso 03-may-09 fec fech_elaborad rado 24-abr-0 r-09 fec fech_expedicion ion 05-juljul-0 09 Precio Compra 0,5 Precio Venta 0,75 Proveedor Azuero Aso. codi codigo go_p _pre rese sent nt p001 p001 codi codigo go_i _ing ngre reso so I001 I001
Presentacion_Productos codigo_pres p001 presentacion 200grs. Fech_Ingre_Productos codigo_ingre I001 12-may-09 fecha
Proveedores
FAX_Proveedor
1658974035698 Azuero Aso Rafael Cuesta Octavio Chacon 808070 096398610 Fideo Vittorio p_dist001
RUC Nombre Contacto Direccion Telefono Celular Producto_distr marca_product cod_prod
1658974035698
RUC Fax
E-MAIL_Proveedor
1658974035698
[email protected]
RUC e-mail
Producto_distr_Provedor cod_prod p_dist001 descripcion fideo
Cuarta Forma Normal No todas todas las tablas llegan a estas instancias o a otras primera o segunda. FACTURA_Maestro Numero_fact codigo_fecha clien_codig prod_cod codigo_impuest codigo_desc Subtotal Total a Pagar
posteriores, algunas pueden solo llegar a la
FACTURA_Cliente 1
juan 1
clien_codig RUC/CI Cliente Telefono
FACTURA_Detalle 1 1 5
Numero_fact Cantidad juan V.Unitario V.total
1 1 5
5 dsc001 13 14,56
Producto_Factura prod_cod nom_product fideo
1
Fecha_Factura codigo_fecha I001 fecha 12-may-09
Impuestos_Factura codigo_impu Im001 valor
1,56
Descuentos_Factura codigo_descu dsc001 0 0,00
20
DESCRIPCION DE TABLAS
CONSTRAINS, TIPOS DATOS, LONGITUD Luego de llevar a cabo la normalización ya tenemos definida la estructura de las mismas, el siguiente paso será definir qué tipo de dato será el que se gurda en sus campos, y cuanto se guardara, así también si algún campo servirá de enlace con otra tabla es decir si es clave Factura_maestro constrain
campo
NN FK
codigo_fecha char numero factura int codigo_prod char codigo_impuesto char codigo_descuent char cliente_codig char subtotal real Total a Pagar real cedula_empleado char estado char
PK NN
NN FK NN FK NN FK NN FK NN NN NN FK NN
tipo datos
longitud
4 4 4 4 4 4 (5,2) (5,2) 10 8
Factura_impuesto
valor
real
constrain campo PK NN
NN FK NN FK NN FK NN FK
tipo da datos l on ongitud
numero factu int cantidad int v.unitario real v. totalñ real codigo_produ char
4 3 (5,2) (5,2) 4
Factura_descuento constrain campo tipo datos longitud
constrain campo tipo datos longitud codigo_impu ch c har 4 PK NN
NN FK
Factura_Detalle
PK NN NN FK
2
codigo_descuento valor
char real
4 2
Factura_cliente
constrain PK NN FK
campo tipo datos cliente_codig char RUC/CI char
longitud 4 13
EMPLEADOS
cliente constrain PK NN
FK NN NN FK
NN
campo
tipo datos
cliente_codig RUC/CI nombre apellido Dierccion telefono celular genero tipo
char char char char char char char char char
longitud
4 13 25 25 50 9 9 7 8
constrain PK NN NN NN NN FK NN NN
campo cedula_empleado nombre apellido direccion telefono ce celular
tipo datos longitu itud 10 char 30 char 30 char 50 char 9 char 9
NN NN
genero fecha_nacim
char date
NN
estado_civil
date
NN
fecha_ingreso
date
7
Empleados_cargo
Empleados_sueldo tipo datos
char
constrain
campo
longitud
NN
cedula_emple char
10
PK NN
codigo_sueld char
4
constrain campo tipo datos longitud cedula_emple char 10 NN
PK NN
codigo_cargo ch char
4
21
sueldos
Empleados_horarios constrain
campo
tipo datos
longitud
NN
cedula_emple char
10
PK NN
codigo_horari char
4
constrain
campo
PK NN
codigo_sueld ch char descripcion char sueldo real
NN
campo
PK NN
codigo_horari char
NN
horario
longitud
10 25 (5,2)
cargos
horarios constrain
tipo da datos
tipo datos
lon longitud
constrain campo 4
char
PK NN
NN
13
codigo_cargo cargo
tipo da datos longitud
char char
4 15
Productos
constrain campo PK NN codigo_producto FK nombre NN descripcion NN FK existencia NN fecha_ingreso NN fecha_elaborado NN fecha_expedici icion NN precio_compra NN precio_venta NN RUC_proveedor codigo_presentaci
tipo datos tos lon longitu itud char 4 Proveedor char 20 constrain campo tipo datos longitud char 60 PK NN Nombre char 30 char 25 FK Contacto char 60 date NN Diereccion char 50 date NN FK Telefono char 9 date Celular char 9 real (5,2) NN RUC_proveed char 13 real (5,2) NN cod_fax char 4 char 13 NN cod_e-mail char 4 char 4 NN
FAX_Proveedor cons constra train in camp campo o tipo tipo datos datos longit longitud ud
Productos_presentacion constra strain in
campo
tipo datos
longitu itud
NN
presentacion char
25
PK NN
codigo_prese char
4
PK NN
fax
char
9
cod_fax
char
4
E-mail_Proveedor
constrain PK NN
campo e-mail cod_e-mail
tipo datos char char
longitud 30 4
22
Modelo Relacional
23
CONCLUSIONES Luego del desarrollo de este proyecto, y según los datos adquiridos y a la práctica realizada hemos llegado a la siguiente conclusión:
“El desarrollo de una buena Base de Datos, depende netamente de cómo esta se diseñe, para lo cual tenemos que seguir los pasos esenciales que se nos presentan ya que lo demás dependerá del tipo de Base de datos, o para que se aplicara la Base de Datos, pero al seguir los pasos podremos mejorar la estabilidad y rapidez de consulta de la Base de Datos, pero también esto dependerá del motor de la Base de Datos”
24
Recomendaciones Después de desarrollar el presente documento y de haber experimentado el diseño de base de datos podemos dar la siguiente recomendación:
Que para el desarrollo de la Base de Datos se vaya trabajando paulatinamente con datos y ejemplos reales ya que lo cual nos dará una visión mejor para la toma de decisiones decisiones y saber si es es oportuno aplicar algún método. método.
25
GLOSARIO •
Regla = tabla o archivo
•
Tupla = registro, fila o renglón
•
Atributo = columna o campo
•
Clave = llave o código de identificación
•
Clave Candidata = superclave mínima
•
Clave Primaria = clave candidata elegida
•
Clave Ajena = clave externa o clave foránea
•
Clave Alternativa = clave secundaria
•
Dependencia Multivaluada = dependencia multivalor
•
RDBMS = Del inglés Relational Data Base Manager System que significa, Sistema
Gestor de Bases de Datos Relacionales. •
1FN = Significa, Primera Forma Normal o 1NF del inglés First Normal Form.
•
DBMS: Data Base Management System (SISTEMA DE MANEJO DE BASE DE DATOS).-
Consiste de una base de datos y un conjunto de aplicaciones (programas) para tener acceso a ellos. •
Modelo de Datos.- es un conjunto de herramientas conceptuales para describir los
datos, las relaciones entre ellos, su semántica y sus limitantes. •
presenta cuando se repiten innecesariamente datos en los Redundancia.- Esta se presenta archivos que conforman la base de datos. d atos.
•
Inconsistencia.- Ocurre cuando existe información contradictoria o incongruente
en la base de datos.
26
BIBLIOGRAFIA
Datos tomados y referencias de:
http://es.wikipedia.org/w/index.php?oldid=26829246 www.3.uji.es/~mmarques/f47/apun/node68.html.. www.3.uji.es/~mmarques/f47/apun/node68.html http://www.itlp.edu.mx/publica/tutoriales/basedat2/ http:/ /www.scourdesign.com/artic /www.scourdesign.com/articulos/BD-FN.Php ulos/BD-FN.Php http://www.ur.mx/ur/faciya/carreras/cursos/sis/mod-dat1/graph.HTM www.yudy.8m.com/Sistemasmanejador.htm
27
Capturas de diseñador y base de datos en Access, SQL
Diseñador CASE STUDIO
Implantado en Access
28
Implantado en SQL
29
