Sei sulla pagina 1di 40
DISEÑO Y GESTION DE BASES DE DATOS
DISEÑO Y GESTION DE
BASES DE DATOS

Diego Fernando Camacho Marin

diegokamacho@yahoo.es
diegokamacho@yahoo.es
DISEÑO Y GESTION DE BASES DE DATOS Una base de datos o banco de datos
DISEÑO Y GESTION DE BASES DE DATOS
Una base de datos o banco de datos (en inglés: database) es un
conjunto de datos pertenecientes a un mismo contexto y
almacenados sistemáticamente para su posterior uso. En este
sentido, una biblioteca puede considerarse una base de datos
compuesta en su mayoría por documentos y textos impresos en
papel e indexados para su consulta.
En la actualidad, y debido al desarrollo tecnológico de campos como
la informática y la electrónica, la mayoría de las bases de datos están
en formato digital (electrónico), que ofrece un amplio rango de
soluciones al problema de almacenar datos.
Existen unos programas denominados sistemas gestores de bases de
datos, abreviado SGBD, que permiten almacenar y posteriormente
acceder a los datos de forma rápida y estructurada. Las propiedades
de estos SGBD, así como su utilización y administración, se estudian
dentro del ámbito de la informática.
Las aplicaciones más usuales son para la gestión de empresas e
instituciones públicas. También son ampliamente utilizadas en
entornos científicos con el objeto de almacenar la información
experimental.
DIEGO F. CAMACHO M.
diegokamacho@yahoo.es
DISEÑO Y GESTION DE BASES DE DATOS Tipos de bases de datos Según la variabilidad
DISEÑO Y GESTION DE BASES DE DATOS
Tipos de bases de datos
Según la variabilidad de los datos almacenados
Bases de datos estáticas
Bases de datos dinámicas
Según el contenido
Bases de datos bibliográficas
Bases de datos de texto completo
Directorios
Bases de datos o "bibliotecas"
de información
Biológica
DIEGO F. CAMACHO M.
diegokamacho@yahoo.es
diegokamacho@gmail.com
Modelos de bases de datos
Bases de datos jerárquicas
Base de datos de red
Base de datos relacional
Bases de datos multidimensionales
Bases de datos orientadas a objetos
Bases de datos documentales
Base de datos deductivas
Gestión de bases de datos distribuida
DISEÑO Y GESTION DE BASES DE DATOS Base de datos: colección de datos persistentes, relacionados
DISEÑO Y GESTION DE BASES DE DATOS
Base de datos: colección de datos persistentes, relacionados y
estructurados.
Un sistema de gestión de bases de datos (SGBD) es una
aplicación que permite trabajar con bases de datos:

Definir la información Insertar información Eliminar información Consultar la información Ordenar la información Filtrar la información Etcétera Microsoft Access, MySQL, Oracle, PostgreSQL, SQL Server, dBaseIV y Paradox de Borland, son ejemplos de sistemas de gestión de bases de datos.

DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com
DIEGO F. CAMACHO M.
diegokamacho@yahoo.es
diegokamacho@gmail.com
DISEÑO Y GESTION DE BASES DE DATOS El dato es la unidad de información elemental.
DISEÑO Y GESTION DE BASES DE DATOS
El dato es la unidad de información elemental.
Los datos pueden ser de diferentes tipos:
Texto: cuando en el campo vamos a introducir texto, tanto caracteres como dígitos.
Tiene una longitud por defecto de 50 caracteres, siendo su longitud máxima de 255
caracteres.
Memo: se utiliza para textos extensos como comentarios o explicaciones. Tiene una
longitud fija de 65.535 caracteres.
Numérico: para datos numéricos utilizados en cálculos matemáticos.
Fecha/Hora: para la introducción de fechas y horas desde el año 100 al año 9999.
Moneda: para valores de moneda y datos numéricos utilizados en cálculos
matemáticos en los que estén implicados datos que contengan entre uno y cuatro
decimales. La precisión es de hasta 15 dígitos a la izquierda del separador decimal y
hasta 4 dígitos a la derecha del mismo.
Autonumérico: número secuencial (incrementado de uno a uno) único, o número
aleatorio que Microsoft Access asigna cada vez que se agrega un nuevo registro a una
tabla. Los campos Autonumérico no se pueden actualizar.
DISEÑO Y GESTION DE BASES DE DATOS Sí/No: valores Sí y No, y campos que
DISEÑO Y GESTION DE BASES DE DATOS
Sí/No: valores Sí y No, y campos que contengan uno de entre dos valores (Sí/No,
Verdadero/Falso o Activado/desactivado).
Objeto OLE: Objeto (como por ejemplo una hoja de cálculo de Microsoft Excel, un
documento de Microsoft Word, gráficos, sonidos u otros datos binarios).
Hipervínculo: Texto o combinación de texto y números almacenada como texto y
utilizada como dirección de hipervínculo. Una dirección de hipervínculo puede
tener hasta tres partes:

Texto: el texto que aparece en el campo o control. Dirección: ruta de acceso de un archivo o página. Subdirección: posición dentro del archivo o página. Sugerencia: el texto que aparece como información sobre herramientas.

Existe otra posibilidad que es la Asistente para búsquedas que crea un campo que permite
Existe otra posibilidad que es la Asistente para búsquedas que crea un campo que
permite elegir un valor de otra tabla o de una lista de valores mediante un cuadro de
lista o un cuadro combinado. Al hacer clic en esta opción se inicia el Asistente para
búsquedas y al salir del Asistente, Microsoft Access establece el tipo de datos
basándose en los valores seleccionados en él.
DIEGO F. CAMACHO M.
diegokamacho@yahoo.es
diegokamacho@gmail.com
DISEÑO Y GESTION DE BASES DE DATOS Cada dato se mantiene en un campo. El
DISEÑO Y GESTION DE BASES DE DATOS
Cada dato se mantiene en un campo.
El conjunto de campos que describen un elemento de
información conforman un registro.
Por ejemplo, la información sobre una persona se mantiene en
un registro cuyos campos son los datos individuales de la
persona.
Datos sobre una persona:
DIEGO F. CAMACHO M.
diegokamacho@yahoo.es
diegokamacho@gmail.com
DISEÑO Y GESTION DE BASES DE DATOS Un registro es el conjunto de datos concretos
DISEÑO Y GESTION DE BASES DE DATOS
Un registro es el conjunto de datos concretos para los
distintos campos que describen un elemento de
información.
Los datos de cada persona se guardan en un registro.
Como podemos tener información sobre muchas personas,
podemos tener muchos registros.

Todos los registros de un determinado tipo de elemento de información (personas) se mantienen uno detrás de otro en lo que se conoce como tabla.

Una tabla es una sucesión de registros. Todos los registros de la tabla tienen los
Una tabla es una sucesión de registros.
Todos los registros de la tabla tienen los mismos campos.
DIEGO F. CAMACHO M.
diegokamacho@yahoo.es
diegokamacho@gmail.com
DISEÑO Y GESTION DE BASES DE DATOS NORMALIZACION Un pobre diseño de la base de
DISEÑO Y GESTION DE BASES DE DATOS
NORMALIZACION
Un pobre diseño de la base de datos puede afectar una
aplicación, produciendo problemas con la redundancia,
inexactitud consistencia
,
, y
concurrencia de sus datos La
.
normalización es un proceso que sirve para reducir, si no
eliminar, estos problemas con los datos. Dado que en los
negocios se utiliza la Tercer Forma Normal como el
modelo lógico, veremos los pasos de las 1ra, 2da, y 3ra
Forma Normal.
DIEGO F. CAMACHO M.
diegokamacho@yahoo.es
diegokamacho@gmail.com
DISEÑO Y GESTION DE BASES DE DATOS 1RA. Forma Normal La primer forma normal requiere
DISEÑO Y GESTION DE BASES DE DATOS
1RA. Forma Normal
La primer forma normal requiere que no existan atributos multi-valores,
asi como tampoco grupo de repeticion. Un atributo multi-valor contiene
más de un valor por ese campo en cada fila.
Consideremos la siguiente tabla referida a Cursos de estudiantes:
En esta tabla, el campo Curso es un campo multi-valor: no hay un
valor simple para cada campo.
Ahora considere este otro ejemplo:
DIEGO F. CAMACHO M.
diegokamacho@yahoo.es
diegokamacho@gmail.com
DISEÑO Y GESTION DE BASES DE DATOS Los campos Curso1, Curso2 y Curso3 representan grupos
DISEÑO Y GESTION DE BASES DE DATOS
Los campos Curso1, Curso2 y Curso3 representan grupos repetitivos. Si
aplicamos los requisitos de la Primer Forma Normal el ejemplo quedaria de la
siguiente manera:
En los primeros 2 ejemplos, seleccionar un estudiante inscripto en algun curso
es una tarea dificultosa. Digamos que quiero saber lo siguiente:
Dígame todos los estudiantes inscriptos en el curso 3100.
En el primer diseño, Ud. deberá tomar el campo Curso y analizarlo de alguna
forma "por dentro" para saber si cumple o no con los requisitos de la
busqueda.
En el segundo diseño, deberá analizar 3 campos por separado para saber si el
alumno está inscripto en el curso 3100.
En el tercer diseño, la consulta es tan simple como :
Select Nro de Registro from Cursos where Curso = 3100
DIEGO F. CAMACHO M.
diegokamacho@yahoo.es
diegokamacho@gmail.com
DISEÑO Y GESTION DE BASES DE DATOS
DISEÑO Y GESTION DE BASES DE DATOS

