Teoría de Base de Datos

1. Profesor José J. Reyes reyesjj@gmail.com 809-903-8876 Teoría de Base de Datos

2. Asignatura • Créditos y Horarios: 3 Créditos de Teorías Sábados: 1100 - 1400 2 Créditos de Laboratorio Jueves: 2000 – 2200 • Puntuación: -TP 25 Pts. 20 Laboratorio 5 Participación -TI 10 Pts. 5 Trabajo de Investigación 5 Presentación del TI. -PP 15 Pts. Examen Teórico. -SP 20 Pts. Examen 50%Teórico y 50% Practico. -EF 30 Pts. Examen 20% Teórico y 80% Practico 100 pts

3. Asignatura • Notas y Reglas: • Para pasar debe sacar la mitad mas 1 del examen final. • Quien no asista a la presentación del TI pierde los puntos del trabajo. • Faltar a un examen es sacar cero (0) en ese examen, no hay convalidaciones. • No se reciben trabajos con entregas tardes. • Los celulares deben de permanecer en silencio y/o apagados. • Se permite entrada solo hasta 15 minutos antes de la hora de inicio de clases. • Si el profesor llegar tarde por encima de los 15 minutos, tiene 5 minutos para reportarse al aula. • Pueden esperar al profesor media hora después del inicio de la clase, sino llega pueden retirarse, excepto si el profesor los contactas para informar que esperen hasta una hora especifica.

4. Objetivos • Al final de esta asignatura usted será capaz de: • Definir los principales conceptos de Dase de Datos y Sistemas Gestores de Base de Datos. • Poder distinguir los diferentes elementos de los Modelos de Datos Relacional. • Entender y crear un Diagrama de Entidad y Relación Nivel Lógico y convertirlo a Nivel Físico. • Entender la arquitectura básica de la Base de Datos ORACLE. • Conectarse e interactuar con el SGBD Oracle. • Creación, manipulación y despliegue de datos con sentencias DDL, DML y SQL.

5. Programa del Curso. • El curso contendrá los siguientes módulos. • Definiciones. • Modelo de Datos. • Modelo Relacional. • Modelo E/R. • SQL’s.

6. Contenido de Módulos. • Modelo de Datos. • Introducción • Los usuarios • Ciclo de vida • Análisis de las necesidades • Estudio de viabilidad • Definición de requisitos • Diseño • Implementación • Evaluación y Perfeccionamiento • Criterios de calidad • Indicadores de calidad • El modelo lógico • Clasificación • Agregación • Generalización • Asociación • Restricciones de integridad • Definiciones. • Base de Datos. • BD Distribuidas • SGDB. • Arquitectura ANSI/SPARC. • Nivel Externo. • Nivel Conceptual. • Nivel Interno. • Arq. Cliente/Servidor o 2 capas. • ODBC • Archivos TNS’s. • Arq. N Capas. • JDBC. • Base de Datos Distribuidas. • Data Warenhouse. • Data Mining. • Sistemas Prerrelaciónales. • Sistemas Relacionales.

7. Contenido de Módulos. • Modelo Relacional. • Introducción. • Proceso de normalización. • Definición de la clave • Primera forma normal (1NF) • Segunda forma normal (2NF) • Tercera forma normal (3NF) • Cuarta forma normal (4NF) • Otras formas normales • Las interrelaciones. • Interrelaciones uno a uno • Interrelaciones uno a varios • Interrelaciones varios a varios • Problemas con las interrelaciones • Atributos de las interrelaciones • Algebra relacional. • Cálculo relacional. • Cuantificadores existenciales • Cuantificadores universales • Modelo E/R. • Entidades • Atributos • Dominios • Claves • Interrelaciones • Restricciones en las interrelaciones • Restricción de Exclusividad • Restricción de Exclusión • Restricción de Inclusividad • Restricción de Inclusión • Ejemplo.

8. Contenido de Módulos. • SQL’s • Introducción y Breve Historia • Componentes del SQL • Comandos • Consultas de Selección • Consultas Básicas • Ordenar los Registros • Alias • Criterios de Selección • Operadores Lógicos • El Operador Like y In. • La cláusula WHERE • Agrupamiento de Registros y Funciones Agregadas • La cláusula GROUP BY • AVG (Media Aritmética) • Count (Contar Registros) • Max y Min (Valores Máximos y Mínimos) • Sum (Sumar Valores) • Consultas de Acción. • DELETE borrar registros, • INSERT INTO Insertar un único Registro • UPDATE • Subconsultas

