1. Universidad de Panamá
Facultad de Informática, Electrónica y
Comunicación
BASE DE DATOS
Labor Social
Curso: Análisis y Diseño de Sistemas
II Semestre 2011

2. Elaborado por:
Solineth Batista y
Samuel Rodríguez

3. Agenda
Introducción
Planteamiento del semestre anterior
Requerimientos del sistema
Diseño Físico
Normalización
Documentación
¿Qué hicimos el semestre pasado?
Conclusiones
Resumen del trabajo anterior
Recomendaciones
¿Qué hizo falta?
¿Qué se agregó?
Diseño Conceptual
Diseño Lógico

4. Introducción
• El trabajo que presentaremos a continuación tiene como
objetivos principales hacer énfasis en las fases de diseño de una
base de datos relacional y destacar la importancia que tienen
estas etapas en la elaboración de una base de datos
estructurada, cuya integridad podremos comprobar a través de
las consultas que ejecutemos en ella.
•El semestre pasado nos correspondió cursar la materia de Base
de Datos, en donde se nos impartieron los principios de las
bases de datos relacionales, las operaciones de álgebra, y la
normalización a la que debe ser sometida cada relación que se
haya formado.
Inicio

5. Introducción
A través de un proyecto sencillo, hemos buscado clarificar
cada etapa del diseño de base de datos y su desarrollo, es
preciso destacar que debe seguirse cada paso sin pasarlo por
alto, asegurando así que nuestra asociación de los datos sea
bastante eficiente.
Luego de la experiencia de haber elaborado el proyecto
anterior, hemos reedificado cada paso, analizando las fallas y
proponiendo soluciones a nuestro sistema de base de datos.
Esta dinámica nos permitirá desarrollar la destreza de
identificar errores, relaciones redundantes, entre otras cosas
Inicio

6. Planteamiento del Semestre
Anterior
En el curso de Base de Datos del semestre anterior se nos asignó
realizar un proyecto final que consistiera en una base de datos
que satisficiera una necesidad común y una interfaz gráfica que
nos permitiera consultar información dentro de la base de datos
(lenguaje de programación libre de elección) tampoco se exigió un
SGBD específico, para ello trabajamos en grupos de cuatro
estudiantes. El tema para nuestra base de datos era libre, cada
grupo podía escoger que tipo de administración manejaría la base
de datos.
Inicio

7. No se nos exigió visitar comercios o instituciones públicas o
privadas para comprobar requerimientos del sistema.
Entre los puntos que debíamos definir en nuestro proyecto final
estaban los siguientes:
•Presentar el modelo relacional previo a la presentación.
•Realizar una presentación del trabajo final que consistía en: la
base de datos completa con datos y la realización de consultas
SQL para comprobar su integridad.
•Requería de los respectivos procesos de normalización (1FN2FN-3FN), sin embargo, no se pidió detalle de cómo realizamos
la misma en nuestra base de datos. Solamente hacerla sin
evaluación.
•Un trabajo escrito con los objetivos de dicho sistema, el
diccionario de datos, algunas consultas de inserción en SQL, el
modelo relacional.
Inicio

8. Requerimientos del Sistema
1.- ¿Qué es lo que se hace?
El sistema de administración de labor social guarda información
de los estudiantes que realizan labor social, sean estos datos
personales o académicos, permite consultarlos y modificarlos
en el momento necesario. Además incluye los datos de
contacto de las instituciones que han sido asignadas como
lugares propicios para realizar dicha labor.
Inicio

9. 2.- ¿Cómo se hace?
Cada una de estas funciones: guardar, consultar y modificar
las realiza a través de un SGBD. Esta es capaz de adaptarse a
diversas plataformas de sistemas operativos.
Debe
capacitarse al personal para que se encargue del
mantenimiento periódico y manejo de este sistema, además
cada facultad de la Universidad de Panamá debe contar con
él. La interfaz que se diseñe en un futuro que conecte con
esta base de datos debe ser lo suficientemente apropiada y
de fácil uso para los colaboradores.
Inicio

10. 3.- ¿Con que frecuencia se presenta?
La frecuencia con la que se presenta la necesidad de realizar
dichas funciones (almacenamiento, consulta y modificación)
es baja actualmente ya que la resolución que declara la
labor social obligatoria para todos los estudiantes de la
Universidad de Panamá se da apenas el año pasado en
2010. Sin embargo, a medida que estos estudiantes inicien
su labor social, será necesario documentar todo esto, y será
mucho más fácil mediante una base de datos manejada a
través de una aplicación, a la vez que el tiempo que la
demanda sea baja permitirá a la vez someter el sistema a
pruebas constantes y concordar con el personal que se
encargará de manejarlos qué tipo de cosas les gustaría que
la aplicación manejara.
Inicio

