AA3-EV2 - DISEÑO LÓGICO DE LA BASE DE DATOS

SEGUNDO LISANDRO CASTELBLANCO CASTELBLANCO

ESPECIALIZACION EN GESTION Y SEGURIDAD DE BASES DE DATOS

SERVICIO NACIONAL DE APRENDIZAJE (SENA)

BOGOTÁ DC

2019
 AA3-EV2 - DISEÑO LÓGICO DE LA BASE DE DATOS

SEGUNDO LISANDRO CASTELBLANCO CASTELBLANCO

TUTOR:

GREGORIO ARTURO BAREÑO MARIN

Magister en Seguridad Informática

ESPECIALIZACION EN GESTION Y SEGURIDAD DE BASES DE DATOS

SERVICIO NACIONAL DE APRENDIZAJE (SENA)

BOGOTÁ DC

2019
 INTRODUCCION

Lo que se quiere es representar las diferentes secretarias de la Alcaldía de San Antonio del Sena en
un diseño lógico, y así determinar la organización de la Base de Datos de la entidad, dando respuesta
a las necesidades de almacenamiento de la información.
El diseño lógico de la Base de Datos se convierte en parte fundamental de los procesos de
construcción de un esquema de la información que utiliza la organización, basándose en un modelo
de Base de Datos específicos e independiente.
La Base de Datos es el sistema que guardan la información de la empresa para que esta pueda ser
utilizadas cuando el usuario así lo desee, este diseño lógico es de gran relevancia porque automatizan
previenen de errores y son eficaces en el tiempo y pueden ser adquiridas cuando el administrador del
sistema lo desee en su almacenamiento y distribución.
 NECESIDADES DE INFORMACION ALCALDIA SANANTONIO DEL SENA

Se realizará la obtención de datos de la organización, que permita satisfacer las necesites de la

organización.
 Acceso eficiente a la información fácil y rápido
 Tener redundancia mínima
 Mayor integridad de los datos
 Menor espacio de almacenamiento
 Confiabilidad de la información BD
 Seguridad en el Motor Base de Datos
 Implementación de la Base de Datos en todas las Secretarias.

SECRETARIA DE GOBIERNO
Esta secretaria busca tener una base de datos donde se registre las querellas, detenciones, y
contravenciones ocurridas en las inspecciones de Policía.
Teniendo en cuenta lo anterior se diseñó una base de datos donde se cumple con los requisitos
solicitados por el señor alcalde como se puede evidenciar en el siguiente gráfico.
Los Diagramas se realizarán en MicroOLAP Database Designer para PostgreSQL
DISEÑO LOGICO DE LA BASE DE DATOS
ENTIDADES: En este modelo existen once entidades que se nombran a continuación.

Detención
Inspección
Actuación
Persona
Inspección Contravención
Querella
Contravención
Demandado
Demandante
Involucrado
Coactuación

La tabla Inspección es la principal entidad dentro de este diseño lógico ya que nos permite hacer las
relaciones con las demás, está relacionada con las 10 tablas restantes para permitir la consultas.

RELACIONES DE CARDINALIDAD.
Entre la entidad Inspección y detención hay una relación Uno a muchos: es decir, en una Inspección
puede haber varias detenciones.
Entre la entidad Detención y persona hay una relación uno a muchos, es decir; en una detención puede
haber varias personas.
Entre la entidad Inspección y querella hay una relación uno a muchos, es decir; en una inspección
puede haber varias querellas.
Entre la entidad Querella y Actuación hay una relación uno a muchos, es decir; en una querella puede
tener varias actuaciones.
Entre la entidad Querella y Demandante hay una relación uno a muchos, es decir; en una querella
puede tener varias demandantes.
Entre la entidad Querella y Demandado hay una relación uno a muchos, es decir; en una querella
puede tener varias demandadas.
Entre la entidad Inspección e inspección contravención hay una relación uno a muchos, es decir; en
una inspección puede haber existir varias contravenciones.
Entre la entidad Inspección y contravención hay una relación uno a muchos, es decir; en una
inspección puede haber existir varias contravenciones
Entre la entidad contravención y contra actuación hay una relación uno a muchos, es decir, en una
contravención puede haber varias contra actuaciones.
Entre la entidad contravención e involucrado hay una relación uno a muchos, es decir, en una
contravención puede haber varios involucrados.

