Modelo de Proyecto - Base de Datos

MINISTERIO VICEMINISTERIO DIRECCIÓN REGIONAL DE INSTITUTO DE EDUCACIÓN SUPERIOR TECNOLÓGICO
PERÚ DE DE EDUCACIÓN DE LIMA PÚBLICO

EDUCACIÓN GESTIÓN INSTITUCIONAL METROPOLITANA “ARGENTINA”
INSTITUTO DE EDUCACIÓN SUPERIOR TECNOLÓGICO PÚBLICO
ARGENTINA
MODELAMIENTO, DISEÑO E IMPLEMENTACIÓN DE UNA BASE DE

DATOS PARA LA UNIVERSIDAD PERUANA DE LAS AMÉRICAS
(Proceso de Admisión y Matricula)
ESPECIALIDAD DE COMPUTACIÓN E INFORMÁTICA
Unidad Didáctica: Taller de Base de Datos
Docente: Mg. Quito Cerna Oscar
INTEGRANTES:
*
*
LIMA – PERÚ
2019
AGRADECIMIENTO
Agradecemos plenamente a Dios por habernos guiado por el sendero del aprendizaje
y el conocimiento, para alcanzar nuestras metas, así como también agradecer a los profesores
del Instituto de Educación Superior Tecnológico Público de las Fuerzas Armadas, por
transmitirnos sus conocimientos y experiencias profesionales a lo largo de nuestra formación
académica, así mismo, queremos agradecer a nuestros padres quienes nos brindan su apoyo
incondicional, en esta etapa de nuestros estudios superiores. Gracias a todas las personas que
ayudaron directa e indirectamente en la realización de este proyecto.
DEDICATORIA
Dedicamos nuestro proyecto de investigación a nuestros familiares, en especial a

nuestros padres, por el apoyo económico y moral brindado en los momentos difíciles, así
como también dedicamos nuestra investigación al docente Mg. Quito Cerna Oscar por toda la
colaboración brindada durante la elaboración de este proyecto.
1
ÌNDICE
AGRADECIMIENTO .................................................................................................................. 1
DEDICATORIA ........................................................................................................................... 2
INTRODUCCIÓN ........................................................................................................................ 5
CAPÍTULO I
SITUACIÓN ACTUAL DE LA EMPRESA
1.1. Descripción de la Empresa................................................................................................ 7

1.2. Organigrama de la Empresa.............................................................................................. 9
1.3. Datos Generales………………………………………………………………………… 10
1.4. Ubicación Geográfica de la Empresa............................................................................. 10
1.5. Visión………………………………………………………………………………………… 11
1. 6.Misión …………………………………………………………………………………..… 11
CAPÍTULO II
EL PROBLEMA DE LA INVESTIGACIÓN
2. 1. Planteamiento del Problema............................................................................................ 12

2.2. Formulación del Problema................................................................................................ 13
2. 3.Objetivos de la Investigación ........................................................................................... 13
2.3.1. Objetivo General...................................................................................................... 13
2.3.2. Objetivo Especifico..................................................................................................... 13
2.4. Hipótesis………………………………………………………………………………………… 14
2.5. Justificación…………………………………………………………………………………… 14
2.6. Limitaciones ………………………………………………………………………………. 14
2. 7. Metodología de la Investigación...................................................................................... 15
CAPÍTULO III
MARCO TEÓRICO
3. 1. Modelo Entidad Relación.................................................................................................. 16

3.1. 1.Entidad……………………………………………………………………………… 16
3.1.2.Atributo……………………………………………………………………………… 17
3.1.2.1. Tipos de Atributos................................................................... 17
3.1.3.Relación………………………………………………………………………………. 18
2
3.1.4.Cardinalidad………………………………………………………………………. 18
3. 2.El Proceso de Normalización ........................................................................................... 19
3.2.1.Primera Forma Normal .............................................................................................. 20
3.2.2.Segunda Forma Normal ............................................................................................ 21
3.2.3.Tercera Forma Normal .............................................................................................. 23
3.2.4.Cuarta Forma Normal ................................................................................................ 25
3.2.5.Quinta Forma Normal ................................................................................................ 26
3. 3.Gestores de Base de Datos Relacional ......................................................................... 29
3.3.1.SQL Server 2014 ........................................................................................................ 32
3.3.2.Características ………………………………………………………………………. 33
3.3.3.Requisitos para su Instalación .................................................................................. 35
3.3.4.Tipos de Datos en SQL Server ................................................................................ 37
3. 4.Definición de Tabla …………………………………………………………………………. 38
3.4.1.Definición de Tabla ..................................................................................................... 38
3.4.2.Definición de Índices .................................................................................................. 38
3.4.3.Definición de Procedimientos Almacenado ............................................................ 38
3.4.4.Definición de Desencadenador ................................................................................ 39
CAPITULO IV
DISEÑO E IMPLEMENTACION DE LA SOLUCION
4. 1.Modelo Entidad Relación de la Base de Datos ............................................................. 40

4. 2.Diagrama Entidad Relación de la Base de Datos ......................................................... 41
4.2. 1.El Diagrama Lógico de la Base de Datos ............................................................... 41
4.2.2. El Diagrama Físico de la Base de Datos............................................................... 42
4.3.El Script de la Base de Datos .......................................................................................... 43
4.4.El Diagrama Físico de la Base de Datos en SQL Server ............................................ 53
4.5.Restricciones…………………………………………………………………………… 54
4.6.Inserción de Registros ...................................................................................................... 55
CONCLUCIONES ......................................................... 57
RECOMENDACIONES............................................................................................................ 58
REFERENCIA BIBLIOGRÁFICA ........................................................................................ 59
3
INTRODUCCIÓN
Actualmente los Sistemas de Información cumplen un papel fundamental para las

empresas, porque facilitan la automatización y sistematización de los procesos comerciales de
toda Unidad Estratégica de Negocio. Sin embargo, los Sistemas de Información necesitan de
una Base de Datos para realizar el almacenamiento de la información. Como todo Sistema de
Información, éste realiza cuatro actividades básicas; la entrada de datos, el procesamiento de
datos, almacenamiento y salida de datos. Sin embargo, existe una quinta actividad la
retroalimentación, la cual consiste en volver a ingresar los datos que salieron del Sistema
Informático.
En ese sentido la Universidad Peruana las Américas, tiene la necesidad de aplicar una
reingeniería de software en su Sistema Informático actual, el cual maneja solo el proceso de
matrícula, por lo que surge la necesidad de integrar en una sola base de datos para el Procesos
de Admisión y Matrícula. En ese sentido el presente proyecto busca implementar una Base de
Datos que contemple el Proceso de Admisión y Matrícula. Para tener una mejor comprensión
de la presente investigación, ésta se ha estructurado por capítulos, a continuación, se detallan
cada uno de ellos.
En el Capítulo I, se describe la Situación Actual de la Universidad Peruana de las

Américas, siendo un primer punto a abordar la Descripción de la Empresa, aquí se describe la
principal actividad económica de la empresa, así como también su fecha de creación, luego se
hace mención al Organigrama en donde se muestra la estructura jerárquica organizacional.
En el Capítulo II, se presenta el Problema de Investigación, Planteamiento del

Problema, aquí se enfoca la problemática de la organización, donde será la razón por la que se
lleva a cabo este proyecto, también se encuentra Formulación del Problema, Los Objetivos de
la Investigación; que será lo que se quiere lograr al finalizar este proyecto. Mediante la
Hipótesis se intenta explicar la problemática situacional; finalmente a través de la
Justificación se explica la razón de ser de la presente investigación y mediante la Metodología
de la Investigación se explica cuáles han sido las técnicas y/o herramientas utilizadas para
4
llevar a cabo la presente investigación; así como también la Metodología utilizada para la
Implementación de la Base de Datos.
En el Capítulo III, se ha hecho mención al Marco Teórico, en dónde se fundamenta

las diversas teorías que forman parte de nuestra investigación y contiene definiciones como el
Modelo Entidad Relación, el Proceso de Normalización, Gestores de Base de Datos y Tablas.
En el Capítulo VI, se visualizará el Diseño e Implementación de la Solución; que

abarcará el Modelo Entidad Relación y Diagrama Entidad Relación (Diagrama Lógico y
Físico) de la Base de Datos, el Script de la Base de Datos, el Diagrama Físico de la Base de
Datos en SQL Server, Restricciones de Campo, Inserción de Registros, finalmente las
Conclusiones y Recomendaciones.
CAPÍTULO I
SITUACIÓN ACTUAL DE LA EMPRESA
1.1. Descripción de la Empresa
El 10 de octubre del 2002, en Lima, la Doctora Lastenia Fernández Pérez suscribió

en su calidad de Gerente General la Minuta conteniendo el Acto de Fundación, el Acuerdo de
Constitución Social y el Estatuto de la Universidad de las Américas, cuya sede y domicilio se
fija en la Capital de la República del Perú. Iniciadas las actividades institucionales y
desarrolladas con convicción académica y compromiso social durante el plazo establecido por
la normatividad vigente, se aprobó las cinco evaluaciones anuales exigidas por ley, gracias a
la dirección estratégica y labor tesonera de sus Promotores y Presidentes Fundadores, Dra.
Lastenia Fernández Pérez y Dr. Luís Hurtado Valencia, quienes contaron con la permanente
colaboración de los distinguidos profesionales universitarios que asumieron la tarea de llevar
adelante el Proceso de Auto evaluación. El Grado Satisfactorio con el que nuestra Universidad
aprobó las evaluaciones requeridas, fue posible debido a que los objetivos, metas y
compromisos establecidos en el Plan de Desarrollo Institucional, se cumplieron con
oportunidad, eficiencia y excelencia, lo cual condujo al logro de una adecuada calidad
5
académica, ética, económica y administrativa. Así, el viernes 20 de marzo de 2009 a las 19:00
horas se llevó a cabo, con la presencia del Presidente de la Asamblea Nacional de Rectores,
doctor Iván Rodríguez Chávez, la solemne Ceremonia de Entrega de la Resolución N° 100-
2009CONAFU, que otorga la autorización definitiva de funcionamiento y plena autonomía
universitaria, conforme a la Constitución y la normatividad vigente, a la Universidad Peruana
De Las Américas, al mismo tiempo que reconoce al doctor Luis Hurtado Valencia como su
primer Rector. Con este acto formal, nuestra Casa Superior de Estudios dio comienzo a una
nueva etapa en su vida institucional, considerando que la autorización definitiva de
funcionamiento supone el primer paso importante de una Universidad joven en proceso de
desarrollo. En la actualidad, contamos con nueve carreras universitarias que ofrecemos y
ponemos a disposición de la comunidad nacional, por lo que reconociéndonos parte de ella,
expresamos de manera muy especial nuestro saludo y agradecimiento a nuestros alumnos y a
los padres de familia que confían la formación de sus hijos a nuestra institución,
exhortándolos a seguir por las rutas del éxito, para asumir un liderazgo personal y de
responsabilidad social en el proceso de cambios positivos que vive nuestro país. La
Universidad Las Américas agradece a la sociedad peruana la confianza depositada en nuestra
Alma Mater para formar profesionales con excelencia en conocimientos y valores humanos,
objetivo que logramos a través del trabajo en equipo y el compromiso social que nos inspira,
con plena conciencia de que el principal capital en el mundo es la persona humana.
6
1.2. Organigrama de la Empresa
1.3. Datos Generales
• Razón Social: UNIVERSIDAD PERUANA DE LAS AMÉRICAS SAC
• RUC: 20506690928
7
• Representante Legal: Rector, Dr. LUIS HURTADO VALENCIA