11. 4.- ¿Qué tan grande es el volumen de transacciones o de decisiones?
El volumen de decisiones que contemplará la aplicación no es
grande, pues las funciones principales como almacenamiento, por
ejemplo, solo requieren que el estudiante proporcione dichos datos.
La consulta permitirá visualizar el avance que cada estudiante lleva
en su labor social, de acuerdo a este se evaluará si este requisito
para graduarse ha sido completado, de lo contrario deberá
completarlo. La modificación de información permitirá depurar
errores humanos al ingresar los datos de algún estudiante, por
supuesto, este proceso debe ser constatado con pruebas reales.
Inicio

12. 5.- ¿Cuál es el grado de eficiencia con el que se efectúan las tareas?
El grado de eficiencia con que se realizan las tareas actualmente no es el mayor
ya que se maneja a través de un sistema de archivos, y hemos constatado que
este carece de integridad.
6.- ¿Existe algún problema?
El problema actual es que manejar esta información de manera manual sería
una tarea sumamente tediosa, complicada, sujeta a pérdida y alteración de los
datos manejados.
7.- Si existe un problema, ¿Qué tan serio es?
Este problema en escala de prioridades es serio porque realizar la labor social
representa para los estudiantes que ingresaron a partir del 2010 un requisito
para obtener su diploma, por ello es que surge la necesidad de documentar
esta información en el momento necesario y para futuras consultas.
8.- Si existe un problema, ¿Cuál es la causa que lo origina?
El problema de manejar información manualmente son las consecuencias que
esta actividad trae, pérdida de información, alteración de documentos, entre
otras.
Inicio

13. ¿Qué hicimos el semestre
pasado?
Plantear el modelo relacional previo a la presentación
final:
Inicio

14. modelo relacional anterior
Inicio

15. Base de Datos completa con datos y
consultas SQL
Inicio

16. Algunas sentencias SQL de creación e inserción de datos
CREATE TABLE INFO_PERSONAL(
IDEN CHAR(18) NOT NULL,
NOMBRE VARCHAR(45) NOT NULL,
SEG_NOMBRE VARCHAR(45) NULL,
APELLIDO VARCHAR(45) NOT NULL,
SEG_APELLIDO VARCHAR(45) NULL,
TEL_RESIDEN VARCHAR(25) NULL,
TEL_CELL VARCHAR(20) NULL,
EMAIL VARCHAR(65) NOT NULL
PRIMARY KEY(IDEN));
CREATE TABLE INFO_URGENCIA(
IDEN CHAR(18) NOT NULL,
TIPO_SANGRE VARCHAR(45) NOT NULL,
PARENTEZCO VARCHAR(45) NULL,
ACUDIENTE VARCHAR(45) NOT NULL,
TEL_ACUDIENTE VARCHAR(45) NULL,
ENFERMEDADES VARCHAR(25) NULL,
FOREIGN KEY (IDEN) REFERENCES INFO_PERSONAL (IDEN));
Inicio

17. INSERT INTO INFO_ACADEMICA VALUES (‘8-837-1611’ , ‘FIEC’ ,
‘INFORMATICA’ , ‘15/FEB/10’);
INSERT INTO INFO_ACADEMICA VALUES (‘8-818-215’ , ‘FIEC’ ,
‘INFORMATICA’ , ‘10/ENE/10’);
INSERT INTO INFO_ACADEMICA VALUES (‘8-630-208’ , ‘FIEC’ ,
‘INFORMATICA’ , ‘01/JUL/12’);
INSERT INTO INFO_ACADEMICA VALUES (‘8-878-645’ , ‘FIEC’ ,
‘INFORMATICA’ , ‘23/DEC/11’);
INSERT INTO INFO_LABORSOCIAL VALUES (‘8-837-1611’ , ‘CASA DE
JUBILADOS’ , ‘100’ , ‘15/FEB/2010’ , ‘16/MAR/2010’ );
INSERT INTO INFO_LABORSOCIAL VALUES (‘8-298-551’ , ‘CASA
ESPERANZA’ , ‘100’ , ‘15/OCT/2010’ , ‘16/FEB/2010’ );
INSERT INTO INFO_LABORSOCIAL VALUES (‘8-877-2107’ , ‘HACIENDA
DE AMOR’ , ‘11’ , ‘20/FEB/2010’ , ‘28/OCT/2010’ );
INSERT INTO INFO_LABORSOCIAL VALUES (‘4-592-23641’ , ‘ESCUELA
BUEN PASTOR’ , ‘26’ , ‘28/MAY/2010’ , ‘30/NOV/2011’ );
Inicio

