Proyecto Tecnologias Informaticas

UNIVERSIDAD DE AQUINO BOLIVIA
FACULTAD DE CIENCIAS Y TECNOLOGÍA

CARRERA DE INGENIERÍA DE SISTEMAS
DESARROLLO DE UNA AGENDA AUTOMATIZADA DE CONTACTOS PERSONALES

PARA LA GESTIÓN DE INFORMACIÓN DE NÚMEROS DE TELÉFONO,
DIRECCIONES Y CORREOS ELECTRÓNICOS
TRABAJO FINAL
DOCENTE: ING. FRANK SEJAS MARAÑÓN

ESTUDIANTES: BETTY IVONNE ANDRADE CÓRDOVA
JUAN CARLOS BLACUTT YUCRA
JUAN MARIA LAURA CAYOJA
JOSÉ LUIS OLMOS ALÁ
ROBERTO QUISPE FLORES
MÓDULO: TECNOLOGÍAS INFORMÁTICAS
COCHABAMBA-BOLIVIA
2019
TABLA DE CONTENIDOS
CAPÍTULO 1. MARCO REFERENCIAL
1.1. INTRODUCCIÓN .............................................................................................................. 1
1.2. SITUACIÓN ACTUAL DEL PROBLEMA .................................................................... 1
1.2.1. FUNDAMENTACIÓN DEL PROBLEMA .................................................................. 1
1.2.2. FORMULACIÓN DEL PROBLEMA .......................................................................... 2
1.3. OBJETIVOS ....................................................................................................................... 2
1.3.1. OBJETIVO GENERAL ................................................................................................ 2
1.3.2. OBJETIVOS ESPECÍFICOS ........................................................................................ 2
1.4. ALCANCES ........................................................................................................................ 2
1.5. JUSTIFICACIÓN ............................................................................................................... 2
CAPÍTULO 2. MARCO TEÓRICO
2.1. BASE DE DATOS .............................................................................................................. 4
2.1.1. TIPOS DE BASES DE DATOS .................................................................................... 5
2.2. MODELO ENTIDAD RELACIÓN .................................................................................. 6
2.2.1. COMPONENTES Y CARACTERÍSTICAS ................................................................ 6
2.3. MODELO RELACIONAL ................................................................................................ 8
2.4. NORMALIZACIÓN ........................................................................................................ 10

2.4.1. PRIMERA FORMA NORMAL .................................................................................. 11
2.4.2. SEGUNDA FORMA NORMAL................................................................................. 11
2.4.3. TERCERA FORMA NORMAL ................................................................................. 11
2.5. SISTEMAS GESTORES DE BASES DE DATOS ........................................................ 11
2.5.1. COMPONENTES DE UN SGBD ............................................................................... 12
2.5.2. TIPOS DE SGBD ........................................................................................................ 12
2.6. SEGURIDAD DE BASES DE DATOS........................................................................... 13
CAPÍTULO 3. MARCO PRÁCTICO
3.1. DEFINICION DEL PROYECTO ................................................................................... 16
3.2. PRIMER SPRINT ............................................................................................................ 16
3.2.1 MODELO ENTIDAD RELACIÓN ............................................................................. 16
3.2.2. NORMALIZACIÓN ................................................................................................... 17
3.2.3. DICCIONARIO DE DATOS ...................................................................................... 18
3.2.4. IMPLEMENTACIÓN DEL MODELO DE DATOS .................................................. 19
3.3. SEGUNDO SPRINT ......................................................................................................... 20
3.3.1. ARCHIVO DATA BASE STORAGE ........................................................................ 21
3.3.2. ARCHIVO DATA BASE PROVIDER ....................................................................... 21
CAPÍTULO 4. CONCLUSIONES Y RECOMENDACIONES
4.1. CONCLUSIONES ............................................................................................................ 23

4.2. RECOMENDACIONES .................................................................................................. 24
BIBLIOGRAFÍA ..................................................................................................................... 24
ÍNDICE DE TABLAS
Tabla 1. Problemática general ................................................................................................... 1
Tabla 2. Adaptación a primera forma normal .......................................................................... 17
Tabla 3. Estructura de la Tabla Persona.................................................................................. 17
Tabla 4. Estructura de la Tabla Teléfono ................................................................................. 17
Tabla 5. Estructura de la Tabla Dirección ............................................................................... 17
Tabla 6. Estructura de la Tabla Correo ................................................................................... 18
Tabla 7. Diccionario de Datos de la Tabla Persona ................................................................ 18
Tabla 8. Diccionario de Datos de la Tabla Teléfono ............................................................... 18
Tabla 9. Diccionario de Datos de la Tabla Dirección ............................................................. 18
Tabla 10. Diccionario de Datos de la Tabla Correo ................................................................ 19

ÍNDICE DE FIGURAS
Figura 1. Ejemplo de estructura de una base de datos. ............................................................... 4
Figura 2. Ejemplo de un diagrama Entidad Relación. ................................................................ 8
Figura 3. Estructura de tablas de una base de datos. ................................................................ 10
Figura 4. Gestores de Bases de Datos más utilizados. ............................................................. 13
Figura 5. Diagrama Entidad Relación de la Agenda de contactos. .......................................... 16
Figura 6. Implementación del modelo de datos en Microsoft Access. ..................................... 19
Figura 7. Implementación del modelo de datos en MySQL. .................................................... 20
Figura 8. Implementación del modelo de datos en Oracle 11g. ............................................... 20

DESARROLLO DE UNA AGENDA AUTOMATIZADA DE CONTACTOS PERSONALES PARA LA
GESTIÓN DE INFORMACIÓN DE NÚMEROS DE TELÉFONO, DIRECCIONES Y CORREOS
ELECTRÓNICOS
CAPÍTULO 1
MARCO REFERENCIAL
1.1. INTRODUCCIÓN
En el entorno del mercado actual, la competitividad y la rapidez de maniobra de una