• Gerente General: LASTENIA FERNÁNDEZ PÉREZ
• Dirección: Av. Garcilaso de la Vega N° 1880 Cercado de Lima, Perú 1.4. Ubicación
Geográfica de la Empresa
La Universidad las Américas, se encuentra ubicada en la Av. Garcilaso de la Vega N°

1880, en el Cercado de Lima.
Fuente: “Ubicación Geográfica”. Recuperado de

https://www.google.com.pe/maps/place/Universidad+Las+Américas
1.5. Visión
Ser líder en formación universitaria de profesionales con alto nivel académico y

ético, impulsando la innovación, competitividad y liderazgo, contribuyendo al desarrollo
nacional orientada a la acreditación con estándares internacionales.
1.6. Misión
8
Formar profesionales líderes, emprendedores e innovadores con

responsabilidad social y ética comprometidos con la preservación del medio ambiente y con
visión global para contribuir al bienestar de la sociedad.
9
CAPÍTULO II
EL PROBLEMA DE LA INVESTIGACIÓN
2.1. Planteamiento del Problema
El Proceso de Admisión y Matrícula en la Universidad Peruana de las Américas, está

inmerso en una situación de recopilar, organizar y agrupar los datos de los postulantes de
manera distinta, a pesar de que en muchos casos se tratan de los mismos datos, por lo tanto,
los sistemas de apoyo que cuenta, no integran los datos obtenidos en cada una de las fases;
enfocándonos en el presente proyecto; se define que ya existe un Sistema Informático y por
ende que ya existe una Base de Datos; por lo tanto, se debe dejar en claro que existe la
necesidad de Implementar una nueva Base de Datos, que contemple el Proceso de Admisión y
Matrícula, debido a que dicho proceso actualmente se encuentra parcialmente sistematizado
en hojas de cálculo de Microsoft Excel y se lleva a cabo de forma manual.
El Proceso de Admisión y Matrícula en la Universidad Peruana de las Américas se

realiza dos veces al año, el primer semestre académico se lleva a cabo en el mes de marzo y el
segundo semestre se realiza en el mes de setiembre, donde existen diversas modalidades de
admisión, tales como: Primeros puestos de colegios secundarios, Graduados y Titulados,
Deportistas Calificados y Estudios Superiores de dos años como mínimo. A través de este
proceso se acopian datos primigenios de los postulantes, los cuales han de ser procesados y
transformados en información relevante para la toma de decisiones, ya que la información
debe considerarse como uno de los principales recursos de la empresa, por lo que necesita de
un adecuado tratamiento y organización; puesto que como se manifestó, hoy no se integran
los datos que se obtienes en cada una de las etapas.
2.2. Formulación del Problema
El presente estudio tiene como finalidad analizar, modelar, diseñar e implementar

una nueva Base de Datos que facilite la integración del Proceso de Admisión y Matricula de la
Universidad Privada de las Américas.
Mediante el análisis de requerimientos del usuario y la aplicación de la técnica del Modelo

Entidad Relación (MER), se procederá a identificar el conjunto de entidades, relaciones,
10
atributos y cardinalidades, luego se aplicará el Proceso de Normalización para evitar la

redundancia de datos entre las entidades; finalmente se creará la Base de Datos en el gestor de
Base de Datos Relacional SQL Server. Para llevar acabo todo este procedimiento es
fundamental conocer como la Universidad Peruana de las Américas lleva a cabo su proceso de
Admisión y Matricula.
Con la implementación de una Nueva Base de Datos que contemple los Procesos de Admisión
y Matricula se busca la integración de la información, para su posterior sistematización de los
procesos antes mencionados.
2.3. Objetivos de la Investigación

2.3.1. Objetivo General
Implementar una nueva Base de Datos que contemple el Proceso de
Admisión de la Universidad Peruana de las Américas
2.3.2. Objetivo Especifico

Analizar los requerimientos de usuario
Aplicar la técnica del Modelo Entidad Relación.
Aplicar el Proceso de Normalización.
Crear la Base de Datos en el Gestor de Base de Datos Relacional de
SQL Server.
2.4. Hipótesis
Mediante la implementación de una Base de Datos que contemple el Proceso de

Admisión y Matrícula, mejorará de forma significativa las actividades de gestión Académica
y Administración de la Universidad Peruana de las Américas.
2.5. Justificación
La presente investigación se lleva a cabo a raíz de la necesidad de Integración de la

información de los Procesos de Admisión y Matricula de los estudiantes de Pregrado y
Posgrado de la Universidad Peruana de las Américas. Dado que actualmente ambos procesos
de negocio se encuentran parcialmente automatizados; donde el proceso de matrícula se lleva
a cabo mediante el uso de un software de escritorio (Microsoft Excel) el cual tiene acceso a
una Base de Datos, la misma que solo contempla el Proceso de Matricula de los estudiantes de
Pregrado.
11
En este sentido la Universidad es consciente de que actualmente muchos de sus estudiantes

requieren continuar sus estudios de Postgrado y ello demanda llevar a cabo un nuevo Proceso
de Admisión y actualmente dicho proceso se lleva a cabo a través de formularios en Excel por
lo que muchas veces se requiere cruzar información respecto a los estudiantes que postularon
y aún no han sido matriculados, otra de las razones es consultar información respecto a
determinar el número de postulantes a las diversas carreras que ofrece la Universidad Peruana
de las Américas.
Es por ello la necesidad de unificar ambos procesos en una sola Base de Datos.
2.6. Limitaciones
Se tiene como limitación temporal el factor tiempo, el mismo que debe ser superado,
para llevar a cabo el Proceso de Admisión y Matrícula para la Universidad Peruana de las
Américas.
2.7. Metodología de la Investigación
Mediante el análisis de requerimientos del usuario y la aplicación de la técnica del

Modelo Entidad Relación (MER), se procederá a identificar el conjunto de entidades,
relaciones, atributos y cardinalidades, luego se aplicará el Proceso de Normalización para
evitar la redundancia de datos entre las entidades, para ello se hará uso de la herramienta de
software ERwin Data Modeler 7.3 para diseñar y construir el Modelo Entidad Relación;
finalmente se creará la Base de Datos en el gestor de Base de Datos Relacional SQL Server
2014. Para llevar acabo todo este procedimiento es fundamental conocer como la Universidad
Peruana de las Américas lleva a cabo su proceso de Admisión y Matricula.
Se planea implementar una Nueva Base de Datos para la Universidad Peruana de las
Américas en el Proceso de Admisión y Matricula. A través de este proceso se acopian datos
principales de los postulantes, los cuales han de ser procesados y transformados en
información relevante para la toma de decisiones de la organización.
12
CAPÍTULO III
MARCO TEÓRICO
3.1. Modelo Entidad Relación
Según Peter P. Chen (1976). “Inicialmente se divulgo como Modelo Entidad –

Interrelación, pero posteriormente a traducciones adecuadas y hasta el día de hoy se le
conoce como Modelo Entidad Relación”. Es la técnica más utilizada para diseñar Base de
Datos, a partir del “análisis de la realidad” y de los “supuestos semánticos “o “reglas de
negocio”. El MER es el proceso creativo para el que no existe un procedimiento definido;
sin embargo, si es posible seguir recomendaciones o “heurísticas” que nos ayuden en el
diseño. El modelo permite una robusta representación de la totalidad de información que
se requiere para la Base de Datos, eliminando redundancia y siendo el punto de partida
para socializar con el cliente o usuario final, pues el modelo es fácil interpretación por
parte de este, al presentar una visión simplificada del negocio. Algunas definiciones
básicas son:
- Entidades - Relación
- Atributos - Cardinalidades
3.1.1. Entidad
Se puede definir como entidad a cualquier objeto real o abstracto que existe en un
determinado contexto o puede llegar existir y del cual deseamos guardar información. La
entidad generalmente denota: personas, lugares, cosas(objetos) o eventos de interés.
En las entidades se clasifican en:

- Entidad fuerte o Entidad padre.
- Entidad débil o Entidad Hijo.
- Entidad Asociativa.
• Entidad Fuerte: Es aquella existencia propia y que posee identificadores internos que
determinan de manera única la existencia de sus ocurrencias.
• Entidad Débil: Puede serlo de dos motivos:

a) Porque su existencia en la base de datos depende de una entidad fuerte.
b) Porque requiere de su identificación a través de los atributos identificadores principales
de otra entidad. No posee atributos identificadores internos propios que permitan la
13
identificación de cada una de las ocurrencias y requiere la presencia de atributos

identificadores externos.
cardinalidad es de muchos (varios) a muchos.
3.1.2. Atributo
Son cada una de las propiedades o características que tienen las entidades, cada
ejemplar de una entidad, posee os mismos atributos, tanto en nombre como en número
diferenciándose cada uno de los ejemplares por os valores que toman dichos atributos.
3.1.2.1. Tipos de Atributos

a) Atributo Obligatorio
Son aquellos que deben tomar un valor y no se permite que ningún ejemplar no tenga un valor
determinado en el atributo.
b) Atributo Opcional
Son aquellos que pueden tener valores o no tenerlos.
c) Atributo Monoevaluado
Son aquellos que solo pueden tener un único valor.
d) Atributo Multievaluado
Son aquellos que tienen varios valores.
- Numero telefónico de un cliente
- Correo electrónico de un cliente
3.1.3. Relación
Es un enlace lógico entre dos o más entidades que se representa una regla de negocio o
una restricción. Para establecer una relación entre entidades, debe existir los siguientes
elementos:
• Llave Primaria: Es un atributo de llave simple o un conjunto de atributos de una llave

compuesta dentro de una entidad. La llave primaria está posicionada sobre la línea de
una entidad de ERwin Data Modeler. La llave primaria es el valor que puede
identificar a los registros (tuplas o filas) como únicos. También se le conoce como
Atributo Identificador Principal, clave principal, clave primaria o primary key (PK).
14
• Llave Foránea: La llave foránea es una llave primaria de una entidad fuerte (Padre) que
es agregada (“migrada”) a la entidad débil (Hija) a través de una relación. Una llave
foránea, es aquel valor que permite enlazar entidades que cuenten con una llave
primaria o clave principal. También se le conoce como Atributo Identificador Externo,
clave externa, clave secundaria, clave foránea, atributo externo, foreign key (FK).
3.1.4. Cardinalidad
Hay una restricción importante que se declara gráficamente en las relaciones entre
entidades. Para ser más específico en el Diagrama Entidad Relacion (DER) y se le llama
cardinalidad, a cuál representa que tantas veces una cosa se representa o relaciona con otra. La
cardinalidad se representa con un valor numero siendo cero el valor mínimo. El valor mínimo
describe si la relación es opcional o requerida.
3.2. El Proceso de Normalización
Según Piattini (199). “Es el proceso de organización, simplificación y cambios que se

