Trabajo practico - Base de Datos (311) - UNA

UNIVERSIDAD NACIONAL ABIERTA
VICERRECTORADO ACADÉMICO
ÁREA: INGENIERÍA
TRABAJO PRÁCTICO
ASIGNATURA: BASE DE DATOS (311)
ALUMNO: MEDINA RONALD
CÉDULA DE IDENTIDAD: V-16.291.029
EMAIL DEL ESTUDIANTE: alexchelsea222@gmail.com
TELÉFONO: 0412-1300161
CENTRO LOCAL: CARABOBO
CARRERA: INGENIERÍA DE SISITEMAS (236)
ASESOR: ING. ISBELIA MEDINA
LAPSO: 2018-1 (DICIEMBRE 2018)
RESULTADOS DE CORRECCIÓN:

Tabla de contenido
Introducción…………………………………………………………………….Pagina 3
Planteamiento….……………………………………………………………….Pagina 4
Objetivo 5…………………………………………………………………………Página 5
Objetivo 6…………………………………………………………………………Página 9
Objetivo 7……………………………………………………………………….Pagina 11
Objetivo 8……………………………………………………………………….Pagina 18

Introducción
La inmensa cantidad de información que las organizaciones tienen que manejar
hoy en día, nos obligan encontrar camino que permita su procesamiento,
resguardo, y consulta de la información.
La bases de datos se define como un conjunto de datos almacenados, con un
nivel de redundancia controlada, interrelacionados y estructurados de acuerdo a
un modelo capaz de recoger el máximo contenido semántico. Las base de datos
se han se han convertido en un elemento imprescindible en la vida cotidiana de la
sociedad moderna.
Las personas cada vez más necesitan algún tipo de interacción con una base de
datos, los datos por si solos por lo general no dicen mucho, pero en conjunto
pueden suministrar información relevante para toma de decisiones, en nuestros
trabajos, vida personal, etc. por todo lo anterior un modelo y una base de datos
bien estructurada y definida suministrará información precisa y acertada para
solucionar problemas en una empresa, vida personal, profesional, donde la
interacción con el usuario sea de forma íntegra y sencilla.
El siguiente trabajo práctico se basará en el diseño conceptual de una base de
datos bajo el modelo de organización relacional, así como también, el diseño
lógico y físico de una base de datos, utilizando un sistema de gestión de base de
datos relacional.