empresa son imprescindibles para su éxito. Para conseguirlo existe cada vez una mayor
demanda de datos y, por tanto, más necesidad de gestionarlos. Esta demanda siempre ha
estado patente en empresas y sociedades, pero en estos años se ha disparado debido al acceso
multitudinario a las redes integradas en Internet y a la aparición de los dispositivos móviles.
En informática se conoce como dato a cualquier elemento informativo que tenga

relevancia para un usuario. Desde su nacimiento, la informática se ha encargado de
proporcionar herramientas que faciliten la manipulación de los datos. Antes de la aparición de
las aplicaciones informáticas, las empresas tenían como herramientas de gestión de datos los
ficheros con cajones, carpetas y fichas. En este proceso manual, el tiempo requerido para
manipular los datos era enorme. Pero la informática ha adaptado sus herramientas para que los
elementos que el usuario utiliza en cuanto al manejo de datos se parezcan a los manuales. Los
sistemas de información actuales se basan en bases de datos y gestores de bases de datos que
se han convertido en elementos imprescindibles de la vida cotidiana de la sociedad moderna.
1.2. SITUACIÓN ACTUAL DEL PROBLEMA
1.2.1. FUNDAMENTACIÓN DEL PROBLEMA
Tabla 1. Problemática general

Causa Problema Efecto
No se cuenta con un recurso No se puede gestionar de forma Demoras en la búsqueda de
que permita administrar la eficiente la información de información específica de
información de contacto de una contacto de una persona. contacto de una persona.
persona.
Fuente: Elaboración Propia.
1
ELECTRÓNICOS
1.2.2. FORMULACIÓN DEL PROBLEMA
¿Cómo lograr la eficiencia en la gestión de la información de contacto de una persona?
1.3. OBJETIVOS
1.3.1. OBJETIVO GENERAL
Desarrollar una agenda automatizada de contactos personales, para registrar y gestionar la

información referente a números de teléfono, direcciones y correos electrónicos; de forma que
permita lograr la eficiencia en la gestión de dicha información.
1.3.2. OBJETIVOS ESPECÍFICOS
• Diseñar el modelo de datos para el almacenamiento de la información, mediante los

modelos Entidad Relación, Relacional y las reglas de normalización.
• Diseñar las interfaces correspondientes para el registro de los datos.
• Realizar la codificación de las funcionalidades correspondientes para el registro de los
datos en la agenda.
• Efectuar la integración de los tres módulos correspondientes para la implementación de
la agenda de contactos.
1.4. ALCANCES
El presente proyecto contempla el desarrollo de una agenda automatizada de contactos

personales, tomando en cuenta la información de números de teléfono, direcciones y correos
electrónicos. Para su desarrollo integral se divide en cuatro áreas esenciales: Gestión de Bases
de Datos, Back End, Front End e Integración. El presente documento corresponde al área de
Gestión de Bases de Datos.
1.5. JUSTIFICACIÓN
El presente proyecto se justifica por la necesidad de gestionar la información de contacto

de una persona. Mediante el desarrollo de una agenda automatizada de contactos personales se
2
ELECTRÓNICOS
puede conseguir la gestión eficiente de dicha información, lo cual es de mucha utilidad a la
hora de realizar la búsqueda de información de una persona determinada, la cual se puede
realizar en menos tiempo y de forma sencilla y eficiente.
3
ELECTRÓNICOS
CAPÍTULO 2
MARCO TEÓRICO
2.1. BASE DE DATOS
Una base de datos es un conjunto de datos pertenecientes a un mismo contexto y

almacenados sistemáticamente para su posterior uso. En este sentido; una biblioteca puede
considerarse una base de datos compuesta en su mayoría por documentos y textos impresos en
papel e indexados para su consulta. Actualmente, y debido al desarrollo tecnológico de
campos como la informática y la electrónica, la mayoría de las bases de datos están en formato
digital, siendo este un componente electrónico, por tanto se ha desarrollado y se ofrece un
amplio rango de soluciones al problema del almacenamiento de datos.
Figura 1. Ejemplo de estructura de una base de datos.

Fuente: Internet.
4
ELECTRÓNICOS
2.1.1. TIPOS DE BASES DE DATOS
• Bases de datos jerárquicas: Los datos se organizan en forma de árbol invertido, en