ATRIBUTOS
Cada entidad tiene unos atributos que se encuentran relacionados en las tablas que se pueden
evidenciar en el gráfico.

SECRETARIA DE PLANEACION Y OBRAS PUBLICAS

Definir y establecer el modelo de desarrollo social, direccionar los diferentes proyectos que las demás
secretarias realicen

Entidades para este modelo

Familia, Vivienda, Barrio, Personas, Departamento, Ruta, Enfermedad, Ciudad, Infante País,
Adolecente, Guardería, Cargo, Colegio, Jornada, Modalidad, Localidad Empresa, Documento

RELACION DE CARDINALIDAD
 Entre la entidad Personas y entidades como Departamento, Adulto, Ciudad, Infante y
Adolecente, hay una relación de unos a muchos porque una persona depende de las otras
entidades
 Entre la entidad colegio y las entidades Jornada, Modalidad, Localidad, Adolecente, hay una
Relación entre unos a muchos, porque un colegio exixten varias jornadas, modalidades y
muchos adolescentes.

DISEÑO LOGICO DE LA BASE DE DATOS

SECRETARIA DE HACIENDA

En la secretaria de hacienda se trabaja en el proceso de generación de recibos para que los

contribuyentes realicen el respectivo pago.
Por lo tanto, la prioridad de esta secretaria es el cobro del impuesto predial, el manejo de las cuentas
por cobrar y cuentas por pagar con terceros.

Diseño lógico de base de datos de la secretaria de Hacienda

Análisis:
En el anterior gráfico muestra lo siguiente:

ENTIDADES: En este modelo existen once entidades que se nombran a continuación.

Detalle factura Vigente

Concepto de Pago
Factura Vigente
Predio
Estrato
Propietario
Tipo Uso
Tercero
Pago
Cuentas por Cobrar
Cuentas por pagar

En esta base de datos encontramos una entidad principal que son:

Factura Vigente

Hay una segunda se llama Predio.

RELACIONES DE CARDINALIDAD.
Entre la entidad Concepto de pago y Detalle Factura Vigente hay una relación Uno a muchos: es
decir, un concepto de pago puede tener varias facturas
Entre la entidad Factura Vigente y Detalle de la factura vigente hay una relación uno a muchos, es
decir; en una factura pueden ir varios detalles.
Entre la entidad Predio y la factura vigente hay una relación uno a muchos, es decir; un predio puede
tener varias facturas.
Entre la entidad Estrato y Predio hay una relación uno a muchos, es decir; en un estrato puede haber
varios predios.
Entre la entidad Propietario y Predio hay una relación uno a muchos, es decir; un propietario puede
tener varios predios.
Entre la entidad Tipo de Uso y Predio hay una relación uno a muchos, es decir, que un predio puede
tener un solo uso.
Entre la Entidad Factura Vigente y Pago la relación es de uno a muchos es decir una factura puede
tener varios pagos.
Entre la entidad Tercero y Factura Vigente la relación es de uno a muchos es decir una tercera puede
tener varias Facturas.
Entre la entidad Tercero y cuentas por pagar la relación es de uno a muchos es decir un tercero puede
tener varias cuentas por pagar.
Entre la entidad Tercero y cuentas por cobrar la relación es de uno a muchos es decir un tercero puede
tener varias cuentas por cobrar.

ATRIBUTOS
Cada entidad tiene unos atributos que se encuentran relacionados en las tablas que se pueden
evidenciar en el gráfico.

SECRETARIA DE SALUD

