FASE 2

TRABAJO COLABORATIVO 2

DIEGO FERNANDO GONZALEZ COD: 94325163

RICARDO SUAREZ GALVIS COD: 1113676160

FLOWER ANDRES PENAGOS PORTILLA: 1085317313

Curso:

BASES DE DATOS BASICO

Grupo: 36

Tutor:

IVAN VELOZA

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA

ESCUELA DE CIENCIAS BÁSICAS, TECNOLOGÍA E INGENIERÍA

PROGRAMA DE INGENIERÍA DE SISTEMAS

2018-II
 TABLA DE CONTENIDO

1. OBJETIVOS.

2. TABLA CON ENLACES GOOGLE DRIVE.

3. INTRODUCCIÓN.

4. DESARROLLO ACTIVIDAD

5. CONCLUSIONES

6. BIBLIOGRAFIA
 1. OBJETIVOS

-Reconocer el esquema lógico como fuente de información para el diseño físico.

-Reconocer que es el diseño lógico y cuál es su inferencia en el proceso de

construcción de esquemas de información.
-Reconocer que es el diseño físico y cuál es su proceso en la implementación de la
base de datos.

-Reconocer cual es el propósito del diseño físico.

 2. TABLA CON LOS ENLACES A GOOGLE DRIVE DE CADA INTEGRANTE.

Estudiante
Enlace (Bitácora individual)
Diego Fernando
González https://drive.google.com/open?id=1Sv4chJbdSf8AtLJkU4aOsWC-p4RRBBQ0

FLOWER ANDRES
PENAGOS https://drive.google.com/file/d/1oWLP_OOuEIgF3ualBcho8U2ba8dQuGTS/view?usp=shari
ng

RICARDO SUAREZ https://drive.google.com/folderview?id=19NuKc_QkyZHDuvGXgpNMA1z5e9WNPpzL

 3. INTRODUCCION

El diseño de una Base de Datos es un proceso complejo que abarca decisiones

a muy distintos niveles. La complejidad se controla mejor si se descompone el
problema en subproblemas y se resuelve cada uno de estos. Por medio de esta
actividad aprenderemos a validar el tipo de información que se quiere almacenar
en ella, teniendo en cuenta la que está disponible y la que se va a necesitar. La
información a incorporar a una BD se obtiene durante las distintas etapas de
diseño de la misma.
 4. DESARROLLO ACTIVIDAD

a. Resultado de la transformación del Modelo Entidad Relación a la primera

versión del Modelo Relacional (Modelo Lógico) siguiendo las siguientes
indicaciones:
Descripción del proceso: Se trata de una base de datos con la información de
los empleados, cargos y departamentos de una empresa donde se concentra la
información personal de cada uno de ellos; recibiremos y almacenaremos
identificación, nombre, segundo nombre, primer apellido, segundo apellido,
fecha nacimiento, fecha ingreso, salario, estado civil, sexo, correo, nombre
cargo, identificación cargo, nombre departamento identificación del
departamento.

1. Transforme entidades en tablas

Tenemos 3 conjuntos de entidades: Empleados, Departamentos y Cargos.

2. Transforme atributos en columnas

Tenemos para la entidad Empleados la almacenaremos identificación, nombre,
segundo nombre, primer apellido, segundo apellido, fecha nacimiento, fecha
ingreso, salario, estado civil, sexo, correo.
Para el caso de Departamentos serian nombre departamento identificación del
departamento y con la entidad Cargo tenemos nombre cargo, identificación
cargo.
Modelo entidad- relación Modelo relacional
entidad tabla
atributo columna
Único Identificador Clave primaria
Relación 1:m Esta llave es única y la cual a ir insertada en
otras tablas
Relación M:M Se hace la realización de la tabla con su llave
y esta estará unida a otra tabla ya creada.
Relación 1:1 Esta llave va hacer ingresada a otra tabla
Generalización: La llave pasara a otras tablas.

3. Agregar a cada tabla un identificador único (UID) o primary key.

Clave primaria (primary key): Hace que los atributos marcados como clave
primaria no puedan repetir valores. Además obliga a que esos atributos no
puedan estar vacíos. Si la clave primaria la forman varios atributos, ninguno de
ellos podrá estar vacío. En este caso tenemos id empleados en la Tabla
Empleados, id cargo en la Tabla Cargo e id departamentos en la Tabla
departamentos.

4. Transforme las relaciones 1:1 o 1: m en llaves foráneas, implementando el