2DA.Forma Normal La Segunda Forma Normal requiere que cualquier campo no integrante de la Clave Primaria, debería ser totalmente dependiente de la clave. Por ejemplo, considere la siguiente tabla de Cursos, donde Nro de Registro y Curso componen la clave primaria.

DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com
DIEGO F. CAMACHO M.
diegokamacho@yahoo.es
diegokamacho@gmail.com
DISEÑO Y GESTION DE BASES DE DATOS El Nombre del estudiante no depende de toda
DISEÑO Y GESTION DE BASES DE DATOS
El Nombre del estudiante no depende de toda la clave primaria, sino
solo del Nro de Registro. El Depto. es un campo que solo depende del
Curso.
En consecuencia, estos datos deberían ser divididos en 3 tablas
separadas, a saber:
En este ejemplo, el campo Nota es el unico dependiente de la clave
primaria completa.
DIEGO F. CAMACHO M.
diegokamacho@yahoo.es
diegokamacho@gmail.com
DISEÑO Y GESTION DE BASES DE DATOS 3RA. Forma Normal La tercera forma normal prohíbe
DISEÑO Y GESTION DE BASES DE DATOS
3RA. Forma Normal
La tercera forma normal prohíbe dependencias transitivas. Una
dependencia transitiva existe cuando cualquier atributo en una tabla es
dependiente de otro campo y éste es quien depende de la clave primaria.
Considere el siguiente ejemplo de una tabla de Cursos:
DIEGO F. CAMACHO M.
diegokamacho@yahoo.es
diegokamacho@gmail.com
DISEÑO Y GESTION DE BASES DE DATOS El campo Nombre de Profesor depende de Nro
DISEÑO Y GESTION DE BASES DE DATOS
El campo Nombre de Profesor depende de Nro de Profesor, el cual es
el campo que realmente depende de la clave primaria. Por ello, el
campo Nombre Profesor debe ser quitado y colocado en otra tabla:
Dividiendo los datos en 2 tablas, la dependencia transitiva es
removida.
DIEGO F. CAMACHO M.
diegokamacho@yahoo.es
diegokamacho@gmail.com
DISEÑO Y GESTION DE BASES DE DATOS NORMALIZACION Un pobre diseño de la base de
DISEÑO Y GESTION DE BASES DE DATOS
NORMALIZACION
Un pobre diseño de la base de datos puede afectar una
aplicación, produciendo problemas con la redundancia,
inexactitud consistencia
,
, y
concurrencia de sus datos La
.
normalización es un proceso que sirve para reducir, si no
eliminar, estos problemas con los datos. Dado que en los
negocios se utiliza la Tercer Forma Normal como el
modelo lógico, veremos los pasos de las 1ra, 2da, y 3ra
Forma Normal.
DIEGO F. CAMACHO M.
diegokamacho@yahoo.es
diegokamacho@gmail.com
DISEÑO Y GESTION DE BASES DE DATOS 1RA. Forma Normal La primer forma normal requiere
DISEÑO Y GESTION DE BASES DE DATOS
1RA. Forma Normal
La primer forma normal requiere que no existan atributos multi-valores,
asi como tampoco grupo de repeticion. Un atributo multi-valor contiene
más de un valor por ese campo en cada fila.
Consideremos la siguiente tabla referida a Cursos de estudiantes:
En esta tabla, el campo Curso es un campo multi-valor: no hay un
valor simple para cada campo.
Ahora considere este otro ejemplo:
DIEGO F. CAMACHO M.
diegokamacho@yahoo.es
diegokamacho@gmail.com
DISEÑO Y GESTION DE BASES DE DATOS Los campos Curso1, Curso2 y Curso3 representan grupos
DISEÑO Y GESTION DE BASES DE DATOS
Los campos Curso1, Curso2 y Curso3 representan grupos repetitivos. Si
aplicamos los requisitos de la Primer Forma Normal el ejemplo quedaria de la
siguiente manera:
En los primeros 2 ejemplos, seleccionar un estudiante inscripto en algun curso
es una tarea dificultosa. Digamos que quiero saber lo siguiente:
Dígame todos los estudiantes inscriptos en el curso 3100.
En el primer diseño, Ud. deberá tomar el campo Curso y analizarlo de alguna
forma "por dentro" para saber si cumple o no con los requisitos de la
busqueda.
En el segundo diseño, deberá analizar 3 campos por separado para saber si el
alumno está inscripto en el curso 3100.
En el tercer diseño, la consulta es tan simple como :
Select Nro de Registro from Cursos where Curso = 3100
DIEGO F. CAMACHO M.
diegokamacho@yahoo.es
diegokamacho@gmail.com
DISEÑO Y GESTION DE BASES DE DATOS
DISEÑO Y GESTION DE BASES DE DATOS