18. Resumen del trabajo anterior
A principios del año 2010 se aprobó en Consejo Universitario la
realización de Labor o Servicio Social por parte de todos los
estudiantes que ingresen desde la fecha de publicación en
Gaceta Oficial (Marzo – Mayo de 2010) en adelante.
De aquí nace la necesidad de llevar un Control Interno de
todos los Servicios Sociales que realicen los estudiantes de la
Facultad de Informática, Electrónica y Comunicación, por
medio de sus respectivas Escuelas.
En el siguiente proyecto utilizaremos los recursos aprendidos
en clases sobre las bases de datos, para resolver esta
necesidad dentro de nuestra propia Facultad.
Inicio

19. De aquí, que los objetivos generales de nuestro proyecto son:
•Facilitar a los administrativos de la Facultad el tratamiento del
tema de Labor Social.
•Facilitar a los estudiantes el registro de sus horas de Labor Social.
•Implementar este Sistema permanentemente en esta y en todas
las demás Facultades que así lo necesiten para el Registro de sus
estudiantes.
Inicio

20. Diccionario de Datos
La tabla info_personal recoge toda la información personal del estudiante
Atributo
Descripción
Restricciones
Iden
Cédula del estudiante
Primary key (PK), not null
Nombre
Primer nombre del estudiante
No nulo
Seg_nombre
Segundo nombre del estudiante
No nulo
Apellido
Primer apellido del estudiante
No nulo
Seg_apellido
Segundo apellido del estudiante
No nulo
Tel_residen
Teléfono de residencia del estudiante
No nulo
Tel_cell
Teléfono celular del estudiante
No nulo
email
Correo electrónico del estudiante
No nulo
Inicio

21. La tabla info_académica recoge toda la información académica del estudiante (en qué
facultad estudia y su fecha de ingreso a la carrera)
Atributo
Descripción
Restricciones
Iden
Cédula del estudiante
Foreign key (FK) referencia a
info_personal(iden), not null
Facultad
Nombre de la facultad del
estudiante
No nulo
Carrera
Carrera que cursa el
estudiante
No nulo
Fecha_ingreso
Fecha de ingreso del
estudiante
No nulo
Inicio

22. La tabla info_urgencia recoge toda la información de contacto del responsable del estudiante, en caso de
urgencia
Atributo
Descripción
Restricciones
Iden
Cédula del estudiante
Foreign key (FK) referencia a
info_personal(iden), not null
Tipo_sangre
Tipo de sangre del estudiante
No nulo
Parentesco
Parentesco que tiene con el estudiante
No nulo
Acudiente
Nombre del acudiente
No nulo
Tel_acudiente
Teléfono de contacto del acudiente
No nulo
enfermedades
Campo donde se nombra si el estudiante padece
alguna enfermedad o es alérgico a algún alimento,
medicina u otro
No nulo
Inicio

23. La tabla info_urgencia recoge toda la información de contacto del responsable del estudiante, en caso de
urgencia
Atributo
Descripción
Restricciones
Iden
Cédula del estudiante
Foreign key (FK) referencia a
info_personal(iden), not null
Tipo_sangre
Tipo de sangre del estudiante
No nulo
Parentesco
Parentesco que tiene con el estudiante
No nulo
Acudiente
Nombre del acudiente
No nulo
Tel_acudiente
Teléfono de contacto del acudiente
No nulo
enfermedades
Campo donde se nombra si el estudiante padece
alguna enfermedad o es alérgico a algún alimento,
medicina u otro
No nulo
Inicio

24. La tabla info_laborsocial recoge toda la información relativa a la realización de su Labor Social
Atributo
Descripción
Restricciones
Iden
Cédula del estudiante
Foreign key (FK) referencia a
info_personal(iden), not null
horas
Cantidad de horas que se obtendrán por el Servicio
Social
No nulo
Fecha_ini
Fecha de inicio del Servicio Social
No nulo
Fecha_fin
Fecha de Cierre del Servicio Social
No nulo
Id_lugar
Código de lugar sea: orfanato, asilo, comedor, escuela,
indicando el nombre de institución.
Primary Key (PK), not null
Id_tipo
Código de tipo de lugar (categorías)
Primary Key (PK), not null
Inicio

