Proyecto de Base de Datos

860 visualizaciones

Publicado el

Publicado en: Tecnología
0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
860
En SlideShare
0
De insertados
0
Número de insertados
3
Acciones
Compartido
0
Descargas
21
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Proyecto de Base de Datos

  1. 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. 2. Elaborado por: Solineth Batista y Samuel Rodríguez
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 13. ¿Qué hicimos el semestre pasado? Plantear el modelo relacional previo a la presentación final: Inicio
  14. 14. modelo relacional anterior Inicio
  15. 15. Base de Datos completa con datos y consultas SQL Inicio
  16. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 27. DISEÑO CONCEPTUAL Inicio
  28. 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. 29. Info_personal Realiza Info_laborsocial Pueden tener Tiene contiene Info_urgencia Se clasifican Info_lugares Info_academica Info_tipos Inicio
  30. 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. 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. 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. 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. 34. DISEÑO LOGICO Inicio
  35. 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. 36. Info_personal IDEN NOMBRE SEG_NOMBRE APELLIDO SEG_APELLIDO Inicio CEDULA TEL_RESID TEL_CEL E_MAIL
  37. 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. 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. 39. Info_personal Modelo Relacional Tiene Info_personal (iden) Info_academica (iden) Info_academica Inicio
  40. 40. Info_personal Pueden tener Modelo Relacional Info_urgencia Info_personal (iden) Info_urgencia (iden) Inicio
  41. 41. Info_personal Info_laborsocial Realiza Modelo Relacional Info_personal (iden) Info_laborsocial (iden) Inicio
  42. 42. Info_laborsocial contiene Modelo Relacional Info_lugares Info_laborsocial (iden, id_lugar) Info_lugares (id_lugar, id_tipo) Inicio
  43. 43. Info_lugares Se clasifican Info_tipos Modelo Relacional Info_lugares (id_lugar, id_tipo) Info_tipos (id_tipo) Inicio
  44. 44. Diseño Lógico: modelo relacional actual Inicio
  45. 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. 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. 47. NORMALIZACIÓN Inicio
  48. 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. 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. 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. 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. 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. 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. 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. 55. Después de normalizar Inicio
  56. 56. DOCUMENTACIÓN Inicio
  57. 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. 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. 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. 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. 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. 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

×