bases de datos unidad 3

UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO

FACULTAD DE CONTADURÍA Y ADMINISTRACIÓN

Licenciatura En Informática

Bases de Datos

Autor: L.I. María de Lourdes Isabel Ponce Vásquez

AGOSTO - DICIEMBRE 2008

Contenido

UNIDAD 3. MODELO RELACIONAL....................................................................................................................4 Objetivos Específicos ....................................................................................................................... 4 3.1. Introducción .............................................................................................................................. 4

3.1.1. Modelos Prerelacionales .................................................................................................... 5 3.1.1.1. Modelo Jerárquico........................................................................................................53.1.1.2. Modelo de Red.............................................................................................................6

3.1.2. Modelo Relacional .............................................................................................................. 7 3.1.3. Modelos Postrelacionales .................................................................................................. 8

3.1.1.3. Modelo Orientado a objetos.........................................................................................83.1.1.4. Modelo Objeto-Relacional............................................................................................93.1.1.5. Modelo de Datos Semiestructurados............................................................................93.1.1.6. Data warehouses y minería de datos...........................................................................9

3.2. Definición de Relación ............................................................................................................ 10 3.2.1. Partes ............................................................................................................................... 11

3.1.1.7. Grado y Cardinalidad..................................................................................................113.1.1.8. Llaves de la Relación.................................................................................................12

3.3. Propiedades de una Relación ................................................................................................. 12 3.4. Restricciones .......................................................................................................................... 13

3.4.1. Restricciones de Integridad .............................................................................................. 13 3.4.2. Restricciones de Usuario ................................................................................................. 13

3.1.1.9. En base a consecuencias de operaciones de Borrado y Modificación.......................133.1.1.10. En base a las relaciones entre atributos...................................................................143.1.1.11. En base a las relaciones entre elementos................................................................14

3.5. Lenguajes Relacionales de Manipulación de Datos ................................................................ 14 3.5.1. Álgebra Relacional ........................................................................................................... 15

3.1.1.12. Proyección................................................................................................................163.1.1.13. Selección..................................................................................................................163.1.1.14. Unión........................................................................................................................173.1.1.15. Intersección..............................................................................................................183.1.1.16. Diferencia.................................................................................................................183.1.1.17. División.....................................................................................................................193.1.1.18. Producto Cartesiano.................................................................................................193.1.1.19. Producto Theta (Reunión o Join)..............................................................................20

3.5.2. Cálculo Relacional ........................................................................................................... 21 3.1.1.20. Cálculo Relacional Orientado a Tuplas.....................................................................223.1.1.21. Cálculo Relacional Orientado a Dominios................................................................23

3.5.3. Lenguajes Orientados a la Transformación ...................................................................... 23 3.5.4. Consulta por Ejemplo (QBE – Query By Example) ........................................................... 24

3.6. Normalización ......................................................................................................................... 24 3.6.1. Anomalías de datos .......................................................................................................... 24 3.6.2. Tipos de Dependencias .................................................................................................... 25

3.1.1.22. Dependencia Funcional............................................................................................253.1.1.23. Dependencia Transitiva............................................................................................263.1.1.24. Dependencia Multivaluada.......................................................................................263.1.1.25. Dependencia de reunión..........................................................................................28

Unidad 2. Modelo Relacional Página 2

3.6.3. Formas Normales ............................................................................................................. 29 3.1.1.26. Primera Forma Normal.............................................................................................293.1.1.27. Segunda Forma Normal...........................................................................................303.1.1.28. Tercera Forma Normal.............................................................................................313.1.1.29. Forma Normal Boyce-Codd......................................................................................323.1.1.30. Cuarta Forma Normal ..............................................................................................333.1.1.31. Quinta Forma Normal ..............................................................................................34

3.6.4. Proceso de Descomposición sin Pérdida ......................................................................... 34 3.1.1.32. Preservación de atributos.........................................................................................353.1.1.33. Preservación de la dependencia..............................................................................353.1.1.34. Descomposición sin Pérdida....................................................................................35

3.7. Reglas de Codd ...................................................................................................................... 37 3.7.1. Regla Cero ....................................................................................................................... 37 3.7.2. Regla 1. Representación de la Información ...................................................................... 37 3.7.3. Regla 2. Acceso Garantizado ........................................................................................... 37 3.7.4. Regla 3. Información Faltante .......................................................................................... 37 3.7.5. Regla 4. Diccionario de Datos Dinámico basado en el modelo relacional ........................ 37 3.7.6. Regla 5. Lenguaje de datos Comprensible ....................................................................... 37 3.7.7. Regla 6. Actualización de Vistas ...................................................................................... 38 3.7.8. Regla 7. Operaciones de Conjuntos (Insert, Delete y Update) ......................................... 38 3.7.9. Regla 8. Independencia Física de los Datos .................................................................... 38 3.7.10. Regla 9. Independencia Lógica de los Datos ................................................................. 38 3.7.11. Regla 10. Independencia de Integridad .......................................................................... 38 3.7.12. Regla 11. Independencia de Distribución ....................................................................... 38 3.7.13. Regla 12. No Subversión ............................................................................................... 38

3.8. Estándar SQL ......................................................................................................................... 39 3.8.1. Antecedentes ................................................................................................................... 39 3.8.2. Versiones ......................................................................................................................... 40 3.8.3. Estructura de instrucciones .............................................................................................. 41

3.9. Transformación del Modelo E/R al Modelo Relacional ............................................................ 44


UNIDAD 3. MODELO RELACIONALUNIDAD 3. MODELO RELACIONAL

Objetivos Específicos

Conocer los modelos de datos anteriores y posteriores al modelo relacional Describir los elementos del modelo Conocer y aplicar las bases del modelo relacional mediante el uso del álgebra y cálculo

relacionales Identificar las anomalías de inserción, actualización y borrado Aplicar las formas normales al diseño de un modelo relacional Comprender los tipos de dependencias entre atributos. Describir las reglas de Codd para modelos relacionales

3.1. Introducción

El modelo relacional fue propuesto originalmente por E. F. Codd en 1970, en un documento llamado “Un Modelo Relacional de Datos para Grandes Bancos de Datos Compartidos”. Fue el primer modelo basado en nociones teóricas de matemáticas, las cuales proporcionaban una sólida base teórica. Las investigaciones de este modelo fueron hechas por Codd y otros en los Laboratorios de Investigación de IBM en San José, California. El primer prototipo de RDBMS fue el System R, desarrollado por investigadores de IBM finales de los 70s. El RDBMS de IBM actual DB2 está basado en el System R. SQL, es un lenguaje desarrollado para el System R que se convirtió en el lenguaje estándar para BD relacionales, con los estándares aprobados por ANSI y publicados en 1986, 1989, 1992 y 199. Otros proyectos de investigación sobre el modelo relacional fueron el Peterlee Relational Test Vehicle, desarrollado en los Laboratorios Científicos de IBM en Inglaterra e INGRES, desarrollado en la Universidad de California en Berkeley. Estas investigaciones obtuvieron una versión universitaria de INGRES y una versión comercial. ORACLE fue desarrollado y comercializado usando mucho de los resultados del System R. La aparición de las microcomputadoras en los 80s, logró desarrollos de RDBMSs para PC, entre ellos dBase, R:Base, Foxpro, Paradox y Access, que es el RDBMS más usado en microcomputadoras. Los RDBMS más populares a nivel empresarial son Oracle, DB2, Informix, SyBase y SQL Server, aunque empiezan a ganar terreno Postgres y My SQL.

El modelo relacional usa simples tablas para organizar los datos. En 1976, P.P. Chen desarrolló un nuevo tipo de modelo, el modelo entidad/relación. Este es un ejemplo de modelo semántico, ya que intenta capturar el significado de los datos que representa, a diferencia del modelo relacional que sólo indica cómo están organizados. El modelo entidad/relación ha sido extendido varias veces para hacerlo semánticamente más rico. También existen otros modelos semánticos.

El modelo relacional es un ejemplo de un modelo basado en registros. Los modelos basados en registros se usan para describir la BD externa, lógica y para algunos extiende sus niveles internos. Estos modelos permiten al diseñador desarrollar y especificar la estructura lógica y proporcionan algunas opciones para la implementación del diseño. Se implementan usando una variedad de DBMSs. Sin embargo, no proporcionan mucha información semántica como categorización de objetos, relaciones, abstracciones o restricciones de datos. Este modelo el actualmente muy usado debido a su simplicidad desde el punto de vista del usuario y por su poder.

El mismo tipo de teoría matemática que usa se completa con notación formal, definiciones, teoremas y prueba que las matemáticas pueden aplicarse a este modelo. El resultado de este desarrollo teórico es entonces aplicado a consideraciones prácticas de implementación. En el modelo


relacional, las entidades se representan como relaciones, las cuales son físicamente representadas como tablas o arreglos de dos dimensiones, y los atributos como columnas de estas tablas. Las interrelaciones pueden representarse como tablas, ya que este modelo ve las interrelaciones como un tipo especial de entidad. Los renglones en las tablas representan los datos almacenados.

3.1.1. Modelos Prerelacionales

Antes de que surgiera el modelo relacional, existieron otros modelos de datos que fueron desarrollados durante los años 60s, estos modelos son los de red y jerárquicos. Estos modelos también son modelos basados en registros y su interés es meramente histórico, ya que no se usan para nuevos desarrollos de BD, aunque aún existen algunas BD basadas en estos modelos.

3.1.1.1. Modelo Jerárquico

El modelo jerárquico de BD fue desarrollado como una solución a las necesidades inmediatas de de aplicaciones reales a mediados de los 60s. El sistema más antiguo e importante de BD jerárquico es IMS de IBM y fue desarrollado para organizar y

almacenar información necesaria para el proyecto de alunizaje del Apolo. IBM y la Aviación Norteamericana trabajaron juntos para producir la primera versión de IMS en

1968. Las versiones posteriores de IMS fueron diseñadas para usarse con dispositivos de cintas magnéticas, pero los posteriores discos magnéticos se convirtieron en el estándar. IMS rápidamente se convirtió en el DBS jerárquico dominante en el mercado y fue por muchos años el DBMS más ampliamente usado, hasta que fue remplazado por los sistemas relacionales. Muchas mejoras fueron hechas a IMS después del 68, resultando en nuevas versiones que obtenían ventajas de las mejoras en hardware y software, proporcionando nuevas características como comunicación de datos y máximo desempeño. IMS era capaz de procesar grandes cantidades de datos de modo eficiente. Usaba una estructura de árbol familiar para los programadores acostumbrados a trabajar con archivos.

La estructura lógica en la que se sustenta es el árbol, el cual se compone de un nodo raíz y varios nodos sucesores, ordenados jerárquicamente. Cada nodo representa una entidad (tipo de registro) y las relaciones entre entidades son las conexiones entre los nodos. El nodo superior es el nodo padre y los inferiores son los nodos hijos. Las conexiones entre archivos no dependen de la información contenida en ellos, se definen al inicio y son fijos (apuntadores). Las interrelaciones entre registros permiten que un padre tenga muchos hijos, pero un hijo sólo puede tener un padre.

Los datos se representan como estructuras de árbol y el árbol representa la jerarquía de registros de datos. La navegación es top-down.

Relaciones: 1 Padre, Múltiples Hijos (1 : M)


PADRE

HIJO HIJO/PADRE HIJO

HIJO HIJO

Por ejemplo, si se tiene dos entidades: cuentahabiente consiste de 3 atributos: nombre, calle y ciudad. La entidad cuenta tiene 2 campos: número y saldo, el modelo jerárquico se puede representar como:

LUIS AV. LEÓN LEÓN PEDRO AV. 2 D.F. JUAN HIDALGO HIDALGO

200 55 256 100000 347 667 347 667 301 10346

Desventajas:

No modela sencillamente las relaciones Muchos a Muchos. Genera anomalías de inserción. Genera anomalías de borrado. Genera anomalías de actualización. Se pueden dar consultas inconsistentes.

3.1.1.2. Modelo de Red

Uno de los DBMS más antiguos fue IDS (Integrated Data Store) que fue desarrollado en General Electric por Charles Bachean a principios de los 60s usando el modelo de red. Este DBMS tuvo gran influencia en el desarrollo de BD durante muchos años. Se formó CODASYL (Conference on Data Systems Languages – Conferencia sobre Lenguajes de Sistemas de Datos), una organización que representaba a la mayoría de los vendedores de

hardware y software y usuarios, para tratar de estandarizar muchos aspectos del procesamiento de datos. Tuvo éxito escribiendo estándares para el lenguaje COBOL. A finales de los 60s, formó un subgrupo llamado DBTG (Database Task Group – Grupo de Trabajo para BD) para definir estándares para DBMSs. Publicó un reporte en 1969 que generó muchas sugerencias y modificaciones por parte de los lectores. DBTG consideró las propuestas y publicó su primer reporte oficial en 1971. Este documento fue enviado a la ANSI (American National Standards Institute – Instituto Estadounidense de Estándares Nacionales) con la esperanza de que sus especificaciones se aceptaran como estándar para DBMSs, sin embargo, ANSI se lo rechazó. Al reporte de 1971 le siguieron varias versiones en 1973, 1978, 1978, 1981 y 1984, pero se mantuvo la documentación principal que describía un modelo basado en red generalmente referido como el modelo CODASYL o el modelo DBGT, y varios DBMS populares se basaron en él. Además de esto, proporcionó el vocabulario y un marco de trabajo para discusiones de temas de BD, estableciendo por primera vez la noción de capaz en la arquitectura de BD y terminología común. El DBTG evolucionó en 1972 en un comité permanente, el DDLC (Data Description Language Committee – Comité para el Lenguaje de Descripción de Datos), que continuó operando y publicando sus hallazgos periódicamente en su Journals of Development hasta 1984, cuando su función fue tomada por el comité ANSI X3H2 para la estandarización. A pesar de que el DBGT u DDLC continuaron haciendo cambios al modelo CODASYL, la propuesta de 1971 fue usada por la mayoría de los vendedores como la base de sus DBMS. El más usado de estos sistemas basados en red fue IDMS de Cullinet. Otros incluyendo PRIME DBMS de PRIME Computer, IDS II de Honeywell, DMS 170 de Control Data Corporation, DC, DMSII y DMS1100 de UNISYS, y DBMS 10 y DBMS 11 de Digital Equipment Corporation.