hacen de los datos en un base de datos; sus objetivos son tener almacenados con el menor
espacio posible, eliminar datos repetido, eliminar errores lógicos y tener los datos ordenados”.
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. La simplificación debe darse sin
que haya perdida de información. Este proceso se hace después y durante la fase de
modelamiento.
En la teoría de bases de datos relacionales, las formas normales (FN) proporcionan los
criterios para determinar el grado de vulnerabilidad de una tabla a inconsistencias y anomalías
lógicas. Cuanto más alta sea la forma normal aplicable a una tabla, menos vulnerable será a
inconsistencias y anomalías. Edgar F. Codd originalmente definió las tres primeras formas
normales (1FN, 2FN, y 3FN) en 1970. Estas formas normales se han resumido como
requiriendo que todos los atributos sean atómicos, dependan de la clave completa y en forma
directa (no transitiva). La forma normal de Boyce-Codd (FNBC) fue introducida en 1974 por
los dos autores que aparecen en su denominación. La cuarta y quinta formas normales (4FN y
5FN) se ocupan específicamente de la representación de las relaciones muchos a muchos y
uno a muchos entre los atributos y fueron introducidas por Fagin en 1977 y 1979
15
respectivamente. Cada forma normal incluye a las anteriores. Antes de dar los conceptos de
formas normales veamos unas definiciones previas:
Dependencia funcional: A → B, representa que B es funcionalmente dependiente de A.

Para un valor de A siempre aparece un valor de B. Ejemplo: Si A es el D.N.I., y B el
Nombre, está claro que para un número de D.N.I, siempre aparece el mismo nombre de
titular.
Dependencia funcional completa: A→B, si B depende de A en su totalidad. Ejemplo:

Tiene sentido plantearse este tipo de dependencia cuando A está compuesto por más de
un atributo. Por ejemplo, supongamos que A corresponde al atributo compuesto:
D.N.I._Empleado + Cód._Dpto. y B es Nombre_Dpto. En este caso B depende del
Cod_Dpto., pero no del D.N.I._Empleado. Por tanto, no habría dependencia funcional
completa.
Dependencia transitiva: A→B→C. Si A→B y B→C, Entonces decimos que C

depende de forma transitiva de A. Ejemplo: Sea A el D.N.I. de un alumno, B la
localidad en la que vive y C la provincia. Es un caso de dependencia transitiva A→B
→C.
Determinante funcional: todo atributo, o conjunto de ellos, de los que depende algún
otro atributo. Ejemplo: El D.N.I. es un determinante funcional pues atributos como
nombre, dirección, localidad, etc., dependen de él.
Dependencia multivaluada: A→→B. Son un tipo de dependencias en las que un

determinante funcional no implica un único valor, sino un conjunto de ellos. Un valor
de A siempre implica varios valores de B. Ejemplo: CursoBachillerato→→Modalidad.
Para primer curso siempre va a aparecer en el campo Modalidad uno de los siguientes
valores: Ciencias, Humanidades/Ciencias Sociales o Artes. Igual para segundo curso.
3.2.1. Primera Forma Normal
16
Una Relación está en 1FN si y sólo si cada atributo es atómico. Ejemplo:

Supongamos que tenemos la siguiente tabla con datos de alumnado de un centro de enseñanza
secundaria.
Tabla1: Alumno
DNI Nombre Curso Fecha_ Tutor Localidad_ Provincia_ Teléfono

Matricula Alumno Alumno
11111111 A_Eva 1ESO- 01-Julio Isabel Écija Sevilla 660111222
A -2016
22222222 B_Ana 1ESO- 09-Julio- Isabel Écija Sevilla 660222333
A 2016 660333444
660444555
33333333 C_Susana 1ESO- 11-Julio- Roberto Écija Sevilla
B 2016
44444444 D_Juan 2ESO- 05-Julio- Federico El Villar Córdoba
A 2016
55555555 E_Jose 2ESO- 02-Julio- Federico El Villar Córdoba 66100011
A 2016 661000222
Como se puede observar, esta tabla no está en 1FN puesto que el Teléfono contiene varios
datos dentro de una misma celda y por lo tanto no es un campo valores sean atómicos. La
solución sería la siguiente:
Tabla2: Alumno
DNI Nombre Curso FechaMatricula Tutor Localidad_ Provincia_

Alumno Alumno
11111111A Eva 1ESO-A 01-Julio-2016 Isabel Écija Sevilla
22222222B Ana 1ESO-A 09-Julio-2016 Isabel Écija Sevilla
33333333C Susana 1ESO-B 11-Julio-2016 Roberto Écija Sevilla
44444444D Juan 2ESO-A 05-Julio-2016 Federico El Villar Córdoba
55555555E José 2ESO-A 02-Julio-2016 Federico El Villar Córdoba
Tabla3: Teléfono
DNI Teléfono
11111111A 660111222
22222222B 660222333
22222222B 660333444
22222222B 660444555
55555555E 661000111
55555555E 661000222
3.2.2. Segunda Forma Normal
17
Una Relación está en 2FN si y sólo si está en 1FN y todos los atributos que no forman
parte de la Clave Principal tienen dependencia funcional completa de ella. Ejemplo: Seguimos
con el ejemplo anterior. Trabajaremos con la siguiente tabla:
Tabla4: Alumnos
DNI Nombre Curso FechaMatricula Tutor Localidad_ Provincia_
Alumno Alumno
11111111A Eva 1ESO-A 01-Julio-2016 Isabel Écija Sevilla
22222222B Ana 1ESO-A 09-Julio-2016 Isabel Écija Sevilla
33333333C Susana 1ESO-B 11-Julio-2016 Roberto Écija Sevilla
44444444D Juan 2ESO-A 05-Julio-2016 Federico El Villar Córdoba
55555555E José 2ESO-A 02-Julio-2016 Federico El Villar Córdoba
Vamos a examinar las dependencias funcionales. El grafico que las representa es el siguiente:
Nombre
DNI ProvinciaAlumno
FechaMatricula LocalidadAlumno
Curso Nombre
Siempre que aparece un DNI aparecerá el Nombre correspondiente y la

LocalidadAlumno correspondiente. Por tanto, DNI → Nombre y DNI →
LocalidadAlumno. Por otro lado, siempre que aparece un Curso aparecerá el
Tutor correspondiente. Por tanto, Curso → Tutor. Los atributos Nombre y LocalidadAlumno
no dependen funcionalmente de Curso, y el atributo Tutor no depende funcionalmente de
DNI.
El único atributo que sí depende de forma completa de la clave compuesta DNI y Curso es
FechaMatrícula: (DNI, Curso) →FechaMatrícula.
A la hora de establecer la Clave Primaria de una tabla debemos escoger un atributo o

conjunto de ellos de los que dependan funcionalmente el resto de atributos. Además,
debe ser una dependencia funcional completa. Si escogemos DNI como clave primaria,
tenemos un atributo (Tutor) que no depende funcionalmente de él. Si escogemos Curso
como clave primaria, tenemos otros atributos que no dependen de él.
18
Si escogemos la combinación (DNI, Curso) como clave primaria, entonces sí tenemos

todo el resto de atributos con dependencia funcional respecto a esta clave. Pero es una
dependencia parcial, no total (salvo FechaMatrícula, donde sí existe dependencia
completa). Por tanto, esta tabla no está en 2FN. La solución sería la siguiente:
Tabla 5: Alumnos
DNI Nombre Localidad Provincia

11111111A Eva Écija Sevilla
22222222B Ana Écija Sevilla
33333333C Susana El Villar Sevilla
44444444D Juan El Villar Córdoba
55555555E José Écija Córdoba
Tabla 6: Matriculas
DNI Curso FechaMatricula
11111111A 1ESO-A 01-Julio-2016
22222222B 1ESO-A 09-Julio-2016
33333333C 1ESO-B 11-Julio-2016
44444444D 2ESO-A 05-Julio-2016
55555555E 2ESO-A 02-Julio-2016
Tabla 7: Curso
Curso Tutor
1ESO-A Isabel
1ESO-B Roberto
2ESO-A Federico
3.2.3. Tercera Forma Normal

Una Relación está en 3FN si y sólo si está en 2FN y no existen dependencias
transitivas. Todas las dependencias funcionales deben ser respecto a la clave principal.
Ejemplo: Seguimos con el ejemplo anterior.
Trabajaremos con la siguiente tabla:

Tabla 8: Alumnos
DNI Nombre Localidad Provincia
11111111A Eva Écija Sevilla
22222222B Ana Écija Sevilla
33333333C Susana El Villar Sevilla
19
44444444D Juan El Villar Córdoba

55555555E José Écija Córdoba
Las dependencias funcionales existentes son las siguientes. Como podemos observar existe una
dependencia funcional transitiva: DNI→
Localidad→Provincia
Nombre
Localidad
Provincia
Para que la tabla esté en 3FN, no pueden existir dependencias funcionales transitivas. Para
solucionar el problema deberemos crear una nueva tabla. El resultado es:
Tabla 9: Alumnos
DNI Nombre Localidad
11111111A Eva Écija
22222222B Ana Écija
33333333C Susana El Villar
44444444D Juan El Villar
55555555E José Écija
Tabla 10: Localidades
Localidad Provincia
Écija Sevilla
El Villar Córdoba
RESULTADO FINAL
Tabla11: Alumnos
DNI Nombre Localidad
11111111A Eva Écija
22222222B Ana Écija
33333333C Susana El Villar
44444444D Juan El Villar
55555555E José Écija
Tabla 12: Localidades
Localidad Provincia
20
Écija Sevilla
El Villar Córdoba
Tabla 13: Teléfono
DNI Teléfono
11111111A 660111222
22222222B 660222333
22222222B 660333444
22222222B 660444555
55555555E 661000111
55555555E 661000222
Tabla 14: Matriculas
DNI Curso FechaMatricula

11111111A 1ESO-A 01-Julio-2016
22222222B 1ESO-A 09-Julio-2016
33333333C 1ESO-B 11-Julio-2016
44444444D 2ESO-A 05-Julio-2016
55555555E 2ESO-A 02-Julio-2016
Tabla 15: Cursos
Curso Tutor
1ESO-A Isabel
1ESO-B Roberto
2ESO-A Federico
3.2.4. Cuarta Forma Normal

Una Relación está en 4FN si y sólo si está en 3FN (o FNBC) y las únicas dependencias
multivaluadas son aquellas que dependen de las claves candidatas. Ejemplo: Tenemos una
tabla con la información de nuestros alumnos y alumnas y las asignaturas que cursan, así
como los deportes que practican.
Tabla 16: Alumnado
Estudiante Asignatura Deporte