9. Grupo Google • Estaremos en contacto en el grupo Google: http://groups.google.com/group/teoriadebasededatos • Hacer debates. • Enviar mensajes. • Recibir tareas. • Compartir documentos. • Presentaciones de clase. • Informaciones general sobre la clase.

10. Investigaciones y Grupos • Se definirán 5 grupos de 3 a 4 personas para el TI. • Teoría Relacional de E.F. Codd. • Modelo Orientado a Objeto. • Definiciones. • Herencia. • Polimorfismo. • Diagramas UML. • Normalización. • 1FN • 2FN • 3FN • 4FN • Otras FN • Datawarehouse. • Otras Base de Datos. • Ventajas. • Arquitectura. • Comparación con Oracle.

11. Ley Murphy Ley de Murphy La ley fue enunciada por Edward A. Murphy Jr., un ingeniero de desarrollo que trabajó por un breve período en experimentos con cohetes sobre rieles hechos por la Fuerza Aérea de los Estados Unidos en 1949. La Ley de Murphy es una forma cómica y mayormente ficticia de explicar los infortunios en todo tipo de ámbitos que, a grandes rasgos, se basa en el adagio: "Si algo puede salir mal, saldrá mal“ y se puede utilizar en todo tipo de situaciones, desde las de la vida cotidiana hasta aquellas más importantes

12. Leyes de Murphy aplicables al diseño. • Desde luego hay que reconocer que: "si algo puede fallar fallará" y además "lo hará de la forma que más destrozos haga". • Si algo puede salir mal, saldrá mal. • Nada es tan fácil como parece. • Todo lleva más tiempo del que usted piensa. • Si existe la posibilidad de que varias cosas vayan mal, la que cause más perjuicios será la única que vaya mal. • Cuando se ponga a hacer algo, se dará cuenta que hay otra cosa que debería haber hecho antes. • Es inútil hacer cualquier cosa a prueba de tontos, porque los tontos son muy ingeniosos.

13. Leyes de Murphy aplicables al diseño. • Nadie por si mismo, puede hacer las cosas lo suficientemente bien. • Siempre hay una forma más sencilla de hacerlo. • Lo que va mal, por lo general, tiene aspecto de funcionar bien. • Cuando se ha detectado y corregido un error, se suele descubrir que no era un error. • Si un experimento funciona, es que algo ha ido mal. • No importa cuál sea el resultado previsto. Siempre habrá alguien impaciente por: • Malinterpretarlo; • imitarlo, ó • Creer que ha sido a causa de su teoría favorita • Si pide ayuda a alguien no sabrá ver el error. Cualquiera que le eche un vistazo, sin que usted o pida, lo verá inmediatamente. • Si funciona la modificación de un programador a un programa ya existente, es probable que no sea lo que quieren los usuarios. • Los usuarios no saben realmente lo que quieren, pero saben con certeza lo que no quieren. • "¡Y nos lo dicen ahora!").

14. Leyes de Murphy aplicables al diseño. • Cualquier programa, cuando funciona, es que se ha quedado antiguo. • Cualquier programa cuesta más caro y se necesita más tiempo. • Si un programa es útil, habrá que cambiarlo. • Si un programa es inútil, habrá que demostrarlo. • Cualquier programa se expandirá hasta ocupar toda la memoria de la PC. • Si una instalación de comprobación funciona perfectamente bien, todos los sistemas posteriores funcionarán mal. • El error más terrible de un programador sólo se detectará cuando lleve, por lo menos, seis meses de funcionamiento. • Si se ha diseñado el editor de entrada de tal forma que rechace entradas nocivas, siempre habrá algún idiota que descubra el método para que se cuelen datos que no deben. • Los ordenadores no son fiables, pero los seres humanos lo son menos aún. • Cualquier sistema que dependa de la fiabilidad humana, no es fiable. “Construya un sistema que pueda utilizar hasta un tonto y sólo lo querrán utilizar los tontos.”

15. Teoría de BD Definiciones Primera Parte