Los datos se representan como registros ligados formando un conjunto de datos intersectados. A diferencia de las jerárquicas, permiten cualquier conexión entre entidades, es decir, se pueden


representar relaciones de muchos a muchos. Un hijo puede tener varios padres y varios hijos a la vez. La conexión entre los registros también es mediante apuntadores.

La representación de los datos es similar al modelo jerárquico, con relaciones de un hijo a muchos padres y un padre a muchos hijos.

Relaciones: 1 Padre a Múltiples Hijos, 1 Hijo a Múltiples Padres (M:M)

Tomando nuevamente el ejemplo anterior, con dos entidades: cuentahabiente con: nombre, calle y ciudad., y cuenta con: número y saldo, el modelo de red se puede representar como:

200 55LUIS AV. LEÓN LEÓN

256 100000PEDRO AV. 2 D.F.

347 667JUAN HIDALGO HIDALGO

301 10346Desventajas:

Resulta difícil definir nuevas relaciones. Es complicado darle mantenimiento, ya que cualquier cambio en la estructura requiere una

descarga de los datos. Representa desperdicio de recursos. Genera anomalías de inserción. Genera anomalías de borrado.

Aunque los modelos jerárquico y de red eran poderosos y eficientes, eran complejos, requerían que los usuarios comprendieran las estructuras de datos y accedieran rutas de datos. Fueron diseñados para usar con programas y no para acceso interactivo de los usuarios, por lo que las consultas específicas no se soportaban. No se basaban en fundamentos teóricos sólidos, sino eran soluciones construidas encima sistemas de archivos existentes.

3.1.2. Modelo Relacional

La estructura lógica de una BD relacional está basada en la representación de entidades mediante tablas, las cuales constan de columnas (campos) y renglones (registros).


PADRE PADRE

PADRE/ HIJO

HIJO

PADRE/ HIJO PADRE/ HIJO

HIJO

Las relaciones entre tablas se realizan a través de un conjunto de columnas en común, logrando una conexión dinámica entre un número ilimitado de ellas mediante el contenido de esas columnas.

Su ventaja es poder modificar la información sin preocuparse por especificar las combinaciones entre registros. La representación de los datos es en forma de tablas con renglones y columnas. Las relaciones se modelan mediante columnas en común.

COLUMNA1 COLUMNA2RENGLÓN 1RENGLÓN 2RENGLÓN 3

Relaciones: 1:1, 1:M, M:M

Usando el ejemplo anterior, con dos entidades: cuentahabiente con: nombre, calle y ciudad., y cuenta con: número y saldo, donde un cuentahabiente puede tener muchas cuentas y una cuenta puede pertenecer a varios cuentahabientes, el modelo relacional se puede representar como:

CUENTAHABIENTE CUENTA/CUENTAHABIENTENOMBRE CALLE CIUDAD CUENTA CUENTAHABIENTELUIS LEON LEÓN 200 LUISPEDRO AV. 2 D.F. 256 PEDROJUAN HIDALGO HIDALGO 347 PEDRO

347 JUANCUENTA 301 JUANNO.CUENTA SALDO200 55256 100000247 667301 10346

3.1.3. Modelos Postrelacionales

La necesidad de almacenar y manipular datos complejos que no son fáciles de modelar usando las simples tablas del modelo relacional, así como el desarrollo de lenguajes de programación orientados a objetos, permitieron el desarrollo de otros modelos de datos.

3.1.1.3. Modelo Orientado a objetos

El modelo orientado a objetos fue desarrollado en los 90s para manejar los datos requeridos para aplicaciones avanzadas como sistemas de información geográfica (GIS), multimedia, diseño asistido por computadora y manufactura asistida por computadora (CAD/CAM), y otros ambientes complejos.

El modelo orientado a objetos es un modelo semántico similar al modelo entidad/relación. Éste extiende los conceptos del E/R agregando encapsulación, que implica incorporar tanto datos como funciones en una unidad donde son protegidos de modificaciones del exterior. A diferencia del E/R con entidades y atributos, este modelo usa objetos que tienen estado y comportamiento. El estado de un objeto se determina por los valores de sus atributos (variables de instancias). El comportamiento es el conjunto de métodos (funciones) definidas para el objeto. Para crear una BD orientada a objetos, El diseñador comienza definiendo clases, las cuales especifican los atributos y


métodos para un conjunto de objetos. Cada objeto es entonces creado instanciando la clase, usando uno de sus propios métodos llamados constructores. La estructura de los objetos puede ser muy compleja. Cada objeto en una BD debe tener un identificador único que funciona como una llave primaria permanente, pero que no toma valores de ninguno de los atributos del objeto. Las clases que se relacionan con otras se agrupan para formar jerarquías de clases. Una diferencia importante entre los objetos de programa y los objetos de la BD es la persistencia, ya que los objetos de programa existen sólo mientras el programa está en ejecución, mientras que un objeto de BD permanece en existencia después de que la ejecución del programa se completa.

3.1.1.4. Modelo Objeto-Relacional

Algunos RDBMSs como Oracle, agregaron algunas capacidades orientadas a objetos a sus productos, resultando en bases de datos híbrida objeto-relacionales.

El modelo objeto-relacional extiende al modelo relacional agregando algunos tipos de datos complejos y métodos. En vez de atomicidad y valores simples en los atributos que requiere el modelo relacional, este modelo permite atributos estructurados y tienen conjuntos de arreglos de valores. También permite métodos y herencia. El lenguaje SQL fue extendido en 1999 para crear y manipular los tipos de datos más complejos que soporta este modelo. Sin embargo, el lenguaje usado para manejar BD objeto-relacionales es más cercano al tipo de lenguaje para BD relacionales que el que se usa para BD estrictamente orientadas a objetos.

3.1.1.5. Modelo de Datos Semiestructurados

El amplio uso de Internet ha tenido gran impacto en el desarrollo de BD. Internet conecta a los usuarios a una amplia red de BDs en constante expansión, proporcionando acceso a bibliotecas digitales, recursos multimedia, recursos educativos y mucho más. Los sitios de comercio electrónico permiten acceso a BDs de información sobre productos y servicios a los clientes a través de mundo. Los dispositivos de cómputo inalámbrico y los clientes pequeños como PDAs son otros desarrollos que permiten a los usuarios conectarse a recursos de BDs en formas nuevas y flexibles.

La mayoría de los modelos requiere que los tipos de entidades (u objetos o registros, dependiendo del modelo) tengan la misma estructura. La estructura se define en el esquema y permanece sin modificaciones a menos que el DBA cambie el esquema. En contraste, el modelo semi-estructurado permite una colección de nodos, cada uno conteniendo datos, posiblemente con diferentes esquemas. El nodo contiene información sobre la estructura de su contenido. Las BD semi-estructuradas son especialmente útiles cuando existen BD que tienen diferentes esquemas integrados. Las BD individuales pueden verse como documentos y pueden agregarse etiquetas XML (Extensible Markup Language) a cada documento para describir su contenido. XML es un lenguaje similar a HTML (Hipertext Markup Language), pero es usado como un estándar para intercambio de datos en vez de presentación de datos. Las etiquetas XML se usan para identificar elementos, sub-elementos y atributos que almacenan datos. El esquema puede especificarse usando DTD (Document Type Definition) o por un esquema XML que identifica los elementos, sus atributos y sus relaciones con otros.

3.1.1.6. Data warehouses y minería de datos

Los data warehouses se desarrollaron en los 90s para proporcionar un método de captura de datos consolidando de muchas bases de datos. Un data warehouse generalmente almacena datos


históricos de una organización, con el propósito de hacer minería de datos, que es un proceso de análisis de datos estadísticos para permitir a las organizaciones analizar sus propios registros.

3.2. Definición de Relación

La estructura básica del modelo relacional es simple y fácil de entender a nivel intuitivo. Permite separar los niveles conceptual y físico, de modo que el diseño conceptual puede ser desarrollado sin considerar las estructuras de almacenamiento. Usuarios y diseñadores encuentran que el modelo permite expresar nociones conceptuales de los datos de un modo fácil de entender. Las operaciones de los datos también son fáciles de expresar y no requieren que el usuario se familiarice con las estructuras de almacenamiento usadas. El modelo usa unos cuantos comandos muy poderosos que permiten manipular los datos de forma simple o compleja. Por estas razones, el modelo relacional se ha convertido en el modelo de datos más popular.

El modelo relacional se basa en el concepto de relación, que se representa físicamente como una tabla o un arreglo de dos dimensiones (matriz). En este modelo, las tablas se usan para contener la información de los objetos a representarse en la BD. Tanto entidades como interrelaciones se representan usando tablas.

El modelo relacional se basa en la noción matemática de relación. Codd y otros investigadores extendieron la noción para aplicarla al diseño de BD. De este modo, es posible sacar ventaja del poder de abstracción matemático y la expresividad de la notación matemática para desarrollar una estructura de BD simple pero poderosa.

Para comprender el significado estricto de relación, se requieren algunas nociones matemáticas. Suponiendo dos conjunto D1 y D2, con D1 = {1,3} y D2 = {a,b,c}. Se puede obtener el producto Cartesiano de estos dos conjuntos, escrito D1 x D2, que es el conjunto de todos los pares ordenados donde el primer elemento es un miembro de D1 y el segundo elemento es un miembro de D2. Otra forma de verlo es como una combinación de elementos donde el primero corresponde a D1 y el segundo a D2. Por lo tanto:

D1 x D2 = { {1, a}, {1, b}, {1, c}, {3, a}, {3, b}, {3, c} }

Una relación es simplemente un subconjunto de este producto Cartesiano. Por ejemplo:

R = { {1, a}, {3, a} }

es una relación. Generalmente se especifica que pares ordenados corresponden a la relación indicando alguna regla para la selección. Por ejemplo, R incluye todos los pares ordenados en los que el segundo elemento es a, esto se puede expresar:

R = { (x, y) | x ∈ D1 y y ∈ D2, y y = a}

Usando el mismo conjunto, se puede crear otra relación, S, En la que el primer elemento es siempre 3:

S = { (x, y) | x ∈ D1 y y ∈ D2, y x = 3} ∴ S = { {3, a}, {3, b}, {3, c} }

La noción de relación se puede extender a tres conjuntos de forma natural, incluso se puede ir más allá u definir una relación general en el dominio n. Suponiendo que D1, D2, . . ., Dn son n conjuntos. Su producto Cartesiano se define como:


D1 x D2 x . . . x Dn = { (d1, d2, . . ., dn) | d1 ∈ D1, d2 ∈ D2, . . . , dn ∈ Dn}

El producto Cartesiano generalmente se expresa como:∏n

i=1 D1

Una relación en los n conjuntos es cualquiera n-tuplas elegidas de este producto Cartesiano. Nótese que en la definición de las relaciones se ha especificado el dominio o conjunto desde el cual se eligen los valores.

Aplicando estos conceptos a BD, suponiendo que A1, A2, . . ., An son atributos con los dominios D1, D2, . . ., Dn. El esquema relacional R es un conjunto de atributos con su correspondientes dominios; o sea, el conjunto {A1, A2, . . ., An} con sus correspondientes dominios {D1, D2, . . ., Dn} es un esquema relacional. Una relación r en un esquema relacional R es un conjunto de los nombres de atributos con sus correspondientes dominios, o sea que la relación r es un conjunto de n-tuplas (A1:d1, A2:d2, …, An:dn) tales que d1 ∈ D1, d2 ∈ D2, …, dn ∈ Dn. Cada elemento en una de estas n-tuplas consiste de un atributo y un valor de ese atributo. Normalmente, cuando se escribe una relación como una tabla, se listan los nombres de los atributos como encabezados de columnas y las tuplas usando valores del dominio apropiado, por lo que las tuplas tienen la forma (d1, d2, . . ., dn). De esta forma, una relación en el modelo relacional es cualquier subconjunto del producto Cartesiano de los dominios de los atributos. Una tabla es simplemente una representación de esa relación.

3.2.1. Partes

Una relación se representa como una tabla bidimensional en la que los renglones corresponden a registros individuales, llamados tuplas (o tuples) y las columnas corresponden a los atributos.

El dominio de un atributo es el conjunto permitido de valores para ese atributo y pueden ser distintos o dos o más atributos pueden tener el mismo dominio.

La tabla, con todos sus renglones descritos, es una instancia o extensión de la relación. La estructura de la tabla, junto con una especificación del dominio y otras restricciones sobre los posibles valores, muestran la intensión de la relación, también llamada esquema de la BD. Estrictamente hablando, el esquema también incluye dominios, vistas, conjuntos de caracteres, restricciones, procedimientos almacenados, disparadores, autorizaciones y otra información relacionada. El esquema de la relación se puede representar usando el nombre de cada relación, seguido de los nombres de atributos entre paréntesis:

Cliente (idCliente, nombre, domicilio, límiteCredito)

El atributo idCliente está subrayado porque se acostumbra subrayar la llave primaria en el esquema de la relación.

3.1.1.7. Grado y Cardinalidad

El número de columnas en una tabla es llamado grado de la relación. Esto significa que cada renglón de la tabla debe contener tantos valores como indique el grado. Una relación que tiene sólo una columna tiene grado uno y se llama relación unaria. Una relación con dos columnas es binaria, una de tres ternaria, y después de eso generalmente se usa el término n-aria. El grado de la relación es parte de la intensión de la relación y nunca cambia.


En contraste, el número de renglones en una tabla, se llama cardinalidad de la relación, cambia cuando se agregan nuevas tuplas o se borrar. La cardinalidad es una propiedad de la extensión de la extensión de la relación, la instancia particular de la relación en un momento dado.

3.1.1.8. Llaves de la Relación