Planteamiento
En las grandes y medianas ciudades existe actualmente un congestionamiento del
tránsito vial debido al aumento del parque automotor. Dicho congestionamiento,
causa a su vez, ciertos problemas que afectan la calidad de vida de los habitantes,
como son: la contaminación ambiental y auditiva, mayor cantidad de accidentes de
tránsito, y un progresivo aumento del nivel el estrés de los ciudadanos en general.
Es por esta razón, los municipios invierten cada vez más proporción de su
presupuesto en acciones para una mayor eficiencia del tránsito, a fin de neutralizar
los citados efectos que genera la circulación de un número de vehículos cada vez
más alto. En este sentido, la empresa “SACARIAS” ha sido encargada para la
puesta en funcionamiento de un sistema de control de tránsito que permite
gestionar y sincronizar semáforos para una ciudad de manera eficiente, sencilla y
segura. El Sistema está compuesto por:
- Un Controlador Autónomo de Luces: El controlador autónomo de luces se
configura con las secuencias, tiempos y posiciones correspondientes mediante un
protocolo diseñado específicamente a tales fines.
- Un Controlador Satelital: se conecta a la red GPS y obtiene la hora exacta
precisión de milisegundos, así el controlador automático de luces se calibra con la
hora oficial de forma regulada.
- Una Central de Control y Monitoreo: el controlador satelital envía a la central de
control y monitoreo el estado de funcionamiento del semáforo, aquí se analiza el
estado y en caso necesario se activan las alarmas correspondientes (emails,
mensajes de textos) a los técnicos correspondientes.
Los operadores del sistema pueden realizar ajustes de configuración y tiempo.
Dentro del servidor se verifica y se envía los cambios correspondientes para cada
controlador.
La Empresa, desea llevar las incidencias generadas por el sistema de gestión y
sincronización de semáforos mediante la implementación de una Base de Datos,
cuyas funcionalidades serán las siguientes:
- Registrar y mantener actualizados los datos de: El Controlador Autónomo de
Luces, el controlador satelital, y la central de control y monitoreo (Identificación,
ubicación, fecha de adquisición, fecha de mantenimiento, vida útil, reparaciones,
Configuración, cambio de piezas (repuestos), seguros.
- Registrar y mantener actualizados los datos de los Semáforos: Identificación,
cantidad, ubicación, fecha entrada al sistema, fecha salida del sistema,
observaciones.

- Registrar y mantener actualizados los datos personales de los técnicos, (Cédula
de identidad, Nombre, Persona Contacto, dirección, teléfonos, correo electrónico,
jornada de trabajo, viáticos, horas/hombre trabajadas).
- Registrar la incidencia por tipo, con fecha, hora y nombre del técnico asignado,
emails o mensajes enviados.
- Informe estadístico de servicios por recorrido y tipo de incidencia.
- La emisión del informe de incidencias con fecha de emisión, tipo de incidencia,
fecha de incidencia, técnico asignado, horas hombre trabajadas.
Tal como se expuso al inicio, la gerencia a través del departamento de informática
de la empresa “SACARIAS”, se propone en la actualidad diseñar la base de datos
relacional que de soporte al sistema de información (a desarrollar a futuro) cuyos
requerimientos funcionales han sido descritos en los párrafos anteriores.
Pregunta # 1 Módulo II Unidad 5 Objetivo 5 – Criterio de Dominio 1/1: Aplicar
las técnicas de normalización en el diseño de una base de datos relacional.
Primera forma Normal
Se dice que una relación se encuentra en primera forma sí y solo sí cada uno de
los dominios de atributo contiene valores atómicos, los elementos del dominio solo
son unidades indivisibles. Para validar esta normalización pondremos de ejemplo
las entidades: controlador, técnico y semáforo.
CONTROLADOR
idCont
rolador
Nombre ubicacio
n
fecha_de_
adquisicion
fecha_de_m
antenimiento
vida_
util
repara
ciones
configur
aciones
cambios_
de_piezas
Seguro
0001 Satélite Orbita 1 1/1/2016 5/7/2017 4 8 3 9 Mercantil
vigencia 3 años
0002 Satélite Deposito 5/8/2018 - 48 1 0 0 Previsora
vigencia 5 años
0003 Controlad
or Luces
Av73 9/3/2010 9/12/2016 28 10 6 16 Progreso esta
vencido
Para mantener los valores atómicos, en este tabla, al momento llenar de las
casillas: vida útil, reparaciones, configuraciones, cambios de piezas y seguro, por
segunda vez, es decir una actualización, se borra el valor anterior, no permite
tener dos registros o filas, evitando que se tenga más de un dato en alguno de
ellos.

TECNICO
cedula nombre Teléfono persona_co
ntacto,
direccion Correo jornada
_laboral
15234789 Juan
Pérez
0412-1400789 Miguel Ruiz Valencia,
Carabobo
Mr09@gmail.com Diurno
25890345 Alex
Páez
0416-0000001 María
Rodríguez
Maracay,
Aragua
Maria87@hotmail.com Nocturn
o
10234654 Pedro
Salinas
0414-1212999 Juana
Pinto
Cumana,
Sucre
pepeganga@gmail.co
m
Diurno
En este ejemplo, es fácil comprender que cada campo tiene valores atómicos, una
persona no puede tener dos cedulas iguales, dos correos iguales, ni dos turnos
laborales actuales distintos, como adelanto se observa que la clave primaria de
esta tabla es la cedula de identidad que es única para cada persona, y determina
la eliminación de posibles homónimos, por ejemplo dos “Pedros Salinas” que sean
de Cumana, ambos son personas diferentes porque tienen números de cedulas
distintos.
SEMAFORO
id_semaforo Cantidad ubicación fecha_in fecha_out Observación
S0001 - AV Las
Mercedes
01/05/12 - Semáforo Led
de 3 luces
S0002 2 AV México 02/07/08 03/09/11 Incandescente
de 5 luces
S0003 5 AV Bolívar 01/04/05 06/12/13 Led de 4 Luces
Esta tabla es particular, al igual que en la tabla de controlador para mantener los
valores atómicos, en los atributos: cantidad, fechas, observaciones, al producir
una actualización en alguno de ellos, se eliminar el valor anterior en el mismo, y
así evitar más de un dato en la casilla. Cada semáforo posee su “cedula” llamada
id_semaforo que hace cada registro único, pueden existir dos filas que tenga el
mismo modelo, en la misma avenida, y con igual número de sustituciones y ser
dos semáforos distintos.
Segunda forma Normal
Una tabla se encuentra en segunda forma normal cuando cumple con las reglas
de la primera forma normal y todos sus atributos que no son claves dependen por
completo de la clave definida. Antes de realizar el proceso de normalización, se
debe definir es la clave; la clave debe contener un valor único para tupla o registro,
ya que no pueden existir dos valores iguales en toda la tabla, y podrá estar
formada por un único atributo o por un grupo de atributos, si todos los atributos de
la entidad dependen directamente de la clave se dice que la relación esta en
segunda forma normal. Como ejemplo de cómo se realizó esta normalización se
tomará la entidad incidencia.

INCIDENCIA (MODELO INICIAL SOLICITADO)
id_incidencia tipo ubicación fecha Hora Texto Mensaje Nombre Técnico
I0001 2 AV Lara 1/1/13 07:34 Bajo Voltaje, en
terminales
Juan Pérez
I0002 3 AV Cipreses 2/3/15 12:25 Pantalla rota Alex Páez
I0003 5 AV León 4/7/`17 15:58 Pernos en base flojos Pedro Salinas
Se define a id_incidencia como la clave primaria, y a partir de esta, se verifica la
dependencia del resto de los campos.
El tipo, ubicación, fecha y hora, dependen directamente del id_incidencia.
El mensaje aunque depende para la incidencia, cada mensaje tiene su manejo
particular, ya que es una estructura que posee su propia id, el tipo del mensaje, y
el texto del mensaje. El nombre del técnico no depende directamente de
id_incidencia, los atributos de cada operador depende de cada registro de la tabla
técnico. Por lo tanto la solicitud inicial no está en segunda forma normal, para
subsanarlo, se crea la tabla mensaje y la mencionada técnico.
Mensaje
id_mensaje Tipo texto
M001 Texto Bajo Voltaje, en terminales
M002 Email Pantalla rota
M003 Texto Pernos en base flojos
TECNICO
cedula nombre Teléfono persona_co
ntacto,
Dirección Correo jornada
_laboral
15234789 Juan
Pérez
Carabobo
25890345 Alex
Páez
0416-0000001 María
Rodríguez
Maracay,
Aragua
o
10234654 Pedro
Salinas
0414-1212999 Juana
Pinto
Cumana,
Sucre
pepeganga@gmail.co
m
Diurno
Y la tabla incidencia correcta queda de la siguiente manera:
INCIDENCIA (MODELO FINAL MODIFICADO)
id_incidencia Tipo Ubicación fecha Hora id_mensaje tecnico_cedula
I0001 2 Av Lara 1/1/13 07:34 M001 15234789
I0002 3 AV Cipreses 2/3/15 12:25 M002 25890345
I0003 5 Av León 4/7/`17 15:58 M003 10234654
El modelo ahora posee una clave primera, y dos claves foráneas: una para los
mensajes y otras para los técnicos.

Tercera forma normal
Se dice que una tabla está en tercera forma normal si y solo si está en segunda
forma normal y los atributos de la tabla dependen únicamente de la clave. Es decir
los atributos de las tablas no dependen unos de otros. Para esta última
normalización se utilizará la entidad informe de base.
INFORME (MODELO INICIAL)
id_informe fecha_e
mision
Tipo de
incidencia
Fecha de
incidencia
Técnico
asignado
Horas hombres
trabajadas
INF001 5/5/13 I0001 1/1/13 Juan Pérez 8
INF002 7/3/15 I0002 2/3/15 Alex Páez 12
INF003 16/4/17 I0003 4/7/`17 Pedro Salinas 15
Se define a id_informe como clave primaria, y a partir de esta, se verifica la
dependencia del resto de los campos. La fecha de emisión, y las horas hombre
trabajadas depende directamente de la clave id_informe. Se definió que un
informe está atado a una única incidencia, es decir tienen una relación 1:1. Debido
al criterio anterior el tipo de incidencia y la fecha de incidencia en parte dependen
de id_informe, pero están de forma más relacionadas con la incidencia.
El nombre del técnico también en parte está relacionado con el informe de la
incidencia ya que un solo técnico está asociado a la incidencia, y por la relación
1:1 incidencia – informe, los hace conexos, sin embargo es mejor que este nombre
venga re direccionado como clave foránea procedente de la entidad técnico para
evitar inconsistencias.
Para subsanarlo, se sustituye los datos solicitados de la incidencia por la clave
primaria id_incidecia, para utilizarla como una clave foránea en esta nueva tabla,
de forma similar se hace con la clave primaria id_tecnico para relacionar el nombre
del técnico asginado. En la versión definitiva de la tabla informe se agregó un
nuevo atributo “viáticos” que está íntimamente relacionado con una incidencia
particular y se verá reflejado en la impresión de un informe, cuando se desee
saber la cantidad de viáticos que posee un técnico en particular se realizará una
consulta.
TECNICO
Cedula nombre Teléfono persona_co
ntacto,
Dirección Correo jornada
_laboral
15234789 Juan
Pérez
Carabobo
25890345 Alex
Páez
0416-0000001 María
Rodríguez
Maracay,
Aragua
o
10234654 Pedro
Salinas
0414-1212999 Juana
Pinto
Cumana,
Sucre
pepeganga@gmail.co
m
Diurno

INCIDENCIA
id_incidencia Tipo Ubicación fecha Hora id_mensaje tecnico_cedula
I0001 2 Av Lara 1/1/13 07:34 M001 15234789
I0002 3 AV Cipreses 2/3/15 12:25 M002 25890345
I0003 5 Av León 4/7/`17 15:58 M003 10234654
INFORME (MODELO FINAL MODIFICADO)
id_informe fecha_emision id_incidencia id_tecnico hht viatico
INF001 5/5/13 I0001 15234789 8 12000
INF002 7/3/15 I0002 25890345 12 15000
INF003 16/4/17 I0003 10234654 15 19000
Pregunta # 2 Módulo II Unidad 6 Objetivo 6 – Criterio de Dominio 1/1:
Resolver en situaciones dadas, problemas de seguridad y/o integridad en la B.D.
relacional.
Se define integridad como la validación de los datos, que los mismos proporcionen
un medio que permita asegurar que las modificaciones realizadas a la base de
datos por los usuarios autorizados, no produzcan perdida de la consistencia de los
datos protegiéndolas contra los daños accidentales.
En la base de datos que nos ocupa, todos los datos están relacionados en tal
forma que tengan consistencia. Por ejemplo en informe se debe colocar nombre
de técnico y de incidencia, pero para mantener la consistencia de los datos en
esta tabla este par de datos no se llenan, por el contrario dependen en otras
entidades, (técnico e incidencia), por eso se debe apuntar a las respectivas claves
foráneas de estos datos solicitados.
INFORME
id_informe fecha_emision id_incidencia id_tecnico hht viatico
INF001 5/5/13 I0001 15234789 8 12000
Otra definición relevante de las tabla creadas para este trabajo practico es que
están elaboradas en cascada, es decir si se modifica un campo, todos los posibles
campos que este atributo pueda apuntar puede cambiar de valor, o pasar a valer
nulo si es eliminado.
La seguridad de la base de datos se refiere a la protección de datos almacenados
a la base de datos, de accesos no autorizados, alteraciones o destrucciones
malintencionadas. Para definir algunos esquemas de seguridad en la base de
datos de este trabajo practico se aplicaran según tipo de área de resguardar y
como se realizaría.
Sistema de base de datos: algunos usuarios solo podrán tener acceso a ciertas
partes, como ejemplo se decidió tener 4 posibles usuarios, Técnicos, Supervisores

de Técnicos, Gerente, Diseñador de BD. Los accesos se describen en la siguiente
tabla.
Controlador Incidencia Semáforo Técnico Mensaje Semaforo_I
ncidencia
informe
Técnico NO SI SI NO SI NO NO
Supervisor de
Técnicos
SI SI SI SI SI NO SI
Gerente SI SI SI SI NO NO SI
Administrador
de la B.D
SI SI SI SI SI SI SI
Sistema operativo: Para evitar el ingreso no autorizado, se pueden diseñar
usuarios y contraseñas de accesos a los equipos.
Red: El acceso remoto por terminales o redes es un cualidad presente en casi
todos los sistemas de base de datos, por lo tanto su seguridad es vital, los
protección de accesos de terceros desde la red a los servidores y en
consecuencia a los datos, puede protegerse por medio de software como firewalls
y protocolos de seguridad.
Físico y Humano: Los almacenes de sistemas informáticos deben protegerse de
la entrada de intrusos, sea de forma clandestina o con participación de personal
interno. El resguardo físico de la data es importante frente a daños físicos,
ambientales.
Como medidas se pueden implementar sistemas de seguridad, cámara, video,
etc., capacitación del personal, y en la parte de respaldo realizar periódicamente la
migración de los datos a dispositivos de almacenamientos secundarios, como
discos duros externos, ópticos, o incluso cintas magnéticas.
Autorizaciones: Los usuarios antes descritos pueden tener jerarquías en la base
de datos, autorización para lectura, para inserción, actualización, y borrado.
Una forma práctica de aplicar estas jerarquías en la base de datos que se está
trabajando, seria por ejemplo en la entidad incidencia: Técnico puede leer
incidencias anteriores, pero al crear una nueva, es decir una inserción, debe tener
una autorización de su supervisor, para que esté pueda verificar los datos. El
técnico a partir de ahí no puede cambiar los datos de la incidencia que liberó al
sistema, si de casualidad realizó un error, le puede solicitar al supervisor un
permiso de actualización, o que lo haga el supervisor directamente. Este tipo de
proceso permite ir validando el flujo de información, evitar errores de transcripción
y reproceso.

Pregunta # 3 Módulo III Unidad 7 Objetivo 7 – Criterio de Dominio 1/1: diseñar
conceptualmente una base de datos bajo el modelo de organización relacional.
Obtención y análisis de requisitos:
Se define como conocer y analizar las expectativas de los usuarios y los usos
potenciales que se le va a dar a la base de datos con el mayor detalle posible. Se
creará una base de datos para mejorar el control y actualización del sistema de
tránsito. Luego de crear el diseño conceptual, se realizará el diseño lógico de
entidades y a partir de ahí se implementara de un SGBDR.
Requerimientos y necesidades de los usuarios:
Los actores en escena, se identifican como las personas que trabajan por
mantener el entorno del sistema de base de datos, en este caso particular se
tiene:
Usuario A: Administrador de la base de datos Es el encargado del diseño y
funcionamiento de la base de datos.
Usuario B: Técnico, es el que registra y reporta las incidencias de fallas o
reparaciones en los semáforos u otro equipo del sistema.
Usuario C: Supervisor o Gerente, es el encargado de realizar los informes
generales de las incidencias, verificar el estatus de productividad de los técnicos,
(basados en horas trabajadas) y actualizar el estatus del controlador autónomo de
luces, controlador satelital, central de control y monitoreo.
Entidades: Los procesos en entidades que tendrá la base de datos serán las
siguientes: Controlador, Mensaje, Técnico, Informe, Semaforo, Incidencia,
Semaforo_Incidencia (Tabla de enlace o transición para cardinalidad n:n)
Documentación de la entidad # 1 Nombre Controlador
Atributos Descripción Atributo Clave
idControlador, nombre,ubicacion,
fecha_de_adquisicion,
fecha_de_mantenimiento, vida_util,
reparaciones, configuraciones,
cambios_de_piezas, seguro
Registra y actualiza los datos de los 3
equipos principales del sistema
idControlador
Documentación de los atributos de la entidad 1 (Controlador)
Nombre del atributo Descripción del atributo Entidades que lo contiene
IdControlador Registra el número del controlador en el
sistema
Controlador, este atributo es
la clave primaria
Nombre Indica el nombre que identifica al
controlador
Controlador
fecha_de_adquisicion Es la fecha que se compró el
controlador
Controlador

fecha_de_mantenimiento Es la fecha del ultimo mantenimiento
realizado al controlador
Controlador
vida_util Indica el número de meses que le resta
de vida útil al equipo
Controlador
Reparaciones Registra el número de reparaciones que
se han hecho al controlador
Controlador
Configuraciones Indica la configuración que tiene el
equipo
Controlador
cambios_de_piezas Indica la cantidad de oportunidades que
sea realizó un cambio de piezas al
controlador
Controlador
Seguro Da una breve descripción sobre el
seguro que posee este controlador
Controlador
Documentación de la entidad # 2 Nombre Semáforo
id_semaforo, cantidad, ubicación,
fecha_in, fecha_out , observación
Esta entidad refleja los datos relevantes
de los semáforos que son utilizados en
el sistema de tránsito.
id_semaforo
Documentación de los atributos de la entidad 2 (semaforo)
id_semaforo Registra con un numero único, cada
semáforo del sistema de tránsito
semaforo, este atributo es la
clave primaria
Cantidad Indica la cantidad de veces que el
semáforo ha sido reemplazado
Semáforo
Ubicación En este campo, se indica la ubicación
del semáforo
Semáforo
fecha_in Se registra la fecha en m/d/a en que
entró al sistema un semáforo
Semáforo
fecha_out Se registra la fecha en m/d/a de salida
del sistema de un semáforo
Semáforo
Observación Se permite realizar un
comentario/observación sobre un
semáforo.
Semáforo
Documentación de la entidad # 3 Nombre Tecnico
cedula, nombre, persona_contacto,
direccion, telefono, correo,
jornada_laboral
Contiene los datos personales del técnico
y las jornadas laborales donde este
laborando.
Cedula
Documentación de los atributos de la entidad 3 (tecnico)
Cedula Es la cedula de identidad del trabajador tecnico, este atributo es la
clave primaria
Nombre Se registra el nombre y apellido del
trabajador
Técnico
persona_contacto Se indica una tercera persona contacto del
trabajador, como un familiar
Técnico
Dirección Se registra la dirección donde vive el
trabajador
Técnico

Teléfono Contiene el número de teléfono del técnico Técnico
Correo Se registra el correo electrónico de
trabajador
Técnico
jornada_laboral Indica en cuál de los turnos labora el
trabajador, es una variable de tipo
enumeración donde se registraron 3 tipos
de turno: vespertino, diurno, nocturno.
Técnico
Documentación de la entidad # 4 Nombre Mensaje
id_mensaje, tipo,texto Esta entidad se refiere a los mensajes
enviados, cuando ocurre una incidencia en
un semáforo
id_mensaje
Documentación de los atributos de la entidad 4 (mensaje)
id_mensaje Identifica el mensaje enviado, único para
cada mensaje
mensaje, este atributo es la
clave primaria
Tipo Indica el tipo de mensaje enviado, es una
variable de tipo enumeración donde se
registraron 2 tipos: texto, email
Mensaje
Texto Se registra el contenido del mensaje Mensaje
Documentación de la entidad # 5 Nombre incidencia
id_incidencia, tipo, ubicación, fecha, hora,
id_mensaje, tecnico_cedula
Contiene los datos afines a una incidencia,
es importante resaltar que posee dos
claves foráneas, ambas críticas para
elaborar un registro
id_incidencia (clave
primaria), id_mensaje (clave
foránea), tecnico_cedula
(clave foránea)
Documentación de los atributos de la entidad 5 (incidencia)
id_incidencia Indica el número de la incidencia ocurrida,
es un número único para cada incidencia.
incidencia, este atributo es
la clave primaria
Tipo Registra el tipo de incidencia, es una
variable de tipo enumeración donde se
crearon 5 tipos: 1, 2, 3, 4 , 5
Incidencia
Ubicación Este campo permite registrar el sitio donde
ocurrió la incidencia
Incidencia
Fecha Este campo registra la fecha donde ocurrió
la incidencia
Incidencia
Hora Este campo registra la hora de la
incidencia
Incidencia
id_mensaje Con este id la tabla incidencia puede
apuntar a la entidad mensaje, y con el
número de id, se puede acceder a todos
los campos por ejemplo, contenido del
mensaje y tipo utilizado
incidencia (como clave
foránea), mensaje (como
clave primaria)
tecnico_cedula Con esta clave foránea la tabla incidencia
puede apuntar a la entidad técnico, y así
acceder a todos los campos relacionados
incidencia (como clave
foránea), técnico (como
clave primaria)

en ese registro, como nombre, teléfono,
etc.
Documentación de la entidad # 6 Nombre Informe
id_informe, fecha_emision, id_incidencia,
id_tecnico, hht, viatico
Almacena los datos que son parte del
informe de incidencia, se asumió que la
relación es 1:1, es decir, un informe por
cada incidencia, ya que para ver varias
incidencias de una sola fecha por ejemplo
se podrían resumir a través de una
consulta. Posee dos claves foráneas.
id_informe (clave
primaria), id_incidencia
(clave foránea), id_tecnico
(clave foránea)
Nombre del atributo Descripción del atributo Entidades que lo
contiene
id_informe Es un número que identifica cada informe
y es único en cada uno de ellos
informe, este atributo es la
clave primaria
fecha_emision Indica la fecha en que se elaboró el
informe
Informe
id_incidencia Este atributo permite a la entidad informe
apuntar a la entidad incidencia, y acceder
a todos los campos de un número de id
determinado, como fecha, tipo, ubicación,
etc.
informe (como clave
foránea), incidencia (como
clave primaria)
id_tecnico Este atributo permite a la entidad informe
apuntar a la entidad tecnico, y acceder a
todos los campos de un número de id
determinado, como nombre, teléfono, etc.
informe (como clave
foránea), tecnico (como
clave primaria)
Hht Indica la cantidad de horas hombre
trabajadas en esa incidencia
Informe
Viatico Cantidad de bolívares que se le asignaron
al técnico para realizar esta reparación,
puede incluir hospedaje, comida, etc.
Informe
Documentación de la entidad # 7 Nombre semaforo_incidencia
Id, id_semaforo, id_incidencia Es una tabla auxiliar, que permite elaborar la
relación entre semáforo e incidencia,
definiendo que un un semáforos puede tener
varias incidencias, pero a su vez varios
semáforos puedes tener el mismo tipo de
incidencia, es resume una cardinalidad n:n
Id (clave primaria),
id_semaforo (clave foránea) ,
id_incidencia (clave foránea)
Documentación de los atributos de la entidad 7 (semaforo_incidencia)
Id Es el identificador de esta tabla de enlace
entra una incidencia y un semaforo
semaforo_incidencia
id_semaforo Este atributo permite a la entidad
semáforo_incidencia apuntar a la entidad
semaforo, y acceder a todos los campos de
un id determinado, como ubicación,
observación, etc
semaforo_incidencia (como
clave foranea), semáforo
(como clave foránea)

id_incidencia Este atributo permite a la entidad
incidencia, y acceder a todos los campos de
un id determinado, como fecha, tipo,
ubicación, etc.
semaforo_incidencia (como
clave foranea), incidencia
(como clave primaria)
Nota: No se desarrolló la entidad “informe por tipo de incidencia y por recorrido,
debido a lo ambiguo de la redacción, sentí que el planteamiento no era claro, y un
informe por tipo de incidencia no sería una tabla como tal, es más acertado una
consulta donde se seleccionan todas las incidencias y se filtra por tipo.
Interacción de las entidades
La interacción se establece en rombos dentro del Diagrama de Entidad – Relación,
ésta unión indica que existe un intercambio de información.
Documentación de la relación # 1 Nombre Envía
Descripción Entidades involucradas
Se establece, que para cada incidencia se envía un mensaje incidencia, mensaje
Cardinalidad de la relación # 1 (Envía)
Entidades y restricciones de cardinalidad involucradas
Esta cardinalidad indica que una incidencia solo posee un mensaje de comunicación.
Cardinalidad Descripción de la restricción de cardinalidad
1:1 Una incidencia solo posee un mensaje enviado
Documentación de la relación # 2 Nombre Tiene
Se establece, que los semáforos pueden tener varias incidencias incidencia, semáforo
Cardinalidad de la relación # 2 (Tiene)
Esta cardinalidad indica que los semáforos pueden tener varias incidencia
n:n Los semáforos pueden tener varias incidencias
Documentación de la relación # 3 Nombre Genera
Se establece, que una incidencia genera un informe incidencia, informe
Cardinalidad de la relación # 3 (Genera)
Esta cardinalidad indica que una incidencia solo posee un informe y viceversa
1:1 Una incidencia genera un informe

Documentación de la relación # 4 Nombre Gestiona
Se establece, que un técnico puede gestionar/reparar varias incidencias técnico, incidencia
Cardinalidad de la relación # 4 (Gestiona)
Esta cardinalidad indica que un técnico puede reparar varias incidencias
1:n Un técnico gestiona varias incidencias
Documentación de la relación # 5 Nombre Desempeño
Se establece, que el desempeño de un técnico
está reflejado en varios informes
técnico, incidencia
Cardinalidad de la relación # 5 (Desempeño)
Esta cardinalidad indica que un técnico puede aparecer un varios informes
1:n El desempeño de un técnico está reflejado en varios informes
Diagrama entidad relación

Documentación de la transacción
Documentación de la
transacción # 1
Nombre Registrar controlador
Tipo de transacción Registrar
Descripción Se registran los datos de uno de los controlador, es decir
uno de 3 equipos principales
Frecuencia Se realizará cada vez que se tenga que cambiar algún
campo de algunos de los equipos ya sea por actualización,
por salida, entrada por un reemplazo, reparación o
mantenimiento
Tiempo de respuesta estimado 0,15 s
Entidad Atributos Usuarios
Controlador idControlador, ombre,ubicacion,
fecha_de_adquisicion,
fecha_de_mantenimiento, vida_util,
reparaciones, configuraciones,
cambios_de_piezas, seguro
Gerente, Tecnico
transacción # 2
Nombre Almacenar
trabajador
Descripción Los datos del técnicos son almacenados
Frecuencia Se crea un registro de técnico por cada trabajador
Tecnico cedula, nombre, persona_contacto,
direccion, telefono, correo, jornada_laboral
Gerente
transacción # 3
Nombre Registrar incidencia
Descripción Los datos de la incidencia son almacenados
Frecuencia Se crea un registro por cada incidencia que ocurra
Incidencia id_incidencia, tipo, ubicación, fecha,
hora, id_mensaje, tecnico_cedula
Gerente, Técnico
transacción # 4
Nombre Ingresar Semáforo
Descripción Los datos de un semáforo se ingresan al sistema
Frecuencia Se crea un registro por cada semáforo
Semáforo id_semaforo, cantidad, ubicación,
fecha_in, fecha_out , observación
Gerente, Técnico
transacción # 5
Nombre Generar informe
Tipo de transacción Salida/Reporte
Descripción Se genera un reporte de incidencia con sus datos

correspondientes
Frecuencia Se crea un registro por cada incidencia
Informe id_informe, fecha_emision,
id_incidencia, id_tecnico, hht, viatico
Gerente
transacción # 6
Nombre Gestionar
Incidencia
Tipo de transacción Gestionar
Descripción Las incidencias de los equipos son procesadas
Frecuencia Se crea un registro por cada incidencia, un técnico puede atender
varias incidencia
Técnico, incidencia id_incidencia, tipo, ubicación, fecha, hora, id_mensaje,
tecnico_cedula, cedula, nombre, persona_contacto,
direccion, telefono, correo, jornada_laboral
Tecnico
Pregunta # 4 Módulo III Unidad 8 Objetivo 8 – Criterio de Dominio 1/1:
Elección de un SGBDR, diseño lógico y diseño físico de la base de datos.
Elección de un sistema de gestión de base de datos relacional
La elección se basa en varios factores: económicos, técnicos y organizacionales.
Los técnicos se refieren a la capacidad y adaptabilidad del SGBDR para la tarea
asignada, como sus estructuras de almacenamiento, caminos de acceso,
interfaces de usuario, herramientas de desarrollo, opciones cliente servidor, etc.
Los factores económicos incluyen, costo de adquisición de software y hardware,
costo de mantenimiento, costo de creación y conversión de la base de datos,
costo de personal.
Los factores organizacionales son:
Adopción de una determinada filosofía: puede afectar la aceptación de cierto
modelo de datos, cierto proveedor, o ciertas metodologías y herramientas de
desarrollo.
Familiaridad del personal con el sistema: Si el personal informático de la
organización ya conoce un SGBD en particular, se puede recomendar para
reducir los costos de entrenamiento y el tiempo de aprendizaje.
Disponibilidad de servicios del proveedor: es importante ya que permite resolver
cualquier problema que se presente con el sistema.

Portabilidad del SGBD: Ya sea entre distintos hardware, software o sistemas
operativos. También debe considerarse la necesidad de aplicaciones para
respaldo, recuperación, rendimiento, integridad y seguridad.
En este caso de estudio, para el desarrollo de la base de datos se utilizará
PostgreSQL como sistema de gestión de base de datos (SGBD).
PostgreSQL está orientado a objetos. Es dirigido por una comunidad de
desarrolladores que trabajan de forma desinteresada, ya que es un proyecto de
código libre y abierto, por lo tanto no tiene costo de adquisición.
Posee un costo de adquisición de hardware relativamente bajo, como muestras
sus requerimientos: CPU 32/ 64 bit, Sistema operativo 32/64 bit, 1 BG de memoria
RAM, procesador Dual/Core o equivalente.
Ventajas de PostgreSQL
Amplia difusión y conocimiento entre los
programadores
Alta concurrencia
Posee soporte nativo de: Números de precisión
arbitraria, texto de largo ilimitado, figuras
geométricas, direcciones IP, Arrays.
Los usuarios pueden crear sus propios tipos de
datos
Claves Foráneas
Disparadores
Vistas.
Integridad transaccional
Soporte para transacciones distribuidas
Funciones que pueden escribirse en diversos
lenguajes: PL/PgSQL, C, C++, Java, PHP,
Python, entre otros.
Seguridad
Soporte de una activa y enorme comunidad
Integridad referencial
Autorizaciones
Conexión a DBMS
Transacciones y respaldos
Herencia de tablas

El costo de creación de la base de datos es despreciable pues es diseñada y
creada por un estudiante de la Universidad Nacional Abierta.
Documentación de la entidad # 1 (Controlador) Tamaño
registro
32 kb
Descripción Registra y actualiza los datos de los 3 equipos
principales del sistema
Volumen estimado de crecimiento (registros/año) 10.000
Cantidad de almacenamiento requerida (bytes/año) 320.000 Kb/año = 320 Mb al año
Atributos Longitud
atributos
Atributo Clave
idControlador, nombre,ubicacion, fecha_de_adquisicion,
fecha_de_mantenimiento, vida_util, reparaciones,
configuraciones, cambios_de_piezas, seguro
2,7 kb idControlador
Documentación de los atributos de la entidad 1 (Controlador)
Nombre del
atributo
Descripción del atributo Longitud
(bytes)
Entidades que
lo contiene
Restricciones
idControlador Registra el número del controlador en el
sistema
2764,8 Controlador, es
clave primaria
Not Null
Nombre Indica el nombre que identifica al
controlador
2764,8 Controlador Not Null
fecha_de_adqui
sicion
Es la fecha que se compró el controlador 2764,8 Controlador Not Null
fecha_de_mant
enimiento
Es la fecha del ultimo mantenimiento
realizado al controlador
vida_util Indica el número de meses que le resta de
vida útil al equipo
Reparaciones Registra el número de reparaciones que se
han hecho al controlador
Configuracione
s
Indica la configuración que tiene el equipo 2764,8 Controlador Not Null
cambios_de_pi
ezas
Indica la cantidad de oportunidades que sea
realizó un cambio de piezas al controlador
Seguro Da una breve descripción sobre el seguro
que posee este controlador
Documentación de la entidad # 2
(Semaforo)
Tamaño registro 32 kb
Descripción Esta entidad refleja los datos relevantes de los
semáforos que son utilizados en el sistema de tránsito.
Cantidad de almacenamiento requerida (bytes/año) 1.280.000 Kb/año = 1.8 Gbl año
Atributos Longitud atributos Atributo Clave
id_semaforo, cantidad, ubicación, fecha_in, fecha_out ,
observación
4,6 kb id_semaforo
Documentación de los atributos de la entidad 2 (semaforo)
Nombre del
atributo
Descripción del atributo Longitud (bytes) Entidades que
lo contiene
Restricciones
id_semaforo Registra con un número único, cada
semáforo del sistema de tránsito
4710,4 semaforo, es la
clave primaria
Not Null

Cantidad Indica la cantidad de veces que el
semáforo ha sido reemplazado
4710,4 Semáforo Not Null
Ubicación En este campo, se indica la ubicación
del semáforo
fecha_in Se registra la fecha en m/d/a en que
entró al sistema un semáforo
fecha_out Se registra la fecha en m/d/a de salida
del sistema de un semáforo
Observación Permite realizar un comentario 4710,4 Semáforo Not Null
Documentación de la entidad # 3 (Tecnico) Tamaño
registro
32 kb
Descripción Contiene los datos personales del técnico y las
jornadas laborales donde este laborando.
Cantidad de almacenamiento requerida (bytes/año) 320.000 Kb/año = 320 Mb al año
Atributos Longitud
atributos
Atributo Clave
cedula, nombre, persona_contacto, direccion, telefono, correo,
jornada_laboral
2,7 kb Cedula
Documentación de los atributos de la entidad 3 (Tecnico)
Nombre del
atributo
(bytes)
Entidades que
lo contiene
Restricciones
Cedula Es la cedula de identidad del trabajador 2764,8 Tecnico, es la
clave primaria
Not Null
Nombre Se registra el nombre y apellido del trabajador 2764,8 Tecnico Not Null
persona_contac
to
Se indica una tercera persona como contacto
del trabajador
2764,8 Tecnico Not Null
Dirección Se registra la dirección donde vive el
trabajador
2764,8 Tecnico Not Null
Teléfono Contiene el número de teléfono del técnico 2764,8 tecnico Not Null
Correo Se registra el correo electrónico de trabajador 2764,8 tecnico Not Null
jornada_laboral Indica en cuál de los turnos labora el
trabajador.
2764,8 tecnico Not Null
Documentación de la entidad # 4 (mensaje) Tamaño registro 200 kb
Descripción Esta entidad se refiere a los mensajes enviados, cuando
ocurre una incidencia en un semáforo
Cantidad de almacenamiento requerida (bytes/año) 20.000.000Kb/año = 20 Gbal año
Atributos Longitud
atributos
Atributo Clave
id_mensaje, tipo,texto 2,7 -100 kb id_mensaje
Documentación de los atributos de la entidad 4 (mensaje)
Nombre del
atributo
Descripción del atributo Longitud (bytes) Entidades que lo
contiene
Restric
ciones
id_mensaje Identifica el mensaje enviado, único
para cada mensaje
2764,8 mensaje, este atributo
es la clave primaria
Not Null

Tipo Indica el tipo de mensaje enviado 2764,8 mensaje Not Null
Texto Se registra el contenido del mensaje 100 Kb mensaje Not Null
Documentación de la entidad # 5 (incidencia) Tamaño
registro
100 kb
Descripción Contiene los datos afines a una incidencia, posee
dos claves foráneas
Cantidad de almacenamiento requerida (bytes/año) 10.000.000 Kb/año = 10 GB al año
Atributos Longitud
atributos
Atributo Clave
id_incidencia, tipo, ubicación, fecha, hora,
id_mensaje, tecnico_cedula
2,7 kb id_incidencia (clave primaria),
id_mensaje (clave foránea),
tecnico_cedula (clave foránea)
Nombre del
atributo
(bytes)
Entidades que lo
contiene
Restricciones
id_incidencia Indica el número de la incidencia ocurrida,
es un número único para cada incidencia.
2764,8 incidencia, es la
clave primaria
Not Null
Tipo Registra el tipo de incidencia. 2764,8 Incidencia Not Null
Ubicación Este campo permite registrar el sitio donde
ocurrió la incidencia
2764,8 Incidencia Not Null
Fecha Este campo registra la fecha donde ocurrió
la incidencia
2764,8 Incidencia Not Null
Hora Este campo registra la hora de la incidencia 2764,8 Incidencia Not Null
id_mensaje Con este id la tabla incidencia puede
apuntar a la entidad mensaje.
2764,8 incidencia ( clave
foránea), mensaje
(clave primaria)
Not Null
tecnico_cedula Con esta clave foránea la tabla incidencia
puede apuntar a la entidad tecnico.
2764,8 incidencia (clave
foránea), técnico
(clave primaria)
Not Null
Documentación de la entidad # 6 (informe) Tamaño
registro
100 kb
Descripción Almacena los datos que son parte del informe de
incidencia, posee dos claves foráneas.
Cantidad de almacenamiento requerida (bytes/año) 10.000.000 Kb/año = 10 GB al año
Atributos Longitud
atributos
Atributo Clave
id_informe, fecha_emision, id_incidencia,
id_tecnico, hht, viatico
7 kb id_informe (clave primaria),
id_incidencia (clave foránea),
id_tecnico (clave foránea)
Documentación de los atributos de la entidad 6 (informe)
Nombre del
atributo
(bytes)
Entidades que lo
contiene
Restriccione
s
id_informe Es un número que identifica cada informe y
es único en cada uno de ellos
7000 informe, es la clave
primaria
Not Null

fecha_emisio
n
Indica la fecha en que se elaboró el informe 7000 Informe Not Null
id_incidencia Este atributo permite a la entidad informe
apuntar a la entidad incidencia.
7000 informe (clave
foránea), incidencia
(clave primaria)
Not Null
id_tecnico Este atributo permite a la entidad informe
apuntar a la entidad tecnico.
7000 informe (clave
foránea), tecnico
(clave primaria)
Not Null
Hht Indica la cantidad de horas hombre
trabajadas en esa incidencia
7000 Informe Not Null
Viatico Cantidad de bolívares que se le asignaron
al técnico para realizar esta reparación.
7000 Informe Not Null
Documentación de la entidad # 7
(semaforo_incidencia)
Tamaño
registro
32 kb
Descripción Es una tabla auxiliar, que permite elaborar la
relación entre semáforo e incidencia
Cantidad de almacenamiento requerida (bytes/año) 3.200.000 Kb/año = 3.2 Gb al año
Atributos Longitud
atributos
Atributo Clave
Id, id_semaforo, id_incidencia 2,7 kb Id (clave primaria), id_semaforo (clave
foránea) , id_incidencia (clave
foránea)
Documentación de los atributos de la entidad 7 (semaforo_incidencia)
Nombre del
atributo
(bytes)
Entidades que lo
contiene
Restricciones
Id Es el identificador de esta tabla de enlace
entra una incidencia y un semaforo
2764,8 semaforo_incidencia Not Null
id_semaforo Este atributo permite a la entidad
semaforo
2764,8 semaforo_incidencia
(clave foranea),
semáforo (clave
foránea)
Not Null
id_incidencia Este atributo permite a la entidad
incidencia.
2764,8 semaforo_incidencia
(clave foranea),
incidencia ( clave
primaria)
Not Null
Diseño lógico de la base de datos
El diseño lógico es parte del esquema conceptual y su resultado es un esquema
lógico, este esquema es una descripción de la estructura de la base de datos en
términos de que pueda procesar un tipo de SGBD. El diseño lógico posee dos
etapas:
Transformación independiente del sistema: El modelo de datos no considera
las características específicas en que el SGBD implementa el modelo de datos.
Corresponde esta etapa al modelo E-R.

Adaptación de los esquemas a un SGBD específico: Los SGBD implementan
un modelo de datos con características y restricciones de modelado específicas.
Se puede ajustar el resultado obtenido en el modelo E-R a las características de
implementación específicas de SGBD seleccionado. El resultado de esta fase
debe consistir en sentencias LDD (lenguaje de definición de datos) escritas en el
lenguaje del SGBD elegido que especifiquen los esquemas en el nivel conceptual
y externo del sistema de base de datos.
Diseño físico de la base de datos
Es el proceso de elegir estructuras de almacenamiento y caminos de acceso
específicos para que los ficheros de la base de datos tengan un buen rendimiento
con las diversas aplicaciones de la base de datos. El diseño físico parte del
esquema lógico y da como resultado un esquema físico. Un esquema físico es una
descripción de la implementación de una base de datos en memoria secundaria:
las estructuras de almacenamiento y los métodos utilizados para tener un acceso
eficiente a los datos. Por ello, el diseño físico depende del SGBD concreto y el
esquema físico se expresa mediante su lenguaje de definición de datos.
Definición de la tabla controlador y TDA específicos, usando lenguaje LDD:

Definición de la tabla semaforo, usando lenguaje LDD:
Definición de la tabla tecnico, usando lenguaje LDD:
Definición de la tabla mensaje, usando lenguaje LDD:
Definición de la tabla informe, usando lenguaje LDD:

Definición de la tabla incidencia, usando lenguaje LDD:
Definición de relación entre incidencia y mensaje, usando lenguaje LDD:
Definición de relación entre incidencia y tecnico, usando lenguaje LDD:
Definición de tabla auxiliar semaforo_incidencia, usando lenguaje LDD:

Diseño físico de la base de datos relacional de la empresa SACARIAS

Trabajo practico - Base de Datos (311) - UNA

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Trabajo practico - Base de Datos (311) - UNA

Similaire à Trabajo practico - Base de Datos (311) - UNA (20)

Plus de Ronald Alexander Medina Pinto

Plus de Ronald Alexander Medina Pinto (20)

Dernier

Dernier (20)

Trabajo practico - Base de Datos (311) - UNA