En la secretaria de Salud se trabaja en el proceso de realizar proceso donde se identifican el número

de afiliados a la EPS, y los diferentes tipos de servicios que presentan cada una de estas
Por lo tanto, la prioridad de esta secretaria es llevar un registro de las EPS en su municipio con el
número de afiliados a la misma y los servicios que se están prestando.

Diseño lógico de base de datos de la secretaria de Salud

Análisis:
En el anterior gráfico muestra lo siguiente:

ENTIDADES: En este modelo existen nueve entidades que se nombran a continuación.

Tipo identificación
Persona
Historial Persona
Tipo de afiliado
Estado Persona
Estado EPS
EPS
Servicio EPS
Tipo Servicio
En esta base de datos encontramos una entidad principal que son:
HISTORIAL PERSONA

RELACIONES DE CARDINALIDAD.
Entre la entidad persona y tipo de identificación hay una relación Uno a muchos: es decir, cada
persona tiene un tipo de identificación único.
Entre la entidad historia persona y persona hay una relación Uno a muchos: es decir, cada historia
personal pertenece a una única persona.
Entre la entidad historia persona y estado persona hay una relación Uno a muchos: es decir, cada
historia personal tiene un único estado.
Entre la entidad historia persona y tipo de afiliación hay una relación Uno a muchos: es decir, cada
historia personal tiene un único tipo de afiliación.
Entre la entidad historia persona y EPS hay una relación Uno a muchos: es decir, cada historia
personal tiene una única EPS.
Entre la entidad ESTADO EPS Y EPS hay una relación Uno a muchos: es decir, cada se puede
presentar varios estados en la EPS.
Entre la entidad EPS Y SERVICIO EPS hay una relación Uno a muchos: es decir, una EPS puede
prestar varios servicios.
Entre la entidad SERVICIO EPS y TIPO DE SERVICIO hay una relación Uno a muchos: es decir,
un servicio de la EPS puede presentar varios tipos.

ATRIBUTOS
Cada entidad tiene unos atributos que se encuentran relacionados en las tablas que se pueden
evidenciar en el gráfico.

SECRETARIA DE DEPORTES, RECREACION Y CULTURA

En la secretaria de recreación se trabaja en el proceso de realizar eventos en el municipio.

Por lo tanto, la prioridad de esta secretaria necesita llevar un registro de asistencia a los eventos que
se realizan y a quienes va dirigido.

Diseño lógico de base de datos de la secretaria de Recreación

Análisis:
En el anterior gráfico muestra lo siguiente:

ENTIDADES: En este modelo existen seis entidades que se nombran a continuación.

Institución Evento
Institución
Evento
Participante Evento
Tipo
Participante

En esta base de datos encontramos una entidad principal que son:

Evento.

RELACIONES DE CARDINALIDAD.
Entre la entidad Institución e Institución evento hay una relación Uno a muchos: es decir, en una
institución se pueden hacer varios eventos.
Entre la entidad evento e institución evento hay una relación Uno a muchos: es decir, un evento se
puede hacer varias instituciones-
Entre la entidad tipo y evento hay una relación Uno a muchos: es decir, un tipo de evento se puede
hacer varias veces.
Entre la entidad participante evento y evento hay una relación Uno a muchos: es decir, un participante
puede participar en varios eventos.
Entre la entidad participante y participante evento hay una relación Uno a muchos: es decir, un
participante puede participar en varios eventos

ATRIBUTOS
Cada entidad tiene unos atributos que se encuentran relacionados en las tablas que se pueden
evidenciar en el gráfico

ESPECIFICACIONES DE ALMACENAMIENTO

Para el almacenamiento se utilizará una arquitectura SAN en una Red de almacenamiento integral,
agrupando los siguientes elementos.

 Una Red de alta velocidad

 Un equipo de interconexión dedicado
 Elementos de almacenamiento de Red
 Servidores
 Topología de Red