11111111A Matemáticas, Lengua Baloncesto
22222222B Matemáticas Futbol, Natación
21
Tabla 17: Alumnado
Estudiante Asignatura Deporte

11111111A Matemáticas Natación
11111111A Matemáticas Baloncesto
11111111A Lengua Natación
11111111A Lengua Baloncesto
22222222B Matemáticas Futbol
22222222B Matemáticas Natación
Para normalizar esta tabla, debemos darnos cuenta que la oferta de asignaturas está compuesta
por un conjunto de valores limitado. Igual sucede con los deportes. Por tanto, existen dos
dependencias multivaluadas:
- Estudiante→→ Asignatura
- Estudiante→→ Deporte
Por otro lado, no existe ninguna dependencia entre la asignatura cursada y el deporte practicado. Para
normalizar a 4FN creamos 2 tablas:
Tabla 18: EstudiaAsignatura
Estudiante Asignatura
11111111A Matemáticas
11111111A Lengua
22222222B Matemáticas
Tabla 19: PracticaDeporte
Estudiante Deporte
11111111A Natación
11111111A Baloncesto
22222222B Futbol
22222222B Natación
3.2.5. Quinta Forma Normal

La quinta forma normal (5FN), es una generalización de la anterior. También conocida
como forma normal de proyección-unión (PJ/NF). Una tabla se dice que está en 5NF si y sólo
si está en 4NF y cada dependencia de unión (join) en ella es implicada por las claves
candidatas. Ejemplo: Tenemos una tabla con varios proveedores que nos proporcionan piezas
22
para distintos proyectos. Asumimos que un Proveedor suministra ciertas Piezas en particular,
un Proyecto usa ciertas Piezas, y un Proyecto es suplido por ciertos Proveedores, entonces
tenemos las siguientes dependencias multivaluadas:
- Proveedor →→ Pieza
- Pieza→→ Proyecto
- Proyecto→→Proveedor
Se puede observar cómo se produce un ciclo:
- Proveedor →→ Pieza→→ Proyecto→→ Proveedor (nuevamente)
Tabla 20: Suministros
Proveedor Pieza Proyecto

E1, E4, E6 P13, P16 PR2, PR4
E2, E5 P11, P12 PR1, PR3
E3, E7 P14, P15 PR5, PR6
Tabla 21: Suministros
Proveedor Pieza Proyecto

E1 P13 PR2
E1 P13 PR4
E1 P16 PR2
E1 P16 PR4
E4 P13 PR2
E4 P13 PR4
E4 P16 PR2
E4 P16 PR4
E6 P13 PR2
E6 P13 PR4
E6 P16 PR2
E6 P16 PR4
E2 P11 PR1
E2 P11 PR3
E2 P12 PR1
E2 P12 PR3
E5 P11 PR1
E5 P11 PR3
E5 P12 PR1
23
E5 P12 PR3
E3 P14 PR5
E3 P14 PR6
E3 P15 PR5
E3 P15 PR6
E7 P14 PR5
E7 P14 PR6
E7 P15 PR5
E7 P15 PR6
Descomponemos la tabla en 3 tabla nuevas: Proveedor-Pieza, Pieza-Proyecto, Proyecto-Proveedor.

Tabla 22: Provedor-Pieza
Proveedor Pieza
E1 P13
E1 P16
E4 P13
E4 P16
E6 P13
E6 P16
E2 P11
E2 P12
E5 P11
E5 P12
E3 P14
E3 P15
E7 P14
E7 P15
Tabla 23: Pieza-Proyecto
Pieza Proyecto
P13 PR2
P13 PR4
P16 PR2
P16 PR4
P11 PR1
P11 PR3
P12 PR1
P12 PR3
P14 PR5
P14 PR6
24
P15 PR5
P15 PR6
Tabla 24: Proyecto – Proveedor
Proyecto Proveedor
PR2 E1
PR4 E1
PR2 E4
PR4 E4
PR2 E6
PR4 E6
PR1 E2
PR3 E2
PR1 E5
PR3 E5
PR5 E3
PR6 E3
PR5 E7
PR6 E7
El producto natural de estas 3 tablas nos da la tabla original. Proveedor-Pieza |x|

Pieza-Proyecto |x| Proyecto-Proveedor= Suministros
3.3. Gestores de Base de Datos Relacional
Un sistema gestor de base de datos (SGBD) - DataBase Management System, es una

aplicación que permite a los usuarios definir, crear y mantener una base de datos, y
proporciona acceso controlado a la misma.
En general, un SGBD proporciona los siguientes servicios:

Permite la definición de la base de datos mediante el lenguaje de definición de datos
(DDL – Data Description Language). Este lenguaje permite especificar la estructura y
el tipo de los datos, así como las restricciones sobre los datos. Todo esto se almacenará
en la base de datos.
Permite la inserción, actualización, eliminación y consulta de datos mediante el

lenguaje de manejo o manipulación de datos (DML – Data Manipulation Language).
Proporciona un acceso controlado a la base de datos mediante:
25
• Un sistema de seguridad, de modo que los usuarios no autorizados no puedan acceder a

la base de datos, mediante el lenguaje de control de datos (DLC – Data Control
Language).
• Un sistema de integridad que mantiene la integridad y la consistencia de los datos.
• Un sistema de control de concurrencia que permite el acceso compartido a la base de

datos.
• Un sistema de control de recuperación que restablece la base de datos después de que se

produzca un fallo del hardware o del software.
• Un diccionario de datos o catalogo accesible por el usuario que contiene la descripción

de los datos de la base de datos.
La principal herramienta de un SGBD es la interfaz de programación del usuario. Esta interfaz

consiste en un lenguaje muy sencillo mediante el cual el usuario interactúa con el servidor.
Este lenguaje comúnmente se denomina SQL (Structure Query Language), esta estandarizado
por la ISO I, es decir, todas las BD que soporta SQL, deben tener la misma sintaxis a la hora
de aplicar el lenguaje.
En la actualidad, existen multitud de SGBD en la mayoría relacionales.
e datos relacional y multiusuario

seguramente el más usado en aplicaciones creadas como software libre. Por un lado, se
ofrece bajo la GNU GPL, pero, empresas que quieran incorporarlo en productos
privativos pueden comprar a la empresa una licencia que les permita ese uso. Ventajas:
- Velocidad al realizar las operaciones

- Bajo costo en requerimientos para la elaboración de bases de datos - Facilidad de
configuración e instalación.
nales basado
en el lenguaje Transact-SQL, capaz de poner a disposición de muchos usuarios grandes
cantidades de datos de manera simultánea. Es un sistema propietario de Microsoft. Sus
principales características son:
- Soporte de transacciones.
26
- Escalabilidad, estabilidad y seguridad.

- Soporta procedimientos almacenados.
- Incluye también un potente entorno gráfico de administración, que permite el uso de comandos
DDL y DML gráficamente.
- Permite trabajar en modo cliente-servidor donde la información y datos se alojan en el servidor

y las terminales o clientes de la red sólo acceden a la información.
- Además, permite administrar información de otros servidores de datos

- Su principal desventaja es el precio, aunque cuenta con una versión EXPRESS que permite
usarlo en entornos pequeños. (Aprox. unos 4GB de información y varios millones de registros
por tabla).
en inglés de Relational Data Base Management System), fabricado por Oracle

Corporation. Tradicionalmente Oracle ha sido el SGBS por excelencia, considerado
siempre como el más completo y robusto, destacando por:
- Soporte de transacciones.
- Estabilidad.
- Escalabilidad.
- Es multiplataforma.
- También siempre ha sido considerado de los más caros, por lo que no se ha estandarizado su uso
como otras aplicaciones.
- Al igual que SQL Server, Oracle cuenta con una versión EXPRESS gratis para pequeñas
instalaciones o usuarios personales.
Microsoft Access: Es un sistema de gestión de bases de datos Relacional creado por

Microsoft (DBMS) para uso personal de pequeñas organizaciones. Se ha ofrecido
siempre como un componente de la suite Microsoft Office, aunque no se incluye en el
paquete “básico”. Una posibilidad adicional es la de crear ficheros con bases de datos
que pueden ser consultados por otros programas. Entre las principales funcionalidades
reseñables podemos indicar que:
- Permite crear tablas de datos indexadas.

- Modificar tablas de datos.
27
- Relaciones entre tablas (creación de bases de datos relacionales).

- Creación de consultas y vistas.
- Consultas referencias cruzadas.
- Consultas de acción (INSERT, DELETE, UPDATE).
- Formularios.
- Informes.
- Entorno de programación a través de VBA
- Llamadas a la API de Windows.
PostgreSQL: Es un sistema de gestión de base de datos relacional orientada a objetos y

libre, publicado bajo la licencia BSD. Como muchos otros proyectos de código abierto,
el desarrollo de PostgreSQL no es manejado por una empresa y/o persona, sino que es
dirigido por una comunidad de desarrolladores que trabajan de forma desinteresada,
altruista, libre y/o apoyada por organizaciones comerciales. La comunidad PostgreSQL
se denominada el PGDG (PostgreSQL Global Development Group). Sus principales
características son:
- Alta concurrencia: mediante un sistema denominado MVCC (Acceso concurrente multiversión,

por sus siglas en inglés)
- Amplia variedad de tipos nativos: provee nativamente varios soportes

- Ahorros considerables de costos de operación
- Estabilidad y confiabilidad
3.3.1. SQL Server 2014

Microsoft SQL Server es un sistema de administración y análisis de bases de datos
relacionales de Microsoft para soluciones de comercio electrónico, línea de negocio y
almacenamiento de datos. En esta sección, encontrará información sobre varias versiones de
SQL Server. También encontrará artículos sobre bases de datos y aplicaciones de diseño de
bases de datos, así como ejemplos de los usos de SQL Server.
Microsoft SQL Server 2014 se basa en las funciones críticas ofrecidas en la versión anterior,
proporcionando un rendimiento, una disponibilidad y una facilidad de uso innovadores para
las aplicaciones más importantes. Microsoft SQL Server 2014 ofrece nuevas capacidades en
memoria en la base de datos principal para el procesamiento de transacciones en línea (OLTP)
y el almacenamiento de datos, que complementan nuestras capacidades de almacenamiento de
28
datos en memoria y BI existentes para lograr la solución de base de datos en memoria más
completa del mercado.
SQL Server 2014 también proporciona nuevas soluciones de copia de seguridad y de

recuperación ante desastres, así como de arquitectura híbrida con Windows Azure, lo que
permite a los clientes utilizar sus actuales conocimientos con características locales que
aprovechan los centros de datos globales de Microsoft. Además, SQL Server 2014 aprovecha
las nuevas capacidades de Windows Server 2012 y Windows Server 2012 R2 para ofrecer una
escalabilidad sin parangón a las aplicaciones de base de datos en un entorno físico o virtual.
3.3.2. Características
Procesamiento de transacciones en línea (OLTP) en memoria: Proporciona