donde un nodo padre de información puede tener varios hijos. El nodo que no tiene padres es
llamado raíz, y a los nodos que no tienen hijos se los conoce como hojas. Son especialmente
útiles en el caso de aplicaciones que manejan un gran volumen de información y datos muy
compartidos permitiendo crear estructuras estables y de gran rendimiento. Una de las
principales limitaciones de este modelo es su incapacidad de representar eficientemente la
redundancia de datos.
• Base de datos de red: Se diferencia del jerárquico fundamentalmente en la
modificación del concepto de nodo. Se permite que un mismo nodo tenga varios padres
(posibilidad no permitida en el modelo jerárquico). Fue una gran mejora con respecto al
modelo jerárquico, ya que ofrecía una solución eficiente al problema de redundancia de datos;
pero, aun así, la dificultad que significa administrar la información en una base de datos de red
ha significado que sea un modelo utilizado en su mayoría por programadores más que por
usuarios finales.
• Bases de datos transaccionales: Son bases de datos cuyo único fin es el envío y
recepción de datos a grandes velocidades, estas bases son muy poco comunes y están dirigidas
por lo general al entorno de análisis de calidad, datos de producción e industrial. Es importante
entender que su fin único es recolectar y recuperar los datos a la mayor velocidad posible, por
lo tanto la redundancia y duplicación de información no es un problema como con las demás
bases de datos.
• Bases de datos relacionales: Este es el modelo utilizado en la actualidad para
representar problemas reales y administrar datos dinámicamente. Tras ser postulados sus
fundamentos en 1970 por Edgar Frank Codd, no tardó en consolidarse como un nuevo
paradigma en los modelos de base de datos. Su idea fundamental es el uso de relaciones. Estas
relaciones podrían considerarse en forma lógica como conjuntos de datos llamados tuplas. En
este modelo, el lugar y la forma en que se almacenen los datos no tienen relevancia (a
diferencia de otros modelos como el jerárquico y el de red). Esto tiene la considerable ventaja
de que es más fácil de entender y de utilizar para un usuario esporádico de la base de datos.
5
ELECTRÓNICOS
• Bases de datos multidimensionales: Son bases de datos ideadas para desarrollar
aplicaciones muy concretas, como creación de Cubos OLAP. Básicamente no se diferencian
demasiado de las bases de datos relacionales (una tabla en una base de datos relacional podría
serlo también en una base de datos multidimensional). La diferencia está más bien a nivel
conceptual; en las bases de datos multidimensionales los campos o atributos de una tabla
pueden ser de dos tipos, o bien representan dimensiones de la tabla, o bien representan
métricas que se desean aprender.
• Bases de datos orientadas a objetos: Bastante reciente, y propio de los modelos
informáticos orientados a objetos, trata de almacenar en la base de datos los objetos completos
(estado y comportamiento). Incorpora todos los conceptos importantes del paradigma de
objetos: Encapsulación, Herencia y Polimorfismo. En bases de datos orientadas a objetos, los
usuarios pueden definir operaciones sobre los datos como parte de la definición de la base de
datos. Una operación (llamada función) se especifica en dos partes. La interfaz (o signatura)
de una operación incluye el nombre de la operación y los tipos de datos de sus argumentos (o
parámetros). La implementación (o método) de la operación se especifica separadamente y
puede modificarse sin afectar la interfaz.
2.2. MODELO ENTIDAD RELACIÓN
Un diagrama entidad-relación, también conocido como modelo entidad relación o ERD, es

un tipo de diagrama de flujo que ilustra cómo las entidades, como personas, objetos o
conceptos, se relacionan entre sí dentro de un sistema. Los diagramas ER se usan a menudo
para diseñar o depurar bases de datos relacionales en los campos de ingeniería de software,
sistemas de información empresarial, educación e investigación. Emplean un conjunto
definido de símbolos, tales como rectángulos, diamantes, óvalos y líneas de conexión para
representar la interconexión de entidades, relaciones y sus atributos. Son un reflejo de la
estructura gramatical y emplean entidades como sustantivos y relaciones como verbos.
2.2.1. COMPONENTES Y CARACTERÍSTICAS
Los diagramas ER se componen de entidades, relaciones y atributos. También representan

la cardinalidad, que define las relaciones en términos de números.
6
ELECTRÓNICOS
• Entidad: Algo que se puede definir, como una persona, objeto, concepto u evento, que
puede tener datos almacenados acerca de este. Se piensa en las entidades como si fueran
sustantivos. Por ejemplo: un cliente, estudiante, auto o producto. Por lo general se muestran
como un rectángulo. Las entidades se clasifican en fuertes, débiles o asociativas. Una entidad
fuerte se puede definir únicamente por sus propios atributos, en cambio, una entidad débil no.
Una entidad asociativa es aquella que relaciona entidades (o elementos) dentro de un conjunto
de entidades.
Las claves de entidad se refieren a un atributo que únicamente define una entidad en un
conjunto de entidades. Las claves de entidad se dividen en superclave, clave candidata o clave
primaria. Una superclave es un conjunto de atributos (uno o más) que juntos definen una
entidad en un conjunto de entidades. Una clave candidata es una superclave mínima, es decir,
contiene el menor número posible de atributos para seguir siendo una superclave. Un conjunto
de entidades puede tener más de una clave candidata. Una clave primaria es una clave
candidata seleccionada por el diseñador de la base de datos para identificar únicamente al
conjunto de entidades. Además se tienen las claves extranjeras, que identifican la relación
entre las entidades.
• Relación: Cómo las entidades interactúan o se asocian entre sí. Se piensa en las
relaciones como si fueran verbos. Por ejemplo, un estudiante podría inscribirse en un curso.
Las dos entidades serían el estudiante y el curso, y la relación representada es el acto de
inscribirse, que conecta ambas entidades de ese modo. Las relaciones se muestran, por lo
general, como diamantes o etiquetas directamente en las líneas de conexión.
• Atributo: Una propiedad o característica de una entidad. A menudo se muestra como
un óvalo o círculo. Los atributos se clasifican en simples, compuestos y derivados, así como
de valor único o de valores múltiples. Los simples implican que el valor del atributo es
mínimo y ya no puede dividirse, como un número de teléfono. Los compuestos implican que
los subatributos surgen de un atributo. Los derivados hacen referencia a que los atributos se
calculan o derivan de otro atributo, por ejemplo, la edad se calcula a partir de la fecha de
nacimiento. Los de valores múltiples denotan más de un valor del atributo, como varios
números de teléfono para una persona. Los de valor único contienen solo un valor de atributo.
7
ELECTRÓNICOS
Los tipos se pueden combinar, por ejemplo, puede haber atributos de valor único simples o
atributos de múltiples valores compuestos.
• Cardinalidad: Define los atributos numéricos de la relación entre dos entidades o
conjuntos de entidades. Las tres relaciones cardinales principales son uno a uno, uno a muchos
y muchos a muchos. Un ejemplo de uno a uno sería un estudiante asociado a una dirección de
correo electrónico. Un ejemplo de uno a muchos (o muchos a uno, en función de la dirección
de la relación) sería un estudiante que se inscribe en muchos cursos, y todos esos cursos se
asocian a ese estudiante en particular. Un ejemplo de muchos a muchos sería los estudiantes
en grupo que están asociados a múltiples miembros de la facultad y a su vez los miembros de
la facultad están asociados a múltiples estudiantes.
Figura 2. Ejemplo de un diagrama Entidad Relación.

