Teoría de Base Teoría de Base de Datosde Datos

Profesor José J. Reyesreyesjj@gmail.com

809-903-8876

Asignatura

• Créditos y Horarios:3 Créditos de Teorías

Sábados: 1100 - 14002 Créditos de Laboratorio

Jueves: 2000 – 2200• Puntuación:-TP 25 Pts.

20 Laboratorio 5 Participación

-TI 10 Pts. 5 Trabajo de Investigación5 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

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.

Asignatura

Al final de esta asignatura usted será capaz de:

1. Definir los principales conceptos de Dase de Datos y Sistemas Gestores de Base de Datos.

1. Poder distinguir los diferentes elementos de los Modelos de Datos Relacional.

1. Entender y crear un Diagrama de Entidad y Relación Nivel Lógico y convertirlo a Nivel Físico.

1. Entender la arquitectura básica de la Base de Datos ORACLE.

1. Conectarse e interactuar con el SGBD Oracle.

1. Creación, manipulación y despliegue de datos con sentencias DDL, DML y SQL.

Objetivos

Programa del Curso.

El curso contendrá los siguientes módulos.

1. Definiciones.2. Modelo de Datos.3. Modelo Relacional.4. Modelo E/R.5. SQL’s.

Contenido de Módulos.

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

• 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

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

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

Contenido de Módulos.

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

Grupo Google

Investigaciones y Grupos

Se definirán 5 grupos de 3 a 4 personas para el TI.

1. Teoría Relacional de E.F. Codd.2. Modelo Orientado a Objeto.

1. Definiciones.1. Herencia.2. Polimorfismo.

2. Diagramas UML.3. Normalización.

1. 1FN2. 2FN3. 3FN4. 4FN5. Otras FN

4. Datawarehouse.5. Otras Base de Datos.

– Ventajas.– Arquitectura.1. Comparación con Oracle.

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

Ley Murphy

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.

• 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!").

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

Leyes de Murphy aplicables al

diseño.

Teoría de BD Definiciones Primera Parte