Ya que una relación es un conjunto y un conjunto no duplica elementos, siempre es posible hablar por separado de los elementos. En una relación de BD, las tuplas son conjuntos de elementos, así que siempre debe ser posible separar cada tupla. Esto significa que siempre debe haber un atributo, o alguna combinación de atributos, que distingue a las tuplas. Una llave es el conjunto mínimo de atributos que identifica unívocamente cada tupla en una relación. Una llave formada por más de un atributo es llamada llave compuesta. En una relación siempre habrá una llave primaria, que es la llave candidata elegida como llave de la relación, y esto implica que siempre habrá una llave candidata, una llave candidata es cualquier conjunto de atributos que puede ser elegido como una clave en una relación. Las llaves no elegidas como llave primaria son llaves alternas. En el peor de los casos, todos los atributos se requerirán para identificar a cada tupla, sin embargo, generalmente, sólo se requiere un pequeño conjunto de atributos para distinguir entre tuplas. Hay que notar que una instancia de la tabla no puede usarse para probar que un atributo o combinación de atributos es una llave candidata, el hecho de que no existan duplicados par los valores que aparecen en un momento dado no garantizan que los duplicados no son posibles. Sin embargo, la presencia de duplicados en una instancia puede comprobar que alguna combinación de atributos no es una llave candidata. La identificación de llaves candidatas requiere que se considere el significado de los atributos involucrados de modo que se pueda tomar una decisión acerca de los valores que pueden duplicarse en el minimundo. Sólo al usar la información semántica e identificando las suposiciones para el modelo se puede asegurar que una combinación de atributos es una llave candidata.

Una llave foránea (ajena o externa) es un atributo o combinación de atributos de una relación que no es la llave primaria de la relación pero que es llave primaria en alguna relación, generalmente diferente. Las llaves foráneas son muy importantes en el modelo relacional porque se usan para representar la conexión lógica entre relaciones; si la llave hace referencia a su propia relación se dice que es una llave foránea recursiva.

3.3. Propiedades de una Relación

Una tabla que representa una relación tiene las siguientes características:

Cada celda de la tabla contiene sólo un valor. Cada columna tiene distinto nombre, que es el nombre de los atributos representados. Los valores en una columna tienen el mismo dominio, ya que todos los valores corresponden

a valores del atributo. Cada tupla es distinta, no existen tuplas duplicadas. El orden de las tuplas no es importante.

La mayoría de las características especificadas para las tablas resultan de las propiedades de las relaciones. Ya que una relación es un conjunto, el orden de los elementos no cuenta, por lo tanto, en una tabla el orden de los renglones no es importante. En un conjunto, los elementos no se repiten, similarmente, en una tabla, no existen renglones duplicados. Cuando se obtiene el producto Cartesiano de valores simples, por ejemplo, enteros, cada elemento en cada tupla es un valor simple, similarmente, cada celda de una tabla contiene sólo un valor. En una relación, el valor posible para una posición dada está determinado por el conjunto o dominio en el cual se define la posición,


en una tabla, los valores en cada columna deben corresponder con el dominio del atributo. En una relación matemática, el orden de los elementos en una tupla es importante, por ejemplo, es par ordenado (1, 2) es diferente que el par ordenado (2, 1), como se pude ver al localizar un punto en un plano usando coordenadas Cartesianas. Sin embargo, en las tablas, el orden de las columnas no es importante, la razón es que el encabezado de las columnas indica a que atributo pertenece el valor, sin embargo, una vez que la estructura de la tabla se elige, el orden de los elementos con los renglones de la extensión debe corresponder al orden de los nombres de las columnas.

3.4. Restricciones

Una restricción (constraint) es una regla que limita los valores en la BD. Un estado legal de la BD es aquel que obedece a todas las restricciones. Parte del trabajo de un DBMS es obligar a cumplir esas restricciones, para asegurar que cualquier dato ingresado genere una instancia legal de la BD. Existen diversos tipos de restricciones:

3.4.1. Restricciones de Integridad

Es importante preservar la integridad, esto significa que los datos son correctos e internamente consistentes en la BD, esto se logra evitando que los usuarios ingresen datos incorrectos. El modelo relacional permite definir restricciones de integridad, que son reglas o restricciones que aplican a todas las instancias de la BD y son definidas por el modelo relacional.

Una restricción de llave primaria, llamada integridad en la entidad, define que en una relación ningún atributo de la llave primaria puede ser valor nulo. Un valor nulo es el valor dado a un atributo en una tupla si el atributo es inaplicable o su valor desconocido. Los valores nulos no son lo mismo que el valor cero ó el carácter de espacio en blanco.

Por definición, una llave primaria es el identificador mínimo que se usa para identificar de manera única a las tuplas, esto implica que ningún subconjunto de la llave primaria es suficiente para proporcionar identificación única de tuplas. Si se permiten valores nulos para una parte de la llave primaria, se estaría demostrando que no se requieren todos los atributos para distinguir entre tuplas, lo cual contradice la definición. Todas las llaves de la relación, tanto primarias como candidatas, deben tener valores únicos. En SQL, se puede identificar la llave primaria usando una restricción de llave primaria cuando se crea la tabla. El sistema forzará entonces las restricciones de no valores nulos y llaves únicas automáticamente. Para las llaves candidatas, la mayoría de los sistemas permiten especificar restricciones de valores únicos y no nulos.

La regla de integridad llamada integridad referencial aplica a llaves foráneas. La integridad referencial indica que, si existe una llave foránea, entonces su valor de llave foránea debe corresponder al valor de alguna tupla en la llave primaria en la relación a la que pertenece, o el valor de la llave foránea debe ser totalmente nulo. SQL permite especificar restricciones de llave foránea cuando se crea una tabla.

3.4.2. Restricciones de Usuario

3.1.1.9. En base a consecuencias de operaciones de Borrado y Modificación.


Operación Restringida (RESTRICT). El borrado o modificación de las tuplas de la relación que contiene la clave primaria referenciada sólo se permite si no existen tuplas con dicha clave en la relación que contiene la clave externa.

Operación con transmisión en cascada (CASCADE). El borrado o modificación de las tuplas de la relación que contiene la clave primaria referenciada lleva consigo el borrado o modificación en cascada de las tuplas en la relación que contiene la clave externa

Operación con puesta a nulos (SET NULL). El borrado o modificación de las tuplas de la relación que contiene la clave primaria referenciada lleva consigo poner a nulos los valores de las claves externas de las tuplas en la relación que contiene la clave externa.

Operación con puesta a valor por omisión (SET DEFAULT). El borrado o modificación de las tuplas de la relación que contiene la clave primaria referenciada lleva consigo poner el valor por omisión a las claves externas de las tuplas en la relación que contiene la clave externa.

Operación que desencadena un procedimiento del usuario. El borrado o modificación de las tuplas de la relación que contiene la clave primaria referenciada pone en marcha o ejecuta un procedimiento definido por el usuario (Trigger).

3.1.1.10. En base a las relaciones entre atributos

Restricción de intrarelación sobre atributos. El valor válido de un atributo en una tupla depende de los valores de otros atributos de la misma tupla dentro de la relación.

Restricción de intrarelación sobre tuplas. El valor válido de un atributo en una tupla depende de los valores de otros atributos en otras tuplas dentro de la relación

3.1.1.11. En base a las relaciones entre elementos

Restricción de interrelación. El valor válido de un atributo depende de los valores de otros atributos contenidos dentro otra relación.

Restricción sobre dominios. El valor válido de un atributo depende de un conjunto de dominios. Ya que cada atributo tiene un dominio asociado, existen restricciones el conjunto de valores que se permiten para los atributos de las relaciones. Esto es llamado restricciones de dominio y pueden forzarse en SQL definiendo el dominio para cada atributo cuando se crea una tabla. Una alternativa es usar tipos de datos predefinidos y agregar una restricción llamada opción check, que permite especificar que el valor de un atributo debe corresponder al conjunto de valores especificado, o que debe obedecer una condición que se especifica usando lógica de predicados.

Existen otros tipos de restricciones, referidas como restricciones generales, las cuales pueden ser restricciones de tablas, que definen reglas sobre los valores permitidos en una tabla, o aserciones que especifican un predicado dado debe ser cierto para todos los estados de la BD. Las restricciones generales se fuerzan por el DBMS cuando se hacen cambios a la BD. El sistema verifica que los cambios no violen las restricciones antes de permitir que se realicen permanentemente.

3.5. Lenguajes Relacionales de Manipulación de Datos


Existe gran variedad de lenguajes usados para RDBMs. Algunos son procedurales, donde el usuario indica exactamente cómo manipular los datos. El álgebra relacional es un ejemplo de lenguaje procedural. Otros son no procedurales o declarativos, que permiten que el usuario indique qué datos necesita pero no exactamente cómo localizarlos. El cálculo relacional y SQL son lenguajes no procedurales. Algunos lenguajes son gráficos, y permiten que el usuario de un ejemplo o ilustración de los datos a encontrar. QBE (Quero By Example) es un lenguaje gráfico que permite proporcionar ejemplos de datos que se desean extraer. Otra categoría es lenguajes de cuarta generación (4GL), que permiten crear una aplicación completa usando unos cuantos comandos en un ambiente amigable, generalmente manejado con menús. Algunos sistemas aceptan una variedad de lenguaje natural, algunas veces llamado lenguaje de quinta generación, que es una versión restringida del inglés.

Tanto el álgebra relacional como el cálculo relacional son lenguajes formales, no amigables al usuario. No se implementan en su forma nativa en los DBMSs, pero se usan como base para otros lenguajes de manipulación de datos de BD relacionales de alto nivel. Estos lenguajes son interesantes porque ilustran la operación básica requerida de cualquier lenguaje de manipulación de datos, y porque sirven como estándar de comparación de otros lenguajes relacionales.

Al diseñar una BD se realiza una abstracción general. Para crear aplicaciones se necesitan lenguajes claros y precisos para expresar la lógica del proceso. Existen cuatro estrategias para manipulación de datos:

Algebra Relacional Cálculo Relacional Lenguajes Orientados a la Transformación Consulta por Ejemplo (QBE)

3.5.1. Álgebra Relacional

El álgebra relacional es un lenguaje teórico con operadores que se aplican sobre una o dos relaciones para producir otra relación, de modo que los operandos y el resultado son tablas. Date originalmente propuso ocho operaciones, pero se han desarrollado otros. Las operaciones más básicas, Selección, Proyección y Reunión (Join), permiten desarrollar la mayoría de las operaciones de extracción de datos importantes. Existen diversas variantes de las sintaxis de los comandos de álgebra relacional.

El Álgebra Relacional define operadores que aplican sobre tablas, creando una nueva tabla, donde se requiere saber qué se desea y cómo.

El Álgebra Relacional tiene cinco operaciones fundamentales con las cuales se puede realizar cualquier consulta:

Proyección Selección Unión Diferencia Producto Cartesiano

Además de las operaciones básicas se pueden realizar tres operaciones adicionales:

Intersección Producto Theta (Join)


División

3.1.1.12. Proyección

El operador Proyección tiene como entrada una relación y produce como resultado un subconjunto vertical de la relación con sólo aquellos atributos especificados por el usuario, eliminando duplicados.

El orden en el cual aparecen los atributos, es el que se indica cuando se hace la proyección. El número de atributos que se pueden proyectar es como máximo el mismo número de atributos de la relación origen y como mínimo un solo atributo.

Sintaxis: ∏ A1 ,..., An (r)

Donde A1 ,..., An es la lista de atributos y "r" la relación sobre la que se actúa.

EmpleadoNúmero de Empleado

Nombre del Empleado

Salario Código Depto.

1 Pedro 12,000 VE2 Luís NO3 Francisco 36,0004 Lorena 24,0005 Gabriela 24,000 NO

La Proyección de los atributos Nombre y Número de empleado, es:

∏ Nombre del Empleado, Número de empleado (Empleado)

RESULTADONombre del Empleado

Número de Empleado

1 Pedro2 Luís3 Francisco4 Lorena5 Gabriela

3.1.1.13. Selección

El operador Selección acepta una sola relación como entrada y produce como resultado un subconjunto horizontal de todos los atributos de la relación origen y las tuplas que sean especificadas por el usuario en el predicado. El predicado admite varios grados de complejidad y puede incluir operadores lógicos (AND, OR y NOT). Para indicar precedencia de operadores se usan paréntesis.

Las comparaciones pueden realizarse con valores literales, valores contenidos en los atributos, o expresiones matemáticas que involucren valores literales de los atributos.

Sintaxis: σ P (r)


Donde r es la relación sobre la que se actúa y P es el predicado que debe cumplirse

EmpleadoNúmero de Empleado

Nombre del Empleado


1 Pedro 12,000 VE2 Luís NO3 Francisco 36,0004 Lorena 24,0005 Gabriela 24,000 NO

La Selección de todos los empleados del departamento de nómina, es:

σ Cod.Depto=‘NO’ (Empleado)

RESULTADONúmero de Empleado

Nombre del Empleado


2 Luís NO5 Gabriela 24,000 NO

Los operadores que pueden usarse para el predicado son los lógicos y relacionales:

<, >, >=, <=, =, ≠, ∧ (and), ∨ (or), ¬ (not)

3.1.1.14. Unión

Ya que las relaciones son básicamente conjuntos de n tuplas, el álgebra relacional incluye una versión de los operadores de conjuntos, unión, intersección y diferencia.

El operador Unión acepta como entrada dos relaciones con el mismo grado, los mismos atributos (los dominios de los i-ésimos atributos deben coincidir) en el mismo orden y produce como resultado todos los atributos y todas las tuplas de ambas relaciones.

Si existe alguna tupla con la misma información en ambas relaciones, esta tupla sólo aparece una vez en el resultado.

Sintaxis: r1 U r2

Donde r1 y r2 son las relaciones sobre las que se actúa.

Empleados Antiguos Empleados NuevosNúmero de Empleado

Nombre del Empleado

Salario Número de Empleado

Nombre del Empleado

Salario

1 Pedro 12,000 3 Francisco 36,0002 Luís 4 Lorena 24,0003 Francisco 36,000 5 Gabriela 24,000

La UNIÓN de las relaciones anteriores, es:

Empleados Antiguos U Empleados Nuevos



Nombre del Empleado

Salario

1 Pedro 12,0002 Luís3 Francisco 36,0004 Lorena 24,0005 Gabriela 24,000

3.1.1.15. Intersección

El operador Intersección acepta como entrada dos relaciones y obtiene como resultado la todas las tuplas que tengan exactamente la misma información en todos los atributos.

Sintaxis: (r1 ∩ r2) ó r1 - (r1 - r2)

Donde r1 y r2 son las relaciones sobre las que se actúa

Empleados Antiguos Empleados NuevosNúmero de Empleado

Nombre del Empleado

Salario Número de Empleado

Nombre del Empleado

Salario

1 Pedro 12,000 3 Francisco 36,0002 Luís 4 Lorena 24,0003 Francisco 36,000 5 Gabriela 24,000

La INTERSECCIÓN de las relaciones anteriores, es:

Empleados Antiguos ∩ Empleados Nuevos


Nombre del Empleado

Salario

3 Francisco 36,000

3.1.1.16. Diferencia

El operador Diferencia acepta como entrada dos relaciones que tengan al menos un atributo en común, en donde el resultado tendrá todos los atributos de la primera relación y las tuplas que no aparezcan en la segunda relación.

Sintaxis: (r1 - r2)

Donde r1 y r2 son las relaciones sobre las que se actúaDepartamento Empleado

Cod. Depto.

Nombre del Depto.

Número de Empleado

Nombre del Empleado

Salario Cod. Depto.

VE Ventas 1 Pedro 12,000 VENO Nómina 2 Luís NOIN Investigación 3 Francisco 36,000ME Mercadotecnia 4 Lorena 24,000


RE Resultados 5 Gabriela 24,000 NO

La DIFERENCIA de las relaciones anteriores, es:

(Departamento – Empleado)

RESULTADOCod.

Depto.Nombre del

Depto.IN InvestigaciónME MercadotecniaRE Resultados

3.1.1.17. División

La División es una operación binaria donde la estructura completa de una relación (el divisor) es una porción de la estructura de la otra (el dividendo). El resultado es el conjunto de valores en los atributos que aparecen sólo en el dividendo coinciden con todas las tuplas del divisor.

Sintaxis: (r1 ÷ r2)


Departamentos CiudadesCod.

Depto.Nombre del

Depto.Cód.

CiudadNombreCiudad

Cód.Ciudad

NombreCiudad

VE Ventas DF D.F. DF D.F.VE Ventas GD Guadalajara GD GuadalajaraNO Nómina DF D.F.NO Nómina GD GuadalajaraIN Investigación DF D.F

La DIVISIÓN de las relaciones anteriores, es:

(Departamentos ÷ Ciudades)

RESULTADOCod.

Depto.Nombre del

Depto.IN Investigación

3.1.1.18. Producto Cartesiano

El operador Producto Cartesiano acepta como entrada dos relaciones y obtiene como resultado la combinación de cada tupla de la primera relación con todas las de la segunda relación. Las columnas resultantes son las columnas de r1 seguidas de las columnas de r2.

Si el número de tuplas de r1 es n1 y el de r2 es n2, el resultado será n1 x n2

Sintaxis: (r1 X r2)



Departamento EmpleadoCod.

Depto.Nombre del

Depto.Número de Empleado

Nombre del Empleado

Salario Cod. Depto.

VE Ventas 1 Pedro 12,000 VENO Nómina 2 Luís NOIN Investigación 3 Francisco 36,000ME Mercadotecnia 4 Lorena 24,000RE Resultados 5 Gabriela 24,000 NO

El PRODUCTO CARTESIANO de las relaciones anteriores, es:

(Departamento X Empleado)

RESULTADOCod.

Depto.Nombre del


Nombre de Empleado

Salario Cod. Depto.

VE Ventas 1 Pedro 12,000 VEVE Ventas 2 Luís NOVE Ventas 3 Francisco 36,000VE Ventas 4 Lorena 24,000VE Ventas 5 Gabriela 24,000 NONO Nómina 1 Pedro 12,000 VENO Nómina 2 Luís NONO Nómina 3 Francisco 36,000… …RE Resultados 5 Gabriela 24,000 NO

3.1.1.19. Producto Theta (Reunión o Join)

Existen diversas operaciones que se pueden definir basadas en el producto cartesiano de relaciones, la más general es la operación producto theta ó join. El operador Join acepta como entrada dos o mas relaciones teniendo cada una al menos un atributo en común con las otras relaciones, y produce como resultado a todos los atributos de las relaciones origen, y las tuplas se concatenan con aquellas tuplas cuyos valores en las relaciones origen cumplen con la condición que se indica para hacer la reunión. El resultado de esta operación se define ejecutando una operación de selección sobre el producto.

Cuando el predicado es de igualdad sobre las columnas en común, se dice que es un Equijoin de tablas. Un Join Natural es un equijoin en el que las columnas repetidas se eliminan y es el join más común por lo que generalmente sólo se le dice join. Otra variación es el Semijoin, que puede ser izquierdo o derecho y donde los resultados corresponderán a las tuplas de la relación izquierda o derecha que participan en el join. Otro tipo es el Join Externo, donde las tuplas de las tablas originales que no tienen coincidencias no se muestran en el resultado. Existen también dos variaciones del Join Externo, el Join Externo Izquierdo y Join Externo Derecho, en los que sólo se muestran las tuplas sin coincidencia de la tabla izquierda o derecha.

Las columnas en común sólo se muestran una vez.

Sintaxis: (r1 θP r2) ó σP (r1 x r2)


Donde r1 y r2 son las relaciones sobre las que se actúa y P representa el predicado de la selección.

Departamento EmpleadoCod.

Depto.Nombre del


Nombre del Empleado

Salario Cod. Depto.

VE Ventas 1 Pedro 12,000 VENO Nómina 2 Luís NOIN Investigación 3 Francisco 36,000ME Mercadotecnia 4 Lorena 24,000RE Resultados 5 Gabriela 24,000 NO

El JOIN con la columna en común del código del departamento en las relaciones anteriores, es:

(Departamento θ Departamento.codDepto= Empleado.codDepto Empleado)RESULTADO

Cod. Depto.

Nombre del Depto.

Número de Empleado

Nombre de Empleado

Salario

VE Ventas 1 Pedro 12,000NO Nómina 2 LuísNO Nómina 5 Gabriela 24,000

Existen muchas extensiones del álgebra relacional, se han agregado métodos para manejar valores nulos de modo sistemático y varios investigadores han agregado funciones como SUM, AVG, MAX, MIN y COUNT.

3.5.2. Cálculo Relacional

El Cálculo Relacional es un lenguaje de manipulación de datos formal y no procedural o declarativo en el cual el usuario simplemente especifica qué datos deben extraerse. El cálculo relacional no está relacionado a la familia de cálculo diferencial e integral en matemáticas, pero usa una rama de la lógica simbólica llamada cálculo de predicado. Cuando se aplica a las BD, puede ser en dos formas: cálculo relacional orientado a tuplas y cálculo relacional orientado a dominios. Ambos usan conceptos de lógica simbólica.

En lógica, un predicado es una sentencia declarativa que puede ser falsa o verdadera. Por ejemplo, “Juan es un cliente”. Si un predicado contiene una variable, por ejemplo “X es un cliente”, debe existir un conjunto o rango asociado para remplazar a X. Cuando algunos valores del rango se substituyen para x, el predicado puede ser verdadero o falso.

Si se usa P para referirse a un predicado, entonces { x | P (x) } indica el conjunto de todos los valores x de modo que P sea verdadero. Los predicados se pueden conectar con conectivos lógicos ∧ (and), ∨ (or) y ¬ (not) para formar predicados compuestos:

P(x) ∧ Q(x) P(x) ∨ Q(x) P(x) ¬ Q(x)

Donde P y Q son predicados.

Una conjunción consiste de predicados conectados por AND, una disyunción consiste de predicados conectados por OR y una negación es un predicado precedido por un NOT.


En lógica existen dos cuantificadores usados con los predicados para indicar cuántas instancias aplican al predicado. El cuantificador existencial, EXISTS, indica “Existe”. Es usado en aserciones, o declaraciones que deben ser verdaderas para al menos una instancia, su símbolo es ∃, como:

∃ x (P (x))

El cuantificador universal, FORALL, indica “Para todos”, su símbolo es ∀. Se usa en aserciones para cada instancia, como:

∀ s (P (s))

que indica que P(s) es verdadero para todos los valores s, en el rango. Una variable sin un calificador (∃ o ∀) es llamada variable libre, y una con un calificador es llamada una variable limitada.

3.1.1.20. Cálculo Relacional Orientado a Tuplas

En este lenguaje, expresamos variables que representan tuplas. Si por ejemplo existe una tupla t contenida en una relación r escribiremos t ∈ r. Si queremos expresar el valor que toma el atributo A para la tupla t, lo haremos de la siguiente forma: t[A].

Como dijimos, el cálculo relacional es declarativo (no tiene procedimientos), por tanto cuando deseamos obtener un conjunto de tuplas (una relación) a partir de otras tenemos que expresarlo usando los medios que el cálculo relacional nos ofrece, si por ejemplo, queremos obtener una relación con el conjunto de tuplas que cumplen el predicado P, tendremos que expresarlo de esta manera: {t | P(t)}. Por ejemplo: "Queremos tener una lista completa de todos aquellos clientes que tienen un préstamo cuyo importe sea más de un millón" (selección).

{t | t ∈ Préstamo ∧ t[importe] > 1,000,000}

El cuantificador ∃ sirve para realizar proyecciones. "Queremos saber los nombres de los clientes que poseen un préstamo de más de un millón".

{t | ∃ s ∈ préstamo ∧ s[importe] > 1.000.000 ∧ t[nombre_cliente] = s[nombre_cliente] }

Con la anterior operación definimos una nueva relación que consta de un sólo atributo (nombre_cliente).

Hasta ahora hemos usado el conectivo ∧, pero también podremos usar ∨ y ¬. Con estos conectivos podemos realizar la unión, diferencia e intersección de conjuntos. "Queremos obtener una relación con los nombres de los clientes que o bien tienen una cuenta, o bien un préstamo, o ambas cosas en la sucursal 10" (unión).

{ t | ∃ s (s ∈ préstamo ∧ t[nombre_cliente] = s[nombre_cliente] ∧ s[nombre_sucursal] = "10" ) ∨ ∃ u (u ∈ deposito ∧ t[nombre_cliente] = u[nombre_cliente] ∧ u[nombre_sucursal] = "10") }

El conectivo ∨ actúa aquí como unión, haciendo incluso que los clientes que tengan depósito y préstamo, aparezcan solamente una vez.

Si queremos realizar una intersección de conjuntos, por ejemplo obtener una relación de todos los clientes que tienen depósito y préstamo en la sucursal 10, bastaría cambiar el ∨ anterior por un ∧. Por


último para hacer una diferencia, habrá que cambiar el ∨ por un ∧ ¬, con lo que obtendremos los nombres de los clientes que tienen préstamo en la 10 pero no tienen depósito en dicha sucursal.

Por último, para realizar un producto cartesiano, por ejemplo, "Queremos obtener el nombre de los clientes con préstamo en la sucursal principal, y las ciudades en las que viven".

{t | ∃ s (s ∈ préstamo ∧ t[nombre_cliente] = s[nombre_cliente] ∧ s[nombre_sucursal] = "Principal" ∧ ∃ u (u ∈ cliente ∧ u[nombre_cliente] = s[nombre_cliente] ∧ t[ciudad] = u[ciudad] ))}

3.1.1.21. Cálculo Relacional Orientado a Dominios

Los datos que se guardan en variables correspondientes a atributos. Las variables se refieren a atributos, lo que en cálculo relacional orientado a tuplas era t[A] es ahora A1, por tanto para referirse a una tupla se deben nombrar todas las variables correspondientes a los atributos de esa tupla. (< x1, x2, ....., xn >). Por ejemplo, una tupla de préstamo se expresaría: < p, s, c, i > con: p = num_prestamo; s = nombre_sucursal; c = nombre_cliente; i = importe.

En el cálculo relacional orientado a dominios, la expresión general tendrá la forma: { < x1, x2, ....., xn > | P(< x1, x2, ....., xn >) }

Las distintas operaciones en este lenguaje serían:

Selección: Queremos los nombres de los clientes, número de sucursal, número de préstamo e importe de todos aquellos préstamos cuyo importe sea superior a un millón de pesos:

{ < p, s, c, i > | < p, s, c, i > ∈ prestamo ∧ i > 1,000,000 }

Proyección: Utilizaremos la cláusula ∃ . Por ejemplo sólo queremos los nombres de los clientes con préstamo superior a un millón.

{ < c > | ∃ < p, s, c, i > ∈ prestamo ∧ i > 1,000,000 }

Unión: Nombre de clientes que tengan préstamo, depósito o ambas cosas en la sucursal principal.

{ < c > | ∃ < p, s, c, i > ∈ prestamo ∧ s = "Principal" ∨ ∃ < s, cu, c, sa > ∈ deposito ∧ s = "Principal" }

Para la intersección y la diferencia, al igual que en el cálculo relacional orientado a tuplas basta sustituir el ∨ por un ∧ o un ∧ ¬ respectivamente.

Al igual que el álgebra relacional, el cálculo relacional tampoco es amigable para el usuario, por esta razón se han desarrollado lenguajes comerciales orientados al usuario, y que se basan en alguno de los lenguajes formales.

3.5.3. Lenguajes Orientados a la Transformación

Estos lenguajes no están orientados a procedimientos. Transforman los datos de entrada expresados como relaciones, en resultados expresados en una sola relación. Proporcionan estructuras fáciles de usar. SQUARE, SEQUEL y su descendiente SQL, son ejemplos de estos lenguajes. Incorporan entre otras funciones:


Definición de esquemas de datos Restricciones de integridad y seguridad Control de transacciones

3.5.4. Consulta por Ejemplo (QBE – Query By Example)

Ofrecen al usuario una imagen de la estructura de la tabla. Ejemplo: Access y Paradox.El usuario llena alguna forma con los datos que requiere y el sistema responde con datos reales en el formato especificado

3.6. Normalización

El objetivo básico del modelado lógico es desarrollar una buena descripción de los datos, sus interrelaciones y sus restricciones. Para el modelo relacional, esto significa que se debe identificar un conjunto correcto de relaciones. Sin embargo, la tarea de elegir las relaciones en ocasiones es difícil porque existen muchas opciones que debe considerar el diseñador. Las técnicas presentadas a continuación se basan en un gran conjunto de investigaciones sobre el proceso de diseño lógico generalmente llamado normalización.

La normalización es el proceso que sirve para crear relaciones bien estructuradas que cubren el modelo de las operaciones de una empresa, siguiendo un conjunto de principios bien definidos y mediante el cual se dividen relaciones en múltiples relaciones para eliminar las anomalías y manteniendo la integridad de los datos.

Siguiendo los principios de normalización, se obtiene un diseño que es altamente flexible, permitiendo que es modelo sea extendido cuando se necesitan nuevos atributos, entidades e interrelaciones. El diseño de la BD creado de esta forma refuerza cierto tipo de restricciones de integridad y reduce la redundancia, ahorrando espacio y evitando inconsistencias de datos. La esencia de la Normalización es que cuando una relación tiene anomalías, estas se eliminan dividiendo la relación en dos o más, donde cada una contendrá un solo tema.