concepto de la integridad referencial.
Integridad referencial (foreign key): significa que la clave externa de una tabla de
referencia siempre debe aludir a una fila válida de la tabla a la que se haga
referencia. La integridad referencial garantiza que la relación entre dos tablas
permanezca sincronizada durante las operaciones de actualización y
eliminación.
Relacion1: Esta relación modela un hecho importante que sucede en el proceso
que estamos analizando y es que un empleado puede dirigir a otros empleados
y que los empleados de la organización pueden ser dirigidos por otro empleado.
- Las relaciones reflexivas o recursivas se tratan de la misma forma que las otras,
sólo que un mismo atributo puede figurar dos veces en una tabla como resultado
de la transformación.

1 a-Muchos (1: N) -1ra llave foránea

Relacion2: Esta relación modela que un empleado trabaja en un departamento

de la organización y que un departamento de la compañía puede ser ocupado
por muchos empleados.

1 a –Muchos (1: N) -2da llave foránea

Relacion3: modela que un Empleado puede dirigir muchos Departamentos de

la organización y que los Departamentos pueden ser dirigidos por un empleado.

1 a –Muchos (1: N) – 3ra llave foránea

Relacion4: modela que un Empleado puede Ocupar un Cargo de la organización

y que un Cargo puede ser realizado por muchos Empleados.

1 a –Muchos (1: N) -4ta llave foránea

Modelo Entidad - Relación Modelo Relacional
Entidad Empleado

Atributo Empleado_ID, Nombres, Apellidos,

F_Nacimiento, F_Ingreso, Salario, Sexo.

Identificador único Empleado_ID

Relación 1:M Cargos;

Relación M:M N/A

Relación 1:1 Departamentos

Generalización/Especialización La llave primaria de la tabla dominante pasara

como llave foránea en las tablas dependientes

Modelo Entidad - Relación Modelo Relacional

Entidad Departamentos

Atributo Departamento_ID, Empleado_ID, Cargo_ID,

Nombre del departamento.

Identificador único Departamento_ID

Relación 1:M Empleados; cargos.

Relación M:M N/A

Relación 1:1 N/A

Generalización/Especialización La llave primaria de la tabla dominante pasara

como llave foránea en las tablas dependientes

Modelo Entidad - Relación Modelo Relacional

Entidad Cargos

Atributo Cargo_ID, Empleado_ID, Departamento_ID,

Nombre del cargo.

Identificador único Cargo_ID

Relación 1:M Empleados

Relación M:M N/A

Relación 1:1 Departamentos

Generalización/Especialización La llave primaria de la tabla dominante pasara

como llave foránea en las tablas dependientes
5. Aplicar técnicas de normalización.

La normalización es una técnica que busca dar eficiencia y fiabilidad a una BD

relacional. Su objetivo es, por un lado, llevar la información a una estructura
donde prime el aprovechamiento del espacio; y por otro lado, que el manejo de
información pueda llevarse a cabo de forma rápida.

Cuando realizamos el diseño en el modelo relacional existen diferentes

alternativas, pudiéndose obtener diferentes esquemas relacionales. No todos
ellos serán equivalentes y unos representarán mejor la información que otros.

Las tablas obtenidas pueden presentar problemas tales como:

-Redundancia. Se llama así a los datos que se repiten continua e

innecesariamente por las tablas de las bases de datos. Cuando es excesiva es
evidente que el diseño hay que revisarlo, es el primer síntoma de problemas y
se detecta fácilmente.

-Ambigüedades. Datos que no clarifican suficientemente el registro al que

representan. Los datos de cada registro podrían referirse a más de un registro o
incluso puede ser imposible saber a qué ejemplar exactamente se están
refiriendo.
-Pérdida de restricciones de integridad. Normalmente debido a dependencias
funcionales.
-Anomalías en operaciones de modificación de datos. El hecho de que al insertar
un solo elemento haya que repetir tuplas en una tabla para variar unos pocos
datos. O que eliminar un elemento suponga eliminar varias tuplas
necesariamente (por ejemplo que eliminar un empleado suponga borrar seis o
siete filas de la tabla de empleados, sería un error muy grave y por lo tanto un
mal diseño).
 FORMAS NORMALES

-La normalización nos permite eliminar estos problemas, forzando a la división

de una tabla en dos o más.

-Las formas normales se corresponden a una teoría de normalización iniciada

por Edgar F. Codd y continuada por otros autores (entre los que destacan Boyce
y Fagin). Codd definió en 1970 la primera forma normal. Desde ese momento
aparecieron la segunda, tercera, la Boyce-Codd, la cuarta y la quinta forma
normal. En este documento sólo consideraremos las tres primeras formas
normales.
-Una tabla puede encontrarse en primera forma normal y no en segunda forma
normal, pero no al contrario. Es decir los números altos de formas normales son
más restrictivos.