25. Inicio
¿Qué hizo falta?
La Base de Datos de Control de Horas de Labor Social requería
de información de contacto con los lugares donde se realiza la
Labor Social, permitiendo de alguna manera comprobar que
en efecto el estudiante estuvo allí y realizo su trabajo.
Para realizar todo este proceso de cambio de la base de datos
necesitamos definir cada una de las etapas de diseño de base
de datos que conforman el modelo relacional, ya que la
estructura se modifica por completo.
Cada una de estas fases no se realizaron en el proceso anterior
por lo tanto, la redefinición de cada una de las relaciones que
conforman esta pequeña base de datos nos permitirán
comprobar si en efecto contaba con las fases de normalización
requeridas.

26. ¿Qué se agregó?
Antes que nada, iniciamos con las etapas de
diseño de base de datos. Primero, el diseño
conceptual de nuestras entidades
involucradas.
Inicio

27. DISEÑO CONCEPTUAL
Inicio

28. Entidades Identificadas
Info_personal
Info_urgencia
Info_laborsocial
Info_academica
Info_tipos
Info_lugares
Info_tipos e info_lugares tendrá información referente a los
lugares donde se hace la labor social, han sido añadidas.
Inicio

29. Info_personal
Realiza
Info_laborsocial
Pueden
tener
Tiene
contiene
Info_urgencia
Se
clasifican
Info_lugares
Info_academica
Info_tipos
Inicio

30. Info_personal
Info_laborsocial
iden
iden
nombre
Realiza
Lugar
seg_nombre
Horas
apellido
Fecha_i
seg_apellido
Fecha_f
cedula
dirección
Pueden
tener
Id_lugar
Id_tipo
tel_resid
tel_cel
Info_urgencia
e_mail
Iden
Info_academica
iden
Facultad
Tiene
Carrera
Fecha_ingreso
Inicio
Total_horas
Tipo_sangre
Parentezco
acudiente
Tel_acudiente
enfermedades

31. Info_laborsocial
Info_lugares
iden
Lugar
Id_lugar
contiene
Horas
Nombre
Fecha_i
dirección
Fecha_f
teléfono
Id_lugar
Id_tipo
Id_tipo
Se
clasifican
Info_tipos
Id_tipo
Tipos
Inicio

32. Inicio
Info_personal
Info_laborsocial
Iden
Nombre
Realiza
iden
seg_nombre
Lugar
Apellido
Horas
seg_apellido
Fecha_i
Cedula
Dirección
Pueden
tener
tel_resid
Info_urgencia
e_mail
Info_academica
iden
Facultad
Carrera
Claves primarias
Claves foráneas
Id_lugar
Id_tipo
tel_cel
Tiene
Fecha_f
Fecha_ingreso
Total_horas
iden
Tipo_sangre
Parentezco
acudiente
Tel_acudiente
enfermedades

33. Info_laborsocial
Info_lugares
iden
Lugar
Id_lugar
contiene
Horas
Nombre
Fecha_i
dirección
Fecha_f
teléfono
Claves primarias
Id_lugar
Id_tipo
id_tipo
Claves foráneas
Info_tipos
Se
clasifican
Id_tipo
Tipos
Inicio

34. DISEÑO LOGICO
Inicio

35. MODELO RELACIONAL
Existen tres reglas básicas para
convertir un modelo conceptual al
modelo relacional, éstas son:
1.Todo tipo de entidad se convierte
en una relación.
Inicio

36. Info_personal
IDEN
NOMBRE
SEG_NOMBRE
APELLIDO
SEG_APELLIDO
Inicio
CEDULA
TEL_RESID
TEL_CEL
E_MAIL

37. 2. Todo tipo de interrelación n:n se
transforma en una relación.
En este caso, no existen relaciones n:n
Inicio

38. 3. Para todo tipo de interrelación 1:n
se realiza lo que se denomina
propagación de clave (regla general),
o se crea una nueva relación.
Inicio

39. Info_personal
Modelo Relacional
Tiene
Info_personal (iden)
Info_academica (iden)
Info_academica
Inicio

40. Info_personal
Pueden
tener
Modelo Relacional
Info_urgencia
Info_personal (iden)
Info_urgencia (iden)
Inicio

41. Info_personal
Info_laborsocial
Realiza
Modelo Relacional
Info_personal (iden)
Info_laborsocial (iden)
Inicio