3.6.1. Anomalías de datos

Las anomalías son estados de la BD inconsistentes, incompletos o contradictorios. Cuando se presentan estas anomalías, no es posible representar alguna información, se puede perder información cuando se realizan algunas actualizaciones y se corre el riesgo de tener inconsistencias.

Anomalía de Actualización. Inconsistencia de los datos como resultado de datos redundantes y actualizaciones parciales.

Anomalía de Borrado. Pérdida no intencionada de datos debido a que se han borrado otros datos.

Anomalías de Inserción. Imposibilidad de adicionar datos en la base de datos debido a la ausencia de otros datos.

El estudio de estas anomalías fue realizado originalmente por Codd, quien identificó las causas y definió las tres primeras “formas normales”. Una relación se encuentra en una formal normal específica si satisface el conjunto de requerimientos o restricciones para esa forma. Investigaciones posteriores realizadas por Boyce y Codd refinaron la tercera forma normal. Las investigaciones independientes de Fagin, Zaniolo y Delobel generaron la definición de tres nuevas formas. Todas las formas normales están anidadas, de modo que cada una satisface las restricciones de la anterior, pero es una mejor forma ya que elimina faltas encontradas en la forma anterior. El objetivo del diseño


debería ser generar un esquema en la forma normal más alta que sea práctica y apropiada para los datos en la BD. La normalización requiere que se tengan claras las características semánticas del modelo.

3.6.2. Tipos de Dependencias

En el intento de eliminar las causas de las anomalías, las investigaciones han identificado cuatro clases de dependencias:

Dependencia funcionales Dependencia transitivas Dependencia multivaluadas Dependencia de reunión

3.1.1.22. Dependencia Funcional

Una dependencia funcional (DF) es un tipo de relación entre atributos donde un atributo determina el valor de los otros.

Definición: Si R es el esquema de una relación y A y B son conjuntos no vacíos de atributos en R, se dice que B es dependiente funcionalmente de A si, y sólo si, cada valor de A en R está asociado con exactamente un valor de B en R.

Se escribe:AàB lo que se lee: “A determina funcionalmente a B”.

Para cada valor de A sólo hay un valor de B. Donde A es la determinante y B es el implicado (o dependiente). B es una información acerca de A. La definición dice que si dos tuplas en una extensión de R tienen el mismo valor para A, deben tener también el mismo valor para B. Esta regla no significa que A causa a B o que el valor de B se calcula a partir del valor de A por una fórmula. Simplemente significa que si se conoce el valor de A y se examina la tabla de la relación R, se encontrará sólo un valor de B en todos los renglones que tengan el valor dado de A en cualquier momento. Sin embargo, para un valor B dado, puede haber varios valores diferentes de A. Una dependencia funcional es pues una interrelación muchos a uno entre los atributos A y B. Nótese que A o B pueden ser conjuntos que consistan de un solo atributo.

Ejemplo:

EstudianteIdEstudiante Apellido Carrera Nivel Créditos CURP

1000 Pérez Historia Avanzado 90 AAAA1111111001 Ramírez Matemáticas Avanzado 95 BBBB2222221002 López Computación Básico 15 CCCC3333331003 Bravo Arte Intermedio 63 DDDD4444441004 Ramírez Computación Básico 25 EEEE555555

Se puede decir que:

{idEstudiante} à {apellido, carrera, nivel, créditos, CURP}{CURP} à {idEstudiante, apellido, carrera, nivel, créditos}


{Créditos} à {nivel}

Pero no se puede decir que

{Apellido} à {idEstudiante, carrera, créditos, nivel, CURP} {Créditos} à {idEstudiante, apellido, carrera, CURP}

Ya que el apellido se puede repetir, igual que la carrera o los créditos, pero los créditos determinan funcionalmente el nivel del estudiante, aunque el valor de créditos no sea único, lo cual indica que una determinante no necesariamente única.

Algunas dependencias funcionales son llamadas triviales porque siempre se satisfacen en cada relación. En las dependencias funcionales triviales, el implicado es un subconjunto de la determinante. Si todos los atributos en el conjunto de la derecha se incluyen en el lado izquierdo de la dependencia, o si los dos lados son iguales, la DF es trivial, ejemplo:

{A, B} à A{A, B} à B{A, B} à {A,B}

3.1.1.23. Dependencia Transitiva

Una dependencia transitiva es un tipo de relación entre mínimo 3 atributos donde Aà B, B à C pero B no à A.

Definición: Si A, B y C son atributos de la relación R, tales que Aà B, y B à C, entonces C es transitivamente dependiente de A.

Por ejemplo, en la relación anterior Estudiante, idEstudiante à créditos y créditos à nivel, por lo tanto idEstudiante à nivel.

Las dependencias transitivas causan anomalías, por lo que es recomendable la eliminación de ciertos tipos. Por ejemplo, en la tabla Estudiante, no se puede insertar la información de que cualquier estudiante con 30 créditos sea de nivel Básico hasta que exista ese estudiante, porque eso requeriría insertar un registro sin idEstudiante, lo que no estaría permitido. Si se borra una tupla de un estudiante con un cierto número de créditos asociados, se perderá la información del nivel asociado con esos créditos. Si existen varias tuplas con los mismos créditos y se cambia el nivel asociado, se puede accidentalmente omitir la actualización de todas las tuplas, dejando la BD en un estado inconsistente.

3.1.1.24. Dependencia Multivaluada

Fagin identificó otro tipo de dependencia que puede causar problemas diseño, las dependencias multivaluadas. Una dependencia multivaluada es un tipo de relación entre atributos donde un atributo multidetermina a otros pero entre los otros no hay una relación. Aàà B, Aàà C pero B no tiene relación con C.

Ejemplo:


En la siguiente tabla se asume que un profesor puede pertenecer a más de un departamento, por ejemplo al departamento de Computación y de Matemáticas. Un profesor puede pertenecer a varios comités, cada uno identificado por el nombre del comité, pero no existe interrelación entre departamento y comité.

Profesor/Departamento/ComitéidProfesor departamento comité

101 Computación Exámenes101 Matemáticas Exámenes101 Computación Titulación101 Matemáticas Titulación221 Biología Biblioteca330 Inglés Exámenes330 Inglés Admisión

De modo que esto obliga a escribir todas las combinaciones de los valores de departamento con los valores de comité para cada profesor, o de otra forma, parecería que existe una interrelación entre departamento y comité. Nótese que la llave de la relación debe ser {idProfesor, departamento, comité}. Si se desea actualizar un comité al que pertenece el profesor 101, se debe hacer en dos lugares, si se desea insertar la tupla de un profesor que no pertenece a algún comité no se puede, ya que comité es parte de la llave y no permite valores nulos. Similarmente, si se borra la membresía del profesor 221 al comité de Biblioteca, se pierde el resto de la información almacenada sobre él, ya que no se permiten valores nulos en la llave.

Ya que un profesor no está asociado con un solo departamento, sino con un conjunto de departamentos y está asociado con un comité específico en un momento dado, el conjunto de departamentos para un idProfesor particular es independiente del conjunto de comités para el profesor. Esta independencia es la causa de los problemas.

Definición: Sea R una relación teniendo atributos o conjuntos de atributos A, B y C. Existe una dependencia multivaluada del atributo B sobre el atributo A si y sólo si el conjunto de valores de B asociados con un valor de A es independiente de los valores de C.

Se escribe:

Aàà B, y se lee: “A multidetermina a B”.

Si R tiene al menos tres atributos A, B y C, entonces en R(A, B, C), si Aàà B, entonces Aàà C también. A diferencia de las dependencias funcionales, que hacían ciertas tuplas ilegales en las relaciones, las dependencias multivaluadas hacen ciertas tuplas esenciales en la relación. En el ejemplo anterior, es obligatorio incluir ciertas tuplas porque se han incluido otras. Por ejemplo, cuando se escribe la combinación 101 con los valores de departamento Computación y Matemáticas, se tienen que escribir dos tuplas para cada valor de comité, Exámenes y Titulación, y colocar cada valor de departamento en una tupla con cada valor de comité.

Definición alterna de Dependencia Multivaluada:

Más generalmente, si R es una relación con dependencias multivaluadas, A àà B

entonces en cualquier tabla para R, si dos tuplas t1 y t2, tienen el mismo valor A, entonces deben existir dos tuplas t3 y t4 que siguen las siguientes reglas:


1. t3 y t4 tienen el mismo valor A que t1 y t22. t3 tiene el mismo valor B que t13. t4 tiene el mismo valor B que t24. si R-B representa los atributos de R que no están en B, entonces t2 y t3 tienen los mismos

valores para R-B y5. t1 y t4 tienen los mismos valores para R-B

La dependencia Aàà B es llamada dependencia trivial multivaluada si B es un subconjunto de A o A U B es todo de R.

3.1.1.25. Dependencia de reunión

Dependencia de Reunión es cuando la existencia de una relación depende de la reunión de todas las combinaciones de otras relaciones. Una dependencia de reunión existe cuando para una relación R con subconjuntos de sus atributos A, B, …, Z, R es igual a la reunión de sus proyecciones en A, B, …, Z.

Como se verá más adelante, no todas las descomposiciones son sin pérdida, ya que existen proyecciones cuyas reuniones no generan la relación original. Por ejemplo, en la relación:

Empleado/Proyecto/Funciónnombre

empleadoFunción nombre proyecto

López diseñador Nueva EspañaLópez programador EmprendedorLópez diseñador EmprendedorPérez diseñador Emprendedor

La tabla muestra qué función realizan los empleados en cada proyecto. Se puede descomponer la tabla por proyección en dos tablas:

Tabla1 Tabla2nombre empleado Función función nombre proyecto

López diseñador diseñador Nueva EspañaLópez programador programador EmprendedorPérez diseñador diseñador Emprendedor

Sin embargo, cuando se reúnen las dos tablas, se obtienen tuplas adicionales que no aparecían en la tabla original, perdiendo información.

Resultado de Reunión de Tabla1 y Tabla2nombre

empleadofunción nombre proyecto

López diseñador Nueva EspañaLópez diseñador EmprendedorLópez programador EmprendedorPérez diseñador Nueva EspañaPérez diseñador Emprendedor

La tabla original puede ser recreada sólo reuniendo una tercera tabla:


tupla espúrea

Tabla3nombre

empleadonombre proyecto

López Nueva EspañaLópez EmprendedorPérez Emprendedor

La recreación depende de esta la reunión de las tres tablas:

Resultado de Reunión de Tabla1, Tabla2 y Tabla3nombre

empleadoFunción nombre proyecto

López Diseñador Nueva EspañaLópez Programador EmprendedorLópez diseñador EmprendedorPérez diseñador Emprendedor

3.6.3. Formas Normales

En la práctica, los diseñadores de BD generalmente desarrollan un modelo lógico inicial para la BD relacional transformando un DER u otro modelo conceptual en un conjunto de relaciones. Se identifica la PK y las posibles DFs durante el proceso del diseño conceptual. Transformando el DER el diseñador crea un modelo relacional que está casi totalmente normalizado. Para completar el proceso de diseño relacional, el diseñador verifica cada relación, identifica un conjunto de DFs para ella y cualquier otra existente que involucre la PK, normalizando si es necesario. Para guiar el proceso de normalización sobre PKs se usa un buen conjunto de reglas llamadas formas normales.

3.1.1.26. Primera Forma Normal

Definición. “Una relación está en primera forma normal (1FN) si, y sólo si, todos los valores en la relación son atómicos para cada atributo en la relación”.

Esto significa que cada atributo en cada renglón, o celda de la tabla, contiene sólo un valor, no puede contener conjuntos, listas, campos repetidos o grupos en el dominio. Los valores en el dominio deben ser valores simples que no pueden separarse en otros datos.


1000 Pérez Historia Avanzado 90 AAAA1111111001 Ramírez Matemáticas Avanzado 95 BBBB2222221002 López Computación

MatemáticasBásico 15 CCCC333333

1003 Bravo Arte Inglés Intermedio 63 DDDD4444441004 Ramírez Computación Básico 25 EEEE555555

En el ejemplo se puede permitir un estudiante realice más de una carrera; se podría intentar almacenar todas las carreras en una sola columna para cada estudiante. Esto violaría la 1FN. Es importante mantener las relaciones en 1FN de modo que los operadores relacionales, como se han


definido, funcionen correctamente. En este caso, si se realiza una búsqueda para los alumnos inscritos en la carrera de Matemáticas “Select idEstudiante From Estudiante where carrera = “Matemáticas”, ¿se deberían incluir aquellos que también tengan otra carrera? Para evitar las ambigüedades, cada relación debe tener valores atómicos en sus atributos.

Otra forma de tratar de normalizar podría ser cuando se conoce el número máximo de repeticiones que un atributo puede tener y se agregan nuevas columnas para los atributos. Por ejemplo, si se sabe que los estudiantes pueden estudiar máximo dos carreras, se podría intentar poner Carrera1 y Carrera2 como atributos. Las desventajas de esta aproximación son que se debe saber el número máximo de repeticiones, y si esto cambia, se deberá modificar el esquema y las aplicaciones que accedan esos datos; también, las consultas se vuelven más complejas y además se pueden tener demasiados espacios vacíos (nulos) en la tabla.

Otra alternativa sería hacer los atributos multivaluados parte de la llave. Usando este método, la nueva tabla contendría múltiples tuplas para cada estudiante con múltiples carreras. Esta solución dificultará tener la relación en una forma normal de nivel más alto ya que se tendrán muchos valores duplicados con las consecuentes anomalías de datos.

Pasos para lograr la 1FN:1. Crear una nueva relación con los atributos que se repiten.2. Borrar los atributos de la relación original.3. Formar la llave primaria con la llave primaria de la tabla original y un atributo que

determine funcionalmente el conjunto de valores repetidos.

Estudiante Estudiante/CarreraIdEstudiant

eApellid

oNivel Crédito

sCURP IdEstudiant

eCarrera

1000 Pérez Avanzado 90 AAAA111111 1000 Historia1001 Ramírez Avanzado 95 BBBB222222 1001 Matemáticas1002 López Básico 15 CCCC333333 1002 Computación1003 Bravo Intermedio 63 DDDD444444 1002 Matemáticas1004 Ramírez Básico 25 EEEE555555 1003 Arte

