Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Diapositivas sql.

3,527 views

Published on

  • Be the first to comment

Diapositivas sql.

  1. 1. COLEGIO DE ESTUDIOS CIENTIFICOS Y TECNOLOGICOS DEL ESTADO DE MEXICO. PROFESORA: YOLANDA RAMIREZ FIGUEROA.
  2. 2. ALUMNA: YATZENY MEDINA RIOS. TEMAS.  NORMALIZACION.  MODELO ENTIDAD – RELACION.  DICCIONARIO DE DATOS.  LENGUAJE SQL.
  3. 3. INTRODUCCION.  El objetivo principal de las bases de datos es el de unificar los datos que se manejan y los programas o aplicaciones que los manejan.
  4. 4. NORMALIZACION.  La Normalización o estandarización es la redacción y aprobación de normas, respecto a problemas presentes o potenciales, estableciendo una serie de especificaciones sobre cualidades, módulos, métodos, unidades de medida o condiciones que deben ser adoptadas o tenidas en cuenta como modelo a seguir. O sea la Normalización consiste en formular, difundir y aplicar disposiciones o normas que deberán cumplirse ante problemas o situaciones de repetición constante, con el fin de lograr un orden y un proceso justo y equitativo.
  5. 5. FINALIDAD. Mediante estas técnicas de base de datos se pretende conseguir a través del Sistema Gestor de Bases de Datos(SGBD):  INDEPENDENCIA de los Datos: Cambios en la estructura de la Base de Datos no modifican las aplicaciones.  INTEGRIDAD de los Datos: Los datos han de ser siempre correctos. Se establecen una serie de restricciones (reglas de validación) sobre los datos.  SEGURIDAD de los Datos: Control de acceso a los datos para evitar manipulaciones de estos no deseadas.
  6. 6. LAS REGLAS MÁS IMPORTANTES DE NORMALIZACIÓN SON: REGLA. DESCRIPCION. PRIMERA FORMA NORMAL. (1FN) SEGUNDA FORMA NORMAL. (2FN) TERCERA FORMA NORMAL. (3FN) INCLUYE LA ELIMINACION DE TODOS LOS DATOS REPETIDOS. ASEGURA QUE TODAS LAS COLUMNAS QUE NO SON LLAVES SEAN COPLETAMENTE DEPENDIENTES DE LA LLAVE PRIMARIA (PK). ELIMINA CUALQUIER DEPENDENCIA TRANSITIVA. UNA DEPENDENCIA TRANSITIVA ES AQUELLA EN LA CUAL LAS COLUMNAS QUE NO SON LLAVES SON DEPENDIENTES DE OTRAS COLUMNAS QUE TAMPOCO SON LLAVES.
  7. 7. NORMALIZACION.
  8. 8. OBJETIVOS DE LA NORMALIZACION.  Simplificación, Unificación y Especificación.
  9. 9. SIMPLIFICACIÓN.  Se trata de reducir los modelos para quedarse únicamente con los más necesarios.
  10. 10. UNIFICACION.  Para permitir el intercambio a nivel internacional.
  11. 11. ESPECIFICACION.  Se persigue evitar errores de identificación creando un lenguaje claro y preciso.
  12. 12. OBJETIVOS.  Evitar la redundancia de datos.  Proteger y dar un mejor soporte a la integridad de los datos.  Eliminar las anomalías en los datos, tanto en las actualizaciones como en las inserciones y los borrados.  Reducir en la medida de lo posible el rediseño de la base de datos cuando ésta se amplía.  Hacer más entendible el modelo de datos a quienes vayan a utilizarlo, puesto que se modeliza mejor la realidad, el dominio del problema.  Huir de las ataduras con lenguajes específicos para la consulta de datos (algo que preocupaba bastante a Codd, al que parece ser no le gustaba demasiado el SQL).
  13. 13. NOS SIRVE PARA:  Regular los requisitos mínimos que debe cumplir un producto en cuanto a seguridad, conformidad, inspección, salud pública, protección del ambiente o prevención de prácticas que induzcan a error al consumidor.
  14. 14. ETAPAS.  DE LA NORMALIZACION.
  15. 15. Primera Forma Normal (1FN).  SE DEBE CUMPLIR CON LO SIGUIENTE:  Una relación R se encuentra en 1FN si y solo sí por cada renglón columna contiene valores atómicos.  Las celdas de las tablas poseen valores simples y no se permiten grupos ni arreglos repetidos como valores, es decir, contienen un solo valor por cada celda.  Todos los ingresos en cualquier columna (atributo) deben ser del mismo tipo.  Cada columna debe tener un nombre único, el orden de las columnas en la tabla no es importante.  Dos filas o renglones de una misma tabla no deben ser idénticas, aunque el orden de las filas no es importante.
  16. 16. EJEMPLO.  Primera forma normal.
  17. 17. 2FN.  Una relación está en 2FN si está en 1FN y si los atributos que no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependencias parciales. (Todos los atributos que no son clave principal deben depender únicamente de la clave principal).  En otras palabras podríamos decir que la segunda forma normal está basada en el concepto de dependencia completamente funcional. Una dependencia funcional es completamente funcional si al eliminar los atributos A de X significa que la dependencia no es mantenida, esto es que . Una dependencia funcional es una dependencia parcial si hay algunos atributos que pueden ser eliminados de X y la dependencia todavía se mantiene, esto es .
  18. 18. EJEMPLO.  {DNI, ID_PROYECTO} HORAS_TRABAJO (con el DNI de un empleado y el ID de un proyecto sabemos cuántas horas de trabajo por semana trabaja un empleado en dicho proyecto) es completamente dependiente dado que ni DNI HORAS_TRABAJO ni ID_PROYECTO HORAS_TRABAJO mantienen la dependencia. Sin embargo {DNI, ID_PROYECTO} NOMBRE_EMPLEADO es parcialmente dependiente dado que DNI NOMBRE_EMPLEADO mantiene la dependencia.
  19. 19. EJEMPLO.  Ejemplo de segunda forma normal.
  20. 20. 3FN  La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional transitiva entre los atributos que no son clave.  Un ejemplo de este concepto sería que, una dependencia funcional X->Y en un esquema de relación R es una dependencia transitiva si hay un conjunto de atributos Z que no es un subconjunto de alguna clave de R, donde se mantiene X->Z y Z->Y.
  21. 21. EJEMPLO.  Ejemplo de la tercera forma normal.
  22. 22. 4FN.  Una tabla se encuentra en 4FN si, y sólo si, para cada una de sus dependencias múltiples no funcionales X->->Y, siendo X una super-clave que, X es o una clave candidata o un conjunto de claves primarias.
  23. 23. EJEMPLO.  Cuarta forma normal.
  24. 24. MODELO ENTIDAD – RELACION.  (A veces denominado por sus siglas en inglés, E-R "Entity relationship", o del español DER "Diagrama de Entidad Relación") es una herramienta para el MODELADO DE DATOS que permite representar las entidades relevantes de un SISTEMA DE INFORMACIÓN así como sus interrelaciones y propiedades.
  25. 25. Utiliza diagramas de entidad relación. Consiste en los siguientes pasos. 1.- Se parte de una descripción textual del problema o sistema de información a automatizar (los requisitos). 2.- Se hace una lista de sustantivos y verbos que aparecen. 3.- Los sustantivos son posibles entidades o atributos. 4.- Los verbos son posibles relaciones. 5. -Analizando las frases se determina la cardinalidad de las relaciones y otros detalles. 6.- se elabora el diagrama o (diagramas) entidad . Relación. 7.- se completa el modelo con listas de atributos y una descripción de otras restricciones que no se pueden reflejar en el diagrama. Se caracteriza por utilizar una serie de símbolos y reglas Para representar los datos y sus relaciones. Representa de manera gráfica la estructura lógica De una base de datos.
  26. 26. ESTA FORMADO:  El modelo de datos entidad-relación está basado en una percepción del mundo real que consta de una colección de objetos básicos, llamados entidades, y de relaciones entre esos objetos.
  27. 27. ENTIDAD.  Representa una “cosa” u "objeto" del mundo real con existencia independiente, es decir, se diferencia unívocamente de otro objeto o cosa, incluso siendo del mismo tipo, o una misma entidad.
  28. 28. Ejemplos:  Una persona. (Se diferencia de cualquier otra persona, incluso siendo gemelos).  Un automóvil. (Aunque sean de la misma marca, el mismo modelo,..., tendrán atributos diferentes, por ejemplo, el número de chasis).  Una casa (Aunque sea exactamente igual a otra, aún se diferenciará en su dirección
  29. 29. DIAGRAMA E.R.
  30. 30. RELACION.  Describe cierta dependencia entre entidades o permite la asociación de las mismas.
  31. 31. EJEMPLO:  Si tenemos dos entidades, "CLIENTE" y "HABITACION", podemos entender la relación entre ambas al tomar un caso concreto (ocurrencia) de cada una de ellas. Entonces, podríamos tener la ocurrencia "Habitación 502", de la entidad "HABITACION" y la ocurrencia "Henry Jonshon Mcfly Bogard", de la entidad "CLIENTE", entre las que es posible relacionar que la habitación 502 se encuentra ocupada por el huésped de nombre Henry.  Una relación tiene sentido al expresar las entidades que relaciona. En el ejemplo anterior, podemos decir que un huésped (entidad), se aloja (relación) en una habitación (entidad).
  32. 32. CLAVES.  Es un subconjunto del conjunto de atributos comunes en una colección de entidades, que permite identificar inequívocamente cada una de las entidades pertenecientes a dicha colección. Asimismo, permiten distinguir entre sí las relaciones de un conjunto de relaciones.  Dentro de los conjuntos de entidades existen los siguientes tipos de claves:  Superclave: Es un subconjunto de atributos que permite distinguir unívocamente cada una de las entidades de un conjunto de entidades. Si se añade un atributo al anterior subconjunto, el resultado seguirá siendo una superclave.  Clave candidata: Dada una superclave, si ésta deja de serlo quitando únicamente uno de los atributos que la componen, entonces ésta es una clave candidata.  Clave primaria: Es una clave candidata, elegida por el diseñador de la base de datos, para identificar unívocamente las entidades en un conjunto de entidades.
  33. 33. DICCIONARIO DE DATOS.  Es un conjunto de metadatos que contiene las características lógicas y puntuales de los datos que se van a utilizar en el sistema que se programa, incluyendo nombre, descripción, alias, contenido y organización.  Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la información, se desarrolla durante el análisis de flujo de datos y auxilia a los analistas que participan en la determinación de los requerimientos del sistema, su contenido también se emplea durante el diseño.
  34. 34. DATOS QUE ENCONTRAMOS EN UN DICCIONARIO.  Se encuentra la lista de todos los elementos que forman parte del flujo de datos de todo el sistema. Los elementos más importantes son flujos de datos, almacenes de datos y procesos. El diccionario de datos guarda los detalles y descripción de todos estos elementos.
  35. 35. DEFINICIONES DEL DICCIONARIO.  Una definición de un dato se introduce mediante el símbolo “=”; en este contexto  El “=” se lee como “está definido por”, o “está compuesto de”, o “significa”.  Para definir un dato completamente, la definición debe incluir:  El significado del dato en el contexto de la aplicación. Esto se documenta en forma de comentario.  La composición del dato, si es que está compuesto de otros elementos significativos.  Los valores que el dato puede tomar, si se trata de un dato elemental que ya no puede ser descompuesto.
  36. 36. DATOS ELEMENTALES DEL DICCIONARIO.  Son aquellos para los cuales no hay una descomposición significativa. Por ejemplo, puede ser que no se requiera descomponer el nombre de una persona en primer-nombre, apellido-materno y apellido-paterno; esto depende del contexto del sistema que se esté modelando.  Cuando se han identificado los datos elementales, deben ser introducidos en el DD y proveer una breve descripción que describa el significado del dato. En el caso de que el dato tenga un nombre significativo, se puede omitir la descripción, sin embargo; es importante especificar las unidades de medida que el dato puede tomar.
  37. 37. DATOS OPCIONALES.  Un dato opcional es aquel que puede o no estar presente como componente de un dato compuesto. Se caracteriza por estar encerrado entre paréntesis.
  38. 38. SELECCIÓN.  Indica que un elemento consiste de exactamente una opción de un conjunto de alternativas que se encierran entre corchetes.
  39. 39. ITERACCIÓN  Se usa para indicar ocurrencias repetidas de un componente en un elemento compuesto.  Ejemplo: Orden-de-compra = nombre- cliente + dirección-de-envío + {artículo} significa que una orden de compra siempre debe contener un nombre de cliente, una dirección de envío y cero o más ocurrencias de un artículo.
  40. 40. El DD define los elementos de datos.  DESCRIBIENDO. • EL SIGNIFICADO DE LOS FLUJOS Y LOS DEPÓSITOS. • LA COMPOSICIÓN DE PAQUETES AGREGADOS DE DATOS QUE SE MUEVEN POR LOS FLUJOS. • LA COMPOSICIÓN DE LOS PAQUETES DE DATOS DE LOS DEPOSITOS. ESPECIFICANDO LOS VALORES RELEVANTES Y UNIDADES DE INFORMACION DE LOS FLUJOS DE DATOS Y DEPÓSITOS DE DATOS.
  41. 41. LENGUAJE SQL.  LENGUAJE DE CONSULTA ESTRUCTURADO, PARA BASES DE DATOS RELACIONAES.  ES MUCHO MAS QUE UN LENGUAJE DE CONSULTA, PUESTO QUE PERMITE ADEMAS FUNCIONES DE DEFINICION Y CONTROL DE DATOS.  LA ESTANDARIZACION HA SIDO CRUCIAL PARA SU DIFUSION.  PRACTICAMENTE LA MAYORIA DE LOS SISTEMAS RELACIONALES SOPORTAN LAS BASES DE SQL ESTANDAR Y SUELEN INCLUIR APORTACIONES PROPIAS.
  42. 42. COMANDOS SQL.  SELECT.  ALTER TABLE.  DELETE FROM.  GROUP BY.  HAVING.  ORDER BY.
  43. 43. La sentencia SELECT  El formato de la sentencia select es:  SELECT [ALL | DISTINCT ] <nombre_campo> [{,<nombre_campo>}] FROM <nombre tabla>|<nombre vista> [{,<nombre tabla>|<nombre vista>}] [WHERE <condición> [{ AND|OR <condición>}]] [GROUP BY <nombre_campo> [{,<nombre_campo >}]] [HAVING <condición>[{ AND|OR <condición>}]] [ORDER BY <nombre_campo>|< indice_campo> [ASC | DESC] [{,<nombre_campo>|< indice_campo> [ASC | DESC ]}]]
  44. 44.
  45. 45. LA SENTENCIA ALTER TABLE. Sirve para modificar la estructura de una tabla que ya existe. Mediante esta instrucción podemos añadir columnas nuevas, eliminar columnas. Ten cuenta que cuando eliminamos una columna se pierden todos los datos almacenados en ella.
  46. 46. COMANDO DELETER FROM.  A veces podemos desear deshacernos de los registros de una tabla. Para ello, utilizamos el comando DELETE FROM. La sintaxis para esto es,  DELETE FROM "nombre tabla" WHERE {condición}  Por ejemplo, digamos que actualmente tenemos la siguiente tabla:  Tabla Store_Information. Txn_Date Store_Name Sales Los Angeles 1500 05-Jan-1999 San Diego 250 07-Jan-1999 Los Angeles 300 08-Jan-1999 Boston 700 08-Jan-1999
  47. 47. Y decidimos no mantener ninguna información sobre Los Ángeles en esta tabla. Para lograrlo, ingresamos el siguiente SQL  DELETE FROM Store_Information . WHERE Store Name = 'Los Angeles';  Ahora el contenido de la tabla se vería: Txn_Date Store_Name Sales San Diego 250 07-Jan-1999 Boston 700 08-Jan-1999 Tabla Store_Information
  48. 48. COMANDO GROUP BY.  Si usa una función de grupo en un comando sin la cláusula GROUP BY , es equivalente a agrupar todos los registros. Txn_DateStore_Name Sales Los Angeles 1500 05-Jan-1999 San Diego 250 07-Jan-1999 Los Angeles 300 08-Jan-1999 Boston 700 08-Jan-1999 Tabla Store_Information
  49. 49. Deseamos saber las ventas totales para cada negocio. Para hacerlo, ingresaríamos. Store_Name SUM(Sales) Los Angeles 1800 San Diego 250 Boston 700 SELECT Store_Name, SUM (Sales) FROM Store_Information GROUP BY Store_Name; Resultado:
  50. 50. COMANDO HAVING SQL.  La consulta SQL HAVING es utilizada junto con SELECT para especificar una condición de búsqueda para un grupo. HAVING se comporta como WHERE, pero se aplica a grupos (las filas o tuplas en el conjunto de resultados representan grupos). La cláusula WHERE se aplica a filas o tuplas individuales, NO a grupos.
  51. 51. EJEMPLO:  ejemplo de una tabla de ventas con la siguiente información: Venta, Precio, Nombre Y Cliente Los datos son los siguientes: 250 - Juan 190 - Patricio 500 - Ernesto 420 - Susana 1000 - María 1000 - Juan 2000 – Patricio.  Para obtener el cuadro anterior, obtuvimos la lista de todos los clientes junto con el monto respectivo de la venta usando la siguiente sentencia SQL:
  52. 52. SELECT NombreCliente, SUM (Venta Precio) FROM Ventas GROUP BY NombreCliente.  Ahora queremos seleccionar los clientes que han gastado más de 1200, para hacer esto utilizamos la HAVING así:  SELECT NombreCliente, SUM (VentaPrecio) FROM Ventas GROUP BY NombreCliente HAVING SUM(VentaPrecio) > 1200; El resultado será: Patricio 2190 Juan 1250
  53. 53. Comando ORDER BY SQL.  Si necesitamos enumerar el resultado en un orden particular. Esto podría ser en orden ascendente, en orden descendente, o podría basarse en valores numéricos o de texto. En tales casos, podemos utilizar la palabra clave ORDER BY para alcanzar nuestra meta.
  54. 54. La sintaxis para una instrucción ORDER BY es la siguiente:  SELECT "nombre_columna" FROM "nombre tabla" [WHERE "condición"] ORDER BY "nombre_columna" [ASC, DESC]  ORDER BY ASC significa que los resultados se mostrarán en orden ascendente, y DESC significa que los resultados se mostrarán en orden descendente. Si no se especifica ninguno, la configuración predeterminada es ASC.
  55. 55. la cláusula ORDER BY anterior se convierte en ORDER BY "nombre1_columna" [ASC, DESC], "nombre2_columna" [ASC, DESC]  EJEMPLO: podríamos desear enumerar los contenidos de la Tabla Store_Information según la suma en dólares, en orden descendente:  Tabla Store_Information.Store_Name Sales Txn_Date Los Angeles 1500 05-Jan-1999 San Diego 250 07-Jan-1999 San Francisco 300 08-Jan-1999 Boston 700 08-Jan-1999 Ingresamos, Ingresamos,
  56. 56. Ingresamos:  SELECT Store Name, Sales, Txn_Date FROM Store_Information ORDER BY Sales DESC.  Resultado: Txn_DateStore_Name Sales Los Angeles 1500 05-Jan-1999 Boston 700 08-Jan-1999 San Francisco 300 08-Jan-1999 San Diego 250 07-Jan-199
  57. 57. POR SU ATENCIÓN. MIL GRACIAS.

×