Primera forma normal (1FN)

Es una forma normal inherente al esquema relacional, por lo que su

cumplimiento es obligatorio; es decir toda tabla realmente relacional la cumple.
Se dice que una tabla se encuentra en primera forma normal si

EMPLEADO

NOMBRE Departamento

Elías Informática

David Coordinación
Mantenimiento
Para resolver este problema simplemente se descomponen aquellas tuplas en los
que los atributos tienen más de un valor en tantas tuplas como valores haya, cada
una con un valor. La siguiente relación sí cumple la primera forma normal:

EMPLEADO

NOMBRE Departamento

Elías Informática

David Coordinación
David Mantenimiento
Segunda forma normal (2FN)

Ocurre si una tabla está en primera forma normal (1FN) y además cada atributo que
no sea clave, depende de forma funcional completa respecto de cualquiera de las
claves. Toda la clave principal debe hacer dependientes al resto de atributos, si hay
atributos que dependen sólo de parte de la clave, entonces esa parte de la clave y
esos atributos formarán otra tabla.

Empleado.
DNI CodCargo Nombre salario
31777999 34 Elías 10

31777999 25 Elías 9

31555222 34 Luisa 8

31456712 25 David 6

31456712 34 David 7
En este ejemplo suponiendo que el DNI y el código de cargo forman la clave
principal para esta tabla, sólo el salario tiene dependencia funcional completa. El
nombre depende de forma completa del DNI. La tabla no satisface la segunda forma
normal (no es 2FN). Para arreglarlo separamos la tabla en dos.

Empleado
DNI Nombre

31777999 Elías

31555222 Luisa

31456712 David

Cargo

DNI CodCargo salario

31777999 34 10

31777999 25 9
31555222 34 8

31456712 25 6

31456712 34 7
Tercera forma normal (3FN): Ocurre cuando una tabla está en segunda forma
normal (2FN) y además ningún atributo que no sea clave depende funcionalmente
de forma transitiva de la clave primaria. Ejemplo:

Empleado
DNI Nombre CodDepartamento Departamento

31777999 Elías 11 Cocina

31777111 Pepe 41 Servicio al cliente

31555222 Rosa 29 Mantenimiento

31717171 Juana 11 Coordinador

12002003 Manuela 08 Mensajería
-Observamos que Departamento depende funcionalmente del código de
Departamento, lo que hace que no esté en 3FN. El arreglo sería:

Empleado

DNI Nombre CodDepartamento

31777999 Elías 11

31777111 Pepe 41
31555222 Rosa 29

31717171 Juana 11

Departamento

CodDepartamento CodDepartamento
11 Cocina

29 Mantenimiento

08 Mensajería

41 Servicio al cliente
Diseño lógico
b.Después de aplicar las anteriores acciones sobre el Modelo Entidad Relación de
la etapa de análisis, debe obtener la Versión preliminar del Modelo Relacional
(Modelo Físico) con su respectivo diccionario de datos así:
1. Descripción de Tablas
2. Descripción de Columnas y las restricciones (Constraints)
3. Descripción de Llaves Foráneas
4. Diseño funcional del Modelo Entidad Relación en la herramienta Data Modeler.

Modelo físico
 DICCIONARIO

Design Name DiseñoBDB

Version Date 30.10.2018 10:16:14
Version Comment
Model Name Relational_1

Table Name CARGO

Functional Name CARGO
Abbreviation
Classification Type Name
Object Type Name
MV Prebuilt
MV Query

Description
Notes

Number Of Columns 3
Number Of Rows Min. 0
Number Of Rows Max. 9999999
Expected Number Of 0
Rows
Expected Growth 0
Growth Interval Year
 Columns

Formula
DT Domain
No Column Name PK FK M Data Type (Default Security Abbreviation
kind Name
Value)

1 id_cargo P Y NUMERIC (5) LT

2 nombre_cargo Y VARCHAR (30) LT

3 EMPLEADOS_id_empleado F Y VARCHAR (30 LT

CHAR)

Indexes
Sort
Index Name State Functional Spatial Expression Column Name
Order

CARGO_PK PK id_cargo ASC

Foreign Keys (referring to)

In Referred Delete
Name Refering To Mandatory Transferable Columns
Arc Columns Rule
CARGO_EMPLEADOS_FK EMPLEADOS Y Y EMPLEADOS_id_empleado id_empleado
 Table Name DEPARTAMENTOS
Functional Name DEPARTAMENTOS
Abbreviation
Classification Type Name
Object Type Name
MV Prebuilt
MV Query