capacidades de OLTP en memoria integradas en el núcleo de la base de datos de SQL
Server para mejorar significativamente el rendimiento de la base de datos de su
aplicación. El OLTP en memoria se instala con el equipo con SQL Server 2014 sin
necesitar medidas adicionales y ofrece beneficios de rendimiento en memoria sin tener
que reescribir la aplicación de su base de datos o actualizar su hardware. Las mejoras
de SQL Server 2014 CTP2 incluyen soporte AlwaysOn, mayor superficie de área
TSQL y la capacidad de migrar objetos existentes al OLTP en memoria.
ColumnStore actualizable en memoria: Proporciona una mayor compresión, mayor

soporte para consultas y actualización de ColumnStore existente para cargas de trabajo
de almacenamiento de datos, lo que le dará velocidades de carga y rendimiento de
consultas más rápidos, asistencia y un precio aún más bajo por TB.
Ampliación de memoria a SSD: Integra sin problemas y de forma transparente
almacenamiento de estado sólido en Server SQL mediante los SSD como una
extensión de la agrupación de búferes de la base de datos, lo que permitirá un mayor
procesamiento en memoria y reducir la entrada/salida de disco.
Alta disponibilidad mejorada

Nuevas características AlwaysOn: Los grupos de disponibilidad soportan ahora hasta
ocho réplicas secundarias que están disponibles para su lectura en todo momento,
incluso en presencia de fallos en la red. Los casos de clúster con conmutación por error
ahora soportan Windows Cluster Shared Volumes, lo que mejora la utilización del
almacenamiento compartido y aumenta la resiliencia a conmutación por error.
29
Operaciones mejoradas de base de datos en línea: Incluye una reconstrucción de índice

en línea de una única partición y administración de prioridad de bloqueo para
movimientos entre particiones de tablas, lo que reduce el impacto de inactividad por
mantenimiento.
Respaldo cifrado: Proporciona soporte de cifrado para respaldos, en las mismas

instalaciones y en Windows Azure.
Administración de los recursos E/S: Los agrupamientos de recursos ahora admiten la

configuración de IOPS mínimo y máximo por volumen, lo que permite controles de
aislamiento de recursos más completos.
Respaldo Smart: Permite el manejo y la automatización de respaldos de SQL Server

(desde internos y Windows Azure) al almacenamiento con Windows Azure.
Asistente para agregar una réplica de Azure: Agregue réplicas fácilmente en Windows
Azure a grupos de disponibilidad internos.
SQL XI (Integración con XStore): Soporta archivos de SQL Server Database (desde
internos y Windows Azure) en blobs para almacenamiento de Windows Azure.
Asistente de implementación: Implemente fácilmente bases de datos internas de SQL

Server a Windows Azure.
3.3.3. Requisitos para su Instalación
a) .NET Framework
.NET 3.5 SP1 es un requisito para SQL Server 2014 al seleccionar Motor de base de
datos, Reporting Services, Master Data Services, Data Quality Services, replicación, o SQL
Server Management Studio, y ya no se instala por
SQL Server el programa de instalación.

-Si ejecuta el programa de instalación y no tiene .NET 3.5 SP1, SQL Server programa de
instalación requiere que descargue e instale .NET 3.5 SP1 antes de continuar con la SQL
Server instalación. (Instale .NET 3.5 SP1 desde Microsoft .NET Framework 3.5 Service Pack
1.) El mensaje de error incluye un vínculo al centro de descarga o bien puede descargar .NET
3.5 SP1 desde Windows Update. Para evitar la interrupción durante la instalación de SQL
Server, puede descargar e instalar .NET 3.5 SP1 antes de ejecutar el programa de instalación
de SQL Server.
30
-Si ejecuta el programa de instalación en un equipo con Windows Server 2008 R2 SP1 o
Windows 8, debe habilitar .NET Framework 3.5 SP1 antes de instalar
SQL Server 2014.

-Si no hay ningún acceso a internet, debe descargar e instalar .NET Framework 3.5 SP1 antes
de ejecutar el programa de instalación para instalar cualquiera de los componentes
mencionados anteriormente. Para obtener más información acerca de las recomendaciones e
instrucciones sobre cómo adquirir y habilitar .NET Framework 3.5 en Windows 8 y Windows
Server 2012
b) Windows PowerShell
SQL Server 2014 no instala ni habilita Windows PowerShell 2.0; Sin embargo, Windows
PowerShell 2.0 es un requisito previo de instalación motor de base de datos componentes y
SQL Server Management Studio. Si el programa de instalación notifica que Windows
PowerShell 2.0 no está presente, puede instalarlo o habilitarlo siguiendo las instrucciones de
la página Windows Management Framework .
c) Software de red
Los sistemas operativos admitidos para SQL Server 2014 tienen software de red integrado.
Las instancias con nombre y predeterminadas de una instalación independiente admiten los
siguientes protocolos de red: Memoria compartida, Canalizaciones con nombre, TCP/IP y
VIA.
d) Virtualización
Dentro del rol Hyper-V de Windows Server 2008 SP2 o Windows Server 2008 R2 SP1, se
puede asignar un máximo de 4 (cuatro) procesadores virtuales a las máquinas virtuales que
ejecutan ediciones de 32 o 64 bits de Windows Server 2008 SP2, de 64 bits de Windows
Server 2008 R2 SP1 o de 64 bits de Windows Server 2012.
e) Disco Duro
SQL Server 2014 requiere un mínimo de 6 GB de espacio disponible en disco
f) Monitor
31
QL Server 2014 requiere un mínimo de 6 GB de espacio disponible en disco
g) Memoria
Ediciones Express 1GB, Todas las demás ediciones: al menos 4 GB y debe aumentar a
medida que el tamaño de la base de datos aumente para asegurar un rendimiento óptimo.
h) Velocidad del Procesador

Procesador x86: 1.0 GHz Procesador x64: 1.4
GHz
i) Tipo de procesador
Procesador x64: AMD Opteron, AMD Athlon 64, Intel Xeon compatible con Intel
EM64T Intel Pentium IV compatible con EM64T
3.3.4. Tipos de Datos en SQL Server
CHAR: Es utilizado para definir campos que permitan almacenar datos de tipo cadena de
texto, donde la longitud de caracteres es fijo y no variable. Ejemplo: Ruc, DNI, Código del
Cliente, Código del Estudiante, etc.
VARCHAR: Es utilizado para definir campos que permitan almacenar datos de tipo cadena de
texto, donde la longitud de caracteres sea variable y no fija, además que solo guardara
físicamente los espacios ocupados a diferencia del tipo de datos CHAR, que almacena la
cadena de texto y automáticamente con espacios en blanco hasta alcanzar el total de caracteres
definido. Ejemplo: Apellidos, Nombres, Dirección, Nombre del Distrito, Descripción del
Articulo, etc. INT: Es utilizado para definir campos que permitan almacenar datos numéricos
entero (sin decimales). Ejemplo: Cantidad de Unidades Vendidas, Número de Hijos, Stock de
Productos, etc.
NUMERIC: Es utilizado para definir campos que permitan almacenar datos numéricos con
decimales. Ejemplo: Precio Unitario, Descuento, Subtotal, IGV, Total a Pagar, Sueldo de un
Empleado, etc.
DATE: Es utilizado para definir campos que permitan almacenar datos de tipo fecha.
Ejemplo: Fecha de Matricula de Estudiante, Fecha de Emisión de una Factura, etc.
32
DATATIME: Es utilizado para definir campos que permitan almacenar datos de tipo fecha y
hora. Ejemplo: Fecha de Nacimiento de una persona, Fecha de Entrega de un pedido, etc.
TEXT: Es utilizado para definir campos que permitan almacenar datos de tipo Memo (Larga
secuencia de caracteres, es decir más de 255 caracteres). Ejemplo: Observación de Pedido,
Observación del Estado de un Contrato, etc. IMAGE: Es utilizado para definir campos que
permitan almacenar datos de tipo imagen. Para ello se debe indicar la ubicación o ruta de la
imagen a insertar dentro de un campo de una tabla especifica. Ejemplo: Fotografía de un
Empleado, Fotografía de un Producto, etc.
INSERT INTO ARTICULO (CODART, DESCRIPCION, PRESENTACION,

CODCATG, STOCK, FOTO)
VALUES (‘ART-001’,’LAVADORA DE 12KG’, ‘CAJA’, ‘CAT03’, 100,
‘C:/Imágenes_Articulo/Lavadora_12kg.jpg’)
BIT: Es utilizado para definir campos que permitan almacenar datos numéricos de tipo entero, en
el cual solo sea acepta dos valores: 1 y 0, donde:
Verdadero = True = Si = 1
Falso = False = No = 0
Ejemplo: Anulación de Factura, Anulación de Cita Médica, etc.
3.4. Definición de Tabla

3.4.1. Definición de Tabla
Las tablas son objetos de base de datos que contienen todos sus datos. En las tablas, los
datos se organizan con arreglo a un formato de filas y columnas, similar al de una hoja de
cálculo. Cada fila representa un registro único y cada columna un campo dentro del registro.
Por ejemplo, en una tabla que contiene los datos de los empleados de una compañía puede
haber una fila para cada empleado y distintas columnas en las que figuren detalles de los
mismos, como el número de empleado, nombre, la dirección, el puesto que ocupa y su número
de teléfono celular.
3.4.2. Definición de Índices

Un índice es una estructura de disco asociada con una tabla o vista que acelera la
recuperación de filas de la tabla o de la vista. Un índice contiene claves generadas a partir de
una o varias columnas de la tabla o la vista. Dichas claves están almacenadas en una
estructura (árbol) que permite que SQL Server busque de forma rápida y eficiente la fila o
filas asociadas a los valores de cada clave.
33
3.4.3. Definición de Procedimientos Almacenado

Un procedimiento almacenado de SQL Server es un grupo de una o varias
instrucciones Transact – SQL o una referencia a un método de Common Runtime Language
(CLR) de Microsoft .NET Framework. Los procedimientos se asemejan a las constrcciones de
otros lenguajes de programación, porque pueden ser:
• Aceptar parámetros de entrada y devolver varios valores en forma de parámetros de
salida al programa que realiza la llamada.
• Contener instrucciones de programación que realicen operaciones en la base de datos.

Entre otras, pueden contener llamadas a otros procedimientos.
• Devolver un valor de estado a un programa que realiza una llamada para indicar si la
operación se ha realizado correctamente o se han producido errores, y el motivo de
estos
3.4.4. Definición de Desencadenador

Los desencadenadores son procedimientos Transact-SQL, que se ejecutan
automáticamente cuando de envía una instrucción update, insert o delete a una tabla base o
vista. Son un mecanismo que posibilita la aplicación lógica del negocio de forma automática
cuando se modifican los datos. Los desencadenadores pueden extender la lógica de
verificación de la integridad de restricciones declarativas, predeterminadas y reglas, aunque
las restricciones declarativas se deberían utilizar preferentemente siempre que se satisfagan las
necesidades.
34
CAPITULO IV
DISEÑO E IMPLEMENTACION DE LA SOLUCION
4.1. Modelo Entidad Relación de la Base de Datos
35
4.2. Diagrama Entidad Relación de la Base de Datos 4.2.1. El
Diagrama Lógico de la Base de Datos
36
37
4.3. El Script de la Base de Datos
USE master
GO
--Evaluamos si existe la Base de Datos: BDProceso_Admi if exists (SELECT

NAME FROM sys.databases where
NAME='BDUniversidad_Admision_Matricula')
BEGIN
---Eliminar la Base de Datos:

BDUniversidad_Admision_Matricula
DROP DATABASE BDUniversidad_Admision_Matricula
PRINT 'Se ha Procedido a eliminar la Base de Datos:

BDUniversidad_Admision_Matricula'
END
ELSE
BEGIN
---Crear la Base de Datos--
CREATE DATABASE BDUniversidad_Admision_Matricula
ON PRIMARY
(NAME = BDUniversidad_Admision_Matricula_Dat,
FILENAME =
'C:\DataBase_Universidad\BDUniversidad_Admision_Matricula_Dat.mdf',
SIZE = 350 MB,
MAXSIZE = 717 MB,
FILEGROWTH = 14 MB)
LOG ON
(NAME = BDUniversidad_Admision_Matricula_Log,
FILENAME =
'C:\DataBase_Universidad\BDUniversidad_Admision_Matricula_Log.ldf',
SIZE = 150 MB,
MAXSIZE = 307 MB,
FILEGROWTH = 6MB)
--imprimir datos--
PRINT 'Se ha procedido a crear la base de datos:
BDUniversidad_Admision_Matricula'
END
GO
USE
GO
SP_HELPFILE
GO
--------------------------CREACIÓN DE TABLAS----------------------------
CREATE TABLE ADMISION

(NUM_ADMISION char(6) NOT NULL ,
TIPO_ADMISION varchar(20) NOT NULL ,
FEC_ADMISION date NOT NULL ,
38
CODSEMESTRE char(5) NOT NULL ,

CODFACULTAD char(5) NOT NULL ,
ESTADO_ADMISION varchar(20) NOT NULL)
GO
ALTER TABLE ADMISION

ADD CONSTRAINT PK_ADMISION_NUM_ADMISION
PRIMARY KEY (NUM_ADMISION ASC)
GO
CREATE TABLE AREA

(CODAREA char(4) NOT NULL ,
NOMBRE_AREA varchar(40) NOT NULL)
GO
ALTER TABLE AREA

ADD CONSTRAINT PK_AREA_CODAREA
PRIMARY KEY (CODAREA ASC)
GO
CREATE TABLE AULA

(NUM_AULA char(7) NOT NULL,
CODPABELLON char(5) NOT NULL ,
CAPACIDAD_PERSONAS int NOT NULL)
GO
ALTER TABLE AULA

ADD CONSTRAINT PK_AULA_NUM_AULA
PRIMARY KEY (NUM_AULA ASC)
GO
CREATE TABLE CARGO

(CODCARGO char(5) NOT NULL ,
NOMBRE_CARGO varchar(40) NOT NULL)
GO
ALTER TABLE CARGO

ADD CONSTRAINT PK_CARGO_CODCARGO
PRIMARY KEY (CODCARGO ASC)
GO
CREATE TABLE COMPROBANTE_PAGO

( NUM_COMPROBANTE char(7) NOT NULL ,
CODPERS char(5) NOT NULL ,
CODPAGO_PENSION char(4) NOT NULL ,
FEC_EMISION datetime NOT NULL ,
CODFORMA_PAGO char(3) NOT NULL ,
SUBTOTAL numeric(10,2) NOT NULL ,
IGV numeric(10,2) NOT NULL,
TOTAL numeric(10,2) NOT NULL ,
ESTADO_COMPROBANTE varchar(20) NOT NULL)
GO
ALTER TABLE COMPROBANTE_PAGO
39
ADD CONSTRAINT PK_COMPROBANTE_PAGO_NUM_COMPROBANTE

PRIMARY KEY (NUM_COMPROBANTE ASC)
GO
CREATE TABLE CURSO

(CODCURSO char(6) NOT NULL ,
NOMBRE_CURSO varchar(60) NOT NULL ,
COMPETENCIAS_CURSO text NOT NULL)
GO
ALTER TABLE CURSO

ADD CONSTRAINT PK_CURSOS_CODCURSO
PRIMARY KEY (CODCURSO ASC)
GO
CREATE TABLE CURSOS_ESCUELA

(CODESCUELA char(6) NOT NULL ,
CODCURSO char(6) NOT NULL ,
NRO_CREDITOS int NOT NULL)
GO
ALTER TABLE CURSOS_ESCUELA

ADD CONSTRAINT PK_CURSOS_ESCUELA_CODESCUELA_CODCURSO
PRIMARY KEY (CODESCUELA ASC,CODCURSO ASC)
GO
CREATE TABLE DEPARTAMENTO

(CODDEP char(5) NOT NULL ,
NOMBRE_DEP varchar(40) NOT NULL)
GO
ALTER TABLE DEPARTAMENTO

ADD CONSTRAINT PK_DEPARTAMENTO_CODDEP
PRIMARY KEY (CODDEP ASC)
GO
CREATE TABLE DETALLE_MATRICULA

(NUM_MATRICULA char(8) NOT NULL ,
CODESCUELA char(6) NOT NULL ,
CODCURSO char(6) NOT NULL)
GO
ALTER TABLE DETALLE_MATRICULA

ADD CONSTRAINT
PK_DETALLE_MATRICULA_NUM_MATRICULA_CODESCUELA_CODCURSO
PRIMARY KEY (NUM_MATRICULA ASC,CODESCUELA ASC,CODCURSO ASC)
GO
CREATE TABLE DISTRITO

(CPOSTAL char(4) NOT NULL ,
NOMBRE_DIST varchar(40) NOT NULL ,
CODPROV char(6) NOT NULL)
GO
40
ALTER TABLE DISTRITO

ADD CONSTRAINT PK_DISTRITO_CPOSTAL
PRIMARY KEY (CPOSTAL ASC)
GO
CREATE TABLE ESCUELA

(CODESCUELA char(6) NOT NULL ,
NOMBRE_ESCUELA varchar(40) NOT NULL ,
CODFACULTAD char(5) NOT NULL)
GO
ALTER TABLE ESCUELA

ADD CONSTRAINT PK_ESCUELA_CODESCUELA
PRIMARY KEY (CODESCUELA ASC)
GO
CREATE TABLE ESTUDIANTE

(CODEST char(5) NOT NULL ,
APELLIDOS varchar(40) NOT NULL ,
NOMBRES varchar(30) NOT NULL ,
DNI char(8) NOT NULL ,
FEC_NAC date NOT NULL ,
SEXO char(1) NOT NULL ,
CPOSTAL char(4) NOT NULL ,
DIRECCION varchar(60) NOT NULL ,
TELEFONO varchar(9) NOT NULL ,
EMAIL varchar(40) NOT NULL ,
ESTADO_EST varchar(20) NOT NULL)
GO
ALTER TABLE ESTUDIANTE

ADD CONSTRAINT PK_ESTUDIANTE_CODEST
PRIMARY KEY (CODEST ASC)
GO
CREATE TABLE EXAMEN_ADMISION

(CODEXAMEN_ADMIN char(10) NOT NULL ,
NUM_ADMISION char(6) NOT NULL ,
CODPOSTULANTE char(5) NOT NULL , CODPERS
char(5) NOT NULL ,
FEC_EXAMEN date NOT NULL ,
NUM_AULA char(7) NOT NULL ,
PUNTAJE_OBTENIDO numeric(5,2) NOT NULL ,
ESTADO_EXAMEN varchar(20) NOT NULL)
GO
ALTER TABLE EXAMEN_ADMISION

ADD CONSTRAINT PK_EXAMEN_ADMISION_CODEXAMEN_ADMIN
PRIMARY KEY (CODEXAMEN_ADMIN ASC)
GO
CREATE TABLE FACULTAD

(CODFACULTAD char(5) NOT NULL ,
NOMBRE_FACULTAD varchar(40) NOT NULL ,
41
EMAIL varchar(40) NOT NULL)

GO
ALTER TABLE FACULTAD

ADD CONSTRAINT PK_FACULTAD_CODFACULTAD
PRIMARY KEY (CODFACULTAD ASC)
GO
CREATE TABLE FORMA_PAGO

(CODFORMA_PAGO char(3) NOT NULL ,
DESCRIPCION_PAGO varchar(40) NOT NULL)
GO
ALTER TABLE FORMA_PAGO

ADD CONSTRAINT PK_FORMA_PAGO_CODFORMA_PAGO
PRIMARY KEY (CODFORMA_PAGO ASC)
GO
CREATE TABLE MATRICULA

(NUM_MATRICULA char(8) NOT NULL ,
CODSEMESTRE char(5) NOT NULL ,
NUM_ADMISION char(6) NOT NULL ,
CODNIVEL char(3) NOT NULL ,
CODEST char(5) NOT NULL ,
FEC_MATRICULA date NOT NULL ,
IMPORTE numeric(10,2) NOT NULL ,
DSCTO numeric(10,2) NOT NULL ,
TOTAL numeric(10,2) NOT NULL ,
ESTADO_MATRICULA varchar(20) NOT NULL)
GO
ALTER TABLE MATRICULA

ADD CONSTRAINT PK_MATRICULA_NUM_MATRICULA
PRIMARY KEY (NUM_MATRICULA ASC)
GO
CREATE TABLE NIVEL_ESTUDIO

(CODNIVEL char(3) NOT NULL ,
DESCRIPCION_NIVEL varchar(30) NOT NULL)
GO
ALTER TABLE NIVEL_ESTUDIO

ADD CONSTRAINT PK_NIVEL_ESTUDIO_CODNIVEL
PRIMARY KEY (CODNIVEL ASC)
GO
CREATE TABLE PABELLON

(CODPABELLON char(5) NOT NULL ,
NOMBRE_PABELLON varchar(40) NOT NULL ,
PISO varchar(20) NOT NULL)
GO
ALTER TABLE PABELLON
42
ADD CONSTRAINT PK_PABELLON_CODPABELLON

PRIMARY KEY (CODPABELLON ASC)
GO
CREATE TABLE PAGO_PENSION

(CODPAGO_PENSION char(4) NOT NULL ,
NUM_MATRICULA char(8) NOT NULL ,
CODEST char(5) NOT NULL ,
FEC_PAGO datetime NOT NULL ,
NUM_CUOTA varchar(20) NOT NULL ,
IMPORTE_CUOTA numeric(10,2) NOT NULL ,
ESTADO_PENSION varchar(20) NOT NULL)
GO
ALTER TABLE PAGO_PENSION

ADD CONSTRAINT PK_PAGO_PENSION_CODPAGO_PENSION
PRIMARY KEY (CODPAGO_PENSION ASC)
GO
CREATE TABLE PERSONAL