42. Info_laborsocial
contiene
Modelo Relacional
Info_lugares
Info_laborsocial (iden, id_lugar)
Info_lugares (id_lugar, id_tipo)
Inicio

43. Info_lugares
Se
clasifican
Info_tipos
Modelo Relacional
Info_lugares (id_lugar, id_tipo)
Info_tipos (id_tipo)
Inicio

44. Diseño Lógico: modelo relacional actual
Inicio

45. DISEÑO FÍSICO: QUERIES
Utilizaremos un SGBD para
implementar el diseño lógico y este será
el diseño físico, el mismo ha sido
modificado ya que agregamos dos
tablas
Inicio

46. CREATE TABLE `info_lugares` (
`id_lugar` int(11) NOT NULL AUTO_INCREMENT,
`nombre` varchar(45) NOT NULL,
`dirección` varchar(45) NOT NULL,
`teléfono` varchar(45) NOT NULL,
`info_tipos_idinfo_tipos` int(11) NOT NULL,
PRIMARY KEY (`id_lugar`,`info_tipos_idinfo_tipos`),
KEY `fk_info_lugares_info_tipos1` (`info_tipos_idinfo_tipos`),
CONSTRAINT `fk_info_lugares_info_tipos1` FOREIGN KEY
(`info_tipos_idinfo_tipos`) REFERENCES `info_tipos` (`idinfo_tipos`) ON DELETE
NO ACTION ON UPDATE NO ACTION
)
CREATE TABLE `info_tipos` (
`idinfo_tipos` int(11) NOT NULL AUTO_INCREMENT,
`tipo` varchar(45) NOT NULL,
PRIMARY KEY (`idinfo_tipos`)
)
Inicio

47. NORMALIZACIÓN
Inicio

48. Primera forma normal
• Eliminar grupos repetidos en tablas individuales.
• Crear una tabla diferente para cada conjunto de
datos relacionados.
• Identificar cada conjunto de datos relacionados
mediante una clave principal. No utilizar varios
campos en una única tabla para almacenar datos
similares.
Inicio

49. Crear una tabla diferente para cada conjunto de
datos relacionados.
Info_academica
iden
Facultad
1. El atributo total_horas es información relativa
a la labor social más no a la información
académica. Se elimina
Carrera
Fecha_ingreso
Info_laborsocial
Total_horas
iden
Lugar
Horas
Fecha_i
2. El atributo lugar corresponde a la
información de lugares donde se realiza la
laborsocial, se elimina ya que se identificara
mediante codigo de lugar.
Fecha_f
Id_lugar
Id_tipo
Inicio

50. Identificar cada conjunto de datos relacionados mediante una
clave principal. No utilizar varios campos en una única tabla para
almacenar datos similares.
Info_personal
iden
nombre
seg_nombre
3. La tabla info_personal contiene dos códigos
como clave, lo cual es innecesario, para esto
eliminamos cedula, y el campo iden tendrá este
dato, y servirá de clave principal única.
apellido
seg_apellido
cedula
dirección
tel_resid
tel_cel
e_mail
Inicio

51. 1, 2, 3. así quedan las tablas
Info_personal
Info_academica
iden
Facultad
Carrera
Fecha_ingreso
Info_laborsocial
iden
Horas
Fecha_i
Fecha_f
Id_lugar
Id_tipo
iden
nombre
seg_nombre
apellido
seg_apellido
dirección
tel_resid
tel_cel
e_mail
Inicio

52. Segunda forma normal
• Crear tablas independientes para conjuntos de valores que se
apliquen a varios registros.
• Relacionar dichas tablas mediante una clave externa.
Los registros tan sólo deben depender de la clave principal de
una tabla (si es necesario, puede ser una clave compuesta).
Inicio

53. Todos los atributos que no son clave principal
deben depender únicamente de la clave
principal
Ejemplo: en la tabla lugares el nombre,
dirección y teléfono dependen del código de
lugar y de tipo de lugar a la hora de realizar
una consulta SQL.
Info_laborsocial
iden
Info_lugares
Info_tipos
Lugar
Id_lugar
Id_tipo
Horas
Nombre
Tipos
Fecha_i
dirección
Fecha_f
teléfono
Id_lugar
Id_tipos
Id_tipo
Inicio

