DIRECCIN ACADMICA

Formato de entrega de evidencias

FO-205P11000-14
Divisin:

Ingeniera en Tecnologas de la Informacin y Comunicaciones

(1)

Asignatura: (3)

Fundamentos de Base de Datos

Nombre y nmero de control:

Docente:

(4)

Chimal Hernndez Israel

Grupo:

1031-V

153110080

Gmez Hernndez Brayan Israel 153110085

(5)

Vargas Esquibel Jonathan Israel

Fecha de entrega:

(2)

Luzma lvarez Monroy

Guerra Ramrez Donoban Gustavo

14/10/2016

(6)

Competencia No.:

Descripcin:

(8)

DISEO DE BASE DE DATOS Y EL MODELO E-R

(7)

Indicador de alcance:

(9)

Evidencia de aprendizaje:

Temario

(10)

DISEO DE BASE DE DATOS Y EL MODELO E-R

2.1 EL PROCESO DE DISEO
El proceso de diseo de una base de datos se gua por algunos principios. El primero de ellos es que se
debe evitar la informacin duplicada o, lo que es lo mismo, los datos redundantes, porque malgastan el
espacio y aumentan la probabilidad de que se produzcan errores e incoherencias. El segundo principio es
que es importante que la informacin sea correcta y completa. Si la base de datos contiene informacin
incorrecta, los informes que recogen informacin de la base de datos contendrn tambin informacin
incorrecta y, por tanto, las decisiones que tome a partir de esos informes estarn mal fundamentadas.
Un buen diseo de base de datos es, por tanto, aqul que:
Divide la informacin en tablas basadas en temas para reducir los datos redundantes.
Proporciona a Access la informacin necesaria para reunir la informacin de las tablas cuando as se
precise.
Ayuda a garantizar la exactitud e integridad de la informacin.
Satisface las necesidades de procesamiento de los datos y de generacin de informes.
El proceso de diseo consta de los pasos siguientes:
Determinar la finalidad de la base de datos
Esto le ayudar a estar preparado para los dems pasos.

 Buscar y organizar la informacin necesaria

Rena todos los tipos de informacin que desee registrar en la base de datos, como los nombres de
productos o los nmeros de pedidos.

Dividir la informacin en tablas

Divida los elementos de informacin en entidades o temas principales, como Productos o Pedidos. Cada
tema pasar a ser una tabla.
Convertir los elementos de informacin en columnas
Decida qu informacin desea almacenar en cada tabla. Cada elemento se convertir en un campo y se
mostrar como una columna en la tabla. Por ejemplo, una tabla Empleados podra incluir campos como
Apellido y Fecha de contratacin.
Especificar claves principales
Elija la clave principal de cada tabla. La clave principal es una columna que se utiliza para identificar
inequvocamente cada fila, como Id. De producto o Id. De pedido.
Definir relaciones entre las tablas
Examine cada tabla y decida cmo se relacionan los datos de una tabla con las dems tablas. Agregue
campos a las tablas o cree nuevas tablas para clarificar las relaciones segn sea necesario.
Ajustar el diseo
Analice el diseo para detectar errores. Cree las tablas y agregue algunos registros con datos de ejemplo.
Compruebe si puede obtener los resultados previstos de las tablas.
Realice los ajustes necesarios en el diseo.
Aplicar las reglas de normalizacin
Aplique reglas de normalizacin de los datos para comprobar si las tablas estn estructuradas
correctamente. Realice los ajustes necesarios en las tablas.

2.2 EL MODELO DE DATOS ENTIDAD-RELACION (E/R)

Cuando se utiliza una base de datos para gestionar informacin, se est plasmando una parte del mundo
real en una serie de tablas, registros y campos ubicados en un ordenador; crendose un modelo parcial de
la realidad. Antes de crear fsicamente estas tablas en el ordenador se debe realizar un modelo de datos.
Se suele cometer el error de ir creando nuevas tablas a medida que se van necesitando, haciendo as el
modelo de datos y la construccin fsica de las tablas simultneamente. El resultado de esto acaba siendo
un sistema de informacin parcheado, con datos dispersos que terminan por no cumplir adecuadamente
los requisitos necesarios.
Entidades y Relaciones
El modelo de datos ms extendido es el denominado ENTIDAD/RELACIN (E/R) En el modelo
E/R se parte de una situacin real a partir de la cual se definen entidades y relaciones entre dichas
entidades:
Entidad. Objeto del mundo real sobre el que queremos almacenar informacin (Ejemplo: una persona).
Las entidades estn compuestas de atributos que son los datos que definen el objeto (para la entidad
persona seran DNI, nombre, apellidos, direccin,...).
De entre los atributos habr uno o un conjunto de ellos que no se repite; a este atributo o conjunto de
atributos se le llama clave de la entidad, (para la entidad persona una clave seria DNI). En toda entidad
siempre hay al menos una clave que en el peor de los casos estar formada por todos los atributos de la
tabla. Ya que puede haber varias claves y necesitamos elegir una, lo haremos atendiendo a estas normas:
Que sea nica.