2DA.Forma Normal La Segunda Forma Normal requiere que cualquier campo no integrante de la Clave Primaria, debería ser totalmente dependiente de la clave. Por ejemplo, considere la siguiente tabla de Cursos, donde Nro de Registro y Curso componen la clave primaria.

DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com
DIEGO F. CAMACHO M.
diegokamacho@yahoo.es
diegokamacho@gmail.com
DISEÑO Y GESTION DE BASES DE DATOS El Nombre del estudiante no depende de toda
DISEÑO Y GESTION DE BASES DE DATOS
El Nombre del estudiante no depende de toda la clave primaria, sino
solo del Nro de Registro. El Depto. es un campo que solo depende del
Curso.
En consecuencia, estos datos deberían ser divididos en 3 tablas
separadas, a saber:
En este ejemplo, el campo Nota es el unico dependiente de la clave
primaria completa.
DIEGO F. CAMACHO M.
diegokamacho@yahoo.es
diegokamacho@gmail.com
DISEÑO Y GESTION DE BASES DE DATOS 3RA. Forma Normal La tercera forma normal prohíbe
DISEÑO Y GESTION DE BASES DE DATOS
3RA. Forma Normal
La tercera forma normal prohíbe dependencias transitivas. Una
dependencia transitiva existe cuando cualquier atributo en una tabla es
dependiente de otro campo y éste es quien depende de la clave primaria.
Considere el siguiente ejemplo de una tabla de Cursos:
DIEGO F. CAMACHO M.
diegokamacho@yahoo.es
diegokamacho@gmail.com
DISEÑO Y GESTION DE BASES DE DATOS El campo Nombre de Profesor depende de Nro
DISEÑO Y GESTION DE BASES DE DATOS
El campo Nombre de Profesor depende de Nro de Profesor, el cual es
el campo que realmente depende de la clave primaria. Por ello, el
campo Nombre Profesor debe ser quitado y colocado en otra tabla:
Dividiendo los datos en 2 tablas, la dependencia transitiva es
removida.
DIEGO F. CAMACHO M.
diegokamacho@yahoo.es
diegokamacho@gmail.com
OTROS EJEMPLOS DE NORMALIZACION DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com

OTROS EJEMPLOS DE NORMALIZACION

DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com

Normalización La normalización es el proceso de organizar los datos en una base de datos.

Normalización

La normalización es el proceso de organizar los datos en una base de datos. Esto incluye la creación de tablas y que establece relaciones entre aquellas tablas según reglas diseñadas para proteger los datos y hacer la base de datos que es más flexible al eliminar redundancia y dependencia incoherente.

Los datos redundantes desperdician espacio en disco y crean problemas de mantenimiento. Si es necesario cambiar datos que aparecen en más de un sitio, el cambio deberá ser exactamente igual en todos estos sitios. Por ejemplo, un cambio de dirección de un cliente es mucho más fácil de implementar si los datos sólo se almacenan en la tabla Clientes y en ningún otro lugar de la base de datos.

DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com

Normalización ¿Qué es una "dependencia incoherente"? Aunque para un usuario puede resultar intuitivo buscar la

Normalización

¿Qué es una "dependencia incoherente"? Aunque para un usuario puede resultar intuitivo buscar la dirección de un determinado cliente en la tabla Clientes, es posible que no tenga sentido buscar en esa misma tabla el sueldo del empleado que atiende a dicho cliente. El salario del empleado está relacionado con el empleado (es decir, existe una dependencia entre ambos), por lo que debe moverse a la tabla Empleados. Las dependencias incoherentes pueden dificultar el acceso a los datos, ya que la ruta de acceso a los mismos puede estar rota o no encontrarse.