Fuente: Internet.
2.3. MODELO RELACIONAL
Es un modelo de organización y gestión de bases de datos consistente en el

almacenamiento de datos en tablas compuestas por filas, o tuplas, y columnas o campos. Se
distingue de otros modelos, como el jerárquico, por ser más comprensible para el usuario
inexperto, y por basarse en la lógica de predicados para establecer relaciones entre distintos
8
ELECTRÓNICOS
datos. Surge como solución a la creciente variedad de los datos que integran las data
warehouses y podemos resumir el concepto como una colección de tablas (relaciones).
• Tabla: Es el nombre que recibe cada una de las relaciones que se establecen entre los
datos almacenados; cada nueva relación da lugar a una tabla. Están formadas por filas,
también llamadas tuplas, donde se describen los elementos que configuran la tabla (es decir,
los elementos de la relación establecida por la tabla), columnas o campos, con los atributos y
valores correspondientes, y el dominio, concepto que agrupa a todos los valores que pueden
figurar en cada columna.
• Claves: Elementos que impiden la duplicidad de registros, una de las grandes
desventajas que presentan otros modelos de organización y gestión de bases de datos. Existen
dos grandes tipos de claves: las claves primarias y las secundarias o externas.
• Restricción de integridad: Límites y restricciones que se imponen en las relaciones,
imprescindibles para mantener la significación correcta de la base de datos. Es un concepto
íntimamente vinculado a las reglas de integridad propias del modelo relacional, el
cumplimiento de las cuales está garantizado por las claves primarias y externas. Existen 4
tipos básicos de restricciones de integridad:
 Los datos requeridos: Los campos o columnas siempre deben poseer un atributo o un
valor.
 La comprobación de validez: Las tablas deben contener solo los datos
correspondientes a la correspondiente relación definida por cada tabla.
 Las integridades de entidad y referencial: Las primeras aseguran que las claves
primarias posean un valor único para cada tupla, y las segundas que las claves principales y las
externas mantengan su integridad.
9
ELECTRÓNICOS
Figura 3. Estructura de tablas de una base de datos.

Fuente: Internet.
2.4. NORMALIZACIÓN
La normalización es el proceso de organizar los datos de una base de datos. Se incluye la

creación de tablas y el establecimiento de relaciones entre ellas según reglas diseñadas tanto
para proteger los datos como para hacer que la base de datos sea más flexible al eliminar la
redundancia y las dependencias incoherentes. Los datos redundantes desperdician el espacio
de disco y crean problemas de mantenimiento. Si hay que cambiar datos que existen en más de
un lugar, se deben cambiar de la misma forma exactamente en todas sus ubicaciones. Un
cambio en la dirección de un cliente es mucho más fácil de implementar si los datos sólo se
almacenan en la tabla Clientes y no en algún otro lugar de la base de datos.
Hay algunas reglas en la normalización de una base de datos. Cada regla se denomina una
forma normal. Si se cumple la primera regla, se dice que la base de datos está en la primera
forma normal. Si se cumplen las tres primeras reglas, la base de datos se considera que está en
la tercera forma normal. Aunque son posibles otros niveles de normalización, la tercera forma
normal se considera el máximo nivel necesario para la mayor parte de las aplicaciones.
10
ELECTRÓNICOS
2.4.1. PRIMERA FORMA NORMAL
• Se deben eliminar los grupos repetidos de las tablas individuales.

• Se crea una tabla independiente para cada conjunto de datos relacionados.
• Se debe identificar cada conjunto de datos relacionados con una clave principal.
2.4.2. SEGUNDA FORMA NORMAL
• Se deben crear tablas independientes para conjuntos de valores que se apliquen a varios
registros.
• Se relacionan estas tablas con una clave externa.
• Los registros no deben depender de nada que no sea una clave principal de una tabla,
una clave compuesta si es necesario.
2.4.3. TERCERA FORMA NORMAL
• Se deben eliminar los campos que no dependan de la clave.

• Los valores de un registro que no sean parte de la clave de ese registro no pertenecen a
la tabla. En general, siempre que el contenido de un grupo de campos pueda aplicarse a más de
un único registro de la tabla, se considera colocar estos campos en una tabla independiente.
2.5. SISTEMAS GESTORES DE BASES DE DATOS
Un sistema gestor de base de datos (SGBD) es un conjunto de programas que permiten el

almacenamiento, modificación y extracción de la información en una base de datos .Los
usuarios pueden acceder a la información usando herramientas específicas de consulta y de
generación de informes, o bien mediante aplicaciones al efecto. Estos sistemas también
proporcionan métodos para mantener la integridad de los datos, para administrar el acceso de
usuarios a los datos y para recuperar la información si el sistema se corrompe. Permiten
presentar la información de la base de datos en variados formatos. La mayoría incluyen un
generador de informes. También pueden incluir un módulo gráfico que permita presentar la
información con gráficos y tablas.
11
ELECTRÓNICOS
Generalmente se accede a los datos mediante lenguajes de consulta, lenguajes de alto nivel
que simplifican la tarea de construir las aplicaciones. También simplifican las consultas y la
presentación de la información. Un SGBD permite controlar el acceso a los datos, asegurar su
integridad, gestionar el acceso concurrente a ellos, recuperar los datos tras un fallo del sistema
y hacer copias de seguridad.
2.5.1. COMPONENTES DE UN SGBD
• El motor de la base de datos acepta peticiones lógicas de los otros subsistemas del
SGBD, las convierte en su equivalente físico y accede a la base de datos y diccionario de datos
en el dispositivo de almacenamiento.
• El subsistema de definición de datos ayuda a crear y mantener el diccionario de datos y
define la estructura del fichero que soporta la base de datos.
• El subsistema de manipulación de datos ayuda al usuario a añadir, cambiar y borrar
información de la base de datos y la consulta para extraer información. Suele ser la interfaz
principal del usuario con la base de datos. Permite al usuario especificar sus requisitos de la
información desde un punto de vista lógico.
• El subsistema de generación de aplicaciones contiene utilidades para ayudar a los
usuarios en el desarrollo de aplicaciones. Usualmente proporciona pantallas de entrada de
datos, lenguajes de programación e interfaces.
• El subsistema de administración ayuda a gestionar la base de datos ofreciendo
funcionalidades como almacenamiento y recuperación, gestión de la seguridad, optimización
de preguntas, control de concurrencia y gestión de cambios.
2.5.2. TIPOS DE SGBD
• Sistemas Gestores de bases de datos Relacionales (SQL): Desde que se comenzó a