54. Tercera forma normal
• Eliminar los campos que no dependan de la clave. Los valores de un registro que
no forman parte de la clave de dicho registro no pertenecen a esa tabla. En
general, siempre que el contenido de un grupo de campos se puede aplicar a más
de un registro de la tabla, debe tener en cuenta la posibilidad de incluir dichos
campos en una tabla independiente.
• EXCEPCIÓN: No es práctico siempre cumplir la forma tercera normal
teóricamente conveniente. Si tiene una tabla Clientes y desea eliminar todas las
posibles dependencias entre campos, debe crear tablas independientes para
ciudades, códigos postales, representantes de ventas, clases de clientes y
cualquier otro factor que pueda aparecer duplicado en varios registros. En teoría,
la normalización merece la pena. Sin embargo, la utilización de un gran número de
tablas pequeñas puede perjudicar el rendimiento o superar la capacidad de
memoria y de archivos abiertos del sistema.
Inicio

55. Después de normalizar
Inicio

56. DOCUMENTACIÓN
Inicio

57. •El sistema de base de datos de los estudiantes que realizan labor
social almacena información personal, académica y relacionada a la
labor social particular de cada uno.
•La base de datos cuenta con datos de los estudiantes actualizados que
pueden ser consultados mediante sentencias SQL, además pueden
aplicársele modificaciones de ser necesario.
•La base de datos realiza todo esto ya que se presenta la necesidad
dentro de la Universidad de Panamá de llevar un registro eficiente de
toda esta actividad y facilitar el proceso de recolección de requisitos
para los estudiantes graduandos
•De esta base de datos de labor social primero se elaboraron los
correspondientes modelos E-R y relacional a través del SGBD de
MySQL “MySQL Workbench que también nos sirvió para crear
posteriormente la base de datos.
Inicio

58. •Previo a todo lo anterior mencionado se había creado una base
de datos similar en la que se manejaron detalles de los
estudiantes y su labor social, mas no se tomó en cuenta las
instituciones involucradas en la actividad de labor social. Además
la base de datos contaba con una aplicación sencilla que
permitía ingresar nuevos datos y consultarlos, sin embargo por
circunstancias inesperadas actualmente no contamos con ella.
•En este momento, contamos con una nueva base de datos que
incluye los detalles obviados en el análisis anterior
Inicio

59. Conclusiones
Luego de realizar un trabajo previo sobre base de datos, contando
con los conocimientos que se nos brindaron en el curso de base de
datos, nos pudimos percatar de que no seguimos las etapas de
diseño de una base de datos relacional; no elaboramos un diseño
conceptual previo, además nuestro diseño lógico estuvo
incompleto, porque solamente elaboramos el modelo relacional
obviando las relaciones 1:n y n:n entre las entidades.
Nuestro diseño físico que consta de las consultas necesarias para
insertar datos, modificarlos y borrarlos si se realizaron en nuestro
proyecto, partiendo del modelo relacional, sin embargo, quedaron
muchos vacíos sin llenar porque la normalización requerida no fue
aplicada a nuestro primer modelo relacional. Nuestros
conocimientos previos sobre normalización de base de datos
relacionales aún estaban pobres.
Inicio

60. Conclusiones
Una vez que lidiamos con otras experiencias como el proyecto de
“Facturación” hemos podido afianzar en qué consiste el proceso
de normalización, y de esta manera hemos podido avanzar
aplicando las 3 primeras formas normales a nuestro nuevo modelo
relacional, cuya estructura fue modificada debido a que había
información que no había sido considerada para nuestro modelo
anterior.
Inicio

61. Recomendaciones
•Se recomienda a todos los estudiantes de cursos como el de base
de datos y análisis y diseño de sistemas que a la hora de elaborar
proyectos o tareas relacionadas, tomen en cuenta lo siguiente:
•El modelo relacional permite obtener una base de datos libre de
redundancias y óptima a través del proceso de normalización.
•Es propicio seguir cada paso en el diseño de datos de una base de
datos relacional: diseño conceptual, diseño lógico, diseño físico.
•Una vez efectuados cada uno de los pases de cada diseño,
elaborar entonces el modelo Entidad-Relación (E-R) y el modelo
relacional, ya sea a mano o con una herramienta que facilite
confeccionar estos diagramas
Inicio

62. Recomendaciones
•Cuando se hayan pasado cada una de estas etapas, entonces
realizaremos el proceso de normalización (1FN-FN-3FN) tomando
en cuenta conceptos como la dependencia funcional.
•Tomemos en cuenta las características con las que cuenta una
base de datos normalizadas, una vez hecho esto, podremos
entonces elaborar una interfaz gráfica en alguno de los lenguajes
de programación conocidos hasta ahora para conectar nuestra
base de datos y consultar datos más rápido de manera eficiente.
Inicio