Existen unas cuantas reglas para la normalización de bases de datos. Cada regla se denomina "forma normal" Si se cumple la primera regla, se dice que la base de datos está en la "primera forma normal" Si se cumplen las tres primeras reglas, se considera que la base de datos está en la "tercera forma normal" Aunque existen otros niveles de normalización, se considera que la tercera forma normal es el máximo nivel necesario para la mayoría de las aplicaciones.

DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com

Primera forma normal Eliminar grupos repetidos en tablas individuales. Crear una tabla diferente para cada

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.

DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com

Ejemplo Artículo Prov1 Prov2 Prov3 Maíz - Granja - En lugar de hacer varios Arroz
Ejemplo
Artículo
Prov1
Prov2
Prov3
Maíz
- Granja
-
En lugar de hacer varios
Arroz
Casita
-
-

Código

Proveedor

145

Casita

154

Granja

Artículo

Cod.Prov

Maíz

154

Arroz

145

campos para los proveedores en una sola tabla, hacemos otra tabla con el campo proveedor y colocamos varios registros para los proveedores (tabla de en medio). Sustituimos la tabla superior de la izquierda por la tabla inferior.

DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com

Segunda forma normal Crear tablas independientes para conjuntos de valores que se apliquen a varios

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).

DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com

Ejemplo piense en la dirección de un cliente en un sistema de contabilidad. La dirección

Ejemplo

piense en la dirección de un cliente en un sistema de contabilidad. La dirección es necesitada por la tabla Clientes pero por las tablas Pedidos, Facturas y Cuentas a cobrar también. En lugar de almacenar la dirección del cliente como una entrada diferente en cada tabla, almacénela en un único lugar, ya sea en la tabla Clientes o en una tabla de direcciones independiente.

DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com

Tercera forma normal Eliminar los campos que no dependan de la clave. Los valores de

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.

DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com

Otras formas normales Otras formas de normalización Existe una cuarta forma normal, llamada también Forma

Otras formas normales

Otras formas de normalización Existe una cuarta forma normal, llamada también Forma normal de Boyce Codd (BCNF), y una quinta forma normal, pero pocas veces se consideran prácticas en un diseño. La omisión de estas reglas puede dar como resultado una tabla que no sea perfecta, pero no debería afectar a su funcionamiento

DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com

Haga esta tabla en Access para normalizarla. La tabla se llama alumnos
Haga esta tabla en Access para normalizarla. La tabla se llama alumnos
tabla en Access para normalizarla. La tabla se llama alumnos DIEGO F. CAMACHO M. diegokamacho@yahoo.es

DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com

Primera forma normal: Ningún grupo repetido Como cada alumno se encuentra inscrito en varios cursos,

Primera forma normal: Ningún grupo repetido

Como cada alumno se encuentra inscrito en varios cursos, estos deben aparecer en una tabla independiente. Los campos curso1, curso2, curso3 de los registros anteriores indican que existe un problema en el diseño.

DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com

DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com
DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com
DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com

DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com

Segunda forma Normal: Elimine datos redundantes Curso no depende del carné (que será nuestra clave

Segunda forma Normal: Elimine datos redundantes

Curso no depende del carné (que será nuestra clave principal) por lo que la tabla no esta en la segunda forma normal. Debemos separar la información de los cursos-alumnos a otra tabla. Haremos la tabla asignaciones.

DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com

Asignaciones
Asignaciones
Asignaciones Tabla alumnos luego del cambio DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com
Asignaciones Tabla alumnos luego del cambio DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com

Tabla alumnos luego del cambio

Asignaciones Tabla alumnos luego del cambio DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com

DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com

Tercera forma Normal: Eliminar datos que no dependen de la clave De el último ejemplo

Tercera forma Normal: Eliminar datos que no dependen de la clave

De el último ejemplo la oficina del asesor depende funcionalmente del atributo asesor. La solución es mover dicho atributo de la tabla alumnos a la tabla personal, como se muestra a continuación.

DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com

Tabla Alumno
Tabla Alumno
Tabla Alumno Tabla Personal DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com

Tabla Personal

Tabla Alumno Tabla Personal DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com

DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com

Normalizada DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com

Normalizada

Normalizada DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com
Normalizada DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com
Normalizada DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com

DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com

Hemos llegado finalmente a una base de datos bien organizada en la cual podemos actualizar

Hemos llegado finalmente a una base de datos bien organizada en la cual podemos actualizar o cambiar los datos almacenados fácilmente y de una manera ordenada sin alterar los demás registros.

DIEGO F. CAMACHO M. diegokamacho@yahoo.es diegokamacho@gmail.com