usar el modelo de bases de datos relacionales en 1970, ha ido sufriendo una serie de
transformaciones hasta convertirse, hoy en día, en el modelo más utilizado para administrar
bases de datos. Este modelo se basa fundamentalmente en establecer relaciones o vínculos
entre los datos, imaginando una tabla aparte por cada relación existente con sus propios
12
ELECTRÓNICOS
registros y atributos. Los principales SBGD relacionales actualmente son: MySQL, MariaDB,
SQLite, PostgreSQL, Microsoft SQL Server, Oracle.
• Sistemas Gestores de bases de datos No Relacionales (NoSQL): Una base de datos
no relacional (NoSQL) es aquella base de datos que no requiere de estructuras de datos fijas
como tablas, no garantiza completamente las características ACID y escala muy bien
horizontalmente. Se utilizan en entornos distribuidos que han de estar siempre disponibles y
operativos y que gestionan un importante volumen de datos. Para la administración de este
tipo de bases de datos, actualmente los principales SGBD son: MongoDB, Redis, Cassandra,
Apache CouchDB.
Figura 4. Gestores de Bases de Datos más utilizados.

Fuente: Internet.
2.6. SEGURIDAD DE BASES DE DATOS
La gran mayoría de los datos sensibles del mundo están almacenados en sistemas gestores
de bases de datos comerciales tales como Oracle, Microsoft SQL Server entre otros, y atacar
una base de datos es uno de los objetivos favoritos para los criminales. Mientras que la
atención generalmente se ha centrado en asegurar los perímetros de las redes por medio de,
firewalls, IDS / IPS y antivirus, cada vez más las organizaciones se están enfocando en la
seguridad de las bases de datos con datos críticos, protegiéndolos de intrusiones y cambios no
autorizados. Para ello, se pueden aplicar los siguientes principios de seguridad:
13
ELECTRÓNICOS
• Identificar la sensibilidad: Confeccionar un buen catálogo de tablas o datos sensibles
de las instancias de la base de datos. Además, se debe automatizar el proceso de identificación,
ya que estos datos y su correspondiente ubicación pueden estar en constante cambio debido a
nuevas aplicaciones o cambios producto de fusiones y adquisiciones. Para ello es conveniente
desarrollar o adquirir herramientas de identificación.
• Evaluación de la vulnerabilidad y la configuración: Evaluar la configuración de
bases de datos, para asegurar que no tiene huecos de seguridad. Esto incluye la verificación de
la forma en que se instaló la base de datos y su sistema operativo (por ejemplo, la
comprobación de privilegios de grupos de archivo -lectura, escritura y ejecución- de base de
datos y bitácoras de transacciones). Asimismo con archivos con parámetros de configuración
y programas ejecutables. Además, es necesario verificar que no se está ejecutando la base de
datos con versiones que incluyen vulnerabilidades conocidas; así como impedir consultas SQL
desde las aplicaciones o capa de usuarios. Para ello se puede considerar (como administrador):
 Limitar el acceso a los procedimientos a ciertos usuarios.

 Delimitar el acceso a los datos para ciertos usuarios, procedimientos y/o datos.
 Declinar la coincidencia de horarios entre usuarios que coincidan.
• Endurecimiento: Como resultado de una evaluación de la vulnerabilidad a menudo se