Description
Notes

Number Of Columns 4
Number Of Rows Min. 0
Number Of Rows Max. 9999999
Expected Number Of 0
Rows
Expected Growth 0
Growth Interval Year

Columns
Formula
DT Domain
No Column Name PK FK M Data Type (Default Security Abbreviation
kind Name
Value)
1 id_departamento P Y NUMERIC (5) LT
2 nombre_departamento Y VARCHAR LT
(30)
3 EMPLEADOS_id_empleado F Y VARCHAR (30 LT
CHAR)

4 EMPLEADOS_id_empleado1 F Y VARCHAR (30 LT

CHAR)

Indexes
Sort
Index Name StateFunctional Spatial Expression Column Name
Order
DEPARTAMENTOS_PK PK id_departamento ASC
Foreign Keys (referring to)
In Delet
Mandat Transfera Referred
Name Refering To Ar Columns e
ory ble Columns
c Rule
DEPARTAMENTOS_EMPLEAD EMPLEAD Y Y EMPLEADOS_id_empl id_emple
OS_FK OS eado ado
DEPARTAMENTOS_EMPLEAD EMPLEAD Y Y EMPLEADOS_id_empl id_emple
OS_FKv2 OS eado1 ado

Table Name EMPLEADOS

Functional Name EMPLEADOS

Abbreviation

Classification Type
Name

Object Type Name

MV Prebuilt

MV Query

Description

Notes

Number Of Columns 12
Number Of Rows Min. 0
Number Of Rows Max. 9999999
Expected Number Of 0
Rows
Expected Growth 0
Growth Interval Year
Columns
Formula
DT Domain
No Column Name PK FK M Data Type (Default Security Abbreviation
kind Name
Value)
1 id_empleado P Y VARCHAR LT
(30 CHAR)

2 p_nombre Y VARCHAR LT
(30 CHAR)

3 s_nombre VARCHAR LT
(30 CHAR)

4 p_apellido Y VARCHAR LT
(30 CHAR)

5 s_apellido VARCHAR LT
6 estadoCivil Y VARCHAR LT
(10 CHAR)

7 fecha_nacimiento Y Date LT
8 fecha_ingreso Y Date LT
9 sexo Y VARCHAR LT
(30 CHAR)

10 salario Y NUMERIC LT
(5)
11 correo VARCHAR LT
(30 CHAR)

12 EMPLEADOS_id_empleado F Y VARCHAR LT
(30 CHAR)

Indexes
Sort
Index Name State FunctionalSpatial Expression Column Name
Order

EMPLEADOS_PK PK id_empleado ASC

Foreign Keys (referring to)

In Delet
Mandato Transferab Referred
Name Refering To Ar Columns e
ry le Columns
c Rule
EMPLEADOS_EMPLEADO EMPLEAD Y Y EMPLEADOS_id_empl id_emplea
S_FK OS eado do
Foreign Keys (referred from)

In Dele
Mandat Transfera Referred
Name Referred From Ar Columns te
ory ble Columns
c Rule

CARGO_EMPLEADOS_FK CARGO Y Y EMPLEADOS_id_em id_emple

pleado ado

DEPARTAMENTOS_EMPLEA DEPARTAME Y Y EMPLEADOS_id_em id_emple

DOS_FK NTOS pleado ado

DEPARTAMENTOS_EMPLEA DEPARTAME Y Y EMPLEADOS_id_em id_emple

DOS_FKv2 NTOS pleado1 ado

EMPLEADOS_EMPLEADOS_F EMPLEADOS Y Y EMPLEADOS_id_em id_emple

K pleado ado
 5. CONCLUSIONES

-El esquema lógico es una fuente de información para el diseño físico.

-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 conceptual de base de datos específico.

-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.

-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
 6. BIBLIOGRAFIA

Modelado Relacional y Normalización

Sosa Flores, M. & López Vázquez, M. (2007) Diseño de bases de datos relacionales.
Córdoba, AR: El Cid Editor. Pág. 20-85. Recuperado de:
http://bibliotecavirtual.unad.edu.co:2460/lib/unadsp/detail.action?docID=3175111&
query=Dise%C3%B1o%20de%20bases%20de%20datos%20relacionales.

Chicano, Tejada, Ester. Utilización de las bases de datos relacionales en el sistema

de gestión y almacenamiento de datos: UF0348, IC Editorial, 2013. ProQuest Ebook
Central, pág. 87-110. Recuperado de:
https://bibliotecavirtual.unad.edu.co:2538/lib/unadsp/reader.action?ppg=