1003 Inglés1004 Computación

3.1.1.27. Segunda Forma Normal

Definición. “Una relación está en segunda forma normal (2FN) si, y sólo si, se encuentra en 1FN y todos los atributos que no son claves dependen por completo de la clave”. Aà B

Un atributo B de una relación R es totalmente dependiente funcionalmente de un atributo o conjunto de atributos A de R si B es funcionalmente dependiente de A pero no funcionalmente dependiente de cualquier subconjunto de A.

Suponiendo la tabla:

EstudianteidMateria idEstudiant

enombre estudiante idFacultad salón grado

art103a 1001 Pérez 101 H221 Aart103a 1010 Ramírez 101 H221art103a 1006 López 101 H221 B


cmp201a 1003 Rodríguez 105 M110 Acmp201a 1006 López 105 M110 Chis205a 1001 Pérez 202 H221

La llave de la relación sería {idMateria, idEstudiante}, por lo que existen atributos que son dependientes funcionalmente de la combinación de la PK, pero hay otros que son dependientes funcionalmente de un subconjunto de esa combinación, por ejemplo, aunque nombre estudiante es funcionalmente dependiente de la combinación {idMateria, idEstudiante}, también es dependiente funcionalmente de una parte de la PK (idEstudiante).

Claramente, si la relación está en 1FN y la PK consiste de un solo atributo, la relación está automáticamente en 2FN. Sólo hay que preocuparse de la 2FN cuando la llave es compuesta.

La transformación a 2FN se hace realizando proyecciones sobre la relación original de modo que sea posible obtener nuevamente la tabla original mediante la reunión de las proyecciones obtenidas. Aún si no existen atributos que dependan funcionalmente de la PK de la relación original, es importante mantener la relación (aún sólo con la PK) para poder reconstruir la relación original mediante la reunión. Esta “relación de conexión” muestra cómo se relacionan las proyecciones.

Pasos para lograr la 2FN:1. Crear una nueva relación usando los atributos que dependan parcialmente de la clave.2. Borrar los atributos anteriores de la relación original.3. Tomar la parte de la clave de que dependan los atributos eliminados (determinante) como

clave primaria de la nueva relación.

Estudiante/Materia Estudiante Materia/FacultadidMateri

aidEstudiant

egrad

oidEstudiant

enombre

estudianteidMateri

aidFaculta

dsaló

nart103a 1001 A 1001 Pérez art103a 101 H221art103a 1010 1010 Ramírez cmp201a 105 M110art103a 1006 B 1006 López his205a 202 H221

cmp201a 1003 A 1003 Rodríguezcmp201a 1006 Chis205a 1001

3.1.1.28. Tercera Forma Normal

Definición. “Una relación está en tercera forma normal (3FN) si, y sólo si, está en 2FN y todos los atributos no clave dependen funcionalmente de la clave y sólo de la clave ó son miembros de alguna llave candidata”. No hay Dependencias Transitivas.

Aún cuando las relaciones en 2FN son mejores que las que sólo están en la 1FN, aún pueden tener anomalías de datos. La 3FN indica que los atributos no clave deben depender de la clave, sólo de la clave y nada más de la clave. Ejemplo:


1000 Pérez Historia Avanzado 90 AAAA1111111001 Ramírez Matemáticas Avanzado 95 BBBB2222221002 López Computación Básico 15 CCCC3333331003 Bravo Arte Intermedio 63 DDDD444444


1004 Ramírez Computación Básico 25 EEEE555555

En esta relación idEstudiante à créditos y créditos à nivel, por lo tanto idEstudiante à nivel.

Pasos para lograr la 3FN:

1. Crear una nueva relación usando los atributos que dependan de otro atributo no clave.2. Borrar los atributos anteriores de la relación original.3. Tomar el atributo del cual dependan los atributos eliminados como clave primaria de la nueva

relación.

Estudiante Créditos/NivelIdEstudiant

eApellid

oCarrera Crédito

sCURP Crédito

sNivel

1000 Pérez Historia 90 AAAA111111 15 Básico1001 Ramírez Matemáticas 95 BBBB222222 25 Básico1002 López Computación 15 CCCC333333 63 Intermedio1003 Bravo Arte 63 DDDD444444 90 Avanzado1004 Ramírez Computación 25 EEEE555555 95 Avanzado

3.1.1.29. Forma Normal Boyce-Codd

Definición. “Una relación está en forma normal Boyce-Codd (BCFN) si cada determinante es una clave candidata”.

La definición de la 3FN es la original desarrollada por Codd y es suficiente para relaciones que tienen una sola llave candidata, pero es deficiente cuando hay múltiples llaves candidatas que son compuestas o traslapadas. Por ello fue formulada, una nueva definición de la 3FN, nombrada por sus creadores Boyce y Codd, para tomar en cuenta todos los casos. Ejemplo:

ProfesornombreProfeso

rdepartamento oficina nivel fechaContratació

nÁlvarez Arte A101 Académico 1975Bravo Matemáticas M201 Asistente 2000

Dorantes Arte A101 Asociado 1992García Matemáticas M201 Académico 2001

Hernández Matemáticas M203 Asociado 1990Salamanca Computación C101 Académico 1980Salamanca Historia H102 Asociado 2001

Trujillo Computación C101 Instructor 1995Vega Computación C105 Asociado 2000

En esta tabla se puede asumir que, aunque los nombres no son únicos, no hay dos profesores con el mismo nombre en el mismo departamento, cada profesor tiene sólo una oficina, un departamento puede tener varias oficinas y los profesores en el mismo departamento pueden compartir oficinas. A partir de esas suposiciones, se obtienen las siguientes DFs:

oficina à departamentonombreProfesor, departamento à oficina, nivel, fechaContratación


nombreProfesor, oficina à departamento, nivel, fechaContratación

En este caso existen llaves candidatas traslapadas (nombreProfesor, departamento) y (nombreProfesor, oficina). Si se elige (nombreProfesor, departamento) como PK, se obtiene una determinante que no es PK. Esto viola la FNBC. Nótese que la relación está en 3FN ya que oficina es parte de una llave candidata.

Pasos para lograr la BCFN:1. Crear una nueva relación con los atributos que estén determinados funcionalmente

por un determinante que no sea clave candidata.2. Borrar los atributos anteriores de la relación original.3. Tomar los atributos determinantes como llave primaria de la nueva relación.

Profesor Oficina/DepartamentonombreProfeso

roficina nivel fechaContratació

noficin

adepartamento

Álvarez A101 Académico 1975 A101 ArteBravo M201 Asistente 2000 C101 Computación

Dorantes A101 Asociado 1992 C105 ComputaciónGarcía M201 Académico 2001 H102 Historia

Hernández M203 Asociado 1990 M201 MatemáticasSalamanca C101 Académico 1980 M203 MatemáticasSalamanca H102 Asociado 2001

Trujillo C101 Instructor 1995Vega C105 Asociado 2000

La llave de Oficina/Departamento es oficina, ya que un departamento puede tener varias oficinas, pero cada oficina pertenece sólo a un departamento. Este esquema está en FNBC ya que la única determinante es llave. La llave de la segunda es {nombreProfesor, oficina} y también está en FNBC, ya que su única determinante es la llave. Sin embargo, este esquema no preserva la dependencia funcional nombreProfesor, departamento à oficina, nivel, fechaContratación, ya que estos atributos no permanecen en la misma relación, haciendo imposible expresar que estos determinan a los otros atributos.

En ocasiones, puede no ser deseable transformar una relación en FNBC. En particular, si existen dependencias funcionales que no se preservan cuando se realiza la descomposición y se vuelve difícil forzar la dependencia funcional en la BD ya que dos o más tablas deben ser reunidas para lograrla o se pierde una restricción importante. En ese caso, es preferible mantener la 3FN, que siempre permite mantener las dependencias.

3.1.1.30. Cuarta Forma Normal

Definición. “Una relación está en cuarta forma normal (4FN) si está en FNBC y no tiene dependencias de valores múltiples no triviales”. Ninguna relación puede contener dos o más relaciones 1:n ó n:m. AààB y Aàà C

Aunque la FNBC es suficiente para remover cualquier anomalía relacionada con dependencias funcionales, las investigaciones de Fagin identificaron la dependencia multivaluada que también causa problemas de diseño. Ejemplo:

Profesor/Departamento/Comité


idProfesor departamento comité101 Computación Exámenes101 Matemáticas Exámenes101 Computación Titulación101 Matemáticas Titulación221 Biología Biblioteca330 Inglés Exámenes330 Inglés Admisión

Esta tabla no está en 4FN porque idProfesor àà departamento y idProfesor àà comité.

Pasos para lograr la 4FN:1. Crear una nueva relación tomando uno de los atributos con dependencia de valores

múltiples.2. Borrar los atributos anteriores de la relación original.3. Tomar el atributo que multidetermina a los demás atributos y el atributo

multideterminado como llave primaria de la nueva relación

Profesor/Departamento Profesor/ComitéidProfesor departamento idProfesor comité

101 Computación 101 Exámenes101 Matemáticas 101 Titulación221 Biología 221 Biblioteca330 Inglés 330 Exámenes

330 Admisión

3.1.1.31. Quinta Forma Normal

Definición. “Una relación está en quinta forma normal (5FN) si está en 4FN y además no tiene dependencias de reunión (Join)”.

Esencialmente, esto significa que las únicas descomposiciones válidas son aquellas que involucran llaves candidatas. Las dependencias de reunión están relacionadas con dependencias de valores múltiples, pero pueden ser muy difíciles de identificar porque son sutiles. Si un diseño consiste de relaciones que están en 5FN, éstas están en su forma más simple, de modo que no se gana nada descomponiéndolas más, ya que ocasionarían pérdida de información. Desafortunadamente, no existe una forma simple de verificar la 5FN. Las dependencias de reunión son generalmente raras, de modo que los diseñadores terminan el proceso de normalización en 4FN, FNBC o 3FN para preservar las dependencias funcionales.

Si para dos relaciones con una interrelación M:M se puede obtener esta interrelación como resultado del producto cartesiano de ambas, se deben mantener separadas y no crear una tercera relación que defina la interrelación de ambas.

Como se mostró en ejemplo de la dependencia de reunión, si el producto cartesiano genera tuplas espúreas, se debe crear una tabla adicional que defina como se interrelacionan las otras dos.

3.6.4. Proceso de Descomposición sin Pérdida

Aunque la normalización puede realizarse usando la aproximación heurística basada en llaves primarias y fue demostrado en las secciones anteriores, una aproximación más formal al diseño de


BDs relacionales está basada estrictamente en dependencias funcionales y otros tipos de restricciones. Estas aproximaciones usan algoritmos de normalización para crear esquemas de relaciones. Para empezar, todos los atributos en la BD se colocan en una sola gran relación llamada la relación universal. Usando dependencias funcionales y otras restricciones, la relación universal es descompuesta en pequeños esquemas relacionales hasta que el proceso llega a un punto donde no se desean más descomposiciones. Es deseable que cada esquema de relación esté en BCNF o al menos en 3FN. Otras propiedades importantes incluyen la preservación de atributos, la preservación de dependencias y reuniones sin pérdida.

3.1.1.32. Preservación de atributos

Cuando la relación universal se construye contiene, por definición cada atributo en la BD. En el proceso de descomposición de la relación universal en pequeñas relaciones y moviendo los atributos a ellas, se desea asegurar que cada atributo aparezca en al menos una de las relaciones, de modo que ningún dato se pierda. Como se ha visto, el esquema de la BD generalmente contiene algunos atributos repetidos para representar las interrelaciones entre tablas. Sin embargo, los atributos tienen que ser colocados en las relaciones de modo que preserven toda la información, no sólo todos los atributos.

3.1.1.33. Preservación de la dependencia

Una dependencia funcional representa una restricción que debe ser forzada en la BD. Cada vez que se realiza una actualización, el DBMS debe verificar que la restricción no se viola. Es más fácil verificar restricciones sobre una tabla que verificar una que involucra múltiples tablas, lo que puede requerir hacer primero una reunión. Para evitar que tener que hacer esas reuniones, sería preferible que en una descomposición las dependencias funcionales involucren atributos que están en la misma tabla, si es posible. Dada una descomposición de una relación R, con un conjunto de dependencias funcionales en ella, sobre un conjunto individual de relaciones {R1, R2, …, Rn}, para cada dependencia funcional A à B es deseable para cada atributo en A U B que aparezcan en la misma relación Ri. Esta propiedad es llamada preservación de dependencia. Siempre es posible encontrar descomposición preservando la dependencia que está en 3FN, pero no siempre es posible encontrar una que está en FNBC.

3.1.1.34. Descomposición sin Pérdida

En las relaciones separadas, se tiene especial cuidado en usar proyecciones que pueden deshacerse reuniendo las tablas resultantes, de modo que la tabla original puede volver a obtenerse. Por tabla original se entiende no solo la estructura de la tabla, que son los nombres de columnas, sino también las tuplas. De modo que una descomposición es llamada descomposición sin pérdida, porque preserva toda la información en la relación original. Se ha usado la palabra descomposición, y su definición formal es:

Definición: Una descomposición de una relación R es un conjunto de relaciones {R1, R2, …, Rn} tales que cada Ri es un subconjunto de R y la unión de todas las Ri es R.

Ahora se puede definir descomposición sin pérdida:

Definición: Una descomposición {R1, R2, …, Rn} de una relación R es llamada descomposición sin pérdida para R si la reunión natural de R1, R2,… Rn produce exactamente la relación R.


No todas las descomposiciones son sin pérdida, porque existen proyecciones cuya reunión no dan exactamente la relación original. Por ejemplo:

Empleado/Proyecto/Rolnombre


López diseñador Nueva EspañaLópez programador EmprendedorLópez diseñador EmprendedorPérez diseñador Emprendedor

La tabla muestra qué función realizan los empleados en cada proyecto. Se puede descomponer la tabla por proyección en dos tablas:

Tabla1 Tabla2nombre empleado función función nombre proyectoLópez diseñador diseñador Nueva EspañaLópez programador programado

rEmprendedor

Pérez diseñador diseñador Emprendedor

Sin embargo, cuando se reúnen las dos tablas, se obtienen tuplas adicionales que no aparecían en la tabla original.