dan una serie de recomendaciones específicas. Este es el primer paso en el endurecimiento de
la base de datos. Otros elementos de endurecimiento implican la eliminación de todas las
funciones y opciones que se no utilicen. Se debe aplicar una política estricta sobre qué se
puede y qué no se puede hacer.
• Auditar: Una vez que se haya creado una configuración y controles de
endurecimiento, se deben realizar autoevaluaciones y seguimiento a las recomendaciones de
auditoría para asegurar que no se desvíe de su objetivo (la seguridad). Se debe automatizar el
control de la configuración de tal forma que se registre cualquier cambio en la misma. Para
ello es conveniente implementar alertas sobre cambios en la configuración. Cada vez que un
cambio se realice, este podría afectar a la seguridad de la base de datos.
• Monitoreo: Un monitoreo en tiempo real de la actividad de base de datos es clave para
limitar su exposición. Para ello se deben aplicar agentes inteligentes de monitoreo, detección
de intrusiones y uso indebido. Por ejemplo, alertas sobre patrones inusuales de acceso, que
14
ELECTRÓNICOS
podrían indicar la presencia de un ataque de inyección SQL, cambios no autorizados a los
datos, cambios en privilegios de las cuentas, y los cambios de configuración que se ejecutan
mediante de comandos de SQL. El monitoreo de usuarios privilegiados es requisito para la
gobernabilidad de datos y cumplimiento de regulaciones de privacidad. También, ayuda a
detectar intrusiones, ya que muchos de los ataques más comunes se hacen con privilegios de
usuario de alto nivel. El monitoreo dinámico es también un elemento esencial de la evaluación
de vulnerabilidad, que permite ir más allá de evaluaciones estáticas o forenses.
• Pistas de Auditoría: Se deben aplicar pistas de auditoría y generar trazabilidad de las
actividades que afectan la integridad de los datos, o la visualización de los datos sensibles.
Esto es un requisito de auditoría, y también es importante para las investigaciones forenses. La
mayoría de las organizaciones en la actualidad emplean alguna forma de manual de auditoría
de transacciones o aplicaciones nativas de los sistemas gestores de bases de datos. Sin
embargo, estas aplicaciones son a menudo desactivadas, debido a su complejidad, altos costos
operativos, problemas de rendimiento, la falta de segregación de funciones y la necesidad de
mayor capacidad de almacenamiento. Afortunadamente, se han desarrollado soluciones con un
mínimo de impacto en el rendimiento y poco costo operativo, basado en tecnologías de
agentes inteligentes.
• Autenticación, Control de acceso, y Gestión de derechos: No todos los datos y no
todos los usuarios son creados iguales. Se debe autenticar a los usuarios, garantizar la
rendición de cuentas por usuario, y administrar los privilegios para limitar el acceso a los
datos. Para ello es necesario implementar y revisar periódicamente los informes sobre
derechos de usuarios, como parte de un proceso de formal de auditoría. Se debe utilizar el
cifrado para hacer ilegibles los datos confidenciales, incluyendo el cifrado de los datos en
tránsito, de modo que un atacante no pueda escuchar en la capa de red y tener acceso a los
datos cuando se envía al cliente de base de datos.
15
ELECTRÓNICOS
CAPÍTULO 3
MARCO PRÁCTICO
3.1. DEFINICION DEL PROYECTO
El presente proyecto tiene por objeto la elaboración de una agenda de contactos personales
para registrar datos de números de teléfono, direcciones y correos electrónicos. Aplicando el
enfoque de la metodología Scrum, el proyecto se divide en 4 áreas esenciales: Gestión de
Bases de Datos, Back End, Front End e Integración. El presente documento se enfoca en el
área de Gestión de Bases de Datos, estructurando el desarrollo en dos sprints de trabajo.
3.2. PRIMER SPRINT
En esta etapa se diseña el modelo de datos para almacenar la información de la agenda de

contactos, mediante la elaboración del modelo Entidad Relación, la aplicación de las reglas de
normalización de bases de datos, la elaboración del Diccionario de Datos, y la implementación
del modelo de datos en un Sistema Gestor de Bases de Datos.
3.2.1 MODELO ENTIDAD RELACIÓN
Figura 5. Diagrama Entidad Relación de la Agenda de contactos.

Fuente: Elaboración propia.
16
ELECTRÓNICOS
3.2.2. NORMALIZACIÓN
• Aplicación de primera forma normal
Se atomizan los siguientes campos en las siguientes tablas:
Tabla 2. Adaptación a primera forma normal

Tabla Campos iniciales Campos resultantes
Persona idpersona idpersona
nombre nombre
fecha_nacimiento apellido
fecha_nacimiento
• Aplicación de segunda y tercera forma normal
Se aplican las reglas de normalización para generar la estructura de tablas del proyecto:
Tabla 3. Estructura de la Tabla Persona

IdContact Name LastName Gender BirdtDate
Tabla 4. Estructura de la Tabla Teléfono

IdContact PhoneNumber PhoneType
Tabla 5. Estructura de la Tabla Dirección

IdContact Address City Country
17
ELECTRÓNICOS
Tabla 6. Estructura de la Tabla Correo
IdContact EMailAddress EmailType
3.2.3. DICCIONARIO DE DATOS
Tabla 7. Diccionario de Datos de la Tabla Persona

Nombre Tipo Tamaño Restricción Descripción
IdContact Autonúmerico 10 [0..9] Código autogenerado
para cada persona.
Name Texto 255 [A..Z, a..z] Nombres de la persona.
LastName Texto 255 [A..Z, a..z] Apellido de la persona.
Gender Texto 10 (Masculino, Género de la persona.
Femenino)
BirdtDate Fecha [dd-mm-yyyy] Fecha de nacimiento de
la persona.
Tabla 8. Diccionario de Datos de la Tabla Teléfono

IdContact Autonúmerico 10 [0..9] Código autogenerado para
cada persona.
PhoneNumber Texto 20 [0..9] Número de teléfono de la
persona.
PhoneType Texto 8 (Móvil, Casa, Tipo de número de
Trabajo) teléfono de la persona.
Tabla 9. Diccionario de Datos de la Tabla Dirección

IdContact Autonúmerico 10 [0..9] Código autogenerado para
cada persona.
Address Texto 255 [A..Z, a..z, Dirección de la vivienda
0..9] de la persona.
City Texto 255 [A..Z, a..z] Ciudad de residencia de la
persona.
Country Texto 255 [A..Z, a..z] País de residencia de la
persona.
18
ELECTRÓNICOS
Tabla 10. Diccionario de Datos de la Tabla Correo
IdContact Autonúmerico 10 [0..9] Código autogenerado
para cada persona.
EMailAddress Texto 255 [A..Z, a..z, Dirección de correo
0..9, @, -, _, .] electrónico de la persona.
EmailType Texto 12 (Personal, Tipo de correo
Corporativo) electrónico de la persona.
3.2.4. IMPLEMENTACIÓN DEL MODELO DE DATOS
Se realiza la implementación del modelo de datos en tres diferentes Sistemas Gestores de

Bases de Datos: Microsoft Access, MySQL y Oracle.
Figura 6. Implementación del modelo de datos en Microsoft Access.

19
ELECTRÓNICOS
Figura 7. Implementación del modelo de datos en MySQL.

Figura 8. Implementación del modelo de datos en Oracle 11g.