Que se tenga pleno conocimiento de ella. Por qu en las empresas se asigna a cada cliente un
nmero de cliente?
Que sea mnima, ya que ser muy utilizada por el gestor de base de datos.
Relacin. Asociacin entre entidades, sin existencia propia en el mundo real que estamos modelando,
pero necesaria para reflejar las interacciones existentes entre entidades. Las relaciones pueden ser de tres
tipos:
Relaciones 1-1. Las entidades que intervienen en la relacin se asocian una a una (Ejemplo: la entidad
HOMBRE, la entidad MUJER y entre ellos la relacin MATRIMONIO).
Relaciones 1-n. Una ocurrencia de una entidad est asociada con muchas (n) de otra (Ejemplo: la entidad
EMPERSA, la entidad TRABAJADOR y entre ellos la relacin TRABAJAR-EN).

Relaciones n-n. Cada ocurrencia, en cualquiera de las dos entidades de la relacin, puede estar asociada
con muchas (n) de la otra y viceversa (Ejemplo: la entidad ALUMNO, la entidad EMPRESA y entre ellos la
relacin MATRCULA).
Representacin grfica de Entidades y Relaciones
Para asimilar fcilmente un diseo de datos cuando se emplea el modelo E/R se utilizan los siguientes
elementos grficos:
2.3 RESTRICCIONES
Restricciones de llave
1. Relacin trabaja en
Un empleado trabaja en un departamento
Un departamento puede tener varios empleados
Sin embargo cada departamento puede tener a lo ms un jefe por la restriccin de llave de la relacin
administrativa.
Restricciones estructurales
Es una notacin alternativa a las restricciones de llave (cardinalidad) que incluye un par de nmeros
enteros (mnimo - mximo) a cada participacin.
Restricciones de participacin
La existencia de una entidad depende de que est relacionado con otra entidad a travs de un tipo de
vnculo.
2.4 LOS DIAGRAMAS E-R
Los diagramas E-R constituyen la representacin grfica de las clases entidad y las clases de asociacin
necesarias para construir el modelo de datos asociado a las situaciones del mundo real que se quiere
representar en la base de datos a disear.
El proceso para construir un modelo E-R y representarlo a travs del diagrama E-R es un proceso iterativo
ms que un proceso secuencial. A partir de una situacin del mundo real los pasos a seguir son:
1. Identificar las clases de entidad relevantes para el modelo, buscando en la situacin planteada entes
con caractersticas propias
2. Describir claramente lo que representa cada clase entidad
3. Identificar para cada clase entidad los atributos pertinentes
4. Identificar las relaciones jerrquicas (supertipo-subtipos) existentes entre las clase entidad
5. Identificar las clases relaciones asociativas existentes entre las clases entidad

6. Describir claramente lo que representa cada clase asociacin

7. Definir la cardinalidad mnima y mxima de la clase relacin
8. Interactuar con el usuario, y repetir iterativamente los pasos anteriores hasta considerar completo el
modelo
2.6 CONJUNTO DE ENTIDADES DEBILES
Una entidad es identificada nicamente por medio de su llave ms la llave de la entidad padre
Un conjunto de entidades padres y entidades dbiles deben participar en una relacin uno a muchos (un
padre, muchas entidades dbiles)
Un conjunto de entidades dbiles debe tener participacin total en estos conjuntos de relaciones
identificadores (o propietarios)
Se denomina relacin identificadora a la relacin de un tipo de entidad dbil con su propietario

2.7 MODELO ENTIDAD-RELACION EXTENDIDO