(CODPERS char(5) NOT NULL ,
EST_CIVIL char(1) NOT NULL ,
NRO_HIJOS int NOT NULL ,
EMAIL_PERSONAL varchar(40) NOT NULL ,
EMAIL_INSTITUCIONAL varchar(40) NOT NULL ,
CODFACULTAD char(5) NOT NULL ,
CODAREA char(4) NOT NULL ,
CODCARGO char(5) NOT NULL ,
ESTADO_PERSONAL varchar(20) NOT NULL)
GO
ALTER TABLE PERSONAL

ADD CONSTRAINT PK_PERSONAL_CODPERS
PRIMARY KEY (CODPERS ASC)
GO
CREATE TABLE POSTULANTE

(CODPOSTULANTE char(5) NOT NULL ,
43

EMAIL varchar(40) NOT NULL ,
ESTADO_POSTULANTE varchar(20) NOT NULL)
GO
ALTER TABLE POSTULANTE

ADD CONSTRAINT PK_POSTULANTE_CODPOSTULANTE
PRIMARY KEY (CODPOSTULANTE ASC)
GO
CREATE TABLE PROVINCIA

(CODPROV char(6) NOT NULL ,
NOMBRE_PROV varchar(40) NOT NULL ,
CODDEP char(5) NOT NULL)
GO
ALTER TABLE PROVINCIA

ADD CONSTRAINT PK_PROVINCIA_CODPROV
PRIMARY KEY (CODPROV ASC)
GO
CREATE TABLE SEMESTRE_ACADEMICO

(CODSEMESTRE char(5) NOT NULL ,
NOMBRE_SEMESTRE varchar(20) NOT NULL)
GO
ALTER TABLE SEMESTRE_ACADEMICO

ADD CONSTRAINT XPKSEMESTRE_ACADEMICO_CODSEMESTRE
PRIMARY KEY (CODSEMESTRE ASC)
GO
CREATE TABLE USUARIO_PERSONAL

(CODPERS char(5) NOT NULL ,
CODUSUARIO char(6) NOT NULL ,
PASSWORD varchar(15) NOT NULL ,
ESTADO_USUARIO varchar(20) NOT NULL)
GO
ALTER TABLE USUARIO_PERSONAL

ADD CONSTRAINT PK_USUARIO_PERSONAL_CODPERS
PRIMARY KEY (CODPERS ASC)
GO

ADD CONSTRAINT FK_ADMISION_CODSEMESTRE
FOREIGN KEY (CODSEMESTRE) REFERENCES
SEMESTRE_ACADEMICO(CODSEMESTRE)
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_ADMISION_CODFACULTAD
FOREIGN KEY (CODFACULTAD) REFERENCES FACULTAD(CODFACULTAD)
44
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO
ALTER TABLE AULA

ADD CONSTRAINT FK_AULA_CODPABELLON
FOREIGN KEY (CODPABELLON) REFERENCES PABELLON(CODPABELLON)
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_COMPROBANTE_PAGO_CODPAGO_PENSION
FOREIGN KEY (CODPAGO_PENSION) REFERENCES
PAGO_PENSION(CODPAGO_PENSION)
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_COMPROBANTE_PAGO_CODFORMA_PAGO
FOREIGN KEY (CODFORMA_PAGO) REFERENCES FORMA_PAGO(CODFORMA_PAGO)
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_COMPROBANTE_PAGO_CODPERS
FOREIGN KEY (CODPERS) REFERENCES PERSONAL(CODPERS)
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_CURSOS_ESCUELA_CODESCUELA
FOREIGN KEY (CODESCUELA) REFERENCES ESCUELA(CODESCUELA)
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_CURSOS_ESCUELA_CODCURSO
FOREIGN KEY (CODCURSO) REFERENCES CURSO(CODCURSO)
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_DETALLE_MATRICULA_CODESCUELA
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO
45

ADD CONSTRAINT FK_DETALLE_MATRICULA_CODESCUELA_CODCURSO
FOREIGN KEY (CODESCUELA,CODCURSO) REFERENCES
CURSOS_ESCUELA(CODESCUELA,CODCURSO)
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_DETALLE_MATRICULA_NUM_MATRICULA
FOREIGN KEY (NUM_MATRICULA) REFERENCES MATRICULA(NUM_MATRICULA)
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO
ALTER TABLE DISTRITO

ADD CONSTRAINT FK_DISTRITO_CODPROV
FOREIGN KEY (CODPROV) REFERENCES PROVINCIA(CODPROV)
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO
ALTER TABLE ESCUELA

ADD CONSTRAINT FK_ESCUELA_CODFACULTAD
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_ESTUDIANTE_CPOSTAL
FOREIGN KEY (CPOSTAL) REFERENCES DISTRITO(CPOSTAL)
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_EXAMEN_ADMISION_NUM_ADMISION
FOREIGN KEY (NUM_ADMISION) REFERENCES ADMISION(NUM_ADMISION)
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_EXAMEN_ADMISION_CODPOSTULANTE
FOREIGN KEY (CODPOSTULANTE) REFERENCES POSTULANTE(CODPOSTULANTE)
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_EXAMEN_ADMISION_NUM_AULA
FOREIGN KEY (NUM_AULA) REFERENCES AULA(NUM_AULA)
ON DELETE NO ACTION
46
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_EXAMEN_ADMISION_CODPERS
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_MATRICULA_CODESCUELA
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_MATRICULA_CODSEMESTRE
FOREIGN KEY (CODSEMESTRE) REFERENCES
SEMESTRE_ACADEMICO(CODSEMESTRE)
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_MATRICULA_CODEST
FOREIGN KEY (CODEST) REFERENCES ESTUDIANTE(CODEST)
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_MATRICULA_CODNIVEL
FOREIGN KEY (CODNIVEL) REFERENCES NIVEL_ESTUDIO(CODNIVEL)
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_MATRICULA_NUM_ADMISION
FOREIGN KEY (NUM_ADMISION) REFERENCES ADMISION(NUM_ADMISION)
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_MATRICULA
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_PAGO_PENSION_CODEST
47
FOREIGN KEY (CODEST) REFERENCES ESTUDIANTE(CODEST)

ON DELETE NO ACTION
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_PAGO_PENSION_CODPERS
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_PAGO_PENSION_NUM_MATRICULA
FOREIGN KEY (NUM_MATRICULA) REFERENCES MATRICULA(NUM_MATRICULA)
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_PERSONAL_CODFACULTAD
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_PERSONAL_CPOSTAL
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_PERSONAL_CODAREA
FOREIGN KEY (CODAREA) REFERENCES AREA(CODAREA)
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_PERSONAL_CODESCUELA
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO

ADD CONSTRAINT FK_PERSONAL_CODCARGO
FOREIGN KEY (CODCARGO) REFERENCES CARGO(CODCARGO)
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO
48
ADD CONSTRAINT FK_POSTULANTE_CPOSTAL

ON DELETE NO ACTION
ON UPDATE NO ACTION
GO
ALTER TABLE PROVINCIA

ADD CONSTRAINT FK_PROVINCIA_CODDEP
FOREIGN KEY (CODDEP) REFERENCES DEPARTAMENTO(CODDEP)
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO
ALTER TABLE USUARIO_PERSONAL

ADD CONSTRAINT FK_USUARIO_PERSONAL_CODPERS
ON DELETE NO ACTION
ON UPDATE NO ACTION
GO
49
4.4. El Diagrama Físico de la Base de Datos en SQL Server
53
4.5. Restricciones
CREATE TABLE ESTUDIANTE

(CODEST char(5) NOT NULL CONSTRAINT uq_CODEST UNIQUE,
APELLIDOS varchar(40) NOT NULL,
NOMBRES varchar(30) NOT NULL,
DNI char(8) NOT NULL CONSTRAINT CK_ESTUDIANTE_DNI CHECK (DNI LIKE ‘[0-9][0-
9][0-9][0-9][0-9][0-9][0-9][0-9]’),
SEXO char(1) NOT NULL CONSTRAINT CK_ESTUDIANTE_SEXO CHECK (SEXO IN
(‘M’,’F’)),
TELEFONO varchar(9) UNIQUE,
EMAIL varchar(40) UNIQUE,
ESTADO_EST varchar(20) NOT NULL)
GO

ADD CONSTRAINT PK_ESTUDIANTE_CODEST
PRIMARY KEY (CODEST ASC)
GO
CREATE TABLE POSTULANTE

(CODPOSTULANTE char(5) NOT NULL CONSTRAINT uq_CODEST UNIQUE,
DNI char(8) NOT NULL CONSTRAINT CK_ESTUDIANTE_DNI CHECK (DNI LIKE ‘[0-9][0-
9][0-9][0-9][0-9][0-9][0-9][0-9]’),
TELEFONO varchar(9) UNIQUE,
EMAIL varchar(40) UNIQUE,
ESTADO_POSTULANTE varchar(20) NOT NULL)
GO