VENTAJAS

 Administración centralizada
 Flexibilidad y escalabilidad en la configuración
 Alta disponibilidad y rendimiento
 Confiabilidad de la transferencia de los datos
 No se afecta el tráfico de la Red LAN
 Compatibilidad con otros dispositivos
 Optimiza el espacio de almacenamiento
 DIAGRAMA

UBICACIÓN

La propiedad del Motor Base de Datos PostgreSQL especifica la carpeta pgAdmin 4\bin donde se
crea y administra todos los archivos de Metadatos y datos de la Base de Datos, todo se almacena en
la carpeta de datos del servidor.
La propiedad de la Base de Datos pgAdmin 4\bin se establece en una ruta de carpeta existente, de
manera predeterminada, no se puede establecer para que apunte a la carpeta de datos del servidor ni
a ninguna subcarpeta. Si la ubicación apunta a la carpeta de datos del servidor o a cualquiera de sus
subcarpetas, se produce erro de ejecución

Ruta predeterminada
  C:\Program Files\PostgreSQL\9.6\pgAdmin 4\bin
Para la creación de las tablas compatibles con PostgreSQL se utilizará el gestor de diagramas
MicroOLAP Database, hay se crean y se ejecutan los diagramas de modelo relacional, para después
realizar su ejecución en PgAdmin 4.

Ruta predeterminada

 C:\Program Files (x86)\MicroOLAP Database Designer for PostgreSQL

En la carpeta 9.6 se almacena el Backup cuando se realizan copias de seguridad.

Ruta predeterminada

 C:\Program Files\PostgreSQL\9.6\Backup

CARACTERISTICAS DE ACCECIBILIDAD DE LOS OBJETOS

Los lenguajes van a permitir la especificación de los datos que componen la Base de Datos, su
estructura, las relaciones entra BD, las reglas de integridad, los controles de acceso, las características
de tipo físico y las vistas externas de los usuarios.

DML, Data Manipulatio Language:

Utilizando instrucciones de SQL, permite a los usuarios introducir datos para posteriormente realizar
tareas de consultas o modificación de los datos que contienen las Bases de Datos.
Los elementos que se utilizan para manipular los datos, son los siguientes:
SELECT, esta sentencia se utiliza para realizar consultas sobre los datos.
INSERT, con esta instrucción podemos insertar los valores en una base de datos.
UPDATE, sirve para modificar los valores de uno o varios registros.
DELETE, se utiliza para eliminar las finas de una tabla.
DDL, Data Definition Language:

Con este lenguaje permite a los programadores de un sistema gestor de base de datos, como Postgres,
definir las estructuras que almacenarán los datos, así como los procedimientos o funciones que
permitan consultarlos.
Para definir las estructuras disponemos de tres sentencias:
CREATE, se usa para crear una base de datos, tabla, vistas, etc.
ALTER, se utiliza para modificar la estructura, por ejemplo añadir o borrar columnas de una tabla.
DROP, con esta sentencia, podemos eliminar los objetos de la estructura, por ejemplo un índice o
una secuencia.

DCL, Data Control Language:

Estos comandos permiten al Administrador del sistema gestor de base de datos, controlar el acceso a
los objetos, es decir, podemos otorgar o denegar permisos a uno o más roles para realizar
determinadas tareas.
Los comandos para controlar los permisos son los siguientes:
GRANT, permite otorgar permisos.
REVOKE, elimina los permisos que previamente se han concedido.

Aplicar las reglas de normalización

Para comprobar si las tablas están estructuradas correctamente. La normalización es más útil una
vez representados todos los elementos de información y después de haber definido un diseño
preliminar. La idea es asegurarse de que se han dividido los elementos de información en las tablas
adecuadas. Lo que la normalización no puede hacer es garantizar que se dispone de los elementos
de datos correctos para empezar a trabajar.

Id. de pedido (clave principal) I

d. de producto (clave principal)

Nombre de producto