Los diagramas Entidad-Relacin no cumplen su propsito con eficacia debido a que tienen limitaciones
semnticas. Por ese motivo se suelen utilizar los diagramas
Entidad-Relacin extendidos que incorporan algunos elementos ms al lenguaje:
Cuando una entidad participa en una relacin puede adquirir un papel fuerte o dbil.
Una entidad dbil es aquella que no puede existir sin participar en la relacin; es decir, aquella que no
puede ser unvocamente identificada solamente por sus atributos.
Una entidad fuerte (tambin conocida como entidad regular) es aquella que s puede ser identificada
unvocamente. En los casos en que se requiera, se puede dar que una entidad fuerte "preste" algunos de
sus atributos a una entidad dbil para que esta ltima se pueda identificar.
Las entidades dbiles se representan mediante un doble rectngulo; es decir, un rectngulo con doble
lnea. Se puede hablar de la existencia de 2 tipos de dependencias en las entidades dbiles:
Dependencia por existencia.
Las ocurrencias de la entidad dbil pueden identificarse mediante un atributo identificador clave sin
necesidad de identificar la entidad fuerte relacionada.
Dependencia por identificacin.
La entidad dbil no puede ser identificada sin la entidad fuerte relacionada. (Ejemplo: si tenemos una
entidad LIBRO y otra relacionada EDICIN, para identificar una edicin necesitamos conocer el
identificador del libro).
El tipo de cardinalidad se representa mediante una etiqueta en el exterior de la relacin, respectivamente:
"1:1", "1:N" y "N:M", aunque la notacin depende del lenguaje utilizado, la que ms se usa actualmente es
el unificado. Otra forma de expresar la cardinalidad es situando un smbolo cerca de la lnea que conecta
una entidad con una relacin:
"0" si cada instancia de la entidad no est obligada a participar en la relacin.

"1" si toda instancia de la entidad est obligada a participar en la relacin y, adems, solamente participa
una vez.
"N", "M", o "*" si cada instancia de la entidad no est obligada a participar en la relacin y puede hacerlo
cualquier nmero de veces.
Ejemplos de relaciones que expresan cardinalidad:
Cada esposo (entidad) est casado (relacin) con una nica esposa (entidad) y viceversa. Es una relacin
1:1.
Una factura (entidad) se emite (relacin) a una persona (entidad) y slo una, pero una persona puede
tener varias facturas emitidas a su nombre. Todas las facturas se emiten a nombre de alguien. Es una
relacin 1:N.
Un cliente (entidad) puede comprar (relacin) varios servicios (entidad) y un servicio puede ser comprado
por varios clientes distintos. Es una relacin N:M.
Las relaciones tambin pueden tener atributos asociados. Se representan igual que los atributos de las
entidades. Un ejemplo tpico son las relaciones de tipo "histrico" donde debe constar una fecha o una
hora. Por ejemplo, supongamos que es necesario hacer constar la fecha de emisin de una factura a un
cliente, y que es posible emitir duplicados de la factura (con distinta fecha). En tal caso, el atributo "Fecha
de emisin" de la factura debera colocarse en la relacin "se emite".

Herencia
Cardinalidad de las relaciones
Atributos en relaciones

La herencia es un intento de adaptacin de estos diagramas al paradigma orientado a objetos. La herencia

es un tipo de relacin entre una entidad "padre" y una entidad "hijo".
La entidad "hijo" hereda todos los atributos y relaciones de la entidad "padre". Por tanto, no necesitan ser
representadas dos veces en el diagrama. La relacin de herencia se representa mediante un tringulo
interconectado por lneas a las entidades. La entidad conectada por el vrtice superior del tringulo es la
entidad "padre". Solamente puede existir una entidad "padre" (herencia simple). Las entidades "hijo" se
conectan por la base del tringulo.
Es una abstraccin a travs de la cual las relaciones se tratan como entidades de un nivel ms alto. Se
utiliza para expresar relaciones entre relaciones o entre entidades y relaciones. Se representa englobando
la relacin abstrada y las entidades que participan en ella en un rectngulo. En la figura se muestra un
ejemplo de agregacin en el que se representa la situacin en la que un profesor, cuando est impartiendo
una clase, puede poner una incidencia ocurrida a lo largo de sta (se fue la luz, falta la configuracin de un
determinado software, etc.).
LA UML
UML es un lenguaje para especificar, construir, visualizar y documentar los artefactos de un sistema de
software orientado a objetos (OO). Un artefacto es una informacin que es utilizada o producida mediante
un proceso de desarrollo de software.
UML se quiere convertir en un lenguaje estndar con el que sea posible modelar todos los componentes
del proceso de desarrollo de aplicaciones. Sin embargo, hay que tener en cuenta un aspecto importante
del modelo: no pretende definir un modelo estndar de desarrollo, sino nicamente un lenguaje de
modelado. Otros mtodos de modelaje como OMT (Object Modeling Technique) o Booch s definen procesos
concretos. En UML los procesos de desarrollo son diferentes segn los distintos dominios de trabajo; no
puede ser el mismo el proceso para crear una aplicacin en tiempo real, que el proceso de desarrollo de
una aplicacin orientada a gestin, por poner un ejemplo.

Las diferencias son muy marcadas y afectan a todas las fases del proceso. El mtodo del
UML recomienda utilizar los procesos que otras metodologas tienen definidos.