Resultado de Reuniónnombre


López diseñador Nueva EspañaLópez diseñador EmprendedorLópez programador EmprendedorPérez diseñador Nueva EspañaPérez diseñador Emprendedor

Estas son tuplas espúreas (falsas), creadas por los procesos de proyección y reunión. Ya que sin la tabla original, no hay forma de identificar cuáles tuplas son genuinas y cuáles espúreas, se puede perder información (aún cuando se tienen más tuplas) si se sustituyen las proyecciones para la relación original.

Se puede garantizar descomposición sin pérdida asegurándose que, para cada par de relaciones que se reúnen, el conjunto de atributos comunes es una llave de una de las relaciones. Esto puede hacerse colocando atributos funcionalmente dependientes en una relación con sus determinantes y manteniendo las determinantes por sí mismas en la relación original.

De modo más formal, para una descomposición binaria, si R es descompuesta en dos relaciones {R1, R2} entonces la reunión es sin pérdida si, y sólo si, alguno de los conjuntos de DFs para R, o es implicado por las DFs en R:

R1 ∩ R2 à R1 – R2ó

R1 ∩ R2 à R2 – R1


tupla espúrea

En el ejemplo, función no era una determinante para nombre de proyecto o nombre de empleado, de modo que la intersección de las dos proyecciones, función, no determina funcionalmente ninguna proyección. Existen muchos ejemplos de proyección sin pérdida cuando se normalizan relaciones.

3.7. Reglas de Codd

En dos artículos de 1985 (“Is Your DBMS Really Relational?” y “Does Your DBMS Aun by i.e. Rules?”), Codd publicó las reglas o principios que un RDBMS deben cumplir para ser considerados “totalmente relacionales”. Codd quería mantener la integridad del modelo relacional y para hacerlo claro identificó 12 reglas, junto con la Regla Cero. Las reglas proporcionan un conjunto estándares para juzgar si un RDBMS es totalmente relacional.

3.7.1. Regla Cero

Un DBMS debe almacenar los datos usando sólo sus capacidades relacionales. Este es el principio fundamental y por tanto, el DBMS debe cumplir todas las siguientes reglas.

3.7.2. Regla 1. Representación de la Información

Toda la información en una base de datos relacional debe ser representada explícitamente, a nivel lógico, en exactamente una manera, por valores en tablas.

3.7.3. Regla 2. Acceso Garantizado

Todos y cada uno de los datos en una base de datos relacional deben ser accesibles lógicamente mediante una combinación del nombre de tabla, nombre de columna y valor de la llave primaria.

3.7.4. Regla 3. Información Faltante

La falta de información y la información no aplicable se soportan en las bases de datos relacionales de modo sistemático e independiente del tipo de dato mediante los valores nulos. Los nulos deben ser distintos de cero o cualquier otro número, y de cadenas vacías.

3.7.5. Regla 4. Diccionario de Datos Dinámico basado en el modelo relacional

La descripción de la base de datos se representa dinámicamente, a nivel lógico, como datos ordinarios, de modo que los usuarios autorizados puedan aplicar el mismo lenguaje relacional para consultarla.

3.7.6. Regla 5. Lenguaje de datos Comprensible

No importa cuántos lenguajes y modos interactivos se soporten, por lo menos un lenguaje debe soportarse, con una sintaxis bien definida, que soporte interactivamente y por programa lo siguiente:

1. Definición de datos2. Reglas de integridad3. Manipulación de datos4. Vistas


5. Control de Transacciones (comienzo, cumplimiento y vuelta atrás)6. Reglas de autorización

3.7.7. Regla 6. Actualización de Vistas

Para cada vista el DBMS debe tener una forma de determinar, en el momento de la definición de la vista, si la vista puede ser utilizada para insertar renglones, borrar renglones, actualizar columnas sobre las tablas en las que está basada, y guardar los resultados de esta decisión en el catálogo del sistema.

3.7.8. Regla 7. Operaciones de Conjuntos (Insert, Delete y Update)

La capacidad de operar en tablas completas no sólo se aplica a la consulta, sino también a la inserción, modificación y borrado de datos. Las operaciones de conjuntos, independientes de la estructura física de los datos, se logra gracias a un proceso llamado optimización que es único para las bases de datos relacionales.

3.7.9. Regla 8. Independencia Física de los Datos

Esto se refiere a una separación, hecha por el DBMS, de los aspectos físicos y lógicos de la base de datos. Las operaciones interactivas y los programas de aplicación no deben ser modificados cuando cambian las estructuras internas de almacenamiento y los métodos de acceso a la base de datos.

3.7.10. Regla 9. Independencia Lógica de los Datos

Las operaciones interactivas y los programas de aplicación no deben ser modificados cuando se realizan cambios sobre las estructuras de las tablas de la base de datos que no involucren pérdida de información, como descomposición de tablas o combinación de tablas.

3.7.11. Regla 10. Independencia de Integridad

Las operaciones interactivas y los programas de aplicación no deben ser modificados cuando se realizan cambios sobre las reglas de integridad definidas y almacenadas en el catálogo de la base de datos. Las restricciones de integridad como la integridad en la entidad y la integridad referencial deben ser especificadas en el sublenguaje de datos y almacenadas en el catálogo. Los programas de aplicación y las operaciones interactivas no deben ser usados para expresar estas restricciones.

3.7.12. Regla 11. Independencia de Distribución

Esta regla se refiere a DBMSs distribuidos. El concepto de independencia de distribución es similar a las reglas de independencia física, lógica y de integridad anteriores, pero aplicadas a distribución a través de computadoras.

Esta regla implica que todas las características y reglas requeridas por el modelo deben extenderse a todo el sistema distribuido.

3.7.13. Regla 12. No Subversión


Si un DBMS se maneja con un lenguaje de bajo nivel (procedural), esto no debe representar el omitir las reglas de integridad y de seguridad que se contemplan con el uso de un lenguaje de alto nivel, y que son almacenadas en el diccionario de la base de datos.

3.8. Estándar SQL

Los lenguajes comerciales permiten definir las estructuras, los limitantes de integridad y los limitantes de seguridad. Los sistemas manejadores de bases de datos relacionales (RDBMS) comerciales requieren un lenguaje de consulta amigable con el usuario; durante varios años, se han implementaciones varios lenguajes de este tipo entre los que se encuentran SQL (Structured Query Language). Aunque es un lenguaje llamado de consulta (Query), contienen muchas otras capacidades además de consultar una base de datos, entre las que se incluyen: definición de la estructura de los datos, actualización de datos y especificación de restricciones de seguridad.

SQL es un lenguaje estándar usado para comunicarse con sistemas manejadores de bases de datos relacionales (RDBMS). El estándar SQL ha sido definido por la Organización Internacional de Estándares (ISO – International Standards Organization) y el Instituto Nacional Americano para la Estandarización (ANSI – American National Standars Institute). El nombre oficial del lenguaje es Lenguaje Estándar Internacional de Bases de Datos SQL (International Standar Database Language SQL) dado en 1992. De los distintos lenguajes que se usaban en los primeros RDBMSs, SQL se impuso como estándar en los RDBMSs actuales y aunque existen algunas variaciones, se sigue intentando su normalización.

Está basado sobre todo en el álgebra relacional. Tiene también facilidades del cálculo relacional, de manera que ciertas tareas pueden ser hechas de varias formas. Es por tanto un lenguaje procedimental y aprocedimental al mismo tiempo.

3.8.1. Antecedentes

Como sabemos, el modelo relacional surgió a finales de los 60s como resultado de las investigaciones de E.F. Codd en los laboratorios de IBM en San José de California; los trabajos de Codd, provocaron una serie de estudios teóricos y prototipos que se extienden a partir de 1970.

El lenguaje SQL inicialmente fue definido durante los 70s, y se llamaba SEQUEL, diminutivo de Structured English Query Language (Lenguaje Inglés Estructurado de Consulta). SEQUEL fue implementado originalmente como parte del Sistema R, un prototipo de RDBMS llamado SEQUEL-XRM, durante los años 74 y 75. Este prototipo evolucionó durante el 76 y 77, pasando a ser SEQUEL/2, en esta versión se empezaron a soportar consultas multitabla y acceso multiusuario. La palabra English eventualmente se eliminó del nombre original y la abreviatura cambió a SQL por motivos legales. Poco después, el Sistema R de IBM implementó un subconjunto de este lenguaje.

Oracle Corporation, formalmente Relational Software Inc., produjo la primera implementación comercial del lenguaje en 1979, Oracle se adelantó por dos años comercialmente a IBM y se ejecutaba en minicomputadoras VAX y Digital que eran menos caros que las maxicomputadoras de IBM, posteriormente van creándose otros productos basados en SQL como SQL/DS, DB2, DG/SQL, SYBASE, INTERBASE, INFORMIX, UNIFY, incluso otros productos que no tenían SQL como lenguaje base (INGRES, ADABAS, etc.) ofrecen interfaces SQL por lo que se convierte en estándar.

Aunque la mayoría de los vendedores de bases de datos relacionales soportan SQL/92, el cumplimiento del estándar no es al 100%. Actualmente, existen diferentes tipos de SQL en el mercado, ya que cada vendedor de RDBMS intenta extender el estándar para incrementar la


comercialización de su producto. Aunque el curso se centra particularmente en el estándar SQL/92, la implementación en cada plataforma tiene diferencias o capacidades particulares propias de cada versión propietaria del lenguaje.

3.8.2. Versiones

En 1982 el Comité de bases de datos X3H2 de ANSI, presentó un lenguaje relacional estándar basado principalmente en el SQL propio de los productos IBM; en 1886 este organismo aprueba el lenguaje como norma pasando a denominarse SQL/ANSI, que también es aprobado el siguiente año como norma ISO (ISO 1987). En esta norma se especifican dos niveles (I y II) a cumplir, siendo el nivel I un subconjunto de las funcionalidades proporcionadas por el nivel II. Este estándar recibió muchas críticas ya que es una intersección de las instrumentaciones existentes, concebido primordialmente para proteger los intereses de los fabricantes; debido a esto, Codd afirma que el SQL/ANSI es muy débil, fallando en el soporte de muchas características que los usuarios realmente necesitan si quieren aprovechar todas las ventajas del enfoque relacional. El SQL/ANSI es incluso menos fiel al modelo relacional que las versiones comerciales.

En 1989 se revisa la versión 1 del estándar conocida como Addendum, que agrega cierta integridad referencial, que se denomina integridad referencial básica, ya que sólo permite definir la opción restringir modificación y borrado y no proporciona cambios en cascada. Por otro lado, ya que la norma ISO 89 no estandariza las definiciones para SQL embebido en lenguajes de programación, ANSI define ese mismo año un estándar para SQL embebido (ANSI 1989). Ese mismo año, Apple Computer presenta el Data Access Language (DAL) para sus computadoras, el cual es un dialecto del SQL que soporta varios RDBMSs.

En junio de 1990, IBM anuncia su estándar DRDA (Distributed Relational Database Access) como parte de la arquitectura SAA (System Application Architecture).

En abril del 91 el SAG (SQL Access Group) completa la Fase I de especificaciones técnicas, que define un estándar para intercambiar mensajes SQL sobre una red OSI, basado en la especialización SQL del RDA de ISO. En junio del 91 este grupo realizó una demostración con más de veinte RDBMSs que se intercambiaban datos y consultas. En el mes de noviembre de ese mismo año, Microsoft anunció ODBC (Open Database Connectivity) basado en es estándar del SAG.

En 1992 este grupo completó su segunda fase, que especificaba una API (Application Programming Interface) y CLI (Call Level Interface) y que ampliaba el estándar a más instalaciones cliente/servidor, en la que además de las especificaciones OSI se incluyen otros protocolos de red como TCP/IP. En noviembre de ese año Borland relanzó el estándar ODAPI (Open Database Application Programming Interface) como IDAPI (Integrated Database Application Programming Interface), con el patrocinio de IBM, Novell y WordPerfect.

También en el 92 se aprueba como norma internacional una nueva versión conocida como SQL2 o SQL-92 (ISO 1992), en la que se incrementa sustancialmente la capacidad semántica del esquema relacional, se agregan nuevos operadores, se mejora el tratamiento de errores y se incluyen normas para el SQL embebido. En esta nueva norma se definen tres niveles de conformidad distintos: Entry SQL, Intermediate SQL y Full SQL, Siendo este último el que ofrece mayores funcionalidades, mientras que el primer nivel es un subconjunto del segundo y este, del tercero.

Este estándar fue complementado con dos nuevas partes que abordan la interfaz a nivel de llamadas (Call Level Interface), ISO 1995 y la definición de módulos almacenados persistentes (Persistent Store Modules) ISO 1996. Esta versión de la norma internacional convierte a SQL en un lenguaje computacionalmente completo agregando estructuras de control, manejo de excepciones, etc.


Durante la segunda mitad de los 90s, se hizo un gran esfuerzo para ampliar el SQL para que soportara la orientación a objetos. El resultado fue un estándar tan voluminoso que fue dividido en nueve partes. Esta versión, conocida en un principio como SQL3 y finalmente como SQL:1999 (ISO 1999) incluyó nuevas características como nuevos tipos de datos básicos (very large objects), tipos definidos por el usuario, disparadores, operadores de consulta recursivos, cursores sensitivos, generalización de tablas y roles de usuario.

Recientemente, se ha publicado una nueva versión del estándar, el SQL:2003 (ISO/IEC 9075, 2003) que revisa todas las partes del estándar anterior. En esta nueva versión se incluyen, entre otras características el SQL/XML (especificaciones relacionadas con XML) y otras características como nuevos tipos de datos básicos (es decir, bigint, multiset y XML), mejoras de las rutinas SQL equivocadas, extensiones de la sentencia CREATE TABLE, una nueva sentencia MERGE, un nuevo objeto de esquema (el generador de secuencias o valores secuenciales) y dos nuevas clases de columnas: identidad, que son aquellas que funcionan como contadores y generadas, aquellas que se obtienen por la combinación de otras columnas.

3.8.3. Estructura de instrucciones

Una de las principales características de SQL es que es declarativo o no procedural. Desde el punto de vista de los programadores, esto implica que el programador no necesita especificar paro a paso todas las operaciones que la computadora tiene que hacer para obtener un resultado particular. En vez de eso, el programador indica al RDBMS lo que necesita obtener y el sistema decide por si mismo cómo obtener el resultado deseado.