ADD CONSTRAINT PK_POSTULANTE_CODPOSTULANTE
PRIMARY KEY (CODPOSTULANTE ASC)
GO
4.6. Inserción de Registros
--------------------------INSERCION DE DATOS------------------------------
INSERT INTO FACULTAD VALUES ('FAC02','INGENIERIA')
INSERT INTO FACULTAD VALUES ('FAC03','CIENCIAS DE LA COMUNICACION Y
PSICOLOGIA')
52
INSERT INTO FACULTAD VALUES ('FAC04','CIENCIAS EMPRESARIALES')

INSERT INTO FACULTAD VALUES ('FAC05','DERECHO')
SELECT * FROM FACULTAD
GO
INSERT INTO POSTULANTE VALUES ('POST01','JUAN CARLOS','ENCISO

PALOMINO','M','JR.LAMPA 258','958632459')
INSERT INTO POSTULANTE VALUES ('POST02','MARIA FERNANDA','CARRAZCO
PALOMINO','F','AV.PERU 3025','997631458')
INSERT INTO POSTULANTE VALUES ('POST03','LURDES CAROLINA','MENA
GARCIA','F','AV.BRAZIL 5258','996325863')
INSERT INTO POSTULANTE VALUES ('POST04','JOEL FERNANDO','GOMEZ
ULLOA','M','AV.GARCILAZO DE LA VEGA 546','989368726')
INSERT INTO POSTULANTE VALUES ('POST05','MARIO','TELLO
VEGA','M','AV.CAJAMARCA 456','903025120')
INSERT INTO POSTULANTE VALUES ('POST06','JOSE ANTONIO','PEREZ
GONZALES','M','JR.HUANUCO 293','996302102')
INSERT INTO POSTULANTE VALUES ('POST07','CAROLA FABIOLA','MINO
GARCIA','F','JRAYACUCHO 368','900316852')
INSERT INTO POSTULANTE VALUES ('POST08','STEFANY','PAREDES
RIOS','F','AV.CONCHUCOS 2934','996375931')
SELECT * FROM POSTULANTE
GO
INSERT INTO ESTUDIANTE VALUES ('EST01','JOEL FERNANDO','GOMEZ

ULLOA','M','AV.GARCILAZO DE LA VEGA 546','989368726')
INSERT INTO ESTUDIANTE VALUES ('EST02','JOSE ANTONIO','PEREZ
GONZALES','M','JR.HUANUCO 293','996302102')
INSERT INTO ESTUDIANTE VALUES ('EST03','JUAN CARLOS','ENCISO
PALOMINO','M','JR.LAMPA 258','958632459')
INSERT INTO ESTUDIANTE VALUES ('EST04','MARIA FERNANDA','CARRAZCO
PALOMINO','F','AV.PERU 3025','997631458')
INSERT INTO ESTUDIANTE VALUES ('EST05','STEFANY','PAREDES
RIOS','F','AV.CONCHUCOS 2934','996375931')
SELECT * FROM ESTUDIANTE
GO
INSERT INTO DEPARTAMENTO VALUES ('DEP01','ANCASH')

INSERT INTO DEPARTAMENTO VALUES ('DEP02','PIURA')
INSERT INTO DEPARTAMENTO VALUES ('DEP03','LIMA')
INSERT INTO DEPARTAMENTO VALUES ('DEP04','TUMBES')
INSERT INTO DEPARTAMENTO VALUES ('DEP05','TACNA')
INSERT INTO DEPARTAMENTO VALUES ('DEP06','CAJAMARCA')
SELECT * FROM DEPARTAMENTO
GO
INSERT INTO PROVINCIA VALUES ('PROV01','HUAYLAS','DEP01')

INSERT INTO PROVINCIA VALUES ('PROV02','SULLANA','DEP02')
INSERT INTO PROVINCIA VALUES ('PROV03','PAITA','DEP02')
INSERT INTO PROVINCIA VALUES ('PROV04','LIMA','DEP03')
INSERT INTO PROVINCIA VALUES ('PROV05','ZARUMILLA','DEP04')
INSERT INTO PROVINCIA VALUES ('PROV06','TACNA','DEP05')
INSERT INTO PROVINCIA VALUES ('PROV07','TARATA','DEP05')
INSERT INTO PROVINCIA VALUES ('PROV08','CUTERVO','DEP06')
INSERT INTO PROVINCIA VALUES ('PROV09','CHOTA','DEP06')
INSERT INTO PROVINCIA VALUES ('PROV10','JAEN','DEP06')
SELECT * FROM PROVINCIA
GO
INSERT INTO DISTRITO VALUES ('DIST01','CARAZ','PROV01')

INSERT INTO DISTRITO VALUES ('DIST02','NUEVO SULLANA','PROV02')
53
INSERT INTO DISTRITO VALUES ('DIST03','COLAN','PROV03')

INSERT INTO DISTRITO VALUES ('DIST04','ANCON','PROV04')
INSERT INTO DISTRITO VALUES ('DIST05','SAN MARTIN DE PORRES','PROV04')
INSERT INTO DISTRITO VALUES ('DIST06','SAN ISIDRO','PROV04')
INSERT INTO DISTRITO VALUES ('DIST07','AGUAS VERDES','PROV05')
INSERT INTO DISTRITO VALUES ('DIST08','TARATA','PROV07') INSERT
INTO DISTRITO VALUES ('DIST09','PALCA','PROV06')
INSERT INTO DISTRITO VALUES ('DIST10','CALANA','PROV06')
INSERT INTO DISTRITO VALUES ('DIST11','SAN ANDRES DE CUTERVO','PROV08')
INSERT INTO DISTRITO VALUES ('DIST12','CHOTA','PROV09')
INSERT INTO DISTRITO VALUES ('DIST13','PUCARA','PROV10')
SELECT * FROM DISTRITO
GO
54
CONCLUCIONES
Con este proyecto de consiguió implementar una solución automatizada

capas de facilitar el proceso de admisión y Matricula, mediante los
requerimientos de usuario, se constató efectivamente que existía la
necesidad de implementar una nueva base de datos, para ello se utilizó
etapas de Análisis, Modelamiento, Diseño para el proceso de admisión y
matricula de la universidad; utilizando el Sistema Gestor de Base de Datos
Relacional (SQL Server) permitió almacenar y posteriormente acceder
satisfactoriamente a los datos de las tablas relacionadas del proceso de
negocio de forma rápida y estructural.
Se logró dar solución a los problemas y necesidades requerida por

Universidad; donde su implementación permite registrar inscripciones de
admisión, agiliza la matrícula de los estudiantes
55
RECOMENDACIONES
Según los resultados positivos obtenidos, la universidad tiene con el

funcionamiento con el sistema informático y así de esa manera lograr
mejores resultados en el Proceso de Admisión y Matricula.
Realizar constantemente un resguardo de Seguridad de la Base de Datos.

La metodología aplicada puede ser extendida a otras áreas de la empresa.
Para ello debe tener presente: la estructura organizacional de la empresa
(Proceso de Negocio), el flujo de información, analizar e identificar la
información relevante apoyándose siempre en los Sistemas de Información
REFERENCIA BIBLIOGRÁFICA
Silberschatz, A., Korth, H. y Sudarshan, S. (2002). Fundamentos de Base

de Datos (4ta.ed.) (Saenz, F., García, A. y López, C, Trud.). España.:
McGRAW-HILL (Trabajo original en inglés)
Código Compilado, (2015). Dase de Datos.

[Videograbación].
Recuperado de
https://www.youtube.com/watch?v=yoeV4Ex8C8U&index=1&list=PLs1s
X iNvW4OyJCZs5WR3OjPZTlIqNcvQi.
Microsoft. (2017). Fundamentos de la Normalización de la Base de Datos.

Recuperado de
https://support.microsoft.com/espe/help/283878/description-of-the-
database-normalization-basics.
Vélez, L., (2018). Departamento de Informática. Gestión Base de Datos.

Volumen 1.0. pp. 12 – 80.
Revista Digital INESEM. (2016). Los Gestores de Base de Datos.

Recuperado de https://revistadigital.inesem.es/informatica-y-
tics/losgestores-de-bases-de-datos-mas-usados/.
Microsoft / Developer Network . (2018). Microsoft SQL Server.

Recuperado de https://msdn.microsoft.com/es-es/library/bb545450.aspx.
56
Internet Ya Soluciones Web. (2014). Características de Microsoft SQL

Server. Recuperado de https://www.internetya.co/caracteristicas-
demicrosoft-sql-server-2014/.
Microsoft. (2018). Requisitos de Hardware y Software para Instalación de

SQL Server 2014. Recuperado de
https://docs.microsoft.com/eses/sql/2014/sql-server/install/hardware-and-
software-requirements-forinstalling-sql-server?view=sql-server-
2017#hwswr.
57

Modelo de Proyecto - Base de Datos

Caricato da

Informazioni sul documento

Titolo originale

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

Modelo de Proyecto - Base de Datos

Caricato da

Copyright:

Formati disponibili

MINISTERIO VICEMINISTERIO DIRECCIÓN REGIONAL DE INSTITUTO DE EDUCACIÓN SUPERIOR TECNOLÓGICO

PERÚ DE DE EDUCACIÓN DE LIMA PÚBLICO

INSTITUTO DE EDUCACIÓN SUPERIOR TECNOLÓGICO PÚBLICO

MODELAMIENTO, DISEÑO E IMPLEMENTACIÓN DE UNA BASE DE

(Proceso de Admisión y Matricula)

ESPECIALIDAD DE COMPUTACIÓN E INFORMÁTICA

Unidad Didáctica: Taller de Base de Datos

Docente: Mg. Quito Cerna Oscar

Dedicamos nuestro proyecto de investigación a nuestros familiares, en especial a

SITUACIÓN ACTUAL DE LA EMPRESA

1.1. Descripción de la Empresa................................................................................................ 7

2. 1. Planteamiento del Problema............................................................................................ 12

3. 1. Modelo Entidad Relación.................................................................................................. 16

DISEÑO E IMPLEMENTACION DE LA SOLUCION

4. 1.Modelo Entidad Relación de la Base de Datos ............................................................. 40

Actualmente los Sistemas de Información cumplen un papel fundamental para las

En el Capítulo I, se describe la Situación Actual de la Universidad Peruana de las

En el Capítulo II, se presenta el Problema de Investigación, Planteamiento del

En el Capítulo III, se ha hecho mención al Marco Teórico, en dónde se fundamenta

En el Capítulo VI, se visualizará el Diseño e Implementación de la Solución; que

SITUACIÓN ACTUAL DE LA EMPRESA

1.1. Descripción de la Empresa

El 10 de octubre del 2002, en Lima, la Doctora Lastenia Fernández Pérez suscribió

1.2. Organigrama de la Empresa

1.3. Datos Generales

• Razón Social: UNIVERSIDAD PERUANA DE LAS AMÉRICAS SAC

• Representante Legal: Rector, Dr. LUIS HURTADO VALENCIA

La Universidad las Américas, se encuentra ubicada en la Av. Garcilaso de la Vega N°

Fuente: “Ubicación Geográfica”. Recuperado de

Ser líder en formación universitaria de profesionales con alto nivel académico y

Formar profesionales líderes, emprendedores e innovadores con

2.1. Planteamiento del Problema

El Proceso de Admisión y Matrícula en la Universidad Peruana de las Américas, está

El Proceso de Admisión y Matrícula en la Universidad Peruana de las Américas se

2.2. Formulación del Problema

El presente estudio tiene como finalidad analizar, modelar, diseñar e implementar

Mediante el análisis de requerimientos del usuario y la aplicación de la técnica del Modelo

atributos y cardinalidades, luego se aplicará el Proceso de Normalización para evitar la

2.3. Objetivos de la Investigación

2.3.2. Objetivo Especifico

Mediante la implementación de una Base de Datos que contemple el Proceso de

La presente investigación se lleva a cabo a raíz de la necesidad de Integración de la

En este sentido la Universidad es consciente de que actualmente muchos de sus estudiantes

2.7. Metodología de la Investigación

Mediante el análisis de requerimientos del usuario y la aplicación de la técnica del

3.1. Modelo Entidad Relación

Según Peter P. Chen (1976). “Inicialmente se divulgo como Modelo Entidad –

En las entidades se clasifican en:

• Entidad Débil: Puede serlo de dos motivos:

identificación de cada una de las ocurrencias y requiere la presencia de atributos

cardinalidad es de muchos (varios) a muchos.

3.1.2.1. Tipos de Atributos

• Llave Primaria: Es un atributo de llave simple o un conjunto de atributos de una llave

3.2. El Proceso de Normalización

Según Piattini (199). “Es el proceso de organización, simplificación y cambios que se

Dependencia funcional: A → B, representa que B es funcionalmente dependiente de A.

Dependencia funcional completa: A→B, si B depende de A en su totalidad. Ejemplo:

Dependencia transitiva: A→B→C. Si A→B y B→C, Entonces decimos que C

Dependencia multivaluada: A→→B. Son un tipo de dependencias en las que un

3.2.1. Primera Forma Normal

Una Relación está en 1FN si y sólo si cada atributo es atómico. Ejemplo:

DNI Nombre Curso Fecha_ Tutor Localidad_ Provincia_ Teléfono

DNI Nombre Curso FechaMatricula Tutor Localidad_ Provincia_