3.3. SEGUNDO SPRINT
En esta etapa se implementan las operaciones CRUD (Create, Read, Update, Delete) para
la información de contactos y números de teléfono, utilizando DTOs (Data Transfer Object).
Para ello se crea una serie de archivos de código en la solución creada en Visual Studio 2017
por el equipo de Back End. Además, para posibilitar el desarrollo del proyecto dividido en
áreas, se crea un repositorio público en GitHub para que todos los grupos puedan acceder a la
versión más actual del proyecto y contribuir en su desarrollo. El repositorio tiene la siguiente
dirección URL:
https://github.com/joseCespedesOlmos/Phone-Book
20
ELECTRÓNICOS
3.3.1. ARCHIVO DATA BASE STORAGE
Se crea una nueva carpeta dentro de la solución, en la cual se crea el archivo

DataBaseStorage.cs, el cual tiene la funcionalidad de establecer la conexión entre la Base de
Datos y los DTO generados por el área de Back End. A continuación se muestra el código de
dicho archivo:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using CommonDTO.Models_DTO;
namespace DatabaseStorage
{
public class DataBaseStorage
{
public List<ContactDTO> GetAllPersonas()
{
List<ContactDTO> lstPersona = new List<ContactDTO>();
return lstPersona;
}
public List<PhoneDTO> GetAllTelefonos()

{
List<PhoneDTO> lstTelefono = new List<PhoneDTO>();
return lstTelefono;
}
}
3.3.2. ARCHIVO DATA BASE PROVIDER
También se crea el archivo DataBaseProvider.cs, en el cual se implementan las

operaciones CRUD para la información de contactos y números de teléfono. A continuación se
muestra el código utilizado para tal efecto:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using CommonDTO.Common_Interfaces;
using CommonDTO.Models_DTO;
namespace DatabaseStorage
{
21
ELECTRÓNICOS
class DataBaseProvider : IPhoneBookProvider
{
private DataBaseStorage _dataBaseProvider;
public object Persona { get; private set; }
public DataBaseProvider()
{
_dataBaseProvider = new DataBaseStorage();
}
public bool DeleteContact(Guid contactId)

{
var entity3 = this.ObjectContext.FirstOrDefault(row => row.IdContact ==
Persona.IdContact);
this.ObjectContext.DeleteObject(result);
this.ObjectContext.SaveChanges();
return true;
}
public bool DeletePhone(string phoneNumber)

{
var entity4 = this.ObjectContext.FirstOrDefault(row => row.PhoneNumber ==
Telefono.PhoneNumber);
this.ObjectContext.DeleteObject(result);
this.ObjectContext.SaveChanges();
return true;
}
public List<ContactDTO> GetContactList()

{
return this.ObjectContext.Persona;
}
public List<PhoneDTO> GetPhoneList(Guid contactId)

{
return this.ObjectContext.Telefono;
}
public bool InsertContact(ContactDTO contact)

{
if ((contact.EntityState != EntityState.Detached))
{
this.ObjectContext.ObjectStateManager.ChangeObjectState(contact,
EntityState.Added);
}
else
{
this.ObjectContext.Persona.AddObject(contact);
}
return true;
}
public bool InsertPhone(PhoneDTO phone)

{
if ((phone.EntityState != EntityState.Detached))
{
this.ObjectContext.ObjectStateManager.ChangeObjectState(phone,
EntityState.Added);
22
ELECTRÓNICOS
}
else
{
this.ObjectContext.Telefono.AddObject(phone);
}
return true;
}
public bool UpdateContact(ContactDTO contact)

{
var entity = this.ObjectContext.Persona.FirstOrDefault(row =>
row.IdContact == Persona.IdContact);
entity.Name = Persona.Name;
entity.LastName = Persona.LastName;
entity.Gender = Persona.Gender;
entity.BirdtDate = Persona.BirdtDate;
Context.SaveChanges();
return true;
}
public bool UpdatePhone(PhoneDTO phone)

{
var entity2 = this.ObjectContext.Telefono.FirstOrDefault(row =>
row.IdContact == Telefono.IdContact);
entity2.PhoneNumber = Telefono.PhoneNumber;
entity2.PhoneType = Telefono.PhoneType;
Context.SaveChanges();
return true;
}
}
}
CAPÍTULO 4
CONCLUSIONES Y RECOMENDACIONES
4.1. CONCLUSIONES
• Se desarrolló con éxito una agenda automatizada de contactos personales para registrar
y gestionar la información referente a números de teléfono, direcciones y correos electrónicos;
de forma que permite lograr la eficiencia en la gestión de dicha información.
• Se realizó el diseño del modelo de datos para el almacenamiento de la información que
administra la agenda de contactos.
• Se efectuó el diseño de las interfaces para el registro de los datos correspondientes a la
agenda de contactos.
• Se realizó la codificación de las funcionalidades correspondientes para el registro de
los datos.
23
ELECTRÓNICOS
• Se efectuó la integración de los módulos correspondientes para la implementación de la
agenda de contactos.
4.2. RECOMENDACIONES
• Para una realización integral del proyecto, es conveniente dividirlo en áreas (Gestión
de Bases de Datos, Back End, Front End e Integración), ya que este enfoque es el más
aplicado en los procesos de desarrollo de software en la actualidad.
• Para llevar un seguimiento eficiente del proyecto, es conveniente definir tareas
específicas para cada área. Su realización debe ser monitoreada por el área de Integración,
para garantizar la conclusión del proyecto en los tiempos establecidos.
• Se debe procurar una comunicación frecuente y fluida entre las áreas, para garantizar
que todas trabajan bajo los mismos parámetros, lo cual es de vital importancia para la
conclusión satisfactoria del proyecto.
BIBLIOGRAFÍA
• Conceptos básicos del diseño de una base de datos. Recuperado el 10 de junio de 2019
de https://support.office.com/es-es/article/conceptos-b%C3%A1sicos-del-dise%C3%B1o-de-
una-base-de-datos-eb2159cf-1e30-401a-8084-bd4f9c9ca1f5
• Qué es un diagrama entidad-relación. Recuperado el 10 de junio de 2019 de
https://www.lucidchart.com/pages/es/que-es-un-diagrama-entidad-relacion.
• Modelo relacional en la gestión de bases de datos. Recuperado el 10 de junio de 2019
de https://blog.es.logicalis.com/analytics/conceptos-basicos-del-modelo-relacional-en-la-
gestion-de-bases-de-datos
• Fundamentos de la normalización de bases de datos. Recuperado el 10 de junio de
2019 de https://support.microsoft.com/es-bo/help/283878/description-of-the-database-
normalization-basics
• Principios Básicos de Seguridad en Bases de Datos. Recuperado el 10 de junio de
2019 de https://revista.seguridad.unam.mx/numero-12/principios-basicos-de-seguridad-en-
bases-de-datos
24

Proyecto Tecnologias Informaticas

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Proyecto Tecnologias Informaticas

Caricato da

Copyright:

Formati disponibili

UNIVERSIDAD DE AQUINO BOLIVIA

FACULTAD DE CIENCIAS Y TECNOLOGÍA

DESARROLLO DE UNA AGENDA AUTOMATIZADA DE CONTACTOS PERSONALES

DOCENTE: ING. FRANK SEJAS MARAÑÓN

CAPÍTULO 1. MARCO REFERENCIAL

1.1. INTRODUCCIÓN .............................................................................................................. 1

1.2. SITUACIÓN ACTUAL DEL PROBLEMA .................................................................... 1

1.2.1. FUNDAMENTACIÓN DEL PROBLEMA .................................................................. 1

1.2.2. FORMULACIÓN DEL PROBLEMA .......................................................................... 2

1.3. OBJETIVOS ....................................................................................................................... 2

1.3.1. OBJETIVO GENERAL ................................................................................................ 2

1.3.2. OBJETIVOS ESPECÍFICOS ........................................................................................ 2

1.4. ALCANCES ........................................................................................................................ 2

1.5. JUSTIFICACIÓN ............................................................................................................... 2

CAPÍTULO 2. MARCO TEÓRICO

2.1. BASE DE DATOS .............................................................................................................. 4

2.1.1. TIPOS DE BASES DE DATOS .................................................................................... 5

2.2. MODELO ENTIDAD RELACIÓN .................................................................................. 6

2.2.1. COMPONENTES Y CARACTERÍSTICAS ................................................................ 6

2.3. MODELO RELACIONAL ................................................................................................ 8

2.4. NORMALIZACIÓN ........................................................................................................ 10

2.4.2. SEGUNDA FORMA NORMAL................................................................................. 11

2.4.3. TERCERA FORMA NORMAL ................................................................................. 11

2.5. SISTEMAS GESTORES DE BASES DE DATOS ........................................................ 11

2.5.1. COMPONENTES DE UN SGBD ............................................................................... 12

2.5.2. TIPOS DE SGBD ........................................................................................................ 12

2.6. SEGURIDAD DE BASES DE DATOS........................................................................... 13

CAPÍTULO 3. MARCO PRÁCTICO

3.1. DEFINICION DEL PROYECTO ................................................................................... 16

3.2. PRIMER SPRINT ............................................................................................................ 16

3.2.1 MODELO ENTIDAD RELACIÓN ............................................................................. 16

3.2.2. NORMALIZACIÓN ................................................................................................... 17

3.2.3. DICCIONARIO DE DATOS ...................................................................................... 18

3.2.4. IMPLEMENTACIÓN DEL MODELO DE DATOS .................................................. 19

3.3. SEGUNDO SPRINT ......................................................................................................... 20

3.3.1. ARCHIVO DATA BASE STORAGE ........................................................................ 21

3.3.2. ARCHIVO DATA BASE PROVIDER ....................................................................... 21

CAPÍTULO 4. CONCLUSIONES Y RECOMENDACIONES

4.1. CONCLUSIONES ............................................................................................................ 23

Tabla 1. Problemática general ................................................................................................... 1

Tabla 2. Adaptación a primera forma normal .......................................................................... 17

Tabla 3. Estructura de la Tabla Persona.................................................................................. 17

Tabla 4. Estructura de la Tabla Teléfono ................................................................................. 17

Tabla 5. Estructura de la Tabla Dirección ............................................................................... 17

Tabla 6. Estructura de la Tabla Correo ................................................................................... 18

Tabla 7. Diccionario de Datos de la Tabla Persona ................................................................ 18

Tabla 8. Diccionario de Datos de la Tabla Teléfono ............................................................... 18

Tabla 9. Diccionario de Datos de la Tabla Dirección ............................................................. 18

Tabla 10. Diccionario de Datos de la Tabla Correo ................................................................ 19

Figura 1. Ejemplo de estructura de una base de datos. ............................................................... 4

Figura 2. Ejemplo de un diagrama Entidad Relación. ................................................................ 8

Figura 3. Estructura de tablas de una base de datos. ................................................................ 10

Figura 4. Gestores de Bases de Datos más utilizados. ............................................................. 13

Figura 5. Diagrama Entidad Relación de la Agenda de contactos. .......................................... 16

Figura 6. Implementación del modelo de datos en Microsoft Access. ..................................... 19

Figura 7. Implementación del modelo de datos en MySQL. .................................................... 20

Figura 8. Implementación del modelo de datos en Oracle 11g. ............................................... 20

En el entorno del mercado actual, la competitividad y la rapidez de maniobra de una

En informática se conoce como dato a cualquier elemento informativo que tenga

1.2. SITUACIÓN ACTUAL DEL PROBLEMA

1.2.1. FUNDAMENTACIÓN DEL PROBLEMA

Tabla 1. Problemática general

¿Cómo lograr la eficiencia en la gestión de la información de contacto de una persona?

1.3.1. OBJETIVO GENERAL