SQL es un lenguaje muy completo que incluye:

Lenguaje de de definición de datos (DDL). El SQL DDL proporciona órdenes para definir la estructura y organización de los datos almacenados y sus relaciones, permitiendo especificar diversos objetos, eliminar los objetos existentes y modificarlos.

Recuperación de datos. SQL permite recuperar los datos almacenado de la base de datos para mostrarlos directamente o usarlos en alguna aplicación; para ello incluye un lenguaje de consulta basado en álgebra relacional y el cálculo relacional de tuplas.

Lenguaje de manipulación de datos (DML). El SQL DML También incluye instrucciones para insertar, suprimir y modificar tuplas de la base de datos.

Definición de Vistas. El SQL DDL incluye instrucciones para definir vistas que facilitan las consultas a los usuarios finales.

Autorización (DCL). El SQL DCL incluye instrucciones para especificar derechos de acceso a tablas y vistas; de este modo restringe la capacidad de los usuarios de recuperar, agregar, eliminar o modificar datos, protegiendo así los datos de accesos no autorizados.

Integridad. El SQL DDL proporciona también medios para definir varias especificaciones de integridad que mantienen los datos consistentes y la protege contra corrupciones debidas a actualizaciones inconsistentes o a fallos del sistema.

Control de transacciones. SQL incluye instrucciones para especificar el inicio y fin de transacciones, permitiendo el bloqueo de datos para controlar la concurrencia. SQL se emplea para coordinar la capacidad de compartir datos por parte de usuarios concurrentes, asegurando que no interfieren unos con otros.

Las instrucciones o comando que componen el lenguaje SQL son generalmente divididas en tres principales categorías o sublenguajes. Cada sublenguaje se especializa en un aspecto particular del lenguaje. Uno de estos sublenguajes es el DDL o Data Definition Language (Lenguaje de Definición


de Datos), también se le conoce como Schema Definition Language de acuerdo con ANSI; este lenguaje incluye instrucciones que soportan la definición o creación de los objetos de la Base de Datos como tablas, índices, secuencias y vistas. Algunas de las instrucciones más comunes usadas en instrucciones DDL son las diferentes formas de los comandos CREATE, ALTER y DROP. Otro sublenguaje principal, el DML o Data Manipulation Language (Lenguaje de Manipulación de Datos), incluye instrucciones que permiten el procesamiento o manipulación de los objetos de la base de datos. Algunas de las instrucciones DML más comunes son las diferentes modalidades de los comandos SELECT, INSERT, UPDATE y DELETE. El último Data Control Language o DCL (Lenguaje de Control de Datos) es utilizado en el control de acceso a datos en la base de datos, ejemplo GRANT y REVOKE. Es importante observar que todos los objetos creados en una base de datos se almacenan en el diccionario de datos o catálogo de sistema.

SQL puede ser usado interactivamente o en su forma embebida. El SQL Interactivo o por comandos permite al usuario indicar comandos de modo interactivo directamente al DBMS y recibir los resultados tan pronto como se producen. Cuando se usa SQL Embebido, las instrucciones SQL se incluyen como parte de programas escritos en un lenguaje de propósito general como C, C++, Java o COBOL. En este caso, nos referimos al lenguaje de propósito general como Lenguaje anfitrión. La razón principal para usar SQL embebido es usar características adicionales del lenguaje de programación que no son soportadas generalmente por SQL.

Cuando se usa SQL embebido, el usuario no observa directamente la salida de las diversas instrucciones, en vez de ello, el resultado se retorna en variables o parámetros de procedimientos.

Como regla general, cualquier instrucción SQL que puede ser usada interactivamente, puede ser usada como parte de un programa de aplicación. Sin embargo, el usuario necesita tener en cuenta que pueden haber diferencias sintácticas en las instrucciones cuando se usan interactivamente o cuando se usan en modo embebido dentro de programas.

Ya que SQL es exclusivamente usado con RDBMSs, es necesario conocer los conceptos básicos de este tipo de base de datos para comprender mejor las características del lenguaje.

Aunque SQL se basa en el modelo relacional, incorpora algunos elementos adicionales que facilitan la gestión de datos. En este sentido se introduce el concepto de catálogo. Un RDBMS puede tener uno o varios catálogos y a su vez, una o varias bases de datos. En cada catálogo existe una definición que contiene las tablas base sobre las que se define un conjunto de vistas o esquemas que son autodescriptivos.

En el catálogo se puede encontrar además de tablas, dominios, aserciones (restricciones que afectan a varias tablas), vistas, privilegios, conjuntos de caracteres (Character Set), secuencias de ordenación (Collation) y traducción (Translation) para esos conjuntos de caracteres. Esto permite soportar idiomas como el japonés, coreano o chino, se superan los 256 caracteres que pueden obtenerse con unan extensión de 8 bits del código ASCII.

El estándar SQL es enorme, por lo que sólo se revisarán los aspectos comunes más significativos.

SQL tiene varios elementos de sintaxis que son utilizados en la mayor parte de las instrucciones, entre ellos:

Identificadores. Nombres de los objetos como tablas, vistas columnas, bases de datos, etc. Operadores. Los operadores periten realizar operaciones aritméticas, lógicos, relacionales,

asignaciones o concatenaciones de valores. Se usan para cambiar datos (permanente o temporalmente), para buscar tuplas o atributos que cumplan con determinada condición.


Comentarios. Fragmentos de texto en instrucciones para explicar instrucciones. Es texto no ejecutable usados para documentar código, deshabilitar temporalmente instrucciones y lotes de instrucciones SQL. (Por ejemplo en MySQL # y /* …*/).

Palabras reservadas. Todas las que utiliza SQL y no deben emplearse como identificadores. Cada SQL tiene su propio conjunto.

Tipos de datos. Definen el conjunto de valores que pueden contener los objetos como columnas, variables y parámetros.

Funciones. Que pueden tomar valores como parámetros y retornan un valor escalar o un conjunto en forma de tabla.

Para especificar las cláusulas del lenguaje se usará una extensión de la Forma Normal Backus (BNF), donde:

<> representa símbolos no terminales del lenguaje::= es el operador de definición[] indica elementos opcionales{} agrupa elementos opcionales| indica una alternativa* indica repetición, en general las repeticiones se separan con coma.

Cualquier instrucción SQL o comando es una combinación de una o más cláusulas. Las cláusulas son, en general, introducidas por palabras reservadas. Un ejemplo de una instrucción es:

SELECT <expresión>*[FROM <nombreDeTabla>*WHERE <condición>*ORDER BY <expresión>*]

En esta instrucción, se pueden distinguir cuatro palabras reservadas y cuatro cláusulas. Una palabra reservada es una palabra que tiene un significado específico dentro del lenguaje. El uso de palabras reservadas fuera de su contexto generará errores. Cada cláusula inicia con una palabra reservada.

Algunas de las cláusulas dentro de la sintaxis de las instrucciones son opcionales y otras obligatorias, las cláusulas encerradas entre corchetes son opcionales.

Las instrucciones SQL se asemejan a frases en inglés, completadas con palabras de relleno que no agregan nada al significado de la frase pero que hace que se lea más naturalmente.

Al escribir instrucciones o comandos de SQL es útil seguir ciertas reglas y guías para mejorar la lectura de las instrucciones y facilitar su edición en caso necesario. Algunas de estas reglas son:

Las instrucciones SQL no son sensibles a mayúsculas y minúsculas. Sin embargo, en ocasiones las palabras reservadas generalmente se escriben en mayúsculas para mejorar la facilidad de lectura de las instrucciones.

Las instrucciones SQL pueden escribirse en una o varias líneas. Es costumbre escribir cada cláusula en su propia línea.

Las palabras reservadas no se pueden separar en diferentes líneas y a excepción de unas cuantas instrucciones, no se pueden abreviar.

En la mayoría de los RDBMS, las instrucciones SQL terminan siempre con un punto y coma (;).


3.9. Transformación del Modelo E/R al Modelo Relacional

Un DER puede convertirse a un modelo relacional fácilmente. Para convertirlo:

Las entidades fuertes representadas por rectángulos se convierten en relaciones representadas por tablas. El nombre de la tabla es el mismo que el nombre de la entidad, que es el nombre escrito dentro del rectángulo.

Para entidades fuertes, los atributos simples, no compuestos, representados por elipses, se convierten en atributos de la relación, o encabezados de columnas.

Para atributos compuestos, el modelo relacional puro no permite representar directamente estos atributos, en ese caso se puede usar una columna para cada atributo simple que forma el atributo compuesto o se puede elegir dejar el atributo compuesto como un solo atributo.

Los atributos multivaluados tampoco se pueden representar directamente en un modelo relacional, ya que violarían la 1FN. La solución general es removerlos de la tabla y crear una relación separada que tenga la PK de la entidad junto con el atributo multivaluado. La llave de esta nueva tabla es la combinación de la llave de la tabla original y el atributo multivaluado. Si existen varios atributos multivaluados en la tabla original, se debe crea una nueva tabla para cada uno. Estas nuevas tablas son tratadas como entidades débiles, con la tabla original actuando como la entidad padre. Es conveniente nombrar las nuevas tablas usando la forma plural del atributo multivaluado.

Las entidades débiles también se representan como tablas, pero requieren atributos adicionales. Se debe recordar que una entidad débil es dependiente de otra entidad y no tiene llaves candidatas consistentes sólo de sus atributos propios. Por tanto, la PK de la entidad padre se usa para mostrar de qué instancia de la entidad padre depende la entidad débil. Para representar la entidad débil, se usa una tabla cuyos atributos incluyen todos los atributos de la entidad débil más la llave primaria de la entidad padre. La entidad débil debe tener un discriminador, algún atributo que junto con la PK de la entidad padre permita identificar cada tupla. Se usa la combinación de la PK del padre y el discriminador como llave.

Las interrelaciones también pueden transformarse directamente en tablas. Una interrelación pude representarse por una tabla teniendo las llaves primarias de las entidades asociadas como atributos, Si la interrelación no tiene atributos descriptivos, se puede construir la tabla de interrelación correspondiente simplemente creando encabezados de columnas consistentes de las llaves primarias de las entidades asociadas. Si la interrelación tiene atributos descriptivos, estos también se convierten en atributos de la relación, se modo que se tienen columnas para ellas y para la PK de las entidades asociadas.

o Para interrelaciones binarias 1:1 ó 1:M se puede elegir no representar las interrelaciones en tablas separadas. Siempre que la interrelación sea uno a uno o uno a muchos, es posible usar llaves foráneas para mostrar las interrelaciones.

o Si A:B es uno a muchos, se puede colocar la llave de A (el lado de uno) en la tabla B (el lado de muchos), donde se convierte en una llave foránea.

o Para entidades débiles, la interrelación con su padre ya está representada, porque la PK de la entidad padre ya está en la tabla de la entidad débil, de modo que no se requiere usar otra tabla para representar su conexión.

o Todas las entidades que tengan una relación uno a uno deben examinarse cuidadosamente para determinar si son la misma entidad. Si es así, deben combinarse en una sola entidad. Si A y B son verdaderamente dos entidades separadas teniendo una interrelación uno a uno, entonces se puede poder la llave de cualquier relación en la otra tabla para mostrar la conexión. Sólo se debe trata de llevar la llave foránea a la tabla que cause menor cantidad de valores nulos.


o Para una relación binaria, el único caso donde es imposible crear la interrelación sin otra tabla es en el caso muchos a muchos. Aquí, la única forma de mostrar la conexión es mediante otra tabla. Es importante mencionar que esta tabla se requerirá aún se no existen atributos descriptivos para la interrelación.

o Cuando se tienen interrelaciones ternarias ó n-arias involucrando tres o más entidades, se debe construir una tabla de interrelación, en la cual se colocan las PKs de las entidades asociadas. Si la interrelación ternaria o n-aria tiene atributos descriptivos, éstos se agregan a la nueva relación.

o Cuando se tiene una interrelación recursiva, su representación depende de la cardinalidad. Siempre se puede representar esta interrelación con una tabla separada, cuidando la cardinalidad. Si la cardinalidad es muchos a muchos, siempre se debe crear la tabla de interrelación. Si es uno a uno o uno a muchos, se puede usar el mecanismo de llave foránea.

o Las interrelaciones de generalización/especialización requieren que la llave primaria del supertipo sea pasada como llave primaria al subtipo como llave primaria y foránea.

Elegir crear o no una tabla adicional en los casos de las interrelaciones uno a uno y uno a muchos depende de la aplicación que se esté diseñando. Tener las interrelaciones en tablas separadas proporciona mayor flexibilidad, permitiendo cambiar las asociaciones fácilmente. Sin embargo, esto requiere realizar reuniones siempre que se use la interrelación, lo cual produce un bajo desempeño si muchas aplicaciones requieren las reuniones. El diseñador debe elegir entre flexibilidad y eficiencia, dependiendo del criterio para la aplicación.

Además de representar las entidades, atributos e interrelaciones mediante tablas y columnas, el modelo puede incluir las siguientes restricciones en cada columna:

Para llaves primarias: PK – que indica que es una llave primaria y automáticamente es no nula, no duplicada y no

cambiable. AS – que indica que la llave primaria es generada por sistema como un número secuencial. AU – que indica que la llave primaria es determinada por el usuario.

Para el resto de los atributos: FK – que indica que el atributo es una llave foránea. NN – que indica que el atributo es obligatorio, no puede tener valores nulos. ND – que indica que el atributo no puede duplicarse, no puede haber dos tupla con el mismo

valor en esa columna, su valor es único. NC – que indica que el valor de la columna no se puede modificar, si se desea cambiar, se

deberá borrar la tupla y crear una nueva con el nuevo valor.

En los casos de FK y ND, cuando estas restricciones se refieren a conjuntos de columnas que deben cumplir la restricción, se pueden numerar (FK1, FK2, …, FKn) para indicar que es una restricción compuesta por varios atributos.

Tarea.a. Leer al menos 2 fuentes adicionales sobre los temas vistos en esta unidad y hacer un resumen

de la unidad (máximo 1 cuartilla). No olvidar conclusiones y bibliografía.b. Explicar cuáles son las diferencias entre el modelo de Red, Jerárquico y Relacional, entre el

modelo orientado a objetos y objeto relacional, entre la intensión y la extensión de la BD.


bases de datos unidad 3

Documents